Subject: Re: GPIO abstraction [was "Re: wscons on a HD44780"]
To: Jesse Off <joff@embeddedARM.com>
From: Jachym Holecek <firstname.lastname@example.org>
Date: 03/05/2005 02:29:57
> >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.
Hmm, looks good. Linux happens to have something similar (umm, an ad-hoc
hack, really) on Axis' CRIS (ETRAX100LX processor) port. Btw, anyone
happens to have a port to this platform?
> "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.
What I did was to handle pin-mapping inside locators (my userland thing
was "of course" closely modelled after NetBSD driver infrastructure :-).
This restricted devices to only be able to use parent's pins, which I now
realize is an unjustified limitation. So locators don't seem to be the right
way -- we'll probably need something like "global routing matrix".
> [... providing electrical details in the API ...]
> 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.
Ok, often "electrical specs" for a pin may end up unknown, which the
consumers could just treat as "It's fine, user knows what he's doing".
> 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.
Totally agreed, given I would have real-world use for such features
> Another thing that would be great is a general API for high frequency
> low-latency timers. [...]
Don't know about the latency part, but as far as API is concerned,
this might end up being related to my other spare time project of
implementing a VHDL-like "reactive/signal based" paradigm inside the
kernel. My primary motivation was to provide more expressive way of
describing conditions upon which a kcont(9) should be run -- currently,
this seems to only be bound to "particular IPL or below". Note that the
idea occurred to me just a few days ago and I didn't yet properly look
whether it even makes sense...
Anyway, I'll give this more thought.
> 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... :-)
-- Jachym Holecek