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 >
