Rtems with Philips LPC2106 ???

[Thomas Schrein]

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
>>>>
>>>
>>>
>>
>
>
>
>