Serial not working

Using up to date firmware and ROM as at today’s date (18-Oct-2016, low vector) I have to unplug serial for the Pi to start up (otherwise it stops at the mod init done stage). This is with a GPS Hat on the Pi model A+ (256M). Remove the Hat and it starts up OK so the problem with Serial may not have been noticed if it works after start up but not during start up.

If I start up the Pi, wait for the desktop, then hot-plug the GPS hat it all works (using !SerialDev serial block drivers). If I reset (and do not allow !SeriaDev to be seen this time) then as soon as I RMReInit Serial (after f12) it immediately hangs.

Does Serial actually work please or is it still being put together?

Does Serial actually work please or is it still being put together?

It should work, at least for my test case of communicating between an Iyonix and a Pi.

What does the GPS Hat do – does it constantly try and send data over the serial port, or only on request? What baud rate, word length, flow control, etc. does it use?

Wow! Swift reply, many thanks. It continually sends data at 9600 baud with no handshaking. 8bit 1 stop bit no parity. I have put together the 18-Oct-2016 low vector build (with CMOS specifying UNPLUG Serial) that I am using here in case there is some odd config.txt issue.

A bit more testing with just pins 1 (3.3V), 4 (5V), 6 (GND) and 10 (RXD) connected between Pi and the GPS Hat:
freezes at ‘mod init done’ if Serial active (i.e. with characters continually being sent to Pi at 9600baud).

Unplug Serial and it starts up OK.

RmReInit Serial and it hangs immediately.

Disconnect RXD, power off, on and it starts up OK

Set up the Serial port using:

SYS "OS_SerialOp",5,7,0:REM Baud rate to 9600
SYS "OS_SerialOp",1,0:REM Set 8bit, 1 stop bit, no parity
SYS "OS_SerialOp",0,&3E:REM Set no handshaking
SYS "OS_Byte",2,2:REM Enable serial input buffer/kbd input

and then reconnect RXD and the serial port works.

Except that the following code:

a$=""
REPEAT
  SYS "OS_SerialOp",4 TO ,r1% ;r2%
  IF (r2% AND (1<<29))=0 THEN
    REM Char in buffer (C clear)
    a$+=CHR$(r1%)
  ENDIF  
  IF r1%=10 OR r1%=13 THEN PRINT a$:a$=""
UNTIL 0

returns lots of valid characters and lots of CHR$(0) in between (in all cases carry clear → character removed from buffer)
which were never sent so you get a ‘String too long’ error (but confusingly as CHR$(0) does not print the problem was elusive).

Can you set up the serial port baud rate etc. whilst the Serial module is unplugged – i.e. through SerialDeviceSupport? If so then that presents a work around: have Serial unplugged, start up, set serial port baud rate, handshaking etc. and only then RmReinit Serial.

It was a nice thought – yes you can set up baud rate etc. (with Serial unplugged) and then RMReInit Serial but it then hangs the machine immediately. Something seriously wrong with the Serial module in ROM.

The processor flags are returned in bits 3-0 (NZCV), so you need to check bit 1.

Can’t help with the serial questions unfortunately, it’s been ages since I played with that.

Looks like I neglected to test line status error interrupt handling, so it stiffs the machine as soon as a corrupt character is received. Shouldn’t be too hard to fix (it all works fine in polling mode!)

The processor flags are returned in bits 3-0 (NZCV), so you need to check bit 1.

Curses! I looked up which bit of the PSR was carry and it said 29! Didn’t cross-check with the BASIC manual. Many thanks – I fudged it by ignoring zero characters and it worked (but until the stiffing is sorted out wouldn’t be much use).

Shouldn’t be too hard to fix

Excellent!

Shouldn’t be too hard to fix (it all works fine in polling mode!)

It would be extremely helpful if it were fixed as I have to unplug the RXDATA (pin 10) line every time I start up my Raspberry Pi. I have tried *CON. Data 5 (to set the serial to no parity) to hope that *RMReInit Serial won’t stiff the machine with it connected but to no avail. So I have to *RMReInit Serial, then set the serial port to 9600 baud before reconnecting RXDATA (and then remember to *Unplug Serial before I shut down if I don’t want to unplug the RXDATA line before starting up again).

It would be extremely helpful if it were fixed as I have to unplug the RXDATA (pin 10) line every time I start up my Raspberry Pi

Give the guy some time to breathe as well – are we nearly there yet? are we nearly there yet? are we nearly there yet? are we nearly there yet? are we nearly there yet? are we nearly there yet? are we nearly there yet?

I’ll admit that impatience is one of my faults!

Do you have a “box of bits”? Got a dinky little switch in there? If so, write that in to make life easier until the firmware is fixed.

I did manage to fix the immediate hang, but there’s also a problem where the “RX FIFO non-empty” IRQ sometimes remains on when the FIFO is empty. If you keep spamming data at the port it does seem to recover, but if you stop at the right time then it will get stuck there forever. Hopefully once that’s fixed there won’t be anything else stopping me from submitting the fixes.

Do you have a “box of bits”? Got a dinky little switch in there? I

Irritatingly the GPS Hat simply stacks on the 40 pin header. The case is designed that way as well. My current fix is to use the PiSerial drivers and leave SerialDeviceSupport and Serial unplugged. Then every time I test Serial I must remember to unplug Serial before turning off otherwise I have to separate the Hat and the Pi or take out the SD card. Or use flying leads (but not use the case).

I did manage to fix the immediate hang, but there’s also a problem where the “RX FIFO non-empty” IRQ sometimes remains on when the FIFO is empty.

Many thanks. I did look at the sources to see if the error problem was easy to overcome but I realised it would take me rather a long time to work out a kludge to ignore errors. (I am building my own rom to get low vectors anyway.)

Have try with B+ and Pi2. Both are booting now with a pluged GPS Hat … PIN 1, 6, 10 via the Pi-Top Hub (PIN 4,5,11).
It looks like the first start with a fresh ROM failed but after activate GPS and restart (also power off/on) with a plugged… no problems today. I mean it takes a bit longer, but not sure.
Pi2 will not work with GPS. No idea what the reason is. Looks comparable with my B+. B+ is working, RPi2 not.
I use a ROM I build 2016-10-13.

Hopefully once that’s fixed there won’t be anything else stopping me from submitting the fixes.

Many, many thanks. The new Serial module works with my GPS Hat (which spams at 9600 baud continually) on the Pi A+, model 1, 2, 3 and Zero. Excellent! The SatNav application now contains instructions on how to update a Pi to the latest ROM (26-Oct-2016) – see the archives High-vector and Low-vector.

Cool – glad to hear that the fix is working.

Going back – to serial on the A310 Arc.

Someone said they didn’t like the Acorn machines because there was no info on where the rs232 regs were in the memory map.

Peek/poking ports – was I believe all the rage in Pc’s – to get speed.
Also handy for reading and setting the control lines.
(for – external projects)
(Just for interest – was it possible to find the rs232 reg’s on a A310)

Is there any info on how HostFS works with the podule space and what is required on the Win side?
(ie – something to pass through – swi serial calls)

I looked up which bit of the PSR was carry and it said 29!

Correct for the ARM, only BASIC shifts the flags down to make things simpler. ;-)

Going back – to serial on the A310 Arc.
Someone said they didn’t like the Acorn machines because there was no info on where the rs232 regs were in the memory map.

Did they never crack open a copy of Acorn User? I’m sure somebody (Mike Cook?) did an article on bashing the serial port a little harder. It’s a bog-standard 6551 mapped in at &033B0000.

Peek/poking ports – was I believe all the rage in Pc’s – to get speed.

That’s because the BIOS sucked, and a 66MHz 486 DX/2 actually managed to flake out at speeds over 9600bps.

That said, peeking/poking ports isn’t at all unusual. It is exactly how memory mapped hardware works. The difference being that such things are usually hidden from you.

Also handy for reading and setting the control lines.
(for – external projects)

Indeed. I have built a printer port IIC interface by bit-banging the control lines. Works on RISC OS, DOS, and Win32 (needs the GIVEIO hack for XP).

(Just for interest – was it possible to find the rs232 reg’s on a A310)

Uh-hu.
Anybody who wanted to do serious low-level stuff with the machines probably should have invested in the “PRM”. Pricey, but four very detailed volumes running to something like 2000 pages of documentation on many aspects of RISC OS.
The old style 6551 serial port is at &033B0000, and the newer style is part of the 82C710 chip at &03010000. That’s on page 1-145 in my PDF copy.
Obstensibly that might be all you’d need – but on the other hand the serial hardware will probably generate interrupts, so you’d need to know how to deal with these. Or just cheat and use the Serial Blockdrivers like everybody else (which, in turn, use the OS_SerialOp SWI and lets RISC OS handle the hardware).

(ie – something to pass through – swi serial calls)

I doubt that is anything to do with HostFS. The emulator you are using will need to respond to attempts to address the serial hardware, and translate that into the appropriate calls for the platform in question.

Or just cheat and use the Serial Blockdrivers like everybody else (which, in turn, use the OS_SerialOp SWI and lets RISC OS handle the hardware).

