#BL602 EVB on #NuttX supports one GPIO Input, one GPIO Output and one GPIO Interrupt ... And names them sequentially: "/dev/gpio0", "/dev/gpio1", "/dev/gpio2" ... Which gets super confusing because "/dev/gpio0" doesn't map to BL602 GPIO Pin 0 🤔
https://github.com/lupyuen/bl602_expander#bl602-evb-limitations
What happens when we try to support 23 GPIOs on #PineDio Stack #BL604? Yep the GPIO Names will look really messy on #NuttX RTOS 🤔
https://github.com/lupyuen/bl602_expander#bl602-evb-limitations
All 23 GPIOs are fully wired up on #PineDio Stack #BL604! 😲 Let's simplify #NuttX and rename the GPIOs as "/dev/gpio0" to "/dev/gpio22" ... Easier for devs to create NuttX Drivers 👍
https://github.com/lupyuen/bl602_expander#bl602-evb-limitations
Tracking all 23 GPIOs used by #PineDio Stack #BL604 can get challenging ... We might reuse GPIOs by mistake! 😱 Our #NuttX GPIO Expander shall validate the GPIOs at startup
https://github.com/lupyuen/bl602_expander#check-reused-gpios
Someday our #NuttX GPIO Expander for #BL604 shall validate that the SPI / I2C / UART Pin Functions are correctly assigned to the GPIO Pin Numbers ... So SPI MISO must be either GPIO 0, 4, 8, 12, 16 or 20
https://github.com/lupyuen/bl602_expander#validate-pin-functions
Can we static assert to avoid overheads in nuttx?
(Ie prevent builds with bad allocations)
@Ralim Here's how we might validate the BL602 Pin Functions at Compile Time...
https://github.com/lupyuen/bl602_expander#validate-pin-functions
@lupyuen
Hmm…
If each pin can only be used once, could we flip the arrignment matrix and instead have it always have an entry for each pin, which is either a selected value or hi-z by default; then use kconfig rules to prevent collisions ?
(Not sure, haven't used this much tbqh)
@Ralim Hmmm major Kconfig Conflict between BL602 and ESP32 ... Wonder how the NuttX folks feel about this 🤔
@lupyuen hmm true. I just like having configurations checked at compile time where possible to save iterations of testing :)