You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2022/03/21 02:26:48 UTC

[GitHub] [incubator-nuttx] robertlipe opened a new issue #5810: GPIO issues on BL602 + suggestions for RISC-V, maybe more.

robertlipe opened a new issue #5810:
URL: https://github.com/apache/incubator-nuttx/issues/5810

1) Some RISC-V architectures have as many as 80 GPIOs. Defining those in KConfigs will be annoying, especially given the current awesome trend of pins being behind a MUX so they can be configured as Inputs, Outputs, or Interrupts. This is a project-wide issue and I don't really know how to fix this.

2) For those arches, the various places defining GPIOs as a bitmask isn't going to work. Since I've discovered that almost all of the current RISC-V targets break over 1 GPIO with only ESP32 reaching 2 as a breaking point, supporting 'only' a long long's of bits isn't terrible.

3) BOARD_NGPIOfoo is defined in the board-specific, configurable board.h. However, they're used in the boards/risc-v/*/*/src/foo_gpio.c files, which are arch-specific and not board-specific. Thus, if you want to add GPIOs, you can't do it solely in boards.h; you have to modify the OS configuration. I have added an example for BL602 on how to at least DEBUG_ASSERT on this configuration error instead of expensive chasing. The basic idea either needs to be hoisted higher into the infrastructure somewhere or repeated into a *bunch* of foo_gpio.c files. Of course, this patch is only relevant until an appropriate design for no.1 here has a better design applied.

4) BL604 supports up to 23 GPIOs; BL602 up to 16. (They're probably the same wafer, just packaged differently.) There are several cases of uint8_t pin = (cfgset & GPIO_PIN_MASK) >> GPIO_PIN_SHIFT; in the code. That's just not going to work for any pin > pin8, though that case has clearly never been exercised in light of no. 3, but I made a patch for that for BL602 that probably helps. Again, this should be in a test case and probably higher level or repeated DEBUG_ASSERTSs to catch it somewhere. src/mpfs/mpfs_gpio.c is almost surely wrong and searching for "8_t.*MASK" elsewhere in the tree brings attention to code that may need inspection. Possible patch attached.

These patches are created by hand (to exclude local changes) and may need hand-fitting, but since they're all one-liners, they should be easy to repair if needed.

gpio.patch addresses the issues in BL602 for GPIO >= 8. at least mpfs needs this, too.
gpio2.patch is inspiration on the bandaid for debug checking that board.h matches *gpio.c. This needs to be ported to every *gpio.c file. Ick. (And nobody is building for RISC-V with a 1989 compiler.. That code is already using designated initializers, which is from C99, which has // comments.)
[gpio.patch.txt](https://github.com/apache/incubator-nuttx/files/8312724/gpio.patch.txt)
[gpio.patch2.txt](https://github.com/apache/incubator-nuttx/files/8312725/gpio.patch2.txt)

Neither of these tries to fix the similar existing problems (def. in ESP-32 and MPFS) elsewhere in the tree.

--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org