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.
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.
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.