I wrote some code to activate a video when a motion sensor detects movement.
So far everything works while everything is wired to the breadboard.
When I connect my motion sensor to the Pi itself, it keeps triggering itself even when there is no motion.
Any idea what could be wrong?
The sensor is connected to GPIO4. When I wire the cables directly on the Raspberry on the corresponding pins the trouble starts.
Do I have to change something in my code when directly wiring to the Pi?
Thanks in advance for any kind of help.
Below my code and a picture of my breadboard setup and the setup when it's wired diretly to the Pi.
Also my config text is included below:
from gpiozero import MotionSensor, LED, Button
from time import sleep
import vlc
playing = set([1,2,3,4])
# creating Instance class object
vlc_instance = vlc.Instance()
player = vlc_instance.media_player_new()
player.set_fullscreen(True)
#Motion Sensor
pir = MotionSensor(4)
#Led
led = LED(26)
#Button
button= Button(18)
led.off()
print("Sensor wordt geladen.")
pir.wait_for_no_motion()
sleep(5)
while True:
print("Ready")
pir.wait_for_motion()
sleep(1)
print("Motion detected")
led.on()
sleep(1)
led.off()
player.set_mrl("/media/pi/GROT/MOSA25.mp4")
player.play()
sleep(120)
while player.get_state() in playing:
sleep(1)
continue
print("Finished")
sleep(600)
continue
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
# Automatically load overlays for detected cameras
camera_auto_detect=1
# Automatically load overlays for detected DSI displays
display_auto_detect=1
# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
# Disable compensation for displays with overscan
disable_overscan=0
[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1
[all]
[pi4]
# Run as fast as firmware / board allows
arm_boost=1
[all]
gpu_mem=156
Related
I have custom board which I program through SWD pins.
When I debug with 16Mhz(default clock), my blink code works.
When I increase it with PLLCLK, it gives an error such as "Break at address "0x2b003300" with no debug information available, or outside of program code." with different addresses.
PLLCLK 16Mhz works.
RCC HSE Crystal/Ceramic Resonator
SYS Trace Asynchronous Sw/Serial Wire (tried both)
In debugger screen, SWD is selected and enabled. I tried with various SWV Clock.
I am trying to use the USB Device library on STM32Cube but when I execute using the debugger or that I try to turn an LED on in CDC_Receive_FS, it never reaches that point.
Here is how I set up everyting:
My board is a NUCLEO-F746ZG
I enabled USB_OTG_FS in Device_Only mode, activated _VBUS and _SOF. Left everything else by default and USB On The Go FS global interrupt is enabled!
I set up USB_DEVICE: Class For FS IP set to Virtual Port Com, left everything by default
Main loop left empty
CDC_Receive_FS: put breakpoint in it and/or HAL_GPIO_WritePin(LD1_GPIO_Port, LD1_Pin, GPIO_PIN_SET);
I have TIM2 set up for the things I would like to do when it will work
Then I tried to send data to the board, first using Python using serial with a baudrate of 921600 but got nothing. Then using PuTTY with a baudrate of 9600, still nothing...
If anyone has a clue, I have been struggling with it the whole day.
Here is the whole project: https://ecloud.global/s/cjGYqK6z9g58Lm4
We're currently using STM32F373CC micros in several of our designs. Part of our standard design has an EEPROM connected via I2C. We have our own hardware layer that is tried and proven over the decades. However, it relies on the I2C port pins having pull-ups connected externally.
On some of our new designs we have designed out the pull-up on the SCL line and have set the port pin to Push-Pull mode. In theory, this should be no problem. However, what we've found is that the micro seems to be treating the port pin as open-drain regardless of the setting. For this particular design, we're using PF6 and PF7 as SCL and SDA respectively. With no pull-up connected, the SCL line is flat-lined. With internal pull-up enabled, the SCL line is pulsing, but the rise time is so long it's not working.
Nothing in the reference manual or the datasheet says anything about this issue. In the errata sheet we have (V4), there's quite a bit about the GPIO and I2C, but nothing that seems to relate to this.
For what it's worth, I'll copy and paste the relevant bit of the initialisation:
switch( kasPinMap[eSCL].lwI2CNum )
{
case 1: RCC_APB1ENR.I2C1EN = TRUE; nI2CEEpsRegisters = (void*)&I2C1_CR1; break;
case 2: RCC_APB1ENR.I2C2EN = TRUE; nI2CEEpsRegisters = (void*)&I2C2_CR1; break;
}
//configure the pins
DIO_vConfigure( kasPinMap[eSCL].ePort, kasPinMap[eSCL].lwBit, DIOkeM_Alternate, DIOkeD_PushPull, DIOkePU_None, DIOkeSP_Medium, kasPinMap[eSCL].lwAFN );
DIO_vConfigure( kasPinMap[eSDA].ePort, kasPinMap[eSDA].lwBit, DIOkeM_Alternate, DIOkeD_OpenDrain, DIOkePU_None, DIOkeSP_Medium, kasPinMap[eSDA].lwAFN );
//reset and enable the peripheral
nI2CEE_vReset();
In the debugger, GPIOF looks like this:
AFR values are set to 4.
The I2C registers look like this:
And the RCC registers look like this:
Our Technical Director mentioned that to comply with the I2C standard and allow for multi-master mode, both SCL and SDA should both be open-drain. However, all we have here is the F3 and the EEPROM.
Any thoughts on why we might not be getting the push-pull action out of the SCL line would be appreciated.
I have a Raspberry pi 3 with the 7" dsi touch screen. I'm loading an empty bundle factory image of Android Things 0.5.1 and I'm having two possibly related issues.
Firstly, the boot animation is incredibly slow. Something in the neighborhood of 2 frames a second.
Secondly, once it boots up to the dev preview connection screen the font is larger than it should be. When I load my app onto the device it is clear that there is something wrong with the resolution or pixel density.
I have tried this on versions 0.5.1 and 0.5.0 and get the same results on both.
Here is my config.txt file
kernel=u-boot-dtok.bin
framebuffer_depth=16
# Prevent the firmware from loading HAT overlays now that we handle pin muxing.
# ourselves. See:
# https://www.raspberrypi.org/documentation/configuration/device-tree.md#part3.4
dtoverlay=
dtparam=i2c_arm=on
dtparam=spi=on
dtparam=audio=on
# pwm and I2S are mutually-exclusive since they share hardware clocks.
dtoverlay=pwm-2chan-with-clk,pin=18,func=2,pin2=13,func2=4
dtoverlay=generic-i2s
start_x=1
# Tell U-boot to always use the "serial0" interface for the console, which is
# set to whichever uart (uart0 or uart1) is set to the header pins. This doesn't
# interfere with the uart selected for Bluetooth.
dtoverlay=chosen-serial0
# Enable skip-init on the UART interfaces, so U-Boot doesn't attempt to
# re-initialize them.
dtoverlay=rpi-uart-skip-init
# Add pin devices to the system for use by the runtime pin configuration driver.
dtoverlay=runtimepinconfig
dtoverlay=uart1
dtoverlay=bcm2710-rpi-3-b-spi0-pin-reorder
# Tell the I2S driver to use the cprman clock.
dtoverlay=bcm2710-rpi-3-b-i2s-use-cprman
# Uncomment to disable serial port on headers, use GPIO14 and GPIO15
# as gpios and to allow the core_freq to change at runtime.
enable_uart=1
core_freq=400
# Enable hardware graphics acceleration.
dtoverlay=vc4-kms-v3d,cma-256
mask_gpu_interrupt0=0x400
avoid_warnings=2
# Support official RPi display.
dtoverlay=i2c-rtc,ds3231
dtoverlay=rpi-ft5406
hdmi_force_hotplug=1
hdmi_drive=2
When I downgrade to 0.4.1 this issues goes away and I get a speedy animation and the screen resolution goes back to normal.
Here is the config.txt for 0.4.1
kernel=u-boot-dtok.bin
framebuffer_depth=16
dtparam=i2c_arm=on
dtparam=spi=on
dtparam=audio=on
# pwm and I2S are mutually-exclusive since they share hardware clocks. To
# enable I2S comment out the pwm line and uncomment the generic-i2s line.
dtoverlay=pwm-2chan-with-clk,pin=18,func=2,pin2=13,func2=4
# dtoverlay=generic-i2s
start_x=1
# Tell U-boot to always use the "serial0" interface for the console, which is
# set to whichever uart (uart0 or uart1) is set to the header pins. This doesn't
# interfere with the uart selected for Bluetooth.
dtoverlay=chosen-serial0
# Enable skip-init on the UART interfaces, so U-Boot doesn't attempt to
# re-initialize them.
dtoverlay=rpi-uart-skip-init
# Uncomment to disable serial port on headers, use GPIO14 and GPIO15
# as gpios and to allow the core_freq to change at runtime.
enable_uart=1
core_freq=400
I have tried applying the fix found in this question but it did not make a difference.
Thanks for the help.
I have the same issue with the screen density with 7" Waveshare 1024x600 display. Display's density isn't identified correctly for some reason. It may be the display's manufacturer issue though.
You can see display reported values with ADB command:
adb shell dumpsys display | grep DisplayInfo
My display reported 240dpi, though the correct value is 160dpi.
Anyway, I've managed to set the correct density through ADB:
adb shell wm density <correct_density_value>
Good news is that you only need to set it once per image.
I have a sensor with the interrupt output connected to a input pin on my RaspberryPi. My goal is to trigger an event from the sensor interrupt. The data sheet for my sensor says that once an interrupt is triggered on the sensor, the interrupt status register will have the appropriate bit set to 1 and stay that way until it is cleared; while the status register has a status bit of 1, the interrupt pad on the sensor will be pulled down.
My problem is that I can see the status register correctly reflect an interrupt when I physically trigger the sensor. But when I read the pin from my Pi, I never see any change reflected. Here's the gist of my code:
import Sensor
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(11, GPIO.IN, pull_up_down = GPIO.PUD_UP)
s = Sensor.start()
while True:
print 'sensor int reg: ', s.readIntReg() # I do not clear interrupt
print 'pin value: ', GPIO.input(11)
The first print will change according to my interaction with the sensor as expected. The second print shows the pin holds 1 or 0 depending on whether it is set to pull up or down, respectively.
It seems like the problem lies in that whenever the interrupt fires, the sensor is pulling the pin down and the Pi is pulling it up... How should I handle this?
The sensor is the VCNL4010 [https://www.adafruit.com/products/466]
I suppose you have the gpio driver installed and active on the Pi?
Then you'll probably never see the interrupt triggering from the Python level since the kernel driver will service it (and reset the flag) already in the background.
I added a 10k external pull-up resistor with 3.3V and that did the trick... not sure why the internal pull-up on the Pi didn't do the same, perhaps I configured it wrong.
UPDATE: That turned out not to be the issue at all. I was neglecting to explicitly set the sensor to free run mode. Part of my code had the unintended side effect of setting that mode so in tweaking things for test sometimes it worked. The pull-up on the Pi works fine.