Skip to content
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

Add DMA engine to write the display buffer into the Display #20

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

Phylex
Copy link

@Phylex Phylex commented Mar 16, 2024

So this is a bit of a large pull request, as it combines two changes.

  1. a modification to the fonts that adds a struct to the font definition and
    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.
  2. Add a build time flag to allow to use the DMA engine in the Pi to transfer the data to the display buffer instead of doing this with blocking routines of the i2c part of the SDK.

Phylex and others added 12 commits March 10, 2024 20:20
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.
@Phylex
Copy link
Author

Phylex commented Mar 16, 2024

I have also worked on a blitting function that should speed up the way text is drawn into the buffer.

@daschr
Copy link
Owner

daschr commented Mar 16, 2024

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)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants