• Print

Author Topic: Anyone have QB64 running on Raspberry Pi  (Read 1818 times)

fatman2021

  • Hero Member
  • *****
  • Posts: 978
  • Lord Jesus Christ, Son of God, have mercy on us.
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #30 on: February 17, 2013, 01:45:22 PM »
Quote from: mcalkins on February 17, 2013, 08:09:03 AM
Fatman: sorry if I missed something, but I'm not understanding this. Are you trying to debug mramos's problem, or did you find a different problem?

Quote
QB64 is probably overrunning an array somewhere.

Is the code that you posted from QB64? If not, I fail to see the connection.

Regards,
Michael

It is just an example of a common way of generating a segmentation fault on the Raspberry PI. The connection is that when ever someone attempts to run QB64 on a Raspberry Pi it generates a segmentation fault.
Woe to those who call evil good, and good evil;
Who put darkness for light, and light for darkness;
Who put bitter for sweet, and sweet for bitter!

Isaiah 5:20

mramos

  • Newbie
  • *
  • Posts: 25
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #31 on: February 21, 2013, 05:16:47 AM »
I only received the segmentation fault when X server was not running. 

But it appears to work fine.

DSMan195276

  • Hero Member
  • *****
  • Posts: 1978
  • Yes
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #32 on: February 24, 2013, 07:42:10 PM »
Marmos, is there any chance you could tar up your QB64 folder for the Raspberry Pi and post it here? I could never get it to compile but if your version works then I'd be able to use that to run some tests on QB64 for the Raspberry Pi. I'm currently planning on buying a few extensions for the Pi as well as trying out some things with the GPIO, and if I can I'm going to try writing a library for QB64 to interface easily with the GPIO -- As easy as it can be made anyway.

Matt
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

fatman2021

  • Hero Member
  • *****
  • Posts: 978
  • Lord Jesus Christ, Son of God, have mercy on us.
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #33 on: February 24, 2013, 08:40:30 PM »
The following should work:

GPIO.BAS

Code: [Select]
DECLARE LIBRARY "python_wrapper", "python2.7:0"
    SUB python_init ()
    SUB python_close ()
    FUNCTION python_run_simple& (s$)

END DECLARE

code$ = ""
code$ = code$ + "import RPi.GPIO as GPIO" + CHR$(10)
code$ = code$ + "import time" + CHR$(10)
code$ = code$ + "GPIO.setup(11, GPIO.OUT) + CHR$(10)
code$ = code$ + "while True:" + CHR$(10)
code$ = code$ + "    GPIO.output(11, True)" + CHR$(10)
code$ = code$ + "    time.sleep(2)" + CHR$(10)
code$ = code$ + "    GPIO.output(11, False)" + CHR$(10)
code$ = code$ + "    time.sleep(2)" + CHR$(10)
code$ = code$ + "sys.exit()" + CHR$(10)

python_init
py_run = python_run_simple(code$)
python_close

python_wrapper.h

Code: [Select]
#include "python2.7/Python.h"

void python_init(){
Py_Initialize();
}

void python_close(){
Py_Exit(0);
}

int python_run_simple(char * s){
return (int)PyRun_SimpleString(s);
}
Woe to those who call evil good, and good evil;
Who put darkness for light, and light for darkness;
Who put bitter for sweet, and sweet for bitter!

Isaiah 5:20

fatman2021

  • Hero Member
  • *****
  • Posts: 978
  • Lord Jesus Christ, Son of God, have mercy on us.
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #34 on: February 24, 2013, 08:51:27 PM »
You need to access the GPIO registers just like you would any other special function registers. The LPC2378 docs show these details:

Code: [Select]
#define GPIO_BASE  0xE0028000
#define IOPIN0     (GPIO_BASE + 0x00) // Port 0 value
#define IOSET0     (GPIO_BASE + 0x04) // Port 0 set
#define IODIR0     (GPIO_BASE + 0x08) // Port 0 direction
#define IOCLR0     (GPIO_BASE + 0x0C) // Port 0 clear
#define IOPIN1     (GPIO_BASE + 0x10) // Port 1 value
#define IOSET1     (GPIO_BASE + 0x14) // Port 1 set
#define IODIR1     (GPIO_BASE + 0x18) // Port 1 direction
#define IOCLR1     (GPIO_BASE + 0x1C) // Port 1 clear

