RE: [ECOS] Re: ECOS - MIPS

RE: [ECOS] Re: ECOS - MIPS

[Ali, Khurram]

I recently had an opportunity to work with eCos. It is a wonderful technology.

Unfortunately, to do anything significant you will need to spend a good amount of time to get familiar with the technology before you can actually start on your own application.

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of K. Sinan YILDIRIM
Sent: Friday, June 24, 2005 9:50 AM
To: Grant Edwards; ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Re: ECOS - MIPS

Cuma 24 Haziran 2005 05:08 ös tarihinde, Grant Edwards şunları yazmıştı: 
> In gmane.os.ecos.general, you wrote:
> > I just mention that eCOS didnt fullfill my needs. The only
> > thing eCOS provides is using reusable components like the ones
> > in visual programming languages.
>
> Huh?  I've no idea what you mean. What are "visual" programming
> languages?  Things like LabVIEW and IBM Data Explorer?
>

- I said visual programming languages. Not tools!  If you say "tools" that 
means you have an idea. This is a contradiction, isn't it ? :P

Some visual programming environments have component based SW development, like 
VB. You drag and drop components, use them, change them. I just wanted to 
mean that eCOS components are ,in mentality, like that. I didn't want to say 
that "eCOS" is bad. An advantage of eCOS is its components. It includes many 
components. Having components is not a bad idea.It is not new also... Isnt it 
? Why do you misunderstand me ? May be your english is not so good... Go and 
take courses. I advice you...


> > If u substract components, uCOS is much more usable than it if
>
> I can't take it any more.  The word is _you_!
>
> > I compare it with eCOS.
>
> That statement puzzles me as well.  I've used both uCOS and
> eCos (and I mean shipped products containing both -- not just
> played with them for an afternoon). They're intended for much
> different markets. You're comparing apples and oranges.
>
> > uCOs is small, deterministic etc...
>
> You probably find it "more usable" simply because it has so
> many fewer available features.  It includes driver models for
> no peripherals, no networking, no filesystem, and only one
> scheduler.  You should be comparing uCOS to just the eCos
> kernel with about half of it's available features removed.
>

- eCOS is much more bigger, it is still groving. There may be many commercial 
products that uses it.  But there are OS'es that do the same  on the embedded 
world ( May be you will misunderstand me again. Let me explain. I mean 
kernel, not components... ). I just wanted to give an example. uCOS is not 
apple and eCOs is not orange. I am not a child that plays operating systems 
on the afternoons. I am not a uCOS fan or an anti-eCOS man. I just tried eCOS 
and saw that it is not really configurable. This is my idea. I wish it 
changes in the future...


> > For example i may write components to uCOS and then it becomes
> > eCOS :P (just a joke...)
>
> OK
>
> > Just examine the books :
> >
> > + Real Time Design Patterns
> > + Patterns for Small Memory Systems
> > + Pattern Oriented SW Architecture ..
> >
> > they are the experiences of embedded SW developers. There are
> > the things that they know much better... I think Operating
> > systems are the products that must live longer. If you want
> > your SW to live longer, you must learn new SW concepts, you
> > must apply them...
>
> So tell us, how many embedded OSes have you written?  How many
> different emebdded SW projects have you shipped?  Did you use
> all those "patterns"?
>
+ I have shipped 1 million embedded products and i have written 1 million 
embedded operating systems. I have been using patterns for a million of 
years.  Patterns doesnt solve everything but it increases reusability. If an 
operating system says  "I am configurable" or " I may be used with many 
projects." it must , at least in the future , use some new SW techniques.

> > For example having an HAL layer as an architecture is not a
> > new concept.
>
> Nobody said it was.  New doesn't not always mean better, and
> old does not always mean worse.

+ Yes. You are really right at that point.

>
> > Unix, Linux and also Windows have HAL layers. Also HAL layer
> > is a must for embedded systems. eCOS is written in C++ . You
> > may use Bridge or Adapter pattern to build an HAL layer.
> > ("Program for interfaces, not for the implementation" is the
> > main concept of modern SW. )
>
> I simply don't see how you think eCos violates that statement.
> The interfaces between eCos and various hardware drivers is
> well defined.
>

