Hello all LPC users,
I'm quite new with embedded development, so please be gentle :-)
I'm about to start my little project for developing an AVL (Automated
Vehicle Location) solution using the LPC2106.
I've studied the alternatives regarding a free RTOS for this little
beast and I've found two so far:
- FreeRTOS
- ecos
I'd like to hear about your experiences with these so I can choose
wisely. From what I've seen, FreeRTOS looks lightweight and simple,
while ecos is quite mature (not that FreeRTOS isn't) and is loaded
with additional functionalities and very configurable.
Question 1: So, to cut the long story short, which RTOS would you
recommend for LPC2106?
There is another feature the project cannot be without, but I'll
start a different thread for it. I'll mention it also here since it
might influence the choice for an RTOS.
After we will develop the hardware and the software, the device will
be shipped to customers.
What will happen if I found a bug in my little piece of software I've
written? Fix the bug and update firmware on each device. Easy, huh?
NOT!
For the first testing phase, we'll equip around 10 vehicles which
will be spread all over the country. This means that I have to wait
for each vehicle to arrive at a central location to update it's
software. That's more or less ok for 10 vehicles. What about for 100?
Or 500? Updating software might become a nightmare for me!
I need a way to update the microcontroller software via Internet/GPRS
(the device will be equipped with a GPRS module).
Question 2: So, the main question is this: do you know of a way to
dynamically load a module from an SD card?
I've seen such code in ecos but it only works (currently) with
PowerPC. And my fear is that ecos is just too big for LPC2106.
However, I'm pretty amazed of how easy is in ecos to load a module:
just compile a .c file which contains your logic and upload the .a
obtained to the device. There, that file can be saved on an SD card
and loaded from there. EASY!
Thanks.
George.
RTOS recommendation for LPC2106
Started by ●June 25, 2006
Reply by ●June 27, 20062006-06-27
George,
I made a similar trade-off a year ago (but with more RTOSes on my
list, notably uC/OS). Actually, eCos dropped from my list fairly
quickly, because it required more RAM than I could spare. I am using
an LPC2138, with no external memory.
Both FreeRTOS and uC/OS are good; both are bare-bones RTOSes. uC/OS
provides "priority inheritance" and FreeRTOS does not. This is not
that important; priority inversion (the problem that "priority
inheritance" fixes) can mostly be avoided by careful analysis of tasks
and shared objects.
If firmware needs to be updatable, you can implement a kind of
bootloader that re-programs Flash ROM. If the changes are likely to be
at "known local spots", it might be an option to build some scriptable
system. Forth is known for compact, quick code with a very little
interpreter. In my project (on the LPC2138), we used "Pawn" scripting
because the abstract machine for it has a small memory footprint (and
it is pretty quick too). But then, scripting was a major feature of
our product, not an add-on for maintenance (although we have on
occasion used it as such).
Kind regards,
Thiadmer
I made a similar trade-off a year ago (but with more RTOSes on my
list, notably uC/OS). Actually, eCos dropped from my list fairly
quickly, because it required more RAM than I could spare. I am using
an LPC2138, with no external memory.
Both FreeRTOS and uC/OS are good; both are bare-bones RTOSes. uC/OS
provides "priority inheritance" and FreeRTOS does not. This is not
that important; priority inversion (the problem that "priority
inheritance" fixes) can mostly be avoided by careful analysis of tasks
and shared objects.
If firmware needs to be updatable, you can implement a kind of
bootloader that re-programs Flash ROM. If the changes are likely to be
at "known local spots", it might be an option to build some scriptable
system. Forth is known for compact, quick code with a very little
interpreter. In my project (on the LPC2138), we used "Pawn" scripting
because the abstract machine for it has a small memory footprint (and
it is pretty quick too). But then, scripting was a major feature of
our product, not an add-on for maintenance (although we have on
occasion used it as such).
Kind regards,
Thiadmer