Raspberry Pi Zero serial port module not working?

I’m trying to get a GPS module talking to a Raspberry Pi Zero with the RC15 ROM image from last April installed. Well, I think it is talking, but the Pi Zero isn’t listening. I suspect this because:

The GPS module will talk to the Pi Zero if I reboot from a memory card with raspbian+GPSD on it. This is also without moving the serial lead at all, i.e. same pins must be connected the same way.

The GPS module will talk to a Pi B with the RC14 ROM using the PiSerial module.

All I get is Zeroes from OS_SerialOP 4.

I used the code below, shamelessly nicked from Gerald Holdsworth in a different but similar thread on this forum. I think it ought to work with the the Serial module included in the RC15 ROM (“*help serial” says it’s version 0.25 dated October 2016), and the syntax looks OK from what I’ve read in the PRM.

Have we missed something that needs to be done before this will work?

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

It’s probably not supported, but it should be very soon.
See there: https://www.riscosopen.org/content/downloads/stable-release-status

Have you tried initialising the port with

SYS "OS_SerialOp", 0, 2, NOT 2

The default serial port on risc os is set to be DCD sensitive. The above sets it to ignore DCD.

I tested your apps, send worked but I couldn’t get receive to work.

This does work

error% = FALSE
file% = 0
ON ERROR error% = TRUE
IF error% THEN
    ON ERROR OFF
    IF file% <> 0 SYS "OS_Find", 0, file%
    file% = 0
    PRINT REPORT$;" (";ERL;")"
    END
ENDIF
bufsize% = 32
DIM buf% bufsize%
PRINT"Waiting - press escape to quit"
SYS "OS_Find", &4f, "Serial1#noblock;nohandshake;baud=9600;data=8;stop=1;noparity:" TO file%
IF file% = 0 ERROR 1, "Can't open serial port"
REPEAT 
    SYS "OS_GBPB", 4, file%, buf%, bufsize%, 0 TO ,,, unused%
    i% = 0
    WHILE i% < (bufsize% - unused%)
        c% = buf%?i%: i%+=1
        IF c% = 13 c% = 10
        IF (c% > 31 AND c% <127) OR c% = 10 VDU c%
    ENDWHILE
UNTIL FALSE

Note if run in a taskwindow you need to press escape to quit otherwise you will leave the file open – one of the drawbacks of using BASIC. If you used C atexit() can be used to close the file when the window is closed.

I use the following:

REM Read from serial
   10REPEAT
   20  SYS "OS_SerialOp",4,-1 TO ,r1% ;r2%
   30  if%+=1
   40  IF (r2% AND 2)=0 THEN
   50    REM Character r1% in buffer (C clear) but ignore nulls
   60  ENDIF
   61UNTIL (r2% AND 2) OR if%>100:REM Buffer empty or 100 attempts
REM Initialise
 2730    *FX 21,1
 2740    SYS "OS_SerialOp",5,3,0:REM Baud rate to slow
 2750    SYS "OS_SerialOp",1,0:REM Set 8bit, 1 stop bit, no parity
 2760    SYS "OS_SerialOp",0,&3E:REM Set no handshaking
 2770    SYS "OS_Byte",2,2:REM Enable serial input buffer/kbd input
 2780    *FX 21,1
 2790    SYS "OS_SerialOp",5,7,0:REM Baud rate to 9600

Colin: ta for that. I’m going to have to study the PRM a bit to figure out what that argument in R1 for the OS_Find call does, plus I had to increase bufsize% to stop the stream getting garbled. It’s now producing legible NMEA sentences at least.

Next stage: work out how to flush the input buffer.

You can go back to using SerialOp if you find it easier you were just missing

SYS "OS_SerialOp",0,&3E
SYS "OS_Byte",2,2
*fx21,1

to disable handshaking, enable serial input *FX21,1 to flush the buffer as Chris pointed out.

I use the file method as it will work with ports which are not the default port and SerialUSB

If you just want to send some text from your pi – maybe to test output – you can

echo hello { > serial1#nohandshake;baud=9600: }

or

type <filename> { > serial1#nohandshake;baud=9600: }

at the command line.

Note the size of the file can’t be too big and serial1 changes depending on the port for example if you have a usb adapter you’d use:

echo hello { > serialusb#nohandshake;baud=9600: }

Colin wrote:

“You can go back to using SerialOp if you find it easier you were just missing

SYS “OS_SerialOp”,0,&3E
SYS “OS_Byte”,2,2
*fx21,1
to disable handshaking, enable serial input *FX21,1 to flush the buffer as Chris pointed out."

Thanks, that does indeed work. A couple of minor puzzlements about the “OS_SerialOp”,0 call remain in my head though. That’s supposed to give set the new state to (old_state AND R2) EOR R1, so what value will be assumed for R2 if none is supplied? I’m guessing &FFFFFFFF as that will preserve the state of all bits, but, if I add To ,oldstate%,newstate% then PRINT ~oldstate%,~newstate%, when the program is run for the first time after a reboot, bits 16-31 are unchanged and bits 0-15 have changed from &0100 to &003E. I’d expect the result to be &013E, so how & why did bit 8 get changed?

BASIC SYS call puts 0 in any missing registers up to r9 – if I remember correctly. So SYS "OS_SerialOp", 0, &3e is the same as SYS "OS_SerialOp", 0, &3e, 0. I’d put the ,0 in explicitly rather than rely on BASIC.

newvalue = (old_value AND r2) EOR r1

so Chris has set the value to &3e

Colin:
“BASIC SYS call puts 0 in any missing registers up to r9 – if I remember correctly. So SYS “OS_SerialOp”, 0, &3e is the same as SYS “OS_SerialOp”, 0, &3e, 0. I’d put the ,0 in explicitly rather than rely on BASIC.

newvalue = (old_value AND r2) EOR r1

so Chris has set the value to &3e"

OK, I think I’m closer to understanding this. (old_value AND R2) will clear all the bits, since (anything AND 0) =0, then (0 EOR &3E)=&3E, so I have to conclude that bits 16-31 are not affected by this call, is that right? PRM seems to say otherwise.

Yes you have highlighted a problem. Reading the PRM it should be

SYS "OS_SerialOp", 0, &3E, &fffffe00

You can’t modify bits 16-23 as they are Read Only, so the mask doesn’t matter for them, but bits 9-15 and bits 24-31 are reserved for future expansion and the PRM’s say you shouldn’t modify them but you can’t know in advance that a future change won’t need clearing/setting.

Although PRM2 states that bits 8-15 are Read Only the change in PRM5a makes bit 8 Read/Write so I think we can expect that reserved bits can be Read/Write.

You can only hope that any changes will not break your program if you use the swi as outlined above.

Oh good, I’m not going mad or particularly stupid then ;) I’ll make a not of that somewhere, and also include it in a stack of REMs in the listing so I’ll remember it when it inevitably does break ;)

Thank you all for your help, this has been a productive thread, for me at least.