I ran a few more tests on serializing a 64-bit stream using C-language and the wiringPi library. Typically, I'm getting around 32usec (measured on a scope) to send the 64-bit burst, which is decent for software-controlled GPIO's.
There are timers available in wiringPi, but I found they are not accurate. A burst that measures ~32usec on my scope is around 22usec per the micros() call. Despite it's inaccuracy, it's still useful for generating histogram data on transmit times. As GastonP pointed out, timing is non-deterministic in Linux. After numerous runs I did see a case where it took 10msec to complete the transmit. The single outlier really skewed the avg TX time. Bottom line is that the RasPi is usable for many, but not all, control applications. A clock should be OK; engine controller ? No way. All of my clocks to-date are at least as reliable as the electric utility (never had logic or FPGA crash on me); not sure if RasPi has similar reliability / availability. greg@rpi0w001:/proj1/pigpio/src $ ../exe/speedtest_gpio_tx64 400 Loops. Max_time = 10083usec, Min_time = 18usec, Avg_time = 45.69usec 0 to 20: N = 161 20 to 25: N = 219 25 to 30: N = 18 30 to 35: N = 0 35 to 40: N = 1 40 to 45: N = 0 45 to 50: N = 0 50 to 60: N = 0 60 to 70: N = 0 70 to 100: N = 0 100 to 150: N = 0 150 to 200: N = 0 200 to 300: N = 0 300 to 400: N = 0 400 to 500: N = 0 500 to 750: N = 0 750 to 1000: N = 0 1000 to 2000: N = 0 Over 2000: N = 1 -- You received this message because you are subscribed to the Google Groups "neonixie-l" group. To unsubscribe from this group and stop receiving emails from it, send an email to neonixie-l+unsubscr...@googlegroups.com. To post to this group, send an email to neonixie-l@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/6b33af15-0371-4fbd-8b42-bdb36fb8a44d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
