Clock frequency

albertsm · Joined: 09 Apr 2004 Posts: 5920 Location: Holland

I got a reply from microchip but it was not helping. they only told about the baud procedure which i now implemented as an option.
but like i told microchip : it would make more sense to adjust the center frequency so all timing is correct.
i hope for some description on how to use the sigrow value to adjust the calib register.
but maybe you find something.
for now till i get a solution i leave it.

SZTRAD · Joined: 30 Dec 2019 Posts: 165

So setting the OSC20MCALIBA register and thus the frequency of the oscillator is simple.
If someone needs it, it can be done like this in bascom (this will raise the frequency from the company's 19.63MHz to 19.96MHz). The value in the register is changed by adding 1. The step is 0.33MHz.
Now I will think about what they meant by the q1.10 format for a 7-bit register

albertsm · Joined: 09 Apr 2004 Posts: 5920 Location: Holland

yes it is simple. but i do not see the relation from the offset reg to the calib register.
how do you know what to add/sub ?

i asked microchip. so i wait for that.

to get the output signal :
Config Sysclock = 20mhz , Prescale = 1 , Clockout = Enabled
Config Portb.5 = Output 'for the clock output

when you do not set the port to output you also can measure the output !
but it seems less stable.

what i still do not get : why do they not load a good correction value ?why let the user do all kind of stuff to get a good result?

albertsm · Joined: 09 Apr 2004 Posts: 5920 Location: Holland

ok, i got a reply. they do not tell me where the OSC20MCALIBA value comes from only that it is set during production.
There is no procedure to adjust the clock.

I guess it would be similar to the baud adjust procedure.
I find it a bit odd. I do not get why they did not put values into SIGROW for say 1.8V, 3V3 and 5V. that would make more sense.
Maybe i will try to make a procedure later myself but for now i leave this as is.

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Well, it's also interesting that he doesn't remember the manual correction after the restart, even though they write in the data sheet that they do.
I just sent how it can be changed, now I'm preparing an automatic correction that calculates it itself and moves the register where it is needed.
It seems to me better to set the correction of the main oscillator as a better idea than to recalculate baud rates or time loops. Something memory will take the other side for the accuracy it's probably worth. Unfortunately, there are critical places where one needs a delay as accurately as possible and not just approximately. I have already solved several times the problem with communications, such as SPI and others, when I was not able to communicate from devices at higher speeds.
I'm just confused by the 0.33MHz step is terribly much. That's why I'm researching what their Q1.10 means.
The error is stored as a compressed Q1.10 fixed point 8-bit value, in order not to lose resolution, where
the MSB is the sign bit and the seven LSBs the lower bits of the Q1.10. This should apply only to the 4 constants that are used only for baud rate correction and apparently have nothing to do with the system frequency rate.
I know how to recalculate it, I just can't calculate a good result.
The number is int8_t, which means 8-bit signed. It follows to me that as they write, I have 7 bits left for my own number, I just don't understand where they have the dot in the fraction.
If I use atmel studio it returns values to me (gcc compiler as known)
Sigrow 16MHz 3V: -4
Sigrow 16MHz 5V: -1
Sigrow 20MHz 3V: -7
Sigrow 20MHz 5V: 0
If I load it hard, Bascom will read it from the registry
SIGROW_OSC20ERR3V = 249dec 1111 1001bin
SIGROW_OSC20ERR5V = 0dec
SIGROW_OSC16ERR3V = 252dec 1111 1001bin
SIGROW_OSC16ERR5V = 255dec 1111 1111bin
If I take the first number and imagine that 8bit is a sign, I have 111 1001bin left.
Once upon a time I used the Q format for calculations (real numbers put a lot of strain on processors and this was nice and quite simple how not to lose accuracy) link how to do it here https://www.allaboutcircuits.com/technical-articles/fixed-point- representation-the-q-format-and-addition-examples /
So from the description we know that we have one number before the decimal point and 9 after. So we will add the number to 10 places 111 1001 000 and determine the number according to the procedure above. 1 * 2 (0) + 1 * 2 (-1) + 1 * 2 (-2) + 1 * 2 (-3) + 0 + 0 + 1 * 2 (-6) + 0 + 0 + 0 add it up and we get the number 1.890625. If I count correctly, I do not get anything from what I read. So what am I doing wrong?

albertsm · Joined: 09 Apr 2004 Posts: 5920 Location: Holland

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.

Netzman · Joined: 25 Nov 2005 Posts: 131 Location: Graz

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.[000XXXXXXX]

To convert to a floating point number: [url]https://en.wikipedia.org/wiki/Q_(number_format)#Q_to_float[/url] (BBCode, what's up?)
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 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):

albertsm · Joined: 09 Apr 2004 Posts: 5920 Location: Holland

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 :

SZTRAD · Joined: 30 Dec 2019 Posts: 165

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.96MHz). I don't like when something doesn't work as it should.
It looks like a binary accessory to me
Just for fun
with a correction factor of 0 oscillates the oscillator at 12.24MHz. The core is able to run up to 32MHz then resets.
If you're wondering why I'm researching this. I don't like artificially modified values that I can't influence and I sometimes need to time very precisely. This doesn't seem like a stable thing to me. By the way, that's why I needed that temperature.
To be honest, the RC oscillator error of 40% during production is nothing a microchip should boast. Such a large compensation does not indicate good production. Let anyone be angry with me who wants this at the old avr was not a habit.
I have to think about what to raise the frequency internally who knows how and then trust it is a lottery bet.

albertsm · Joined: 09 Apr 2004 Posts: 5920 Location: Holland

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.

SZTRAD · Joined: 30 Dec 2019 Posts: 165

Unfortunately, the price of the resonator (crystal is out of the question for 14pin circuits) exceeds the price of the circuit itself twice, and I'm not saying that at 5V there are already saffron.
Well, sometimes it helps to read the data sheet until the end, for example, section 31.9. Smile

I lost my smile while peeking at the table. I wanted to use a 32kHz oscillator and perform an internal calibration. Well, he's not much better at measuring it. So the only option is calibration from the outside and this will be a bit more complicated than I wanted, especially in series production. Unfortunately the customer will have to reconsider the use of microchip circuits and I will forget about Bascom. They will go there stm8 and my unpopular c. Price and stability speak for them.
Anyway, thank you for the good work, Mark.

Regards RS