Is each interrupt vector 2 bytes or 4 bytes in size on ATmega328P?

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

The data sheet says:

Each interrupt vector occupies two instruction words in Atmel ATmega328P.

Each word is 16 bites:

Most AVR® instructions have a single 16-bit word format.

 

So each vector should occupy 4 bytes, however the vector table on the same data sheet shows each program address offset is only 2 bytes ?

 

 

Using `avr-objdump` also shows 4 byte offsets for each vector:

Disassembly of section .text:

00000000 <__vectors>:

   0:    0c 94 34 00 jmp 0x68 ; 0x68 <__ctors_end>
   4:    0c 94 40 00 jmp 0x80 ; 0x80 <__vector_1>
   8:    0c 94 3e 00 jmp 0x7c ; 0x7c <__bad_interrupt>

So I'm not sure why the table in data sheet is showing 2 byte offsets instead of 4?

This topic has a solution.
Last Edited: Thu. Mar 31, 2022 - 11:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avruser1523 wrote:
So I'm not sure why the table in data sheet is showing 2 byte offsets instead of 4?

The Datasheet shows it as 2 "Words", not bytes.

 

FF = PI > S.E.T

 

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

however the vector table on the same data sheet shows each program address offset is only 2 bytes

Two locations, not two bytes.  Each location is 16 bits 

 

Note generically, locations (addresses) and amount stored there can be decoupled.

For example you could make some digital system having an address of only 1 byte width (total 256 different possible addresses) and each address contains 7 bytes of information to be retrieved.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Mar 31, 2022 - 08:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

The Datasheet shows it as 2 "Words", not bytes.

Isn't program address in bytes? i.e INT0 is at address `0x002` and INT1 at address `0x0004`, 4-2 = 2 byte offset.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel chose to use word addressing for its documentation (2 bytes = 1 word), but gcc is used on many mpu's, and uses a common byte addressing, so you always /2 to convert gcc addresses to atmel word addresses.

This is a common beginner confusion! 

 

Note the ATmega 48/88 vector table is one word(two bytes) per vector, while the 168/328 uses two words(four bytes) per vector

 

FF = PI > S.E.T

 

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

ki0bk wrote:

This is a common beginner confusion! 

Thanks but sounds like a horrible idea! almost every ISA I know uses simple byte addressing. Maybe they should change it if it confuses everyone. 

 

While we are at it I like to ask another question on this topic. Are instructions fetched in Little Endian order or 1 byte at a time like x86? if in LE order then how can the processor tell the length of an instruction (16 or 32 bits) to fetch/read (since the most significant byte ins't stored first), or is the LSB the indicator?

Last Edited: Thu. Mar 31, 2022 - 09:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how can the processor tell the length of an instruction 

I would presume the first 16 bits read will decode to tell whether another 16 are needed. 

 

Its very important the processor maintain lockstep so that a first part is always decoded as a first part and a second part used as a 2nd part...otherwise chaos!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Mar 31, 2022 - 09:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't program address in bytes?

In most of the gnu tools, the addresses will be specified in bytes.

In the data sheets, some Atmel SW, and the actual instructions, program memory is referenced by word.  (for example. you cannot JMP or RJMP to an odd (byte) program memory address, because the low-order bit just isn't there.  (This is also why the "easy" flash memory size is "up to 128k bytes", rather than just 64k.)

 

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


The next place you are going to be hit by this is in the positioning of code in bootloader sections. If I take an innocuous looking chip like ATmega16 which (clue in the name) is what mere mortals might call a "16K micro" then you might think it's address range was 0x0000 to 0x3FFF where the upper limit is the 16,384th byte in the device. As bootloader sections (in these older AVRs anyway) are positioned from the "top down" you might expect the positions to be something like 256 bytes, 512 bytes, 1024 bytes, 2048 bytes from the end of the device. So 0x4000 - 0x100, 0x4000 - 0x200, 0x4000 - 0x400 and 0x4000 - 0x800. That would be 0x3F00, 0x3E00, 0x3C00, 0x3800. Then you look at the datasheet and find:

 

 

so boundaries at 0x1F80, 0x1F00, 0x1E00 and 0x1C00 ??

 

This is, of course, because Atmel chose to write that table in terms of WORDS not BYTES. 2 x 1F80 is 3F00, 2 x 1F00 is 3E00 and so on.

 

Even more confusing is that if you are writing a bootloader and using avr-gcc tools then you need to move the base of the program to 3F00, 3E00 or whatever and you do that with:

-Wl,-section-start .text=3F00

or similar. But then you come to do that in Atmel/Microchip's IDE (Studio 7) and it has a section to configure things:

 

 

yet when you build that what actually happens is:

"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o newProject.elf  main.o   -Wl,-Map="newProject.map" -Wl,-u,vfprintf -Wl,--start-group -Wl,-lm -Wl,-lprintf_flt  -Wl,--end-group -mrelax -Wl,-section-start=.text=0x7e00  -mmcu=atmega2560 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\gcc\dev\atmega2560"  

WTAF? You told it 3E00 and yet it has doubled that to 7E00. That is because the number you put in the box must be an Atmel style WORD address. It does tell you this:

 

 

So in this Memory Settings dialog you actually have three boxes:

 

 

if you use the top one of the three the value must be given as a WORD address but if you use either of the other two it must be a byte address.

 

Exactly how confusing is that?!?

 

(the world would rotate much more smoothly if everyone using computers just decided that all addressing/sizes/etc would be in bytes)

 

(Oh and don't get me started about memory chips that are sold in terms of their bit size not their byte size - how many people have ordered a "64K" memory chip to find it only delivers 8KB of actual memory?)

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

avruser1523 wrote:
Thanks but sounds like a horrible idea! almost every ISA I know uses simple byte addressing. Maybe they should change it if it confuses everyone. 

Could the background be that there are also processors with 12-bit (1,5 bytes) instructions ? 

 

 

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

The interrupt vector table, which is found at the beginning of the flash memory, is four bytes per entry because each entry  is a two-byte JMP instruction followed by a two-byte address that it is jumping to.

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

Paddy72 wrote:
Could the background be that there are also processors with 12-bit (1,5 bytes) instructions ? 

Or 18-bit using two 9-bit bytes!   See PDP-10

 

avruser1523 wrote:
Are instructions fetched in Little Endian order or 1 byte at a time like x86?

Yes LE, no, all instruction fetches are 1 word at a time (16 bit) All op codes are 16 bit (1 word) or 32 bit (2 word), yet it is considered to be an 8 bit micro, confused?  

Welcome to AVR!

Once you figure out the opcodes are all 1 or 2 words in size, it begins to make sense, there is no need for byte addressing within the program memory space, and as it's Harvard Arch, there

are separate memory spaces for program and data, memory fetch size can be different between the various memory spaces....

 

Fly over Jim

See AVR Instruction Set manual for details

 

 

FF = PI > S.E.T

 

Last Edited: Fri. Apr 1, 2022 - 01:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Paddy72 wrote:
Could the background be that there are also processors with 12-bit (1,5 bytes) instructions ? 
Yes

PIC10F200/202/204/206 Data Sheet

[page 7]

 

"Dare to be naïve." - Buckminster Fuller

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

Note generically, locations (addresses) and amount stored there can be decoupled.

For example you could make some digital system having an address of only 1 byte width (total 256 different possible addresses) and each address contains 7 bytes of information to be retrieved.

This was my point a few comments back...an address is just saying where you will get the information (partitioning of storage)...how much is there could be any amount, depending upon the arrangement of memory resources.

 

You could have 2k different addresses of 64 bit words each.   Those 64 bit words could be opcodes (kinda wide!!), and maybe reserve 11 or 22 of those bits to reference the 2k address space (for opcodes needing to use addressing).   

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Simonetta wrote:
The interrupt vector table, which is found at the beginning of the flash memory, is four bytes per entry because each entry  is a two-byte JMP instruction followed by a two-byte address that it is jumping to.
Except when it isn't you mean? For example it is in mega168p/mega328p but it is not in mega48p and mega88p

Last Edited: Fri. Apr 1, 2022 - 02:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Or 18-bit using two 9-bit bytes!   See PDP-10

My CDC6400 COMPASS is way rusty, but conceptually not much different from AVR in terms of approach.  Word size wider, so there were 1/2/4 instructions per word versus the AVR's 1 or 2 words per instruction.  From Wikipedia:

Instructions were either 15 or 30 bits long, so there could be up to four instructions per 60-bit word. A 60-bit word could contain any combination of 15-bit and 30-bit instructions that fit within the word, but a 30-bit instruction could not wrap to the next word. The op codes were six bits long. The remainder of the instruction was either three three-bit register fields (two operands and one result), or two registers with an 18-bit immediate constant. All instructions were 'register to register'. For example, the following COMPASS (assembly language) code loads two values from memory, performs a 60-bit integer add, then stores the result: ...

avruser1523 wrote:
Thanks but sounds like a horrible idea! almost every ISA I know uses simple byte addressing. Maybe they should change it if it confuses everyone. 

Who exactly is "they", and what do you want "them" to change?  Give an example.  I'm sure that "they" would walk-back everything to the 1990's and change all of the documents relating to the invention of the AVR and change all the datasheets and go back even further and change the instruction set to give each instruction half the range (think about branch targets) so that you do not need to do any arithmetic.  While you are at it, I find IEEE 754 awfully confusing, as with the AVR an extra bit is forced/assumed for both exponent and mantissa.  Please have it changed.  From Wikipedia:

Further, the exponent is not represented directly, but a bias is added so that the smallest representable exponent is represented as 1, with 0 used for subnormal numbers. For numbers with an exponent in the normal range (the exponent field being neither all ones nor all zeros), the leading bit of the significand will always be 1. Consequently, a leading 1 can be implied rather than explicitly present in the memory encoding, and under the standard the explicitly represented part of the significand will lie between 0 and 1. This rule is called leading bit convention, implicit bit convention, or hidden bit convention. This rule allows the binary format to have an extra bit of precision. The leading bit convention cannot be used for the subnormal numbers as they have an exponent outside the normal exponent range and scale by the smallest represented exponent as used for the smallest normal numbers.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

yet it is considered to be an 8 bit micro, confused

Well the AVR fastest instructions handle 8 bits at a time, so whoop there it is. A few select operations work 16 bits, but take more cycles, so we remain silent about those.

The opcodes could be any width, though we usually try to make them memory-efficient so they fit in & access like a nice jig saw puzzle into common ram/ rom areas.  When each is its own memory preserve, there is more flexibility  

Some of the PICs, with separate data and program areas use those daggone 14 bit opcodes, but they get their own custom memory design to fit nicely into.  But they still work their data in 8 bit chunks.

 

Not that if you use external ram, you might swap address lines.  We had some system many years ago, where a few address lines needed swapped for some reason.  That meant if you wrote to locations 0 to 55, the actual ram locations were scrambled.  But reading unscrambled it, so no one was any the wiser.  If it was EPROM & you downloaded it, the straight line disassembly could be rather strange for any hackers!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!