Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
7 years, 11 months ago.
SPI speed difference between old (rev 17) MBED lib and latest MBED lib
Hi guys,
I'm running into a strange speed difference with SPI running the exact same program, with 2 different MBED libraries. I am driving a small 128x64 OLED screen on SPI, where I'm measuring the time it takes to clear the display. The display library I'm running can be found here: https://developer.mbed.org/users/Anaesthetix/code/SSH1106/
In both cases I'm driving the SPI bus with a frequency of 24 MHz (checked with a scope). The one using rev 17 of the mbed lib, clears the display in 1ms. Where the same program, with the latest mbed lib included, completes its task in 2ms. It seems that the time in between writes to the bus doubled. To check whether there are any differences when running iterations, I've run a madgwick filter with both mbed libraries. In both cases, it takes 62us to run the filter once. So no speed difference there.
A quick scope snap of the SCLK pin while running the old (rev17) lib: https://postimg.org/image/7ffi5c1x5
And one while running the latest lib: https://postimg.org/image/742n6baux
The code mentioned above runs on the Mbed LPC1768, at a 128 MHz core clock. I've sifted through the changelogs, but cannot find anything related to this. If anyone is able to give insight into why this happens, that would be greatly appreciated. Also, merry christmas to you all!
1 Answer
7 years, 11 months ago.
No explanation yet, but some remarks: You state the LPC1768 is running at coreclock of 128 MHz. That seems wrong. The default coreclock for the mbed lib on the LPC1768 is 96 MHz (to support the USB function). The nominal freq of the LPC1768 is 100 MHz. Have you modified the PLL?
The SPI baudrate is set at 24 MHz in the OLED lib, and you say it was checked on a scope. However, even the first picture shows SCLK rate at about 919 KHz. So way off.. The second pic shows SCLK freq of about half that speed, which could explain doubling the time for the clear operation. So there seems to be problem with the coreclock. Have you tested other frequencies (serial port baudrate) or timers (LED blink rates).
Thank you for your comment. I have indeed changed the PLL settings to run the LPC1768 at a higher clock rate, using Michael Wei's lib, which can be found here: https://developer.mbed.org/users/no2chem/notebook/mbed-clock-control--benchmarks/
The SPI is running in mode 3, so the idle clock state is 1. So I thought the clock signal to be this part: https://postimg.org/image/6pydiaid9/
I've also tried timers, which seem to work correctly, but only if I initialize them after I change the clock rate (also checked with a scope). Haven't checked serial port baudrates yet.
posted by 23 Dec 2016Ok, I wondered about the low level pulses and thought it might be ringing..The low level is a bit suspicious. Is the load too high or is it the scope bandwidth (50MHz) or samplerate? So we are looking at longer delays between writes. Could be that the clock is actually runner slower than 96MHz. Check the clock to make sure:
printf ("SystemCoreClock = %d\n\r", SystemCoreClock);
Whenever you change the PLL settings in your main all previously declared clock dependent values become invalid and must be recalculated. That can be done by a new declaration or by setting the baudrate. I assume the OLED and the SPI object are declared globally and before you change the SystemCoreClock (in main) ? Is the OLED init method called before or after changing the clock.
Edit: I did a quick test on the SPI clock speed and delays. The delays between writes are indeed shorter for older library versions (v50) compared to the latest ones (1 us vs 2 us), maybe due to some more testing to make sure the transmission completed. However, there is also an error in the clockfreq for the older lib: I get about 16 Mbit/s instead of 24 Mbit/s. So you win some, you lose some.. Note you can use older libs by selecting the mbed lib and clicking 'revisions' in the righthand panel with lib build details. Anyhow, the BurstSPI should be faster than single transmissions in case you have a block of data.
posted by 23 Dec 2016It's on a breadboard with long wires, my guess is that's causing the low level pulses. I've checked the clock and it says 128MHz so that should be ok, with every declaration made after changing the clock.
BurstSPI does help a lot indeed. Had to use some short delays to get it to work correctly at this speed, but filling the screen now takes 600 us. Certainly fast enough for my application. I'd also like to thank you for the explanation regarding the SPI speed difference.
posted by 05 Jan 2017
Not an explanation as to why it's now slower but you probably don't need to read from the display very often which means BurstSPI should give you a bit of a speed up.
posted by Andy A 23 Dec 2016Thank you. I am definitely going to try this later this evening.
posted by Erik van de Coevering 23 Dec 2016