So libpruio looks like it wraps calls to interface with the GPIOs via the PRU with Freebasic or C calls, yes?
We are committed to building this application in a language that is 1. High level and 2. Prevalent in the job market--we need to be able to find people who know it reasonably well. (also, developer cycles are a lot more expensive to us than processor cycles. Actually, performance is not a high priority for us.) Python fits pretty well. Freebasic does not. C does not either, but I guess I could use SWIG to generate an API for myself to use. That sounds doable, but it doesn't sound like less trouble to me, more like exchanging one difficulty for another. You could add a SWIG interface file to libpruio so people could talk to it in whatever language they wanted. That would make it a lot more attractive to a lot more developers, myself included... http://www.swig.org/ On Tue, Feb 9, 2016 at 11:05 AM TJF <jeli.freih...@gmail.com> wrote: > A bunch of code for a single GPIO pin (in order to get slow sysfs access). > Keep in mind that you've to maintain all that code for each pin you use in > your project. > > For libpruio it is > > chgrp pruio /dev/uio5 > chmod g+rw /dev/uio5 > > and you're done for all GPIO, CAP and PWM pins (and you'll get much faster > direct access). > > BR > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
