Am 08.09.2012 um 16:48 schrieb Kenneth Lerman: > Michael, > > I took a quick look at the code and am wondering why there is a call to > delay within the loop. The delay function is called with a value of n > (default value is ten) which causes a loop incrementing a counter n > times. What effect does the delay constant have on the timing?
I know it's a hack (this aint our hal_gpio merge candidate just yet ;) - the reason: clock_nanosleep() is pretty useless at least on my current kernel (stock; Linux raspberrypi 3.2.27+ #102 PREEMPT Sat Sep 1 01:00:50 BST 2012 armv6l GNU/Linux) - it gave a minimum delay of some 25usec I've tried adapting the swave.c example from the RT linux wiki - same thing: http://git.mah.priv.at/gitweb/raspberry-test.git/shortlog/refs/heads/rt-gpio see e.g. http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=9882 one would have to dig, eg in https://github.com/raspberrypi/linux/blob/rpi-patches/arch/arm/mach-bcm2708/bcm2708.c to find out if corners were taken which are fixable or the architecture wont support acceptable precision timing if anything this seems to be the issue with the Rpi as an LinuxCNC "realtime outboard", not io path latency still great for the sprinkler application though > > It's also worth noting that depending on the compiler and the > optimization level chosen, the delay function might be optimized out so > as to have no affect. To avoid such unwanted optimization, the variable > being counted could be declared global and volatile. > > [I recognize that at least part of this code was written by others.] > > I've often commented that there is no value in arguing how many angels > can dance on the head of a pin -- you need to get out there and count > them. Thank you for doing that. yeah, my armchair expert detector started wailing, and I cant credibly bitch about 'musings and conjecture' without actually doing it myself, so I had to cook this up: http://static.mah.priv.at/public/rpi-lport.jpg ;) is your German good enough for "Wer misst, misst Mist!"? I appreciate the look over the shoulder. - Michael > > Regards, > > Ken > > > On 9/8/2012 6:43 AM, Michael Haberler wrote: >> I've done some bit-bang timing measurements for the Raspberry GPIO pins >> >> see >> http://linuxcnc.org/index.php/english/component/kunena/?func=view&catid=18&id=20514&limit=6&start=48#24062 >> >> I'm not saying the Pi has many cycles left at 220nS transition spacing, but >> the 'slow ARM IO myth' seems to be just that, memory mapped IO is roughly an >> order of magnitude faster than I ever got with a PC parport driven from a >> user process; interrupt latency is another issue but GPIO in this style >> doesnt use it >> >> - Michael >> >> >> Am 20.07.2012 um 16:30 schrieb Charles Steinkuehler: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 7/20/2012 9:11 AM, Kent A. Reed wrote: >>>> On a more serious note, as has been discussed on the two emc mail >>>> lists, the road to ARM is littered with ideas but so far we have >>>> little result. >>>> >>>> The nicely done miniEMC2 project by Sergey Kaydalov is the most >>>> complete effort I know of. It employed the higher-latency Xenomi >>>> code rather than RTAI. Inquiring minds want to know more about the >>>> possibility of porting this code or something like it to boards >>>> like the RPi or BB and about the resulting performance attainable. >>>> I wish I could have tackled this already but I've got too many >>>> family issues at the moment. >>> I'm planning on trying to use the PREEMPT_RT version of LinuxCNC with >>> my Pi when it comes in, but I'm not sure what sort of latencies to expect. >>> >>> On conventional PC hardware, I've gotten decent latency jitter with >>> modern systems, but not yet down to the RTAI levels. On older >>> hardware latency with PREEMPT_RT is much worse, particularly on >>> single-core systems (although I don't yet know if this is due to not >>> having two cores to schedule between or because all my single-core >>> systems are pretty ancient). >>> >>> I'm also hoping on the Arm it might be possible to use the fast IRQ >>> and read/write the I/O pins in an ISR which may allow the servo thread >>> to run with much higher jitter. >>> >>>> Then there's the problem of gluing these boards to our CNC hardware >>>> about which I yield to Jon. >>> My current plan is to bit-bang GPIO pins based on code from the >>> parallel port driver, but adding a bit of electronics would probably >>> make things much easier. I'll evaluate that option once I see where I >>> get with software stepgen. >>> >>> - -- >>> Charles Steinkuehler >>> char...@steinkuehler.net >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (MingW32) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAlAJa6IACgkQLywbqEHdNFyNjwCfTVchMrwrcmA2RZ78hoYM0OEa >>> zn0AoOyTZa74B1MnFaDOL2HqUxG5LwOH >>> =Dmby >>> -----END PGP SIGNATURE----- >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Emc-developers mailing list >>> Emc-developers@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/emc-developers >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
