Bringing up eCos on a new platform

We have a project that demands IP connectivity and little bit of simple
database stuff that will take about a megabyte of memory.  For this project,
something like eCos seems like a logical solution as it seems to have all
the functionality without having the footprint and MMU requirements that
Linux has.  However, I've never used it before so need a little help in
evaluating it against other solutions.

Approximately how much time should I estimate for a single developer to get
eCos up and running on a new board (using an existing core such as Arm 7,
Arm 9 or Coldfire) with a couple of MACs to the point of getting TCP/IP
running and communicating over Ethernet.  Development platform will
certainly be Windows and probably be Cygwin.

Any comments on gotchas that you've stumbled on in this sort of development
will also be greatly appreciated.

--
Alf Katz
alfkatz@remove.the.obvious.ieee.org


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.601 / Virus Database: 382 - Release Date: 29/02/2004

On 2004-03-12, Unbeliever <alfkatz@remove.the.bleedin.obvious.ieee.org> wrote:

> Approximately how much time should I estimate for a single
> developer to get eCos up and running on a new board (using an
> existing core such as Arm 7, Arm 9 or Coldfire) with a couple
> of MACs to the point of getting TCP/IP running and
> communicating over Ethernet.  Development platform will
> certainly be Windows and probably be Cygwin.

Firstly, Windows/Cygwin will slow you down compared to using a
Linux host.

 * Are you using Ethernet controllers for which drivers exist?

 * Are you using a part for which drivers/platform support
   exists? (e.g. code to handle timers, interrupt controller,
   memory controller, serial ports, etc.)

If the answers to both no, and you've got to write the entire
set of peripheral handlers and the Ethernet driver, then I'd
plan on a couple months.
    
> Any comments on gotchas that you've stumbled on in this sort
> of development will also be greatly appreciated.

A good JTAG interface that works with GDB will help tons
(especially in troubleshooting the board).  The BDI2000 is
great since it talks directly to GDB using the normal "remote"
protocol.  EPI Jeeni will talk directly to GDB also, but it's
only ARM7.  Most of the others require protocol converters that
are a PITA to set up and only run on certain platforms.

Oh, and you should join the eCos mailing list. There's tons of
good help there.

-- 
Grant Edwards                   grante             Yow!  I've read SEVEN
                                  at               MILLION books!!
                               visi.com            

Thanks Grant,

> Firstly, Windows/Cygwin will slow you down compared to using a
> Linux host.
Real world stuff creeps in here.  In the absence of systems and people, I'd
probably agree with you.

