Forums

Bringing up eCos on a new platform

Started by Unbeliever March 12, 2004
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