>From: "Witold J. Wnuk" <witek@wnuk.eu.org>
>To: Herb Peyerl <hpeyerl@beer.org>, Jason R Thorpe 
><thorpej@wasabisystems.com>
>CC: tech-kern@netbsd.org
>Subject: Re: RFC: General purpose "general purpose i/o pin" framework
>Date: Wed, 14 Aug 2002 09:28:24 +0000
>
>On Tuesday 13 August 2002 12:36, Herb Peyerl wrote:
> >
> > The icing on the cake would be some sort of uploadable filter language
> > that can define a state machine implemented by the kernel. Then it'd
> > be a no-brainer to build an SPI filter... Or, say, a BDM filter that
> > gets attached to the PC Parallel port GPIO driver.  Shouldn't be
> > too hard to put a vhdl parser in the kernel. :-)
>
>Something like /dev/bpf program interpreter but more fool proof... Ability 
>to,
>for example, reliably program all these in-circuit-programmable
>microcontrollers using parallel port would certainly be welcomed by
>hobbyists.

The ppbus driver from FreeBSD has a microsequence facility: it allows you to 
specify a sequence of operations to control the lines on the parallel port 
specifically (i'm not sure how it does to specify pulses though, although I 
*think* it uses DELAY() if it does implement this).

>
>Alternatively - a /dev/music-like sequencer device (with additional pin
>transitions recording and/or timed sampling capability) should suffice in
>most cases and perhaps would be little easier to implement.
>
>How to get timing more precise than callout or tsleep in NetBSD kernel?

DELAY()? Busy-looping basically.

>
>
>Uploadable programs could also (more or less) solve interrupt problem - 
>they
>would be always handled in kernel. This means that Jason could forget about
>them in first phase (the basic functionality phase - sufficient for
>everything but more complicated protocols).

The microsequenec thing doesn't even handle interrupts I think.....


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com