Given the significant differences in the voltage levels it is not safe to directly connect any RS232 signal lines to the Pi's GPIO. Even if the voltage of some RS232 drivers might be as low as 3 V, the logic one (called "mark") is represented as a negative voltage which will kill the Pi.
The standard specifies a maximum open-circuit ...
All Raspbian images should work in all models (provided they have been updated with suitable kernel/firmware).
It is, of course, possible to install incompatible software or configuration, but any reasonable settings work.
The CSI port of the Zero W is smaller than that of the Pi 2 and 3. You will need an adapter cable to make it fit. I'd say it's rather complicated to DIY that.
See e.g. here: Raspberry Pi Zero Camera Adapter or Camera Cable - Raspberry Pi Zero edition and others.
... and some nice additional information about the pinout is to be found here.
This Fingerprint Scanner is compatible with the Raspberry Pi Zero. As it uses UART to interface.
Amazon.com says the fingerprint scanner uses, "Simple UART protocol (Default 9600 baud)".
Since the Raspberry Pi Zero does have UART pins it is compatible.
Note: this fingerprint scanner is also compatible with all other versions of Raspberry Pi, as they all ...
To summarize the comments in an answer: if you want real gigabit throughput you cannot use any Raspberry Pi. The RPi Zero is the worst candidate. 10Mb would be more realistic. Raspberry Pi USB's are USB2.0. USB2.0 has an absolute theoretical maximum speed of 480Mbit - though, in reality you'd be lucky to get 300Mbit - and I dare say that would be half duplex ...
More than one device can be used on a Pi I2C bus provided that:
They can be configured to have different I2C addresses.
They can operate with a 3V3 bus.
They do not have their own I2C pull-ups to more than 3V3 (ideally they should have no pull-ups at all).
They use 8-bit I2C addresses (the normal case, you rarely see 10-bit address devices).
If your ...
Probably a bit late, but i had the same issue and it was impossible to find information, maybe this i'll help someone.
My Camera is almost exactly like the one in the photo, and it doesn't have a "sunny" connector.
What fixed it for me was just unscrewing it completely, pressing lightly on the sides of the sensor module, and reattaching everything, except ...
For users with macOS Sierra (and I think newer):
First, you need to have an RNDIS/Ethernet Gadget interface in the Mac's Network Preferences.
This is available as standard on Sierra. However, it might not appear automatically in the Network Preferences, and you may have to add it, using the + icon. The list of available interfaces to add will not include ...
As others have commented, yes, you can have multiple I2C devices (that's the whole point of a bus!)
Make sure that you only have ONE set of pull-up resistors on the bus. Presumably your oled card already has them, otherwise it would not be working. Unfortunately, many I2C vendors put pullups on their boards; the better ones put solder jumpers that you can ...
The above answer (goldilocks) is correct. I just wanted to add the steps without having to navigate to another site.
In the Pi terminal:
chmod +x adafruit-pitft.sh
Choose your correct screen size
Choose rotation (this can be ...
On these purple PCBs there are 5 sets of bridging pads.
On the front (component side) there is one pair of pads which may be bridged to tie the SCK (system clock) low. This will force the PCM510x to generate the system clock using its internal PLL. You may bridge these pads to remove the need for an external SCK or connect the SCK pin to ground (0V). The ...
We're using the CAN board from SK-Pang and it wouldn't work on the newer RPi v3 B+ model. dmesg logs gave us the same error message as you.
Turns out they've increased the frequency of the SPI onboard bus which is too fast for the CAN board. Simply decreasing the max SPI frequency solved the issue for us.
Edit /boot/config.txt and alter the overlay ...
I don't know if this helps but it reduces one possible source of error. Doing what the developers from systemd suggest is using a Unit file. Here is a very generic one for your problem. Create a new unit file with:
rpi ~$ sudo systemctl edit --force --full hid-keyboard.service
In the empty editor insert these statements, save them and quit the editor:
This seems weird to me.
It's for the same reason you cannot connect the USB ports on your laptop to your desktop and use SSH over that.
USB is not a symmetrical protocol, meaning the two parties in a relationship are not equals. One is the master, and one is the slave. This is controlled in hardware, and although I believe it would be pretty simple to ...
The problem was with how the wiringPi handles sleeping. Actual sleeps appear to not be accurate enough so a wait loop has to be used.
The solution was to change the call to the delayMicroseconds function in RCSwitch::transmit to delayMicrosecondsHard which is defined in wiringPi.c but not exported so I copied the implementation into RCSwitch.
The tvservice command does not consistently sense when HDMI is disconnected. Say you boot the Pi with HDMI, then manaully disconnect the HDMI cable. The tvservice command will still report that HDMI device is connected, in that -n, -s, etc. commands still report the last previously connected monitor via HDMI.
How about something like the following.
I'm using a list to store your pan and tilt values and capturing 1 image on each loop. Simply concatenating the string value of i onto 'image' followed by .'jpg' to create the image name.
panTilt = [[ 30, -10],
[ 20, 0],
[ 10, 10],
Here's what I do for C++
sudo apt-get install build-essential
sudo apt-get install g++-arm-linux-gnueabihf
sudo apt-get install gdb-multiarch
arm-linux-gnueabihf-g++ -v to test the installation.
After that, open "testing.cpp" and put in
using namespace std;
cout << "Hello, World!";
The culprit turned out to be the mini OTG adapter: It is cute, but it doesn't work with the hard drive. Switching to a regular OTG cable made the drive appear.
Following is a diff of the boot messages when using the mini OTG adapter and the OTG cable. The message timestamps have been removed to produce a clean diff. Someone more familiar with Pi hardware ...
If the OS loads correctly but randomly freezes, there might be something wrong with the RPi, but if the boot process gets interrupted, or paused for a very long time without letting you login it most likely means the DHCP server is trying to find the interface in which your Pi was set and thus you may need to boot again on the other Pi and disable wifi, or ...
You need to connect the ground of the two Pis together as well as any GPIO you want to use for data transfer.
If the grounds are not connected the Pis can not tell if a GPIO is set high or low by the other Pi.
As @Arnaud suggests it would be sensible to add a resistor somewhere in-line between each Pi GPIO to other Pi GPIO connection. Something of the ...
You are correct, they are overclocked in the sense that the processors come off the same production line as the ones in other single core models and "binned" according to how they test.
However, this is not at all a phenomenon unique to the Pi or Broadcom; Intel and presumably most or all other microprocessor manufacturers do this as well.
I think the issue is down to the differences in the processors. The Rasberry Pi 3B+ has a ARM Cortex-A53 and the Pi Zero has a ARM1176JZF-S processor. Both are ARM CPUs, but the 3B+'s CPU is a much newer ARMv8 architecture compared to the Zeros' ARMv6 architecture. They are similar, but not exactly the same. Think Intel Core 2 Duo vs Core i7. The i7 can run ...
The issue turns out to be that the Raspberry PI's RNDIS module generates a pair of random MAC addresses for the network each time it starts up.
The host therefore sees a new device attached to its network each time, hence the issue described in the question.
The solution is to set the MAC addresses on the PI rather than allowing them to be set.
Unless you have changed your router's IP address, neither of these look like a normal router address. 192.168.0.1 or 192.168.1.1 are more common: Google your router's name and "default IP address" to find out what it should be, then browse to that IP it to check it hasn't changed. If it really is 192.168.88.44 then your RPi static address will need to be ...
Put one Pi Zero in USB Gadget mode for Ethernet. This will create the equivalent of a WiFi network between them only needing one USB cable and some software configuration. You could solder the test pads for the USB ports together once you're in a stable working configuration to save on weight.
Following directions from here and here:
echo "dtoverlay=dwc2" |...
As there is no delay / sleep in the code, you are hitting the CPU & the underlying Linux systems pretty hard - I'd imagine that at some point some housekeeping is being triggered and I've seen SD Card writes tie up a Pi for a second or two.
Can you put a sleep(0.01) at the bottom of your while loop - this will reduce accuracy / response time by a 100th ...