From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <35A33F66-EF03-4659-ABA1-F25082DBFE41@gmail.com> <4657D0DD-A119-4E19-B50D-EBCE5861F9F8@gmail.com> <821cb256954ce0bf4ad389ffe5eafa50@mikro> <54A95F7A-CCA3-42EA-AAFD-08C9B01E9F10@gmail.com> Date: Wed, 1 Jan 2014 11:12:22 +1100 Message-ID: From: Shane Morris To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=f46d04138c29eb34fb04eedd87b1 Subject: Re: [9fans] "gpio device" for Plan 9 Topicbox-Message-UUID: aa780966-ead8-11e9-9d60-3106f5b1d025 --f46d04138c29eb34fb04eedd87b1 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable I do remember some post asking about the status of the GPIO interfacing to the Plan 9 OS some time ago, when you released the temperature readouts, I had some hopes you might go on and address the GPIO functions, of which until your work consisted solely of the serial port for debug purposes - correct me if I'm wrong at any point other members of the list. This of course opens up the Plan 9 OS for control applications - simply to make a control application you read from or write to a file! I hope to implement such an application to, in user space, discipline the free running 1MHz oscillator from a 1PPS signal (thanks for your help on that one Erik!). My next challenge will be to examine the output of a HID device over USB, the Playstation 3 joypad, and integrate that into Plan 9 for the "non-deterministic user interaction." On Wed, Jan 1, 2014 at 11:04 AM, Krystian Lewandowski < krystian.lew@gmail.com> wrote: > I don't mind! I don't think what i did is a major improvement - only some > ideas of a begginer. BCM port in general was a milestone. I'm just trying > to connect dots while learning something - and have some fun with it. > Happy new year for you too. > Krystian > > Wiadomo=B6=E6 napisana przez Shane Morris w dniu= 1 > sty 2014, o godz. 00:16: > > 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 yo= u > for this work. Erik has noted I would get a reasonable accuracy within a > seconds timeframe from the onboard oscillator, and disciplining it is wel= l > within the capabilities of the ARM microcontroller on the RPi board. If y= ou > 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 h= ow > 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 t= o > 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=B6=E6 napisana przez erik quanstrom w dn= iu >> 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 som= e >> > 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 byt= es" >> 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 tryin= g >> 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 >> > > > --f46d04138c29eb34fb04eedd87b1 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable
I do remember some post asking about the status of the GPI= O interfacing to the Plan 9 OS some time ago, when you released the tempera= ture readouts, I had some hopes you might go on and address the GPIO functi= ons, of which until your work consisted solely of the serial port for debug= purposes - correct me if I'm wrong at any point other members of the l= ist.

This of course opens up the Plan 9 OS for control applicatio= ns - simply to make a control application you read from or write to a file!= I hope to implement such an application to, in user space, discipline the = free running 1MHz oscillator from a 1PPS signal (thanks for your help on th= at one Erik!). My next challenge will be to examine the output of a HID dev= ice over USB, the Playstation 3 joypad, and integrate that into Plan 9 for = the "non-deterministic user interaction."


On Wed,= Jan 1, 2014 at 11:04 AM, Krystian Lewandowski <krystian.lew@gmail.co= m> wrote:
I don&rs= quo;t mind! I don’t think what i did is a major improvement - only so= me ideas of a begginer. BCM port in general was a milestone. I’m just= trying to connect dots while learning something - and have some fun with i= t.
Happy new year for you too.
Krystian

Wiadomo=B6=E6 napisana przez Shane Morris <edgecomberts@gmail.com> w= dniu 1 sty 2014, o godz. 00:16:

My ap= ologies for hijacking the thread, it is an interrelated work, and a practic= al example of your work Krystian. In any case, my hat is off to you for thi= s work. Erik has noted I would get a reasonable accuracy within a seconds t= imeframe from the onboard oscillator, and disciplining it is well within th= e 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 t= o 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 uncer= tain of how many "birds" in the Russian constellation are over Au= stralia at any one time, and I am unsure of whether my chosen GPSDO is a GL= ONASS 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 perio= d 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 sync= fs.

Many thanks for entertaining my notions, in any case. H= appy 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=B6=E6 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 sch= eme 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 i= n a sec
>> as well.
>
> it could be that i misunderstood the op's point.  what i unde= rstood from the
> original post was a scheme was envisioned where a user process would p= oll a
> status file to get interrupt status.  if i understood this correc= tly, then providing
> an interrupt file that returns even 0 bytes when there's an interr= upt would be
> an alternative providing interrupt semantics to the up.  there ar= e some
> bits to work out if the user process falls behind, but it's no dif= ferent than a
> network device.
>
> does that answer your question?
>
> - erik
>

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

I’m not even sure what is my point of view. For ISR i was thinking ab= out an interrupt routine writing something (a single byte) to a file when a= n interrupt occurs - writing using functions defined in qio - something sim= ilar to /dev/kprint - reading user process is waiting for new data if i und= erstood the behavior correctly. It is not clear to me how this „0 byt= es” method:
> providing
> an interrupt file that returns even 0 bytes when there's an interr= upt would be
> an alternative providing interrupt semantics to the up
could be implemented and how ioproc is related (how ioread can be wok= en 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 t= rying to figure out how it can be extended in the future, regarding your fe= edback. But if you think it is worth to extend this thread with new informa= tion then that would be great.

Thanks for this discussion!
Krystian


--f46d04138c29eb34fb04eedd87b1--