IIRC, Blockdrivers did hit the 16450/8250 compatible chip inside the A5000/A4000/A3010/A3020/A4 machines directly because RISC OS only supported 19200 baud, and the Blockdrivers aimed to support up to 57600 baud.

There is a very subtle bug in the serial module that was shown up by SatNav. What I think is happening is that the Serial_Op call returns carry clear even though there is no character waiting and SatNav therefore gets stuck in an infinite loop (due to an otherwise harmless typo). The code is:

 1050  REM Try to obtain (only) up to twenty characters in each poll
 1060  if%=0
 1070  REPEAT
 1080    SYS "OS_SerialOp",4,-1 TO ,r1% ;r2%
 1090    if%+=1
 1100    IF (r2% AND 2)=0 THEN
 1110      REM Character in buffer (C clear)
 1120      IF r1%<>-1 AND r1%<>0 THEN 
              REM add character CHR$(r1%) to string
           ENDIF
 1580    ENDIF
 1590  UNTIL (r2% AND 2) OR i%>20:REM Buffer empty or 20 attempts

Basically it says after a few hours that there is always a character in the buffer, returns (so far as I can tell) either -1 (preserved) or 0, and because the UNTIL statement has the wrong variable (i% instead of if%) isn’t terminated after up to 20 attempts to extract a character. Twenty attempts every Wimp_Poll is plenty for a serial buffer size of 110 or so bytes that is being filled at 9600 baud (i.e. at a maximum rate of about 10 characters per centisecond) with only up to 400 characters each second (mostly only 150 characters every second depending how many messages are being sent). Twenty characters per centisecond is 2000 characters per second after all. I have corrected the UNTIL statement now so that if the bug appears it is worked around. Note the -1 parameter in R1 is simply to flag (separately from the carry flag) that no character is available as R1 is preserved if no character is fetched.

Any ideas please? I am using a 26 October 2016 low vector rom from Update5L.

NB I have to check for unwanted null bytes as the checksum is fairly primitive and would not pick them up but they would cause problems when decoding the string.

UNTIL (r2% AND 2) OR i%>20:REM Buffer empty or 20 attempts

There’s another potential worry with that, in that BASIC doesn’t do logical AND and OR. I don’t think it’s an issue here, but I’d be more comfortable with

UNTIL ((r2% AND 2) <> 0) OR (if% > 20) :REM Buffer empty or 20 attempts

just to make sure that the OR works as expected in all situations (especially if you later change the second half of the expression to something similar which doesn’t guarantee that bit 2 is set).

Twenty attempts every Wimp_Poll is plenty for a serial buffer size of 110 or so bytes that is being filled at 9600 baud (i.e. at a maximum rate of about 10 characters per centisecond) with only up to 400 characters each second (mostly only 150 characters every second depending how many messages are being sent). Twenty characters per centisecond is 2000 characters per second after all.

Um. What happens if the Wimp stops polling the app for a second or so whilst something else is hourglassing? Is it really a performance hit to empty whatever is in the buffer each time, to minimise the risk of byte loss?

In 5 or 6 Wimp_Polls it would empty the buffer (the serial buffer is only 110 or so bytes so anything over this is just dumped as there is no handshaking) so it’s not a problem.

In the good old days, we all used the SerialBuffer by David Pilling, usually with 16KiB input buffer, which stopped the worrying about losing valuable data. Maybe time to revive this tradition?

In this particular case the data are not valuable as any missed messages are out of date. There’s no handshaking (but there is a primitive checksum) and a large buffer would be very unhelpful.

but there’s also a problem where the “RX FIFO non-empty” IRQ sometimes remains on when the FIFO is empty. If you keep spamming data at the port it does seem to recover, but if you stop at the right time then it will get stuck there forever.

Even with data being spammed at the port for several hours, on very infrequent occasions (like a few times a day) the Serial_Op call returns with carry clear (character in buffer) but can’t extract it (as there’s nothing there) so you get stuck in a loop waiting for the carry to get set. Work around is to try a few times then wait for the next Wimp_Poll before trying again – that seems to get back to normal by then but repeatedly trying doesn’t work.

Ticket #430 raised in the bug tracker.

In the good old days, we all used the SerialBuffer by David Pilling, usually with 16KiB input buffer, which stopped the worrying about losing valuable data. Maybe time to revive this tradition?

Just had a look at the module source, what it does is tell DeviceFS to use a larger buffer. Simple and effective. ;-)

It is part of the “Tools” of the Hearsay source code archive → http://www.davidpilling.com/wiki/index.php/Hearsay