calculation time fixcomma for si5351

[rulixa]

I have a project with Arduino UNO where the execution time for this line is 5,78 ms

si5351.set_freq_manual((fnow) * 100ULL, pll_freq, SI5351_CLK0); //4,5 ms
//bin von BluePill enttäuscht

My expectation was, using BluePill, 5,78 / (72/16) MHz = 1,28 ms. Result see above.
Only 22% quicker.
I'm using only fixcomma variables.

Any proposals?

Codes available if wanted.

[GonzoG]

Wrong section, this is about STM8 (8bit MCUs), blue pills are usually STM32.

You cannot simply divide time for faster MCUs. It works only for basic math operations.
1st. You're using external library, that might not be optimized for STM32.
2nd. SI5351 is a device that communicates over IIC which is pretty slow interface (up to 400kHz and only half duplex).
3rd. You need to know what exactly this function does, eg. it might simply wait 4ms for something.

[rulixa]

ad1: what do you mean?

ad 2: void setup()
{ Wire.begin();
Wire.setClock(400000);

ad3:used lib is https://github.com/etherkit/Si5351Arduino
the formulas are something like freq = pll_freq( a+ b/c)

the si5351 is quite complicated, so I'm only using the lib.
IF I would insert an assembler section in fickomma, it would sure be quicker. But no time to step into STM32 assembler.
In 2015 I had a project in assembler with tiny4313 and AD9850 with a wobblespeed of max. 70 Hz not around 3 HZ.

May be a STM with builin math would solve the problem.

[rulixa]

sorry should read "fixkomma " and "builtin"

[GonzoG]

sorry should read "fixkomma " and "builtin"

1. libraries for different type MCUs might need optimization for each MCU type. You're using Arduino library, that might not work best with STM32 MCUs.
2. As I wrote - it's slow and MCU speed does not affect communication speed. It will need same time even on 5GHz CPU.
3. The equation does not matter here. You don't know what set_freq_manual() function does and it's for external IC so you cannot calculate execution time form MCU frequency.

[ag123]

a few things
normally
https://learn.adafruit.com/adafruit-si5 ... r-breakout
si5351 is a clock generator, after you have set the frequency, u won't need to set it again soon right?

mcus (including stm32) runs the firmware from flash, this is one of the main limits, not just the cpu clock speed.
if you prefer a faster chip try something in the stm32 f4xx series, some of those have like up to 168 mhz cpu clock speeds (i think a few even higher).
e.g. https://learn.adafruit.com/adafruit-stm ... er-express
and the most important thing about f4 series is the 'ART accelerator', the on chip cache, if your app / sketch / firmware repeatedly runs the same function.
It is likely it'd benefit from a stm32f4xx, the 'ART accelerator' cache can accelerate speeds so much that what takes many wait states to access i.e. flash become 0 wait state.

note that some codes deliberately wait for IO to change state.e.g.

Code: Select all

while(state != 0); // run forever

these are often spinlocks, if you have such codes, e.g. in the libraries, no matter what you do it won't go faster.

[ozcar]

ad 2: void setup()
{ Wire.begin();
Wire.setClock(400000);
...

How does the timing you measure change if you use a different I2C clock? Say:

Code: Select all

Wire.setClock(100000);

The answer to that could let you work out how much of the time is just down loading the required values into the SI5351.

If changing the I2C clock frequency in your setup() routine makes no difference at all to the time you measure, this might indicate that the library itself does something to set the I2C clock, so you might have to change it in there for the purpose of this test.

[dannyf]

My expectation was, using BluePill, 5,78 / (72/16) MHz = 1,28 ms. Result see above.
Only 22% quicker.

A given transmission (I2C, UART or SPI for example) will take exactly the same amount of time, regardless of how fast the CPU is running.

In essense, that's what you are seeing here.

[rulixa]

transmission (I2C, UART or SPI for example) will take exactly the same amount of time"

That's clear,
I 'm going to measure the I2C-time needed to load the si%351

Will take some time... garden

Will also look into AN619 if I can take some info.
Need for wobbling only 1 kHz min step size at around 460 KHz and 10 kHz at 10,7 MHz

[rulixa]

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 have also checked if the interrupt 1, 2 or 5 ms influences the ececution time. No influence the Interrupt is very simple.
Is a rotary encoder

void handler_tim2(void){

const uint8_t enc_lut[16] = {0,0,2,0,0,0,0,1,0,0,0,0,0,0,0,0};
uint8_t index;
// aktuell = PINA & 0b00001100; //leider geht das nur so für den 328er so kurz
// aktuell = digitalRead(phaseA)|digitalRead(phaseB) & 0b00001100 ; //input und mask Phasen
aktuell = GPIOA -> regs -> IDR & 0b0000000000001100;
index = aktuell | last ; //erzeuge index für enc_lut
last = aktuell >> 2; //altes last im Nirvana
flag = enc_lut[index]; // flag ist ja global
//im 328er sind die folgenden Zeilen jeweils in Main, damit interrupt max. kurz ausfällt
if (flag == 2) {freq = freq + fstep; cal = cal + fstep;
if (freq >= 120000000) freq = 12000000;
if (cal >=150000) cal = 150000;
}
if (flag == 1) {freq = freq - fstep; cal = cal - fstep;
if (freq <= 10000) freq = 10000;
else if (freq < 10000) freq = 100000000;
if (cal <= -150000) cal = -150000;//*/
}
// TIMER2_BASE->SR = 0;
GPIOC_BASE->ODR ^= 0x2000; //toggle PC13
}

int time is measured via toggle PC13, the LED pin.

I think I need an assembler part for fixcomma calc - I alredy used it in tiny 4313- , but my knowledge for si5351 is the key point.