Here is some Python I used to test the reliability of software serial. The input side is fairly trivial. You just make the appropriate bit bang serial open calls in Python or C. The output side is more involved as you have to use waveforms to construct the bit stream.
The code here is using 7-bit rather than 8-bit data. The test was written at about the ...
A USB UART, such as FTDI, isn't really expensive. All your other options sound like they will cost you more in parts and time than the ~$13 it might cost you, and be unreliable or slow. Just go for the fast and trouble-free option, such as:
Sparkfun sells one too. In ...
The preliminary Raspberry Pi 4 Model B datasheet, section "5.1.1 GPIO Pin Assignments" says:
As well as being able to be used as straightforward software controlled input and output (with programmable
pulls), GPIO pins can be switched (multiplexed) into various other modes backed by dedicated
peripheral blocks such as I2C, UART and SPI.
The preliminary Pi4 datasheet shows there are 6 UARTs.
Given that UART 0/1 are both connected to the same GPIO you can only use one of them at any one time. So potentially there are 5 accessible UARTs at any one time.
You can enable each of the UARTs on the Pi4B by making appropriate ...
The Pi's UART has a fault (in the firmware). Whenever the port is opened there is a 30 µs low glitch on TXD.
See http://elinux.org/RPi_Serial_Connection#Unwanted_serial_garbage_input and search for glitch.
You will need to find a workaround as the fault will not be fixed.
What you are referring to is called Software Serial, where bytes are bit banged and create the same effect as a serial port.
Using a normal Linux distribution the answer is, No. The reason is because bit banging required real time processing of data, otherwise the data will just be junk.
This answer at Electronics Stack shows a USB board with 4 hardware ...
The properties of a USB serial converter have nothing to do with the hardware of the hosting system, but only with the USB serial chip itself, and the software stack of the hosting system.
The pi should be using stock Linux USB serial drivers.
Therefore, you can enable/disable the linkage of DTR to port open/close via the usual Linux method of clearing the ...
My pigpio library supports reading and writing 9-bit serial data. It uses bit banging so you can use any available GPIO.
If I remember correctly any speeds of 19.2 kbps or slower were pretty stable.
What bits per second do you need?
Reading (C, Python) is slightly easier than writing (C, Python).
@ChrisStrattons post describes how to use stty -F /dev/ttyUSB0 to avoid the hangup which results in a reset. Here is a snippet to do it in Python:
path = '/dev/ttyACM0'
# Disable reset after hangup
with open(path) as f:
attrs = termios.tcgetattr(f)
attrs = attrs & ~termios.HUPCL
termios.tcsetattr(f, termios.TCSAFLUSH, ...
The Raspberry Pi 4 supports up to 4 UART interfaces now that need to be enabled by means of an device tree overlay. You can find how to do this and which Pins are used here for now:
The RPi foundation is still preparing the documentation for this.
I found what you are looking for: an I2C/SPI slave to UART/IrDA/GPIO bridge.
They come in single and dual version (so 1 or 2 extra UARTs). They (NXP) also (for the other side in case needed) have I2C/SPI master to UART/IrDA/GPIO bridges.
More information can be found about these chips here and the master counterpart.
Maxim also has chips that do the exact ...
If you decide to skip adding extra hardware and just go the bit-banging route, this isn't as difficult as some picture it.
First off, your communication thread must go realtime:
struct sched_param param;
param.sched_priority = sched_get_priority_max(SCHED_FIFO);
if( sched_setscheduler( 0, SCHED_FIFO, ¶m ) == -...
This is probably the well known bug of the spurious character when the serial port is opened. I don't remember the details, something to do with the TX line dropping for an instant so signalling a spurious start bit. From memory it is a bug in the Raspberry Pi Linux driver. I don't know why it hasn't been fixed, it has been commented on for several years.
Assuming you are talking about one of these that looks like this
you should go over this to test your device.
From what I can see
This device communicates over serial port (USART) using board pins (8-TX, 10-RX) and supports the AT commands
When you connect this device to the PI, the required USART pins are connected to module and the rest of the pins are ...
I was having trouble making my SIM800 hat work with my Raspberry Pi Zero W; I thought it could be because of burnt gpios... So I tried with my Raspberry Pi 3. Same trouble.
I then found this solution and it works on my RPI III (I have not tried on Zero):
In this tutorial we ...
This is not correct. Even single core CPUs are capable of running multiple processes giving them short time window to run and then switching to next process. Also both Python and C programs are capable of using the same services from system so you can achieve the same from both.
The easy answer is no, the hard answer is yes. The issue lies at the heart of the Linux operating system. Linux is not a real time operating system, unlike the Arduino, so timing is an issue. Any process can take CPU time at any time, which can cause your timing to be off, making it very difficult to interpret the received signal on the remote device.
It works on a B+.
I added the following line to /boot/config.txt and rebooted.
I set the baud rate to (the maximum) 4000000 with
stty -F /dev/ttyAMA0 4000000
I then sent 262 "A"s to the port with
I believe they are referring to the pin on the hat not the pin on the Pi. If you look at the following picture . You will see pin #4 labeled in the third row of pins across the top. It is a little hard to be sure from the pic but it looks like it is connected to GPIO4.
Let me try to un-confuse you :)
In the good old days, computers came with serial ports. The standard is known as RS232. These slowly disappeared, first from laptops and then from desktops. These days, you can use either internal cards, or USB-to-serial adaptors (but read on).
The serial connection on the Pi (also on Arduinos and other such things) is not ...
All GPIO pins can be either Input or Output, and many can have alternate functions. See Pinout for details of alternatives.
Depending on the Pi model, Pins 8/10 (BCM 14/15) are usually configured as UART. All GPIO pins are Input when first booted, except for the UART (the Pi3 also has these as input). This can be modified by Device Tree - set in /boot/...
All of the GPIO pins can be configured for different purposes. At their simplest they can all act as general purpose input/output (hence the name). This means they can be set to act as an outputs, thus the pin can be driven LOW (0v) or HIGH (3.3v). It can also be configured as an input where an external circuit drives the pin LOW or HIGH and the pi can read ...
Just yesterday I managed to make my assembly respond. Here are my steps:
Disable Serial Console
sudo raspi-config --> Interfaces --> Serial --> No to 1st prompt; Yes for the 2nd
Use "serial0" instead of "ttyAMA0" or "ttyS0"
*Edit: Appended working code
import RPi.GPIO as GPIO
import os, time
You can use multiple USB serial dongles. They will appear as /dev/ttyUSBx where x will be a small number such as 0, 1, 2. You can use any serial software you want. They will all use the Linux serial driver "under the hood".
You can connect one serial device directly to the Pi expansion header on TXD/RXD (GPIO 14/15, pins 8/10). The device must be 3V3 ...
You can solve this by setting the bootdelay of u-boot to -2 using the u-boot console:
Another solution is adding these lines of code to include/configs/rpi.h:
#define CONFIG_AUTOBOOT_PROMPT "\nRPi booting... Stop with ENTER\n"
#define CONFIG_AUTOBOOT_DELAY_STR "\r"
See also here.
Check if you have disabled the login prompt on /dev/serial0. What you see may be due to two processes (your script and getty) reading from the same port.
Login prompt on serial port can be disabled by running sudo raspi-config, navigating to "Advanced", "Serial" and answering "No" to the question about the login shell.
Alternatively, get a cheap USB-to-...