On Fri, Apr 26, 2019 at 07:52:48PM +0200, Jan Kiszka wrote: > On 26.04.19 19:46, Manivannan Sadhasivam wrote: > > On Fri, Apr 26, 2019 at 07:39:56PM +0200, Jan Kiszka wrote: > > > On 26.04.19 19:33, Manivannan Sadhasivam wrote: > > > > On Fri, Apr 26, 2019 at 08:20:19PM +0300, Andy Shevchenko wrote: > > > > > On Fri, Apr 26, 2019 at 7:05 PM Jan Kiszka <[email protected]> > > > > > wrote: > > > > > > > > > > > > On 26.04.19 16:42, Enrico Weigelt, metux IT consult wrote: > > > > > > > On 26.04.19 15:36, Jan Kiszka wrote: > > > > > > > > > > > > > > > At the same time, there are no real alternatives - to my> > > > > > > > > knowledge - for the value it brings (various bindings) to simply > > > > > > > switch> the engine. > > > > > > > Which value exactly does that collection of crude wrappers and > > > > > > > broken > > > > > > > attempts to buypass the kernel (driving gpios via /dev/mem > > > > > > > *facepalm*) > > > > > > > provide ? > > > > > > > > > > > > Leaving that blunt hack aside: > > > > > > > > > > > > import mraa > > > > > > > > > > > > pin = mraa.Gpio(13) > > > > > > pin.dir(mraa.DIR_OUT) > > > > > > pin.write(1) > > > > > > > > > > > > And the same goes for nodejs, java and c++. > > > > > > > > > > > > Moreover, this allows you to abstract away where "Pin 13" actually > > > > > > came from on > > > > > > that board if the kernel changes (BSP -> upstream...) or the > > > > > > extension board or > > > > > > ... > > > > > > > > > > The problem here is opaque number. This has to be chip + *relative* > > > > > pin number/ > > > > > See this: > > > > > https://stackoverflow.com/questions/55532410/how-do-linux-gpio-numbers-get-their-values/55579640#55579640 > > > > > > > > > > > > > But for platform like 96Boards we don't need controller specific > > > > lookup, these > > > > are all handled by the platform code [1] so that the users can use the > > > > standard > > > > pinout number to access GPIOs. For instance, pin 23 on the Low Speed > > > > expansion > > > > header is the GPIO for all 96Boards platform, so the user can access > > > > that pin > > > > using 23 itself in the application and it will run across all supported > > > > 96Boards. > > > > > > Can you ensure stable numbering when probing order changes, e.g. due to > > > adding an extension board? > > > > > > > Good point! For tackling this, I'm planning to introduce an API for > > accessing > > the GPIO by its line name. It will be tricky to implement but once done, it > > will serve. > > Whatever is stable and handy. As cited in the other thread, I played with > the device path as well, see [1][2]. Feel free to pick what what is useful, > I will likely not have time to work on that soon again. >
Cool, thanks for sharing :-) Regards, Mani > Jan > > [1] > https://github.com/siemens/mraa/commit/034d787eea1a5b201ea77a6549ffc0bdbc3b776d > [2] > https://github.com/siemens/mraa/commit/6fd8a3c27764718c1e62a4938a6dc88819c3f65f > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux
