ScottM
Posts: 2
Joined: Mon Sep 28, 2015 12:22 pm

wiringPi: thread safe?

Postby ScottM » Fri Feb 17, 2017 1:39 pm

I have a handful of threads, each calling wiringPi's digitalWrite. Do I need to wrap a mutex around the digitalWrite call, or does it already have one internally?

Also, and off topic - I'm horrified to learn the GPIO pins come up at boot time as anything other than Input, pulled in some consistent direction. I'm more horrified to learn the start state of the pins varies with the hardware revision (and maybe OS?). This is beyond a joke. I realize this is not wiringPi's fault or problem, but if anyone has a way to hack the OS (raspian) to get the pins to a proper starting state as soon as possible at boot time (microseconds preferred to seconds), I'd love to know about it. My application currently only drives LEDs, but without at least ONE pin that is guaranteed to come up in a known state forever, it looks like I won't be using the pi for anything but LEDs.
User avatar
joan
Posts: 12702
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: wiringPi: thread safe?

Postby joan » Fri Feb 17, 2017 2:22 pm

ScottM wrote: ...
Also, and off topic - I'm horrified to learn the GPIO pins come up at boot time as anything other than Input, pulled in some consistent direction.
...
Boot time (the point in time that boot starts) has no effect on the GPIO. All the GPIO are set as inputs at power-up and all the accessible GPIO have fixed pulls set (some high, most low) at the same time.

Boot software will make the changes requested by device tree etc.
User avatar
gordon@drogon.net
Posts: 1946
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact:

Re: wiringPi: thread safe?

Postby gordon@drogon.net » Fri Feb 17, 2017 7:57 pm

ScottM wrote:I have a handful of threads, each calling wiringPi's digitalWrite. Do I need to wrap a mutex around the digitalWrite call, or does it already have one internally?
You can read the source. Get it here: http://wiringpi.com/ then make your own mind up.

However, knowing a little about how the hardware works will go a long way. The Pi's GPIO hardware does not need a read/modify/write cycle. Write a bit in one register to turn a pin on, write a bit in another register to turn that pin off, so no mutex is required.

If you're using digitalWrite() to control some external GPIO expander, then you may need to wrap mutexes round it, depending on the device. Again, inspection of the source code will help you here.
Also, and off topic - I'm horrified to learn the GPIO pins come up at boot time as anything other than Input, pulled in some consistent direction. I'm more horrified to learn the start state of the pins varies with the hardware revision (and maybe OS?). This is beyond a joke. I realize this is not wiringPi's fault or problem, but if anyone has a way to hack the OS (raspian) to get the pins to a proper starting state as soon as possible at boot time (microseconds preferred to seconds), I'd love to know about it. My application currently only drives LEDs, but without at least ONE pin that is guaranteed to come up in a known state forever, it looks like I won't be using the pi for anything but LEDs.
I'm horrified to learn that you've not read the manual. It's very predictable. The power-on values and pull up/down resistors are all in the Broadcom ARM peripherals manual.

After power-on, the bootloader enables the serial port and the aux. I2C port to read an eeprom (if present). It passes the eeprom data to the kernel as a device tree, then the kernel does what it needs based on that information and the device tree stuff in /boot/config.txt. No eeprom and nothing extra in the config file and it doesn't do anything else.

Do google "crushed to death by automatic garage door" though and build in your own interlocks for anything critical. This is why industrial PLCs cost 1000x more than a Pi.

-Gordon
--
Gordons projects: https://projects.drogon.net/