Using serial port on Raspberry Pi

Do I need any extra modules to send/receive strings down the Raspberry Pi serial pins, or is it all built into the OS?
I’ve seen mention of OS_SerialOp – does this do the job on the RPi?

Cheers,

Gerald.

PiSerial blockdrivers can be found here
http://www.tankstage.co.uk/Software/PiSerial.zip

Cheers Ronald – I’ll give it a go.

FYI as of today the development Pi ROMs should have working serial port support (OS_SerialOp + DeviceFS Serial1 interface). The Internal32 block driver (or similar) should work.

If people need to stick with PiSerial or other solutions then they should be able to *RMKill Serial to stop the OS’s driver from interfering with things

Is a PiSerial module aviable that works on a RPi2?

FYI as of today the development Pi ROMs should have working serial port support (OS_SerialOp + DeviceFS Serial1 interface). The Internal32 block driver (or similar) should work.

I have a socket with flying leads – how do I connect it, please, to use this facility? RPi2 B running 5.23 (10-Oct-16).

Could someone put a reference page up, please?

Following from Jeffery’s post above (10th October), I have finally got RISC OS onto my borrowed Pi3 (which has a Serial add-on card, plugging into the GPIO pins) and have knocked up the following programs:

REM>SerialReceive
PRINT"Waiting"
REM Set up the serial device
REM 8 bit word, 1 stop bit, no parity
SYS"OS_SerialOp",1,%000000
REM 9600 Baud rate
SYS"OS_SerialOp",5,0:REM RX
SYS"OS_SerialOp",6,0:REM TX
REM Read from the serial buffers
REPEAT
SYS"OS_SerialOp",4,0 TO ,c%
IF c%>31 AND c%<127 VDUc%
UNTILFALSE

and:

REM>SerialSend
REPEAT
INPUT"Text to send: “t$
REM Set up the serial device
REM 8 bit word, 1 stop bit, no parity
SYS”OS_SerialOp",1,%000000
REM 9600 Baud rate
SYS"OS_SerialOp",5,0:REM RX
SYS"OS_SerialOp",6,0:REM TX
REM Send the text to the serial buffers
FOR i%=1 TO LENt$
c%=ASCMID$(t$,i%,1)
SYS"OS_SerialOp",3,c%
NEXT
UNTILFALSE

but am unable to communicate with my Windoze 10 laptop using a USB to serial adapter and TeraTerm software. Am I missing something?
I’ve installed the October firmware update (low vector), and RISC OS 5.23 (5th December), and I’ve ensured that the serial modules are enabled.

Cheers,

Gerald.

Is the cable connected correctly? If it is, you should be able to measure several volts on each of pins 2 and 3 of the 9 pin D type connector, relative to pin 5. This is general advice for checking an EIA-232 connection, so it’s worth remembering.

If the cable is not correct, the chances are that only one of pins 2 and 3 will have significant voltage; this would indicate that you’ve got two transmitters trying to transmit to each other, and two receivers listening to each other – and that ain’t going to do anything useful. If it is like that, you could fix it by swapping pins 2 and 3 in the cable at one end.

Another thing to try: if you connect pins 2 and 3 together and run both your apps in task windows, you should be able to type to yourself.

Sorry, I forgot to mention that the serial cable is one I have previously used to get my work PC to talk to various bits of kit. However, I’ll stick a voltmeter on the pin and see if it shows anything. I was going to stick an oscilloscope on it.

Never thought of connecting pins 2 and 3 together…good idea – I’ll give it a go.

Sorry, I forgot to mention that the serial cable is one I have previously used to get my work PC to talk to various bits of kit.

While PC’s are DCE presentation and require a null modem cable (cross-over) to connect to another DCE device most of the dev board serial port presentations are DTE and therefore the connections are pin-to-pin.

Never thought of connecting pins 2 and 3 together

Normally you’d need to do some hardware handshake connections too but the Pi and various other dev boards don’t pass the handshake pins through and reply on software handshake.

One trick is to connect the output of your board to the serial input on a PC and run Putty at the right baud rate. All printable characters sent will appear in the putty console window.

This old thread suddenly seems relevant again…

I’ve just got a Raspberry Pi 3B+ (to replace my old BBxM that I accidentally killed). It’s very important for me to get serial comms working via a blockdriver (to programme an LPC1114), but the PiSerial module that I just downloaded from Tank’s site doesn’t work – when I try to load the module, it puts up an error message “PiSerial is not suitable for this machine”.

I wonder whether it’s just rejecting the machine on the grounds that it’s too recent for it to know about.

Anyway – all help gratefully received. It has to be a blockdriver, otherwise I have some hours ahead of me rewriting my programming app.

Since October 10th 2016, the Pi port has supported the standard serial interfaces (OS_SerialOp + DeviceFS Serial1 interface). So PiSerial should be redundant and you should be able to use the Internal32 block driver (or similar) instead.

to replace my old BBxM that I accidentally killed

Whoo, how’d you kill it? 5V on a 3V3 pin?

I wonder whether it’s just rejecting the machine on the grounds that it’s too recent for it to know about.

It’s not so much the machine as RISC OS.

Back when, it was possible to use an OS_Hardware call to the Comms/GPIO device, which would return some platform specific information (described here and documented here), however somewhere along the way this device giving the board type and revision was removed (so the wiki page probably ought to be removed as well?).
It was, largely, replaced by OS_ReadSysInfo 9,7 which will return a platform dependent string identifier which is about as good as it’s going to get given the powers that be don’t like things trying to poke around to work out what the hardware type is (see this thread).
So PiSerial as it stands will no longer recognise anything.

Just as well you don’t need it then. :-)

I have a Prolific Technology Inc. USB-to-UART serial controller used for a GPS tracking project.
After reading another old topic on these forums, I thoutht I would try and get it working on my Pi 2.

I downloaded the SerialUSB/zip file containing the serialUSB module and was pleasantly surprised when I got it working in double quick time. (and just three lines of BASIC will download each of the settings to my GPS trackers)

outfile%=OPENOUT("SerialUSB#baud=9600;noblock:")
BPUT#outfile%,"AT+GTRVC=gl300,1,1000,1000,1,0,,,FFFF$"
CLOSE#outfile%

This https://www.globaltelesat.co.uk/data-cable-m-for-queclink is the one I have, but I think it can be found with a standard 9 pin RS2323 plug on the end.

As I was bored, I decided to figure out what Tank’s code was doing.
Here is an annotated version of how it detects the Pi.

MOV   R0,#&0400        ; Device: Comms
ADD   R0, R0, #3       ;         GPIO
MOV   R1, #0           ; Initial enumeration
MOV   R8, #4           ; Enumerate
SWI   XOS_Hardware     ; (do it)
BVS   &00000368        ; Had a problem with the hardware
CMN   R1, #1           ; <-- BUG: should now BEQ to an error message!
LDR   R1, [R2,#68]     ; Load revision into R1
LDR   R0, [R2,#64]     ; Load board type into R0 (Pi = 0); BUG: doesn't check CPU type!
CMP   R0, #0           ; Is it a Pi?
BNE   &00000370        ; If not, "Not suitable for this machine"
CMP   R1, #6           ; Revision 6?
MOV   R2, #0           ; Serial port is at &20201000 on Pi
MOVEQ R2, #4           ; except revision six (Pi2) where it's at &3F201000
MOV   R0, #13          ; Map in I/O
ADR   R1, &00000678    ; Point to base address pair
LDR   R1, [R1, R2]     ; Load serial port address from base + is_it_rev_6_offset
SWI   XOS_Memory       ; Map it in

As I was really bored, I decided to see if I could come up with some alternative code that might work on newer OS builds (and newer models).

Note that this is not only completely untested, it’s also completely useless as said newer OS builds contain native serial code making PiSerial superfluous.
It’s an intellectual exercise.

MOV   R0, #9           ; Read platform info
MOV   R1, #7           ; Read device string
SYS   XOS_ReadSysInfo  ; Do it
BVS   &00000368        ; Problem if couldn't be read
LDRB  R1, [R0]         ; Read first byte
CMP   R1, #82          ; Is it an 'R'? [can only look at first byte, space constraint]
BNE   &00000370        ; If not "[R]aspberry" then not suitable
LDRB  R1, [R0, #14]    ; Pick up model number
CMP   R1, #57          ; Compare with '9'
MOVHI R1, #0           ; Translate 'A', 'B', 'B+', 'Zero' to type 0
SUB   R1, R1, #48      ; Convert ASCII to number
CMP   R1, #1           ; Compare with '1'
MOV   R2, #0           ; Use old base
MOVHI R2, #4           ; > 1? Use new base
MOV   R0, R0           ; NOP because new code is one instruction shorter
ADR   R1, #&0000678    ; Point to base address pair
LDR   R1, [R1, R2]     ; Load serial port address
SWI   XOS_Memory       ; Map it in

Jeffrey: thanks. My oscilloscope confirms that the transmit side works. Confirmation of the receive side will have to await the arrival of the level shifter board :-) But I’m sure it will work.

Whoo, how’d you kill it? 5V on a 3V3 pin?

My guess is ESD, but we will never know for sure. But it doesn’t owe me anything; it has served me excellently for some years now, since I got fed up with the increasingly drawn out faff of getting the Iyonix to start up. And the replacement is even cheaper and much faster!

I’ve already got one 3B+ running Open Media Vault, serving up a couple of spinning rust drives. That’s very successful too. Not to mention an earlier model running the central heating.

Edit: Oh, and another one running OpenVPN so I can safely access WebJames from the outside world.

The level shifter board arrived. Today I got the smouldering iron out and wired it up, along with a CJE RTCC. I can confirm operation of my LPC1114 app using the Internal32 driver.

Thank you, Jeffrey!