PocketBeagle2 M4 enable GPIO #88731
PocketBeagle2 M4 enable GPIO #88731
Conversation
github-actions
bot
added
area: Samples
github-actions
bot
requested review from
con-pax,
glneo,
jadonk,
kartben,
nashif and
vaishnavachath
| @@ -14,4 +14,12 @@ | |||
| mcu_uart0_tx_default: mcu_uart0_tx_default { | |||
| pinmux = <K3_PINMUX(0x0018, PIN_OUTPUT, MUX_MODE_0)>; | |||
| }; | |||
|
|
|||
| P2_09_D4_gpio: P2-09-D4-gpio-pins { | |||
There was a problem hiding this comment.
To me, D4 is a comment and not something a user should need to look-up/remember. It seems like all the header pins should be defined and set all needed pinmuxes for that pin.
There was a problem hiding this comment.
This is the style we are following in beagle devicetrees.
The reason is a lot of pins can be muxed in multiple ways, even for the same functionality. And it is possible to damage the hardware if you do it incorrectly.
Even for just MCU domain, P2.11 can be muxed as MCU_SPI0_CS2 and MCU_SPI1_CS2. Hence, we need to keep it part of the name.
| compatible = "gpio-leds"; | ||
|
|
||
| led0: led_0 { | ||
| gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; |
There was a problem hiding this comment.
Should there be definitions that can be used that are based on the header pins? What is the standard practice? This feels arduous for users.
There was a problem hiding this comment.
This is the standard practice for now.
It is possible to use gpio-nexus nodes, at least on linux to provide a better numbering, but until we have a "connector" in dt, it does not make sense to use it. Also I do not know if ZephyrRTOS supports nexus nodes right now.
|
|
||
| / { | ||
| aliases { | ||
| led0 = &led0; |
There was a problem hiding this comment.
Is this proper regarding tabs/spaces?
There was a problem hiding this comment.
I am using tabs, which I think is correct. And there are no errors in CI.
There was a problem hiding this comment.
why are you not making the LED definition part of the board's main devicetree? this way it can be used "for free" in other samples etc?
There was a problem hiding this comment.
The pin is not an internal LED. It is a normal header pin.
There was a problem hiding this comment.
but the board has user LEDs, does it not? that's what people expect to use with blinky -- and I guess I am effectively making the same comment as @jadonk, it doesn't seem to make sense to add a "random" overlay where user would just have to guess that they're supposed to hook up an LED to an undocumented header pin?
There was a problem hiding this comment.
The on-board LEDs are on Main domain, which I don't think M4 has access to.
If there is a place to document which pin is being used, I can do that.
Do note that M4 is essentially a co-processor on PocketBeagle 2. Hence, any pin used by the M4 should not be enabled for use in Linux. So, using almost anything (even default UART) requires documentation to ensure that those pins are disabled in Linux.
- Define pinmux for using P2.9 and P2.11 as MCU_GPIOs. Signed-off-by: Ayush Singh <[email protected]>
Use PocketBeagle 2 P2.09 pin as LED GPIO in this example Signed-off-by: Ayush Singh <[email protected]>
Tested blinky example on pin P2.09 Signed-off-by: Ayush Singh <[email protected]>
- The board currently shows up as none in the rendered docs. So fix it. Signed-off-by: Ayush Singh <[email protected]>
Ayush1325
force-pushed
the
zephyr-m4-gpio
branch
from
0107bed to
617c25f
Compare
Tested GPIO with blinky sample on pin P2.09
Also added pinmux for P2.11 as GPIO pin.