RE: [ECOS] How do you like eCos

RE: [ECOS] How do you like eCos

[Fabrice Gautier]

> -----Original Message-----
> From: Lewin A.R.W. Edwards [ mailto:larwe@larwe.com ]
> Subject: Re: [ECOS] How do you like eCos
> 
> 
> >While you are waiting for your hardware i suggest you play with the
> >synthetic target and do the tutorial in the documentation. Thats the
> 
> Which isn't supported under Win32. I guess I can dig out 
> another PC and 
> install Linux again. *sigh*
> 
> >lot. Its much faster to go around the edit/compile/run/crash loop on
> >the synthetic target.
> 
> It's hard for us to get our inputs into an emulator. We need 
> to connect to 
> external hardware. Writing interfaces and abstraction layers 
> would probably 
> increase the overall project size by 50% if not more.

Then, if you're external hardware can be connected to a PC, I suggest you
use your spare PC as a test platform and install eCos instead of linux on
it.

That's what I did here. 

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

RE: [ECOS] How do you like eCos

[Lewin A.R.W. Edwards]

> > It's hard for us to get our inputs into an emulator. We need
> > to connect to
> > external hardware. Writing interfaces and abstraction layers
>
>Then, if you're external hardware can be connected to a PC, I suggest you
>use your spare PC as a test platform and install eCos instead of linux on

Not easily. Building the hardware and software glue would be at least as 
much work as getting the real system working - and just as much debugging 
effort, most of which would be wasted. This stuff really needs to be done 
in vivo.


Lewin A.R.W. Edwards (Embedded Engineer)
Got any Commodore 16 or VIC-20 hardware, cartridges, tapes?
Visit http://www.larwe.com/vintage/
================================================
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] How do you like eCos

[Robin Farine]

Lewin,

