From mboxrd@z Thu Jan 1 00:00:00 1970 From: Krystian Lewandowski Content-Type: multipart/alternative; boundary="Apple-Mail=_4E450446-88B1-4446-A546-DA19ECA9FE78" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Wed, 1 Jan 2014 01:04:54 +0100 References: <35A33F66-EF03-4659-ABA1-F25082DBFE41@gmail.com> <4657D0DD-A119-4E19-B50D-EBCE5861F9F8@gmail.com> <821cb256954ce0bf4ad389ffe5eafa50@mikro> <54A95F7A-CCA3-42EA-AAFD-08C9B01E9F10@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: Subject: Re: [9fans] "gpio device" for Plan 9 Topicbox-Message-UUID: aa721a92-ead8-11e9-9d60-3106f5b1d025 --Apple-Mail=_4E450446-88B1-4446-A546-DA19ECA9FE78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1250 I don=92t mind! I don=92t think what i did is a major improvement - only = some ideas of a begginer. BCM port in general was a milestone. I=92m = just trying to connect dots while learning something - and have some fun = with it. Happy new year for you too. Krystian Wiadomo=9C=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 = 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...! >=20 > 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. >=20 > 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. >=20 > Many thanks for entertaining my notions, in any case. Happy New Year = to you both, and to the rest of the list! >=20 >=20 > On Wed, Jan 1, 2014 at 9:57 AM, Krystian Lewandowski = wrote: >=20 > Wiadomo=9C=E6 napisana przez erik quanstrom w = dniu 31 gru 2013, o godz. 20:50: >=20 > > 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 > > >=20 > I=92ll answer at the bottom, to not make even more mess i did before. = :) >=20 > I=92m 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 =840 bytes=94 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=92t quite clear = now. >=20 > As i said i don=92t know much about BCM, Plan 9 and the whole thing = and basic GPIO implementation seemed to be a good entry point. Now i=92m = 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. >=20 > Thanks for this discussion! > Krystian >=20 --Apple-Mail=_4E450446-88B1-4446-A546-DA19ECA9FE78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1250 I = don=92t mind! I don=92t think what i did is a major improvement - only = some ideas of a begginer. BCM port in general was a milestone. I=92m = just trying to connect dots while learning something - and have some fun = with it.
Happy new year for you = too.
Krystian

Wiadomo=9C= =E6 napisana przez Shane Morris <edgecomberts@gmail.com> 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 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=9C=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 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=92ll answer at the bottom, to not make even more mess i = did before. :)

I=92m 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 =840 bytes=94 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=92t quite clear = now.

As i said i don=92t know much about BCM, Plan 9 and the whole thing and = basic GPIO implementation seemed to be a good entry point. Now i=92m = 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


= --Apple-Mail=_4E450446-88B1-4446-A546-DA19ECA9FE78--