2008-08-19 16:49:23 Anyway to speed up simple gpio driver?
Isaac Leung (CANADA)
Message: 60678
I've successfully gotten one portion of our software going that relies on the GPIO using the simple gpio driver. Our custom board is based on the BF547.
The only issue I'm having right now is that the data/clock rate out of the GPIO using the simple gpio driver is very slow. For example, a simple test clock pattern out of the pin shows that I can at most toggle at ~100kHz or less. I'm pretty sure this isn't a silicon limitation as I've duplicate function that runs out of u-boot (i.e. before booting to uClinux) which runs much faster.
What is chewing up the time is the time required to execute each read/write command to the port. Should I be looking into writing our own driver for our purposes (we'd have to pretty much duplicate the functionality of simple gpio, and I can't imagine it's written that badly...) or is there something more obvious that I can look into that explains this slow performance?
There isn't a lot of other overhead in the code. For example, the test clocking code snippet basically looks like:
=========================
while(1) {
clock = '1';
write(Control_fd[CLK], &clock, 1);
clock = '0';
write(Control_fd[CLK], &clock, 1);
}
========================
so the timing I have really should be just the cost of those 2 write operations.
Thanks,
Isaac
QuoteReplyEditDelete
2008-08-19 16:58:01 Re: Anyway to speed up simple gpio driver?
Mike Frysinger (UNITED STATES)
Message: 60680
the driver isnt really meant for high performance ... you're talking about plenty of context switches just to read/write one sample
you could try using the toggle command ('T') rather than reading 0/1 back and forth ... see the gpio driver for more info
if you need higher performance you'll probably have to move logic into kernel space
QuoteReplyEditDelete
2008-08-19 18:37:58 Re: Anyway to speed up simple gpio driver?
Isaac Leung (CANADA)
Message: 60692
Well, we are doing more than just toggling :-), that was just a test to check out the "native" speed of the operation.
I think for various reasons, it wouldn't probably be a good idea to have the logic in kernel space. Parts of the application need read/write access to other peripherals and devices via the GPIO. It would be possible, but kind of like writing our entire application in kernel space.
If I understand correctly, what you're saying is this is roughly as good as it gets if we want a truly general-purpose method of waggling the GPIO pins? I mean this is pretty much a Linux issue, so if I tried this on a desktop PC, it would be the same deal, just perhaps faster due to the CPU core clock speed, yes? Or is there a better way to control the GPIO's while still maintaining controllability in user space, while booted into uClinux?
QuoteReplyEditDelete
2008-08-19 19:07:32 Re: Anyway to speed up simple gpio driver?
Mike Frysinger (UNITED STATES)
Message: 60693
yes, according to the current design (keep things simple and provide completely generic method), i'm pretty sure this is as good as it gets
each write has to go through user->kernel context switching ... increasing the CPU or changing the arch would change this bottleneck
i dont know exactly what you're doing, but you may be able to build up a set of commands and pass them to the kernel in a single write ... that'd require modification on the simple-gpio side of things ...