Please either switch definitively to Visual XYZ++ development or if you
really want to use free tools and OSes, first try to think positive, and
then accept to have to read source code, to understand how the damned
things work (or, more often, why they don't), and even to fix bugs!

After that, you'll certainly feel a lot better and, for instance, you
will propose some improvements to the documentation instead of
complaining.

I know, Window$ users are not trained in understanding (because they do
not have any documentation or source code perhaps), but it's never too
late to start!

Robin

Re: [ECOS] How do you like eCos

[Lewin A.R.W. Edwards]

Hello Robin,

>really want to use free tools and OSes, first try to think positive, and
>then accept to have to read source code, to understand how the damned
>things work (or, more often, why they don't), and even to fix bugs!

What you are saying here boils down to "it is free, therefore you must 
expect the quality to be below par", and I do not accept this. And really 
the only change I am proposing is very sensible: Whoever maintains a set of 
instructions for installing a set of tools should keep available for 
download a snapshot of the exact versions that the instructions reference. 
Yes, they will be out of date at the end of the week. But at least a person 
can get started. You can't learn how the tools work if you can't build them.

I was thinking very positive at the start, but in the face of zero results 
it is difficult to retain this state of mind.

The version of gcc and libc I'm using in our current product was compiled 
in 1996. It is ancient, but I see no need for upgrades. Iff (not a typo) we 
were having some problem attributable to compiler age then I would consider 
battling the make process to try to get an update built. With the current 
system, I don't get a choice.

>I know, Window$ users are not trained in understanding (because they do

That is an unfair comment. Just because I have written for Windows does not 
mean I am a new user unwrapping his first PC and installing AOL. Actually I 
got into Windows quite late, and I haven't written a line of code for the 
OS in more than  a year and a half (and I don't miss it...) In fact it is 
refreshing not to be a slave to Microsoft and undocumented APIs and 
concealed OS bugs. We are currently getting into Universal Plug'n'Pray and 
I am having feelings of deja vu, seeing the way MS is trying to leverage 
all its proprietary technologies into our project. It will be a cold day in 
hell before we put WinCE into our devices, though.

As for wanting to run devtools inside Windows, the simple fact is that most 
commercial apps are for Windows. So it is a significant disruption to my 
life to have to run two OSs on two PCs. Running Linux I can't just switch 
over to the circuit diagram or our intra-office email system or MS-Word to 
update a spec document. It is an appreciable drain on productivity.

I want to boot my board and debug my own code, not someone else's. I don't 
have the ability to tell five junior programmers "Go work out how to build 
the tools, you've got a month to do so".

I can't believe that my viewpoint is unique.


Lewin A.R.W. Edwards (Embedded Engineer)
Got any Commodore 16 or VIC-20 hardware, cartridges, tapes?
Visit http://www.larwe.com/vintage/
================================================
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] How do you like eCos

[Andrew Lunn]

> As for wanting to run devtools inside Windows, the simple fact is that most 
> commercial apps are for Windows. So it is a significant disruption to my 
> life to have to run two OSs on two PCs. Running Linux I can't just switch 
> over to the circuit diagram or our intra-office email system or MS-Word to 
> update a spec document. It is an appreciable drain on productivity.

The nice thing about Unix is that its multi user and knows about
remote displays. All the people here have NT workstations on the
desk. We have one Linux box in a machine room which we all telnet into
and do development work on. It has no problem handling 7 or more
simultanious users compiler and debugging. So we get the best of both
worlds. Linux to do the serious work on and NT for Word. Turn your
spare PC into a Linux server for all your engineers to use.

        Andrew

PS don't try this with NTs telnet client, its too broken.

Re: [ECOS] How do you like eCos

[Lewin A.R.W. Edwards]

> > commercial apps are for Windows. So it is a significant disruption to my
> > life to have to run two OSs on two PCs. Running Linux I can't just switch
>
>desk. We have one Linux box in a machine room which we all telnet into
>and do development work on. It has no problem handling 7 or more
>simultanious users compiler and debugging. So we get the best of both

Hmm. Have to admit I didn't think of this, thanks for that suggestion. I 
suspect I will end up going with swappable or partitioned hard drives, 
though, as it's the line of least resistance (however annoying). I don't 
have time to climb additional learning curves, unfortunately.

Don't you just hate the way building the infrastructure to get a 
development system working requires more effort than getting the actual end 
object code right?


Lewin A.R.W. Edwards (Embedded Engineer)
Got any Commodore 16 or VIC-20 hardware, cartridges, tapes?
Visit http://www.larwe.com/vintage/
================================================
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] How do you like eCos

[Matthew H. Gerlach]

Many folks in our group, run Windows 2000 and use Vmware to run a complete Linux
on the same machine at the same time for embedded development.   The arm-elf
compiles under a Vmware Linux are neglibly slower that arm-elf compiles under
straight Linux.

Matthew



"Lewin A.R.W. Edwards" wrote:

> > > commercial apps are for Windows. So it is a significant disruption to my
> > > life to have to run two OSs on two PCs. Running Linux I can't just switch
> >
> >desk. We have one Linux box in a machine room which we all telnet into
> >and do development work on. It has no problem handling 7 or more
> >simultanious users compiler and debugging. So we get the best of both
>
> Hmm. Have to admit I didn't think of this, thanks for that suggestion. I
> suspect I will end up going with swappable or partitioned hard drives,
> though, as it's the line of least resistance (however annoying). I don't
> have time to climb additional learning curves, unfortunately.
>
> Don't you just hate the way building the infrastructure to get a
> development system working requires more effort than getting the actual end
> object code right?
>
> Lewin A.R.W. Edwards (Embedded Engineer)
> Got any Commodore 16 or VIC-20 hardware, cartridges, tapes?
> Visit http://www.larwe.com/vintage/
> ================================================
> Work: http://www.digi-frame.com/
> Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] How do you like eCos

[Robin Farine]

Ho Lewin,

"Lewin A.R.W. Edwards" wrote:
> <snip>
> What you are saying here boils down to "it is free, therefore you must
> expect the quality to be below par", and I do not accept this. And really
> the only change I am proposing is very sensible: Whoever maintains a set of
> instructions for installing a set of tools should keep available for
> download a snapshot of the exact versions that the instructions reference.
> Yes, they will be out of date at the end of the week. But at least a person
> can get started. You can't learn how the tools work if you can't build them.
> 
> I was thinking very positive at the start, but in the face of zero results
> it is difficult to retain this state of mind.
> <snip>

I meant that with eCos we have two main choices: either we pay a few
hundreds of K$ for special support from Red Hat and then we get a
private channel to increase the pressure on eCos developers/maintainers,
or we do not pay anything but we benefit from the eCos mailing-list
which provides a means of reporting specific problems or discussing
about potential improvements. This second choice compares with any other
free-software project, something like:

	"This program is distributed in the hope that it will be useful, but
WITHOUT ANY 		WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A 		PARTICULAR PURPOSE."

It also implies that we shall make a personal effort of collaboration to
improve it rather than asking others to do the job for us. Note that I
do *not* mean that that's what *you*'re expecting, but I have seen many,
many times things like:

	"I have downloaded your software XYZ but when I tried to install it, I
got an error 		message saying blah blah blah. PLEASE HELP ME!"

but naturally no indication of version, date, OS, tools, FTP transfer
mode, cygwin mount type, ... and sometimes it makes me loose a bit of
self-control.

I apologize if my previous posting hurted you and thanks for answering.

Robin

Re: [ECOS] How do you like eCos

[Andrew Lunn]

On 29-Nov-2000 Andrew Lunn wrote:
> If you are having realy problems mail to the list. One thing where
> eCos differece from VxWorks and Nucleaus etc, is there is a net
> community, a bizarre is in opertation and people are working on the
> ego.
> 

Upps. Me Dyslexia strikes again. I meant to say

..there is a net community, a bazaar is in operation and people are
working on their ego.

For those that are totaly confused i suggest you read 
http://www.openresources.com/documents/cathedral-bazaar/index.html

        Andrew 

[ECOS] How do you like eCos

[anarchy]

Hi All:

Our company is trying to find a "serious kernel" to get rid of pSOS and
VxWorks. I found eCos very charming but have no experience using it. Is
there any company using eCos longer than one year and thinking it's
good(or very good or bad). I need to hear some serious comment about
using eCos by senior users. Please give me any advice or suggestions.
Thanks a lot.

Sincerely

Jeffrey Wu

Re: [ECOS] How do you like eCos

[Grant Edwards]

On Tue, Nov 28, 2000 at 10:49:51PM +0800, anarchy wrote:

> Our company is trying to find a "serious kernel" to get rid of pSOS and
> VxWorks. I found eCos very charming but have no experience using it. Is
> there any company using eCos longer than one year and thinking it's
> good(or very good or bad). I need to hear some serious comment about
> using eCos by senior users. Please give me any advice or suggestions.
> Thanks a lot.

We've been using it for about a year now (we've been shipping a
product that uses eCos for about 4 months).  I've got no
complaints.  The level of support provided by the mailing list
is _far_ better than support my colleagues have gotten for
pSOS.

