STM32F103 math packagecalculation time fixcomma for si5351 I have a project with Arduino UNO where the execution time for the line below is 5,78 ms. The line is part of a Wobbler, which is running with 64 steps only. I awaited 1.28 ms with BluePill. After porting to STM32F103 see yourself.
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.
Guest
#7115171
I think, it's not a problem of the math package. Analyze communication overhead to SI5351
Guest
#7115600
Rudi D. wrote: > Any proposals? It looks as if there is no proper setup for the clock. Therefore the chip runs from only a slow internal RC-oscillator. Another idea is, that the function "si5351.set_freq_manual" does it's calculations in a very clumsy way. Or both, slow clock and clumsy algorithm. W.S.
Guest
#7124185
Independent on I2C speed 100k or 400k nothing changes. Still 4,4 ms for the si5351 Command. Also the time needed for encoder interrupt is very short. If I set the interrupt to 5 ms -missing some encoder steps- does not change the 4,4 ms. I'm familiar with fixcomma in assembler with tiny4313 and wobble frequencies at max. 70 HZ. DDS Project in RMorg 2014-2015 with AD9850 up to 30 MHz. I think this would be a solution, but the si5351 is much more complex comp. to AD9850. I want to use the si5351 up to 120 MHz. With some phase mod. to have some sound. Will see if I have enough drive to step into the si53551 deteils registers and communication.
Guest
#7124294
ruilxa wrote: > I think this would be a solution, but the si5351 is much more complex > comp. to AD9850. The SI5351 is a clock-generator based on PLL - it gives only a digital output. The AD9850 is a DDS - it gives an analog output and needs a low pass filter on the output. While the AD9850 is very agile (it only needs to set the phase-offset to switch it from one frequency to another) the SI5351 needs some time to settle the VCO and its phase-loops. Both chips are complex in their own way, but the use of the SI5351 ist much more complicated compared to the AD9850, because the SI needs a combination of 2 integer numbers, which give the best approximation to the desired frequency - while the AD needs only the best value for the phase increment. W.S.
Guest
#7124337
Rudi D. wrote: > si5351.set_freq_manual is this from some public library? When it was designed for Arduino with AVR, a common problem is the superfluous usage of type double. With 8 Bit AVR, the calculations were performed as float, but when used with Cortex-M, expensive double math is used.
Guest
#7124641
JojoS wrote: > a common problem is the superfluous usage of type double that is good news. I thought all is done with fixcomma. But how can I interfere?
Guest
#7124713
you could show which lib you have used
Guest
#7125026
JojoS wrote: > show which lib you have used https://github.com/etherkit/Si5351Arduino #include <si5351.h> //Etherkit
Guest
#7125055
Obviously, FP math is not an issue in this lib. The development of this lib looks stale, there was as issue: https://github.com/etherkit/Si5351Arduino/issues/22 I don't use this chip and cannot help further. It may be a problem of the pll setting to a new frequency. Or a problem of the I2C transfer, there was a comment of using a bulk transfer and speeding it up. here is the complete code so far. Only 10 wobble steps for time measurement.
Guest
#7125185
> the function "si5351.set_freq_manual" does it's calculations in a very > clumsy way. Indeed. > si5351.set_freq_manual((fnow) * 100ULL, Da kraeuseln sich einem ja die Nasenhaare. > >> si5351.set_freq_manual((fnow) * 100ULL, > > Da kraeuseln sich einem ja die Nasenhaare. der si will ja 1/100 Hz Angaben. Besser wäre eine Erklärung, warum sich die Haare kräuseln This is the overview of STM32F103 newly updated. It includes the clock tree of STM32F103 and more, hope it helps. The SI5351 is a clock-generator based on PLL - it gives only a digital output. The AD9850 is a DDS - it gives an analog output and needs a low pass filter on the output. I guess by using HAL the differences should be minor as it's a deep abstraction layer over the CMSIS. Usually the StdPeripheral library (or LL - low level) libraries -which also wrap the CMSIS- have significant differences between different families. Reply |