Serial Port on Pi (and other platforms)

At present I have an application (SatNav) designed for the Raspberry Pi which uses the serial port to communicate with a ‘top hat’ with a GPS receiver. This receiver is capable of being attached to any RISC OS platform with a serial port. How do I make my application work seamlessly on newer Pi ROMS (which have serial in ROM) as well as older Pi ROMS (which require the serial block drivers) and on other platforms (e.g. ARMX6 and Titanium)?

At present I use the following code:

serial%=TRUE
LOCAL ERROR
ON ERROR LOCAL serial%=FALSE
IF serial% THEN OSCLI("RMEnsure PISerial 0.00 Error 6,This app requires the PiSerial drivers")
RESTORE ERROR

during initialisation then

IF serial% THEN
  SYS "PiSerial_Speed",,9600
  SYS "PiSerial_Format",,&0:REM 8bit 1 stop No parity
ENDIF

to initialise then

IF serial% THEN SYS "PiSerial_RX",,binf%,200 TO ,r1%,r2%

to read bytes as required. Note that the application can still be used with no serial connection as it can simulate reading of GPS data.

Suggestions welcome.

You can “*RMEnsure SerialDeviceSupport” as a way of checking if serial support is present in the ROM. This will work with all machines (I believe the module’s been around since the Archimedes), but was missing from the Pi ROM until the serial support was finished.

I’m not quite sure what the state of the serial block drivers are – the Iyonix-era Internal32 block driver will kind of work on modern machines (it’s what I was mainly using for testing the Pi serial), but I know that someone (Willi Theiss?) was also working on a new/updated driver that would cope with all the serial ports exposed by the HAL (the Iyonix is a bit funny, I believe both serial ports use the same style of chip, but one of the drivers is provided by SerialDeviceDriver (→ OS_SerialOp), and the other is provided by the HAL (→ DualSerial → DeviceFS IOCtl interface), so Internal32 actually uses two different APIs internally depending on which port number you specify).

For ARMX6 and Titanium SerialDeviceDriver isn’t used at all, everything goes through DualSerial (the same as everything else post-Iyonix). But they will be using a new enough version of DualSerial for the SerialDeviceDriver API to be implemented, so OS_SerialOp will still be available (with the obvious caveat that OS_SerialOp only supports one port). So you have the choice of implementing support for OS_SerialOp (compatibility with every RISC OS machine with working serial drivers, with the limitation of no choice over which port is used), or you can use DualSerial-compatible block drivers (or the IOCtl interface directly), which should get you compatibility with all RISC OS 5 machines and choice over which port is used (and theoretically it will give you some compatibility with a few other machines, since DualSerial was a Phoebe-era thing I believe).

Many thanks for the reply, it’ll be towards the end of next week before I’ll have time to try to understand what to do! :) The GPS device I’m using needs a level shifter to connect to an RS232 port as it’s designed to sit on a Pi. Also the serial block drivers (the only option on a Pi with an early ROM) don’t work on either or both of Pi model 2 and 3.

I’ve got a u blox GPS module here. I’ve tested it with an NMEA library demo on Arduino and it is working. I have a Pi 3 and a Pi Zero. If you want a basic test of whether your program works on these platforms with that GPS module I may be able to help. I can’t take the Pi for a walk though.

Many thanks.

The simplest test is to see whether RISC OS can read the data from the Pi’s serial port and, if so, whether the serial block drivers work or whether you need a ROM after 10 Oct 2016 (which has serial support in rom). But (once I get the time) I can test as I have a Pi Zero and Pi 2 and Pi 3. Just not got round to it yet, I am using a model A+.

You can ‘*RMEnsure SerialDeviceSupport 0.00’ as a way of checking if serial support is present in the ROM. This will work with all machines

I now use RMEnsure SerialDeviceSupport (to see whether OS_SerialOp is supported). If so I’ll use that (with the limitation that it uses a particular port, which I assume is always the 40-pin header pins 8/10 on the Pi).

If not then ‘*RMEnsure PiSerial 0.00’ and use PiSerial block drivers (which don’t work on certain models of Pi, not sure which but model 0, model 2 and model 3 probably). So they would need roms after 10 Oct 2016 (Pi roms after 10 Oct 2016 have serial support in rom) – only downside is that recent roms kill Aemulor (due to memory management changes) but on the Pi where Aemulor is a paid-for item that will no doubt get fixed quickly if anyone complains. Incidentally that explains why there have been no official rom upgrades since June 2016 on IGEPv5, Titanium and ARMX6, as users would not tolerate Aemulor not working.

If no data are received then it plays back a GPS simulation. Version 0.61 now under test…

Many thanks.