Mark, thank you for great support. I have quite some work to do in the meantime. If I will be done before you release the update, then I will ask for beta, otherwise I will wait for the tested update.

i got a long way in the mean time.
At the moment the dat files are updated.
And after that the help need to be updated for the timers. then its ready.
if you need it urgent you can write to support (make sure your email is the same as the one used for registration) and you get a beta when ready.

I agree. And i would not expect the huge offset until i measured it. But when you need very precise timing it is best to use a temp. controlled xtal. also, it is possible to use the RTC. with the internal 32 KHz or external 32 KHz.
So an exact timing would still be possible. I see these internal osc as a nice extra that was not in the older AVR.
I think the ones in xmega were better but on the other hand i did not test that lately. so who knows.

Ok I understood it, I will add it wrong in the model example (see above) three 0 before and I will get the result 0.1181640625. So how AS got the value -7 for SIGROW_OSC20ERR3V. I have measured that the frequency of the oscillator at a correction factor of 23 oscillates at 19.63MHz (when changing to 24 oscillations at 19.6MHz). I don't like when something doesn't work as it should.

I see....ATtiny816 only has ADC0...

I won't dig into registers to run ADC1 as this eats way too much time, I will rather manage other things while waiting for the update

thanks for clearing this up : 0.[000XXXXXXX
Now it makes sense. i did not think about the fixed zeros.

the offset works good for baud. in fact :
[code:1:45fb143445]Config Com1 = 250000 , Mode = Asynchroneous , Parity = None , Databits = 8 , Stopbits = 1 , Baud_offset = Osc20_5v[/code:1:45fb143445]
the new baud_offset option will read the specified sigrow value and applies the offset.

i would have preferred a better osc, or a better way to tweak it. the center freq. can not be adjusted to a precise value. but on the other hand, there exist other options.
ok, all clear

The format is stated in the datasheet p.62:
"The Error is stored as a compressed Q1.10 fixed point 8 bit value, in order not to lose resolution, wherethe MSB is the sign bit and the 7 LSBs the lower bits of the Q.10."

The number is in fixed point format, where the integer part is fixed to 0, the sign is denoted by bit 7, the remaining 7 bits are the least significant bits of the 10-bit wide fractional part:
+/- 0.

To convert to a floating point number: https://en.wikipedia.org/wiki/Q_(number_format)#Q_to_float
Or, in other words, bit 6 of the register value has a magnitude of 0.0625, bit 5 has 0,03125, ..., bit 0 has 0.001953125.

So it is a linear factor which can be applied to the baud rate calculation, wait loops, system clock etc. My guess why the user has to do it, is because the hardware implementation of the RC frequency correction is quite coarse, the user could to decide where more accurate calibration is needed (the baud rate calculation has smaller steps). Additionally, the RC temperature calibration is also more application-specific.

The correction factor is applied in a linear equation (doesn't matter which unit is used for Freq, could be Hz, the baud rate register setting, or something other):
Freq_corr = Freq * (1 + factor)

Which translates in fixed point math to (Bascom-like pseudocode):
[code:1:6fc6abed50]Dim Freq As Integer
Dim Freq_corr As Integer
Dim sigrow_val As Integer
sigrow_val = SIGROW.OSC16ERR3V
Shift sigrow_val, Left, 8
Shift sigrow_val, Right, 8, Signed
Freq_corr = Freq * (1024 + sigrow_val)
Shift Freq_corr, Right, 10[/code:1:6fc6abed50]

you need to wait for the update. the first release only covers the hardware found in xtiny816.
multiple devices are not supported.
like i wrote on the add on page 'you can expect some updates'.
but the good news is that there will be an update for the add on in a few days.

From the PDF :
The error is stored as a compressed Q1.10 fixed point 8-bit value, not to lose resolution, where the MSb is the sign
bit, and the seven LSbs are the lower bits of the Q1.10.

Q1.10 means you have 1 bit for the integer and 10 bits for the fraction. somehow that will not fit into a byte with also a sign.
interesting is that they assign it to a short int which is just a signed byte.
i think they omitted some bits.
that is why they give this for the baud :
int8_t sigrow_val = SIGROW.OSC16ERR3V; // read signed error
int32_t baud_reg_val = 600; // ideal BAUD register value
assert (baud_reg_val >= 0x4A); // Verify legal min BAUD register
value with max neg comp
baud_reg_val *= (1024 + sigrow_val); // sum resolution + error
baud_reg_val /= 1024; // divide by resolution
USART0.BAUD = (int16_t) baud_reg_val; // set adjusted baud rate

i did check and it works. the 1024 is of course 10 bits.

so similar to this, you could do this with the calib register.
I tried that but it does not work because even the smallest bit change will result in a huge offset like you noticed too.



[code:1:2f409e1931]
Config Sysclock = 20mhz , Prescale = 1 , Clockout = Enabled
Config Portb.5 = Output 'for the clock output

'configure the USART
Config Com1 = 250000 , Mode = Asynchroneous , Parity = None , Databits = 8 , Stopbits = 1 , Baud_offset = Osc20_5v

Waitms 2000

Print "Test USART"
Dim B As Byte

Do
Print "this is a baud test"
Print Hex(clkctrl_osc20mcaliba) '9E
B = Inkey()
If B = "+" Then
Cpu_ccp = &HD8
Incr Clkctrl_osc20mcaliba
Elseif B = "-" Then
Cpu_ccp = &HD8
Decr Clkctrl_osc20mcaliba
End If
Waitms 500
Loop
[/code:1:2f409e1931]

so i think you can not get a precise clock. at least not with the internal osc.
for a lower frequency such as a baud rate the compensation will work out ok.
till somebody proves otherwise i leave it as is.

ATtiny3217 has 2 ADCs (ADC0 and ADC1). In xtiny Bascom "Config ADC0" works and "Config ADC1" is not even recognized. How can I now configure ADC1 (I need to read voltage on pin 19 (ADC1/AIN8))?

"Getadc (n)" command now gives ADC0 value where "n" is from 0 to 11 (mux position). What is the syntax to read from desired pin 19 with ADC1?


P.S. "Getadc (100)" also compiles with no errors reported....I suppose this is not right isn't it?

[b:6f865fcd53][color=red:6f865fcd53](BASCOM-AVR version : 2.0.8.3 )[/b:6f865fcd53][/color:6f865fcd53]