----- Original Message ----- From: "Jachym Holecek" <freza%liberouter.org@localhost>
To: "Jesse Off" <joff%embeddedARM.com@localhost>Cc: "Werner Backes" <werner%bit-1.de@localhost>; "Hubert Feyrer" <hubert%feyrer.de@localhost>; <tech-embed%netbsd.org@localhost>
Sent: Friday, March 04, 2005 1:01 PM Subject: GPIO abstraction [was "Re: wscons on a HD44780"]
Hi, sorry for replying *so* late.[... bitbang PC/104 bus ...] PC/104 bus to give the embedded systems designer more GPIO. As processor power in embedded systems increase, it also becomes feasible to implement an entire bit-banged ISA/PC104 bus with nothing but GPIO.I'd just glue an gate array on the board and let it deal ;-).I've been toying with the idea of attempting a full abstraction of GPIO(aka bit-bang) buses for devices such as LCD's and keypads. Drivers wouldregister their pins and their capabilities (in, out, in/out, open-collector, pull-up/down resistors, current capabilities, TTL/CMOS levels, etc...) and then drivers like the hitachi LCD and matrix keypadscould just be generically attached. The code I wrote for the TS7200 could then just as well work for a PC and its parallel port. I could be gettingahead of myself here though... :-)I very much like this idea, and I've actually used a "pinbus" concept in one project (targeted at JTAG and low-level circuit debugging[*]). As you note, this could be used to "normalize" all the bitbang APIs NetBSD has as of now (MII, I2C, ..., serial EEPROMs).
I've since noticed OpenBSD implemented something very similar to what is being discussed here in their gpio(4) driver.
"pinbus" sounds like exactly the perfect word for the abstraction. A wishlist item that I'd like to see enabled is the general attachment of certain pins to full devices and functions such that a "pinbus" could be attached at bootup and then individual pins could be arbitrarily aggregated into devices that could be "hot-plugged" e.g. a matrixkp, hd44780 LCD, serial-port, SPI-based ADC's. Remaining pins might be assigned to a generic OpenBSD style gpio(4) device for user programs to twiddle. I was initially thinking that providing the information such as which pins have pullups, 5V or 3.3V levels, etc would be useful for either the userspace program that uses gpio(4) or in the pinbus sub-device probe to assure that the matrixkp, hd44780 LCD etc can actually use the pins its being told to use. True, this is not likely something you can change under software control, but it is valuable information that could be provided au-gratis by the pinbus provider.
I would really love to see NetBSD start distinguishing itself more in the embedded world by providing more functionality like this that might be of more practical use to embedded. Another thing that would be great is a general API for high frequency low-latency timers. Something such that some devices would be providers of timing hardware and and the timers could be allocated, used and deallocated by device drivers. Extra hardware timers might be "emulated" using the one-shot modes of a single real timer. I'd like MD timers that can bypass as much of the normal IRQ preamble as possible such that if I wanted to use a GPIO pin to generate a 10Khz square wave in software on a 200Mhz processor with a 4 insn intr handler, it'd be possible.
I'm also not sure how much time I have to implement something like this, but maybe I can bribe some extra help with free TS-7200 boards... :-)
//Jesse Off