Skip to content

Working with STM32U575; DMA transfer functionality added #93

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

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

somesh-audioinventions
Copy link

Ported to work with Nucleo-U575ZI-Q. Added functionality for DMA transfers through 4-wire SPI, utilising a statemachine and TxCpltCallback.

@afiskon
Copy link
Owner

afiskon commented Jan 24, 2025

Thanks for your PR. I have a couple of questions / observations:

  • Are there any measurable benefits of using DMA for SSD1306?
  • I don't think your patch should change ssd1306_conf_template.h except for adding commented DMA options
  • extern int use_dma; in ssd1306.h doesn't look right to me. I should be able to build non-DMA versions of the library as before, as it's currently done for I2C/SPI

@somesh-audioinventions
Copy link
Author

Thanks @afiskon, taking your points in reverse order:

  • extern int use_dma; was mistakenly left in. Taken out now.
  • I've verified that your library works natively with a STM32U5 processor. Is it worth leaving that in as an option? I've removed some other changes
  • It's definitely a benefit for processors that have a heavy load, I would have thought, especially if you're not using an RTOS and the processor is stuck behind polling SPI transactions. If you're not convinced, I can try and measure instruction counts between the two mechanisms, or alternatively leave the DMA mechanism out of the pull request

@afiskon
Copy link
Owner

afiskon commented Jan 30, 2025

extern int use_dma; was mistakenly left in. Taken out now.

👍

I've verified that your library works natively with a STM32U5 processor. Is it worth leaving that in as an option? I've removed some other changes

This part is fine.

It's definitely a benefit for processors that have a heavy load, I would have thought, especially if you're not using an RTOS and the processor is stuck behind polling SPI transactions. If you're not convinced, I can try and measure instruction counts between the two mechanisms, or alternatively leave the DMA mechanism out of the pull request

Practice shows that new features put noticeable burden on the maintainer, that's me. See for instance the recent bug report #94 And I don't have that much spare time, this library is just my pet project implemented many years ago and for some reason people happened to like :)

So yes, I would very much appreciate if you could demonstrate a measurable benefits of this PR before I accept it. Or alternatively you can always maintain your own fork.

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