My experience is that development under Linux/Unix involves
fewer hassels than under Win32 (Cygwin/toolchain issues are
solvable but ever-present).

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] How do you like eCos

[Lewin A.R.W. Edwards]

Hi Grant,

>We've been using it for about a year now (we've been shipping a
>product that uses eCos for about 4 months).  I've got no
>complaints.  The level of support provided by the mailing list
>is _far_ better than support my colleagues have gotten for
>pSOS.

I'm curious: What specific platform do you use for development, and what is 
your target CPU/architecture?

The reason I ask this is because I have one very major gripe with the free 
open-source level of support from Red Hat, and that is that there is no 
version unification, no known point from which to start, and every time one 
hits a problem one has to start debugging it from the ground up.

I'm wondering if I have experienced my usual Murphyesque ill luck and 
chosen the one maverick platform (pun intended) in the "supported 
platforms" list, but my experience with eCos and its toolchain thus far is 
that almost no component has installed/configured/compiled per the 
installation instructions, and a big part of the problem is that instead of 
providing specific snapshots of known-working versions, the install 
instructions refer to nonexistent historical versions.

Point taken about Linux host being less problematic, but I tried both Linux 
and Cygwin and had only slightly different results. Also, I don't know 
about other embedded engineers, but it is a significant annoyance to me to 
have to use anything other than Win9x for development, because most of the 
special-purpose hardware we use is DOS-only. It's quite painful to have to 
use two PCs instead of one.

One certainly couldn't describe eCOS as a fast track to anything; there are 
a dozen different steep learning curves to be climbed before you can even 
build the OS, much less try to link your own program.

Lewin A.R.W. Edwards (Embedded Engineer)
Got any Commodore 16 or VIC-20 hardware, cartridges, tapes?
Visit http://www.larwe.com/vintage/
================================================
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] How do you like eCos

[Stephen Polkowski]

Hi,

	I've been evaluating eCos for Intel systems for the last 2
months and I'm impressed by it.  I've also been watching this
forum.  However, one thing that I've noticed is that getting
code changes into the eCos source may depend on the platform
you're developing.

	For instance,  Fabrice Gautier has been very active in
publishing changes for the Intel platform.  Three or four
months ago he wrote a patch for the 386 PCI support.  He also
contributed several other changes for the 386.  None of these
changes have been promoted to CVS source tree.  Why?$$

	Before you decide to use eCos, make sure your platform is
actively supported.  Even if its on list, don't assume your
free coding efforts will be put into the source tree.
		   

"Lewin A.R.W. Edwards" wrote:
> 
> Hi Grant,
> 
> >We've been using it for about a year now (we've been shipping a
> >product that uses eCos for about 4 months).  I've got no
> >complaints.  The level of support provided by the mailing list
> >is _far_ better than support my colleagues have gotten for
> >pSOS.
> 
> I'm curious: What specific platform do you use for development, and what is
> your target CPU/architecture?
> 
> The reason I ask this is because I have one very major gripe with the free
> open-source level of support from Red Hat, and that is that there is no
> version unification, no known point from which to start, and every time one
> hits a problem one has to start debugging it from the ground up.
> 
> I'm wondering if I have experienced my usual Murphyesque ill luck and
> chosen the one maverick platform (pun intended) in the "supported
> platforms" list, but my experience with eCos and its toolchain thus far is
> that almost no component has installed/configured/compiled per the
> installation instructions, and a big part of the problem is that instead of
> providing specific snapshots of known-working versions, the install
> instructions refer to nonexistent historical versions.
> 
> Point taken about Linux host being less problematic, but I tried both Linux
> and Cygwin and had only slightly different results. Also, I don't know
> about other embedded engineers, but it is a significant annoyance to me to
> have to use anything other than Win9x for development, because most of the
> special-purpose hardware we use is DOS-only. It's quite painful to have to
> use two PCs instead of one.
> 
> One certainly couldn't describe eCOS as a fast track to anything; there are
> a dozen different steep learning curves to be climbed before you can even
> build the OS, much less try to link your own program.
> 
> Lewin A.R.W. Edwards (Embedded Engineer)
> Got any Commodore 16 or VIC-20 hardware, cartridges, tapes?
> Visit http://www.larwe.com/vintage/
> ================================================
> Work: http://www.digi-frame.com/
> Personal: http://www.zws.com/ and http://www.larwe.com/

