Kiosk GUI Screens

I got it working. I only added code portion from libgpio manual. Needed more. There were two examples and I assumed wrong.

Found some good tutorials
He says not to use ifdef.

This one says use it....
Oh boy.
 
Just to critique my learning I thought that the statement:

gpio_config_t was sufficent alone.

While the top part of the previous example was needed.

gpio_handle_t handle;
handle = gpio_open(0);

Compiler was complaining about handle undeclared.

In my head I was thinking device does not need to be opened to check config. That's why I ignored the top section of example.
That assumption was wrong.

Code:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <libgpio.h>

    int main(int argc, char **argv)
    {
        gpio_handle_t handle;
        handle = gpio_open(0);
        gpio_config_t cfg;
        cfg.g_pin=31;
        gpio_pin_config(handle, &cfg);
        printf("Pin %d: \"%u\"\n", cfg.g_pin, cfg.g_flags);
};
 
OK now my dumb questions come. From everything I read for each programmatic OPEN you should do a CLOSE operation.

Why is there no gpio_close shown. That should be part of the function for a "One time call" right? If polling you might want to keep it open.
 
I would use a C++ wrapper class and open the handle in the constuctor and close it in the destructor. Then have wrapper methods for each operation you want to support.
 
A C binding to a C++ library does not make sense imho. It only adds confusion to the project. Object orientation is one of the strengths of C++, and it should not be abandoned.
 
I am sitting here reflecting on my decision to use FLTK or anything not C.
Doing some Hello World with Motif. Playing with Xaw.

I feel like I have the GUI part down and now its meat and potatoes. FLTK meets my needs.
I can make GUI screens just like I could with MS Access but there is no SQL Query builder here.

I have the Community College course book open and looking at the offerings.
CSC 221 teaches with Python.
Ugg.
I do need the structure of a classroom. Dank old books and web pages just are not enough.
 
I would use a C++ wrapper class and open the handle in the constuctor and close it in the destructor. Then have wrapper methods for each operation you want to support.
That was over my head. Because of it I started on the W3C C++ tutorial but got bored quick.

This may sound stupid but please advise.
My thought is here I was to use FreeBSD GPIO functions over and over so could I build an Fl_GPIO widget or class that I could reuse within Fltk?

Would that just be one part with a C to C++ translator layer needed for libGPIO or am I off base??

Break it down like I am 10 years old please.
 
Would that just be one part with a C to C++ translator layer needed for libGPIO
You could use an own C++ wrapper class and wrap the C API of libGPIO to simplify things or just use it directly.

A wrapper class could look like this (off the top of my head, don't know if it compiles):

C++:
#include    <sys/types.h>
#include    <err.h>
#include    <libgpio.h>

class GPIOWrapper
{

public:
   
    // constructor opens the handle
    GPIOWrapper()
    {
        this->handle = gpio_open(0);
    }
   
    // destructor closes the handle
    ~GPIOWrapper()
    {
        gpio_close(this->handle);
    }
   
    // an example wrapper method
    gpio_config_t getConfig(int pin)
    {
        gpio_config_t cfg;

        cfg.g_pin = pin;
        gpio_pin_config(this->handle, &cfg);

        return cfg;
    }

private:
   
    // the handle
    gpio_handle_t handle;
};

And you would use it like this

C++:
void fltkButtonCallback()
{
    // instance of wrapper class
    GPIOWrapper gpio;

    // use wrapper method
    gpio_config_t config = gpio.getConfig(32);
}
 
That was over my head. Because of it I started on the W3C C++ tutorial but got bored quick.

This may sound stupid but please advise.
My thought is here I was to use FreeBSD GPIO functions over and over so could I build an Fl_GPIO widget or class that I could reuse within Fltk?

Would that just be one part with a C to C++ translator layer needed for libGPIO or am I off base??

Break it down like I am 10 years old please.
I think the easiest path at this point is for you to push your code to some public place where we can all look at it and provide suggestions.
 
OK I have some time to learn with this code over the holiday weekend. I have some really basic dumb questions.

Starting with dumbest: Is this wrapper file compiled? If so as an object file or cpp compiled program?

Doing some reading on an error I found a similar topic and different methods:

While trying to compile above provided GPIOWrapper example I had an error that I was attempting to correct:
Code:
lib/crtend.o /usr/lib/crtn.o
ld: error: undefined symbol: main

So I understand every program needs main int but I am wondering if the error is related to this being compiled wrong?
I tried add various other headers like iostream and namespace to no avail.

If this wrapper needs compiling where does main() go here? In c++ code or with the C-code wrapped ?
 
Is this wrapper file compiled? If so as an object file or cpp compiled program?
In my head I cant help wondering if this is not just a matter of choice.
Use the wrapper as code at compile time or as a dynamic link library that is compiled.

Please set me straight.
 
While trying to compile above provided GPIOWrapper example
I did not provide a main function which of course is neccessary for every C/C++ program.
I just meant to show how you'd invoke the wrapper from a FLTK button callback.

In c++ code or with the C-code wrapped ?
The main function should be in a C++ source file since you want to write a C++ program.

If so as an object file or cpp compiled program?
Depends on if you have a translation unit for the wrapper or not.

A translation unit is the basic unit of compilation in C++. It consists of the contents of a single source file, plus the contents of any header files directly or indirectly included by it, minus those lines that were ignored using conditional preprocessing statements.

A single translation unit can be compiled into an object file, library, or executable program.

Since the wrapper is currently header only, it does not get compiled into an object file.
 
invoke the wrapper from a FLTK button callback.
I appreciate that. I was thinking more along the lines of a text box but button would be better for refreshing. Maybe more work than simple text box.

I have conceptual problems wtih code. It helps to have naming conventions with hints.
Dumb question here.
What part does "this" have in your code. Is it a label? I can feel you emphasizing it but I am dumb.
this->handle = gpio_open(0)

So I should be working in my fl toolkit. Thanks for the help.

I was using this:
c++ -v -o gpiowrap gpiowrap.cpp -I/usr/local/include -I/user/include -L/usr/local/lib
 
What part does "this" have in your code.
In C++, 'this' pointer is an implicit pointer available inside all non-static member methods of a class, and it always points to the current object that called the method. You can omit it, but for me it feel cleaner to have it. This way, I can immediately see that the variable belongs to the class.
 
I am realizing I should have done the self taught tutorial "How to display a sysctl like CPU Temp in Fl-Text box" first....

I might divert. I feel I jumped the shark with GPIO. I skipped a section.
 
I have a MinnowBoardMax all warmed up ready to work...

But I did not do the most basic text box yet.

With sysctl fetching I could get dragged into coding. I can start with command line sourcing data and dip my toe in sysctlbyname. Another wrapper...
 
So back to dumb questions.
Conceptually should I put multiple functions into wrapper like libgpio + sysctlbyname or separate wrapper for each C library?

Multiple functions for different GPIO operations in same GPIOWrapper is OK? Separate wrapper for each GPIO function?
 
don't bother with c++ if you don't have to.
if you really want to close that friggin handle you can use atexit(3) but it's just a file handle to /dev/gpiocwhatever which the kernel will clean at exit if you don't
 
Back
Top