From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 29 Dec 2013 17:34:19 -0500 To: 9fans@9fans.net Message-ID: <54bcd5aa745b69e3cf73fbe39ca499bf@brasstown.quanstro.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] "gpio device" for Plan 9 Topicbox-Message-UUID: a97766a6-ead8-11e9-9d60-3106f5b1d025 > Using slightly modified (unmodified in most cases) uartmini.c GPIO func= tions i implemented #G/gpio device: > Structure is as follows: > #G/gpio/ > /bcm/ ... > /board/ ... > /wpi/ ... > /OK >=20 > - bcm uses board revision specific pin numbering > - board uses human readable pin addressing (board revision agnostic) > - wpi uses wiringPi pin assignment (board revision agnostic) > - OK pin can be used to switch on/off OK LED on the board >=20 > Each directory above contains files that are mapped to pins. > Maybe it is an overkill, i don=E2=80=99t know. first off, cool! #G seems fine to me. it might be just as well to just export only the board wiring, letting something in the boot-time configuration set this up. seems worth implementing uartmini (and spi) on top, and allowing group pin allocation to support this. - erik