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
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.
Erik
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!