GPIO using C

huxflux

Hi, I've been playing around with C and GCC on the Onion Omega for some days now. I just made some functions for manipulating the GPIO using C and have pushed it up to github. Remember you need gcc and Expansion Dock for this, and probably need to compile and link it on the Onion Omega itself.

https://github.com/huxflux/onion_omega_gpio

main.c is just testing the LEDs on the Expansion Dock to showcase that the functions are working. Nothing pretty, just chaotic.

All done on the Onion Omega.

Next is to find out how expled is done, since you can give values for each LED between 0x0 - 0xFF. Anyone know how he/she/they did it?

Kit Bishop

@huxflux Good to see someone else doing this too.
I published some C/C++ code for GPIO access some time ago - see https://github.com/KitBishop/new-gpio

huxflux

Very nice!

And very interesting too.. "new-expled - a program that uses GPIO pin access to control expansion dock led similar to the Omega supplied expled script" .. I know the GPIO's can only be set to 0 and 1.. but.. wondered how they could send in 0x0 - 0xFF.

EDIT: Just started reading from your sourcecode. Do you use their 'expled' binary to do your stuff?

Kit Bishop

@huxflux The expansion led is driven by using PWM output on pins 15, 16 and 17. Brightness of each of RGB is controlled by the duty cycle on the respective pins.
Polarity of the led control pins is the reverse of what one might expect. Component is on for a LOW out put and off for a high output. Thus a PWM duty cycle of 0% turns the component fully ON, 100% is fully OFF
The standard Omega supplied expled program (actually script) just uses the fast-gpio program to set the PWM output appropriately for each of the 3 pins
Running PWM output continuously requires a process to stay alive to toggle the pin state continuously. Using fast-gpio to do this requires 3 separate background processes - one for each pin
My new-expled program uses my libnew-gpio library. This library runs PWM in separate threads (not processes) - one thread for each pin. Thus (to keep these threads alive) only one background process is required to drive the LED

huxflux

Thanks for the explanation. Never heard of PWM until now. New to electronics.

Kit Bishop

@huxflux Though it is more about the Servo Expansion in general, quite a good description of PWM can be found at https://wiki.onion.io/Tutorials/Expansions/Using-the-Servo-Expansion#pwm-signals

Jeff Verive

@Kit-Bishop,

I have found that the PWM at 100% doesn't quite turn the LEDs off, but rather they illuminate dimly. I can compensate for this at the command line by issuing

fast-gpio pwm 15 200 101
fast-gpio pwm 16 200 101
fast-gpio pwm 17 200 101

Is this your experience as well? I haven't done much playing around with servos, but I'm presuming that the "thin" pulse stream at 100% is meant to keep servos happy (since they generally don't like constant DC waveforms).

Kit Bishop

@Jeff-Verive Yes - and this is kind of to be expected.
fast-gpio uses software to perform the PWM output. The main part of the code is:

while (1) {
	//// HIGH part of cycle
	gpio.Set(pinNum, 1);
	_Sleep(periodHigh);

	// LOW part of cycle
	gpio.Set(pinNum, 0);
	_Sleep(periodLow);
}

Where periodHigh and periodLow are set by:

dutyCycle       = (double)duty / 100.0f;
// find the period (in ms)
period 		= (1.0f/freq) * 1000;

// find the low and high periods based on the duty-cycle
periodHigh	= period * dutyCycle;
periodLow	= period - periodHigh; /

Even if periodHigh or periodLow are zero, there is still some software delay in switching the output state.

I recently did some basic analysis of PWM output - the details can be found here: https://community.onion.io/topic/710/some-observations-on-pwm-output-both-via-gpio-and-pwm-expansion