Fix DMA to SPI transmits on RP2350

[hb9cwp]

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.

[eliasnaur]

Why export these? They're useful, sure, but do they belong in the machine package from the perspective of importing packages?

[hb9cwp]

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?

[deadprogram]

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.

[eliasnaur]

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.

[hb9cwp]

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.

[hb9cwp]

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"
	...

[eliasnaur]

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"
	...

These constants are internal implementation details. Why should they be exported?

[eliasnaur]

Ditto.

[deadprogram]

Looks like the new files need to have go fmt run on them, if you please:

Unformatted:
  src/device/rp/rp2040-plus.go
  src/device/rp/rp2350-plus.go
make: *** [GNUmakefile:185: fmt-check] Error 1

[deadprogram]

Thanks for the format fixes @hb9cwp

Only suggestion I have left is perhaps name the new files src/device/rp/rp2040-bitfields.go to match the sam files.

[hb9cwp]

@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 -const first, then contemplated more generic -bis, -extra, or -plus that stipulate extensions of the generated files. Because later, we might also include additional types/classes and functions/methods, much like the generated files. Unless we add those to additional files with specific suffixes rp2nnn-xyz.go?

[deadprogram]

@hb9cwp I think -extra would be my personal choice of the options, now that you have explained your thinking. Whichever we end up with here, we should consider changing the names of the existing similar files to match.

[deadprogram]

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.