Zephyr master broke frdm_k64f GPIO port naming

[pfalcon]

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.

[grgustaf]

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!

[pfalcon]

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?

[grgustaf]

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.

[grgustaf]

#954 makes GPIOs work again so that we can see @pfalcon's Zephyr naming patch is in and working.

[qiaojingx]

Verified with commit f3d587d + #954. This issue is not reproducible.