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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to