Certainly, that answers my question.

Of things interrelated, I wish to sample a 10kHz square wave into a GPIO,
which I am certain the RPi will do, see my earlier post with link to RPi
forums. This will be a constant signal (an output of a GPSDO, with
potentially a rubidium oscillator backup). So while the 10kHz is constant,
the users input is not, and I wish to correlate in time the users input to
the rising edge of the 10kHz signal, as it is then to be sent over a
network with the time data of the event.

Obviously, one would need to "trim" events (so, no interrupt file of 0
bytes being transmitted) if no user input was received. This is merely to
minimise network overheads.

I could be wildly off here Erik in my way of thinking, but my motivation is
to extend the syncfs module to correlate precisely in time. The example
system used by the Indiana University had no synchronisation across the
network - presumably the only synchronised filesystem was the local
filesystem on the cart robot? I will also be writing some kind of memory
bounding for the ramfs. So, the events themselves are asynchronous and
non-deterministic, however the clock source against which the events are
placed in time is deterministic, and allows for easy reference and auditing.

Perhaps there is a better way of doing this, I am not sure. Remember, I am
an outsider to Plan 9 ways of thinking, although I am mostly unspoiled by
Linux ways of thinking. To be precise, my ways of thinking are MSDOS, if
that is at all possible in this day and age. I accept any and all better
suggestions.


On Wed, Jan 1, 2014 at 6:50 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Tue Dec 31 14:40:29 EST 2013, edgecomberts@gmail.com wrote:
>
> > Erik,
> >
> > Just for the purposes of edification (and curiosity), are you able to
> > elaborate on "long reads"? Its understandable such a scheme would be
> > implemented in the network drivers, but how exactly does it work, as
> > opposed to a polling scheme or an ISR? I will, of course, Google in a sec
> > as well.
>
> it could be that i misunderstood the op's point.  what i understood from
> the
> original post was a scheme was envisioned where a user process would poll a
> status file to get interrupt status.  if i understood this correctly, then
> providing
> an interrupt file that returns even 0 bytes when there's an interrupt
> would be
> an alternative providing interrupt semantics to the up.  there are some
> bits to work out if the user process falls behind, but it's no different
> than a
> network device.
>
> does that answer your question?
>
> - erik
>
>