Re: [9fans] "gpio device" for Plan 9

[Shane Morris <edgecomberts@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4002 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4781 bytes --]