Rtems with Philips LPC2106 ???
Thomas Schrein
thomas at schrein.com
Wed Jan 28 08:28:57 UTC 2004
Joel,
I've annother, may be stupid, question: What's the most important
difference beween ecos and rtems. From my feeling I think I will like to
use rtems in my future projects. But I have no real argument to do so.
Can you give me a short hint ?
Thanx
Thomas
Joel Sherrill wrote:
> Thomas Schrein wrote:
>
>> First of all thanx to list for your quick answers to the questions of
>> a newbie like me :-)
>>
>> As a result of this discussion it seems to me to be worth to do more
>> investigations on that part and to play around with rtems and the
>> LPC21xx.
>> Philips has anncounced a version with integrated ethernet and a
>> version with integrated CAN. But how to use these network interfaces
>> with such limited memory ? Does rtems has a too large footprint
>> compare with systems like ecos etc. ?
>>
> All of the link in RTOS's are going to have the same "feature" -- the
> more functions you use, the
> more code space required. The TCP/IP stack included with RTEMS is a
> port of the FreeBSD
> stack so is high functionality but a basic networking application
> tends to be in the 200-250K
> of code space depending on the CPU and servers (httpd, ftpd, telnetd,
> etc.) being used.
>
> A user has a port of LWIP (is that the name) which is a light weight
> TCP/IP stack which
> would be more appropriate for lower memory systems. You will just end
> up with
> possibly only the functionality you ABSOLUTELY need for Ethernet or CAN.
>
> If ecos also newlib, then all my statements about the C library still
> apply. When you use
> certain functions like printf, they assume a fair amount of
> infrastructure behind them
> in the C library and you will get more code space. RTEMS has a simple
> printk which
> is tiny in comparison by only for debug IO.
>
> So code space is a variable which is directly dependent upon the
> amount of functionality
> you require.
>
> FWIW if you find that something you did not actually use or need is
> pulled into an RTEMS
> application because of an unexpected/unintended reference, it is
> something that we try to
> fix. FOr example, a BSP using printf() is generally considered bad
> form since it places
> a minimum burden on all applications on that board.
>
>> It would be quite nice to use only one OS, like rtems, in control
>> applications using in a distributed network enviroment consisting of
>> controllers of different sizes: rtems working in a sensor as well as
>> in a big management or control systems.
>>
>> I am a novice at rtems. How to do the next steps ?
>> My ideas is to buy an ARM7 eva board like the EB40 form ATMEL to have
>> a stable test basis and to buy a LPC eva board. From that EB40 basis
>> it should be not so hard to port rtems to the LPC and then figure
>> out the opportunities.
>
>
> That would be a good next step.
>
>>
>> Does anyone has experience with the EB40 ? Or can you recommend me an
>> other one ?
>> Can I get further advices from the list if I am in trouble ?
>
>
> Yes. There is also the Cogent EDP7312 ARM board which has a BSP in
> the tree.
>
>> Where can I fiind the propper info redarding the use of RTEMS with
>> ARM7 to start ? I haven't found much ARM7 stuff on the server, esp.
>> in the BSP section.
>
>
> The 4.6.0pre5 has all the current ARM support. Just ask questions.
>
>>
>> Thomas
>>
>> Joel Sherrill wrote:
>>
>>> Scott Newell wrote:
>>>
>>>> At 11:16 AM 1/16/2004 , Joel Sherrill wrote:
>>>>
>>>>> That may be shrunk more with attention to the RTEMS
>>>>> configuration and what services you use. The ticker test
>>>>> has 3 tasks, uses printf (often 20-30K baggage itself),
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Would using iprintf() help?
>>>
>>>
>>>
>>>
>>> Yes. And I think that in later RTEMS versions, the
>>> tests actually (by macro magic) have switched to
>>> using iprintf.
>>>
>>> Better would be to avoid using printf unless you
>>> really need it. For debug IO to a serial console,
>>> printk() is much smaller.
>>>
>>>> newell
>>>>
>>>
>>>
>>
>
>
>
>
More information about the users
mailing list