Use this macro to access memory-mapped registers:

Code: [Select]
#define mmioReg(a) (*(volatile unsigned long *)(a))
Then the code to read the port looks like this:

Code: [Select]
unsigned long port0 = mmioReg(IOPIN0); // Read port 0
unsigned long port1 = mmioReg(IOPIN1); // Read port 1

The same macro works for accessing the set/clear/direction registers. Examples:

Code: [Select]
mmioReg(IOSET1) = (1UL << 3);   // set bit 3 of port 1
mmioReg(IOCLR0) = (1UL << 2);   // clear bit 2 of port 0
mmioReg(IODIR0) |= (1UL << 4);  // make bit 4 of port 0 an output
mmioReg(IODIR1) &= ~(1UL << 7); // make bit 7 of port 1 an input

Woe to those who call evil good, and good evil;
Who put darkness for light, and light for darkness;
Who put bitter for sweet, and sweet for bitter!

Isaiah 5:20

DSMan195276

  • Hero Member
  • *****
  • Posts: 1978
  • Yes
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #35 on: February 24, 2013, 09:00:15 PM »
Ah, yes doing it via Python is an idea. I was planning on doing it using the C stuff for GPIO (I think linux/gpio.h) since I'm comfortable with C and I think I'll be able to get at least some basic stuff working pretty quickly (And really, I'm just looking to have some fun messing around with it all, so if I can't get anything working that easily it's not that big of a deal to me). I don't know Python so it's a bit out of my comfort zone. That code looks simple enough though.

The C GPIO stuff should be a bit cleaner to implement via DECLARE LIBRARY (Mapping C stuff to DECLARE LIBRARY should work pretty well) and with any luck it won't even need a header file to go with it. Either way I probably won't be able to work on it until next month so when I get there I'll post back if I get anything working.

And ah, so I just get a volatile pointer to the memory location directly, that will work?

Matt
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

fatman2021

  • Hero Member
  • *****
  • Posts: 978
  • Lord Jesus Christ, Son of God, have mercy on us.
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #36 on: February 24, 2013, 09:10:38 PM »
The Raspberry Pi User Guide by Eben Upton and Programming the Raspberry Pi - Getting Started with Python by Simon Monk should tell you everything you need to know.
Woe to those who call evil good, and good evil;
Who put darkness for light, and light for darkness;
Who put bitter for sweet, and sweet for bitter!

Isaiah 5:20

mcalkins

  • Hero Member
  • *****
  • Posts: 1269
    • qbasicmichael.com
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #37 on: February 25, 2013, 02:35:38 AM »
Linux lets you access hardware directly from user mode? Windows doesn't allow that for security and reliability reasons. What if your thread gets preempted while you are controlling the hardware? Perhaps the other thread tries to use the same hardware?

A very brief glance at: http://www.kernel.org/doc/Documentation/gpio.txt seems to confirm my impression that hardware would be used by kernel mode drivers. I assume that Linux has the same kernel mode/user mode separation that Windows has, otherwise there would be no security.

Code: [Select]
#define mmioReg(a) (*(volatile unsigned long *)(a))
At the risk of being pedantic, it is a pointer to a volatile, the pointer itself is not volatile. Otherwise, I think it would be:
unsigned long * volatile

Regards,
Michael
« Last Edit: February 25, 2013, 02:45:17 AM by mcalkins »
The QBASIC Forum Community: http://www.network54.com/index/10167 Includes off-topic subforums.
QB64 Off-topic subforum: http://qb64offtopic.freeforums.org/

DSMan195276

  • Hero Member
  • *****
  • Posts: 1978
  • Yes
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #38 on: February 25, 2013, 03:16:11 AM »
http://unix.stackexchange.com/questions/42980/can-hardware-be-accessed-directly-from-user-space

I'd say it's safe to assume you can't. You can however, access hardware on a somewhat 'higher level', such as you can access your drives (Hard-drives, flash-drives, etc.) starting right at the MBR and on from /dev/sd* (Where /dev/sda is the first drive, /dev/sdb is the second, etc.). This is actually quite useful for writing USB images to a USB drive, or backing up your MBR, etc. And of course only root can access it. it's really no more access then is given by Windows to an Admin (They can write over the MBR of disks if wanted) just it's more convenient to use (Since it doesn't require writing out and compiling a program that calls some Windows system call). There is /dev/mem which I've seen used to access processor address space (And I think /dev/kmem for virtual memory space) however I believe it's limited, such as you can only access the first MB (so you can get BIOS info etc.). And, I also believe it still goes through the kernel so it's not 100% direct.

