I have to make an rtos for 8051.
1.what are the functions performed by bootloader during startup of the chip? if i can execute a program on my chip stored at any location in memory then what do i mean by making a separate OS for 8051?
please help me..
regards, M.Stephen Selvaraj
"I have to make an rtos for 8051."
Why do you have to?
DO you mean that you have carefully considered the options, and an RTOS is the only way to go?
Or have you been set an assignment, "make an rtos for 8051"?
Or what?
In general, applications that are suitable for implementation on an 8051 do not need an RTOS.
Even if your application does need an RTOS, why do you need to make it?
Desigining and implementing an RTOS is certainly not a trivial task - so, if you need to ask the question, you are probably not ready to start making you own. Have you looked at http://www.keil.com/c51/rtx51/ ? Other products are also available...
"1. what are the functions performed by bootloader"
This has nothing specifically to do with an RTOS. Many systems that don't have an RTOS do use a bootloader for loading code... What preliminary research have you done to answer this question?
"what do i mean by making a separate OS for 8051?"
Nobody can look inside your mind to tell what you mean...
"the Core2Duo/Vista combination, which will do stuff "right now" most of the time, but be busy with doing Windows Vista-related things occasionally."
I think you typed that slightly wrong?
Didn't you mean:
"the Core2Duo/Vista combination, which will do Windows Vista-related things "right now" most of the time, but be busy with doing reall stuff occasionally"
;-)
"thats why i call mine 'rapid time oparating system', it is quick but not instentanious"
Which is no more help than calling it "Real Time", is it?
"Rapid" is no more nor less specific than "Real Time", and just adds unnecessarily to the confusion by bringing a different name to the same concept!
"Rapid" in some systems will mean seconds; in others, it will mean nanoseconds.
no,,, real implies the poserbilty of immediate. Rapid implies quick (eg. not immidiate.) i use a better describing name of what the sw does. Rapid is more descriptave for the use bcoz it implies reletive time.
anyways,,, it do to me ;)-
No, it merely means that you didn't read the documentation of your RTOS/uC - you should have made sure that the guaranteed response time is actually less than minimum response time required by your application. I did read and found none. that had a "guaranteed response time" better than "minimum response time required". There is a limit to what a '51 (even a f120) can do in 200nS. I guess that with a Pentium (where using an OS would be appropiate) running at a few GHz it could be done.
Or you can switch to the Core2Duo/Vista combination, which will do stuff "right now" most of the time, but be busy with doing Windows Vista-related things occasionally.
the very recipe for creating intermittent problems.
Erik
The Real Time part is that the OS is deterministic.
The threads that have hard requirements are guaranteed to be started fast enough to never miss an event.
In some situations, the requirement is in ns - which means we need dedicated hardware.
In some situations, it is in us, which mean we can use the highest prioritized interrupt, as long as we know that the longest time interrupts are disabled + the response time of the most prioritized interrupt handler is less than our requirement.
In some situations the requirement is in ms, so we can use threads with high priority and let the OS switch in the task based on the trigger event.
The Real Time part is that the system can always manage the requirement. Or - in some situations - it may be accepted that it sometimes fails, as long as the system always knows when it has failed and can guarantee that it can perform an alternative (such as a corrective action) within a guaranteed time.
In the end, an RTOS doesn't need to be fast. It just has to prommise a max response time. The advantage of a fast RTOS is that a slower (cheaper and/or less power-consuming) processor may be used for a specific timing requirement.
The little '51 do have an advantage that it can swap register sets. The mighty x86 may run at crazy clock frequencies but isn't optimized for quick interrupt handlers. Admittedly, some of it has been fixed by the virtualization of registers and micro instructions.
I did read and found none.
In that case, you can either roll your own RTOS (if you think you can do better than what's available on the market), pick one that lets you take care of some of the ISRs and run them without any OS overhead (usually possible as long as you don't call any of the RTOS system functions inside the ISR), skip the RTOS altogether, or pick a piece of hardware that takes some of the load off the CPU so it doesn't need to react every time it receives a handful of bits.
Of course, these options differ in development time and cost per unit.
...you can either roll your own RTOS...
or you can ask me for a copy of my rapid time opareting system.
go on.... you know your wanting it ;)
In some situations, the requirement is in ns - which means we need dedicated hardware. ---- In that case, you can either roll your own RTOS ---- or you can ask me for a copy of my rapid time opareting system.
WHY ON EARTH????
or you can ask me for a copy of my rapid time opareting system. sure, if it can handle a 100ns task period.
PS I am not a RTOS hater, I use them on more capable processors, but the hops, skips and jumps taken by those that make OS for the '51 is nothing but trying to fit a square peg in a round hole.
sure, if it can handle a 100ns task period.
it can do.... but youve got to use a 8051 microprocessor core running at more than 1500MHz
thats a meaty chip ;)
How much more than 1.5GHz?
1.5GHz only informs us what the clock cycle time is. It still doesn't say anything about now many clock cycles a single instruction takes, or how many clock cycles that are needed to detect that a task switch is needed and then manage to perform that switch.
Do you detect and switch in 150 clock cycles? And normally, the real-time requirement is that the task must have responded within the stipulated time, so the task may need a couple of clock cycles too...
BULL!!!
the correct statement would be "it can NOT do since no 8051 microprocessor core running at more than 1500MHz exist".
I repeat a RTOS for the '51 is trying to for a square peg in a round hole
"a RTOS for the '51 is trying to for a square peg in a round hole"
With powerful chips like the big SiLabs ones, and especially the extended ones like Dallas with >>64K linear code space, there most certainly are applications where an 8051-derivative could be used and an RTOS could be appropriate.
Sure, these are at the "high end", and I stand by my earlier assertion that, In general, applications that are suitable for implementation on an 8051 do not need an RTOS - but that is quite a bit different from just calling it unqualified BULL...
"or you can ask me for a copy of my rapid time opareting system."
You originally promised to just post it without the need for anyone to ask - so where is it...?
This is a side issue, but I really don't buy this comment: the correct statement would be "it can NOT do since no 8051 microprocessor core running at more than 1500MHz exist".
Both Intel and AMD are processing more than one instruction/clock cycle at higher frequencies. And the x86 instructions are not easier to process than the '51 instructions. With duplication of the tiny execution units, such a processor could use speculative evaluation to avoid stalls on misspredicted branches.
The problem is not if a GHz '51 core can be made - the problem is that the I/O pins would not work too well at 5V or 3.3V logic with such frequencies.
To make it worth the investment, and at the same practical, the core would have to be integrated into an application chip, allowing it to run all I/O at 1.2 to 1.8V. With 5V outputs supporting several mA each and full speed toggling, the chip would probably start to glow if put in a tight loop toggling all pins.
the original statement: it can do.... but youve got to use a 8051 microprocessor core running at more than 1500MHz
Andy Neil Posted
I stand by my earlier assertion that, In general, applications that are suitable for implementation on an 8051 do not need an RTOS - but that is quite a bit different from just calling it unqualified BULL...
I stand by my statement, stating that something "can do" something if a nonexisting device were available, is BULL. If something requires something nonexisting to do somathing it can NOT do it.
The qualified 'BULL' referred to that specific phrase.
As a software developer, you should notice that the "You can do xx if yy..." in a previous post is a valid sentence, and not automatically bull because of the lack of existing 1.5GHz '51 processors. That's the nice thing about qualified conditionals :)
If the sentence had said "You can do xx [now]" it would have been bull unless such a core had existed.
The question here is if 1.5GHz is enough or how much "more than 1500MHz" that would be required.
The question here is if 1.5GHz is enough or how much "more than 1500MHz" that would be required just for ease let us make the orignal statement 1.2Ghz making the instruction cycle frequency 100MHZ ~10nS. That would give (for a 100ns task switch) 10 instruction cucles to save the stack in XRAM, restore the new tasks stack, switch task etc. Evwn with a one clocker (120 instruction cycles) I doubt very much it could be done.
so my estimate
a whole lot more
Maybe the guy pushing his real (sorry, rapid) time operating system is expecting us to emulate an 8051 running at 1500MHz on a PC quad core running at 4MHz or more?
PC quad core running at 4MHz...
Whoops, I think I should have typed 4GHz!
I was thinking about the new hip trend in embedded systems: Z80Quad :)
View all questions in Keil forum