-- 
Stephen Polkowski
Centaur Technology  
Austin, TX
(512) 418-5730

Re: [ECOS] How do you like eCos

[Jonathan Larmour]

Stephen Polkowski wrote:
> 
>         For instance,  Fabrice Gautier has been very active in
> publishing changes for the Intel platform.  Three or four
> months ago he wrote a patch for the 386 PCI support.  He also
> contributed several other changes for the 386.  None of these
> changes have been promoted to CVS source tree.  Why?$$

Because large changes like that need a copyright assignment and although he
has sent one, it still has not been processed by Red Hat's legal
department. The reason it has not been processed is our responsibility,
admittedly. We've already tried to chase it up here a few times. We'll try
again.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] How do you like eCos

[Stephen Polkowski]

Jifl,

	I apologize for my rash note.  I was unaware that the lawyers
were mucking up the progress.  So, in general, all contributed
code needs to get the OK from the law staff?  Now I truly have
a reason to hate lawyers! :-}

Steve	

Jonathan Larmour wrote:
> 
> Stephen Polkowski wrote:
> >
> >         For instance,  Fabrice Gautier has been very active in
> > publishing changes for the Intel platform.  Three or four
> > months ago he wrote a patch for the 386 PCI support.  He also
> > contributed several other changes for the 386.  None of these
> > changes have been promoted to CVS source tree.  Why?$$
> 
> Because large changes like that need a copyright assignment and although he
> has sent one, it still has not been processed by Red Hat's legal
> department. The reason it has not been processed is our responsibility,
> admittedly. We've already tried to chase it up here a few times. We'll try
> again.
> 
> Jifl
> --
> Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
> "Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

-- 
Stephen Polkowski
Centaur Technology  
Austin, TX
(512) 418-5730

Re: [ECOS] How do you like eCos

[Jonathan Larmour]

Stephen Polkowski wrote:
> 
>         I apologize for my rash note.  I was unaware that the lawyers
> were mucking up the progress.  So, in general, all contributed
> code needs to get the OK from the law staff?  Now I truly have
> a reason to hate lawyers! :-}

This link:
http://sources.redhat.com/ecos/faq.html#contrib_assign gives the reasoning
behind it. The FSF take the same approach.

It doesn't apply to "trivial" patches though, although the exact boundaries
are somewhat subjective.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] How do you like eCos

[Andrew Lunn]

> It doesn't apply to "trivial" patches though, although the exact boundaries
> are somewhat subjective.

Thats definatly true. Look at the ChangeLog in the anoncvs. My name
pops up in various places and i've never had to sign a legal document.

        Andrew

Re: [ECOS] How do you like eCos

[Grant Edwards]

On Tue, Nov 28, 2000 at 12:44:02PM -0500, Lewin A.R.W. Edwards wrote:

> >We've been using it for about a year now (we've been shipping a
> >product that uses eCos for about 4 months).  I've got no
> >complaints.  The level of support provided by the mailing list
> >is _far_ better than support my colleagues have gotten for
> >pSOS.
> 
> I'm curious: What specific platform do you use for development,

Linux (Intel).

> and what is your target CPU/architecture?

ARM7TDMI (custom board using a Samsung KS32C5000).

> The reason I ask this is because I have one very major gripe
> with the free open-source level of support from Red Hat, and
> that is that there is no version unification, no known point
> from which to start,

I'm not sure what you mean.  There are "official" releases: the
current one is 1.3.1, and you also have access to CVS sources.

Commercial products only provide the official releases.

> and every time one hits a problem one has to start debugging it
> from the ground up.

Are you saying that you would prefer that official releases
came out more often?

> I'm wondering if I have experienced my usual Murphyesque ill
> luck and chosen the one maverick platform (pun intended) in the
> "supported platforms" list,

Don't know.  I've never used a supported platform.

> but my experience with eCos and its toolchain thus far is that
> almost no component has installed/configured/compiled per the
> installation instructions, and a big part of the problem is
> that instead of providing specific snapshots of known-working
> versions, the install instructions refer to nonexistent
> historical versions.

