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
Thanks a bunch to all you Masters...
My query is now answered. Kindly do not think that anyone is abusing the other. You all have been kind enough to post the answers.
Hats off to you guys.
A short intro of mine.
I am a embedded hardware design engineer for automotive electronics working at Infosys Technologies LTd, India. Working on electronics and circuit design, i wanted to try my hands on the software part of it.So I am trying my hands on Philips P89C51RD2BN uC on a evaluation board. Trying to learn each peripheral one by one. I have written a driver for the UART as of now. AM planning to write all drivers first and then write a mini RTOS for my kit.
If you GURUs can guide me in my voyage to master the art of programming the hardware. I would be realy grateful to you.
Best Regards, Mrunmoy.
"guide me in my voyage to master the art of programming"
Fundamental to this is a thorough reading of the Manuals for the tools, and the Datasheets for the devices. You cannot hope to get anywhere by skimping on these.
I have written a driver I hope this is language confusion. If you are working from a book that talks about 'device drivers' either switch to another processor or throw the book away.
however if what you mean is "I have succesfully done output and input" cudos to you
Erik
"AM planning to write ... a mini RTOS for my kit."
Writing an RTOS is not a project for a novice!
You need to develop your basic firmware skills before you start thinking about RTOS! :-0
"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.
"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?