I want to implement OSEK API, so it is not problem for me if it is 8051 or anything else. 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.
8051
Started by ●February 1, 2006
Reply by ●February 2, 20062006-02-02
Reply by ●February 2, 20062006-02-02
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...and there are others, that have an option of an extended stack pointer, that grows above the natural IDATA space. That does need care, as some code manipulates the stack using IDATA aliasing, and such extended stacks only work via the CALL, PUSH, POP. Some variants allow the whole data space to swap into XDATA space, which could provide some serious context switching :) -jg
Reply by ●February 2, 20062006-02-02
"Grant Edwards" <grante@visi.com> wrote in message 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".Just what I want, a pacemaker that is fairly immune to latching up.
Reply by ●February 2, 20062006-02-02
"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
Reply by ●February 3, 20062006-02-03
Grant Ok - fairly - thousands of processors running for the last ten years 24/7 in railway signalling. Kobus
Reply by ●February 3, 20062006-02-03
"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)
Reply by ●February 3, 20062006-02-03
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... > >RufusA 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 \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●February 3, 20062006-02-03
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 \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●February 3, 20062006-02-03
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 \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●February 3, 20062006-02-03