I guess I didn't have any memorable problems installing and
building eCos.  It did take a few days of messing around to get
the toolchains built, but certainly no more hassle than I've
run into with some of the commerical toolchains I've debugged
over the years.  The nice thing (for me) about using the gnu
toolchain is the lack of a learning curve.  I've been using gcc
et al for almost 15 years, so it was nice that I didn't have to
learn yet another set of compiler, assembler, andlinker options
when I started doing eCos development.

> Point taken about Linux host being less problematic, but I
> tried both Linux and Cygwin and had only slightly different
> results. Also, I don't know about other embedded engineers, but
> it is a significant annoyance to me to have to use anything
> other than Win9x for development,

I've never used Windows for embedded development, though I used
DOS briefly many years ago.  I've always found SW development
under Unix to be easier than what I've observed other Windows
users doing.  I started out 15 years ago doing embedded
development under Unix, and though I've tried a few other
systems in the meanwhile (VMS and DOS), I still find Unix to be
the most productive environment.

> because most of the special-purpose hardware we use is
> DOS-only. It's quite painful to have to use two PCs instead of
> one.

I don't buy DOS-only hardware.  Except for that one HC11
emulator.  That one I ran under Linux's DOSemu.  Worked 
better than it did under real DOS.

> One certainly couldn't describe eCOS as a fast track to
> anything; there are a dozen different steep learning curves to
> be climbed before you can even build the OS, much less try to
> link your own program.

It didn't seem any more difficult than the commerical RTOSes
I've used.  The process of porting eCos to a new platform and
writing drivers for custom hardware seemed equivalent to or
better than what I've seen trying to get other RTOSes running
on custom hardware.

Perhaps there are other systems that are quicker than eCos if
you want an off-the-shelf turnkey system, but I've always done
development for custom boards, so I can't make a comparison.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] How do you like eCos

[Lewin A.R.W. Edwards]

Hi Grant,

> > and what is your target CPU/architecture?
>
>ARM7TDMI (custom board using a Samsung KS32C5000).

My intended target is very similar - Cirrus Logic EP7212 (Maverick, hence 
my pun). How did you manage to build gcc for thumb? I gave up on this task.

> > The reason I ask this is because I have one very major gripe
> > with the free open-source level of support from Red Hat, and
> > that is that there is no version unification, no known point
> > from which to start,
>
>I'm not sure what you mean.  There are "official" releases: the
>current one is 1.3.1, and you also have access to CVS sources.

Well, I was thinking more about the toolchain than the OS itself when I 
wrote that. I went through perhaps 80-100 full builds of binutils, gcc and 
insight before finally concluding that (a) the instructions for arm-thumb 
on Red Hat's site are just wrong, and (b) the arm-thumb target seems to be 
broken in all current and all past versions of gcc. RH's site talks about 
the 20000113 gcc snapshot as working - why the heck could they not have 
archived that version? A CVS checkout of that date still doesn't build 
properly, maybe the repository got corrupted in some way.

> > and every time one hits a problem one has to start debugging it
> > from the ground up.
>
>Are you saying that you would prefer that official releases
>came out more often?

Well, that would be nice :) But realistically, I am asking for publication 
somewhere of a complete working set of tools and a set of OS sources that 
can be built with those tools, even if the whole package is rather elderly. 
With that to start from, at least one can (for example) debug one's circuit 
while cautiously trying to build and use more recent versions of tools and 
OS sources. It's very frustrating to be where I am now, where nothing 
builds quite the way it's supposed to and I can't trust any component.

>over the years.  The nice thing (for me) about using the gnu
>toolchain is the lack of a learning curve.  I've been using gcc
>et al for almost 15 years, so it was nice that I didn't have to
>learn yet another set of compiler, assembler, andlinker options

Frankly, I'd rather not learn any compiler, assembler and linker options or 
makefile syntax. Working on Windows or OS/2 or DOS, I prefer to use an IDE 
to select source files and generate my makefiles, then work at the command 
line for builds and source editing. But that's not germane to the issue and 
I'm not complaining about having to deepen my knowledge of gcc.

>I've never used Windows for embedded development, though I used
>DOS briefly many years ago.  I've always found SW development
>under Unix to be easier than what I've observed other Windows

I don't know about you, but we have standardized on OrCAD for our schematic 
capture and PCB layout, mainly because our factories use it. It's just so 
handy to be able to Alt-Tab away from the source window to the schematic, 
and to develop circuit and software simultaneously.

Additionally, with our current DOS/Win9x development system (actually it's 
an ancient version of gcc, compiled for a Win32 host), I can carry all the 
source and schematics on my laptop, so when I go home I have access to it 
and can answer midnight questions from our Oriental factory, build 
emergency test versions of software to deal with production issues, etc.

>I don't buy DOS-only hardware.  Except for that one HC11

