Forums

Re: some questions about keil mcb2300 (with lpc2378)

Started by Joel Winarske October 1, 2007
karelvergauwe wrote:
> I have bought a mcb2300 v3.1 board from Keil. I have tested some
> example programs wich I loaded with uVision3 and my ULINK2.
>
> I would like to have a RTOS on it for my project. I saw freeRTOS and
> think this is the best. Others I have seen are: eCos, RedBoot,
> tnkernel. Can I edit the code for freeRTOS with any development tool.
>

Yes. You may also want to review these, both high quality products:
http://www.micrium.com/products/rtos/kernel/rtos.html // They now
distribute OS source with app notes. They have made some aggressive
progress in the past two years.
http://www.segger.com/embos_general.html

RTOS selection should be based on your design requirements.
freeRTOS.org does not support events yet, which are quite useful with
ISR handlers.

> How can I start with it on a fast way. Wich is the easiest tool for
> programming and debugging (on Windows XP). I found the Keil software
> very good and easy to use, but I think my project is going to exceed
> the 16kB. Wich other easy to use tools are there which I can use with
> ULINK2 (or can I get around the 16kB limitation of Keil). I saw
> Yagarto with OpenOCD but don't know if my linker will work with this.
>

Another path worth exploring:

IAR offers a 30-day evaluation of their EWB-IAR toolset:
http://www.iar.com/p89661/p89661_eng.php#ev

With this you can build the uC/OS-II LPC3278 port and run it on your
mcb2300 board with very little effort.
http://www.micrium.com/nxp/LPC23xx.html

An Engineer's Guide to the LPC2100 Series

> RTOS selection should be based on your design requirements.
> freeRTOS.org does not support events yet, which are quite useful
with
> ISR handlers.

You can signal events via queues, semaphores and mutexes within ISRs -
but I assume you are referring to the lack of event flags as a
separate feature....

....Implementing event flags is straight forward. Implementing them
in a manner that does not require a critical section to be entered
for the entirety of a flag set or clear function is another matter
(this is generally a long operation as there will be sets of tasks
waiting for different combinations of flags). Generally using event
flags kills your worst case interrupt response time - although under
FreeRTOS.org this could be minimised using the scheduler locking
mechanism (whereby critical sections can be entered without leaving
interrupts disabled).

An alternative solution is to have an event flag service task that
runs at a high priority, but this requires RAM to being allocated to
this task and still suffers from starvation of your application tasks
while the event flags status is being updated - but at least no
critical section is required.

Regards,
Richard.

+ http://www.FreeRTOS.org
13 official architecture ports, 1000 downloads per week.

+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related
systems.