+ Yes. You are right too. I just mean that, i think in modern object oriented 
manner and the code and design of eCOS has some design based lacks.

> > There are many operating systems that are done with C++. Have
> > u ever examined them ? For example Chorus, L4, Amobea... etc.
> > They have new ideas,they try to use new SW techniques.
>
> And how many products in the field contain those OSes?
>
> --
> Grant Edwards                   grante             Yow!  LOOK!!! I'm
> WALKING at               in my SLEEP again!! visi.com

+ You must learn that many contain these OS'es. I know the internals of 
embedded products. I know what sort of bugs they have... Commercially used 
operating systems doesnt meand that they are the best. If eCOS wasnt open 
source or free, how many users will choose eCOS instead of Nucleus, uCOS, QNX 
etc... ? 




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: ECOS - MIPS

[Grant Edwards]

In gmane.os.ecos.general, you wrote:
> Cuma 24 Haziran 2005 05:08 ös tarihinde, Grant Edwards ?unlar? yazm??t?: 
>> In gmane.os.ecos.general, you wrote:
>> > I just mention that eCOS didnt fullfill my needs. The only
>> > thing eCOS provides is using reusable components like the ones
>> > in visual programming languages.
>>
>> Huh?  I've no idea what you mean. What are "visual" programming
>> languages?  Things like LabVIEW and IBM Data Explorer?
>
> - I said visual programming languages. Not tools!  If you say
> "tools" that means you have an idea. This is a contradiction,
> isn't it ? :P

Sorry, I have no idea what that means.

> Some visual programming environments have component based SW
> development, like VB.

The VB with which I am most familiar is Victoria Bitter.  After
googling for "VB" I'm guessing you're talking about Visual
Basic?

> You drag and drop components, use them, change them. I just
> wanted to mean that eCOS components are, in mentality, like
> that. I didn't want to say that "eCOS" is bad.

This is all about the configuration tool's UI design?  You want
to drag and drop stuff instead of using the tree widget?

> An advantage of eCOS is its components. It includes many
> components. Having components is not a bad idea.It is not new
> also... Isnt it ? Why do you misunderstand me ? May be your
> english is not so good... Go and take courses. I advice you...

Yea, that's it.  My English isn't good enough.

>> You probably find it "more usable" simply because it has so
>> many fewer available features.  It includes driver models for
>> no peripherals, no networking, no filesystem, and only one
>> scheduler.  You should be comparing uCOS to just the eCos
>> kernel with about half of it's available features removed.
>
> - eCOS is much more bigger, it is still groving. There may be
> many commercial products that uses it.  But there are OS'es
> that do the same on the embedded world ( May be you will
> misunderstand me again. Let me explain. I mean kernel, not
> components... ). I just wanted to give an example. uCOS is not
> apple and eCOs is not orange. I am not a child that plays
> operating systems on the afternoons. I am not a uCOS fan or an
> anti-eCOS man. I just tried eCOS and saw that it is not really
> configurable. This is my idea. I wish it changes in the
> future...

You're right.  My English must not be up to snuff.  I'll bow
out of the discussion and let those with better English handle
it.

-- 
Grant Edwards                   grante             Yow!  This is my WILLIAM
                                  at               BENDIX memorial CORNER
                               visi.com            where I worship William
                                                   Bendix like a GOD!!

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: ECOS - MIPS

[K. Sinan YILDIRIM]

Cuma 24 Haziran 2005 05:08 ös tarihinde, Grant Edwards şunları yazmıştı: 
> In gmane.os.ecos.general, you wrote:
> > I just mention that eCOS didnt fullfill my needs. The only
> > thing eCOS provides is using reusable components like the ones
> > in visual programming languages.
>
> Huh?  I've no idea what you mean. What are "visual" programming
> languages?  Things like LabVIEW and IBM Data Explorer?
>

- I said visual programming languages. Not tools!  If you say "tools" that 
means you have an idea. This is a contradiction, isn't it ? :P

