Re: GPIO abstraction [was "Re: wscons on a HD44780"]

[Jachym Holecek <freza%liberouter.org@localhost>]

Hi,

> >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
myself. :-)

> 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... :-)

:-)

        Regards,
                -- Jachym Holecek