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
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?
Erik
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.
if you "work 14-16 hours daily", then how come "nobody wants hardware engineers". it sounds to me like your boss need to hire more of them.
That said, the real champs of small micro design know both HW and SW, so a dual capability is definitely an advantage.
PS stop the cuzzing, it is VERY annoying
Mrunmoy,
I think you've got a pretty good "mission" here. My personal opinion (and I'm fairly certain that everyone on here will agree) is that what separates truly great embedded systems designers from mediocre ones is their ability to think about hardware and software seamlessly. In organizations like yours where one process is divorced from the other, projects often become less-than-optimal and far more difficult.
Your hardware design background will be invaluable to you in your understanding of embedded software design. Hopefully, when you come out of this, you'll find that your productivity (even in software) is greater than that of an experienced person who's never taken the time to fully understand both sides of embedded design.
-Jay Daniel