Zephyr master broke frdm_k64f GPIO port naming #665
Comments
|
I'm currently working on updating to the iot-js-api style, and am busy trying to create another C version of the mapping for A101 as a strawman. But maybe I will see the light of doing this in JS. ;) I think we'll have a "zephyr" board that lets you use these generic port/pin names to support boards without a convenience module. But yes this sure proves your point! |
|
Ok, so I submitted a patch to just revert to older FRDM-K64F GPIO naming and it was accepted by its maintainers: https://gerrit.zephyrproject.org/r/11668 . So, that gives us additional time to come up with something, and @grgustaf's your plan in good! In the meantime, can we update deps/zephyr to the HEAD of v1.7-branch to pull this fix (and to be ready to work with Z 1.7 in general for the next Z.js release)? Should I submit a separate ticket on that? |
|
We have updated to 1.7 release so this shouldn't be an issue specifically. However, I can't seem to get any GPIO output pins working so I need to go back to some Zephyr samples and try to see what's going on. Today we theorized that maybe some default configs have changed. |
Zephyr defaults changed around January for this board to no longer set GPIO as default pinmux state for any of the external pins. So we need to override them ourselves. Eventually we may need to get fancier to set pinmux based on what the user's script wants to use the pins for, or set up a default "ABI" for pinmux settings for the board. The pinmux must be set up at board initialization time apparently. Add new zjs_pinmux.c (currently for k64f only) to configure the pinmux settings at initialization time. Add a new prj.conf to enable GPIO port "D". Add new samples GPIOInputs-k64.js and GPIOOutputs-k64.js to quickly demonstrate which pins are functional. With this update, pins D14 and D15 work as outputs for the first time. But pin D8 on my rev E3 board doesn't seem to work as either anymore. Fixes intel#514 and lets us finally see that intel#665 really was resolved. Signed-off-by: Geoff Gustafson <geoff@linux.intel.com>
|
Thanks! I assume I'm in the best position to close it. |
Zephyr defaults changed around January for this board to no longer set GPIO as default pinmux state for any of the external pins. So we need to override them ourselves. Eventually we may need to get fancier to set pinmux based on what the user's script wants to use the pins for, or set up a default "ABI" for pinmux settings for the board. The pinmux must be set up at board initialization time apparently. Add new zjs_pinmux.c (currently for k64f only) to configure the pinmux settings at initialization time. Add a new prj.conf to enable GPIO port "D". Add new samples GPIOInputs-k64.js and GPIOOutputs-k64.js to quickly demonstrate which pins are functional. With this update, pins D14 and D15 work as outputs for the first time. But pin D8 on my rev E3 board doesn't seem to work as either anymore. Fixes #514 and lets us finally see that #665 really was resolved. Signed-off-by: Geoff Gustafson <geoff@linux.intel.com>
They switched to "gpio_porta", "gpio_portb", long ugly strings. Well, just as I argued before, the Zephyr application software can't rely on any particular, and even consistent device naming scheme (sigh). Thanks to my previous patch, I can get my LED linking with "gpio_portb.21", the question what to do with zjs_k64f_pins.c. My kind suggestion is to dismantle all the pin maps from C space, and have k64f_pins.js, a101_pins.js, etc.
The text was updated successfully, but these errors were encountered: