libgpio example on Beaglebone

I am messing with libgpio and I modified the example below to work with the Beaglebone.
http://www.claydowling.com/blog:blinking_lights_with_gpio
The difference with the Beaglebone is it uses 4 gpio controllers. Labeled gpioc0-gpioc3.
Each has 32 pins assigned.
I wanted to use blink.c to run the onboard LED's for some easy testing.
This meant I needed to use gpioc1, pin 21. By default libgpio's open_gpio function defaults to gpioc0.
I noticed Emmanuel's example includes the 'unit' controller.
So i used that and it works. There are Pins 21,22,23,24 available to manipulate. All on gpioc1.
Code:
   #include <inttypes.h>
    #include <libgpio.h>
    #include <stdlib.h>
    #include <stdio.h>
    #include <unistd.h>
 
    gpio_handle_t handle = -1;
    int pin = 21;
    int unit = 1;
    int main(int argc, char **argv)
    {
       int low_time = 1;
       int high_time = 1;
       int ch;
 
       while((ch = getopt(argc, argv, "h:l:")) != -1) {
           switch(ch) {
           case 'h':
               high_time = strtol(optarg, NULL, 10);
               break;
           case 'l':
               low_time = strtol(optarg, NULL, 10);
               break;
           case '?':
           default:
               fprintf(stderr, "%s [-l low_time -h high_time]\n",
                   argv[0]);
               return EXIT_FAILURE;
           }
       }
 
       handle = gpio_open(unit);
       if (-1 == handle) {
           perror("gpio");
           return EXIT_FAILURE;
       }
       gpio_pin_output(handle, pin);
       while(1) {
           gpio_pin_high(handle, pin);
           sleep(high_time);
           gpio_pin_low(handle, pin);
           sleep(low_time);
       }
 
       return EXIT_SUCCESS;
    }
 
Can anyone give some insight as to the "while h:l statement".
Is this a feature which allows command line argument like blink.app 5:5 to change the low / high time from the default 1:1 seconds?
I am lost with strtol(optarg,NULL, 10); Is that 10 seconds? What does 10 represent?
Thanks
 
Why are they converting numbers in the section of code? It seems like it should be a simple high - low and I wonder what that section does.
Is this a high-low tick- tock back and forth function?
 
I lost all my C-fu about 20 years ago and it was low quality Fu event then, but I would guess you are getting characters from command line so you have to convert them to numbers before using them in timers.

And the while loop is straightforward I think - While getting command line options, if it is h, convert to number and save to high_time, if it is l, convert to number and save to low_time, if it is something else, print usage info to stderr and exit.
 
high_time and low_time are declared with a value before the section.
Yes, they are and you can change them here. So flow is following - Set default value for both, check if user wants another values, if he does, update given variable, if he did something wrong, exit with error, else proceed.

Set some reasonable defaults and update them with user input if any exists is common way how to do that.
 
OK I got it figured out. That section sets the -l and -h command options.
Code:
root@BBB3:/libgpio # ./blinky21.app -l
blinky21.app: option requires an argument -- l
./blinky21.app [-l low_time -h high_time]
root@BBB3:/libgpio # ./blinky21.app -l 3 -h 3
This blinks it at 3 seconds instead of 1 second.
 
OK so 1 second high-low cycle is pretty boring.
I want millsecond instead of seconds for interval. How can I do that?

My first thought was try to use a decimal like this:
int low_time = .1
That didn't work because of data type, so I used:
double low_time=.1
That compiled but it did not seem give me any faster interval.

What do I need to change for shorter sleep time?
 
Use usleep() instead of sleep().

Googleing freebsd c timer functions gives nice result. This for example is a nice intro, considering also controller needs.

Edit: You might like to google for am335x_pwm too. But that is more complex stuff...
 
Phishfry
OT: I got curious about Beaglebone because STM32 / Cortex M7 still seems not supported by arm-eabi-gcc. (Had bought one kit some time ago only to find out one needs Windows+Eclipse for compiling that... Bleech...)
So I'd like to ask you, when using Beaglebone, can I use HDMI for console output and USB keyboard using FreeBSD, or is it necessary to do things via ssh only? Because I am thinking about getting a BeagleBone too...
 
BBB HDMI support hit in FreeBSD11 so anything greater than that has HDMI enabled by default.

I will say for messing with PWM that FreeBSD 10.4 has PWM enabled by default with sysctl's available. No HDMI though.
Newer FreeBSD needs to have dtb modified to have working PWM. I still have one running 10.4 to avoid this hassle.

I had to use another way to flash the eMMC for FreeBSD11.
I write an FreeBSD BBB image to microSD but after writing image I gpart resize and growfs.
Then I mount and copy the FreeBSD 11 BBB image onto the microSD card in the root dir.
Boot up off the microSD card and use dd to write the image to /dev/mmcsd1.
I stole the idea from this post.
https://forums.freebsd.org/threads/61551/#post-354484

I have used the crochet script copy-to-emmc.sh but it was failing for me with FreeBSD 11.
 
