In this tutorial we will see how to use the serial port on Raspberry Pi. We will use the serial port available on Raspberry with a RS232/TTL 3-5,5V adapter and a USB-serial adapter. By default the Raspberry Pi’s serial port is configured to be used for console input/output. This can help to fix problems during boot, or to log in to the Pi if the video and network are not available.
Python code to read the serial port. While 1: Register with the combination Ctrl + X then Y by giving a name to the file (for example read_serial.py). Now, launch the program to read messages sent on the serial port from your device (for example an Arduino). Reading the messages of a Gateway MySensors on the serial port of a Raspberry Pi.
To be able to use the serial port to connect and talk to other devices (e.g. a modem a printer.. ), the serial port console login needs to be disabled.
Here we use Raspberry Pi 2, and we connect a RS232/TTL 3-5,5V adapter to pins 4 (5V), 6 (GND) ,8 (TX),10 (RX) of Raspberry, obviously connect tx with rx and vice versa.
To search for available serial ports we use the command
The output is something like this
Python Serial Read Time Out Examples
Last line indicates that the console is enabled on the serial port ttyAMA0, so we disable it
Python Read Timeout
Run the configuration command and follow the instructions below
Reboot and try with
output now is
Now we can use the serial ttyAMA0. We connect an adapter usb / serial, then we will try to establish a communication between the two serial ports; obviously in a practical application to every serial we could connect a device, for example a modem, a printer a RFID reader etc.
After connecting the second serial port we launch the command to find the name that Raspberry gives him
The output is something like this
Ok, now we create two files, one who writes something on the ttyAMA0 port and the other that reads on the ttyUSB0 port.
serial_write.py
serial_read.py
If we run both files, serial_read.py will read what serial_write.py writes
This is just a small example but it can serve as a starting point to send a print to an old printer or read data from a router or a gps.
Follow us on social to stay informed.
http://www.emmeshop.eu
I think we have very different views on what is 'sane' :-)
I think a sane function all either a) does what it's expected to do, b) raises an exception, c) provides another way for the caller to understand what has happened. Returning from a function without a way for the caller to know whether it has succeeded... it's a bad design.
If I always need to check the terminator is there... what's the purpose of read_until() ? I can just read one byte each time and append it to a buffer, until I get the terminator, I get the same complexity.
Also, as you will know, when UNIX socket programming, if I get a timeout, an error is set, EAGAIN or EWOULDBLOCK. This is quite a standard way, so the difference in your library is surprising, probably to most programmers having worked with other implementations.
More than that: I would expect that read_until() could actually return without the terminator, in one crucial case: when the other side closed the connection. In THAT situation, I could need to accept the fact and handle it by myself (but if it were me, I'd probably raise an exception, maybe a specific one). But your library leaves me with no choice, since I can't understand whether it's the timeout that has expired, or the other side has closed the connection.
An alternative which doesn't raise an exception would be to provide a 'success' flag, e.g. return a tuple from your function, something like (status, bytes) ; the first value could be something like 'success' (e.g. read until terminator), 'timeout_expired', 'file_closed', the other the actual bytes.
For your other concern:
This looks an implementation issue to me, not an interface design matter. if I understood it properly. read_until() should buffer read bytes and make them available to further read() or read_until() calls; nothing mandates that once you exit the function, such bytes should be lost.