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 < [email protected]> 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ść napisana przez Shane Morris <[email protected]> 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 < > [email protected]> wrote: > >> >> Wiadomość napisana przez erik quanstrom <[email protected]> w dniu >> 31 gru 2013, o godz. 20:50: >> >> > On Tue Dec 31 14:40:29 EST 2013, [email protected] 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 >> > > >