Thank you very much!
Sounds great! I know it's not yet so well-supported like on Linux, but I'd like to avoid Linux (don't need it for my purposes, just some timers and digital in/outputs and i2c).
Will order a BBB today :)
 
In the future I want to use microSD for writing temperature data from onewire. Instead of wear and tear on the eMMC.
I had bad luck with my RRD database on a USB thumbdrive.
It would become stuck(unresponsive) or knocked offline every 4-6 days. I did not have it auto mounted so that experiment ended badly.
I think BBB will make a better candidate with eMMC and microSD.
I might even build a NanoBSD for the purpose.
 
Hmm just reading around a bit how to avoid eMMC. Seems possible to boot directly off microSD...

Regarding USB thumbdrives, I have very bad experiences too.
Even brands like Verbatim were very disappointing, sometimes lived only for days.

In my experience it seems better to use Samsung microSD in an USB-microSD adapter. This way one can be sure to have high-quality flash memory. Didn't have a Samsung SD failure yet. But let's see what will come with BBB wearing it out :)

Edit: This thread says that /boot/uEnv.txt determines the sequence which possible boot devices are checked. <still reading>
 
I have found a line of industrial microSD card that are worthy. Apacer.

Booting off the microSD card works well. I prefer the eMMC so I can use microSD slot for RRD database.
Will see how well it works. USB storage mounting was disappointing.
Was writing to disk every 10 seconds.

The boot sequence on BBB is also influenced by a switch. Hold it down to switch boot device on startup.

Analog support is one of the reasons I am back to my original Arm board.
https://obsigna.net/?p=660
 
This thread says that /boot/uEnv.txt determines the sequence which possible boot devices are checked.
The boot sequence is defined by 5 LSBs of SYSCON register, which are wired to the LCD_DATAx pins (x=0..15), the official Technical Reference Manual has a comprehensive description on page 5028. The BBB schematic has a brief description. The installed switch S2 sets bit 2 low to force booting from micro-SD card (MMC0).
Regarding using u-boot's files like uEnv.txt etc.: they are read by u-boot, which means it's already loaded - either from eMMC (MMC1) or from micro-SD (MMC0). So, yes, then you can "forward" your booting process to another device, but first you have to "get" to that file.
 
can I use HDMI for console output and USB keyboard using FreeBSD, or is it necessary to do things via ssh only?
I see no reason to use HDMI unless you want to run a graphical application. I agree, that SSH is not always convenient since e.g. you have to know the IP address.
IMO it's much more handy to login via serial terminal which works out of the box (pins 4, 5 and 1 of J1).

Also, there available 7" LCDs ("capes") which can be used to make a stand alone device: 7-beaglebone-capes without any soldering.
 
Phishfry Apacer seems really interesting, they even seem to offer SLC flashes. Probably much more durable and better data retention (important for my application).
aragats According to an (old) Rev. A3 schematic these LCD pins seem to be centered by 2x 100k between GND and Vcc. Meaning boot device could be selected by a tristate buffer turned on for the first (few) seconds after power-on/reset. Simple 555 could control that. So one could directly select the boot device without need for modifying u-boot, if I understand correctly. Would be very sweet.

I want to build sort of home controller via touch screen, so HDMI+touch is most important factor for me. Currently searching and looking around about support level state. Seems to be some support on FreeBSD for some time already :)
 
In the future I want to use microSD ... Instead of wear and tear on the eMMC.
just reading around a bit how to avoid eMMC.
I envision an "ideal" system which boots off eMMC but uses it in read-only mode. All user data go to micro-SD.
Thus you'll have a reliable system without mechanical contacts and with removable storage.
Also, do not forget that eMMC has 8-bit interface whereas micro-SD only 4-bit. There is very noticeable difference in speed.
 
Meaning boot device could be selected by a tristate buffer turned on for the first (few) seconds after power-on/reset.
If you decide to not use any LCD at all, you do not need to control those pins dynamically, i.e. just leave them configured as inputs and tie to vcc/ground all times.
 
I wanted to note that obsigna website instructions for ADC work on FreeBSD 11.1 as well as -CURRENT

Next up tonight potentiometer tests on AIN1

I envision an "ideal" system which boots off eMMC but uses it in read-only mode. All user data go to micro-SD.
That was my thought too with a NanoBSD build to preserve the eMMC cells.
 
The Newhaven LCDs I mentioned above are touch screens. They have capacitive touch panel with i2c interface.
Just perfect :) Will look around for a distributor in Germany :)

I envision an "ideal" system which boots off eMMC but uses it in read-only mode. All user data go to micro-SD.
Thus you'll have a reliable system without mechanical contacts and with removable storage.
Also, do not forget that eMMC has 8-bit interface whereas micro-SD only 4-bit. There is very noticeable difference in speed.
Hmm, good point... like eMMC as part of "extended firmware" containing OS and application, and microSD as "drive", containing user data, sensor logs etc...

If you decide to not use any LCD at all, you do not need to control those pins dynamically, i.e. just leave them configured as inputs and tie to vcc/ground all times.
oh yes :) with HDMI no need for LCD pins :)

this all makes me really appetite!
 
Back
Top