2025-02-13 3:05 AM
I am using the above library to display simple text msg on the OLED display. It works.
However the controller slows down - while(1) loop works as if delay(5000) is implemented. At first the internal HSI clock running at 8Mhz was being used. Thinking that increasing the clock speed might help , activated the PLL so as to increase the clock to 48MHZ. But still the SSD1306 somehow pulls down the speed.
If the code for SSD1306 are commented out , rest of the operation runs faster. The controller is used to read only 2 ADC channels with DMA, which is not much of a task. Nothing else.
Has anyone encountered such an issue ? What could be the likely issue ?
2025-02-16 10:46 AM
I tried this too. It is practically the same one as I was using with only minor difference. This one too is slowing down this particular MCU
I tried the same program on Blue pill and it is fast. too fast that I had to slow it down..
May be I have to try another chip.
Thank you.
BTW do you know how to create custom size font , that is used in this library ?
2025-02-16 11:38 AM
>>Let me ask you a straight question Have you worked with this particular micro controller ?
The Cortex-M0?
Yes, I've used SSD1306, SH1106 and SSD1309 via I2C on L0, L4, F7 and H7 among others.
Specifically the STM32F030C8T6TR, probably not, but if I did it wouldn't take 5 seconds to paint the screen.
We're a page deep here, still not clear what pins you've used, the I2C configuration code, or the library you're trying to integrate. It's great it's working on your other platforms, and MCUs, but those are the ones you're trying to debug.
2025-02-16 10:52 PM
//Specifically the STM32F030C8T6TR, probably not, //
That is the point. rest is assuming.
If you have NOT worked with this particular MCU , what are you going to do with the code , if I post the code which is pretty standard stuff ?
Further , did I post about the code ? Have you read my original post carefully ?
I have done a lot of projects with esp, PIC , STM32 , RPI.
I need a cost effective solution for a medium scale project. So this MCU was a good option. But was hit by this issue.
Any ways, Since F103C8T6 works as expected with the same SSD1306 library. So decided to go for it for the time being.
Hope you understood.
BTW, I THINK - Not 100% sure, it is the buffer size (128 * 64 /8 = 1024) that is pulling down the performance on this MCU , which is not a problem for F103 or ESP32. I tried reducing the buffer size and it ran faster , but affected the display (naturally). So there is something wrong with how both get working together.
,
2025-02-20 1:15 PM
You mention "a library" but don't specify which or whose. The SSD1306 is a part, for which many libraries and code examples exist. I've not heard you mention a specific one, just that you've got it working with multiple other platforms, which is great, but this is the one causing you trouble.
I'm still not seeing any HW initialization code, scope traces, or data movement specifics that would make me think the F030 is incapable of the task. The L0 can do it running at 32 MHz, so pretty sure an F0 at 48 MHz with 8K of SRAM should.
Start looking at what's happening in the library and on the wire.
Make sure the MCU's running as fast as you think it is, and the I2C is at 400 KHz, that functions aren't timing out.
I'm trying to understand why it's unduly slow here, so either help me do that, or take leave.
2025-02-20 1:23 PM
The frame buffer is 1KB, so 8192 bits, written in blocks, with I2C running at 400 KHz, should be able to get a frame rate approaching 40 Hz, not 0.2 Hz
I don't see this being a memory problem, I do see it being a bus problem.