Some visual programming environments have component based SW development, like 
VB. You drag and drop components, use them, change them. I just wanted to 
mean that eCOS components are ,in mentality, like that. I didn't want to say 
that "eCOS" is bad. An advantage of eCOS is its components. It includes many 
components. Having components is not a bad idea.It is not new also... Isnt it 
? Why do you misunderstand me ? May be your english is not so good... Go and 
take courses. I advice you...


> > If u substract components, uCOS is much more usable than it if
>
> I can't take it any more.  The word is _you_!
>
> > I compare it with eCOS.
>
> That statement puzzles me as well.  I've used both uCOS and
> eCos (and I mean shipped products containing both -- not just
> played with them for an afternoon). They're intended for much
> different markets. You're comparing apples and oranges.
>
> > uCOs is small, deterministic etc...
>
> You probably find it "more usable" simply because it has so
> many fewer available features.  It includes driver models for
> no peripherals, no networking, no filesystem, and only one
> scheduler.  You should be comparing uCOS to just the eCos
> kernel with about half of it's available features removed.
>

- eCOS is much more bigger, it is still groving. There may be many commercial 
products that uses it.  But there are OS'es that do the same  on the embedded 
world ( May be you will misunderstand me again. Let me explain. I mean 
kernel, not components... ). I just wanted to give an example. uCOS is not 
apple and eCOs is not orange. I am not a child that plays operating systems 
on the afternoons. I am not a uCOS fan or an anti-eCOS man. I just tried eCOS 
and saw that it is not really configurable. This is my idea. I wish it 
changes in the future...


> > For example i may write components to uCOS and then it becomes
> > eCOS :P (just a joke...)
>
> OK
>
> > Just examine the books :
> >
> > + Real Time Design Patterns
> > + Patterns for Small Memory Systems
> > + Pattern Oriented SW Architecture ..
> >
> > they are the experiences of embedded SW developers. There are
> > the things that they know much better... I think Operating
> > systems are the products that must live longer. If you want
> > your SW to live longer, you must learn new SW concepts, you
> > must apply them...
>
> So tell us, how many embedded OSes have you written?  How many
> different emebdded SW projects have you shipped?  Did you use
> all those "patterns"?
>
+ I have shipped 1 million embedded products and i have written 1 million 
embedded operating systems. I have been using patterns for a million of 
years.  Patterns doesnt solve everything but it increases reusability. If an 
operating system says  "I am configurable" or " I may be used with many 
projects." it must , at least in the future , use some new SW techniques.

> > For example having an HAL layer as an architecture is not a
> > new concept.
>
> Nobody said it was.  New doesn't not always mean better, and
> old does not always mean worse.

+ Yes. You are really right at that point.

>
> > Unix, Linux and also Windows have HAL layers. Also HAL layer
> > is a must for embedded systems. eCOS is written in C++ . You
> > may use Bridge or Adapter pattern to build an HAL layer.
> > ("Program for interfaces, not for the implementation" is the
> > main concept of modern SW. )
>
> I simply don't see how you think eCos violates that statement.
> The interfaces between eCos and various hardware drivers is
> well defined.
>

+ Yes. You are right too. I just mean that, i think in modern object oriented 
manner and the code and design of eCOS has some design based lacks.

> > There are many operating systems that are done with C++. Have
> > u ever examined them ? For example Chorus, L4, Amobea... etc.
> > They have new ideas,they try to use new SW techniques.
>
> And how many products in the field contain those OSes?
>
> --
> Grant Edwards                   grante             Yow!  LOOK!!! I'm
> WALKING at               in my SLEEP again!! visi.com

+ You must learn that many contain these OS'es. I know the internals of 
embedded products. I know what sort of bugs they have... Commercially used 
operating systems doesnt meand that they are the best. If eCOS wasnt open 
source or free, how many users will choose eCOS instead of Nucleus, uCOS, QNX 
etc... ? 




--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: ECOS - MIPS

[Grant Edwards]

In gmane.os.ecos.general, you wrote:

> I just mention that eCOS didnt fullfill my needs. The only
> thing eCOS provides is using reusable components like the ones
> in visual programming languages.