I think it's more likely that the GPIO are more like an oddball, to at extent. I skimmed over the Kernel documentation and it looks like you have to have GENERIC_GPIO=y set in the kernel config when you compile the kernel to allow for GPIO to be access directly. And at that, I don't know if the way Fatman outlined will work, I think you'd still have to set root to be able to write to all of /dev/mem to get that to work (There is a kernel option for this, but for normal Linux's it's kept off). The other way is via linux/gpio.h which is what I plan on trying to use. This I assume calls the kernel, and then that accesses the GPIO.

Matt
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

mramos

  • Newbie
  • *
  • Posts: 25
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #39 on: February 25, 2013, 06:35:16 AM »
Quote from: DSMan195276 on February 24, 2013, 07:42:10 PM
Marmos, is there any chance you could tar up your QB64 folder for the Raspberry Pi and post it here? I could never get it to compile but if your version works then I'd be able to use that to run some tests on QB64 for the Raspberry Pi. I'm currently planning on buying a few extensions for the Pi as well as trying out some things with the GPIO, and if I can I'm going to try writing a library for QB64 to interface easily with the GPIO -- As easy as it can be made anyway.

Matt

Matt, let me know what you come up with.  Like to see C examples for sure, and simple is better for me.  haha.  Note I used the -czf to make it but forgot to name is with the "z".  This is a Linux/Weezy compile for ARM.

Will try fatmans code tonight.  Have to be at console to use qb64 with X.
« Last Edit: February 25, 2013, 07:46:00 AM by mramos »

fatman2021

  • Hero Member
  • *****
  • Posts: 978
  • Lord Jesus Christ, Son of God, have mercy on us.
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #40 on: February 25, 2013, 08:41:01 AM »
In order to test our GPIO access program we will need to connect the GPIO pins to actual hardware components. I decided to to use GPIO pin 4 as an output pin that turns on an LED and GPIO pin 17 as an input pin that reads the state of a pushbutton.

When using the Linux (sysfs) way to access GPIO, we must ensure that we’re logged in as root:

Code: [Select]
pi@raspberrypi ~ $ sudo -i
we then must “export the pin” in question. For example to use pins GPIO4 & 17 we  must first export them by writing the GPIO pin numbers to the file “/sys/class/gpio/export” as follows:

Code: [Select]
root@raspberrypi:~# echo "4" > /sys/class/gpio/export
root@raspberrypi:~# echo "17" > /sys/class/gpio/export

The next step is to set pin 4 as output and pin 17 as input. This is achieved by writing “out” into the “/sys/class/gpio/gpio4/direction” file and writing “in” into the “/sys/class/gpio/gpio17/direction” file as follows:

Code: [Select]
root@raspberrypi:~# echo "out" > /sys/class/gpio/gpio4/direction
root@raspberrypi:~# echo "in" > /sys/class/gpio/gpio17/direction

To set the output GPIO4 pin high and therefore cause the LED to light-up, we need to write a “1″ to the “/sys/class/gpio/gpio4/value” file:

Code: [Select]
root@raspberrypi:~# echo "1" > /sys/class/gpio/gpio4/value
To clear the output GPIO4 pin to low and therefore cause the LED to turn off we need to write a “0″ to the “/sys/class/gpio/gpio4/value” file:

Code: [Select]
root@raspberrypi:~# echo "0" > /sys/class/gpio/gpio4/value
To read the state of the input pin GPIO17, we need to read the “/sys/class/gpio/gpio17/value” file.  This will return either a “0″ if the pin is connected to 0V or a “1″ if the pin is connected to 3.3V:

Code: [Select]
root@raspberrypi:~#cat /sys/class/gpio/gpio17/value
And finally, when we’re done with the GPIO pins we must unexport them by writing the GPIO pin numbers to the “/sys/class/gpio/unexport” file!

Code: [Select]
root@raspberrypi:~#echo "4" > /sys/class/gpio/unexport
root@raspberrypi:~#echo "17" > /sys/class/gpio/unexport

Notice how the sysfs approach reduces the problem of GPIO access to reading and writing files! This is by the way the norm for Linux. All I/O access (serial ports, console, printers e.t.c.) involves reading to and writing from files. The next step will be to perform the same functions in C++!

The goal of the GPIOClass class is to enable the control of a single GPIO  pin. The class was designed so that the GPIO pin number must be passed to the GPIOClass object when its created via an overloaded constructor. The “GPIOClass.h” header file is provided below:

Code: [Select]
#ifndef GPIO_CLASS_H
#define GPIO_CLASS_H
 
#include <string>
using namespace std;
/* GPIO Class
 * Purpose: Each object instantiated from this class will control a GPIO pin
 * The GPIO pin number must be passed to the overloaded class constructor
 */
class GPIOClass
{
public:
    GPIOClass();  // create a GPIO object that controls GPIO4 (default
    GPIOClass(string x); // create a GPIO object that controls GPIOx, where x is passed to this constructor
    int export_gpio(); // exports GPIO
    int unexport_gpio(); // unexport GPIO
    int setdir_gpio(string dir); // Set GPIO Direction
    int setval_gpio(string val); // Set GPIO Value (putput pins)
    int getval_gpio(string& val); // Get GPIO Value (input/ output pins)
    string get_gpionum(); // return the GPIO number associated with the instance of an object
private:
    string gpionum; // GPIO number associated with the instance of an object
};
 
#endif

Each GPIOClass object has member functions that enable us to export/unexport GPIO pins, set the direction of the GPIO pins as well as set and get the value of the GPIO pins. The GPIOClass object has one private variable which is the GPIO pin number. The implementation of these member functions  are provided below “GPIOClass.cpp”:

Code: [Select]
#include <fstream>
#include <string>
#include <iostream>
#include <sstream>
#include "GPIOClass.h"
 
using namespace std;
 
GPIOClass::GPIOClass()
{
    this->gpionum = "4"; //GPIO4 is default
}
 
GPIOClass::GPIOClass(string gnum)
{
    this->gpionum = gnum;  //Instatiate GPIOClass object for GPIO pin number "gnum"
}
 
int GPIOClass::export_gpio()
{
    string export_str = "/sys/class/gpio/export";
    ofstream exportgpio(export_str.c_str()); // Open "export" file. Convert C++ string to C string. Required for all Linux pathnames
    if (exportgpio < 0){
        cout << " OPERATION FAILED: Unable to export GPIO"<< this->gpionum <<" ."<< endl;
        return -1;
    }
 
    exportgpio << this->gpionum ; //write GPIO number to export
    exportgpio.close(); //close export file
    return 0;
}
 
int GPIOClass::unexport_gpio()
{
    string unexport_str = "/sys/class/gpio/unexport";
    ofstream unexportgpio(unexport_str.c_str()); //Open unexport file
    if (unexportgpio < 0){
        cout << " OPERATION FAILED: Unable to unexport GPIO"<< this->gpionum <<" ."<< endl;
        return -1;
    }
 
    unexportgpio << this->gpionum ; //write GPIO number to unexport
    unexportgpio.close(); //close unexport file
    return 0;
}
 
int GPIOClass::setdir_gpio(string dir)
{
 
    string setdir_str ="/sys/class/gpio/gpio" + this->gpionum + "/direction";
    ofstream setdirgpio(setdir_str.c_str()); // open direction file for gpio
        if (setdirgpio < 0){
            cout << " OPERATION FAILED: Unable to set direction of GPIO"<< this->gpionum <<" ."<< endl;
            return -1;
        }
 
        setdirgpio << dir; //write direction to direction file
        setdirgpio.close(); // close direction file
        return 0;
}
 
int GPIOClass::setval_gpio(string val)
{
 
    string setval_str = "/sys/class/gpio/gpio" + this->gpionum + "/value";
    ofstream setvalgpio(setval_str.c_str()); // open value file for gpio
        if (setvalgpio < 0){
            cout << " OPERATION FAILED: Unable to set the value of GPIO"<< this->gpionum <<" ."<< endl;
            return -1;
        }
 
        setvalgpio << val ;//write value to value file
        setvalgpio.close();// close value file
        return 0;
}
 
int GPIOClass::getval_gpio(string& val){
 
    string getval_str = "/sys/class/gpio/gpio" + this->gpionum + "/value";
    ifstream getvalgpio(getval_str.c_str());// open value file for gpio
    if (getvalgpio < 0){
        cout << " OPERATION FAILED: Unable to get value of GPIO"<< this->gpionum <<" ."<< endl;
        return -1;
            }
 
    getvalgpio >> val ;  //read gpio value
 
    if(val != "0")
        val = "1";
    else
        val = "0";
 
    getvalgpio.close(); //close the value file
    return 0;
}
 
string GPIOClass::get_gpionum(){
 
return this->gpionum;
 
}

In order to open and close files in C++, the ifstream/ofstream  classes where used. Even though the C++ string class was used, the C++ strings had to be converted into C strings since pathnames in Linux can only be interpreted as C strings.  The GPIOClass is pretty self explanatory. It is also very basic I intend to clean in up a bit in the future, but for now it will have to do.

A main program “GPIOtest1.cpp that tests this class is provided below:

Code: [Select]
#include <iostream>
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include "GPIOClass.h"
 
using namespace std;
 
int main (void)
{
 
    string inputstate;
    GPIOClass* gpio4 = new GPIOClass("4"); //create new GPIO object to be attached to  GPIO4
    GPIOClass* gpio17 = new GPIOClass("17"); //create new GPIO object to be attached to  GPIO17
 
    gpio4->export_gpio(); //export GPIO4
    gpio17->export_gpio(); //export GPIO17
 
    cout << " GPIO pins exported" << endl;
 
    gpio17->setdir_gpio("in"); //GPIO4 set to output
    gpio4->setdir_gpio("out"); // GPIO17 set to input
 
    cout << " Set GPIO pin directions" << endl;
 
    while(1)
    {
        usleep(500000);  // wait for 0.5 seconds
        gpio17->getval_gpio(inputstate); //read state of GPIO17 input pin
        cout << "Current input pin state is " << inputstate  <<endl;
        if(inputstate == "0") // if input pin is at state "0" i.e. button pressed
        {
            cout << "input pin state is \"Pressed \".\n Will check input pin state again in 20ms "<<endl;
                usleep(20000);
                    cout << "Checking again ....." << endl;
                    gpio17->getval_gpio(inputstate); // checking again to ensure that state "0" is due to button press and not noise
            if(inputstate == "0")
            {
                cout << "input pin state is definitely \"Pressed\". Turning LED ON" <<endl;
                gpio4->setval_gpio("1"); // turn LED ON
 
                cout << " Waiting until pin is unpressed....." << endl;
                while (inputstate == "0"){
                gpio17->getval_gpio(inputstate);
                };
                cout << "pin is unpressed" << endl;
 
            }
            else
                cout << "input pin state is definitely \"UnPressed\". That was just noise." <<endl;
 
        }
        gpio4->setval_gpio("0");
 
    }
    cout << "Exiting....." << endl;
    return 0;
}

The GPIOtest1.cpp program is pretty straightforward. It first instantiates two GPIOClass objects attached to GPIO4 & GPIO17 (gpio4 and gpio17) on the heap. Note that the object names was chosen to reflect the GPIO pin number but could’ve been called anything else.

The GPIOs are then exported, GPIO4 set to output and GPIO17 set to input. At this point code execution enters into an infinite loop that reads the status of the input pin GPIO17. If the pin has a state of “0″, this means that the button could be pressed. The state of the GPIO17 pin is checked again to ensure that this is indeed the case. If so the GPIO4 pin is set to high, causing the LED to turn ON. Another while loop ensures that the LED is ON, so long as the button continues to be pressed. Note that line before “return 0;” , “cout << “Exiting…..” << endl;” never executes.

There is a major flaw in this program and that is, the only way to exit the program is to press ctrl-C. Terminating the program in this way means that the program is unable to unexport the GPIO pins. More importantly it means that the program is unable to free the heap memory allocated for GPIOClass objects gpio4 & 17.

One way of fixing this problem is to write a signal handler (software interrupt handler) and attach it to the SIGINT (ctrl-C) signal (event). This enables the program to jump to the signal handler whenever ctrl-C is pressed, instead of directly exiting the program. The signal handler can then initiate a graceful exit of the program i.e. deallocate heap memory and unexport pins before exiting. First we have to include:

Code: [Select]
#include <signal.h>
The next step is then instantiate a sigaction struct and to fill it  as follows:

Code: [Select]
struct sigaction sig_struct;
sig_struct.sa_handler = sig_handler;
sig_struct.sa_flags = 0;
sigemptyset(&sig_struct.sa_mask);

The first line above instantiates a sigaction struct called sig_struct. The second line causes the signal handler field (sa_handler) of sig_struct to point to a function called “sig_handler”. The “sa_flags” in the sigaction structure can be used to trigger certain behaviors that modify the signal event. The sa_flags field was chosen to be zero because the functionality it provides is not needed.  Finally the last line of code ensures that the sa_mask field of the sigaction structure is empty. The sa_mask field enables certain additional set of signals to be blocked during execution of signal handler function.

Once the sigaction struct “sig_struct” is completed, the “sigaction” function is used to map the filled “sig_struct” structure with the SIGINT signal  as follows:

Code: [Select]
if (sigaction(SIGINT, &sig_struct, NULL) == -1) {
        cout << "Problem with sigaction" << endl;
        return -1;
    }

We will also need to write the signal handler function “sig_handler”. This function’s entire purpose is to set a global boolean variable (a flag). When ctrl-C is pressed, program execution immediately jumps to the signal handler function and sets this boolean variable (flag) to “true”. In the infinite while loop in main this flag is polled. If it is asserted (by the signal handler), the program then exits gracefully ensuring all heap memory is deallocated and GPIO pins unexported properly.

Code: [Select]
void sig_handler(int sig)
{
    write(0,"\nCtrl^C pressed in sig handler\n",32);
    ctrl_c_pressed = true;
}

It is important to note here that functions called in signal handler functions must be re-entrant.  This is why the re-entrant “write” function was used instead of the non-re-entrant printf  or cout. The flag variable used in this example is “ctrl_c_pressed”.

The additional code added to the main program’s infinite while loop allows the program to exit gracefully and is provided below:

Code: [Select]
if(ctrl_c_pressed)
{
    cout << "Ctrl^C Pressed" << endl;
    cout << "unexporting pins" << endl;
    gpio4->unexport_gpio();
    gpio17->unexport_gpio();
    cout << "deallocating GPIO Objects" << endl;
    delete gpio4;
    gpio4 = 0;
    delete gpio17;
    gpio17 =0;
    break;
 
}

The complete code is provided below “GPIOTest2.cpp”:

Code: [Select]
#include <iostream>
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include "GPIOClass.h"
using namespace std;
 
void sig_handler(int sig);
 
bool ctrl_c_pressed = false;
 
int main (void)
{
 
    struct sigaction sig_struct;
    sig_struct.sa_handler = sig_handler;
    sig_struct.sa_flags = 0;
    sigemptyset(&sig_struct.sa_mask);
 
    if (sigaction(SIGINT, &sig_struct, NULL) == -1) {
        cout << "Problem with sigaction" << endl;
        exit(1);
    }
 
    string inputstate;
    GPIOClass* gpio4 = new GPIOClass("4");
    GPIOClass* gpio17 = new GPIOClass("17");
 
    gpio4->export_gpio();
    gpio17->export_gpio();
 
    cout << " GPIO pins exported" << endl;
 
    gpio17->setdir_gpio("in");
    gpio4->setdir_gpio("out");
 
    cout << " Set GPIO pin directions" << endl;
 
    while(1)
    {
        usleep(500000);
        gpio17->getval_gpio(inputstate);
        cout << "Current input pin state is " << inputstate  <<endl;
        if(inputstate == "0")
        {
           cout << "input pin state is \"Pressed \".\n Will check input pin state again in 20ms "<<endl;
           usleep(20000);
                   cout << "Checking again ....." << endl;
                   gpio17->getval_gpio(inputstate);
            if(inputstate == "0")
            {
                cout << "input pin state is definitely \"Pressed\". Turning LED ON" <<endl;
                gpio4->setval_gpio("1");
 
                cout << " Waiting until pin is unpressed....." << endl;
                while (inputstate == "0"){
                    gpio17->getval_gpio(inputstate);
                };
                cout << "pin is unpressed" << endl;
 
            }
            else
                cout << "input pin state is definitely \"UnPressed\". That was just noise." <<endl;
 
        }
        gpio4->setval_gpio("0");
 
         if(ctrl_c_pressed)
                    {
                        cout << "Ctrl^C Pressed" << endl;
                        cout << "unexporting pins" << endl;
                        gpio4->unexport_gpio();
                        gpio17->unexport_gpio();
                        cout << "deallocating GPIO Objects" << endl;
                        delete gpio4;
                        gpio4 = 0;
                        delete gpio17;
                        gpio17 =0;
                        break;
 
                    }
 
    }
    cout << "Exiting....." << endl;
    return 0;
}
 
void sig_handler(int sig)
{
    write(0,"\nCtrl^C pressed in sig handler\n",32);
    ctrl_c_pressed = true;
}

It is important to note that in order for any of these programs to execute properly you need to run them as root either via the sudo command (i.e. “sudo ./GPIOtest) or preferably login into to your root account with “sudo -i” before running the GPIO based program(s).
Woe to those who call evil good, and good evil;
Who put darkness for light, and light for darkness;
Who put bitter for sweet, and sweet for bitter!

Isaiah 5:20

OlDosLover

  • Hero Member
  • *****
  • Posts: 3859
  • OlDosLover
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #41 on: February 25, 2013, 09:11:08 AM »
Hi all,
    I wish i has a Raspberry Pi to try this out on. One day i will ! Thanks fatman!
OlDosLover.

Omega

  • Sr. Member
  • ****
  • Posts: 377
    • Recall site..
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #42 on: February 25, 2013, 11:45:55 AM »
oh... very cool.
I like this.


Time to boot up the PI.

fatman2021

  • Hero Member
  • *****
  • Posts: 978
  • Lord Jesus Christ, Son of God, have mercy on us.
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #43 on: February 25, 2013, 12:00:00 PM »
You should also check out /sys. It contains a lot of useful information (memory addresses, port addresses, video resolution, color depth, etc.) which may help you with your programming.
Woe to those who call evil good, and good evil;
Who put darkness for light, and light for darkness;
Who put bitter for sweet, and sweet for bitter!

Isaiah 5:20

TerryRitchie

  • Hero Member
  • *****
  • Posts: 2264
  • FORMAT C:\ /Q /U /AUTOTEST (How to repair Win8)
    • Email
Re: Anyone have QB64 running on Raspberry Pi
« Reply #44 on: February 27, 2013, 10:35:52 PM »
Finally got a Raspberry Pi in the mail yesterday. :)

When I get time I'm going to get QB64 working on it.  Thanks for all the info in this thread guys.

  • Print