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 an example of a compressed DMA frame buffer #2238

Closed
wants to merge 1 commit into from

Conversation

Dominaezzz
Copy link
Collaborator

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

  • I have updated existing examples or added new ones (if applicable).
  • I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
  • My changes were added to the CHANGELOG.md in the proper section.
  • I have added necessary changes to user code to the Migration Guide.
  • My changes are in accordance to the esp-rs API guidelines

Extra:

Pull Request Details 📖

Description

Depends on #2191 and #2237.

This example is to showcase what users can do with the DmaTxBuffer trait.
I've added a "compressed frame buffer" (names hard) which shrinks the space/memory required to store a full solid frame buffer for a 320 * 480 screen, from 307,200 bytes down to just 3,840 bytes. You don't even need PSRAM anymore (Of course for more complex images, just using PSRAM for the full frame buffer would be the better choice).

This example is for I8080 but no reason SPI screens can't use this as well.
It is also particularly useful for #2081, where screens don't typically have a frame buffer and chunking is not possible.

The last commit contains the actual changes.

Testing

Ran the example on my devkit.

20240926_125811-ezgif com-optimize

@bugadani
Copy link
Contributor

bugadani commented Sep 26, 2024

This is fun. I don't see much practical use (I only mean for the example demonstrating sending out single color frames or repeating tiles of essentially random size), and for an example you could just hard-code the values IMO, but linking the same buffer multiple times is a good idea and has practical benefits for sure.

@Dominaezzz
Copy link
Collaborator Author

and for an example you could just hard-code the values IMO

Fair, can do.
I left them in just in case someone wanted to try different screen sizes but anyone can figure out the numbers if they want to.

(I'll update once all the dependent PRs have landed)

@Dominaezzz
Copy link
Collaborator Author

Instead of the I8080 example, I'll do it for the RGB driver's example, and probably add the buffer to the hal directly.

@Dominaezzz Dominaezzz closed this Oct 7, 2024
@Dominaezzz Dominaezzz deleted the compressed_buffer branch October 7, 2024 13:04
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.

2 participants