Raspberry GPIO and wiringPi. Is it possible?

[DaveJJ]

Hi,

I'm trying to access the GPIO on a Rasberry Pi using Freebasic. As I understand it there are no native commands to carry out the direct control of the IO on the Pi.

On searching the internet there seem to be very few options with FB except possibly wiringPi which I have installed and tested ok. However (isn't there always!) there seems to be no wiringPi.bi for including into programs and using the suggested -lwiringPi as a compiler switch brings back ...

error 78: Invalid command-line option, "-lwiringPi"

Is there another undocumented installation/build stage I have miss to create the wiringPi.bi file?

As someone well out of touch with C and crosscompiling and manipulating libraries, have I bitten off more than I can chew? :(

Thanks

[TJF]

error 78: Invalid command-line option, "-lwiringPi"

FreeBASIC expects a white space after the -l option

• -l wiringPi

[DaveJJ]

Worked a treat. Funny that the white space did not appear to be in the help info after building the wiringPi library.

Now all I have to do is find out how to create "wiringPi.bi" which does exist after installing the wiringPi library. I read somewhere on the forum there is a .bas utility to create a .bi library from C headers. Can anybody point me in the right direction to incorporate this on my Pi?
Thanks

[TJF]

There're several tools. Just search for fbfrog or h_2_bi.bas.

[DaveJJ]

Thanks again.

I'd already found the h_2_bi and already given up as it seemed poorly documented in the location I found it. fbfrog on the other hand looks much better documented and well worth a go even though I suspect I'll be wading into the deep-end.

[DaveJJ]

I have created a wiringPi.bi and a DRCSerial.bi from running all the headers (probably wrong to do *.h) through fbfrog, but when I include the library into my program I get duplicated definition errors. These occur whether I try to compile direct on the RPi using FB or on my desktop with Geany.

Loading wiringPi.bi into Geany I see that the lines with the errors are input and output definitions and the keywords input and output are in heavy blue.

#define INPUT 0
#define OUTPUT 1

Does this suggest that they are keywords elsewhere and not just in the wiringPi library.

Do I need some other compiler options as I already use switch "-l wiringPi" when compiling.

Thanks

[TJF]

INPUT and OUTPUT are FreeBASIC keywords. When you use h_2_bi, it will mangle the symbols by an underscore (or the customized mangling characters, specified in the source) and report those adaptions in the protocol section (at the end of the header, if enabled).

When you use fbfrog, you've to resolve those naming conflicts manually.

BTW: You can install h_2_bi as a custom command in Geany and translate the headers line-by-line. That's more transparent, you can watch what happens and adapt the configuration file step-by-step.

[dkl]

Just to talk about h => bi conversion a bit:

fbfrog had an auto-renaming feature for a while during 2014, but I ended up removing it, because it renamed things that didn't need renaming, and it often resolved symbol conflicts incorrectly (by renaming the wrong thing). Instead, I feel like command line options such as -renametypedef <old> <new> are more useful - they can be used to rename specific symbols on command. I.e. the user decides what to rename and how, which is of course more work, but offers good control without giving the annoying wrong results. (and it's much easier to implement in the tool)

Unnecessary renames happened for example because the auto-renaming only partially respected scopes and other FB language rules (e.g. differences between keywords, quirk keywords, operators, and built-in functions/macros), or because of a conflict between two declarations where one of the two will be removed from the binding anyways, or because of a conflict with an FB keyword that will be #undef'ed for the binding... all of this could technically be fixed, but the code was so complex already, so I didn't think it's worth it.

Wrong renames happened for example with conflicts between a #define and a function. Sometimes the #define is a constant (then the situation is something like #define FOO_VERSION vs. declare function foo_version()), sometimes the #define is a macro intended to override the function (e.g. #define foo(x) foo(x, 0) vs. declare sub foo(byval x as integer, byval unused as integer)). These two cases need to be resolved differently, but it's not easy for the tool to decide.

All in all, I'm going with the idea of letting fbc detect name conflicts, and then rerunning fbfrog with adjusted options to fix the issues as needed. The options can be collected in a script, so it's all good.

[mramos]

Any reason you do not use the /sys/class/gpio files? They run from memory and do not hit the SD card. Grant it, not pretty but works and one less thing to install on the OS too.