Datasheet: What is the implied unit of 0x02?

Go To Last Post
69 posts / 0 new

Pages

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

Even though the reti seemed to be also missing with AS4.18 it is now listed both for the 817 and 1617 versions.

 

T817 with rjmp

 

 

T1617 with jmp

 

 

This exercise has cleared up my misunderstanding of the wraparound issue, thank you.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I guess that a part of the confusion is the 817 has the CALL and JMP instruction, but there are no real need for them.

 

It's like it has the LPM instruction, which also is no need for any more.

 

My guess is that it is a part of the "packet" from the XMEGA

 

And as a part of that it's the only tiny/mega that can't address registers :(    (a real pain for my code, but that is for an other thread)   

Last Edited: Fri. May 26, 2017 - 07:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

je_ruud wrote:
The migration diagram do have a point, but the text might be misleading/doesn't tell the whole truth.

 

The wording is not "migration". If it's not about binary compatibility, the documents should make that clear.

 

A typical use-case for binary compatibility is this:

 

You want to distribute some binary code, say as .bin, .ihex or statically linked .elf, and users can upload and run the code no matter whether they use ATtiny417 or ATtiny817.  The users don't need any development tools or knowledge, except how to upload the binary to their device. No need for assembler or compiler, no sources available.

 

Hence, the author of the code has to cater for that situation by writing code in a spacial way, namely in such a way that it does not matter on which platform the code will end up (you'll have to specify a set of valid targets, of course).

 

For example, this means you have to avoid RJMP / RCALL except you know that no wrap-around will occur, for any device that's opt to be targeted, same for any other feature.

 

In the RJMP / RCALL case, and when using avr-gcc, you'd say -mno-pmem-wrap-around.  For devices > 8KiB, the compiler will generate jump-tables and all as expected, even together with -mrelax.   For devices <= 8KiB, the code asserts to run on 4 KiB devices AND 8 KiB devices, hence code size <= 4 KiB, hence all of code can be targeted by RJMP / RCALL *without* need of wrap-around.

 

Actually, the specification of same vector size for ATtiny417 and ATtiny1617, plus the assertion of code compatibility between ATtiny417 and ATtiny 1617, lead me to the wrong concluson that ISR entries on either device were 2 WORDS...

 

But it's not one class of potential comatible devices in that case, it splits into two at least: Devices <= 8 KiB and decices > 8 KiB.

 

The different start of RAM is yet another issue to take care of: 256 B RAM devices start it at 3f00, 512 B RAM devices start it at 3e00, 2KiB devices (provided they exist) start at 3f80.  Hence, to achieve compatibility, RAM start has to be set to 3e80, End of RAM is 4000.  Maybe the small 256 B devices are just morroring their RAM and repeat it every 0x100 bytes (existing specs files allowed that interpretation) so that there's some more flexibility.

 

avrfreaks does not support Opera. Profile inactive.

Last Edited: Fri. May 26, 2017 - 10:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

the 817 has the CALL and JMP instruction,

I don't think they work with the 817, I had to provide 2 versions of the line (see AS4.18 list files above)

 rjmp    button_released

 in order to assemble for the 1617 or 817

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

If you have code that is above 8K then the rjmp or rcall will follow the 2K words rule, if you move a routine outside the 2K range then you must use jmp or call, anything staying below 8K should still wraparound.

 

Or am I going senile?? (in case there was any doubt....)

There seems to be some confusion on this point, addressed as an OT in this thread:

https://www.avrfreaks.net/forum/assembly-interrupt-vectors-vs-datasheet-interrupt-vector

... starting around #7.

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

They say a picture is worth a thousand words. So I made one, showing why there are addresses that can be reached by rjmp in the 8k device but not in the 16k, thanks to wraparound. In an 8k device, all program memory can be reached by rjmp, but this requires wraparound. In a 4k device (not shown) rjmp can reach any memory with or without wraparound (there are two optional encodings for every rjmp).

 

And so it just occurred to me that on an attiny with just 1kB flash, each rjmp can have 8 (I think) possible encodings (multiple wraparound).

 

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

And so it just occurred to me that on an attiny with just 1kB flash, each rjmp can have 8 (I think) possible encodings (multiple wraparound).

Conceptually, perhaps.  However in reality there is really only 1 'wraparound' which would occur, since the PC will only be as wide as is necessary to reach flash, and the 12-bit rjmp/rcall operand will be truncated to that width.  For a 1KB device, that's 9 bits (512 words), so the top 3 bits of the operand are truncated.

 

For devices with > 8KB, the operand is sign-extended to the width of the PC.  13 bits for 16 KB devices, 14 bits for 32KB devices, etc.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

El Tangas wrote:

They say a picture is worth a thousand words. So I made one, showing why there are addresses that can be reached by rjmp in the 8k device but not in the 16k, thanks to wraparound.

 

Nice graphics! I just want to add.

There are also addresses that can be reached in the 16k device but not by the 8k device.

Since rjmp (and rcall) spans 8k no matter where the instruction is located in memory means it covers the same amount memory on both devices.

 

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

And perhaps the table is correct, it's still undefined to wraparound on chips bigger than 8K (I will really like to see a place where Atmel say it's ok).

 

And 2. which tool compiler or assembler would use/accept it ?  (all tools I have used will say "out of reach" or something like that)

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

Since rjmp (and rcall) spans 8k no matter where the instruction is located in memory means it covers the same amount memory on both devices.

Except that for 8K devices there is no error if the rjmp/rcall is say, 6K (bytes) away, thanks to wraparound. But if you try the same thing on a 16K device then you get an out of range error (as they only cover 4K bytes (2k words) back or forward)  and that's what the code provided by el tangas makes apparent when you assemble the code.

 

I was under the same misunderstanding as I pointed out in my earlier post...hmmm I must have never had any code larger then 8k in ASM projects. cheeky

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I understand on the 8k memory devices it works out that way due to the 8k rjmp/rcall limit just happens to match the 8k device memory.

My point is that rjmp/rcall covers 16k devices as well with an 8k range, the instruction can be located anywhere in the 16k, even at the top of 16k memory.

There was some confusion in this thread or another that seemed to indicate that rjmp/rcall must be used at memory locations below 8k. Which is not true.

 

 

 

 

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

And perhaps the table is correct, it's still undefined to wraparound on chips bigger than 8K (I will really like to see a place where Atmel say it's ok).

This is enough:

 

 

If the PC is only wide enough to address available flash, then it cannot ever attain a value that points to non-existent flash.  Two's complement arithmetic with the (sign-extended) rjmp/rcall address operand assures a defined result.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Then I guess we just need some tools that use this feature!

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

Quote:
which tool compiler or assembler would use/accept it ? (all tools I have used will say "out of reach" or something like that)

GNU Tools support it — cum granum salis.

 

Just write CALL / JMP and let the linker relaxation machinery do the job:  Compile / link with -mrelax and -mpmem-wrap-around.  Older avr-gcc versions don't have exact knowledge of all devices' flash size, and AFAIR the respective spec just skips -mpmem-wrap-around.  If that is the case, you have to feed the flash size into the linker, e.g. -Wl,--pmem-wrap-around=32k for a 32 KiB program memory device.
 

avrfreaks does not support Opera. Profile inactive.

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

In the other recent thread where wraparound was discussed, I posted a test program. I didn't knew about -mrelax and -mpmem-wrap-around, so I hardcoded the wraparound jump.

But now I tested with these options and they work fine, thanks. They automagically converted all jmps and calls to rjmp and rcall whenever possible, even in assembly code.

So in my test program, I could replace the hardcoded wraparound line

    rjmp     0x4000 + m1

by

    jmp     m1

Moreover, the C startup code was also converted, saving some extra bytes. Also, a couple Arduino sketches I tested shrunk by a few percent (~5%). Very cool.

Last Edited: Mon. May 29, 2017 - 08:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

even in assembly code.

GAS I presume but not the Atmel assembler??

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:

even in assembly code.

GAS I presume but not the Atmel assembler??

 

Yes, GAS, IDK if Atmel assembler has any similar option, probably not.

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

The Atmel assembler has always made an error on chip over 8k

 

(and because of an error in the assembler it made (in the beginning) a out of reach some times on 8k devices. (On a project in 2000 I had to have some nop to make sure it could build (-max gave an error)). 

Pages