OS for 8 bits processor

Thank you

/Ulf

Ulf Reiman wrote:

> 
> Ian Bell skrev:
> 
>> Ulf Reiman wrote:
>>
>> > I am creating the 802.4.15 from scratch together with some people. Do
>> > you have any link to source code for some availably stack I would be
>> > very happy?
>> >
>> > What is your suggestion of using OS or not, a mean the stack must have
>> > multiple threads of execution
>>
>> Are you sure it must?
>>
>> Ian
> I dont now,may it not go faster if i do like that. Do you think it
> better to have just a queue to put in the things to do?
> 
> /Ulf

For most stack only applications a simple event queue works very well.

Ian

Kelly Hall wrote:
> rTrenado wrote:
> > An RTOS would really simplify the software architecture for
> > appliactions involving networking stacks.
>
> Why do you think so?  I've been using networking stacks on machines
> without real-time operating systems for the better part of 20 years.
>
> Having multiple threads of execution is great, but an RTOS is a lot more
> than just a task scheduler.
>
> Kelly


I have been programming networking/communication stacks from some time
(almost 10 years) in the embedded space. The reason I say that an RTOS
could simplify you architecture is because you can:

(1) abstract complex state machines (by using the provided data
objects)
(2) Hide implementation details (by creating stand alone modules with
little dependencies)
(3) Encapsulate data (instead of using global state and/or status flags
(4) Change the data flow with little effort (i.e. remove protocol
handlers or add hooks)
(5) High level applications do also benefit from the multitasking
environment in the same way as the networking stack.

I agree with you in that you can get away without an RTOS, but a simple
scheduler with some synchronization primitives can make our embedded
programming life much easier.

Rene

rTrenado wrote:
> I have been programming networking/communication stacks from some time
> (almost 10 years) in the embedded space. The reason I say that an RTOS
> could simplify you architecture is because you can:
> 
> (1) abstract complex state machines (by using the provided data
> objects)
> (2) Hide implementation details (by creating stand alone modules with
> little dependencies)
> (3) Encapsulate data (instead of using global state and/or status flags
> (4) Change the data flow with little effort (i.e. remove protocol
> handlers or add hooks)
> (5) High level applications do also benefit from the multitasking
> environment in the same way as the networking stack.
> 
> I agree with you in that you can get away without an RTOS, but a simple
> scheduler with some synchronization primitives can make our embedded
> programming life much easier.

I totally agree with you, except none of the reasons you sight have 
anything to do with a real-time operating system - they are present in a 
generic operating system without any real-time functions.

Kelly

Indeed, you are right. The point I wanted to make is that the RTOS
further simplifies the net stack development on an embedded system as
small as the AVR and gives you a lot of tools to achieve the points I
listed for as little as 4K of ROM.


Kelly Hall wrote:
> rTrenado wrote:
> > I have been programming networking/communication stacks from some time
> > (almost 10 years) in the embedded space. The reason I say that an RTOS
> > could simplify you architecture is because you can:
> >
> > (1) abstract complex state machines (by using the provided data
> > objects)
> > (2) Hide implementation details (by creating stand alone modules with
> > little dependencies)
> > (3) Encapsulate data (instead of using global state and/or status flags
> > (4) Change the data flow with little effort (i.e. remove protocol
> > handlers or add hooks)
> > (5) High level applications do also benefit from the multitasking
> > environment in the same way as the networking stack.
> >
> > I agree with you in that you can get away without an RTOS, but a simple
> > scheduler with some synchronization primitives can make our embedded
> > programming life much easier.
>
> I totally agree with you, except none of the reasons you sight have
> anything to do with a real-time operating system - they are present in a
> generic operating system without any real-time functions.
> 
> Kelly

On Wed, 31 Aug 2005 18:37:17 -0000, Grant Edwards <grante@visi.com>
wrote:

>On 2005-08-31, Ken <nomailgiven@gmail.com> wrote:
>>
>>> We'll, we have thousands of HAPPY customers. Not sure whom this friend
>>> is, but I can provide contact info of people specifically using
>>> CMX-TINY+ for the AVR and are very happy with it and some have tried or
>>> compared other OSes and we have won against them.
>>
>> I think the comments are more an expression of frustration at your spamming
>> this thread.
>
>No, my friend's negative comments regarded his having to find
>and fix a bug in the scheduler.  He said that the scheduler was
>written in "spaghetti" assembly language, and it wasn't fun to
>work on.  I was surprised to hear that the scheduler was in
>assembly language -- I've worked with 4-5 RTOSes, and they were
>all written in C with a bit of assembly language for context
>save/restore.

I earn my living writing RTOS in Assembly _but_ our customer don't
have to search for bugs in the sources (they get). That's my job ;-)
(No, I do _not_ work for CMX !)
-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

On 31 Aug 2005 02:08:51 -0700, "Ulf Reiman" <ulf.reiman@gmail.com>
wrote:

>Hi!
>I am looking for a free Operation system that can be used for 8-bits
>CPU, AVR; I am using a card with Atmega 128 and CC2420. I will

Just out of curiousity: Why free ? Is it a hobby project ?
If not, save your employers money and buy a commercial one with a good
support.

-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

On Mon, 05 Sep 2005 15:10:10 GMT, bastian42@yahoo.com (42Bastian
Schick) wrote:

>On Wed, 31 Aug 2005 18:37:17 -0000, Grant Edwards <grante@visi.com>
>wrote:
>
>>On 2005-08-31, Ken <nomailgiven@gmail.com> wrote:
>>>
>>>> We'll, we have thousands of HAPPY customers. Not sure whom this friend
>>>> is, but I can provide contact info of people specifically using
>>>> CMX-TINY+ for the AVR and are very happy with it and some have tried or
>>>> compared other OSes and we have won against them.
>>>
>>> I think the comments are more an expression of frustration at your spamming
>>> this thread.
>>
>>No, my friend's negative comments regarded his having to find
>>and fix a bug in the scheduler.  He said that the scheduler was
>>written in "spaghetti" assembly language, and it wasn't fun to
>>work on.  I was surprised to hear that the scheduler was in
>>assembly language -- I've worked with 4-5 RTOSes, and they were
>>all written in C with a bit of assembly language for context
>>save/restore.
>
>I earn my living writing RTOS in Assembly _but_ our customer don't
>have to search for bugs in the sources (they get). That's my job ;-)
>(No, I do _not_ work for CMX !)

I have to agree that, at least as far as the scheduler and its near
kin, my experience has been that in most architectures writing that
code in -Assembly- results in code that is somewhat spagetti-ish (you
are swapping contexts, handling atomic operations like semaphores and
avoiding deadlocks), but in C or any other "high" level language it
would be just as spagetti-ish and require that you be fluent in both
the architectural assembly language and C (or whatever) as well as
knowledgeable when it comes to the optimizing the complier is going to
do for/to you.

I have written several custom RTOSes, developed on several comercial
RTOSes (though some might reserve another name for "Real Time
Unix/Regulus"), and by far the easiest to debug were the ones with a
well defined hardware abstraction layer (sorry, not to be confused
with the Windows NT HAL) with assembly below the interface and
whatever language you want above it.

[And I don't work for CMX either.]

--Charles

It is a project at my University, and we do not have money for
commercial products unfortunately. so i do not have any choice

/Ulf

Can you recommend some RTOS?

/Ulf