Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


porting FreeRTOS on ADUC7026

Posted by emerico on December 11, 2005
I have many problem with my FreeRTOS on ADUC7026 and have decided to control how the porting have been done.
The starting point of porting was LPC2129, using Keil debugger.

the portBYTE_ALIGNMENT is currently set to 4 as ADuc7026 (ARM7)has a 32 bit data bus.

My Question:

Which value should be set for portBYTE_ALIGNMENT
when l used the THUMB MODE?
my response is 2 because my memory will then be a 16-bit memory system, which increase performance on THUMB mode.
portBYTE_ALIGNMENT is currently set to 4 and l want to use THUMB Mode to reduce memory.
ADUC7026 can support 8 bit 16 bit or 32 bit mode.

Any new idea is wellcome.
Best regards

RE: porting FreeRTOS on ADUC7026

Posted by Nobody/Anonymous on December 11, 2005
Thumb mode uses 16 bit instructions (code) but is still 32 bit data? Byte alignment must therefore still be 4.

RE: porting FreeRTOS on ADUC7026

Posted by emerico on December 11, 2005
okay thank you very much.

RE: porting FreeRTOS on ADUC7026

Posted by Nobody/Anonymous on January 19, 2006
I am trying to port FreeRTOS to ADuC7026 and I am looking for sugestions on what is the best way to do it. I realise that it this part doesn't have VIC. Is there are any example on how to implement software IRQ handler? Is there are any other things I need to be aware of? Any sugestions will be greatly appreciated.



RE: porting FreeRTOS on ADUC7026

Posted by Nobody/Anonymous on January 20, 2006
Not familiar with this part, but if there is no VIC then I am guessing that you have to ascertain the interrupt source in software? Is this correct?

I would have thought your best options would be to have a common interrupt entry point and save and restore the context each interrupt. This would not be very efficient though. Normally if the interrupt cannot cause a context switch there is no need to save/restore the context, but if on entry you don't know what the interrupt is you also don't know if the interrupt can cause a context switch.

Alternatively use the banked registers only when ascertaining the interrupt source. This way the system mode registers remain completely uncorrupted. Once you know what caused the interrupt you can save the context if necessary, and the system mode registers can be saved in their original state.

Just guessing though.

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner