FYI, x5 ADC_INTERNAL1V1 and ADC_GROUND look flipped to me (compared to datasheet, no hardware test performed)

[ens-ds23]

I don't have an x5 to hand at the moment, but the constants ADC_GROUND and ADC_INTERNAL1V1 in tinyx5/pins_arduino.h look flipped to me compared to the Amtel datasheet (Table 17.4 on p135). That indicates you select Vbg with MUX[3:0] bits 0x0C and GND with MUX[3:0] bits 0x0D.

Sorry if this is a noob mistake. If it is it might be worth at least a comment in the code. The other ADC_CH(...) constants match the table precisely, so it's at least a trap for the inexperienced.

Eventually digikey will deliver my part, and I'll be able to test this properly!

[hmeijdam]

Certainly something going on that looks odd.
When I set the ADMUX register manually to select the bandgap, I can correctly calculate the VCC. Just tested and works fine.

Admux is then B00001100

void setup() {
Serial.begin(9600);// Serial output Attinyx5 on PB0
}

void loop() {
Serial.print("VCC: ");
Serial.println (readVDD());
Serial.println(ADMUX, BIN);
delay(1000);
}

long readVDD() {
  ADMUX = _BV(MUX3) | _BV(MUX2); // selecting bandgap reference of 1.1V (on page 135)
  delay(2); // Wait for bandgap reference to stabilize
  ADCSRA |= _BV(ADSC); // Start ADC conversion, this is where the 1.1V reference is read against vcc
  while (bit_is_set(ADCSRA, ADSC)); // wait until complete
  uint16_t result = ADC; //Needs to be 16 bit long ! This only reads the two registers in one command
  result = 1126400L / result; // Calculate Vcc (in mV); 1126400L = 1.110241000 // 1024 should be right
  return result; // Vcc in millivolts
}

Output (VCC = 3.3V)

VCC: 3444
1100
VCC: 3352
1100
VCC: 3352
1100
VCC: 3342
1100
VCC: 3342
1100

When I change
ADMUX = _BV(MUX3) | _BV(MUX2); // selecting bandgap reference of 1.1V (on page 135)
into one of these below, the REFS1 bit 7 also becomes set so ADMUX becomes as follows:

  ADMUX = ADC_INTERNAL1V1;   >>> ADMUX becomes  B10001101
  ADMUX = ADC_GROUND;        >>> ADMUX becomes  B10001100
  ADMUX = ADC_TEMPERATURE;   >>> ADMUX becomes  B10001111

in the variants folder in subflder tinyx5 in the file pins_arduino.h these are defined
I think indeed, like you said, the 0x0D and 0x0C are swapped

/* Special Analog Channels */
#define ADC_TEMPERATURE     ADC_CH(0x0F)
#define ADC_INTERNAL1V1     ADC_CH(0x0D)
#define ADC_GROUND          ADC_CH(0x0C)

But first in arduino.h ADC_CH is defined as:
#define ADC_CH(x) (0x80 | (x))
That is causing the REFS1 bit to be set, which changes the VCC reference to the internal reference.

That explains why I cannot measure VCC then anymore

Running at 3.3V VCC you see the output with the different values of ADMUX

VCC: 3444
1100
VCC: 3352
1100
VCC: 3352
1100
VCC: 3342
1100
VCC: 3342
1100

VCC: 65535
10001101
VCC: 65535
10001101
VCC: 65535
10001101
VCC: 65535
10001101
VCC: 65535
10001101

[ens-ds23]

As I read the code, that 0x80 bit is masked out of pin by line 284 in wiring_analog.c ADMUX_MUX_MASK when setting ADMUX. The setting of 0x80 in ADC_CH seems to just be a mechanism to get a real pin value through the initial pin remapping code unchanged (line 185-189). Note that this doesn't set REFS (Table 17.3) but MUX (Table 17.4). Refs is set in analog_reference which is masked by ADMUX_REFS_MASK which preserves bit 7. I'm not planning to alter the reference but leaving it at Vcc REFS=0x00, (as you correctly guessed, I'm doing all this to indirectly measure Vcc), so I don't think that top bit is relevant here.

Eventually DigiKey will actually deliver my part and I can do a proper test!

[SpenceKonde]

Well, the high bit is just there as a signal to the core what numbring system is being g used. Thats why on the 2.0.0beta you can do analogRead(5) (and read digital pin 5) analogRead(PIN_PB2) (and read whatever pin is PB2) or analogRead(A3) and read analog channel number 3, normally marked A3 on pinput diagram. The high bit gets stripped off. Some other things look suspicious I. Your test, will get back to you o. That

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Mon, Apr 8, 2024, 04:14 Hans ***@***.***> wrote: Certainly something going on that looks odd and/or I do not understand. When I set the ADMUX register manually to select the bandgap, I can correctly calculate the VCC. Just tested and works fine. Admux is then B00001100 void setup() { Serial.begin(9600);// Serial output Attinyx5 on PB0 } void loop() { Serial.print("VCC: "); Serial.println (readVDD()); Serial.println(ADMUX, BIN); delay(1000); } long readVDD() { ADMUX = _BV(MUX3) | _BV(MUX2); // selecting bandgap reference of 1.1V (on page 135) delay(2); // Wait for bandgap reference to stabilize ADCSRA |= _BV(ADSC); // Start ADC conversion, this is where the 1.1V reference is read against vcc while (bit_is_set(ADCSRA, ADSC)); // wait until complete uint16_t result = ADC; //Needs to be 16 bit long ! This only reads the two registers in one command result = 1126400L / result; // Calculate Vcc (in mV); 1126400L = 1.110241000 // 1024 should be right return result; // Vcc in millivolts } Output (VCC = 3.3V) VCC: 3444 1100 VCC: 3352 1100 VCC: 3352 1100 VCC: 3342 1100 VCC: 3342 1100 When I change ADMUX = _BV(MUX3) | _BV(MUX2); // selecting bandgap reference of 1.1V (on page 135) into one of these below, the REFS2 bit 7 also becomes set so ADMUX becomes as follows: ADMUX = ADC_INTERNAL1V1; >>> ADMUX becomes B10001101 ADMUX = ADC_GROUND; >>> ADMUX becomes B10001100 ADMUX = ADC_TEMPERATURE; >>> ADMUX becomes B10001111 in the variants folder in subflder tinyx5 in the file pins_arduino.h these are defined I think indeed, like you said, the 0x0D and 0x0C are swapped /* Special Analog Channels */ #define ADC_TEMPERATURE ADC_CH(0x0F) #define ADC_INTERNAL1V1 ADC_CH(0x0D) #define ADC_GROUND ADC_CH(0x0C) But first in arduino.h ADC_CH is defined as: #define ADC_CH(x) (0x80 | (x)) That is causing the REFS2 bit to be set. According the datasheet setting the REFS2 bit should not matter. At least thats how I interpret the "X" I see there there when VCC is the voltage reference, which is so in my case. image.png (view on web) <https://github.com/SpenceKonde/ATTinyCore/assets/9595465/b8100d97-a587-429e-8857-8095307a28a1> However I get totally wrong values out of my VCC calculation if REFS2 bit is set. Running at 3.3V VCC you see the output with the different values of ADMUX VCC: 3444 1100 VCC: 3352 1100 VCC: 3352 1100 VCC: 3342 1100 VCC: 3342 1100 VCC: 65535 10001101 VCC: 65535 10001101 VCC: 65535 10001101 VCC: 65535 10001101 VCC: 65535 10001101 — Reply to this email directly, view it on GitHub <#851 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW6K7PQ7VPLWJ47W3VLY4JGVFAVCNFSM6AAAAABF3VOVIKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANBSG42TA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[ens-ds23]

Agreed re high bit.

[hmeijdam]

Thanks for making me understand how I should use the core in this regard.
I normally set the registers myself (bare metal programming), so when I use core functions I should stay away from mixing core functions with bare metal programming. It's either use the functions completely, or not at all.

Besides the 0x0D and 0x0C that are swapped, below sketch perfectly prints VCC with a correct ADMUX

void setup() {
Serial.begin(9600);// Serial output Attinyx5 on PB0
}

void loop() {
Serial.print("VCC: ");
Serial.println (1126400L /analogRead(ADC_GROUND));
Serial.println(ADMUX, BIN);
delay(1000);
}

After fixing that ADC_GROUND should then become ADC_INTERNAL1V1

[hmeijdam]

FWIW I opened a pull request to fix this.
I launched the pull request from Github Desktop (fisrt time for me), and saw in the workflow that it fails for all parts other than the x5 parts. That's kinda nice, that the workflow is smart enough to discover that.