Hans-Bernhard Broeker wrote:

> Ian Bell <ruffrecords@yahoo.com> wrote:
> 
>> The problem for a pre-emptive OS is stack. No 8051 variant has a stack
>> greater then 256 bytes (and in practice it is rather less).
> 
> BZZZZ! --- and thanks for playing ;-) Check out the DS80C390: 1 kB of
> dedicated stack space.  And it's even in on-chip XDATA memory so it
> doesn't even eat up valuable IDATA.
> 

Now that is an interesting variant; they have actually increased the stack
pointer to 10 bits so it can address 1K of memory. Pity is has CAN bus
baggage. Now if someone brought out a range of variants all with a 1K stack
that would be interesting. The compiler writers would have fun with it too.

Ian

cbarn24050@aol.com wrote:

> 
>> >>
>> >>I would have thought the PIC18 would have even worse than the 8051.
>> >>
>> The problem for a pre-emptive OS is stack. No 8051 variant has a stack
>> greater then 256 bytes (and in practice it is rather less). Some OS get
>> round this by using XRAM to save non running processes' stacks but this
>> is slow.
>>
>> Most (all?) PICs have a fixed, inaccessible and rather small stack which
>> makes it harder to write an RTOS IMHO.
>>
>> Ian
> 
> The other problem is the lack of data pointers on the 8051. The pic18
> have 3 I think so you can easily make your own data stack and plenty on
> onboard ram to accomodate it.

The 8051 has three as well. Two 8bit and one 16 bit pointer. Why anyone
would want to do something as cumbersome as their own datastack on a small
8 bit micro is beyond me.

Ian

diggerdo wrote:

> 
> The 8051 has no banking to deal with either. Why do PICs STILL bank.
> The 8051 replaced the 8048 that had banking. A renovation that happened in
> 1985.

Actually, it was even earlier than that. The 8051 came out in 1980.

Ian

In article <1138901484.942189.106440@o13g2000cwo.googlegroups.com>,
zibidi <onurakdemir1@gmail.com> writes
>I want to implement OSEK API, so it is not problem for me if it is 8051
>or anything else. 

This is not the case. 


>I have started with 8051 than I can port it to any
>other proccesor even on an ARM, I just want to learn how can I
>implement an API from specification.

Then start with a more suitable MCU.... say something like an Infineon
166 Then when you have done that and you have some experience try
porting it back to a 8051 or AVR

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <43e32476$0$18465$e4fe514c@dreader32.news.xs4all.nl>, Frank
Bemelman <f.bemelmanq@xs4all.invalid.nl> writes
>"Grant Edwards" <grante@visi.com> schreef in bericht
>news:11u484anh5urm3b@corp.supernews.com...
>> On 2006-02-02, kobus <jacobuses@spoornet.co.za> wrote:
>>
>> > I've designed and used a minimal RTOS for the last 15 years I call it
>> > RTE51 (Real Time Executive). Because of the way that it is used, it is
>> > fairly immune to latch ups. It can execute up to 8 task preemptively
>>
>> "fairly immune to latch ups?"  That doesn't sound good.  I
>> would only use an RTOS that _never_ "latches up".
>
>I don't believe folks who say "never". In particular
>when they say "_never_". You can't even test for it,
>so how can you say that.
>
>Now let's see who responds first with that old line "how can
>you run a sattelite in orbit with that" etc.
>


In a VERY expensive test rig! I have seen some of what goes into testing
of a satellite..... They usually start buy testing the tools!!! Down to
the exact loading and propagation delays caused by a high end ICE and
the loading caused by a LA. 

Often testing is longer than the actual code and HW design and initial
production. 

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <43e2a3c6$0$8257$6d36acad@taz.nntpserver.com>, Rufus V. Smith
<nospam@nospam.com> writes
>>
>> If you're interested, I can e-mail the assembler code to you.
>>
>> Regards
>> Kobus
>>
>
>DCE51?
>
>This is the RTOS which was a successor and/or predecessor to DCX51 used by 
>Intel
>when they built industrial control boards?  Over BITBUS networks??
>
>DCX = Distributed Control Executive...
>
>I used  this in a former life...  When source code (and compilers) fit on a 
>floppy...
>
>Rufus

A Floppy what?  Is that some sort of CD or USB stick? :-)





