Your previous program run must have exited but left GPIO pins in use. The next run of the program is warning you that it is reassigning pins that are in use. If you execute
before the program exits then it won't happen.
According to the official docs you can switch off their usage in /boot/config.txt. Just set force_eeprom_read to 0.
Set this option to 0 to prevent the firmware from trying to read an
I2C HAT EEPROM (connected to pins ID_SD & ...
Is there a device that e.g. uses i2c to set it's pin states?
Yes, they are so called I2C expanders (already mentioned and linked on some other comments). For 100+ pins hovewer I strongly advise against branching them off a single Pi, I cannot really imagine how to route them for example in a building automation project.
Cool thing is I2C can be more or less ...
I've not used one personally, but this should do the job: http://www.nationelectronics.com/raspberry-pi-extensions/174-raspberry-pi-hat-32-io-port-expander-v11-mcp23017-i2c-black-0648260628239.html
It does cover the whole Pi, but should only be using I²C to set the pin states (it is what they say) allowing you to use other pins yourself. You can stack them ...
The option you are looking for is
value 0x10000 should perform a horizontal flip, 0x20000 a vertical one.
It's next to impossible to say for sure what is wrong with a self-compiled binary. Try installing an official version, e.g. for Buster there's https://packages.debian.org/buster/openocd
If there's a reason you must use the binary you have, you may want to try using -c "script openocd-pi.conf" instead of -f openocd-pi.conf. Double check the syntax ...
The build date (2018-06-09) on that binary is from before some major (good) changes were made to openocd. The raspbian source image is probably from the same version you had the binary for.
My suggestion is to get the source from git and compile it yourself:
git clone git://git.code.sf.net/p/openocd/code openocd
Got it working by doing the following for anyone coming here searching a solution to the same problem with the Sunfunder 10 inch touchscreen.
idletime=60000 # in milliseconds
while true; do
#echo $idle >> /home/pi/idle.log
if [ "$idle" -gt "$idletime" ] && [ "$...
This code will set the output Low for about 1 microsecond then reconfigure it as an INPUT.
So depending on what is connected this is expected.
If you want the state to persist remove the call to cleanup.
Probably found an answer thanks to @joan 's answer.
It seems like RPi.PWM can only do software PWM, but the fan requires hardware PWM to run as smooth as possible. To do hardware PWM on any GPIO pin, the pigpio daemon has to be executed, and controlled by Python. Therefore, pigpio has to be installed first and configured to be started on boot (systemd). ...
There are two fundamental differences between the two approaches.
The gpio utility (part of wiringPi)
is using hardware timed PWM.
appears to be setting a frequency of 40 kHz.
The RPi.GPIO script
is using software timed PWM.
is setting a frequency of 50 Hz.
I'd guess the frequency is the main factor.
The problem is caused by the line range(100) and None which is causing your loop to exit. You need to remove it. Where did it come from? It's not in the docs.
If you want to loop 100 times, change the while True: to for i in range(100):
Also it's probably just the way you pasted in the code here but your first line is indented, just make sure it isn't ...
I would look to use the gpiozero module as that’s more powerful but saying that the cleanup function is designed to reset all pins as it’s the last thing you should do in your program NOT part way through.
Also the setting of the pin mode should only be executed once in your program.
Normally, you would ‘reset’ the output by putting a high or low voltage ...
See RPi.GPIO documentation.
At the end any program, it is good practice to clean up any resources
you might have used. This is no different with RPi.GPIO. By returning
all channels you have used back to inputs with no pull up/down, you
can avoid accidental damage to your RPi by shorting out the pins. Note
that this will only clean up GPIO channels ...
For some reason (historic that made sense at the time I am sure), the Pi4J project followed the WiringPi software for pin layout. To quote their site:
Pi4J (by default) uses an abstract pin numbering scheme to help insulate software from hardware changes.
Pi4J implements the same pin number scheme as the Wiring Pi project
The good news is that ...
Probably your electrodes got dirty. For a quick solution, you can clean them, preferably with alcohol.
For a long term one, you can improve your design with a different sensor. E.g. use your floater to activate two fixed photo gates, or induction sensors/hall sensors with a magnet on the floater. Or even better: use an ultrasonic sensor to measure your water ...
No, the GPIO pins can not be used to drive a DC motor.
They can only supply a few milliamps of current at 3V3 which will not be enough. In addition driving any inductive load direct from a GPIO is likely to destroy the GPIO and the Pi. An inductive load is such as a DC motor or a relay coil.
You need a motor driver board or chip or discrete components (e.g. ...
You could use something like the Perma-Proto HAT to make an adapter between the Pi and the relay board. Use the regular 40-pin header to connect the Proto to the Pi, then solder on a custom 6-pin header to the Proto to mate with the relay. This would make the package a bit thicker, but would avoid wires and maybe you could use the Proto for other components ...
The output of gpio readall (which is deprecated) DO NOT show "default states" - they only show nominal usage and DO NOT show any user defined changes (although this does show the actual state (High/Low) of pins.
E.g. unless you specifically enable serial pins 8,10 are just GPIO inputs.
My program gpioread reads the ACTUAL state - and there are ...
Expected scenario: always turn off the bulb when the pi disconnects, turn on the bulb only from the script
NOTE: Please know this answer disregards all comments made to the OP's question.
The issue you're facing cannot be solved with software alone. You will need to add some hardware if you wish to maintain positive control of your relay at all times. As ...
You do not understand the way GPIO work.
You can control GPIO pins, setting High or Low, and the pins retain their state, even if the Pi is shutdown.
When you remove the Pi power the pins become undefined.
On re-applying power the GPIO pins are configured as INPUTS, with either a weak pullup or pulldown, which depends on the pin.
The pins ONLY become ...
None of the GPIO pins are 'multiplexed' in the sense you mean. In other words, some of the GPIO pins have alternate functions, but these are functions that you maintain control of in your configuration, and in your code. You do not need to worry about the system commandeering a GPIO pin for some other purpose.
There are many sources of detailed information ...