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 ...
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.
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 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.
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 ...
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 ...
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, ...
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 ) == -...
The config looks OK, and both ends should support 115.2k and the RS232/USB cable certainly will.
Have you tried putting a 'scope on the Tx/Rx lines just to be sure that the data is getting out? This could help narrow down the problem.
Another possible check is that, depending on the version of the MAX232 and the capacitors around the device, you may be ...
The voltage levels are not a problem, a LVTTL logical '1' will also be a TTL logical '1'. The only issue can be the (sinking) current, as Alex Chamberlain already suggested. This can be a problem.
This sinking current depends on the input circuit of the printer, as we can only guess how it is constructed, it might be better to be safe then sorry!
So to ...
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 ...
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 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 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.
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.
The Problem in this setup is the "Prolific" USB-to-Serial Interface. I managed to get everything to work with a borrowed Notebook with native serialport. I further investigated with a tool from Prolific to check chip version. It stated that it's a PL2303HXA. On their website it states:
Please be warned that counterfeit (fake) PL-2303HX (Chip Rev A) USB to ...
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