Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
04/07/11 05:16
Modified:
  04/07/11 05:19

Read: times


 
#181757 - There are many ways to skin the proverbial cat ...
Responding to: ???'s previous message
Per Westermark said:
The name vector table is normally used both for processors that have a table of addresses and processors that jumps to the addresses and expects to find the first instruction there.

I see a more significant distinction between processor units that jump to a predefined start address expecting to find an instruction there, and those that seek a vector as part of an executing instruction at a predefined address. I used the 6502 as an example only because I found it easy to remember and explain. At 0xFFFC, it expected to find the 16-bit address of the first instruction to be executed after RESET. That's the RESET vector. At 0xFFFA, it expected to find an interrupt vector which represented the first instruction to be executed when a specific interrupt occurred, and at 0xFFFE, it expected to find the 16-bit address of another interrupt routine. I don't recall which was the for NMI (non-maskable interrupt) and which was for the maskable IRQ. This is really quite different from what goes on in a standard (Intel-style) 805x, as if nothing is found there aside from zeroes, as will occur with many programmers, then the MCU will keep executing those NOP's until it encounters something it know how to interpret, however wrong that may be. If the data is random, well, it's not predictable, without more information, just exactly what the MCU will do. Some processors of old, e.g. i8080, expected to find an instruction in one predefined place, but expected to find a vector in another when an interrupt occurred, IIRC. As Andy has pointed, all bets are off when one is using one of the more modern MCU's, in which cases one might have to turn off things like watchdogs, or other interrupts, etc, in order to avoid undesired events.

In THIS case, however, I believe the O/P's actions was presumable correct, though he's apparently discovered that he made a serious hardware configuration error.

In my book, I see it as a vector table even when the processor reserves a significant amount of space for each interrupt - some chips may have 128 bytes separation between each interrupt target address, allowing smaller ISR to be stored completely inside this space and remove one extra jump.


I have to agree that it's interesting to consider placing an entire ISR in the space available in an interrupt vector table, and there's probably room for debate about which approach is "better". The space in the 805x isn't very generous, though having a larger space might not have proven particularly efficient in the days of 1-kByte EPROMs. The use of a fixed vector address rather than a whole jump instruction might be preferable in a situation in which there are lots of interrupts, often not the case with 805x. Some microprocessor cores even allowed the interrupting peripheral to assert a vector on interrupt acknowledge ... maybe that's the ticket?

RE



List of 15 messages in thread
TopicAuthorDate
My port does not do as my program            01/01/70 00:00      
   Tested...            01/01/70 00:00      
      Details of components            01/01/70 00:00      
         How a microprocessor/microcontroller starts...            01/01/70 00:00      
      Just a minute ...            01/01/70 00:00      
         Vectors            01/01/70 00:00      
            Difference between 8051 "Vectors" and ARM "Vectors"            01/01/70 00:00      
               All in a name            01/01/70 00:00      
                  Sort of            01/01/70 00:00      
         Vectors            01/01/70 00:00      
            There are many ways to skin the proverbial cat ...            01/01/70 00:00      
               placing an entire ISR in the space available            01/01/70 00:00      
         vectors and vectors            01/01/70 00:00      
         Startup            01/01/70 00:00      
   Found the problem !!!            01/01/70 00:00      

Back to Subject List