Re: Si5351 Programming Flowchart

Pavel Milanes Costa <pavelmc@...>

Hi to all.

The flowchat is a instructive guide for the curious of how to doit without float point math and an expression of the KISS principle.

It's just a cheat sheet to learn from.

The trick is to understand the way he (like Gerry) find a, b and c not needing floating point math. (for the PLL/VCO Msynths case is)

a = int(Fvco/xtal)

b = Fvco % xtal (module, aka: rest of the division)

c = xtal

For example Gerry do a do..while to find a value of b/c that match the allowed size of c, he need it because he is working with the output Msynth dividers not the PLL/VCO Msynth, in his case c = fout and is variable.

In the later case (moving the PLL/VCO Msynth, output Msynth dividers are fixed) c is fixed and equal to the Xtal and we know it already then we can do a simple x >> 5 to both b/c to retain maximum accuracy and make it fit on the register. If we do that just set the output Msynth divider to a integer & even value to minimize jitter or phase noise.

In Gerry routines he fixes the VCO and moves the output divider Msynth and that make some jitter or phase noise (almost negligible in real applications, I know) and makes 3 outs from just one fixed VCO and does not handles the R values or the DIV_BY4 feature limiting the full range of output frequencies (not needed on his target application, I know).

This is just another way of doing things, a way that can be better understood because it uses a simple and elegant image (flowchart), to make life (& code) easier (& smaller)...

BTW I found a possible bug that can haunt more than one in the routines of computing MSx_P2. A tip for the "math" experts... and a common fault.

As per the data:

MSx_P2 = 128 * b - c * floor (128 * b / c)


It's very tempting to reduce it but the floor functions is in there... let see... floor is the lower integer for that float number, hum...

Floor is on the C of Gcc the compiler used by the arduino project but it implies the use of floating point math hence bigger code, just eliminate it and do the math, let try to reduce it...

MSx_P2 = (128 * b) - (c * 128 * b / c)
MSx_P2 = (128 * b) - (128 * b) ---> (c is eliminated as it's * and /  in the expression)
MSx_P2 = 128 * (b - b) ---> ( hum....)
MSx_P2 = 128 * 0 ---> (HUMMMM!!!)
MSx_P2 = 0 ---> (WTF !!!!)

Doing some math and wall head-hiting you can conclude that the floor function is instructing you to IGNORE the use of fractions and then you get a value in MSx_P2 that it related to the amount of error or rest of division of doing things (math) with integers... hence the floor function... forcing you to use just integers... nice.

For example Gerry users in his code this:

msxp2 = 128 * msb - 128 * msb / msc * msc;

If you play that same function with human and integer rules it play well and result is different from zero, but if you use floating point math it always equals to ZERO!

Let's play it with me in full integer math

let's say msb = 900 and msc = 1000

msxp2 = 128 * 900 - 128 * 900 / 1000 * 1000;
msxp2 = 115200 - 115200 / 1000 * 1000;
msxp2 = 115200 - 115 * 1000;   // <<<<=== here is the floor in action (result in float is 115.200 we get it down to 115, all with the magic of integer math)
msxp2 = 115200 - 115000;
msxp2 = 200;

In this case 200 is a relation of the error of using integer math... interesting, mind you how the chip use it internally

For correctness and just to be sure to maintain the best accuracy you must get sure the compiler do the 128*b/c * c in the correct order, that is as per Gerry code fragment:

msxp2 = 128 * msb - 128 * msb / msc * msc;

Must be forced to execute in the correct order by placing some parenthesis to maintain more accuracy.

msxp2 = 128 * msb - ((128 * msb) / msc) * msc;

Firmware size impact is unchanged, compiled code is the same (sha256sum) with and without the parenthesis so GCC compiler is doing he job right, beware of others...

I mentioned this because I have a ham fellow in university (freshman) that hit his head against this wall a few times, "that's impossible, that has no sense.... MSx_P2 is always zero..." he said...

Just my two cents for other that may be in troubles like this understanding the chip.

Cheers, Pavel.

El 12/02/18 a las 12:07, JuanCarlos Berberena Gonzalez escribió:
Hi Guys
A weeks ago Josué Marin-CO7RR- sent me this information to share with my group.
I am only try to be a good 'USER" testing some interesting project I can get on the web and afterward share it with my group.
Now Pavel-CO7WT- sent me this link and I think is a good idea to share with all of you.

It is a Josué Marin email address
73's Jc

Join to automatically receive all group messages.