>  * Are you using Ethernet controllers for which drivers exist?
>
Maybe, maybe not.  Front runners at this stage appear to be an ARM9 with
external MACs (the answer for this would almost certainly be yes) or a
Coldfire with integral MACs (I don't think these are supported).

>  * Are you using a part for which drivers/platform support
>    exists? (e.g. code to handle timers, interrupt controller,
>    memory controller, serial ports, etc.)
> If the answers to both no, and you've got to write the entire
> set of peripheral handlers and the Ethernet driver, then I'd
> plan on a couple months.

That's exactly the reason I'm treating the processor choice and RTOS choice
as single decision.  At present eCos with ColdFire, one of a couple of ARMs
and a PowerPC seem to be the front runners.  What we'd ideally like is drop
in solution with an eCos (or ucLinux or any other small footprint rtos +
TCP/IP stack + some peripheral drivers).  eCos is probably a bit of overkill
for us, but its reuseability in future projects may make it worthwhile.

Small footprint is key, we're looking at less than a meg for RTOS + stack +
application.   Even that seems excessive to someone used to dealing with 8
bit micros wit a few k whose written a UDP/IP stack and drivers in a 16k
AVR, but we're looking for a *robust* and reasonably complete TCP/IP
solution.


> A good JTAG interface that works with GDB will help tons
> (especially in troubleshooting the board).  The BDI2000 is
> great since it talks directly to GDB using the normal "remote"
> protocol.  EPI Jeeni will talk directly to GDB also, but it's
> only ARM7.  Most of the others require protocol converters that
> are a PITA to set up and only run on certain platforms.
The BDI2000 looks like a good thing, will contact the Aussie agent (a
notorious rogue) and see what his price is (shudder).

> Oh, and you should join the eCos mailing list. There's tons of
> good help there.
>
I'll have a look myself and recommend that to the guy tasked with actually
doing the work.

regards,
Alf Katz
alfkatz@remove.the.obvious.ieee.org


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.601 / Virus Database: 382 - Release Date: 29/02/2004

On 2004-03-13, Unbeliever <alfkatz@remove.the.bleedin.obvious.ieee.org> wrote:

>> Firstly, Windows/Cygwin will slow you down compared to using a
>> Linux host.
>
> Real world stuff creeps in here.  In the absence of systems
> and people, I'd probably agree with you.

I've built eCos and associated apps on both Cygwin and Linux,
and both work fine. But, Cygwin seems more fragile, and it
always felt like I was constantly battling odd problems --
particularly with gdb and serial ports.  Builds take 2-4 times
as long as well, but that's probably not a big deal unless
you're building gcc et al on a P166 like I was.

>>  * Are you using Ethernet controllers for which drivers exist?
>>
> Maybe, maybe not.  Front runners at this stage appear to be an ARM9 with
> external MACs (the answer for this would almost certainly be yes) or a
> Coldfire with integral MACs (I don't think these are supported).

The API is well documented and there are plenty of examples to
look at, so eCos Ethernet drivers aren't particularly hard to
write if you know how the Ethernet controller works (or if
you've got good documentation and/or sample code).  Figuring
out how an Ethernet controller works based on mis-translated
docs and trial-and-error can sure eat up a lot of time...

>> If the answers to both no, and you've got to write the entire
>> set of peripheral handlers and the Ethernet driver, then I'd
>> plan on a couple months.
>
> That's exactly the reason I'm treating the processor choice
> and RTOS choice as single decision.

What a refreshingly sensible approach.  You'd have been sacked for
over-use of common-sense at some places.

> At present eCos with ColdFire, one of a couple of ARMs and a
> PowerPC seem to be the front runners.  What we'd ideally like
> is drop in solution with an eCos (or ucLinux or any other
> small footprint rtos + TCP/IP stack + some peripheral
> drivers).  eCos is probably a bit of overkill for us, but its
> reuseability in future projects may make it worthwhile.
>
> Small footprint is key, we're looking at less than a meg for
> RTOS + stack + application.

That should be doable -- depending on the application.  People
(including myself) have posted detailed size numbers in the
past. 

IIRC, in my last ARM7 project the kernel was about 60K and the
networks stack was in the 100K-126K (code).  Expect to spend
about 64KB on network buffers per concurrent TCP/IP connection.

My last big project had a pretty fancy web server (including a
JavaScript interpreter), SNMP support, DHCP client support, and
came in at around 1MB of code (including maybe 200K of actual
application-specific stuff).

> Even that seems excessive to someone used to dealing with 8
> bit micros wit a few k whose written a UDP/IP stack and
> drivers in a 16k AVR, but we're looking for a *robust* and
> reasonably complete TCP/IP solution.

I know what you mean.  I'm now back on a project with 128K of
ROM and 32K of RAM.  Still big compared to a lot of projects,
but a bit tight compared to the ARM-based eCos stuff I worked
on previously.

> The BDI2000 looks like a good thing, will contact the Aussie
> agent (a notorious rogue) and see what his price is (shudder).

Brace yourself, they're not cheap.  Unless you're starting with
known good hardware and a working ROM-monitor or GDB-stubs, the
BDI2000 is definitely worth it.  One of the handy features is
you can just telnet to it and do basic hardware debugging stuff
(even burning flash).

The downloadable eCos docs are excellent, and there is also an
eCos book by Anthony Massa that came out last year that's
bundled with a CD. The CD is now a bit out of date for
production use, but the basic info is still good.

http://www.amazon.com/exec/obidos/tg/detail/-/0130354732/qid=1079155016/sr=8-5/ref=sr_8_xs_ap_i5_xgl14/103-8522077-3679016?v=glance&s=books&n=507846


-- 
Grant Edwards                   grante             Yow!  I always have fun
                                  at               because I'm out of my
                               visi.com            mind!!!

Unbeliever wrote:
> Thanks Grant,
> 
> 
>>Firstly, Windows/Cygwin will slow you down compared to using a
>>Linux host.
> 
> Real world stuff creeps in here.  In the absence of systems and people, I'd
> probably agree with you.

I am not sure I understand your point here but making a dual boot 
machine is not that hard (I have a quad boot actualy :-) ). And if 
development people cannot adapt themselves to a different development 
environment, then I'd start wondering about the convenience to replace 
them. :-)

Cheers!

Elder.

> >>Firstly, Windows/Cygwin will slow you down compared to using a
> >>Linux host.
> >
> > Real world stuff creeps in here.  In the absence of systems and people,
I'd
> > probably agree with you.
>
> I am not sure I understand your point here but making a dual boot
> machine is not that hard (I have a quad boot actualy :-) ). And if
> development people cannot adapt themselves to a different development
> environment, then I'd start wondering about the convenience to replace
> them. :-)
>

While this was a very minor part of the post, setting out some relevant
constraints, and I don't want this to degenerate into the usual boring Linux
vs. Windows thing (I use both, and  have a dual boot box and a Linux only
machine on my home network), I'll go a little further.  When I say systems,
of course I mean business systems used by the rest of the company as well as
the R&D dept.  Such things as e-mail systems for meetings, faxes and even
telephone calls, revision management systems, change management systems,
project and team management systems, OO analaysis and design systems,
databases of various sorts, word processing systems.  And people are not
just developers, but include IT people who maintain the networks, servers
and PC's that we all use.

Most of us by now realize that there are alternatives to most of these
systems in the Linux world that we could change to, that we could hire new
developers and IT people.  All this costs time and money, these are what I
refer to as "real world stuff".

I don't see much point in going any further down this thread.

