calculation time fixcomma for si5351

[ozcar]

So results are:Independent of 100k or 400k fpr I2C the execution time stais at 4,4 ms, per transfer of the new data to si5351
...

I still think you are “barking up the wrong tree” here.

Do you have some way to check that the I2C clock frequency actually changed according to what you tried to set it to?

You previously showed Wire.setClock() right at the beginning of your setup() routine, so presumably you are doing that before calling si5351.init(...) ? Try putting the Wire.setClock() after the si5351.init(...) .

Or else try inserting the Wire.setClock() after the Wire.begin() in the init routine in s15351.cpp:

Code: Select all

...
bool Si5351::init(uint8_t xtal_load_c, uint32_t xo_freq, int32_t corr)
{
	// Start I2C comms
	Wire.begin();
        Wire.setClock(xxxxxx);    // <<< try different frequencies here

	// Check for a device on the bus, bail out if it is not there
	Wire.beginTransmission(i2c_bus_addr);
...

[ozcar]

I was thinking about this some more, wondering what calculations that library could be doing that cause you concern. From what I can see, it does various integer calculations, some of which involve uint64_t variables (nothing that looks too heavy to me).

I was wondering what benchmarks might have been done previously. I can turn up some for floating point calculations, but not much for integer calcs. Maybe somebody else knows of some good ones.

One that I did turn up was this (despite the title it does include some Uno and STM32F103 results):
https://forum.arduino.cc/t/benchmark-es ... 6/325526/7

There they repeatedly do a calculation like this: b += b * b + 1000 / b – 40;
I guess this is to include add, subtract, multiply and divide.

I modified that somewhat, to see what effect different integer sizes makes. I don’t have a Uno to try on, so used 16MHz Nano (same processor as Uno), and a 72MHz F103. I measured the time in microseconds, and only repeated the calculation 1000 times, and also partially unrolled the loop, so these results cannot be directly compared to the ones given at the above link.

Code: Select all

            float    uint8_t  uint32_t   uint64_t
Nano        58372     14928     43076      45688
F103        19870      182       135       1340
				
Nano/F103    2.94     82.02     319.08    34.10

I don’t claim that is a definitive result, as I did not spend too long on it, but for what it is worth that shows that floating point calculations on the F103 are only three times faster than on the Nano, which is certainly less of an improvement than you might hope for.

However, the library in question does not appear to use float for anything, and integer calculations on the F103 are at least 30 times faster, and maybe more than 300 times faster.