4 ms·

> and each cycle on an RPi at 900Mhz is 1.1ns Its not the CPU's clock that matters here. https://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-spe

> and each cycle on an RPi at 900Mhz is 1.1ns Its not the CPU's clock that matters here. https://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ https://codeandlife.com/2012/07/03/benchmarking-raspberry-pi... With 14MHz best-case from the Rasp. Pi, its clear that the GPIO clocks are simply at a slower rate than the CPU. Also, with C, you can achieve the highest possible GPIO rate on the Rasp. Pi. No need to go into an alternative OS.

monocasa 4y ago
The sentence just prior I stated that it was dozens of CPU cycles to access GPIO blocks. Your citation is consistent with my statements. And BTW, the problem isn't slow clocking from the GPIO. It runs at about half CPU clock depending on the RPi model, which doesn't account for the latency you're seeing. It's actually spending most of the time simply propagating unchached accesses across the fabric, taking a long time for the same reason that an uncached read from DRAM takes a lot of cycles. But at the end of the day, my whole argument was that the hardware is capable of about equivalent to an Arduino in terms of wiggling lines. However, from Linux you can't consistently meet deadlines without writing a kernel module because of the IPIs the kernel uses internally for bookkeeping. At that point you're comparing the developer UX between writing a kernel module with that of an Arduino sketch, and there's a pretty clear winner for productivity. That's why I welcome alternative software stacks.