Cheers,
Alf
alfkatz@remove.the.obvious.ieee.org


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.601 / Virus Database: 382 - Release Date: 29/02/2004

> The API is well documented and there are plenty of examples to
> look at, so eCos Ethernet drivers aren't particularly hard to
> write if you know how the Ethernet controller works (or if
> you've got good documentation and/or sample code).  Figuring
> out how an Ethernet controller works based on mis-translated
> docs and trial-and-error can sure eat up a lot of time...
The RTL8019 docs were a real cow.

> > That's exactly the reason I'm treating the processor choice
> > and RTOS choice as single decision.
>
> What a refreshingly sensible approach.  You'd have been sacked for
> over-use of common-sense at some places.
I have been at one place!

> That should be doable -- depending on the application.  People
> (including myself) have posted detailed size numbers in the
> past.
>
> IIRC, in my last ARM7 project the kernel was about 60K and the
> networks stack was in the 100K-126K (code).  Expect to spend
> about 64KB on network buffers per concurrent TCP/IP connection.
>
That's useful size info, thanks! As the app is pretty small, we should have
no trouble fitting it into a reasonable size.  I'll hunt throught the
archives for some other points of reference.

> The downloadable eCos docs are excellent, and there is also an
> eCos book by Anthony Massa that came out last year that's
> bundled with a CD. The CD is now a bit out of date for
> production use, but the basic info is still good.
>
Books are cheap and good books can repay their purchase price hundreds of
times over in a project.  I've ordered it.  Now I'll just have to wait till
it floats down the Amazon international delivery chain.

Thanks again for your input,
Alf,
alfkatz@remove.the.obvious.ieee.org


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.601 / Virus Database: 382 - Release Date: 29/02/2004

On 2004-03-13, Unbeliever <alfkatz@remove.the.bleedin.obvious.ieee.org> wrote:

> When I say systems, of course I mean business systems used by
> the rest of the company as well as the R&D dept.  Such things
> as e-mail systems for meetings, faxes and even telephone
> calls, revision management systems, change management systems,
> project and team management systems, OO analaysis and design
> systems, databases of various sorts, word processing systems.

If you're required to use the same host for developmeand as
those other things, then I guess you've got no choice.  At my
last job we were required to use Windows for that sort of
stuff, but we still did all of our actual eCos development work
under Linux.  Of course it required that the company invest in
a second computer for people, but computers are dirt cheap --
especially considering a P166 will work just fine for code
development.

-- 
Grant Edwards                   grante             Yow!  .. I'm IMAGINING a
                                  at               sensuous GIRAFFE, CAVORTING
                               visi.com            in the BACK ROOM of a
                                                   KOSHER DELI --

On 13 Mar 2004 22:20:12 GMT, Grant Edwards <grante@visi.com> wrote:

>On 2004-03-13, Unbeliever <alfkatz@remove.the.bleedin.obvious.ieee.org> wrote:
>
>> When I say systems, of course I mean business systems used by
>> the rest of the company as well as the R&D dept.  Such things
>> as e-mail systems for meetings, faxes and even telephone
>> calls, revision management systems, change management systems,
>> project and team management systems, OO analaysis and design
>> systems, databases of various sorts, word processing systems.
>
>If you're required to use the same host for developmeand as
>those other things, then I guess you've got no choice.  At my
>last job we were required to use Windows for that sort of
>stuff, but we still did all of our actual eCos development work
>under Linux.  Of course it required that the company invest in
>a second computer for people, but computers are dirt cheap --
>especially considering a P166 will work just fine for code
>development.

Especially if one invest in a KVM. Keep the same monitor, keyboard and
mouse, and with a simple button press on the KVM or a sequence of
keystrokes on the keyboard one can switch between Linux and Windows.


Regards
  Anton Erasmus

On 2004-03-16, Anton Erasmus <junk@junk.net> wrote:

>>> When I say systems, of course I mean business systems used by
>>> the rest of the company as well as the R&D dept.  Such things
>>> as e-mail systems for meetings, faxes and even telephone
>>> calls, revision management systems, change management systems,
>>> project and team management systems, OO analaysis and design
>>> systems, databases of various sorts, word processing systems.
>>
>>If you're required to use the same host for developmeand as
>>those other things, then I guess you've got no choice.  At my
>>last job we were required to use Windows for that sort of
>>stuff, but we still did all of our actual eCos development work
>>under Linux.  Of course it required that the company invest in
>>a second computer for people, but computers are dirt cheap --
>>especially considering a P166 will work just fine for code
>>development.
>
> Especially if one invest in a KVM. Keep the same monitor, keyboard and
> mouse, and with a simple button press on the KVM or a sequence of
> keystrokes on the keyboard one can switch between Linux and Windows.

I used VNC and a headless Windows machie for a long time.  Then
BOFH split the "office" network from the "engineering" network
and I couldn't VNC the two machines together anymore.  Then I
bought a KVM.

-- 
Grant Edwards                   grante             Yow!  NOW do I get to blow
                                  at               out the CANLDES??
                               visi.com