Sorry I should know better. I was around when floppys were 8 inches 


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Grant Edwards" <grante@visi.com> schreef in bericht
news:11u484anh5urm3b@corp.supernews.com...
> On 2006-02-02, kobus <jacobuses@spoornet.co.za> wrote:
>
> > I've designed and used a minimal RTOS for the last 15 years I call it
> > RTE51 (Real Time Executive). Because of the way that it is used, it is
> > fairly immune to latch ups. It can execute up to 8 task preemptively
>
> "fairly immune to latch ups?"  That doesn't sound good.  I
> would only use an RTOS that _never_ "latches up".

I don't believe folks who say "never". In particular
when they say "_never_". You can't even test for it,
so how can you say that.

Now let's see who responds first with that old line "how can
you run a sattelite in orbit with that" etc.

-- 
Thanks, Frank.
(remove 'q' and '.invalid' when replying by email)

Grant

Ok - fairly - thousands of processors running for the last ten years
24/7 in railway signalling.

Kobus

"kobus" <jacobuses@spoornet.co.za> wrote in message 
news:1138866376.750604.324960@g14g2000cwa.googlegroups.com...
> Hi
>
> I've designed and used a minimal RTOS for the last 15 years I call it
> RTE51 (Real Time Executive). Because of the way that it is used, it is
> fairly immune to latch ups. It can execute up to 8 task preemptively
>
> . I use register bank 0 for all the tasks, this leaves the other
> register banks free for interrupts. This however means that I have to
> copy the contents of register bank 0 to xram during context switching.
> This adds some latency to the context switching but it saves a
> tremendous amount of stack space.
>
> I've originally used it with PL/M51 but changed it later to work with
> KEIL-C which I use extensively. A later change and experiment that I
> made was to add an additional layer that enabled me to put a task to
> sleep. These task can be woken after a certain time or after reception
> of a telegram.
>
> On the original version, once a task have been scheduled, it must
> execute till it is finished. Higher priority tasks can however preempt
> lower priority tasks which makes it preemptive.
>
> What might be of interest to you is how to get from an interrupt
> routine. As you know once you enter an interrupt routine on the 8051 a
> flag is set which prevents the 8051 from entering a same priority
> interrupt again. This flag is only reset once the iret instruction is
> executed but then control is passed back to the program from where it
> interrupted. With a RTE you would normally want to pass control to the
> executive after execution of an interrupt. The following snippet shows
> how to release the 8051 to again be able to interrupt while entering
> the scheduler and thus reducing latency:
>
> ;###################################################**
> ;*                                                   *
> ;*     Call here from 'c' interrupt routines         *
> ;*         in order to execute tasks                 *
> ;*                                                   *
> ;###################################################**
>
> RteIntExecC:
> mov r1,#2
> sjmp rie05
>
> ;###################################################**
> ;*                                                   *
> ;*     Call here from PL/M interrupt routines        *
> ;*         in order to execute tasks                 *
> ;*                                                   *
> ;###################################################**
> rte_int_exec_us1:
> rte_int_exec_us2:
> rte_int_exec_us3:
> mov r1,#4
> rie05: clr ea ;dissable interrupt
> mov a,sp ;remove redundant stack
> clr c
> subb a,r1
> mov sp,a
>  mov a,#low rie10 ;restore the interrupt priority
> push acc
> mov a,#high rie10
> push acc
> reti ;the interrupt is over
> rie10: clr c ;change to register bank 0
> mov psw.4,c
> mov psw.3,c
> sjmp r_e05 ;regular task scheduler
>
> ;#############################################**
> ;*                                             *
> ;*     Call here from task or background       *
> ;*                                             *
> ;#############################################**
> RteExec:
> rte_exec:
> push acc         ;save register PL/M style
> push b
> push dph
> push dpl
> push psw
>                clr ea ;dissable interrupt
>            .
>            .
> ; this is where teh scheduler starts
>
>
>
> If you're interested, I can e-mail the assembler code to you.
>
> Regards
> Kobus
>

DCE51?

This is the RTOS which was a successor and/or predecessor to DCX51 used by 
Intel
when they built industrial control boards?  Over BITBUS networks??

DCX = Distributed Control Executive...

I used  this in a former life...  When source code (and compilers) fit on a 
floppy...

Rufus