Faster GPIO on XU4

[sgjava]

I'm working on a light weight cross platform IO library for Java called Java Periphery https://github.com/sgjava/java-periphery which can use MMIO for GPIO updating registers directly instead of using GPIO device or deprecated sysfs interface. Using GPIO device I get 44 KHz (square wave) and using MMIO I get 300 KHz. I've seen where people have said you can get 2-3 MHz, but I've not seen that. Also, I'm only using a single core. With my Allwinner boards I get 2+ MHz on a single core using same exact code.

[odroid]

Try our wiringpi library to narrow down root causes.
https://wiki.odroid.com/odroid-xu4/appl ... o/wiringpi

[sgjava]

It's an apples and oranges kind of thing. Firstly, I'm running Armbian with a 5.4.x kernel. Secondly, I'm trying to stay away from deprecated interfaces such as sysfs and wiringPi (although I did look at the wiringPi XU3/XU4 code). I'm using /dev/mem and register mappings to keep my MMIO code board cross platform. I see there's /dev/gpiomem, so I'm going to test this since it should be a bit safer than /dev/mem.

[LikeSmith]

Looks like I'm a little late to the party, but I'm currently setting up servo signals with my XU4 using C and the memory mapped gpio registers. I've been able to get somewhat reasonably accurate timings using bitbanging with an thread running real time. Still not as good as what I could get off a microcontroller, but much better than what I get without the RT!

[mctom]

Looks like I'm a little late to the party, but I'm currently setting up servo signals with my XU4 using C and the memory mapped gpio registers. I've been able to get somewhat reasonably accurate timings using bitbanging with an thread running real time. Still not as good as what I could get off a microcontroller, but much better than what I get without the RT!

I had the same problems with my pistackmon projects, where I bitbanged serial data to emulate PWM on 16 LEDs. It worked quite well with C++ sleep_until, and incrementing the target time by fixed amount on each cycle. It was more stable than a comparable sleep_for.
I'm taking about 50us resolution here, so as you said, not comparable to microcontroller performance at all.