My apologies for hijacking the thread, it is an interrelated work, and a practical example of your work Krystian. In any case, my hat is off to you for this work. Erik has noted I would get a reasonable accuracy within a seconds timeframe from the onboard oscillator, and disciplining it is well within the capabilities of the ARM microcontroller on the RPi board. If you were to observe any real drift over the 100usec range, I think you'd be asking for a new board...!

Erik, clocking signals are received, not distributed... or to wit, the US Government distributes the clocking signals for me, by means of the GPS network. I would prefer to use GLONASS of course, but I am uncertain of how many "birds" in the Russian constellation are over Australia at any one time, and I am unsure of whether my chosen GPSDO is a GLONASS receiver. I'm assuming negative answers to both queries, although that is a matter for my own investigation, and in its due time.

As an aside, I have priced Rockwell GPS modules with a 1PPS signal, the princely sum of US$9, free shipping. I thought this may be a good place to start my timing investigations with Plan 9 on the RPi, by seeing if I can get the RPi to consistently clock over a considerable period of time. The next challenge will be to make the whole lot happen "in respect to time" according to the non-deterministic input of the user. That input would be placed in time in both the ramfs, as well as the syncfs.

Many thanks for entertaining my notions, in any case. Happy New Year to you both, and to the rest of the list!

On Wed, Jan 1, 2014 at 9:57 AM, Krystian Lewandowski <krystian.lew@gmail.com> wrote:

Wiadomość napisana przez erik quanstrom <quanstro@quanstro.net> w dniu 31 gru 2013, o godz. 20:50:

> 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
>

I’ll answer at the bottom, to not make even more mess i did before. :)

I’m not even sure what is my point of view. For ISR i was thinking about an interrupt routine writing something (a single byte) to a file when an interrupt occurs - writing using functions defined in qio - something similar to /dev/kprint - reading user process is waiting for new data if i understood the behavior correctly. It is not clear to me how this „0 bytes” method:

> providing
> an interrupt file that returns even 0 bytes when there's an interrupt would be
> an alternative providing interrupt semantics to the up

could be implemented and how ioproc is related (how ioread can be woken up with 0 bytes returned). But now, my mind isn’t quite clear now.

As i said i don’t know much about BCM, Plan 9 and the whole thing and basic GPIO implementation seemed to be a good entry point. Now i’m trying to figure out how it can be extended in the future, regarding your feedback. But if you think it is worth to extend this thread with new information then that would be great.

Thanks for this discussion!
Krystian