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
Please read the Keil C51 manual about the directives interrupt and using.
Hint: the 8051 has 4 core register banks at the base of data RAM.
"Does the last keyword "using 2" denote the polling priority of the interrupt?"
Read about interrupt priority on the so-called 8051 bible set: www.nxp.com/.../80C51_FAM_ARCH_1.pdf www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf
A last note: the interrupt priority is not decided by polling, but by a combinatorial priority encoder on the chip interrupt logic.
Johnny,
Not to be overly pedantic, since you clearly know your stuff, but the Intel MCS-51 manual always refers to the fixed priority-arrangement among interrupts that are enabled and whose IP registers settings match as a "polling" order.
The "bible" says something to the effect of the interrupt flags being latched on S5P2 of each machine cycle and then "polled" in a fixed order on the next to determine which interrupt is "accepted."
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?
Erik
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?
"ARM7 ... are actually cheaper than the 8051s"
You can't just say that without qualification!
I think you mean, "some ARM7s are actually cheaper than some 8051s."
Both ARM7 and 8051 cores are available in an extremely wide range of devices, and there is certainly an overlap between the lower range of ARMs and the higher range of 8051s...
In this case, I think the price doesn't matter, since we are talking about learning to program a microcontroller.
The '51 core has been available for quite a number of years now, but it will not disapear too soon, because of widespread use and gazillions of variants. Hence, it is a good processor for learning embedded programming. Especially since it very clearly shows the difference between embedded and workstation programming.
The '51 core has been available for quite a number of years now, but it will not disapear too soon, because of widespread use and gazillions of variants
true, AND a new derivative is introduced almost every day.
in addition to the 'processor only derivatives' all kinds of combos are coming out: BB (now TI) chose the '51 architecture when they came out with the first 24 bit a/d intefrated with a uC IR chose the '51 for their "integrated washer-dryer" power solutions Nordic chose the '51 for their UC radio con=mbination A?D has some '51 combos ..........
I do believe that every year since it's introduction (including 2006) more '51s have been used than the year before. It is a fact (that microchip obfusciates) that when you add all the brands of the '51 together it is the most used processor in the world.
I wrote: "ARM7 ... are actually cheaper than the 8051s"
Andy replied: "You can't just say that without qualification!"
In which he is correct.
The higher-end 8051s, like the 64Kb Flash devices, e.g., the P89C668 (recently discontinued), the RD2 and RE2 (an Atmel vaporware), overlap with many ARM7 families in price, like the LPC21xx and LPC23xx from Philips. The remarkable thing is that for US8.22 you get a LPC2368 with 72MIPS, 32bit core with full speed Ethernet, USB and CAN for less than a P89C668 and slightly more than a P89V664. But there are 8051s that cost around U$1.00, and there are also ARM7s that cost around U$1.50.
But I agree with all what was said about the relevance of mastering the 8051 core. Although it is one of the first uC cores still in action, it has an impressive number of derivatives, and if you want you can get a single-cycle 8051 that runs at 200MHz.
I agree with Erik that you must know the chip and the toolchain, and not use them outside their limits. For example, the classic '51 and all its C compilers are really bad at floating point and math-intensive apps, like filtering, but are very good at control apps and 8/16bit math.
I think that a systems designer must be knowledgeable in many platforms. The '51s have many hardware and software peculiarities, and you must know them. I like Microchip cores very much also, and have developed quite many systems for all PIC families. The ARM core implementations available are very interesting, and you should know them also, if you are serious about system development. Every architecture has its strong and weak points, and you must explore and apply the right mindset to each one. What is a completely prohibitive approach for one core is natural and fast for another.
I will answer Erik's point here.
I got these ideas from the software team who writes the software for the hardware we design.
In fact, I think i should give some picture on what all i have worked on till date.
My very first project was a test system development for testing the vehicle braking systems by generating various kinds of faults in it. So this system was basically introducing faults and also recording the results.
My second project was on PIC16F73. It was basically a re-engineering project where I redesigned a super regenerative receiver with a super heterodyne receiver. PIC was used as the micro in the receiver design along with Maxim's RF receiver chip. I was totally new to the embedded world and this was our company's very first radio design. There were challenges but I was able to finish of the project to its end.
My third project was a intelligent power management system for the vehicle. It was based on NEC V850 core. Although the design was pretty complex as it had many high current nets, still we managed to design and prototype it. I was not involved in the software part of it and testing because i was pulled into another design project.
My fourth project was a gateway module. We designed it on a HCS12X core. This design had challenges in terms of providing on-board diagnostics, protections and recovery for the in-vehicle networks and I/O channels. I was again not involved in the software design as they think I am a design engineer so I cannot write code.
I mean the hardware design work is cool but I need to know about the software too. I am not able to change my job because nobody wants hardware engineers today? My employer pays too less and we are just two of us in the company to do hardware design. We have to work 14-16 hours daily cuz there are no one else to do it. I have my family and I am not able to give them time.
Now, I had to think of a way to get out of this place. Just to meet the market needs and my needs I have to learn software part of it. This is what compelled me to start learning about the software in order to get a break for myself in the market today.
I know writing all these things here is a waste of your time and also my time. Anyways, back to topic.
Ya, I came across all this RTOS, drivers etc when my manager used to speak about all these in team meetings and I used to feel that I am nowhere in the world!
Apologies for wasting your precious time here.
So, I should take 8051 and understand its software architecture in C first.
I believe its not a big deal to work on any microcontroller based designs. Because, if you do one design from starting to end. Its just the same in all others. The only things that we should keep in mind are the design checklists. I mean, personally I think that given a concept, I can prototype it with the right choice of micro and it depends a lot on the requirements of the customer.
The datasheets and application notes give it all that is required to design. And the best part are the people like you who are ready to provide help on concepts online.
Thanks, thanks a lot for all your concepts and discussions in this thread that i posted. I wish I could meet such seasoned technical people like you and get some good tips for design. That would give me more confidence on myself.
Dear All,
If you do not mind then I would like to have your contact details, so that i can post my questions to you directly.
Jonny Doin Jason Daniel Per Westermark Andy Neil Erik Malund
Kindly provide me your details.
Best Regards, Mrunmoy.
I believe its not a big deal to work on any microcontroller based designs. Because, if you do one design from starting to end. Its just the same in all others what a load of CRAP.
If you are one of the best at the PIC and get thrown into a '51 design, your firts attempt will, at best, be mediocre. That said, there is nothing hindering that you can, eventually, become proficient in both.
I agree 100% to you Erik, that I should post all the technical questions here. Because even i got benefited by the answers that all of you have posted.
But, what i said was not crap. At least a seasoned person like you shouldn't be saying that. Pls. don't take it otherwise, i am not blaming anyone here.
If you can do one design well, even if it is a small one, you'd definitely do the big design well. I mean a microcontroller will always be a microcontroller no matter how many extra features it has. It all depends upon how well one has understood and comprehended that first design. We make mistakes but, these mistakes teach us good lessons.
After all, everything starts small and grows big. Don't you agree with that Erik?
"I should post all the technical questions here."
Actually, this forum should only be used for discussions specifically about Keil products - see: http://www.keil.com/forum/
For general discussions about the 8051/2 family, you could try: http://www.8052.com/forum
See also: http://www.keil.com/forum/otherforums.asp
If you can do one design well, even if it is a small one, you'd definitely do the big design well. and the moon is made of green cheese. That you get 'blinky' to work, by no means make you qualified for a big job.
I mean a microcontroller will always be a microcontroller no matter how many extra features it has. there is NO SUCH THING AS "A" microcontroller e.g. a PIC and a '51 are as different as ... no, a hundered times more different than an apple and an orange.
We make mistakes but, these mistakes teach us good lessons. correct
After all, everything starts small and grows big. usually.
Actually, this forum should only be used for discussions specifically about Keil products...
But a higher number of high-quality technical discussions that are handled on _this_ forum, will result in a correspondingly fewer number of people who will visit other forums where they may accidentaly get recommendations to look at products by IA<beep> or similar.
Strictly speaking, it would be advantageous for Keil to allow general-purpose embedded discussions, possibly allowing people to filter away these threads if not interested. The cust of running a forum is not proportional to volume of posts.
After all, everything starts small and grows big.
Like the list of open bugz in Bugzilla? :)
Jay Daniel said: "what separates truly great embedded systems designers from mediocre ones is their ability to think about hardware and software seamlessly."
That is quite true. Quite many control operations can be expressed as analog circuitry, digital circuitry, mixed electronics, pure software and mixed hardware/software. Knowing where to draw the interface line is a good design asset. Example: In a recent project a synthesized chopped stepper motor drive waveform started the design in pure software and eventually part of the chopping processing was moved to analog hardware to free up mcu core processing bandwidth and increase motor current ripple stability.
"Your hardware design background will be invaluable to you in your understanding of embedded software design."
I agree. I have found that it is harder for people that come from high-level software development to become proficient in embedded systems design than it is for hardware design engineers to become good at systems design. Nonetheless, you must not overlook a good base of software engineering, data structures, failsafe design, event-driven modeling, and control theory, just to name a few 'software' skills you need to master.
A few recommendations:
- Although embedded design can look like 'see one see all', mcu cores are widely different, and require quite different design approaches. Have this always in mind. Never try to port raw code, but port algorithms and knowledge instead. You cannot blindly apply specific techniques of one chip to another, but you can apply your systematic learning approach to every new technology.
- Always read ALL the chip datasheets, from start to end. The datasheet is your best friend, keep it at ARM's length;
- Get the silicon Errata for ALL the chips on your design. Every mcu chip has at least one Errata sheet. If you can't find it, be suspicious;
- Get to know your mcu core at an intimate level. Learn its assembly language. Learn how data is organized in its memory, the memory layout, special areas and rules. It *IS* important to know the chip at low-level, even if you will only program in C. Get to know, for example, how parameters are passed in functions, and write functions that make the best usage of the procedure call standard;
- Get to know the gory details of the interrupt processing of your chip and of your compiler, special function registers and peripheral setup and capabilities. At systems-level design, you must know what to expect from them.
- Get a deeper understanding of how your toolchain works. Study small sequences of compiled code at several optimization levels to get a grasp of what is the best style of C to generate the best machine code. Good developers write efficient C code because they know which style translates to lean machine code for the compiler/cpu at hand.
- Pay attention to your system architecture at the design stage. This is a hardware/software constraint. Try to secure good boundary conditions for your problem, and then take into account the combined hardware/software behavior, latencies and data path. A well-planned architecture will save you a life of maintenance and reimplementation in the future, not to say your job position.
Wonderful!
View all questions in Keil forum