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.
According to Farnell's Quick Start Guide, the default baud rate is: 115200. A fairly detailed discussion of the UART settings and capabilities can be found in this blog post More on Raspberry Pi serial ports. More specific implementation details/challenges of working with the serial port can be found in the blog post Getting my Raspberry Pi set up for high-...
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.
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).
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 ...
@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 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 ...
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.
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 ...
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 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 ...
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.
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 ...
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.
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 ...
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 ...
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 ...
The three options are:
UART0/ttyAMA0 to Bluetooth
Mini-UART/dev/ttyS0 to GPIOs 14 and 15
no Bluetooth support
UART0/ttyAMA0 to GPIOs 14 and 15
Mini-UART/ttyS0 connected to Bluetooth
UART0/ttyAMA0 to GPIOs 14 and 15
In general, the Mini-UART has one big pitfall. It doesn't have its own clock source, ...
if you delete this part ("console=ttyAMA0,115200 kgdboc=ttyAMA0,115200"), the UART is free (not really see note ...), you can use it for other task like connect a sensor for example, if you keep this parameter you can read the kernel bootlog of your OS linux on the serial port (UART).
if your port is wrong (erroneous character) it will be ignored by the ...
This thread has a solution for an arbitrary (non-standard) baud rate: https://stackoverflow.com/questions/12646324/how-to-set-a-custom-baud-rate-on-linux/21960358
Doing POSIX manipulations first, then this to set the custom speed, works fine on the built-in UART of the Raspberry Pi to get a 250k baud rate. So as well as the POSIX standard rates, you can ...
USB to UART bridges are cheap and readily available, but have really lousy timing characteristics. Newark sells an "Embedded Pi" board which has an STM32F ARM processor that you can write bare-metal code on. That chip has three UARTs on it, and I think they can go pretty fast; if you were to use one to communicate with the Raspberry Pi that would leave two ...