Huh?  I've no idea what you mean. What are "visual" programming
languages?  Things like LabVIEW and IBM Data Explorer?

> If u substract components, uCOS is much more usable than it if

I can't take it any more.  The word is _you_!

> I compare it with eCOS.

That statement puzzles me as well.  I've used both uCOS and
eCos (and I mean shipped products containing both -- not just
played with them for an afternoon). They're intended for much
different markets. You're comparing apples and oranges.

> uCOs is small, deterministic etc...

You probably find it "more usable" simply because it has so
many fewer available features.  It includes driver models for
no peripherals, no networking, no filesystem, and only one
scheduler.  You should be comparing uCOS to just the eCos
kernel with about half of it's available features removed.

> For example i may write components to uCOS and then it becomes
> eCOS :P (just a joke...) 

OK

> Just examine the books :
>
> + Real Time Design Patterns
> + Patterns for Small Memory Systems
> + Pattern Oriented SW Architecture ..
>
> they are the experiences of embedded SW developers. There are
> the things that they know much better... I think Operating
> systems are the products that must live longer. If you want
> your SW to live longer, you must learn new SW concepts, you
> must apply them...

So tell us, how many embedded OSes have you written?  How many
different emebdded SW projects have you shipped?  Did you use
all those "patterns"?

> For example having an HAL layer as an architecture is not a
> new concept.

Nobody said it was.  New doesn't not always mean better, and
old does not always mean worse.

> Unix, Linux and also Windows have HAL layers. Also HAL layer
> is a must for embedded systems. eCOS is written in C++ . You
> may use Bridge or Adapter pattern to build an HAL layer.
> ("Program for interfaces, not for the implementation" is the
> main concept of modern SW. )

I simply don't see how you think eCos violates that statement.
The interfaces between eCos and various hardware drivers is
well defined.

> There are many operating systems that are done with C++. Have
> u ever examined them ? For example Chorus, L4, Amobea... etc.
> They have new ideas,they try to use new SW techniques.

And how many products in the field contain those OSes?

-- 
Grant Edwards                   grante             Yow!  LOOK!!! I'm WALKING
                                  at               in my SLEEP again!!
                               visi.com            

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: ECOS - MIPS

[Nick Garnett]

"K. Sinan YILDIRIM" <sinany@beko.com.tr> writes:

> 
> Just examine the books :
> 
> + Real Time Design Patterns
> + Patterns for Small Memory Systems
> + Pattern Oriented SW Architecture ..
> 
> they are the experiences of embedded SW developers. There are the things that 
> they know much better...

eCos was designed and written by experienced embedded software
engineers. We don't need books to tell us how to suck those eggs.

> I think Operating systems are the products that must 
> live longer. If you want your SW to live longer, you must learn new SW 
> concepts, you must apply them...

Long lived software must be based on well understood, tried, tested
and trusted techniques. It should not adopt the latest
flavour-of-the-month fad just for the sake of appearing modern. 

> 
> For example having an HAL layer as an architecture is not a new concept. Unix, 
> Linux and also Windows have HAL layers. Also HAL layer is a must for embedded 
> systems.

We have never claimed that any of the techniques in eCos are original
or novel. Quite the opposite, for the reasons I give above.

> eCOS is written in C++ . You may use Bridge or Adapter pattern to 
> build an HAL layer.

The Bridge and Adapter patterns seem to be no more than techniques for
separating interface from implementation. They can only be directly
applied in object oriented languages and require a rather complex
class hierarchy to be created.

The HAL for an embedded system must be small and efficient. Embedding
it in layers of C++ class hierarchies would defeat the object. Much of
the HAL needs to access hardware resources, some of which must be done
in assembler, and for efficiency needs to be done inline. Assembly
linkage to C++ is hard, and we want the HAL code to be callable from
both C++ and C code.

If you want to see something similar to the Bridge/Adapter patterns
being applied in eCos, see the way in which thread objects and thread
queues are constructed from a mixture of interface and implementation
classes. It may not match the patterns exactly, but its goal is the
same.