We have no choice, dealing with Taiwanese chip vendors. The chips are cheap 
and often work, but the development systems are unbelievably bad. I am 
trying to wean us off them, but we still have a lot of hardware round the 
place that uses proprietary parallel port controls.


Lewin A.R.W. Edwards (Embedded Engineer)
Got any Commodore 16 or VIC-20 hardware, cartridges, tapes?
Visit http://www.larwe.com/vintage/
================================================
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] How do you like eCos

[Grant Edwards]

On Tue, Nov 28, 2000 at 02:58:57PM -0500, Lewin A.R.W. Edwards wrote:

> > > and what is your target CPU/architecture?
> >
> >ARM7TDMI (custom board using a Samsung KS32C5000).
> 
> My intended target is very similar - Cirrus Logic EP7212
> (Maverick, hence my pun). How did you manage to build gcc for
> thumb? I gave up on this task.

I'm running in 32-bit ARM mode.  I've never done anything in
thumb mode.

> Well, I was thinking more about the toolchain than the OS
> itself when I wrote that. I went through perhaps 80-100 full
> builds of binutils, gcc and insight before finally concluding
> that (a) the instructions for arm-thumb on Red Hat's site are
> just wrong, and (b) the arm-thumb target seems to be broken in
> all current and all past versions of gcc. [...]

Ah, I forgot that you were using thumb mode.  That probably
explains the differences in our experiences.  There are a lot
more people using 32-bit ARM mode (people running Linux on
StrongARM, for example), so I think that tends to be better
supported than the thumb stuff.  How well the open source model
works tends to depend a lot on how large the user community is.

"All bugs are deep to a small number of eyes."

> > > and every time one hits a problem one has to start debugging it
> > > from the ground up.
> >
> >Are you saying that you would prefer that official releases
> >came out more often?
> 
> Well, that would be nice :) But realistically, I am asking for
> publication somewhere of a complete working set of tools and a
> set of OS sources that can be built with those tools, even if
> the whole package is rather elderly. With that to start from,
> at least one can (for example) debug one's circuit while
> cautiously trying to build and use more recent versions of
> tools and OS sources. It's very frustrating to be where I am
> now, where nothing builds quite the way it's supposed to and I
> can't trust any component.

You might be able to purchase a gnu-pro version from Red Hat,
but if you're looking for something you can download for free,
that pretty much depends on whether somebody else who has
needed the same stuff has taken the time to make it all
available.  I put together a working snapshot of
Cygwin/32-bit-ARM-tools (which is available via FTP thanks to
Dave Airlie), but I don't have any thumb mode tools.

> I don't know about you, but we have standardized on OrCAD for
> our schematic capture and PCB layout, mainly because our
> factories use it. It's just so handy to be able to Alt-Tab away
> from the source window to the schematic, and to develop circuit
> and software simultaneously.

Well, I don't do hardware design any more.  The last time I
did, we were using Electrical CAD software than ran on Sun
Workstations.  Since it was all X11 based, I could run the
programs remotely from my Linux box (as could Win32 users after
they futzed with Hummingbird Exceed for a day or two).

> Additionally, with our current DOS/Win9x development system
> (actually it's an ancient version of gcc, compiled for a Win32
> host), I can carry all the source and schematics on my laptop,
> so when I go home I have access to it and can answer midnight
> questions from our Oriental factory, build emergency test
> versions of software to deal with production issues, etc.

I can do the same with my Laptop that runs Linux, except that I
can't actually edit the schematics, only look at them.

> >I don't buy DOS-only hardware.  Except for that one HC11
> 
> We have no choice, dealing with Taiwanese chip vendors. The
> chips are cheap and often work, but the development systems are
> unbelievably bad. I am trying to wean us off them, but we still
> have a lot of hardware round the place that uses proprietary
> parallel port controls.

Yea, that sucks.  Development tools that come from IC vendors
are notoriously bad, but sometimes they're the only choice.
JTAG debugging w/ the ARM isn't the greatest, and I miss having
real ICE, but it works and it's fairly platform independent.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] How do you like eCos

[Hugo 'NOx' Tyson]

"Lewin A.R.W. Edwards" <larwe@larwe.com> writes:
> ...my experience with eCos and its toolchain thus far is that almost no
> component has installed/configured/compiled per the installation
> instructions, and a big part of the problem is that instead of providing
> specific snapshots of known-working versions, the install instructions
> refer to nonexistent historical versions.

I certainly don't want to have an argument about the quality of the free
distributions or anoncvs, nor of the politics of free software or open
source projects, and I'm definitely not disputing what you say.  I'm also
not the "political officer"^W^W "commercial contact" ;-) here.  Please take
this as a personal aside, not an official Red Hat frontman's comment!

In a nutshell, providing specific snapshots of known-working versions which
we have thoroughly tested and that we continue to test for your specific
platform, is the business side that allows all this stuff's existence in
the first place.  Put another way: we're more responsive to folks with a
support contract - sorry, but that's the way it is.

