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

rp2040 SPI0 variable is a pointer and not struct #4663

Open
irai opened this issue Dec 17, 2024 · 4 comments
Open

rp2040 SPI0 variable is a pointer and not struct #4663

irai opened this issue Dec 17, 2024 · 4 comments
Labels
rp2040 RP2040 (Pi Pico, RP2040 Feather, etc)

Comments

@irai
Copy link

irai commented Dec 17, 2024

I am developing for the RPI Pico and noticed that the definition of the SPI0 & SPI1 variables are pointers to the SPI struct. This differ to the SPI0 definition for generic boards, which is simply a struct. As a result the following code compiles with target=pico but does not compile if target is generic/wasm.

func main() {
	machine.SPI1.Configure(machine.SPIConfig{
		SDO: machine.GP15, // default SDO pin - TX
		SCK: machine.GP14, // default sck pin
		SDI: machine.GP28, // default sdi pin
		Frequency: 10000000,
	})
	driver = max72xx.NewDevice(*machine.SPI1, machine.GP13) // Selector
       // compiler error if target is generic

This is because the declaration of SPI0 is different depending which tag you use:
machine/machine_rp2040_spi.go

// SPI on the RP2040
var (
	SPI0  = &_SPI0
	_SPI0 = SPI{
		Bus: rp.SPI0,
	}
	SPI1  = &_SPI1
	_SPI1 = SPI{
		Bus: rp.SPI1,
	}
)

machine/machine_generic_peripherals.go

var (
	UART0 = hardwareUART0
	UART1 = hardwareUART1
	SPI0  = SPI{0}
	SPI1  = SPI{1}
	I2C0  = &I2C{0}
)

It would be more consistent for rp2040 SPI to also be a struct, not a pointer. unless you know a particular reason why this is like that.
Happy to submit a change request if the change makes sense.

@aykevl
Copy link
Member

aykevl commented Dec 19, 2024

I think we will eventually want to convert all SPI objects to use pointers instead, like we did for I2C a long time ago. See: #1693

@aykevl
Copy link
Member

aykevl commented Dec 19, 2024

The best way to fix this for now would be to use drivers.SPI instead of machine.SPI in the max72xx driver (meaning the max72xx driver should be fixed).

@irai
Copy link
Author

irai commented Dec 19, 2024

The best way to fix this for now would be to use drivers.SPI instead of machine.SPI in the max72xx driver (meaning the max72xx driver should be fixed).

That makes sense. In my local environment, I updated the max72xx driver to support multiple maxis in series (up to 8) and was planning to submit a PR in future. So I will include this change.

I wasn't aware of a drivers.SPI interface and am wondering if there a reason for a machine.SPI and a drivers.SPI? I noted they are different types, a struct vs interface. Possibly just legacy evolution...

@irai
Copy link
Author

irai commented Dec 20, 2024

@aykevl to add support to multiple max72xx in series, I would need to make small function signature changes. Would you accept small breaking code for the max72xx or do you prefer that I create new functions? For example,

  1. change NewDevice and WriteCommand to add the device number :
func NewDevice(bus drivers.SPI, cs machine.Pin, n uint8) *Device
func (driver *Device) WriteCommand(device uint8, register, data byte)
  1. or create a new functions such as
func NewDeviceN(bus drivers.SPI, cs machine.Pin, n uint8) *Device
func (driver *Device) WriteCommandN(device uint8, register, data byte)

in (1) the users would have to make some small modifications to their code to identify how many devices they have.

@deadprogram deadprogram added the rp2040 RP2040 (Pi Pico, RP2040 Feather, etc) label Dec 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rp2040 RP2040 (Pi Pico, RP2040 Feather, etc)
Projects
None yet
Development

No branches or pull requests

3 participants