I measured the toggle rate on one GPIO pin with a simple oscilloscope and a library I wrote to access the pin from user land (/sys filesystem). Toggling the pin achieves a frequency of about 3.9kHz. Writing the same program in bonescript with nodejs resulted in a toggle rate of about 1.9kHz. I think this is rather slow, or at least I was expecting different results.
I tried to research the problem a bit and only came across one link that said, that the GPIO pins have a different clock, but I think this was for the beagleboard. Could someone please shed some light on the board design and give me an idea about the toggle rate which would be reasonable?
Or to put the question in a more practical light. If I wanted to drive stepper motors via drivers and the Step/Dir/Enable interface the current rate would be much to low in my opinion. How would one start to design for such a problem using the beaglebone?
and the GPIO unit? What is achievable there? Jitter or not jitter, 3.9kHz is still kind of boring :-)Researching for PRU did not yield any results in the beaglebone SRM - which domain does that belong to, where can I find out more? What does it stand for?
and the GPIO unit? What is achievable there? Jitter or not jitter, 3.9kHz is still kind of boring
With a kernel driver you should get a lot better performance, not sure about the numbers.
Researching for PRU did not yield any results in the beaglebone SRM - which domain does that belong to, where can I find out more? What does it stand for?
Programmable Realtime Unit. Have a look at the AM335x manual or search the TI wiki for PRUSS.
It is not surprised that using /sys is rather slow since it caused
data transfer and context switch between user and kernel space. Better
solution would be to trigger GPIO with direct writes to the (mapped)
memory. It should be considerably faster but then the jitter might be
the problem. For this reasons I decide to test what could be
achievable with Xenomai (xenomai.org).
First, I try user-space xenomai application. Results were much better
then without xenomai but still not good enough under high system load
(jitter was to large and servo I was controlling starts shaking).
Currently I am working on the similar test application written also
with xenomai but running in the kernel space (xenomai RTDM driver). I
am expecting much better results but I am not ready yet. If you are
interested, you can take a look at the following article I've written
about it: veter-project.blogspot.com/2011/09/real-time-enough-about-pwms-and-shaky.html
Thank you Andrey, that was interesting reading material. Have you actually tried using the “official” PWM pins instead of simulating with GPIO? Or solved your problem otherwise?
The test described in the article was just to see what is achievable
with xenomai in user and kernel space. As I mentioned, I am not
finished the kernel-space implementation yet, but I am rather
optimistic with my expectations .
and the GPIO unit? What is achievable there? Jitter or not jitter, 3.9kHz is still kind of boring
Researching for PRU did not yield any results in the beaglebone SRM - which domain does that belong to, where can I find
out more? What does it stand for?
there was a thread on the mailing list some time ago about GPIO speed:
I recently did a pin toggle test on the Beagleboard (not -bone), directly accessing GPIO through mmap, and found that the time between two changes can be as short as 228ns, which means 4MHz.
On a beaglebone using mmap with 5v power (720MHz) I got 2.48Mhz toggle speed (2.13 MHz for USB power 500 MHz).
snippet of code to toggle USR1 USR2 and USR3 LEDs looks like
#define GPIO1_START 0x4804C000
int gpio_fd = open("/dev/mem", O_RDWR | O_SYNC);
if (gpio_fd < 0) {
printf(“Could not open GPIO memory fd\n”);
return 0;
}
.