ATTINY416 TEMPSENSE

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


Hello, 

 

I'm working on the Attiny416 Xnano kit, and i'm trying to use the internal temperature sensor. But i'm getting error with the TEMPSENSEn register ( uknown location ). I followed the instructions of the datasheet : 

Does anybody have already done this ? 

 

Thank's in advance !! 

 

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

leooo wrote:
i'm getting error with the TEMPSENSEn register ( uknown location )

What tools are you using?

 

Post the complete, unabridged  message - use copy & paste.

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

If you are using AS7.0 it is probably easier to ZIP up your project and attach the ZIP.

 

David.

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

Hi, yes i'm using Atmel Studio 7, here is my project : 

 

Attachment(s): 

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

There are many problems, but first apply the basic fix for this mistake to the whole.
Incorrect:

    ADC0.CTRLA = 1 << ADC_ENABLE_bm     /* ADC Enable: enabled */

Correct:

    ADC0.CTRLA = ADC_ENABLE_bm     /* ADC Enable: enabled */

 

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

Thanks for the ZIP.   It seems to compile correctly.   You have the correct spelling.

 

The Simulator just gives 0xFF for SIGROW.TEMPSENSEn and never sets ADC_RESRDY_bm in ADC0.INTFLAGS

 

I will see what happens on the real hardware of my XMINI-tiny817

 

David.

 

Edit.  I get the same behaviour on the Tiny817 i.e. ADC_RESRDY_bm in ADC0.INTFLAGS is never set

 

Last Edited: Wed. Apr 15, 2020 - 01:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Here's what i got  : 

thank's for taking time to help ! 

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

In #1, leooo wrote:
 i'm getting error with the TEMPSENSEn register ( uknown location ).

That's not what your screenshot in #7  shows!

 

Most likely, that is telling you that the variable you're trying to look at has been optimised away.

 

https://www.avrfreaks.net/forum/tutcoptimization-and-importance-volatile-gcc

 

 

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 have a tiny817 xplained mini with an lcd connected. I"m not sure I have the various conversions right as I get 118F which I think is in the wrong ballpark (I guess its possible, but seems high).

 

 

#include "MyAvr.hpp"
#include <stdio.h>
#include "LcdChar.hpp"

 

using namespace PINS;

 

static constexpr PINS::PIN LcdPins[]{PB1,PB0,PA7,PA6,PA5,PA4};
LcdChar< LcdPins > lcd;

 

Port<PC0> led( OUTPUT );

 

int main(){
    Adc0 adc;
    adc.refSelInternal( adc.v1V1 );
    adc.prescale( adc.DIV4 );
    adc.initDelay( adc.DLY32 );
    adc.sampLengthAdd( 26 );

 

    const int8_t toffset = Sigrow.TEMPSENSE1;
    const uint8_t tgain = Sigrow.TEMPSENSE0;
    Print( lcd, "offset: %3d\n  gain: %3u\n", toffset, tgain );
    Rtc::wait( 5_sec );
    //offset:  14
    //  gain: 151

 

    while(true){

        led.toggle();
        uint16_t adcv = adc.adcSingle( adc.TEMPSENSE );
        uint32_t t = adcv + toffset;
        t = (t * tgain + 0x80) / 256;
        Print( lcd, " adcv: %5u\ntempF: %5d\n", adcv, (int16_t)(t * 9 / 5 - 459)  );
        Rtc::wait( 1_sec );
        // adcv:   530
        //tempF:   118
    }
}

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

curtvm wrote:
. I"m not sure I have the various conversions right

So print/display the raw values, and check them manually ?

 

Have you checked the Product Page to see if there's any Application Notes or Examples on this ?

 

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

>So print/display the raw values, and check them manually ?

 

That's already done, and is shown in the code- offset=14, gain=151, adcv=530. I can compute manually and get  the same value, but does not tell if I'm interpreting the formulas correctly.

 

Turns out I was adding the offset for some reason, thinking the stored signed value was the correction, even though the formula shows what needs to be done (subtract). Now I get 88F, which is more believable, but still seems a little high but do not know what is expected and do not see any specs in the datasheet. I wouldn't expect a precision temp sensor, but maybe it would be nice to know what can be expected.

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

curtvm wrote:
seems a little high

don't forget that it's inside the chip - so will be subject to self-heating ...

 

I wrote:
Have you checked the Product Page to see if there's any Application Notes or Examples on this ?

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...
Last Edited: Wed. Apr 15, 2020 - 03:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've not used these new chips, but on classic mega/tiny's I seldom use the temp sensor as an absolute value, but rather in relative (differential) mode.  

ex. if I need to temp comp some thing, I record the temp value at calibration time, then use that to compare current temperature value and apply this diff to my needed temp compensation, this way absolute values are not needed, but accomplishes the needed change for temperature drift.

Try add/sub a calibration offset to any readings and see how well it tracks your temp changes.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

There are some app notes for xmega/avr, and avr122 would be one example. It looks like one can expect +/- 10C 'accuracy' or worse, unless you do some more work on your own.

 

I'm taking the easy way out- I just doubled the stored offset value and my temp now looks correct. Maybe the offset is stored incorrectly and the conversion to a signed 8bit number ended up shifting the value by 1 in the process (at the factory), or maybe its just luck on this one particular mcu.  With the configuration of this tiny817 (3.3MHz, driving a blinking led), the self heating adds maybe a count or two to the raw adc value.

 

 

edit-

 

I also tested on a mega4809 curiosity board, the numbers I had were 478 adc, 139 gain, -31 offset. It also does not make much sense until the offset value is doubled-

478 - (-62)  = 540

540 * 139 / 256 = 293

293 - 273 = 20 (K -> C)

20 * 9 / 5 + 32 = 68F

 

Maybe they really do have the tempsense offset value shifted right by one. A sample of 2 does not make it so, but also seems unlikely I can come up with about the same (correct) temp with both boards a couple feet apart using the same formula with the offset doubled. I have tried tempsense before, and was left baffled in the past but it was unimportant so just assumed I was doing something wrong. If that offset value is not as described, things would start to make some sense.

 

Last Edited: Thu. Apr 16, 2020 - 04:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've enabled the temperature sensor on my devices, but it seems not very useful, it reads a little bit high and not totally consistent.

 

It does appear to vaguely increase when the device gets hotter.

 

I'm using code a bit like:

 

static void tempsense_hw_init()
{
    // Use ADC0 to sense temperature.
    VREF.CTRLA = VREF_ADC0REFSEL_1V1_gc;
    ADC0.CTRLC = ADC_PRESC_DIV16_gc      /* CLK_PER divider */
               | ADC_REFSEL_INTREF_gc  /* Internal reference */
               | ADC_SAMPCAP_bm; // capacitance for temp sensor
    ADC0.CTRLD = ADC_INITDLY_DLY64_gc;
    // ADCn.SAMPCTRL select SAMPLEN≥32μs
    // (each clock cycle is 1.6 us so we need at least 20 of them)
    ADC0.SAMPCTRL = 0x18; // only 5 bits
    ADC0.MUXPOS = ADC_MUXPOS_TEMPSENSE_gc;
    ADC0.CTRLA = ADC_ENABLE_bm |
        ADC_RESSEL_10BIT_gc;
    ADC0.CTRLA |= ADC_FREERUN_bm;
    // Start the first conversion.
    ADC0.COMMAND = ADC_STCONV_bm;
}

static uint16_t temp_calc()
{
    // returns temperature in Celsius * 10

    // Code from datasheet
    int8_t sigrow_offset = SIGROW.TEMPSENSE1;  // Read signed value from signature
    uint8_t sigrow_gain = SIGROW.TEMPSENSE0;    // Read unsigned value from signature row
    uint16_t adc_reading = ADC0.RES;   // ADC conversion result with 1.1 V internal reference
    uint32_t temp = adc_reading - sigrow_offset;
    temp *= sigrow_gain;  // Result might overflow 16 bit variable (10bit+8bit)
    // We now have temperature in K * 256
    // temp += 0x80;               // Add 1/2 to get correct rounding on division below
    // temp >>= 8;                 // Divide result to get Kelvin
    // uint16_t temperature_in_K = temp;
    // Let's assume at this point that the temp is above freezing...
    temp -= ((uint32_t) (273.1 * 256.0));
    // Now we can fit in a 16 bit
    uint16_t tempc_256 = temp;

    // This jiggery-pokery should convert to C * 10
    return (((tempc_256 / 8) * 10) /32);
}

 

Last Edited: Thu. Apr 16, 2020 - 12:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also have a couple tiny416 nano boards, but they do not have the tempsense gain/offset stored in sigrow (both are 0xff) so must be the ones with the specific date code where they 'forgot' to store the tempsense info. The datasheet does not show the adc tempsense mux, but the atdf file does (plus they have an errata for those missing tempsense sigrow values, so they must also believe it has the capability even if the datasheet does not). The values returned by the adc for the tempsense on these 416's look correct (505/550), so the tempsense channel is most likely in place.

 

I don't have any more avr0/1 to check. If you want to use tempsense or test it, try doubling the signed offset value to see if that gets you closer to a temp value that makes more sense.

Last Edited: Thu. Apr 16, 2020 - 10:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have to say thank you: The code of markxr works very well on my Attiny 1604 !

With Vcc 3.3V   Tempsense Values  are exactly ! With Vcc 5V not !