-
Notifications
You must be signed in to change notification settings - Fork 955
Fix DMA to SPI transmits on RP2350 #4903
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
Conversation
DMA DREQ line numbers for "flow control" between SPI bus and DMA channels on RP2350 differ from RP2040. Tested with st7789 driver for Pico-1.14-LCD from Waveshare on Pico 2W. Without this fix func st7789.tx() blocks indefinitely while attempting to use DMA to SPI transfers.
Specific for RP2350, missing in generated src/device/rp/rp2350.go
Specific for RP2040, missing in generated src/device/rp/rp2040.go
src/machine/machine_rp2_2040.go
Outdated
DMA_DREQ_SPI0_TX = 16 | ||
DMA_DREQ_SPI0_RX = 17 | ||
DMA_DREQ_SPI1_TX = 18 | ||
DMA_DREQ_SPI1_RX = 19 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why export these? They're useful, sure, but do they belong in the machine
package from the perspective of importing packages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why export these?
Because the generated src/device/rp/rp2040|rp2350.go
don't provide them, and they are global and specific for these processors as well.
but do they belong in the machine package
What alternatives do you propose which would be a better fit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See https://github.com/tinygo-org/tinygo/blob/release/src/device/sam/atsamd51x-bitfields.go for example of how to handle values that are not part of the files generated from the SVDs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why export these?
Because the generated
src/device/rp/rp2040|rp2350.go
don't provide them, and they are global and specific for these processors as well.but do they belong in the machine package
What alternatives do you propose which would be a better fit?
For every exported API the question should be: what are the use cases for outside users? If there's no identifiable outside need, it's better to keep the API unexported and deal with isssues such as naming, other platforms etc. when the need arises.
If you or some other maintainer (@soypat?) decide to export anyway, I suggest package device/rp
. The machine
package is for abstractions across a wide range of hardware, and I know of no restriction that say device/rp
is for machine generated code only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, device/rp
would be a good place, similar to device/tkey
or device/riscv
for example.
Unfortunately, it is currently excluded by .gitignore. It would be helpful to have also generated *.go and *.s files in the repo that are versioned. This would facilitate searching and automatic cross-referencing, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved the additional global constants for DMA to device/rp/rp2nnn0-plus.go
, see refactoring below.
But I did not touch some other lines in src/machine/machine_rp2_2nnn.go
that could be refactored as well, such as:
const (
cpuFreq = 150 * MHz
_NUMBANK0_GPIOS = 48
_NUMBANK0_IRQS = 6
rp2350ExtraReg = 1
_NUMIRQ = 51
notimpl = "rp2350: not implemented"
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved the additional global constants for DMA to
device/rp/rp2nnn0-plus.go
, see refactoring below. But I did not touch some other lines insrc/machine/machine_rp2_2nnn.go
that could be refactored as well, such as:const ( cpuFreq = 150 * MHz _NUMBANK0_GPIOS = 48 _NUMBANK0_IRQS = 6 rp2350ExtraReg = 1 _NUMIRQ = 51 notimpl = "rp2350: not implemented" ...
These constants are internal implementation details. Why should they be exported?
src/device/rp/rp2350-plus.go
Outdated
// Hand created file. DO NOT DELETE. | ||
// Definitions that are missing in src/device/rp/rp2040.go generated from SVDs | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto.
Looks like the new files need to have
|
Thanks for the format fixes @hb9cwp Only suggestion I have left is perhaps name the new files |
@deadprogram Thanks for re-launching the tests. Yesterday, I could not figure out why one failed. Eventually #4898 is affected as well. About the naming, I was considering |
@hb9cwp I think |
Thank you for adding this @hb9cwp and for making all the requested changes. Also, thanks @eliasnaur for your in-depth reviews and feedback! Now squash/merging. |
DMA DREQ line numbers for "flow control" between SPI bus and DMA channels on RP2350 differ from RP2040. Tested with st7789 driver for Pico-1.14-LCD from Waveshare on Pico 2W. Without this fix func st7789.tx() blocks indefinitely while attempting to use DMA to SPI transfers, see #4690.