The pigpio library supports remote GPIO: http://abyz.me.uk/rpi/pigpio/
The GPIO Zero library also supports using pigpio as the pin driver, so you can use the GPIO Zero API with pigpio features. See the sections on remote GPIO: https://gpiozero.readthedocs.io/en/stable/remote_gpio.html and https://gpiozero.readthedocs.io/en/stable/recipes_remote_gpio.html
I realize this is an old thread but it's still high on the Google ratings so an update. I've just built a NAS using a Raspberry Pi 4+ 4GB and four external 1-TB backup drives (Seagate Basic Portable STX1000400). The Pi's power over USB is insufficient to run four spindles, so it requires a powered USB hub, but this also has the advantage of spinning all ...
Plenty of ways if you share a network (wired or wireless) with the Pi.
Have a look at my pigpio especially the Python module. That will allow you to control the GPIO from another Windows, Mac, Android, Linux machine as long as it can run Python. Each Pi you wish to control must have the pigpio daemon running on it.
Also have a look at gpiozero which lets ...
For GPIO 2/3 (pins 3/5) to operate as the I2C bus they must be in a GPIO mode called ALT0.
They are set to this mode when the Linux I2C/SMBus driver is loaded.
The RPi.GPIO module is changing the mode of GPIO 2/3 to INPUT. This stops the proper operation of the I2C bus.
You need to again set the mode to ALT0 for GPIO 2/3 for the bus to operate again.
The mode of each pin is either in, out or any of the other functions (I2C in this case). Pins 3 and 5 are in ALT0 mode by default after reboot if the I2C driver is active. Type gpio readall on the command line to see which pins are in which mode.
To do the same as
gpio mode 8 alt0
gpio mode 9 alt0
in code, you need to do something like
These types of radio systems are inherently unreliable, which is the reason the transmitter tends to repeat the signal multiple times. Ten repetitions is not unusual. As an aside consider a TV infrared remote control, it will continually transmit the signal until you take your finger off the button.
The receiver is seeing radio static. The automatic ...
I also faced the same problem while I was working on it for the first time. But after some debugging, I concluded that after cleanup, the pins go to the default state which is high for few pins and low for some. Trying by not to clean the state of the pins might solve your problem.
This does a fairly accurate job of reading pwm fq and dutyCycle, as long as the signal is < 50hz:
import RPi.GPIO as gpio
from datetime import datetime
from time import sleep, time
risingCount = 0
You appear to have got confused between the pin numbering of the GPIO connections on the Pi. There are several conventions including BCM (Broadcom pin number, commonly called "GPIO") and Physical (Number corresponding to the pin's physical location on the header).
The tutorial is using the BCM numbering however you have placed your connections in the ...
UART is an odd choice for connecting two computers. It's definitely possible to use it with a bit of programming, but don't expect there to be many pre-existing options in terms of software.
If you use any kind of network as a connections, there are many tools which allow you to forward keystrokes over the network, starting with USBIP (which forwards data ...
You can use any spare GPIO as a chip select as far as the Linux kernel SPI driver on the Pi is concerned.
Whether a HAT or other device can use that GPIO as a chip select depends on several things.
Is the GPIO used by the HAT or other device hard wired by the HAT or other device
Have you got access to the HAT or other device software to make the needed ...
The correct answer was from Janka, I'm adding these info for reference to other people that will try to do the same thing with no success.
Following the Janka's directions I was able to get the job done.
Well, my fault was pretty silly and was about the PIN's numbers: I was using the connector number but the correct value is the BCM pin.
I found this tool:...
Your schematic is not a good idea: It will put 6V on your GPIO pin, and fry your RPi. You could save yourself some money by avoiding the obvious mistakes :)
The best solution for driving a MOSFET from your 3.3V GPIO is a Darlington Pair. Here's why I say this.
If you want to drive an n-channel MOSFET as you've shown in your schematic, simply swap the npn ...
Firstly you are applying 6V to the GPIO and are likely to damage the Pi.
There is nothing you can do to make a MOSFET which needs more than 3.3V miraculously work. Although you could use a transistor to drive the gate.
There ARE MOSFETs which switch with 3.3V Vgs although most need more.
It seems you are missing the critical part of converting RS232 signal (which is not 3.3 V) to RPI GPIO compatible 3.3V Signal as described in this example:
On GPIO header of RPi you can find a so called UART pins. In fact, it ...