...which doesn't excuse poor quality in free distributions.  But this list
helps a lot with that, we hope.  And for most people who have climbed that
learning curve, it seems that newer (and maybe unreliable) is better than
more solid but out of date in terms of feature set.  Hence the anoncvs
service.

	- Huge

Re: [ECOS] How do you like eCos

[Lewin A.R.W. Edwards]

Hi Hugo,

> > instructions, and a big part of the problem is that instead of providing
> > specific snapshots of known-working versions, the install instructions
> > refer to nonexistent historical versions.
>
>not the "political officer"^W^W "commercial contact" ;-) here.  Please take
>this as a personal aside, not an official Red Hat frontman's comment!
>In a nutshell, providing specific snapshots of known-working versions which
>we have thoroughly tested and that we continue to test for your specific
>platform, is the business side that allows all this stuff's existence in

I understand this political issue. The chicken and egg problem I have for 
you is this: I'm the lead engineer on a consumer electronics line 
[www.digi-frame.com], currently running a proprietary OS (written by 
myself) and shipping thousands of pieces a year, of two models. Next year 
we want _at least_ three _new_ models including a new ultra-low-cost 
high-sales-volume unit. We want TCP/IP and multitasking and out-of-box 
support for our new CPU of choice, and eCOS looks good to me for that reason.

So we are not just making some contracted doodad that's going to sell three 
pieces and only make $1000 profit; we can afford a service contract. Heck, 
at the price I heard mentioned I'd be willing to forego a few pizzas and 
buy it out of my own pocket, if it works. But there's the rub: I cannot 
make a good case for this product, even if it was entirely free, if it 
doesn't work.

Thus far I'm waiting in agony for eval hardware so I've not been able to do 
very much beyond build the tools (kinda - I can't build the tools for 
arm-thumb, only those for arm-elf), play with the configuration tool, and 
find out that I can't install the TCP/IP module.

>And for most people who have climbed that
>learning curve, it seems that newer (and maybe unreliable) is better than
>more solid but out of date in terms of feature set.  Hence the anoncvs

Hmm. "Unreliable" isn't the word I'd use, more "undocumented". The tools 
and the OS itself might be exceedingly reliable, but the documentation is 
rather like one of those pictures that looks like a splatter of colored 
dots until you defocus your eyes. (I've never been able to see the hidden 
picture in one of those things, either).

Lewin A.R.W. Edwards (Embedded Engineer)
Got any Commodore 16 or VIC-20 hardware, cartridges, tapes?
Visit http://www.larwe.com/vintage/
================================================
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] How do you like eCos

[Paul Black]

"Lewin A.R.W. Edwards" <larwe@larwe.com> wrote:
> So we are not just making some contracted doodad that's going to sell three
> pieces and only make $1000 profit; we can afford a service contract. Heck,
> at the price I heard mentioned I'd be willing to forego a few pizzas and
> buy it out of my own pocket, if it works. But there's the rub: I cannot
> make a good case for this product, even if it was entirely free, if it
> doesn't work.

I'm in a similar boat, we will probably go with one of 3: VxWorks,
Nucleus or eCos. I've built the kernel (I think!) but now I don't know
what I can do:
How do I get my own Apps. in?
Can I simulate it on my dev platform (Linux)?
Basically, what do I do?


> Hmm. "Unreliable" isn't the word I'd use, more "undocumented". The tools
> and the OS itself might be exceedingly reliable, but the documentation is
> rather like one of those pictures that looks like a splatter of colored
> dots until you defocus your eyes. (I've never been able to see the hidden
> picture in one of those things, either).

Undocumented does seem to be the problem: I've looked at eCos dev. on
Linux, a colleague looked at eCos dev. on Windows. Neither of us have
actually got anywhere yet (probably a couple of weeks of combined
effort). There comes a point when we give up.

Paul

Re: [ECOS] How do you like eCos

[Andrew Lunn]

> I'm in a similar boat, we will probably go with one of 3: VxWorks,
> Nucleus or eCos. I've built the kernel (I think!) but now I don't know
> what I can do:
> How do I get my own Apps. in?

Look at the Tutorial section of the documentation.

> Can I simulate it on my dev platform (Linux)?

Yes. Look for references to the Synthetic target. It runs eCos as a
process on Linux.

> Basically, what do I do?

RTM and try it. 

> Undocumented does seem to be the problem: I've looked at eCos dev. on
> Linux, a colleague looked at eCos dev. on Windows. Neither of us have
> actually got anywhere yet (probably a couple of weeks of combined
> effort). There comes a point when we give up.

I personaly have not found the documentation too bad. Its terse, but
just about all there. Comming from a Unix background, man pages etc,
im used to it and like it. 

When i get a new release i can generaly compile everything from
scratch in half a day. The tool chain takes the longest time. The
limit is disk io, not human. I just follow what i says in the
documentation, plus one ecosconfig import file to make things a little
easier for me.

