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
High level and
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…
libpruio is PRUSS assembler code to control the subsystems GPIO, ADC, PWM/CAP. An API is available to control that assembler part from host CPU (ARM), written in FreeBASIC. Also a C wrapper is shipped in the package.
When you say Python fits well, why do you think FreeBASIC doesn’t? It combines a steep learning curve (like Python) with the advantages of a real compiler.
Some years ago I tried to use SWIG. From my point of view it’s not flexible, not really well documented and much too complicated to use. Finally I wrote a similar tool (h_2_bi) from scratch, in order to meet my needs.
In April 2015 Benoit Clouet and me made a libpruio Python binding based on ctypes for his browser controlled tank project. Find the source code and additional information in this post.
Anyway, I just tried to share experiences from other libpruio users and myself in order to minimize your development costs. If you feel like replacing one difficulty by another, then I need not spend my time in posting here.
Thanks, I appreciate your efforts. Please read that with zero sarcasm. I’ve been there too, thinking I knew what would save someone time and effort and not realizing I was in a different situation.
I have a large application to build. I’m not sure how much of the complexity is going to be running on the BBBs I will use. I will probably have to hire a small-to-medium sized team over the next few years. I have to consider the technologies I will start with carefully. Python isn’t perfect, but it’s easy to find developers who have mastered it and can be productive quickly, and that’s important.
You might want think more about this then the peep hole approach.
Rather then running things in userland and relying on user id isolation; a
better way is to write a kernel driver that exposes a very specific and
limited interface. GPIOs are directly toggling hardware which means there are
more then thing simple "privileges" -
- Can the pins be reconfigured to conflict (i.e. BBB is an Output and the
thing connected is an output) and is the hardware tolerant of that or will
things die?
- Is there anything bad that will happen if the pin floats (i.e. a normally
output pin is switched to an input)? Will it pickup noise and let things go
crazy?
Just merely changing permissions can leave a dangling problem.
I’ve often given thought to running two processes in this context, and using inter process communications( shared memory seemed the most attractive to me ). How I envisioned this though, is that you have one process running as root, that is the main “supervisor” part of the application. Then a regular user application that makes requests via whatever shared memory mechanism that get used.
I think the main benefit of an application of this sort is that there is kind of a partition between privileged commands, and non privileged users. With the ability of having very fine grained control.
Anyway, I only bring this up because the last post kind of reminds me of what I mention above, and actually could be made to work as a “userland” driver.
I tried that ls -la /dev and could not find anything like a GPIO group - my Nanopi M1 does not have a GPIO group and right now the only way I can run the MATRIX programs that come with the NanoPi - is by root- and every recommendation I have ever seen for Node-Red says NOT to run it as root - and Node-Red’s EXEC function cannot accesss SUDO which suggests there is no way for Node-Red to access the GPIO on the M1. Ideas anyone?