I expect you will find many examples of software patterns throughout
eCos, they are mostly common implementation techniques that any
experienced software engineer applies as a matter of course.


> ("Program for interfaces, not for the implementation" is 
> the main concept of modern SW. )
>

That is hardly a new concept, it is probably one of the oldest system
structuring techniques around. You will find well defined and enforced
interfaces throughout eCos. It is the only way for an OS that runs on
a wide range of platforms, supports a wide range of devices, and is
highly configurable to manage the complexity.


> There are many operating systems that are done with C++. Have u ever examined 
> them ? For example Chorus, L4, Amobea... etc. They have new ideas,they try to 
> use new SW techniques.

Chorus is 20+ years old. So is Amobea. Hardly new. L4 is interesting
mainly for the very low level techniques used in the kernel to achieve
very fast context switch times.

Of course I have examined them, read the papers, downloaded the
sources, talked to the authors. In the case of Chorus and Amobea,
probably long before you had ever heard of them. Those parts that were
useful were noted and used. Most of the more exotic techniques were
marvelled over and then firmly set aside.


As far as software patterns are concerned, I think you have things the
wrong way round. Software Patterns are a descriptive technique used
to codify the insights, knowledge and experience of expert
programmers. It is not a prescription for building all code. Any
pattern needs to be adapted and changed to match the specific
situation. As a teaching mechanism I don't doubt that it is useful,
but it is just a more formal version of learning by example, which we
all went through. For real software design, it doesn't seem to be any
kind of substitute for genuine knowledge and experience.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: ECOS - MIPS

[Richard Forrest]

I may have given the impression that I was unhappy with eCos. That could  
not be further from the truth. I love its compile-time configuration  
system. It is a really clever concept, beautifully and cleanly  
implemented. Altogether it is a fantastic piece of software and I would  
not be wasting my time learning to use it if I thought otherwise. I am  
genuinely incredibly grateful to all who have contributed and released it  
under the GPL for us all to enjoy.

You probably get fed up with newbies telling you what is wrong with eCos  
without putting in the effort of understanding it first. And I would agree  
with you there. I am not going to make any criticisms (if at all) until I  
am a lot more experienced with eCos than I am today. My point is that  
criticisms should not be discouraged. Sometimes people with different  
software backgrounds might see something that the eCos community might  
miss. Encouraging people to put forward concrete proposals for discussion  
(not necessarily just patches) might be a good way to sort the good ideas  
 from those that are misguided. By submitting a concrete proposal a critic  
can show they understand eCos, the issue they are criticising and that  
they have a carefully considered and practical solution.

Richard Forrest



On Thu, 23 Jun 2005 19:03:48 -0500, Grant Edwards <grante@visi.com> wrote:

> In gmane.os.ecos.general, you wrote:
>
>> My initial impressions were that the coding style in eCos was
>> rather old fashioned.
>
> Are you referring to the coding style (i.e. indentation,
> variable names, etc.) or the actual architecture and design?
>
>> We are probably both used to the amazing things that can be
>> done with STL, boost, template metaprogramming etc. However I
>> realise that many of these libraries and techniques are not
>> appropriate for embedded programming.
>
> Depends on the system.
>
>> On the other hand it is possible that some modern C++
>> techniques could be useful in this context.
>
> Like what?
>
> Since eCos is the only RTOS kernel i know of written in C++, it
> would appear it's leading the pack in using "some modern C++
> techniques.  I'm no C++ expert, but the design and
> implimentation of the eCos kernel looked pretty nifty what with
> those objects and classes and whatnot.
>
> Most of the drivers, OTOH, are pretty much what drivers always
> are: nasty low-level C code.
>
> Embedded systems development is just plain hard compared to
> many other sorts of SW development.  It requires a lot of
> knowlege about the platform hardware, the tools, and the
> problem domain. There is no silver bullet.
>
>> Currently I do not have enough experience of embedded
>> programming to give an opinion.
>>
>> Could you provide an example of how some part of eCos could be
>> improved using a specific design pattern. This could form the
>> basis of a more focused discussion of the benefits of what you
>> are proposing. If your ideas are practical and would genuinely
>> make eCos more easily configured then I am certain that the
>> eCos maintainers would be very happy to help you incorporate
>> them.
>
> I'm certain they would.
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: ECOS - MIPS

