Concurrent processes/threads

5 posts
by bjs » Wed Jun 06, 2012 6:22 am
Hi guys,

Can anyone tell me if it will be possible to run concurrent processes or threads with the GPIO? What I have in mind is to run a sine wave oscillator via a DAC on one process and have an ADC as another process to log circuit response etc. I could then build some virtual instruments.
Posts: 26
Joined: Thu Mar 08, 2012 10:51 am
by Gert van Loo » Wed Jun 06, 2012 7:32 am
The GPIO don't care about concurrency. It is just a common resource so you should treat it as such: Only one thread should access a (set of) pins at a time.
If you read the GPIO register description you will see that they are designed for such usage as you can set pins high or low with a single write access. So you never need to use a read-modify-write which are the bane of threading. You do need to take care when you are yourself setting up the pins as the mode register are shared between pins. So only there do you need a lock-read-modify-write-unlock sequence. Normally that functionality is provided by a hardware-control-task which is called from each thread and is part of the OS (As the OS itself also needs to use the GPIO pins)
User avatar
Posts: 2292
Joined: Tue Aug 02, 2011 7:27 am
by bjs » Thu Jun 07, 2012 9:16 am
Thanks for your prompt reply Gert. I don't think I phrased my question very well. If I want to have virtual instruments like an oscillator and and data-logger I would presume that the software that implements each instrument would have to run as a separate process or thread, even though the GPIO is a common resource, since I would want to have both instruments running at the same time.

You will have to forgive me if I am being thick, I have had very little experience of hardware programming and I'm trying to get my head around it. :?
Posts: 26
Joined: Thu Mar 08, 2012 10:51 am
by Gert van Loo » Thu Jun 07, 2012 1:18 pm
It was a good question :-).
Let me elaborate for users who have the same question.
If you have two threads and each is using the GPIO just as set-pin-high-or-low, you have no problems providing the threads us different pins.
But you may also have two threads using the same pins or interface. For example you have an A-to-D converter which you read through one thread. Then you have a D-to-A converter which you control through a different thread. Now if both devices use the same interface (e.g. both use I2C or both use SPI) you have a problem. In that case you must use (or design) a common interface task/thread/driver which can support both threads.
User avatar
Posts: 2292
Joined: Tue Aug 02, 2011 7:27 am
by jdj » Sat Jun 09, 2012 6:24 pm
Just my $0.02;

This is what drivers are for (amongst other things); to give programs/processes/threads/<insert your name here> access to common, shared resources.

Usually a thread interfaces with a driver by requiring the program/thread/etc to ask the driver for access (for instance using 'open'). The driver will then check if the resource is free and if that is the case, it marks it as busy and returns a positive response to the caller. If another process/thread later wants to access the same resource it will deny that request.

Later, when the thread/process is finished with the resource it signals this to the driver through the 'close' command and the driver is then free to hand it out to someone else.

It is really up to the driver developer how this is handled in detail, but IMHO each GPIO pin should be a separate resource, so each pin can be assigned to a different program.

/ Daniel
Posts: 7
Joined: Mon Dec 26, 2011 3:15 pm