AVR Freaks

OK so I had a look first in 

 

C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATtiny_DFP\1.3.172\atdf

 

and the ATtiny412.atdf file contains:

      <value-group caption="Analog Channel Selection Bits select" name="ADC_MUXPOS">
        <value caption="ADC input pin 0" name="AIN0" value="0x00"/>
        <value caption="ADC input pin 1" name="AIN1" value="0x01"/>
        <value caption="ADC input pin 2" name="AIN2" value="0x02"/>
        <value caption="ADC input pin 3" name="AIN3" value="0x03"/>
        <value caption="ADC input pin 4" name="AIN4" value="0x04"/>
        <value caption="ADC input pin 5" name="AIN5" value="0x05"/>
        <value caption="ADC input pin 6" name="AIN6" value="0x06"/>
        <value caption="ADC input pin 7" name="AIN7" value="0x07"/>
        <value caption="ADC input pin 8" name="AIN8" value="0x08"/>
        <value caption="ADC input pin 9" name="AIN9" value="0x09"/>
        <value caption="ADC input pin 10" name="AIN10" value="0x0A"/>
        <value caption="ADC input pin 11" name="AIN11" value="0x0B"/>
        <value caption="DAC0" name="DAC0" value="0x1C"/>
        <value caption="Internal Ref" name="INTREF" value="0x1D"/>
        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
        <value caption="GND" name="GND" value="0x1F"/>
      </value-group>

so that's what it looks like in a chip that has this. So then:

C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATtiny_DFP\1.3.172\atdf>grep -w TEMPSENSE *
ATtiny1604.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny1606.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny1607.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny1614.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny1616.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny1617.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny202.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny204.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny212.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny214.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny3214.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny3216.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny3217.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny402.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny404.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny406.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny412.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny414.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny416.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny417.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny804.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny806.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny807.atdf:        <value caption="Temp sensor/DAC1" name="TEMPSENSE" value="0x1E"/>
ATtiny814.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny816.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>
ATtiny817.atdf:        <value caption="Temp sensor" name="TEMPSENSE" value="0x1E"/>

So that would appear to be a list of the devices that DO have this temp sense option. 204 and 404 are in that list.

As I say, while these new chips are "settling in" (for the first 2..5 years perhaps?) the datasheet are likely to be riddled with errors so I'd take most of it with a pinch of salt. Things like the ATDF are more definitive.

Microchip have a policy of almost never end of line'ing their chips so I think you can be pretty confident that anything now in production will be for at least the next 5..10 years.

Thanks for the heads up. I wish AS7 was "self updating" so it would just pull updates of this kind of thing when it was notified of being available!

well the quick answer is search here

 

But loads of stuff won't work right if you use -O0. For example many things in AVR land need two things done in 4 cycles or less. An example is the disabling of a JTAG interface. On chips that have one you do a "double write" that is:

MCUSR = (1 << JTD);
MCUSR = (1 << JTD);

A lot of people innocently write things like this in their C then are a bit perturbed when they later discover this does NOT switch off JTD. The error is later traced to -O0. The reason is fairly horrendous. here is that code for mega16:

	MCUCSR = (1 << JTD);
  74:	84 e5       	ldi	r24, 0x54	; 84
  76:	90 e0       	ldi	r25, 0x00	; 0
  78:	20 e8       	ldi	r18, 0x80	; 128
  7a:	fc 01       	movw	r30, r24
  7c:	20 83       	st	Z, r18
	MCUCSR = (1 << JTD);
  7e:	84 e5       	ldi	r24, 0x54	; 84
  80:	90 e0       	ldi	r25, 0x00	; 0
  82:	20 e8       	ldi	r18, 0x80	; 128
  84:	fc 01       	movw	r30, r24
  86:	20 83       	st	Z, r18

then here is what you get for -O1 ("Debug"):

	MCUCSR = (1 << JTD);
  6c:	80 e8       	ldi	r24, 0x80	; 128
  6e:	84 bf       	out	0x34, r24	; 52
	MCUCSR = (1 << JTD);
  70:	84 bf       	out	0x34, r24	; 52

much better - basically two OUTs - about as efficient as an AVR could possibly do this and, indeed, you get that same code for all of -01, -02, -03, -Os and -Og. The one you don't get it for is -O0 as no "AVR knowledge" has been applied to the code.

 

That's timed sequences but just consider more "normal" code like:

	if (PIND & (1 << 3)) {
		PORTB |= (1 << 5);
	}
	else {
		PORTB &= ~(1 << 5);
	}

Anything from -O1 upwards gives:

	if (PIND & (1 << 3)) {
  6c:	83 9b       	sbis	0x10, 3	; 16
  6e:	02 c0       	rjmp	.+4      	; 0x74 <main+0x8>
		PORTB |= (1 << 5);
  70:	c5 9a       	sbi	0x18, 5	; 24
  72:	01 c0       	rjmp	.+2      	; 0x76 <main+0xa>
	}
	else {
		PORTB &= ~(1 << 5);
  74:	c5 98       	cbi	0x18, 5	; 24

I think most folks here would be fairly happy with that fast/tight sequence in their AVR program. SBIS, SBI and CBI are the fast possible way this could be done.

 

Now -O0....

	if (PIND & (1 << 3)) {
  74:	80 e3       	ldi	r24, 0x30	; 48
  76:	90 e0       	ldi	r25, 0x00	; 0
  78:	fc 01       	movw	r30, r24
  7a:	80 81       	ld	r24, Z
  7c:	88 2f       	mov	r24, r24
  7e:	90 e0       	ldi	r25, 0x00	; 0
  80:	88 70       	andi	r24, 0x08	; 8
  82:	99 27       	eor	r25, r25
  84:	89 2b       	or	r24, r25
  86:	51 f0       	breq	.+20     	; 0x9c <main+0x30>
		PORTB |= (1 << 5);
  88:	88 e3       	ldi	r24, 0x38	; 56
  8a:	90 e0       	ldi	r25, 0x00	; 0
  8c:	28 e3       	ldi	r18, 0x38	; 56
  8e:	30 e0       	ldi	r19, 0x00	; 0
  90:	f9 01       	movw	r30, r18
  92:	20 81       	ld	r18, Z
  94:	20 62       	ori	r18, 0x20	; 32
  96:	fc 01       	movw	r30, r24
  98:	20 83       	st	Z, r18
  9a:	09 c0       	rjmp	.+18     	; 0xae <main+0x42>
	}
	else {
		PORTB &= ~(1 << 5);
  9c:	88 e3       	ldi	r24, 0x38	; 56
  9e:	90 e0       	ldi	r25, 0x00	; 0
  a0:	28 e3       	ldi	r18, 0x38	; 56
  a2:	30 e0       	ldi	r19, 0x00	; 0
  a4:	f9 01       	movw	r30, r18
  a6:	20 81       	ld	r18, Z
  a8:	2f 7d       	andi	r18, 0xDF	; 223
  aa:	fc 01       	movw	r30, r24
  ac:	20 83       	st	Z, r18

Are we allowed to say "Furkin Hell" here ?? But Flippin Heck. Exactly how bad do you want your AVR code to be? A few port operations and I've probably filled the flash !!

 

Yes, that code checks and writes the same bits as my 4 opcode sequence above but I wouldn't have this dropped on me!!

 

So, your call, use -O0 if you like but don't be surprised if your code is bloaty and astronomically slow. 

 

The one reason people say to use -O0 is because there will be no resquencing or removal of "pointless" code which can make for a much more ordered debugging experience. Because locals really are created as RAM (stack) locations instead of being held in machine registers then things like Watch Windows work which might not be the case otherwise. But the GCC Gods recently delivered -Og to the AVR world so those arguments are now empty anyway.

 

The reason your timing loops would not work is because if you write:

int main(void) {
	int i;
	while(1) {
		PORTB ^ = 0xFF;
		for (i = 0; i < 1000; i++);
	}
}

any C optimiser worth its salt will say "what is the point of "i" here? It is neither and input nor an output to anything else so why would I bother?". Therefore it does not bother and discards "i" and the for loop from this. If you really wanted the pointless code there's a way in C to say "this may look pointless but I really want this" and that is the qualifier "volatile". it says to C "just trust me on this - I need you to read/write this when you see it even if it looks unused". So:

int main(void) {
	volatile int i;
	while(1) {
		PORTB ^ = 0xFF;
		for (i = 0; i < 1000; i++);
	}
}

would have a delay in any optimisation.

 

Indeed the reason things like "PORTB" actually work is because deep in their definition they are "volatile" (actually "a pointer to a volatile location"). If it wasn't volatile the optimiser would discard my XOR of PORTB too thinking that looked pointless.

 

You want the optimiser to weed out pointless code to make your program as fast and efficient as it can be.

 

When you build -O0 you effectively say "everything you see here is volatile".