notro/pico-usb-io-board

Raspberry Pi Pico USB I/O Board

pico-usb-io-board's Issues

gpio interrupts are not fired

Hi there!
I had a problem with GPIO interrupts not getting fired and had to make some code changes to make it work:

void dln2_gpio_init(void)
{
    // It's not possible to just set the callback, so use the board led as a dummy gpio
    // gpio_set_irq_enabled_with_callback(25, 0, false, &dln2_gpio_irq_callback);
    gpio_set_irq_callback(&dln2_gpio_irq_callback);
    irq_set_enabled(IO_IRQ_BANK0, true);
}

I am using Ubuntu 22.04 with arm-none-eabi-gcc 12.2.0 and pico-sdk from git master. The board is a Waveshare RP2040-Zero.

Thanks for this nice project!

spi mode

Hello, god i love and use all your projects! Simply amazing thank you! So i assumed i would have to add a device tree section for the spi mode to work but plugged it in anyway to see. It gave a couldnt shutdown or turn off spi controller error (cant remember the exact warning) and depending if it needed platform data to perform that task that maybe the expected outcome...(it gave that error first half dozen times now its, failed to enable spi module, dunno why the change)Can you confirm? Im very very green at programming but have been gaining a little experience with usb to spi/i2c/gpio devices and kernel drivers(nice to see a new example). i have a working usb to i2c (uses tiny-usb driver) and gpio with irq (my kernel drivers) on stm32f1/f4 but havent tackled spi except with ftdi mpsse devices. Ive found the official device tree method cumbersome, time consuming and irritating. Ive come to prefer a platform driver passing the required platform info and init method. I was wondering if you have been using the device tree etc? Very interested in what/how someone as talented as yourself goes about it. Ill be tackling adding the spi platform data via sysfs for "on the fly enumeration" on mpsse driver soon but havent flushed out what methadology to use yet. I may use this firmware and a new platform/edit mfd, as a second testbed as well. Again thank you!

devicetree overlay

Hello good sir. Im still trying to figure out the best (apparently gonna be non standard) way of passing platform data to my usb to i2c/spi etc devices. Your wiki for the devicetree info (awesome btw ty!) Im a little confused. I know combined modes are for simple bus devices with a single interface etc. Im just not sure If your pc was getting a phandle and setting it up without you supplying and devicetree data, or if the overlay in the writeup was an upgrade/update to a simple bus version? I havent seen it written as such but I guess since the two are combined/sharing it would be kinda like auto conf a phandle for yeah. Curious if a overlay fragment could add more interfaces or whatever and continue to share the handle. Ive tried all kinds of things most recently hacked in a live overlay interface into my drivers directly So no need to patch the kernel. Much Like your fdt_loader I just now seen. Yours may actually fill a gap I had being limited to overlays by allowing pdata as firmware files! Again you write the best stuff. That seems more reasonable when switching between x86 and arm. The other approach I like but probly just cuz I used it the most is have a usb driver setup the pdata then load its companion platform driver and pass that info off. I havent written any true mfd drivers but they look very similar in concept minus the data passing, probly trivial to add. Ive been getting something similiar going on my h7 with ulpi like your dln2 pico project. gpio/irq/spi/i2c/adc all work with kernel drivers, It needs some tlc but haven't implemented the platform stuff yet. Its written in libopencm3 so the usbhs and m4core booting etc (plus unfortunate amount more) was forrest gumped by myself (so its probly suspect lol) . But so little info on such devices and even less when you bring in kernel drivers. Thats why ive bothered you here a second time which I apologize for. I realize my project is beneath you but if your aware of anyone or even decent resources like examples and such Im all ears my friend :) And since i saw you used compression so successfully on pico with gud, well I just gotta try it on something cool. Im sure I can get something going faster then usbhs adc/spi something and give her hell. Thank you again. Just came to me I never looked by the dln2 is just a single interface? Guess not that suprising.

GPIO25 (LED) works, all others GPIOs don't

Got the project working on the Rpi Pico, with Ubuntu Kernel 6.2.0-39.
For now I'm accessing the GPIOs using gpioset. This works for the green onboard LED:
$ gpioset dln2 25=1
$ gpioset dln2 25=0
but does not do anything for the other GPIO pins.
They do get set to "Output" automatically when writing to them, as gpioinfo shows, but they do not go high (measured with Multimeter).
Attaching an LED via 330R to GND, I can very briefly see the LED flash when setting the GPIO pin to high - but that's it.
Any suggestions or ideas what might go wrong here?

GPIO Pins 4, 5, 17 result in IO errors

Board mostly works, but I found that some GPIO pins can't be accessed, specifically: Pins 4, 5, 17.
When trying to read or write to them, I get an IO error.
In effect, I get the same behavior for 4,5,17 as I get for GPIOs 23 and 24, but for the latter ones this is understandable, since they are special GPIOs and filtered out in main.c ("unavail_pins").

How to reproduce:

$ gpioset dln2 22=1 # this works
$ gpioset dln2 4=1
gpioset: error setting the GPIO line values: Remote I/O error

Running gpio info shows that Pin 4 has not been set to output either, despite the above gpioset command:

	line   4:      unnamed       unused   input  active-high 
        [...]
	line  22:      unnamed       unused  output  active-high 

The dmesg and Kernel logs show no error messages.

I also did an strace to make sure there's nothing funky going on in user land, but it all looks fine:

22843 openat(AT_FDCWD, "/dev/gpiochip1", O_RDWR|O_CLOEXEC) = 4
22843 newfstatat(AT_FDCWD, "/dev/gpiochip1", {st_mode=S_IFCHR|0660, st_rdev=makedev(0xfe, 0x1), ...}, AT_SYMLINK_NOFOLLOW) = 0
22843 newfstatat(AT_FDCWD, "/dev/gpiochip1", {st_mode=S_IFCHR|0660, st_rdev=makedev(0xfe, 0x1), ...}, 0) = 0
22843 access("/sys/bus/gpio/devices/gpiochip1/dev", R_OK) = 0
22843 openat(AT_FDCWD, "/sys/bus/gpio/devices/gpiochip1/dev", O_RDONLY) = 5
22843 read(5, "254:1\n", 15)            = 6
22843 close(5)                          = 0
22843 ioctl(4, GPIO_GET_CHIPINFO_IOCTL, {name="gpiochip1", label="dln2", lines=29}) = 0
22843 close(3)                          = 0
22843 ioctl(4, GPIO_GET_LINEINFO_IOCTL, {line_offset=4} => {flags=0, name="", consumer=""}) = 0
22843 ioctl(4, GPIO_GET_LINEHANDLE_IOCTL, {lines=1, lineoffsets=[4], flags=GPIOHANDLE_REQUEST_OUTPUT, default_values=[1], consumer_label="gpioset"}) = -1 EREMOTEIO (Ein-/Ausgabefehler der Gegenstelle (remote))

I built the Pico FW with serial debug output - it prints USB communication debug info to the console for the successful requests, and I also enabled the debug printing in the logs.. but (in contrast to main.c) I haven't got the LOG1 debug printfs from dln2-gpio.c to work, which hinders debugging a bit.

Before spending more hours on this.. is there (again) anything obvious I'm missing here?