Interrupt Vector table

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,
what is the use for interrupt vector table?

different ways of handling interrupts?
please explain these to me......

thanks,
prabu

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Each interrupt has to have it's own handler routine, for example the USART TXC has to have it's own IF USED or a timer must have it's own when used. When an event happens, the processor drops whatever it is doing and will go and service that event. If a character has been send out and there is no other data buffered, then the TXC interrupt will be set and the processor will get the address of the service routine from the TXC vector etc. ie

Quote:
0x0040 jmp USART1_TXC ; USART1 TX Complete Handler

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now I'm really confused. In one post you are asking about a concept as complicated as callback functions in RTOS and in the next you are asking about something as basic as vector tables.

Are you just picking questions out of a bag or something?

I'd like to help and went to some length to post replies to your other threads but I'm not sure what it is you are trying to achieve here (a degree in computing science perhaps?)

Do you have an actual AVR application you are trying to design? If so what is it? This will determine whether (a) you need to be worried about RTOS' at all, (b) whether you need to be worried about interrupts or (c) whether it can just be a simple app using none of these.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My suspicion is that these are questions on a school home assignment. If that is the case and the teacher is just fairly smart, he will not only collect the finished assignment but also run a very short (5 min) interview with the student, asking a few "Tell me a little more about how you reasoned around teh problem of vector tables", or showing a piece of code and asking "would you call this an example of using a callback function".

So we can just go on and answer the questions, as long as we do not provide a ready-to-type-into-an-assignment answer.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Now I'm really confused. In one post you are asking about a concept as complicated as callback functions in RTOS and in the next you are asking about something as basic as vector tables.

Are you just picking questions out of a bag or something?

I'd like to help and went to some length to post replies to your other threads but I'm not sure what it is you are trying to achieve here (a degree in computing science perhaps?)

Do you have an actual AVR application you are trying to design? If so what is it? This will determine whether (a) you need to be worried about RTOS' at all, (b) whether you need to be worried about interrupts or (c) whether it can just be a simple app using none of these.

first of all i really thanks to personalities like you.ya this forums is helped lot for my previous(energy meter) project.and i learned many things about micro controllers on this forum only

i had developed energy meter application using ATmega 168.for this i had not used any RTOS.

now we are designing a intelligent power management unit in Aerospace for that we are using 2 micro controllers."Intelligent Power Management Unit Controller (IPMUC) for the continuous operation in Unmanned Air Vehicle where flight durations would range from 15 – 20 hrs. The system includes aspects of control and monitoring for power management. The system must be reliable and perform the functions of the electrical power supply bus management while monitoring the power supply system. It aims at providing the solution to cater the above said function while maintaining the redundancy through out the system."

for this application should we use RTOS?

on interrupt vectors, i know little bit about interrupt vector tables.
Is there any other efficient way to handle interrupts other than that interrupt vector table?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are actually designing an unmanned flying vehicle, and are asking thing like "should we use a RTOS or interrupt vectors"? Now I'm really hoping that this is a school assignment.

If I'm wrong: Please don't fly that thing anywhere near me...

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> If I'm wrong: Please don't fly that thing anywhere near me...

Chances are probably good it will crash halfways between India and Sweden.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow a UAV - that is one hell of a step up in project complexity. I'd have said that if you don't already know the answer to the "should we use an RTOS?" question then you aren't ready to undertake such a complex project. You are going to face many many technical hurdles and the last thing you want is to add hurdles such as not understanding the basics of computer science!

Having said all that I'm not sure what the answer to the RTOS question is. There comes a point in system complexity (maybe at the 64K->128K code size boundary?) where the chances are that things have got so complex that just a main loop and a bunch of ISRs aren't sufficient to handle the complexity of all the processes that are going on in a system but, while an RTOS can help it will bring it's own complexities. You stop thinking in terms of "flags set in ISRs" and start thinking in terms of "blocking on semaphore acquistion" and so on. You probably also need to start considering inter-process communication using queues and named pipes and so on. So while the RTOS will help to a certain extent it will hinder to another (apart from anything else the RTOS itself if just "one more thing to go wrong")

Like I say, a tricky decision to make - I'd probably be erring on the side of "yes" perhaps - but only with a few years of programming and computer science experience in the bag.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hell, forget the RTOS question.

If the UAV isn't made out of balsa wood or styrofoam, you should be looking at coding the firmware in Ada for safety-critical stuff.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could, but even writing software in C with some assembler can fulfill DO-178B Level A (a failure would be catastrophic). Avionics software is specified, documented and tested to death which makes me think Prabu isn't working on a commercial product, or at least one that will be certified.

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

prabu wrote:
now we are designing a intelligent power management unit in Aerospace for that we are using 2 micro controllers."Intelligent Power Management Unit Controller (IPMUC) for the continuous operation in Unmanned Air Vehicle where flight durations would range from 15 – 20 hrs.

Uh, Ha!!! Did you know that I single-handedly solved the age old mystery of perpetual energy?

I'll explain the whole process to you, when you get your first 20 hours of flight time in...

And, what's this one controller redundancy thing? That can't possibly happen.

Remember... "Redundancy" and "Fail-Safe", while losely related, are not the same thing. You can take measures to be "Fail-Safe" using a single controller but, "Redundancy" only comes with duplication of the control system or, at least certian aspects of it, using multiple controllers. I have heard that NASA likes to use groups of at least three controllers for their redundancy measures.

Now, if there is a knowledge gap pertaining to intrrupts and, if there is a knowledge gap pertaining to RTOs, how do we make the giant leap from intrrupts & RTOs, to redundancy and UAVs holding 20 hours of flight time per session?

I guess a good test of this is to do some simple stuff and determine the reliability of your hardware and code design.

Can you reliably communitate using RS232? Can you make an LCD display text? Can you drive a small DC motor using PWM? Can you capture various analog signals and scale them, display them, and use them to hold some device in a stable position?

Can you launch a model rocket (being that it is only a 10 to 15 second flight time) and capture atmospheric data reliably?

And, we'll be doing what during this 20 hour flight time? Was that managing power? How much power? How heavy is this UAV going to be?

Are there any plans, drawing, etc... for this UAV?

What is the operating budget? Hell, I can bearly muster $50.00 to $100.00 at any given time to design and build simple projects.

What is the game-plan?

What are the details?

Oh! And too, who gets to write the test proceidures and test code to check the viability of the "Redundancy" and "Fail-Safe" mechanizms?

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

If the UAV isn't made out of balsa wood or styrofoam, you should be looking at coding the firmware in Ada for safety-critical stuff.

I never quite understood that. What is it about ADA that makes it more "safe" than any other language? It all compiles down to AVR assembly, in any case. I would have thought that the reliability of the system comes from the competency of the programmer rather than the language it's programmed in.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

C is a rather liberal language when it comes to doing whatever you want with it. It is one of the things that make it such a powerful language. But because of this, it will let you get into a whole lot of trouble. You can, as you know, take a float value and tell the compiler to treat it as a 32 bit integer, two 16 bit integers, or 4 8 bit integers. The compiler trusts you to know what you are doing, even though what you are doing might actually be total nonsense. Other languages won't let you do such things and will complain bitterly. I have never used ADA, so I can't say exactly what it is about that language that makes it good for one purpose or another, but I am certain that it is constraints within the language that is a big part of it.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wikipedia wrote:
Notable features of Ada include: strong typing, modularity mechanisms (packages), run-time checking, parallel processing (tasks), exception handling, and generics.
[...]
Ada supports run-time checks in order to protect against access to unallocated memory, buffer overflow errors, off by one errors, array access errors, and other avoidable bugs.
[...]
It also includes facilities to help program verification.

Dean wrote:

I would have thought that the reliability of the system comes from the competency of the programmer rather than the language it's programmed in.

Why does one have to exclude the other, Dean?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Back to the earlier question....

Basicaly, you have no choice about using interrupt vectors IF you use interrupts. The MCU is designed, by internal state coding, to jump to the vector location associated with the specific interrupt. Again, you have no choice if you use interrupts!

However, if you do NOT enable the interrupts and simply poll status bits (inside something like an RTOS), you can get interrupt-like action. The down-side is much greater latancy and much more time resolving "simultaneous" events. Simultaneous events are prioritized in hardware and there is no way you can beat that, speedwise, in software.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net