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
The expression "real time" as in RTOS basically means "determinable time". The phrase "real time" by Websters definition basically means "NOW".
For that reason, in computing, if you say 'real time' and do not specify which definition you refer to, it can mean anything.
If you have bits coming down a pipe at multiMegaHertz speed, "real time" an the RTOS meaning will leave you wanting.
I, personally, believe that the language should be interpreted according to Webster, and not according to what somebody wants it to mean.
Erik
The phrase "real time" by Websters definition basically means "NOW".
yes,,,thats why i call mine 'rapid time oparating system', it is quick but not instentanious. microprocessors are clocked and any action has to wait for next clock cicle. it cannot do stuff immideataly.
it cannot do stuff immideataly.
At the most basic level, no practical system can do anything immediately, since the speed at which information propagates is limited by c.
For any real system, however, having a delay that is a negligible fraction of the smallest time constant of the system does not violate the criterion for real-time.
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.
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 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.
the very recipe for creating intermittent problems.
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