SSD1306 OLED controller<\/h2>\n\n\n\n
We never have access to a bare matrix. There\u2019s always some controller in between. This is the case with alphanumeric displays (HD44780), TFTs, and OLEDs. The controller\u2019s job is to receive instructions from the host on how to set the pixels on the matrix. They often feature additional built-in functions.<\/p>\n\n\n\n
A popular manufacturer of OLED display controllers is Solomon Systech Limited. They produce very good, popular controllers marked SSD. They offer a dozen or so chips capable of driving OLED matrices. They differ in the sizes of supported matrices, interfaces, or available grayscale levels. For those interested, see the brochure \u2013 This controller has a few built-in effects:<\/p>\n\n\n\n You\u2019ll find more valuable information in the chip\u2019s datasheet \u2013 <\/p>\n\n\n\n Chinese modules offer two interfaces \u2013 I\u00b2C and SPI. Communication is split into commands<\/i> and data<\/i>. The choice of the type of information transmitted over I\u00b2C is made by writing to the appropriate register (0x00 for data and 0x40 for commands). In SPI it\u2019s a bit different because you can choose 3- or 4-wire communication. With four wires, in addition to the standard SPI signals, there is also a D\/C signal that determines what is being sent to the display. If 3-wire mode is selected, you need to send an extra bit at the beginning of each byte. This makes the communication 9-bit. So, shall we? Let\u2019s get cracking!<\/p>\n\n\n\n The code provides several definitions you can change, such as:<\/p>\n\n\n\n The rest of the control is done through appropriate functions. Image creation is based on an RAM buffer in the MCU. It contains information about each pixel \u2013 the so-called frame. This is a monochrome display, so the entire buffer occupies only 1 kB of RAM. That\u2019s not much for an STM32, and using such a buffer offers great convenience. Thanks to it, it\u2019s easy to implement image overlaying (the transparency<\/i> argument).<\/p>\n\n\n\n The basic function is initialization. Depending on the interface, it takes as an argument a pointer to the appropriate I\u00b2C or SPI structure. Note.<\/strong> This function sets, among other things, matrix size, COM voltage, and drawing directions, which can differ especially with other resolutions and sizes. Make sure you have the right ones and, if necessary, change them to those recommended by your display\u2019s manufacturer.<\/strong> Smaller resolutions may have a different pixel-to-memory organization. However, for most cases, these settings should be correct.<\/p>\n\n\n\n Four configuration functions allow you to:<\/p>\n\n\n\n Next, the most important display functions.<\/p>\n\n\n\n Drawing a single pixel in the RAM buffer. This function draws a pixel with the given coordinates and color in RAM. It is not sent to the display. This allows you to prepare all graphics before they are sent to the OLED\u2019s RAM.<\/p>\n\n\n\n Fill the RAM buffer with the selected color. Only WHITE and BLACK are available. Any other value will be ignored. It\u2019s used to clear the frame contents.<\/p>\n\n\n\n Send the entire buffer to the display\u2019s RAM. Only when this function is called is the previously prepared buffer sent to the display and the final image appears on the matrix.<\/p>\n\n\n\n This function is similar to SSD1306_Display<\/i>, except that we can send an image that is outside the buffer, e.g. in Flash memory. It must be the same size as the matrix<\/strong>. Otherwise some garbage from memory will be sent or a HardFault will occur.<\/p>\n\n\n\n Next, I implemented the graphics functions offered by the controller. There is content scrolling in different directions.<\/p>\n\n\n\n Arguments of type scroll_horizontal_speed<\/i> decide how many frames apart the animation advances. This is not the number of frames you send to the controller.<\/strong> These are the controller\u2019s refresh frames, based, among other things, on Display Clock<\/i> and Multiplex Ratio<\/i> values provided during initialization. For convenience, they are in enumerated form. I encourage you to experiment with these functions.<\/p>\n\n\n\n The last section is the \u201cadvanced\u201d graphic commands. The first is Fade Out<\/i>.<\/p>\n\n\n\n It gradually dims the display, i.e. decreases the contrast. The change goes from the given Interval<\/i> down to zero and remains there until canceled.<\/p>\n\n\n\n A similar effect is blinking.<\/p>\n\n\n\n The effect is similar to Fade Out<\/i>, except that the display returns to the Interval<\/i> value and \u201cblinks\u201d in a loop.<\/p>\n\n\n\n After dimming or setting blinking, the display does not return to the \u201cnormal\u201d state. You need to pull it out with<\/p>\n\n\n\n The last, most pointless function for me is Zoom In.<\/i><\/p>\n\n\n\n It only works with the full possible matrix, i.e. 128\u00d764, and the idea is that the top half of the display (128\u00d732) is stretched downwards. See how it works for yourself. Will it be useful?<\/p>\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n The graphics library I use is based on various examples from the Internet. It can be used with both STM32 and AVR. It requires passing three values to work correctly. These are the function that draws a single pixel and the display dimensions in pixels.<\/p>\n\n\n\n In my example, the library will draw in the RAM buffer because that\u2019s what the pixel function does. To send this to the OLED controller, you\u2019ll need to use SSD1306_Display().<\/p>\n\n\n\n I also included a few switches to decide which drawing functions will be needed. You can save some Flash space by skipping compilation of unnecessary things. What gets compiled is determined by USING_XXX-style switches (#define). Setting zero removes the given function, while one adds it to the code. Some functions require others, and I added a small \u201cautomaton\u201d to handle that. Available are:<\/p>\n\n\n\n I encourage you to play with the library and report bugs or modification proposals to me. Now I\u2019ll move on to the main part of the post.<\/p>\n\n\n\n <\/p>\n\n\n\n I\u2019ll start with I\u00b2C. With an STM32 I only need two wires for this interface, so it\u2019s a tempting option for default use. The SSD1306 datasheet says that the maximum supported I\u00b2C clock is 400 kHz. For today\u2019s tests I\u2019ll use a Nucleo with STM32L476RG<\/strong><\/a> on board. It supports I\u00b2C communication in Standard Mode (100 bit\/s), Fast Mode (400 bit\/s), and Fast Mode Plus (1 Mbit\/s). I\u2019ll try to overclock the SSD1306 controller\u2019s I\u00b2C clock, why not! Let\u2019s see what happens.<\/p>\n\n\n\n Since I used a ready-made module with the display, the schematic to connect it to I2C1 is trivially simple.<\/p>\n\n\n <\/p>\n\n\n\n First I\u2019ll test a \u201csafe\u201d clock value \u2013 100 kHz. Cube configuration is trivial.<\/p>\n\n\n <\/p>\n\n\n\n In later steps I\u2019ll change the speed via the I2C Speed Mode<\/i> menu, but I won\u2019t show that on screenshots. Sending a complete frame at an I\u00b2C clock frequency of 100 kHz looks like this:<\/p>\n\n\n <\/p>\n\n\n\n The time to send all pixels is about 103 ms. That\u2019s quite a lot given that sending frame after frame yields only 10 frames per second with 100% MCU load. I\u2019ll increase the speed a bit.<\/p>\n\n\n <\/p>\n\n\n\n It\u2019s definitely better. 27.4 ms is already a nice value that gives about 36 frames per second. Even though the SSD1306 datasheet states that the maximum I\u00b2C clock frequency can be 400 kHz, I\u2019ll try to overclock communication a bit. The STM32L476RG offers Fast Mode Plus. Here\u2019s the effect.<\/p>\n\n\n <\/p>\n\n\n\n Frame transfer time is only 12.38 ms. This value allows about 80 FPS<\/strong>. That\u2019s quite a lot. Usually such a high FPS isn\u2019t needed, so you can limit it, freeing up CPU for other operations. Speaking of which, can we ease the processor a bit during transfer? Of course! With DMA \ud83d\ude42 I\u2019ll perform the same operation now by sending the entire buffer via DMA. See how much the CPU usage drops.<\/p>\n\n\n\n 100 kHz:<\/p>\n\n\n <\/p>\n\n\n\n As you can see, the processor is busy for just one millisecond. That\u2019s the time I send over I2C to the display the information that I\u2019m going to send a frame. You can shorten this time a bit.<\/p>\n\n\n\n 400 kHz:<\/p>\n\n\n <\/p>\n\n\n\n 0.3 ms of CPU occupancy at 400 kHz is an excellent result. There\u2019s still 1000 kHz left.<\/p>\n\n\n <\/p>\n\n\n\n In practice, the STM32L476RG sets the I2C clock to 800 kHz even though 1000 is set in Cube. Hence the \u201conly\u201d twice lower result \u2013 0.15 ms. How fast is that? Very.<\/p>\n\n\n\n If you still don\u2019t know the benefits of using DMA, let me show how many main loops the CPU completes each second while working with the display. These will be results with DMA off and on. The first photos concern blocking transfer, i.e. without DMA.<\/p>\n\n\n <\/p>\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n As you can see, the program will execute only as many main loops as frames per second the display is able to show. That\u2019s logical, because the CPU waits until the OLED transfer finishes. Now results with DMA. The transfer of the next frame happens only if the previous transfer has finished. At the same time, the main while loop keeps running all the time.<\/p>\n\n\n <\/p>\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Not only did the FPS count go up, but the program executes about 300 thousand iterations of the while loop per second<\/strong>. While the frame is being transferred by DMA, the CPU is idle and can, for example, receive data from sensors. You can go for double buffering and smoothly prepare data for the display.<\/p>\n\n\n\n Choosing how to handle it \u2013 DMA or not \u2013 besides the configuration in Cube is done in the library with the #define SSD1306_I2C_DMA_ENABLE<\/i> definition.<\/p>\n\n\n\n So how does this all look when working with the SPI interface?<\/p>\n\n\n\n The SSD1306 controller allows the SPI interface to operate with three or four connections. The difference is in connecting the DC pin, which tells the chip whether data or commands are being sent. Communication in 4-wire mode is 8-bit, while 3-wire requires sending 9 bits over SPI each time (one informational bit instead of a dedicated wire). My display does not allow me to test 3-wire mode, so I\u2019ll limit myself to the available four connections. Besides, 9-bit SPI seems rather unnatural\u2026 The module I have does not have the MISO pin brought out, but there\u2019s no need to read anything from the display anyway. In such a case, I\u2019ll set SPI to Half-Duplex. SPI + DC equals 4 pins, and there\u2019s also the RESET pin. It\u2019s not mandatory, but if we have free pins in the system, why not use it. It\u2019s enabled conveniently in the library with one \u2018define\u2019 \u2013 #define SSD1306_RESET_USE.<\/i> Then this pin should be connected to 3.3 V.<\/p>\n\n\n\n I\u2019ll connect all possible pins to the MCU. The schematic looks like this.<\/p>\n\n\n <\/p>\n\n\n\n The CS pin strayed a bit from the rest of the group, but there\u2019s a reason for that, which I\u2019ll explain in a moment.<\/p>\n\n\n\n The SSD1306 datasheet says the maximum SPI clock frequency can be 10 MHz. The STM32L476RG runs at 80 MHz, so the prescaler should be set to 8. As with I\u00b2C, I can overclock the communication. For SPI, I can raise the SCK line frequency up to 40 MHz. I\u2019ll test it, of course \ud83d\ude42<\/p>\n\n\n\n Initially, however, I\u2019ll set a reasonably safe value. A prescaler of 64 gives me a clock of ~1.25 MHz. Later it\u2019s enough to just decrease this value. The I\u00b2C pins are remnants from the previous mode and are not needed at this point.<\/p>\n\n\n <\/p>\n\n\n\n Time to see what the analyzer shows. At 1.25 MHz we already get a good result. Sending the whole frame takes 8.25 ms. Definitely better than the maximum I\u00b2C frequency, and this is only 12% of the controller\u2019s SPI capability.<\/p>\n\n\n <\/p>\n\n\n\n For comparison, 5 MHz \u2013 2.07 ms.<\/p>\n\n\n <\/p>\n\n\n\n And 10 MHz \u2013 1.04 ms. Very fast!<\/p>\n\n\n <\/p>\n\n\n\n Alright, but what about overclocking? \ud83d\ude42 I checked what the prescaler allows, i.e. 20 MHz and 40 MHz. As with I\u00b2C, the controller didn\u2019t even flinch. I didn\u2019t see any random or missing pixels on the screen. Everything goes smoothly. And the times? Regardless of what the analyzer interprets on MOSI and SCK (16 MHz sampling), the test tells the truth.<\/p>\n\n\n\n Frame transfer at 20 MHz takes just 0.53 ms.<\/p>\n\n\n <\/p>\n\n\n\n And at 40 MHz\u2026 0.27 ms! What a speed. At such a rate you could skip DMA \ud83d\ude42<\/p>\n\n\n <\/p>\n\n\n\n However, remember this is 4 times the maximum value given by the manufacturer. The fact that I managed it on a desk doesn\u2019t mean the display will work flawlessly at 40 MHz in a production environment! It\u2019s better to stick to a maximum of 10 MHz and use DMA.<\/p>\n\n\n\n Of course, I anticipated this option in the library. Enable DMA the same way as for I\u00b2C and use the #define SSD1306_SPI_DMA_ENABLE<\/i> definition to switch the code to DMA transmission. Unfortunately, that\u2019s not all. As you know, with SPI you also have to control the CS pin. You need to return it to the high state after the DMA transmission is complete. I\u2019m not going to wait for the transfer to finish just to toggle a pin. I didn\u2019t configure DMA to wait like with a regular transfer\u2026 There are two approaches that I implemented in the library:<\/p>\n\n\n\n You have to decide what\u2019s right for you. What are the MCU occupancy times with SPI DMA like? 1.25 MHz \u2013 38.37 \u00b5s.<\/p>\n\n\n <\/p>\n\n\n 5 MHz \u2013 28.81 \u00b5s.<\/p>\n\n\n\n 10 MHz \u2013 21.81 \u00b5s.<\/p>\n\n\n What remains is the FPS count and the number of while-loop iterations with DMA. Allow me to skip the photos of the display showing the results. I\u2019ll present them in a table together with I\u00b2C.<\/p>\n\n\n\n What conclusions can be drawn? Which interface to use in a project? For tinkering or a simple device, it won\u2019t matter much which interface you choose. However, if:<\/p>\n\n\n\n Should you care about the maximum FPS? The only \u201cthreat\u201d to animation smoothness is I\u00b2C at 100 kHz. Everything else will handle 30 frames for smoothness. It\u2019s also better to programmatically limit FPS to 30 or 60. This isn\u2019t Counter\u2011Strike.<\/p>\n\n\n\n And DMA? In my opinion, it\u2019s a must have. Life\u2019s too short to wait for the MCU to send data \u201cby hand.\u201d You can really do other things during that time, like data acquisition from all sensors. Operation will be smooth, and the display will please the eye with a consistently high frame rate.<\/p>\n\n\n\n I mentioned double buffering earlier. If you want to send frames at equal time intervals, for example using a timer<\/i> interrupt, it may happen that the timer<\/i> triggers the DMA transfer when the MCU is writing some data to the display buffer. Then at least one frame will be corrupted, which a keen eye may notice. You can implement double buffering to solve this. What is it? How to do it? Another time \ud83d\ude09<\/p>\n\n\n\n OLEDs are great displays. Using them is very enjoyable and I\u2019m eager to use them in my devices. I think I\u2019ve shown the difference between the interfaces well and you\u2019ll choose the right control more consciously.<\/p>\n\n\n\n If you liked OLED displays, you can get them in various variants in my shop<\/a>.<\/p>\n\n\n\n The project with code is on my GitHub: link<\/a><\/p>\n\n\n\n If you noticed any error, disagree with something, would like to add something important, or simply want to discuss this topic, write a comment. Remember that the discussion should be polite and in accordance with the rules of the Polish language.<\/span><\/p>\n\n\n
SSD_OLED_IC_Catalog<\/a>
. Undoubtedly, the most popular on the market is the SSD1306. It\u2019s relatively simple. It supports matrices up to 128\u00d764 pixels. It has a 256-step brightness scale and note, this is not grayscale. It simply dims\/brightens the entire matrix. It has built-in RAM for the displayed image. You can talk to it via an 8-bit parallel interface, I\u00b2C, or SPI (3\/4-wire), with the parallel interface rarely implemented on Chinese modules. And that\u2019s good because I believe I\u00b2C and SPI are fast enough. An important feature is the built-in voltage converter, since OLED panels require about 12 V to operate. Thanks to this converter you don\u2019t have to worry about it, although supposedly they can whine. Luckily, I\u2019ve never had one do that.<\/p>\n\n\n\n\n
\n
SSD1306 Datasheet<\/a>
. I will focus on a display based on this controller. It will be 0.96\u2033.<\/p>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/02\/OLED_baner-1024x341.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nControl<\/h2>\n\n\n\n
Library<\/h2>\n\n\n\n
\n
\n
void SSD1306_DrawPixel(int16_t x, int16_t y, uint8_t Color);<\/pre>\n\n\n\n
void SSD1306_Clear(uint8_t Color);\n<\/pre>\n\n\n\n
void SSD1306_Display(void);<\/pre>\n\n\n\n
void SSD1306_Bitmap(uint8_t *bitmap);<\/pre>\n\n\n\n
void SSD1306_StartScrollRight(uint8_t StartPage, uint8_t EndPage, scroll_horizontal_speed Speed);\nvoid SSD1306_StartScrollLeft(uint8_t StartPage, uint8_t EndPage, scroll_horizontal_speed Speed);\nvoid SSD1306_StartScrollRightUp(uint8_t StartPage, uint8_t EndPage, scroll_horizontal_speed HorizontalSpeed, uint8_t VerticalOffset);\nvoid SSD1306_StartScrollLeftUp(uint8_t StartPage, uint8_t EndPage, scroll_horizontal_speed HorizontalSpeed, uint8_t VerticalOffset);\nvoid SSD1306_StopScroll(void);<\/pre>\n\n\n\n
typedef enum\n{\n\tSCROLL_EVERY_5_FRAMES,\n\tSCROLL_EVERY_64_FRAMES,\n\tSCROLL_EVERY_128_FRAMES,\n\tSCROLL_EVERY_256_FRAMES,\n\tSCROLL_EVERY_3_FRAMES,\n\tSCROLL_EVERY_4_FRAMES,\n\tSCROLL_EVERY_25_FRAMES,\n\tSCROLL_EVERY_2_FRAMES\n} scroll_horizontal_speed;<\/pre>\n\n\n\nvoid SSD1306_StartFadeOut(uint8_t Interval);<\/pre>\n\n\n\n
void SSD1306_StartBlinking(uint8_t Interval);<\/pre>\n\n\n\n
void SSD1306_StopFadeOutOrBlinking(void);<\/pre>\n\n\n\n
void SSD1306_ZoomIn(uint8_t Zoom);\n<\/pre>\n\n\n\n
![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_normal.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_zoom.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nGraphics library<\/h2>\n\n\n\n
#define GFX_DrawPixel(x,y,color) SSD1306_DrawPixel(x,y,color)\n#define WIDTH SSD1306_LCDWIDTH\n#define HEIGHT SSD1306_LCDHEIGHT<\/pre>\n\n\n\n
\n
I\u00b2C<\/h2>\n\n\n
![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2020\/07\/Nucleo-64-baner.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/11\/oled_i2c_schematic.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/11\/oled_i2c_cube_conf_100k-1.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frametime_100k.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frametime_400k.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frametime_1000k.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frametime_100k_DMA.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frametime_400k_DMA.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frametime_1000k_DMA.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frames_100k-300x200.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frames_400k-300x200.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frames_1000k-300x200.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frames_100k_DMA-300x200.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frames_400k_DMA-300x200.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/12\/oled_i2c_frames_1000k_DMA-300x200.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nSPI<\/h2>\n\n\n\n
![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/01\/oled_spi_schematic.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/01\/oled_spi_cube_conf.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/01\/oled_spi_frametime_1250k-1024x203.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/01\/oled_spi_frametime_5000k-1024x203.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/01\/oled_spi_frametime_10000k-1024x203.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/01\/oled_spi_frametime_20000k-1024x203.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/01\/oled_spi_frametime_40000k-1024x203.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nSPI DMA<\/h3>\n\n\n\n
\n
![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/01\/oled_spi_frametime_1250k_DMA-1024x203.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/01\/oled_spi_frametime_5000k_DMA-1024x203.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/01\/oled_spi_frametime_10000k_DMA-1024x203.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n
It won\u2019t get better than this. At 20 and 40 MHz this time is the same. Most likely the surrounding overhead operations like function returns or HAL SPI handling take much longer than transferring the three commands themselves. Nevertheless, the result is impressive.<\/p>\n\n\n\nSo which interface to choose?<\/h2>\n\n\n\n
<\/td> CPU time Poll(ms)<\/th> FPS Poll<\/th> CPU time DMA<\/th> FPS DMA<\/th> Loops DMA<\/th><\/tr><\/thead> I2C 100 kHz<\/td> 109<\/td> 10<\/td> 1.08 ms<\/td> 11<\/td> 331655<\/td><\/tr> I2C 400 kHz<\/td> 27.4<\/td> 36<\/td> 0.3 ms<\/td> 38<\/td> 317300<\/td><\/tr> I2C 800 kHz<\/td> 12.38<\/td> 80<\/td> 0.15 ms<\/td> 81<\/td> 293911<\/td><\/tr> SPI 1,25 MHz<\/td> 8.25<\/td> 104<\/td> 38.37 us<\/td> 102<\/td> 2368545<\/td><\/tr> SPI 5 MHz<\/td> 2.07<\/td> 285<\/td> 28.81 us<\/td> 272<\/td> 1585956<\/td><\/tr> SPI 10 MHz<\/td> 1.04<\/td> 403<\/td> 21.81 us<\/td> 378<\/td> 1098468<\/td><\/tr> SPI 20 MHz<\/td> 0.53<\/td> 507<\/td> 21.81 us<\/td> 477<\/td> 691864<\/td><\/tr> SPI 40 MHz<\/td> 0.27<\/td> 583<\/td> 21.81 us<\/td> 544<\/td> 393303<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n \n
\n
Summary<\/h2>\n\n\n\n