Add DMA engine to write the display buffer into the Display #20
Conversation
Instead of encoding font properties in the bitmap buffer, Encode them in a struct, thus removing magic numbers in the code
When using the built in font, it creates a conflict in the linker as the symbol font5x8 is defined twice (once in the executable and once in the 'library'. As this is a fairly trivial wrapper, the user can recreate it with their 'default' font for the project.
Instead of having the CPU Idle while the Data is being transfered to the Display, Use the DMA engine to transfer display buffer into the I2C peripheral. allowing the CPU time to be used otherwise. The use of the DMA needed to change the way the peripheral is initialized. Most of the data initialization is done via a Macro that sets up all the necessary data in the display struct. To initialize the display, the ssd1306_init function still needs to be run. The define also changes the implementation of the 'ssd1306_show' function to use the DMA instead of 'fancy_write' Also add commands to the CMakeLists.txt file of the example to allow for changing the compile Define on the target.
The example is modified so that during build time DMA mode may be selected or standard mode. Due to a small added delay due to copying data into the DMA tx buffer the sleep time needed to be increased to eliminate tearing.
|
I have also worked on a blitting function that should speed up the way text is drawn into the buffer. |
|
Oh wow, very cool! Thank you! I'm currently on vacation but I will come back home tomorrow and then check your code out. |
| * Struct that holds a font and all relevant information | ||
| */ | ||
| typedef struct { | ||
| uint16_t bytes_per_char; // the size of the char sprite in bytes (including padding) |
There was a problem hiding this comment.
Why are these 16-bit vs the uint8_t they were before? A character greater than 255 doesn't seem likely / useful. Granted the sprite size would be limited to ~45x45 but that doesn't feel very limiting.
There was a problem hiding this comment.
This is the size of the character sprite, so the memory used to store the bitmap of the character. If a font is large, it very well might take more than 255 bytes to store the sprite in. (The display is 128x64 -> 128 x 8 bytes -> 1024 bytes large (which may all be a single char sprite) this means we need more than 255 bytes in extreme cases. Given that the pico can do 32bit load and store and we have plenty of ram i dont think a single byte per font element would matter much.
So this is a bit of a large pull request, as it combines two changes.
removes magic numbers (the indices of the font metadata in the font buffer) from the code replacing them with the name of the struct members.