[K. Sinan YILDIRIM]

SW is a different concept. You make code  really faster but after 2 months you 
cannot improve it. Also you write it in a really maintanainable way, but it 
may consume too much space... vice versa...Modern SW is done with reusing the 
architecture, not only reusing components or codes. There are plenty of 
documents, you may read and learn. Embedded SW is behind the general PC 
software. PC SW evolved so much, many problems are solved but embedded 
systems are just popular and there are many problems to be solved. These 
discussions are the result of this situation.

I just mention that eCOS didnt fullfill my needs. The only thing eCOS provides 
is using reusable components like the ones in visual programming languages.
If u substract components, uCOS is much more usable than it if I compare it 
with eCOS. uCOs is small, deterministic etc... For example i may write 
components to uCOS and then it becomes eCOS :P (just a joke...) 

Just examine the books :

+ Real Time Design Patterns
+ Patterns for Small Memory Systems
+ Pattern Oriented SW Architecture ..

they are the experiences of embedded SW developers. There are the things that 
they know much better... I think Operating systems are the products that must 
live longer. If you want your SW to live longer, you must learn new SW 
concepts, you must apply them...

For example having an HAL layer as an architecture is not a new concept. Unix, 
Linux and also Windows have HAL layers. Also HAL layer is a must for embedded 
systems. eCOS is written in C++ . You may use Bridge or Adapter pattern to 
build an HAL layer. ("Program for interfaces, not for the implementation" is 
the main concept of modern SW. )

There are many operating systems that are done with C++. Have u ever examined 
them ? For example Chorus, L4, Amobea... etc. They have new ideas,they try to 
use new SW techniques.



Perşembe 23 Haziran 2005 06:28 ös tarihinde, Grant Edwards şunları yazmıştı: 
> In gmane.os.ecos.general, you wrote:
> > patterns means reusability of the design and architecture. if
> > u want your opearting system to fullfill future requests, i
> > must strongly suggest to use them.the things that eCos uses is
> > traditional C programming way of doing reusability and
> > maintainability.
>
> Right.
>
> > modern operating systems must modern software ideas and
> > architecture.
>
> You're free to write your own.  eCos suits my needs quite
> nicely.
>
> > Pattern oriented architecture is not a new idea
> > but none of the embedded operating systems uses them.
>
> Firstly, there might be a reason for that.  We're not stupid,
> you know.
>
> Secondly, I have no idea what you mean by "pattern oriented
> architecture" can you point to a description?  The things that
> Google found were either describing ways to fail:
>
>    Pattern oriented architecture - A trend that's found in
>    systems created by architects who've recently read and
>    digested books on architectural patterns and come to the
>    conclusion that implementing patterns (such as
>    front-controller, etc) is the key to a successful
>    architecture. Rather than determining if common patterns are
>    appropriate, and picking the most suitable one, all patterns
>    that can be applied are done so, on top of one another,
>    creating an entangled, schizophrenic system.
>
> or were marketing buzword-bullshit:
>
>    A standards-based, pattern-oriented architecture that follows
>    industry best-practices assures that the NEFS will fit right
>    into your development environment.
>
> > Java classes are dynamically loaded. Java will be a future for
> > embedded systems. Many companies started to use java. it has
> > many benefits. If performance problems are solved, Java will
> > be a revolution for embedded systems.
>
> People have been saying that for 10 years.  I stopped paying
> much attention 5 years ago.  Java requires MASSIVE amounts of
> storage compared to eCos.
>
> > i am going to write an operating system with patterns and
> > reusable architecture. i will share it with you in the future
> > when i finish.
>
> OK.
>
> --
> Grant Edwards                   grante             Yow!  I own
> seven-eighths at               of all the artists in visi.com           
> downtown Burbank!


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: ECOS - MIPS

[Grant Edwards]

In gmane.os.ecos.general, you wrote:

