Open ajevticc opened 6 months ago
If RPi.GPIO is accessing the GPIO registers from user space at the same time as the kernel (in the shape of the onewire driver) then this is the expected outcome. The solution is not to use user space GPIO libraries - try the compatible rpi-lgpio library instead: https://github.com/waveform80/rpi-lgpio/
If RPi.GPIO is accessing the GPIO registers from user space at the same time as the kernel (in the shape of the onewire driver) then this is the expected outcome. The solution is not to use user space GPIO libraries - try the compatible rpi-lgpio library instead: https://github.com/waveform80/rpi-lgpio/
Many thanks for the response, although agreed that this is an easy fix, for most users this is not so obvious. Nor did I find it anywhere convenient as a heads up warning. Hence, wanted to leave a trace somewhere. Will be more aware of this in the future.
Describe the bug
In this thread (https://forums.raspberrypi.com/viewtopic.php?p=2218276#p2218276) it has been concluded that enabling 1-Wire protocol in the Raspberry Pi Configuration window, affects the usage of the GPIO4 pin as a generic I/O pin. This does not happen with I2C and SPI capable pins.
Steps to reproduce the behaviour
Device (s)
Raspberry Pi Zero 2 W
System
Logs
No response
Additional context
Note in the program itself, there is no call for the 1-Wire protocol. It is just enabled as an option to the Pi's GPIOs.
Personally, I consider this a bug, because if you are unaware of this behavior, and pin GPIO4 is critical to your application, a lot of debugging can go in to this. Especially that the hardware I2C ans SPI buses do not cause a similar affect.
I did not find a similar bug report.
Thank you for your time and this wonderful platform!