Do all new ATTINYs have TEMPSENSE on the ADC ?

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

Hoping an Atmel/Microchip person can help here.

 

The datasheets for the ATTINY414 through ATTINY1616 all mention that writing 0x1E to ADC.MUXPOS selects an internal temperature sensor.

 

The datasheet for the ATTINY204/404 have some of the same text there but TEMPSENSE isn't actually listed in the MUXPOS description - the 0x1E line is missing.  I obviously don't want to rely on something that may disappear in future revisions of the chip so is this simply an editing error or something that isn't guaranteed to be there ?

 

 

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

That would be a better question for MC support!

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

Agreed but have asked them other things and never got a reply

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

If you raise a support ticket it should be "lost" - they'll be duty bound to answer it at some stage.

 

Recent traffic on this board about these new AVR-0 and AVR-1 series chips suggests that the datasheets may be riddled with cut/paste errors. One way to check definitively is to examine the .atdf (atmel data file) for a particular device. It is a full XML description of what the chip really has (these files are used internally in Studio 7 for things like the debugger/simulator so they know which registers to display). I supposed another way to check the same thing is to actually look at the register view in the simulator and see if bits you are looking for are there for a particular device - this is more definitive than trusting human hacked datasheets.

 

(of course there is a potential for error in the XML too ;-)

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

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.

Last Edited: Thu. Jan 31, 2019 - 10:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Many thanks for your help Clawson.   The actual ICs I have seem to have the sensor but I didn't want to have it disappear at a later revision because it wasn't actually in the official spec.   I could have changed to the 414 but RS stock the 404 but not the 414 so it was easiest to stay with that one.

 

 

 

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

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.

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

"while these new chips are "settling in" (for the first 2..5 years perhaps?) "

 

How on Earth do Microchip manage with their ARM based chips ?    Most of the ST ARM based ones I use seem to go not recommended for new design within a few years.

 

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

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.

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

Go to the stm32duino Forum.    Most of the die-hard members there want to use the (first generation M3) STM32F103

 

Yes,  I agree that ST are always introducing new and better ARM chips.    They are easy to migrate backwards and forwards to anything that came after the STM32F103

 

As you can understand,   the first generation of any chip is often superseded by improved peripherals and more intuitive register design.

 

The SAM3X chip used in the Arduino Due is the Atmel first generation M3.    It is also not recommended for new designs.

 

This applies to many semiconductor chips.   The modern replacements tend to be better and cheaper.

Of course you may just want to maintain an "old product".     The "not recommended" chips will become harder to find.    The price goes up.

 

However,   the manufacturers will still make them if there is enough demand.     I suspect that the STM32F103 will see me go up the chimney.

 

David.

 

Edit.   Regarding the OP.    I would guess that any chip design with an internal Temperature Sensor will continue with subsequent revisions.

Don't expect the Sensor to be very accurate but it is useful to detect catastrophic overheating or even just for "clever" compensation of RC clock frequency.

Last Edited: Thu. Jan 31, 2019 - 12:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes I've never used Microchip before but NXP stopped making their simple ARM devices so decided to downgrade to 8 bits as its only a slave processor to the main one.  Don't need 5-10 year production runs when the product will only be current for a year or two before replacement, but it is helpful if the documentation is up to scratch.

 

@ David

 

Actually that's exactly what I wanted the temperature sensor for - to detect things getting too hot and shut down.

 

And I have used the F103 as well, but have tended to use the F407 recently.  However even that is being superceded.

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

clawson wrote:

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.

 

Cliff, while not related to the OP's question. but the latest version of the atdf is 1.3.229 http://packs.download.atmel.com/

 

From my experience with these new tinys specially Tiny 0 & Tiny 1 series, the datasheet of the higher pin count seems to be much better organized and less error. while for example for the 8-pin Tiny1 & Tiny0, it seems definetly that 90% of the datasheet is just a copy/paste.

 

Since we already had a discussion about this, I always check the XML description in the atdf file. I also suggest the OP to do so.

 

Regards,

Moe

 

EDIT: Typos

Last Edited: Thu. Jan 31, 2019 - 12:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

first the question 

 

The 202-204 datasheet has this :

 

29.3.2.6 Temperature Measurement

...

...

 

And then the comment about datasheets, Atmel was very very bad about update errors in the datasheets (even the simple AVR1200 died with errors), and it actually look like microchip is worse. :(

 

I really can't understand why it's not important to have correct datasheets.  

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

sparrow2 wrote:

first the question 

 

The 202-204 datasheet has this :

 

29.3.2.6 Temperature Measurement

...

...

 

And then the comment about datasheets, Atmel was very very bad about update errors in the datasheets (even the simple AVR1200 died with errors), and it actually look like microchip is worse. :(

 

I really can't understand why it's not important to have correct datasheets.  

 

It is something that I also dont understand it!, How can a respectable company with the size of Microchip cant make a normal datasheet ?!

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

I think half the problem is they make too many variants.  For instance the 204 is half the memory of the 404 but is listed at exactly the same price so why use the 204 ?  Same with the old 45 and 85.

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

that is simple, they only make the big chip to begin with, and only if the small sell very well it actually will be made.

 

in 2000 I designed with AVR4414 but before we started to produce it went obsolete but I could get 8515 for the same price. 

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

Moe123 wrote:
Cliff, while not related to the OP's question. but the latest version of the atdf is 1.3.229 http://packs.download.atmel.com/
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!

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

An unrelated question Cliff - why does your subscript say to avoid -O0 optimisation ?   Your link doesn't give any info on this.  

 

I used that optimisation on a prototype I built with Arduino/ATTINY85 before changing to Atmel Studio and the 404, and didn't hit any problems.  Indeed I couldn't get timing loops correct without it and was assuming I'd end up with it on the new version once the PCBs arrive.

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

MikeDB1 wrote:
An unrelated question Cliff - why does your subscript say to avoid -O0 optimisation ?   Your link doesn't give any info on this.  
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".

Last Edited: Thu. Jan 31, 2019 - 02:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MikeDB1 wrote:
I obviously don't want to rely on something that may disappear in future revisions of the chip ...

 

OK, I'll bite:  How might you use the internal temperature sensor?  Perhaps for overheating?  How will you calibrate?  Adjust error in the other channels based on the temperature of the chip itself?

 

To me, the questionable utility of the feature would surely depend on the needed dissipation due to the particular application at a given set of conditions and load.  Couple with explicit and implicit heat sinking of the board design.  Ambient temperature.  Enclosure or not.

 

I guess you could use it to investigate the utility of the listed and similar variants.

 

 

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.

Last Edited: Thu. Jan 31, 2019 - 02:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Moe123 wrote:
Cliff, while not related to the OP's question. but the latest version of the atdf is 1.3.229 http://packs.download.atmel.com/
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!

 

Welcome, Yeah that would be a nice future, just like Eclipse for example.

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

glad I found this thread, the atiny1614 atiny3216 is missing all temperature sensor channel info in the datasheet. opened a support ticket with microchip to get the datasheets updated. The tinyavr1 series datasheets seem to have a bunch of errors from the revision logs, I've got them to update the OneWire having RX and TX mixed up, I'm sure more stuff will also pop up. So when writing code and something is not working right, sure is a bummer when the datasheet says RX is the wire one port, and it is really TX, spent a whole day on that nonsense, then just tried TX for the heck of it, and viola, worked.

Last Edited: Sun. Oct 6, 2019 - 05:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, sometime you gotta look at the "Getting started notes", for this specific problem we have discussed this many times in the forum we end up with the conclusion that for these new AVR-0 & AVR-1 the application notes seems much more accurate.