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 <quans...@quanstro.net>wrote: > On Tue Dec 31 14:40:29 EST 2013, edgecombe...@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 > >
