Facing issues in integrating camera in raspberry pi (ov7251)
Steps we have followed
sudo raspi-config
Turn on the i2c interface
legacy camera is disabled
reboot
config.txt change gpu_mem = 128
libcamera-hello
libEGL warning: DRI2: failed to authenticate
Made X/EGL preview window
[0:02:41.853640220] [1549] INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3866-0c55e522
ERROR: *** no cameras available ***
If anyone knows smooth integration of camera interfacing for raspberrypi please reply
Related
I installed this module and have the corresponding RaspberryPi HAT(Waveshare Rpi 35A) attached to my Raspberry Pi.
After running modprobe ili9486 in the terminal:
In /sys/module, I see the device.
In /dev/ and /dev/spi/, I don't see anything with ili9486 in it's name.
How do I send a command to the device?
In specific how do I send the command to ili9486_probe, which will in turn, send the command to waveshare_command? My goal is to get the command to reach waveshare_command?
I didn't install the dtoverlay on the Waveshare github because I do not want touch screen features. I just want to write to the screen.
I am trying to run a simple hello world sketch using Visual Studio Code for ESP32. To upload and to see the response,
I typed "idf.py flash monitor" in terminal. It uploads successfully, but after upload, the messages said:
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
I am using ESP32 development board. 38 pin board.
Here, I have attached the screen shot.
So far I have worked only in Arduino IDE. I am new to ESP-IDF. What is the problem here?
You just have to select exactly the chip to correctly set the boot address at https://micropython.org/download/esp32/
for example, for the ESP32 Vendor: Espressif, Features: BLE, WiFi1, is
0x1000, with the command
esptool.exe --chip esp32 --port COM4 --baud 460800 write_flash -z 0x1000 esp32-20190125-v1.10.bin
The boot rom detects the state of the gpio boot pin when it's powered up. That pin is connected to a button on development boards. If the button is pressed while powering up, software reset will go to download mode rather than booting from the flash.
So the solution is to not press the button while powering up the board. In some cases maybe the button state is incorrectly detected, so just repower the board in that case.
press the boot button and then click reset button.
it worked out for me
I'm running into a very strange issue attempting to run CodeSys on a 4GB RasPi-4. Long story short, the Pi works fine right up until I start running the CodeSys project. When I do, within 60sec, eth0 goes down and cannot be brought back up. Even rebooting the Pi has no effect. The only way I've found to recover eth0 is to re-burn RasPiOS from the source image from Raspberrypi.org (which I've done about 30 times over the past few days, trying to trial-and-error my way out of this).
Linux raspberrypi 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
I have eth0 set to a static IP using /etc/dhcpcd.conf. Whatever is causing this issue is not altering my settings there. Attempts to use ifconfig eth0 up/down have no effect -- no errors, no feedback, just nothing. Checking eth0's state shows "waiting for carrier," despite being connected to an active switch (I've also swapped out all the cables and the switch to eliminate them as the source of the problem).
When I re-burn the Pi and install CodeSys, eth0 stays up indefinitely (24hrs+ in my longest test). It's starting the CodeSys project that kills eth0. A reboot after etho "dies" gives a series of bcmgenet messages that appear to be related:
pi#raspberrypi:~ $ dmesg | grep bcmg
[ 1.033665] bcmgenet fd580000.ethernet: failed to get enet clock
[ 1.033685] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
[ 1.033709] bcmgenet fd580000.ethernet: failed to get enet-wol clock
[ 1.033730] bcmgenet fd580000.ethernet: failed to get enet-eee clock
[ 1.044648] libphy: bcmgenet MII bus: probed
[ 9.528502] bcmgenet fd580000.ethernet: configuring instance for external RGMII
[ 9.535175] bcmgenet fd580000.ethernet eth0: Link is Down
I also tried creating a new CodeSys project from scratch that had no eth0 drivers (ModBus, Ethernet/IP) installed, only the GPIO driver. That didn't help either -- eth0 dies within 60sec.
The strangest part is, only eth0 seems to be affected. The GPIO pins keep cycling as controlled by the CodeSys project (I have a simple LED-blinking program running), and I can still SSH into the Pi using wifi. But since my main reason for setting this Pi up is to use Ethernet/IP and ModBus....
This thread: at GitHub is the only place I've found anyone describing anything similar to what I'm experiencing, but in that case CodeSys is not installed. I did try adding genet.skip_umac_reset=n to my cmdline.txt as suggested in the thread, but it had no effect.
So, it turned out this was an issue configuring the GPIO pins.
CodeSys has two difference "device" files for adding the GPIO pins to the project device tree. The default selection is for older Pi models, and the alternate choice (labelled only for B+ and Pi2) is the correct one for the Pi4.
As it turns out, the outdated GPIO device file will work on a Pi4, mostly. But using the wrong device file allows CodeSys to try configuring GPIO pins that shouldn't be tampered with. In this case, GPIO 28 and 29. Setting either of them to Output mode killed eth0.
Using the correct device file removes 28&29 from the list of configurable GPIO pins. It also gives the correct list of available GPIO pins for the newer Pi models, hopefully avoiding other potential config issues that I didn't trip over.
In CodeSys, right-clicking on the GPIOs element in the device tree offers the option to "Update the Device." Select this option to get the list of available device files, and select the correct one before using the "Update Device" button in the bottom of the window.
I've been trying to figure out how to upload a code to a STM32103c8T bulepill board.
My setup is
1- MacOs Catalina
2- STM32103c8T bulepill board
3- SLAB UART USB-TTL CP2012 V3.0
4- Platformio IDE
5- STM32 CUBE Programmer software which detects and connects to my board through UART.
meaning that It has no problem connecting but there are issue with setting up the Platformio
BTW I am new to the ARM world and I bought this board to examine its speed and deep sleep and interrupt, I mean all the things that an Arduino Uno can't do.
The thing is I have no idea on how to setup the platformio.ini File to comunicate with the board
using the UART method and not requesting ST-link dongle!
What I have now in Platformio.ini is:
[env:bluepill_f103c8]
platform = ststm32
board = bluepill_f103c8
framework = arduino
upload_protocol = stlink
upload_port = tty.slab_usbtoUART
and when trying to upload the program i get:
Uploading .pio/build/bluepill_f103c8/firmware.elf
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-12:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 1
hla_swd
none separate
Error: open failed
in procedure 'program'
OpenOCD init failed
shutdown command invoked
[upload] Error 1
I just need help getting the system talk to each-other and see each-other
P.S.
I want to go as bareMetal as possible and not to use arduino firmware HAL
You can use the following configurations:
upload_protocol = serial
upload_port = COMX/ttyx //whichever applies
There is a demo which comes with UV4L demo OS for Raspberry PI, https://raspberry:8080/stream/webrtc. When i run it on a macOS computer (Firefox browser), and select that a screen is to be shared, it always says 'no suitable video device found!' and apparently doesn't connect anywhere. Same happens when i go there on a Chromium browser on a Raspberry PI itself. There doesn't seem to be any error messages anywhere - some deprecation warnings but no more than that:
onopen() webrtc:197:25
navigator.mozGetUserMedia has been replaced by navigator.mediaDevices.getUserMedia webrtc:251:32
WebRTC interfaces with the “moz” prefix (mozRTCPeerConnection, mozRTCSessionDescription, mozRTCIceCandidate) have been deprecated. webrtc:105:25
{"iceServers":[{"urls":["stun:stun.l.google.com:19302","stun:192.168.0.101:3478"]}]} webrtc:104:21
onaddstream is deprecated! Use peerConnection.ontrack instead. webrtc:107
peer connection successfully created! webrtc:110:21
URL.createObjectURL(MediaStream) is deprecated and will be removed soon. webrtc:255:60
call(), request={"what":"call","options":{"force_hw_vcodec":false,"vformat":"60"}} webrtc:193:25
message =message webrtc:281:25
Where shall i look into?
Clarification: i can see my desktop in a 'local' box, so sharing has been successful, same on Raspberry PI. But it never goes to the other side, i can't even use the data channel - it is greyed out - so apparently no connection happens, at all.
The following command runs an instance of UV4L that allows to mirror your desktop or window to the Raspberry Pi HDMI display. Note that you must pass the SSL certificates .key and .crt (see the UV4L installation instructions to know how to generate them):
uv4l --enable-server --driver dummy --server-option '--use-ssl=yes' --server-option '--ssl-private-key-file=/home/pi/selfsign.key' --server-option '--ssl-certificate-file=/home/pi/selfsign.crt' --verbosity=7 --server-option '--enable-webrtc-video=no' --server-option '--enable-webrtc-audio=no' --server-option '--webrtc-receive-video=yes' --server-option '--webrtc-renderer-fullscreen=yes' --server-option=--webrtc-renderer-window=0 0 1920 1080 --server-option '--webrtc-receive-datachannels=yes' --server-option '--webrtc-receive-audio=yes' --auto-video_nr --server-option '--webrtc-receive-audio=yes --server-option '--port=9000'
You can then access the WebRTC streaming page at:
https://raspberry:9000/stream/webrtc
You must explicitly enable screen sharing in firefox or chrome according to the instructions written in the the same page.
I would check if the camera module on the pi itself is attached correctly. Did you try to capture a test image using something likeraspistill -o test.jpg yet? I've seen the 'No Suitable devices found' problem come up when I either didn't enable the camera on raspi-config or I didn't insert the camera's ribbon cable correctly. You can also check if you've connected the GPIO corresponding pins right.