If you are having realy problems mail to the list. One thing where
eCos differece from VxWorks and Nucleaus etc, is there is a net
community, a bizarre is in opertation and people are working on the
ego.

        Andrew

Re: [ECOS] How do you like eCos

[Lewin A.R.W. Edwards]

>I personaly have not found the documentation too bad. Its terse, but
>just about all there. Comming from a Unix background, man pages etc,
>im used to it and like it.

It's not just that the documentation is terse, but it is scattered across 
many unrelated documents and is _always_ out of date because of version 
creep between components. Actually this is the same complaint I have about 
Linux also - too many things are built on a fragile structure of 
incremental patches. If you have been following something ever since it was 
an early beta, and you have downloaded every +0.001 patch, then what you 
have will match the latest readme file (which you won't need anyway because 
you are an expert). But if you are a new user, then you will get 
documentation version 1.200 that points you to a site where you can only 
download software version 1.305 with a readme file that describes only 
changes between version 1.304 and 1.305. The installation instructions for 
1.200 will not work for the 1.305 version. Also the developers will forget 
to mention that between 1.300 and 1.301 they upgraded some other component 
on their system, and that this upgrade is mandatory.

Maybe lurking on some mirror site in deepest Transylvania is an old 
snapshot that has actual documentation matching product, but finding this 
is harder than finding the holy grail.

It's very frustrating for new developers. If I ever get to understand this 
enough to get it working properly, I will try to develop a "real" getting 
started document including actual snapshots of working sources and tools.


Lewin A.R.W. Edwards (Embedded Engineer)
Got any Commodore 16 or VIC-20 hardware, cartridges, tapes?
Visit http://www.larwe.com/vintage/
================================================
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] How do you like eCos

[Paul Black]

Andrew Lunn <andrew.lunn@ascom.ch> wrote:
> 
> > I'm in a similar boat, we will probably go with one of 3: VxWorks,
> > Nucleus or eCos. I've built the kernel (I think!) but now I don't know
> > what I can do:
> > How do I get my own Apps. in?
> 
> Look at the Tutorial section of the documentation.

Ah yes found it. Had to do a find piped into grep to actually get it. If
it was linked off the top level contents page I might have had a
fighting chance of knowing it existed.


> > Undocumented does seem to be the problem: I've looked at eCos dev. on
> > Linux, a colleague looked at eCos dev. on Windows. Neither of us have
> > actually got anywhere yet (probably a couple of weeks of combined
> > effort). There comes a point when we give up.
> 
> I personaly have not found the documentation too bad. Its terse, but
> just about all there. Comming from a Unix background, man pages etc,
> im used to it and like it.

I also come from a Unix background but if the information can't be found
then it's irrelevant whether it's terse or verbose.

Paul

Re: [ECOS] How do you like eCos

[Andrew Lunn]

> Thus far I'm waiting in agony for eval hardware so I've not been able to do 
> very much beyond build the tools (kinda - I can't build the tools for 
> arm-thumb, only those for arm-elf), play with the configuration tool, and 
> find out that I can't install the TCP/IP module.

As someone else pointed out, the arm-elf is the more used tool
chain. Why not go with the flow and use that?

While you are waiting for your hardware i suggest you play with the
synthetic target and do the tutorial in the documentation. Thats the
way i was introduced to eCos. I tend to use the synthetic target a
lot. Its much faster to go around the edit/compile/run/crash loop on
the synthetic target.

        Andrew

Re: [ECOS] How do you like eCos

[Lewin A.R.W. Edwards]

> > very much beyond build the tools (kinda - I can't build the tools for
> > arm-thumb, only those for arm-elf), play with the configuration tool, and
>
>As someone else pointed out, the arm-elf is the more used tool
>chain. Why not go with the flow and use that?

Well, I don't have any choice, since I can't build the thumb tools and 
don't believe they currently work at all. However, I was really hoping for 
smaller and faster code using Thumb (especially on our ultra-cost-pared 
model, where I want to use 16-bit buses). I don't really want to spend the 
thousands on the ARM toolkit though (especially since it comes from 
Metrowerks and to add insult to injury it has copy-protection).

>While you are waiting for your hardware i suggest you play with the
>synthetic target and do the tutorial in the documentation. Thats the

Which isn't supported under Win32. I guess I can dig out another PC and 
install Linux again. *sigh*

>lot. Its much faster to go around the edit/compile/run/crash loop on
>the synthetic target.

It's hard for us to get our inputs into an emulator. We need to connect to 
external hardware. Writing interfaces and abstraction layers would probably 
increase the overall project size by 50% if not more.


Lewin A.R.W. Edwards (Embedded Engineer)
Got any Commodore 16 or VIC-20 hardware, cartridges, tapes?
Visit http://www.larwe.com/vintage/
================================================
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/