----- Original Message ----- 
From: "Jachym Holecek" <freza@liberouter.org>
To: "Jesse Off" <joff@embeddedARM.com>
Cc: "Werner Backes" <werner@bit-1.de>; "Hubert Feyrer" <hubert@feyrer.de>; 
<tech-embed@netbsd.org>
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 
>> would
>> register 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 keypads
>> could 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 
>> getting
>> ahead 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