We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
There is an application note on using the interrupt vectors in C51 c programming for 8051. It goes like this-
unsigned int int_count; unsigned char second;
void timer0 (void) interrupt 1 using 2 { if (++int_count == 4000) { /* count to 4000 */ second++; /* second counter */ int_count = 0; /* clear interrupt counter */ } }
Can anyone explain what does that "using 2" at the end of the function denote?
I understand that interrupt 1 specifies that this is the ISR for interrupt number for timer0 overflow at adress 000Bh. Does the last keyword "using 2" denote the polling priority of the interrupt?
TIA, Mrunmoy
"and then write a mini RTOS for my kit."
An RTOS for the 8051 is far from simple.
This is a recurrent theme for developers. It's a worthy one, but you should probably first acquire some background on realtime processing distribution theory.
The design task of distributing the processing units of a given system is not simple, and any architecture has its compromises. You have to put the compromises and limitations of your particular platform in perspective before blindly taking a design path.
Pseudo-multitasking is used in all serious realtime embedded systems, implemented in many forms. Amongst the many architectures, you can pick a cooperative multitasking approach versus a preemptive RTOS, or multithreading RTOS.
A cooperative multitasking system can be very easily produced, and depends only on the architecture of your single C program, not to mention that a well designed coop loop is always faster than any RTOS-based app.
An RTOS, on the other hand, must provide an individual runtime environment for each running thread. This involves a massive retargeting of the CLib routines, possibly a re-implementation of many of them, and a significant amount of context saving/restore for the thread context switch, not to mention that it requires significant amount of RAM only to maintain the state of each thread. A 'real' RTOS, even when based in a nanokernel, will eat a significant share of your available processing bandwidth, depending on the processor platform. IMHO, in the 8051 specifically, this amount is prohibitive. In my experience, I never used or saw a decent RTOS that was clearly superior to a well balanced mixed coop/interrupt approach for a real product.
An RTOS for the 8051 is far from simple. and the architecture of the '51 makes the overhead horrendous. The '51 probably is the single most awful choice for a multitasking OS.
you say you are a novice, did you get a book by some PCidiot "you must have device drivers, you must have an OS, you must screw up your system"?
DO NOT confuse small embedded with "PC programming"
Pseudo-multitasking a.k.a. the workloop, I hope.
Erik
"the architecture of the '51 makes the overhead horrendous. The '51 probably is the single most awful choice for a multitasking OS."
Agreed totally. Interestingly, the 'banked' core registers are described in the Intel original datasheets as to be designed for easy context switching for a multitasking system. Of course, it takes much more than a cpu context switch to do multitasking. One of the reasons why all '51 RTOSes suck is that the full context switch is sluggish when compared to the same '51 core running a light event-driven loop (or workloop, as Erik mentioned). And the memory overhead taken by the true-reentrant code needed by thread-safe library is absolutely prohibitive when compared to the heavily overlaid memory of a single thread system.
I wrote: "... I never used or saw a decent RTOS that was clearly superior to a well balanced mixed coop/interrupt approach for a real product"
That is, for a 8051 core. A small and fast nanokernel is a very good asset in many other processor cores. The ARM, for example, is designed specifically for RT kernel implementations, and actually is faster than the 80486 at the same core speed for task switching. Moreover, the RVCT compiler and libraries are designed for retargeting at the low level, offering the developer with a very simple way of implementing the thread static runtime space for the Clib.
There are many good RT kernels for the various ARM cores available.
I hope all this discussion doesn't discourage you from trying. But you should take Andy Neil and Erik advice, and get some good understanding of the chip and the architecture before going off the bounds of the compiler.
The '51 architecture, like any other, has its peculiarities, but is simple and if you master it you will have enough base to master other cores.
Thats exactly what i was thinking of. If i can master 8051, i can do it on any processor. Its just for my learning.
A note about the driver thing which i mentioned earlier:- I called it a driver and not an I/O cuz i thought thats the jargon commonly used by the technical guys. Thats in fact the jargon my manager uses. May be i am ignorant about it. Ya, I know that PC is much different from emb sys. The catch is, i have not coded for microcontrollers before. I have designed 8,16 and 32 bit micro based circuits but since i am in the hardware design team, i was never given a chance to code.
Since I had heard a lot of people in my team shouting the hell about microcontroller drivers and blah blah that they had written taking months to make it work, i thought of trying my hands on UART (RS232) of the PHilips P89C51RD2BN micro which i am using, and i wrote the so called "driver" in less than 3 hours and it is working cool.
This made me think that they are not doing a really big thing. Anyways, though the journey looks a long n winding road, still I think I should at least get a good grip on the starters before jumping into the main course :)
Thanks, Mrunmoy.
"I called it a driver and not an I/O cuz i thought thats the jargon commonly used by the technical guys."
A device driver implies the existence of an operating system, or at least the existence of a clearly defined software interface through which standardized commands are sent to some piece of external hardware.
Most deeply embedded systems do not have an operating system at all, not even a standard software interfacing concept to access hardware.
You said you are a hardware design engineer, with no software experience at all. Although there are many areas of expertise specific to software design, the foundations of embedded design are much closer to the hardware. You must always see the logic descritpion of the system before looking into the gory implementation details. For projects where you synthesize logic in FPGAs or ASICs, for example, it is common to design the system as a logic description and only decide which parts are to be implemented as hardware or software at a later stage.
One piece of advice: try to see the system as a single circuit, where all its details are important, from the CPU decoupling capacitors to the response latency of fast interrupts.
Code that places received data into a ring buffer, or sends data from a ring buffer can be seen as a device driver.
Code that increments a variable once/second can be seen as a RTC device driver.
Code that loads or saves a block of data to nonvolatile memory using whatever interface is needed can be seen as a device driver.
A lot of embedded programs makes use of a mapping layer, exporting a set of standardized commands.
True, but the thread is Cx51 and I hope that none does so with a '51 abusing the poor little chip.
True. I will probably never understand how the ugly little core have managed to stay alive for so many years. I hated the ancient thing 10-15 years ago and the only thing that has happened is that there seems to be billions of derivates available... I wouldn't be surprised if the normal car light bulbs starts to use embedded '51 cores.
The core really loves high-level languages with it's magnificent stack ;)
Guys,
I think I am lost in your high funda discussions :(
I mean you guys, might be having at least 10-15 years of experience and i am a kid in front of you. You guys are in best position to show me the way. Just show me the way, I'll walk through it.
Pls suggest where should i start then if not the 8051?
B.R, Mrunmoy.
I will probably never understand how the ugly little core have managed to stay alive for so many years.
ugly? "beauty is in the eye of the beholder".
The '51 is about as beautiful as any chip can be when used for its purpose try the interrupt latency on an ARM vs the interrupt latency on a '51 and your eyes may open.
Everyone that call any uC 'ugly' should examine their application vs the chosen chip.
No chip is 'beautiful' with the wrong app - or maybe the wrong programmer?
If you are going to produce in volume - or have very specific requiremens about power consumption, availability, support for magic function x, ... - you are seldom in a position to select a chip based on how funny and/or easy it is to program, or how efficiently it can handle an interrupt request.
Then you can be in a position that you really, truly dislike a specific processor, but you will still select it for a product, or someone may already have designed the hardware and request software for it.
Sometimes, a chip may be selected just because someone thinks that they own a compiler for it.
I have worked with projects where the HW designer selected the uC because he happened to have made a construction with the same chip 5 years earlier - ignoring end-of-life, price, and need for external chips because of lack of built-in devices.
Nothing is as funny as developing for a brand new chip that has so favourable price that it is selected on the speculation that the chip manufacturer _may_ be able to follow their projected release plan.
If the chip is then suddenly delayed with 6 months, or the manufacturer reports that they can only deliver 1k instead of 10k chips, I can promise that you will consider the panic replacement chip an ugly *** when you try to port the source in a frenzy.
"Pls suggest where should i start then if not the 8051?"
The 8051 core is as good a starter point as any. It is a 'old' Intel core, with several shortcomings, but has many interesting features also. You get hardware multiply and divide, something you will not find im many 8-bit cores. You also have the bit-manipulation instructions, for example.
If your aim is learning about microcontroller structure and embedded design, it will be worth the effort. Moreover, there are millions of 8051 variants, so you may actually get to use the knowledge. Besides, every core has its idiosyncrasies, and you must get used to quickly learn about them.
If you want to begin with something 'newer', you may try to start with an ARM7 core. They are actually cheaper than the 8051s, and are in another league, with 32bits and extremely optimized instructions.
Pls suggest where should i start then if not the 8051?"
I do not think anyone have suggested you start anywhere else.
What has been pointed out is that the '51 should be treated as a '51, not as some RTOS base. the '51 ia a great chip wben used as intended.
Would you drive a Porsche like a tractor?, would you drive a Tractor like a Porsche?
It really puzzles me that a hardware guy even would think about a RTOS, drivers, whatever in that league, could you enlighten us as to where you got those ideas from?