Skip to content

STM32duino 1.5.0 STM32F103C8 very slow. #440

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sergiojolly01 opened this issue Feb 15, 2019 · 3 comments
Closed

STM32duino 1.5.0 STM32F103C8 very slow. #440

sergiojolly01 opened this issue Feb 15, 2019 · 3 comments
Labels
duplicate This issue or pull request already exists

Comments

@sergiojolly01
Copy link

Hello,
I just installed the new release 1.5.0 and tried it with a sketch that already works well with ArduinoSTM32 platform (Maple-Roger). The new platform, compiled it with no problems, but then the software run very slow on the target. The hardware configuration is:
BME280 (I2C), TLS2561 (I2C) and a SPI 240X240 TFT display (based on ST7789) and STM32F103C8T6.
The software is:
Adafruit_GFX, revision 1.3.6 (just mod. for set HW SPI speed at 18 MHz and the SPI mode3, (other modes not compatible with display i.e. does not work)
Adafruit ST7735 and ST7789 Library, revision 1.2.7
BME280 revision 3.0.0, written by Tyler Glenn
TLS2561_SparkFun Library, revision 1.1.0
What I noted is slow refresh of the display, so I investigate with a logic analyser and discovered the following:
refresh time of display: about 130 ms compiled with platform ArduinoST32 Maple-Roger
refresh time of display: about 800 ms ompiled with platform STM32duino 1.5.0 (STM).
Of course I think there is something wrong, the performance is about 1/5. Please note that the time between one SPI transmission to another is about 1 us for Maple and about 7 us for STM32duino, so I think the problem is inside the the SPI libraries. Both use the HW SPI set at 18 MHz clock speed.
Do not hesitate to ask me if you need more information or test.
Thanks a lot for your support and best regards,
Sergio F. Italy

@fpistm
Copy link
Member

fpistm commented Feb 15, 2019

The SPI implementation is not the same btw each core so this could not be compared.
Other users have already opened issue about SPI optimization. See #257.

@fpistm fpistm added the duplicate This issue or pull request already exists label Feb 15, 2019
@sergiojolly01
Copy link
Author

Hello,

thanks a lot for your replay.
I know that the implementation is different, but the MCU is the same, so for me was rasonable to porting my application in the new platform without timing problems. This is the reason of my test, not to compare the perfomance of the two implementations. In any case, with one I can do my final application, with the other is not possible due its low performances. So, for now, I have to move back to the Maple platform. I look forward for the new release of platform with improved performance.

Thankyou and best regards,
Sergio

@fpistm
Copy link
Member

fpistm commented Feb 15, 2019

Welcome.
Roger's core is the best for performance for F1 (use of DMA,...)
Maybe one day this core will be at the same level 🙄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

2 participants