> My initial impressions were that the coding style in eCos was
> rather old fashioned.

Are you referring to the coding style (i.e. indentation,
variable names, etc.) or the actual architecture and design?

> We are probably both used to the amazing things that can be
> done with STL, boost, template metaprogramming etc. However I
> realise that many of these libraries and techniques are not
> appropriate for embedded programming.

Depends on the system.

> On the other hand it is possible that some modern C++
> techniques could be useful in this context.

Like what?  

Since eCos is the only RTOS kernel i know of written in C++, it
would appear it's leading the pack in using "some modern C++
techniques.  I'm no C++ expert, but the design and
implimentation of the eCos kernel looked pretty nifty what with
those objects and classes and whatnot.

Most of the drivers, OTOH, are pretty much what drivers always
are: nasty low-level C code.

Embedded systems development is just plain hard compared to
many other sorts of SW development.  It requires a lot of
knowlege about the platform hardware, the tools, and the
problem domain. There is no silver bullet.

> Currently I do not have enough experience of embedded
> programming to give an opinion.
>
> Could you provide an example of how some part of eCos could be
> improved using a specific design pattern. This could form the
> basis of a more focused discussion of the benefits of what you
> are proposing. If your ideas are practical and would genuinely
> make eCos more easily configured then I am certain that the
> eCos maintainers would be very happy to help you incorporate
> them.

I'm certain they would. 

-- 
Grant Edwards                   grante             Yow!  LOU GRANT froze
                                  at               my ASSETS!!
                               visi.com            

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: ECOS - MIPS

[Grant Edwards]

In gmane.os.ecos.general, you wrote:

> patterns means reusability of the design and architecture. if
> u want your opearting system to fullfill future requests, i
> must strongly suggest to use them.the things that eCos uses is
> traditional C programming way of doing reusability and
> maintainability.

Right.

> modern operating systems must modern software ideas and
> architecture.

You're free to write your own.  eCos suits my needs quite
nicely.

> Pattern oriented architecture is not a new idea
> but none of the embedded operating systems uses them.

Firstly, there might be a reason for that.  We're not stupid,
you know.

Secondly, I have no idea what you mean by "pattern oriented
architecture" can you point to a description?  The things that
Google found were either describing ways to fail:

   Pattern oriented architecture - A trend that's found in
   systems created by architects who've recently read and
   digested books on architectural patterns and come to the
   conclusion that implementing patterns (such as
   front-controller, etc) is the key to a successful
   architecture. Rather than determining if common patterns are
   appropriate, and picking the most suitable one, all patterns
   that can be applied are done so, on top of one another,
   creating an entangled, schizophrenic system.

or were marketing buzword-bullshit:

   A standards-based, pattern-oriented architecture that follows
   industry best-practices assures that the NEFS will fit right
   into your development environment. 

> Java classes are dynamically loaded. Java will be a future for
> embedded systems. Many companies started to use java. it has
> many benefits. If performance problems are solved, Java will
> be a revolution for embedded systems. 

People have been saying that for 10 years.  I stopped paying
much attention 5 years ago.  Java requires MASSIVE amounts of
storage compared to eCos.

> i am going to write an operating system with patterns and
> reusable architecture. i will share it with you in the future
> when i finish.

OK.

-- 
Grant Edwards                   grante             Yow!  I own seven-eighths
                                  at               of all the artists in
                               visi.com            downtown Burbank!

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: ECOS - MIPS

[Grant Edwards]

In gmane.os.ecos.general, you wrote:

> i wont make it configurable with make files. i would use object oriented
> configurabilitiy.  just inspect Java.
>
> you register classes, you program for interfaces, you use abstract classes.
>
> just inspect bridge or adapter pattern. you will understand me.

That sort of run-time configurability is completely unusable
for the dedicated, embedded systems for which eCos is intended.
You approach would require huge amounts of storage and probably
some sort of filesystem.

If you want a JVM, run a JVM.

-- 
Grant Edwards                   grante             Yow!  My uncle Murray
                                  at               conquered Egypt in 53
                               visi.com            B.C. And I can prove
                                                   it too!!

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss