Datasheet: What is the implied unit of 0x02?

Go To Last Post
69 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Reading the data sheet of [1] of ATtiny417, I am confused about some values without units like "0x02".  In particular, "7.2 Interrupt Vector Mapping" on pp. 44 assigns "Vector Number 1" to "Base Address 0x02".

 

From other posts in this forum I'd infer that the implied unit is "word", which is 16 bits in this context as the address refers to an address in program memory.  What's confusing is that the devices in [1] all have flash <= 8 KiB and all such devices so far have vector sizes of 2 bytes.  2 bytes is confirmed by disassembling the respective startup code as supplied by Atm^H^H^H Microchip in [2] (which is just a ZIP resp. JAR file):

$ avr-objdump -d .../gcc/dev/attiny417/avrxmega2/crtattiny417.o:

Disassembly of section .text:

00000000 <__bad_interrupt>:
   0:   0c 94 00 00     jmp     0       ; 0x0 <__bad_interrupt>

Disassembly of section .vectors:

00000000 <__vectors>:
   0:   00 c0           rjmp    .+0             ; 0x2 <__vectors+0x2>
   2:   00 c0           rjmp    .+0             ; 0x4 <__vectors+0x4>
...
  32:   00 c0           rjmp    .+0             ; 0x34 

Disassembly of section .init9:

00000000 <.init9>:
   0:   0e 94 00 00     call    0       ; 0x0 <.init9>
   4:   0c 94 00 00     jmp     0       ; 0x0 <.init9>
Besides that, the devices seem to support JMP + CALL even though their flash is <= 8 KiB.  This is indicated by the presence of JMP + CALL in the startup code and also by "37. Instruction Set Summary" in [1] pp. 581.  The support of JMP + CALL is also indicated on pp. 10 "1. ATtiny Device Family Overview" by asserting that code for ATtiny417 is binary compatible to ATtiny1617 which definitely supports CALL and has a vector size of 4 bytes.

 

Would be great if someone could shed some light on this.  As the data sheet appears to conflict with code supplied by Microchip, and also by paradigms of older devices, maybe someone has hardware available and can run a small program to clarify the matter.

 

[1] http://ww1.microchip.com/downloa...

[2] Atmel ATtiny Series Device Support (1.2.118) http://packs.download.atmel.com/

avrfreaks does not support Opera. Profile inactive.

Last Edited: Mon. May 22, 2017 - 10:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
I am confused about some values without units like "0x02"

0x... is simply 'C' notation to identify a number written in hexadecimal; ie, base (or radix) 16.

 

This is a pure number, and does not imply any units, word size, or usage.

 

The units, word size, etc come from the context in which it is used - not from the 0x... notation itself.

 

eg,

"Vector Number 1" to "Base Address 0x02".

From other posts in this forum I'd infer that the implied unit is "word"

The unit comes from the fact that it is an address in program memory (flash) - it has nothing to do with the value being quoted in the  0x... notation

 

The above could equally have been written

"Vector Number 1" to "Base Address 2".

without affecting the implied unit

 

Or as 

"Vector Number 1" to "Base Address 0b10".

if we take the notation 0b... to indicate a number written in binary.

 

 

 

 

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
From other posts in this forum I'd infer that the implied unit is "word", which is 16 bits in this context as the address refers to an address in program memory.  

Always helpful to give specific links rather than something vague like "other posts" - so we can see the actual context.

 

I guess you're thinking of something like this:

https://www.avrfreaks.net/forum/a...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
0x... is simply 'C' notation to identify a number written in hexadecimal; ie, base (or radix) 16
Andy, you do know who SprinterSB is?!? (hint: he added "__flash" to avr-gcc and has done a lot of the other recent fixes and improvements) so I think you can take as read he knows what "0x" means!! 

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

clawson wrote:
Andy, you do know who SprinterSB is?!?

Nope.

 

so I think you can take as read he knows what "0x" means!! 

So why has he posted a question which specifically says, "What does 0x02 mean?" ??

 

surprise

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, my initial question is really misleading, should be "what are the implied units of 2".  Adjusted the topic.

 

My question is not about notation of integers, it's about implied units.  Because "2" without any units does not make any sense. To be more specific:

 

1) What is the vector size of ATtiny417 (2 words as indicated by data sheet, 2 words as indicated by availability of JUMP + CALL, 1 word as indicated by 3))?

 

2) Does the device support JUMP + CALL (as indicated by ISA summary and by 3))?

 

3) How does this fit together with the startup code supplied by microchip (which uses 1 word vector size)?

 

Obviously, there is a bug somethere as not all pieces of information can be put together in a consistent way.

 

TYI, different notations of integers are explained in "38.1 Conventions: Numerical Notation" in the data sheet, but no units given. In "38.2 Conventions: Memory Size an Type", bit, byte and word are explained:

 

B: byte (8 bit)

word: 16 bit

 

avrfreaks does not support Opera. Profile inactive.

Last Edited: Tue. May 23, 2017 - 07:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
Sorry, my initial question is really misleading, should be "what are the implied units of 2"

But, again, 2 is just a number - it has no implied units in itself.

 

The title should be, "what are the implied units of Vector Address?"; or, perhaps, "what are the implied units of Flash Address?"

 

My question is not about notation of integers, it's about implied units.  

Indeed - which depends on the context - not the integer.

 

1) What is the vector size of ATtiny417

The thing that implies the units is the fact that it's a vector.

 

3) How does this fit together with the startup code supplied by microchip (which uses 2 words vector size)?

I think it was noted in the above-mentioned thread that some chips have different-sized vectors.

 

There was also a note that it depends on which particular tools are used.

 

TYI, different notations of integers are explained in "38.1 Conventions: Numerical Notation" in the data sheet, but no units given.

because the units depend on what is being counted (eg, vectors) - not on the integers themselves.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess that the simulator in studio 7 is the best bet! (It's supposed to be based on the real chip).

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

OP is the one that write the AVR parts of the GCC compiler.

 

And this is some confusion about errors in the datasheet.

Normally AVR's with 8K flash and less have 1 word between ISR addresses (I really hate to call then vectors because they aren't), and bigger chips has 2 words (space for jmp).

 

with this info read #1 again !

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

hehe If SprinterSB doesn't know, it must be a DEEP question!

The largest known prime number: 282589933-1

In my humble opinion, I'm always right. 

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

Well, not a "deep" question. Just one that's about how to (optimally) support such devices.

 

The startup-code from the device package is either suboptimal or incorrect or both.

 

This is remarkable because it doesn't stem from the default startup code from avr-libc which would use either JMP in the vectors and CALL to main, or RJMP in the vector and RCALL to main, not a mixture of either flavours.  So some additional effort has been put into the startup code in order to adjust it in the way it is and as shown above...

 

For now my guess is that the vector entries are 4 bytes in size (as indicated by the docs) and that CALL / JMP are supported (also as indicated by the docs).  But this is only a speculation.

 

Reasons agains it would be the start-up code as disassembled above. And that up to now, availability of JMP / CALL has always been strongly coupled to the flash size and whether it exceeds 8KiB or not.

 

On the other hand, it's not uncommon that hardware producer multiply the number of available devices by labelling them accordingly, i.e. they use the same mask for production and only after production the chips are configured as desired (device-id, start of RAM).  This reduces costs of production because the same mask can be used for various devices.  It's easier to adjust to market needs and the customer is pleased with more options to pick from.  And if a device test reveals that RAM has one bug, but besides that the device operates unimpeded, then it can be downgraded to a smaller device instead of being garbage.

 

avrfreaks does not support Opera. Profile inactive.

Last Edited: Mon. May 22, 2017 - 02:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Georg-Johan,

Atmel have a site somewhere where they publish all their open sources. I know they have a GPL requirement to publish the parts of the compiler they change while AVR-LibC is something like Free BSD so they don't HAVE to publish that but i think they do anyway, in the same place so you should be able to see their modifications to gcrt1.S and see if something in the source helps.

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

In general I prefer engineering very much over reverse engineering...

 

Whatever the sources of avr-libc are, the outcome is 2-byte vectors and YES for support of CALL / JMP.

 

The gcc specs are also out of sync with some of the XML device descriptions.  For example, ATtiny416/417.atdf are stating that RAM starts at 0x3f00.

 

specs-attiny416/417 however, has -Tdata 0x803e00.

 

Maybe it doesn't matter because devices with small RAM are mirroring their memory to cover the space of the big devices (which would make sense from the binary-compatibility point of view).  But I just don't know.

 

As far as the compiler is concerned, my changes will be different from the ones Atmel did and their stuff won't be helpful.  For example, they put the mentioned devices into avrxmega2 class, whereas I suppose to add new multilib variants to get the best suppport.  And their device descriptions deviate from their device XML, so either they wrote the specs file by hand (sources won't help then) or the sources deviate from XML (sources won't help then).  As avrxmega2 supports CALL + JMP, sub-optimal code will result for the small devices.

 

 

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:

 

This is remarkable because it doesn't stem from the default startup code from avr-libc which would use either JMP in the vectors and CALL to main, or RJMP in the vector and RCALL to main, not a mixture of either flavours.  So some additional effort has been put into the startup code in order to adjust it in the way it is and as shown above...

 

 

The tiny417 is part of the new XTiny MCUs (I think Atmel wants to call it TinyX). We have been discussing some of their architectural quirks here. I don't remember if anyone had noticed the matter of interrupt vector size before, though.

 

I have tiny817 hardware and can check vector size in that chip if you want.

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

Somewhat aside, but still..: If Atm.., ahem.., Microchip has not supplied SprinterSB with a special channel directly to the people inside Microchip that does development on avr-gcc/avrlibs, then it's about time they did. Not using him as a special (re-)source is just plain stupid. Regardless of the possibly misleading fomulations in the original question, he should be the one of the very few which gets special treatment from Microchip.

 

The next one would be Jörg Wunsch, but we don't see him around much these days. (And he might well have those contacts already since, AFAIK he did paid work for Atmel sround the time the wireless AVRs saw the light of day.)

 

I'm tempted to put Cliff as third on the list.

 

But SprinterSB should be the first one here to have "insider contacts". (It might be that he has. He's in discussions elsewhere on the Internet with Senthil, who's been seen here occasionally and is, or at least was, affiliated with Atmel/Microchip IIRC.)

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]

Last Edited: Mon. May 22, 2017 - 04:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Georg-Johan,

Atmel have a site somewhere where they publish all their open sources.

Linked from the AVR and SAM compilers page :

Microchip Technology Inc

Microchip

AVR and ARM Toolchains (C Compilers)

http://www.microchip.com/development-tools/atmel-studio-7/avr-and-arm-toolchains-(c-compilers)

browsing leads to :

http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.0/

...

Atmel AVR 8-bit GNU Toolchain is available with Atmel Studio. To download toolchain alone refer:

...

which is a part of Atmel Studio 7.0.1417.

 


http://distribute.atmel.no/tools/opensource/

http://www.microchip.com/development-tools/atmel-studio-7

 

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

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

El Tangas wrote:
The tiny417 is part of the new XTiny MCUs (I think Atmel wants to call it TinyX). We have been discussing some of their architectural quirks here. I don't remember if anyone had noticed the matter of interrupt vector size before, though.

 

I have tiny817 hardware and can check vector size in that chip if you want.

 

Would be great, after all hardware won't lie.

 

That device appears to be common as some boards are equipped with it.  If something was wrong with the startup code then I'd expect someone would already have hit that problem (provided avr-gcc is used together with the linked device support).  As I don't use AStudio... maybe it comes with a more up-to-date version of the files?  The stand-alone support package also has ATtiny214 for example, but no data sheet available. Possibly vapour-ware...

 

JohanEkdahl wrote:
special channel

 

Mailing lists should be enough here.  Other people might also be interested in the information or add their 3 cent, and in general no private discussions are needed.

 

As avr-gcc v5+ can support new devices without hacking the compiler source (provided no change in multilib layout is required), that reduces the need to add new devices to the compiler.  Or at least to contribute local changes.  Adding something to the compiler is terribly slow from that perspective:  If you add device support now, respective avr-gcc (v8 then) will be released spring 2018 and diffused into folks not before 2019.  Moreover, adding support to the compiler might conflict with distributed packages.

 

The bulk of support code will be needed for avr-libc however:  Device header, startup-code, device-lib with naming consistent to the compiler's.

 

In the case of the mentioned device family ATtiny414...ATtiny3217, a new multilib variant is warranted, at least if you want to get the best out of the compiler.  So bit more work is needed across the tools.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
00000000 <__vectors>: 0: 00 c0 rjmp .+0 ; 0x2 <__vectors+0x2> 2: 00 c0 rjmp .+0 ; 0x4 <__vectors+0x4>
SprinterSB wrote:

Reading the data sheet of [1] of ATtiny417, I am confused about some values without units like "0x02".  In particular, "7.2 Interrupt Vector Mapping" on pp. 44 assigns "Vector Number 1" to "Base Address 0x02".

 

From other posts in this forum I'd infer that the implied unit is "word", which is 16 bits in this context as the address refers to an address in program memory.  What's confusing is that the devices in [1] all have flash <= 8 KiB and all such devices so far have vector sizes of 2 bytes.  2 bytes is confirmed by disassembling the respective startup code as supplied by Atm^H^H^H Microchip in [2] (which is just a ZIP resp. JAR file):

$ avr-objdump -d .../gcc/dev/attiny417/avrxmega2/crtattiny417.o:

Disassembly of section .text:

00000000 <__bad_interrupt>:
   0:   0c 94 00 00     jmp     0       ; 0x0 <__bad_interrupt>

Disassembly of section .vectors:

00000000 <__vectors>:
   0:   00 c0           rjmp    .+0             ; 0x2 <__vectors+0x2>
   2:   00 c0           rjmp    .+0             ; 0x4 <__vectors+0x4>
...
  32:   00 c0           rjmp    .+0             ; 0x34 

Disassembly of section .init9:

00000000 <.init9>:
   0:   0e 94 00 00     call    0       ; 0x0 <.init9>
   4:   0c 94 00 00     jmp     0       ; 0x0 <.init9>
Besides that, the devices seem to support JMP + CALL even though their flash is <= 8 KiB.  This is indicated by the presence of JMP + CALL in the startup code and also by "37. Instruction Set Summary" in [1] pp. 581.  The support of JMP + CALL is also indicated on pp. 10 "1. ATtiny Device Family Overview" by asserting that code for ATtiny417 is binary compatible to ATtiny1617 which definitely supports CALL and has a vector size of 4 bytes.

 

Would be great if someone could shed some light on this.  As the data sheet appears to conflict with code supplied by Microchip, and also by paradigms of older devices, maybe someone has hardware available and can run a small program to clarify the matter.

 

[1] http://ww1.microchip.com/downloa...

[2] Atmel ATtiny Series Device Support (1.2.118) http://packs.download.atmel.com/

 

Is not:

00000000 <__vectors>:
   0:   00 c0           rjmp    .+0             ; 0x2 <__vectors+0x2>
   2:   00 c0           rjmp    .+0             ; 0x4 <__vectors+0x4>
...
  32:   00 c0           rjmp    .+0             ; 0x34 

0x2 the same as uint8_t 0x02, the same as uint16_t 0x0002, the same as uint32_t 0x00000002 ?

 

And isn't 0x4 the same as uint8_t 0x04, the same as uint16_t 0x0004, the same as uint32_t 0x00000004 ??

 

And isn't uint8_t 0x34 the same as uint16_t 0x0034, the same as uint32_t 0x00000034 ???

 

I mean, in decimal, 00054 = 00000054 = 54.

 

I guess the compiler is a bit lazy and simply blanks the leading zeros.

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

I was writing the test program, but from the assembly include file for the tiny817 in AS7, it's already obvious that the vectors are 1 word (2 bytes) in size. This means the address units in the datasheet are bytes and not words.

 

Here is the data from the include file:

; ***** INTERRUPT VECTORS, MODULE BASES **********************************

.equ CRCSCAN_vbase = 1
.equ BOD_vbase = 2
.equ PORTA_vbase = 3
.equ PORTB_vbase = 4
.equ PORTC_vbase = 5
.equ RTC_vbase = 6
.equ TCA0_vbase = 8
.equ TCB0_vbase = 13
.equ TCD0_vbase = 14
.equ AC0_vbase = 16
.equ ADC0_vbase = 17
.equ TWI0_vbase = 19
.equ SPI0_vbase = 21
.equ USART0_vbase = 22
.equ NVMCTRL_vbase = 25

and also:

.equ INT_VECTORS_SIZE = 26 ; size in words

 

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

The .inc file seems to be the best source of information on this, I can't make head or tail of the datasheet when it comes to interrupt vectors, it used to easy and spelled out until recently.

 

Looking at the 16K version of the same chip (tn1617def.inc) we see the vectors jumping by 2 words instead of 1 word like the above shows for the t817.

 

; ***** INTERRUPT VECTORS, MODULE BASES **********************************

.equ CRCSCAN_vbase = 2
.equ BOD_vbase = 4
.equ PORTA_vbase = 6
.equ PORTB_vbase = 8
.equ PORTC_vbase = 10
.equ RTC_vbase = 12
.equ TCA0_vbase = 16
.equ TCB0_vbase = 26
.equ TCB1_vbase = 28
.equ TCD0_vbase = 30
.equ AC0_vbase = 34
.equ AC1_vbase = 36
.equ AC2_vbase = 38
.equ ADC0_vbase = 40
.equ ADC1_vbase = 44
.equ TWI0_vbase = 48
.equ SPI0_vbase = 52
.equ USART0_vbase = 54
.equ NVMCTRL_vbase = 60

 

.equ INT_VECTORS_SIZE = 62 ; size in words

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Tue. May 23, 2017 - 09:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I guess everything normal and this :

 

Overview" by asserting that code for ATtiny417 is binary compatible to ATtiny1617 

 

Is the untrue statement ! 

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

Errors in the datasheets... as usual. Copy/paste abuse of table 7-2, that contains the vector addresses, but for the 1617 they forgot that the vectors are 4 bytes in size. Or maybe they are meant to be word addresses, in that case it's the 817 datasheet that is in error.

 

Better have a word with those interns that manage the datasheets.

 

edit: by the way, I did write that test program, so I'll just add it as attachment.

Attachment(s): 

Last Edited: Tue. May 23, 2017 - 10:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you actually execute code which runs some non-trivial ISR (not at offset 0x0)?

 

After all, the data sheet is "preliminary".

avrfreaks does not support Opera. Profile inactive.

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

Yeah, my program executes vector #5 and works fine, I tested on my tiny 817 Xplained Mini.

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

Where does it say that tiny[8|4]17 is binary compatible with tiny1617? Source, yes.  But binary, no.

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

Vector size of devices tiny417, 814, 816 and 817 are 2 bytes. Header file defines macro "_VECTOR_SIZE" with value 2, that is used when compiling startup code in libc.

Sources for last release of toolchain 3.6.0 is available in: http://distribute.atmel.no/tools...

Device specs files are auto-generated, not hand-written. Data-section start address is corrected already, next device pack release will have the updated specs.

 

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

Georg-Johan,

You probably know this already but if you look at the check in history on AVR-LibC then "pitchumani" is perhaps the most prolific contributor in recent years as he works on Atmel's own avr-gcc team and has been responsible for backporting most of Atmel's private branch changes (mainly new device support) back into the main line branch.

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

pitchumani wrote:
Vector size of devices tiny417, 814, 816 and 817 are 2 bytes.

Thanks for that info, also to El Tangas for asking the hardware oracle.

 

Quote:
Header file defines macro "_VECTOR_SIZE" with value 2, that is used when compiling startup code in libc. Sources for last release of toolchain 3.6.0 is available in:

 

Okay.  As the avr-libc master doesn't need that macro, everything is fine and consistent for me.  The vector offsets of 1 words matches the availability of CALL: not available.  Even if the devices support CALL that's pointless as any location can be targeted by RCALL / RJMP, hence the vector layout is implied by the multilib variant and everything fits smoothly into the existing picture :-)  Making availability of CALL / JMP switchable is also pointless because code for, say ATtiny417 won't run on ATtiny1617 anyway.

 

My contributions are from scratch and I won't (re)use stuff published by someone else (with the notable exception of Jean D'Epagnier's fixed point support which I integrated into GCC) or that not available in open repos.  I might peek into available matters and see if something is questionable — like disagreement between code and docs as in the present case — but anything what I am contributing will base on and target openly available projects like Binutils, GCC or AVR-LibC.

avrfreaks does not support Opera. Profile inactive.

Last Edited: Tue. May 23, 2017 - 04:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps you should look into the possibility to use 3 pointers to flash (X, Y and Z). I guess only X and Z make sense for the GCC compiler. 

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

sparrow2 wrote:
Perhaps you should look into the possibility to use 3 pointers to flash (X, Y and Z). I guess only X and Z make sense for the GCC compiler.

I actually though of that: Just letting decay __flash to generic address space. However, this would break code that uses pointers to __flash together with xxx_P functions from AVR-LibC.  As it is trivial to just

#define __flash /*empty */

or to -D__flash= on the command line, so that users that want to drop __flash can easily achieve that.  Won't be that easy for PROGMEM + pgm_read_xxx though and the xxx_P functions.

 

Using more regs to address flash might be tempting, but the most natural way (both in application and in the compiler) is to treat the progmem constants as .rodata.  Or just put it that way: Just write plain C / C++ code without any __flash or progmem gaga, the linker description file will do all the magic.

 

avrfreaks does not support Opera. Profile inactive.

Last Edited: Tue. May 23, 2017 - 06:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tested on my tiny 817 Xplained Mini.

So now AtChip/Micromel should sent some of us tiny1617 Xplained Minis so that we can continue to provide support for the new chip.devil

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Tue. May 23, 2017 - 09:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where does it say that tiny[8|4]17 is binary compatible with tiny1617? Source, yes.  But binary, no.

The statement

Vertical migration can be done upwards without code modification

may need to be worded differently maybe in an updated version of the datasheet? You know for all those not as clever as others. wink

 

 

 

 

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:

Where does it say that tiny[8|4]17 is binary compatible with tiny1617? Source, yes.  But binary, no.

The statement

Vertical migration can be done upwards without code modification

may need to be worded differently maybe in an updated version of the datasheet? You know for all those not as clever as others. wink

 

 

I suppose when they say "code" and "source" they are not taking assembly into consideration. Because asm code can use only relative jumps/calls if the memory is 8K or less but not on the tiny 1617.

If you have to change a rjmp to a jmp in an assembly program, you cannot say the MCUs are source compatible.

 

And yeah, if Microchip/Atmel send me a Xplained mini 1617 (do they even exist?) I'll gladly write an example asm program that is not compatible cheeky

After all, we need to celebrate 20 years of AVRs, the freebies must flow!

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

El Tangas wrote:
If you have to change a rjmp to a jmp in an assembly program
Why would you change rjmp to jmp if you are not modifying the code?

The point is, if a specific code runs in a 417, it will run in a 1617 without any changes.

(Of course, it is not taking advantage of any additional memory or features.)

 

Edit: typo

Edit2: unless it uses wrap-around rjmps...

 

 

David (aka frog_jr)

Last Edited: Wed. May 24, 2017 - 01:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

frog_jr wrote:

 

Edit2: unless it uses wrap-around rjmps...

 

 

Exactly. If you have an ISR residing in the top half of the memory of a tiny 817 (let's say at byte address 6000), you would normally use a wraparound rjmp as vector. If you then go to a 1617, you will have to change it to a jmp, because address 6000 will be out of reach of rjmp in this chip.

 

Edit: and obviously, if you hardcode the ISR entry points instead of using the include file equates, the source codes will also not be compatible. Sure, you shouldn't do this, but in assembly you can.

Last Edited: Wed. May 24, 2017 - 09:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's how the vector size for XMEGAs and the new tiny's is set:

if flashSize > 0x2000 //8KB

    vectorSize = 4; //bytes

else

    vectorSize = 2; //bytes

 

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

I opened a support request at Microchip's and the answer was, that in the data sheet of ATtiny417, the Vector Adresses are in BYTES.

 

avrfreaks does not support Opera. Profile inactive.

Last Edited: Wed. May 24, 2017 - 09:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So we have at least one errata in the Tiny1614-1617 datasheet as the vector size is the shown as the same even though they are 4 bytes instead of 2.

 

 

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Wed. May 24, 2017 - 10:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
... he should be the one of the very few which gets special treatment from Microchip.
An indirect way to support is to donate to GCC.

Ones at Microchip may supply FSF with tiny817 boards (and such) though likely a better fit for the ones who steer GCC to make the decisions on what to buy and when.

GCC, the GNU Compiler Collection

https://gcc.gnu.org/

(right column, Make A Donation)

GCC 7.1 Released

by Jakub Jelinek

https://gcc.gnu.org/ml/gcc/2017-05/msg00017.html

(bottom)

Driving a leading free software project such as GNU Compiler Collection
would not be possible without support from its many contributors.
Not to only mention its developers but especially its regular testers
and users which contribute to its high quality.  The list of individuals
is too large to thank individually!

Please consider a donation to the GNU Toolchain Fund to support the
continued development of GCC!

 

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

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

So nobody told the school kid to change the ISR list!

Nothing have changed, this hole thread is because the normal don't care about documentation, I was hoping it would be better with microchip in charge :( 

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

Added issue to correct interrupt vector size in datasheet for all new tinys with flash size > 8KB, TPUBSTINY-403.

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

I reread some older data sheets and their ISR addresses of the 1st vector after reset (vector numbering differs, some docs start enumeration at 0, others start counting at 1).

 

ATtiny1614/1616/1617:  0x2 (=2 words)

 

ATmega164/324/644:   0x2 (= 2 words)

 

ATmega48/88:  0x1 (= 1 word)

 

ATmega168:  0x2 (= 2 words)

 

AT90S8515: $001 (= 1 word)

 

Hence the new ATtiny161* device docs already follow the convention of using words, nothing wrong there.

 

The inconsistency is in ATtiny414/416/417/814/816/817 which should read address ***1*** for vector 1.  So I'd propose to fix the current byte address / offsets of 2 to a word address of 1, similarly for the following addresses.

 

And allow me to propose that you also fix or remove the very misleading statement about binary(*) compatibility between ATtiny416 et al. and ATtiny1616 et al. etc.  As their vector sizes differ (1 word for the former, 2 words for the latter), except for trivial cases, the code won't be compatible.

 

(*) It makes hardly any sense to interpret it as "source compatibility" which would imply making assertions about which software tools are (not) being used and what programming paradigms are (not) used like conditional compilation / assembling.

 

The questionable line on "vertical compatibility" is shown here: https://www.avrfreaks.net/comment...

 

avrfreaks does not support Opera. Profile inactive.

Last Edited: Thu. May 25, 2017 - 07:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The word addressing of the flash never ceases to create conflict...

 

If we use word addressing it is the "flash size <= 8KB" that should be fixed to 1 word interrupt vector size. I'll talk to "the people with strong opinions on this" and see to that TechPubs update the datasheets to whatever is decided. Nevertheless it could definitely have been written clearer.

 

The compatibility statement is marketing talk. I'll mention it to them, but they sometimes have their own way of see things.

The point is that you can use a hex-file in any of the devices from 2KB to 8KB, as long as it fits and all the peripherals in use are present. If you move up to 16KB you would have to do a recompile to get the interrupts correct, but you shouldn't have to change any code as long as you use the defines in the header files. You could of course hard-code everything, like stated in a comment above, and you would have a serious porting issue, but you don't have to.

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

je_ruud wrote:

(...)

The compatibility statement is marketing talk. I'll mention it to them, but they sometimes have their own way of see things.

The point is that you can use a hex-file in any of the devices from 2KB to 8KB, as long as it fits and all the peripherals in use are present. If you move up to 16KB you would have to do a recompile to get the interrupts correct, but you shouldn't have to change any code as long as you use the defines in the header files. You could of course hard-code everything, like stated in a comment above, and you would have a serious porting issue, but you don't have to.

 

Sure, the vector incompatibility in ASM can be solved by always using the include file. However this is not the only incompatibility, there is also the matter of wraparound rjmp and rcall that become out of range when you move from the 817 to the 1617.

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

Quote:
If we use word addressing it is the "flash size <= 8KB" that should be fixed to 1 word interrupt vector size. I'll talk to "the people with strong opinions on this" and see to that TechPubs update the datasheets to whatever is decided. Nevertheless it could definitely have been written clearer.

 

It's not too bad an approach to follow tradition.   Apart from that, whether or not you prefer to follow the "word" tradition, you can just remove any ambiguity by expressing what you want to express: 0x2 B or 002 W or $2 Bytes or 2 Words is simple and clear.

 

Quote:
The compatibility statement is marketing talk. I'll mention it to them, but they sometimes have their own way of see things.

The point is that you can use a hex-file in any of the devices from 2KB to 8KB

 

The point is that the graphics is displaying devices from 4 KiB up to 16 KiB.  If they don't understand that this asserts that code for ATtiny417 runs on ATtiny1617 (which is plain wrong), then... well.

 

Quote:
If you move up to 16KB you would have to do a recompile

 

I have code that I just need to recompile and it runs on ATtiny40, ATmega128, STM32F103, x86_64, you name it.  Anything that's not binary compatibility is just fooling people and not really smart marketing.

 

As for the 2 KiB devices: Presumably you are referring to ATtiny212/214? I couldn'd find a data sheet for these and assumed they was vapour-ware. No?

 

 

 

avrfreaks does not support Opera. Profile inactive.

Last Edited: Thu. May 25, 2017 - 09:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They should take this opportunity to add negative vector numbers, like ARM.  :-;

 

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

there is also the matter of wraparound rjmp and rcall that become out of range when you move from the 817 to the 1617.

I have seen this kind of statement before and I don't understand what it is getting at. blush

 

It isn't any different with any Mega type of processor, if you change from  a 8K of less device to a 16K or higher device then the vectors must change, nothing else.

 

The wraparound only occurs in the lower 8k boundaries and this seems to be an assembler special case which you must tell the assembler you want to do otherwise it will, correctly, flag an out of range error for rjmp or rcall >2K words. Wraparound for rjmp or rcall above 8K would be disastrous.

 

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....)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Thu. May 25, 2017 - 10:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
I have code that I just need to recompile and it runs on ATtiny40, ATmega128, STM32F103, x86_64, you name it.

I'm sure you do, but migration is not only about code. Sometimes similar electrical characteristics is important. And even though both mega128 and tiny817 have an ADC, they certainly not have the same implementation of the ADC.
The migration diagram do have a point, but the text might be misleading/doesn't tell the whole truth.

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

An example may clarify, this one was written in AS7. This is the same test program as in #22, but I moved the ISR entry point to the top half of the 817 memory (lets imagine this was a big program and the programmer happened to place the ISRs in the end).

Now, the rjmp instruction that vectors to the ISR can only access this entry point with negative displacement, and wrapping through address 0 to the top of memory. An rjmp with positive displacement cannot get to this ISR, it can only access the bottom half of memory.

The program builds fine for tiny 817. If you now change the chip to the 1617 and rebuild, you'll get the "branch out of reach" error, because that address cannot be reached with a negative or positive displacement if the chip has more than 8kB of memory. Note that I'm using the include file equates, not hardcoding.

 

;interrupt test program for XPlained Mini with tiny 817

.org    FLASHSTART
    rjmp    start

.org    PORTC_PORT_vect           ;for the tiny 817 this (word) address is 5
    rjmp    button_released

.org    INT_VECTORS_SIZE
start:
    ;stack is auto-initialized to RAM top on reset

    ;keep port C base address in z register
    ldi     zh, high(PORTC_base)
    ldi     zl, low(PORTC_base)

    ;program pin C5 (button) to trigger interrupt on rising edge
    ldi     r16, PORT_ISC_RISING_gc
    std     z + PORT_PIN5CTRL_offset, r16

    ;program pin C0 (LED) as output
    ldi     r16, 1 << 0
    std     z + PORT_DIRSET_offset, r16

    sei
forever:
    nop
    rjmp    forever

.org	0x0f80		;simulate body of large program

button_released:
    ;no need to save regs in a mere test, but it's just good practice
    push    r16
    ;clear port C5 int flag
    ldi     r16, 1 << 5
    std     z + PORT_INTFLAGS_offset, r16
    ;toggle LED
    ldi     r16, 1 << 0
    std     z + PORT_OUTTGL_offset, r16
    pop     r16
    reti

 

edit: I just want to illustrate that the 817 and the 1617 are not fully source code compatible even if you use the vector defines. You need to manually change the rjmp to jmp.

Last Edited: Thu. May 25, 2017 - 11:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did a quick test but need to rush out. However there seems to be a bug, at least in the .lss file the reti is not included in either 817 or 1617 versions, hope the hex file has it, I'll look into this a bit more later on.

 

Note the missing reti after pop r16 which is included in the source file.

 

 

edit

You need to manually change the rjmp to jmp.

I feel like yet another macro is in order for this, like I do for many other instruction like for in/lds etc.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Strange, the missing reti. I uploaded the program to the Xplained mini and it's working fine (the program toggles the Xplained LED when the button is pushed), so the reti is in the hex file. And on second thought, it is also in the lss instruction use summary, reti:1.

Last Edited: Fri. May 26, 2017 - 01:14 AM

Pages