OS_SerialOp working on XM yet?

I’m experimenting with a device that sends its current co-ordinates as a stream of ascii chars via a serial output. As every RISC OS machine sports a serial port I thought it would be a fun device to play with and easy to code for.

However, I’ve drawn a blank with the XM. Initially I’m just trying to throw the input stream on the screen so I can relate its output to whatever position the device is in.

This works fine on an RPC, but produces nothing on screen for the XM:

=======

REM Echo serial input stream to screen
ON ERROR PRINT’ REPORT$" at line ";ERL: QUIT
PRINT’’’’
SYS “OS_SerialOp”,1,0: REM 8N1
SYS “OS_SerialOp”,5,7: REM 9600 baud
SYS “OS_Byte”,2,2: REM Set input stream to keyboard + serial port
SYS “OS_Byte”,21,1: REM Clear serial buffer
REPEAT
SYS “OS_SerialOp”,4 TO ,byte%
IF byte%>0 PRINT CHR$(byte%);
UNTIL FALSE
END
=======

What would the equivalent code be for the above to work on XM?

Thanks,
-Neil.

Should have added I’m running 5.18. I wonder if 5.19 has any added serial bits?

I’ve been reading up a bit more around use of the serial blockdrivers and the present state of serial support in the Beagleboard rom.

Am I right in thinking that whatever combination of blockdriver (e.g. Internal32) or Serial_Op SWIs are used, there is currently no way to do even a simple RX/TX via the standard DB9 socket on the board – so no existing serial peripherals will work on BB or XM/ARMini?

Notwithstanding the much appreciated effort that our small band of Risc OS experts are putting in, and the understandable attractiveness of working on code for sexy new hardware like R-pi etc, shouldn’t we be ensuring at least basic functionality first for existing hardware on which Risc OS is already supposed to be running? Or are Beagleboard and ARMini fast becoming ‘legacy’ hardware and unlikely to see much further work?

I ask because I have two interesting new apps I’m working on whose main advantage was going to be plug-and-play functionality right across the Risc OS range. Sadly, they’re stalled on XM/ARMini hardware at the moment.

Neil, I don’t think a working serial port could be described as “basic functionality” nowadays. We have so few resources to develop RISC OS further that it might not be sensible to invest in specific hardware support – a generic USB-Serial driver for a few common chipsets would be a lot more valuable.

At the moment, only few people work an R-Pi, and nearly all things developed help all RISC OS 5 platforms, be they emulated or physical hardware. And to be honest, R-Pi presents such a fantastic opportunity for RISC OS that is infinitely more valuable than a working serial port for the BeagleBoard.

My personal opinion is that, now that the Pandaboard is available, it does not make much sense to develop Beagleboard specific stuff further – the Pandaboard is so much better. And if we get a new low-cost board with OMAP5/Cortex-A15, it should be the next thing to develop.

At the end of the day, it boils down to the usual RISC OS way: if you want to get it done, do it yourself.

Although OS_SerialOp and the block drivers aren’t working yet, you will be able to make use of the serial port if you use the DeviceFS interface. Devices:$.Serial3 is the device you want. Sometime this weekend I should be able to get OS_SerialOp working – it looks like all that’s needed is for the DualSerial module to respond to the Service_SerialDevice service call that SerialDeviceSupport issues.

The number of beagleboard-centric things on my todo list is decreasing, but that’s a sign that the hardware support is reaching maturity, not that the platform is being abandoned. Although I can’t guarantee I’ll get everything done, there are still at least a couple of big things left on my list (e.g. GraphicsV overhaul) which I know I’ll be doing before I put beagleboard/OMAP3 development behind me.

Thanks Jeffrey. Much appreciated.

I’ve just been playing with Terry Swanborough’s OS_Hardware approach that he detailed in his 2011 thread, but it requires such a good understanding of the Beagleboard/rom innards, it’s easy to get lost in the sewers.

I’ll wait for your official version and then do things the conventional way.

I dont have my serial cable connected at the moment, but on the Iyonix you can stream a file to Devices#sleep;baud=115200;data=8;stop=2;noparity;nohandshaking:$.Serial1
It looks like *Pipecopy file Devices#slee…. is waiting for a taker so that
might work with Serial3? I dont have a BB but something like this would
show that the Devices# method is working.
I think the pdf for the XM shows the serial port as requiring a straight through cable for connecting to another device rather than the usual crossover cable.

Hi Jeffrey. Good news and bad news. I’ve tried your suggestion of using the DevicesFS with serial3 and can now talk to the DB9 port – cheers for that.

I seem to have hit another snag though: if a ‘live’ data cable is left plugged in at startup, the board hangs and doesn’t reach the system beep. Users of serial devices would normally expect them to be left connected, so having to unplug prior to every switch on or restart would be a show stopper. Is there a way to prevent BB/xm checking or waiting for the port at startup, at least for the DB9 connector?

-Neil.

If you hook up a serial terminal to the XM you will see a start up message that says ‘press any key to ..’ which allows the start up to be halted for user input (rather than do a standard start up). So all it is doing is that and this is not what you want!

I’ve been caught many times by this problem while I was working on the SD/MMC software. I think there should be a way to stop it.

Possibly use the CTS line and force it for four seconds after a reset? That way any serial characters will be held in a queue until the XM has started up?

You could try using the latest uboot and use the preenv.txt file to set the bootdelay to zero. This disables the ‘press any key to ..’. You can download it here.

Chris, there’s no CTS line on the DB9 connector. Just RX and TX.

Pin 8 of DB9 is CTS.

Pin 8 of DB9 is CTS.

Not on the XM, Chris. Only the RX, TX and GND lines are connected on the DB9 – there are no control lines present.

Another oddity of the XM is that the RX and TX lines appear to be swapped compared with a standard cable – so you can’t use a standard A5000/RPC/Iyonix cable and a straight-through gender changer. You have to source an obscure and pricey null-modem gender changer to get things working.

Edit to add:
A quick look through the Beagleboard TRM suggests there’s no CTS or other control lines present there either (RS232 on header P9).

The crossover is done for you ‘in’ the XM so you need a straight through cable such as what was used for serial internet modems and some serial printers/plotters. If you have to use a 25 pin to 9 pin adapter that introduces another possible crossover, though I never encountered a problem there.
Normally you would use a crossover cable, some were known as X-link cables, to go from computer to computer.
HTH
I have just checked, and an external modem has the same gender as the XM so at the worst you would need a 25pin-9pin adapter if you dont have a 9pin-9pin dial up modem cable.

Not on the XM, Chris. Only the RX, TX and GND lines are connected on the DB9 – there are no control lines present.

My meaning is that you need to provide the CTS signal so that is active for four seconds after a reset so that there won’t be any received signals during this time. You can pick up the RESET line from the push button on the XM and make up a small circuit to hold it active on the outgoing pin 8 on the DB9 for 4 sec.

You can pick up the RESET line from the push button on the XM and make up a small circuit to hold it active on the outgoing pin 8 on the DB9 for 4 sec.

No, Chris, this is a software-induced problem and is best served by a software solution. And I speak as a hardware engineer.

The crossover is done for you ‘in’ the XM so you need a straight through cable such as what was used for serial internet modems and some serial printers/plotters. If you have to use a 25 pin to 9 pin adapter that introduces another possible crossover, though I never encountered a problem there.

It’s simpler than that, Ronald.

Say I have an item that sends out a serial data stream – it could be any one of thousands of bits of existing scientific apparatus, or a ham radio device, or a sat nav, or in this case a piece of robotics. It has a standard serial lead on it terminating in a 9-pin female d-sub, which is nice and convenient for the male connector on the RPC, Iyo, A5000, A4, what-have-you, etc.

But when I want to plug it into a Beagle-XM I’m presented with a 9-pin female socket instead. Female into female won’t go, so the obvious solution is to grab a mini 9-pin male-to-male straight-through gender changer and everything should be fine – but it isn’t.

Because the TX and RX pins are transposed on the XM compared with a ‘standard’ Risc OS socket, you need a null modem gender changer instead.

Uniquely in the ‘Risc OS’ range, the XM is set up as standard to suit computer-to-computer serial data transfers, not device-to-computer. I presume this was because the serial socket was included purely for debug and code loading purposes. Every other computer pairing in the Risc OS range requires a cross-over cable for computer-to-computer data exchanges, because their serial ports were intended to be used for device-data I/O, not file transfers.

It took me quite few days of fiddling around with gender changers and head scratching before the penny dropped. Just saying – in case anyone else finds their otherwise ‘standard’ serial device is mysteriously inoperative when connected to an XM.

“Because the TX and RX pins are transposed on the XM”
Thats the important bit to know about, I appreciate your need to use a crossover again when you’re only available connection is also crossed over, or if you did want a straight connection to a dial up modem you would have to do a crossover to cancel the xm’s crossover.
Now that that’s done, how did you get on with your comms to your device? It would be interesting to see an example of what you used.

I’m afraid I haven’t had a chance to get OS_SerialOp working yet. I was under the impression that SerialSupport (the module that implements OS_SerialOp) would be using the IOCtl interface to talk to the serial driver, but it turns out that it’s using a completely different set of DeviceFS calls instead. So I’m now in the process of adding support for those to DualSerial. Hopefully I’ll have it finished in the next day or two.

I did consider adding IOCtl support to SerialSupport (which would make it compatible with any other IOCtl based drivers), but that looks like it would have involved some major reworking since the IOCtl interface requires the streams/buffers to exist, whereas the existing interface doesn’t.

Thanks for the update, Jeffrey.

I presume going through DualSerial will allow bi-directional access to the DB9 port. It’s RX only at the moment – any attempt to OPENOUT a DeviceFS channel on port3 results in an error. I had some good results on the RPC adapting the bones of your blockdriver terminal prog, but it still comes up dead on the XM DB9 connector.

One good thing about all this trying to wriggle through every avenue in or out of the port is that it’s forced me to get into the detail of serial comms in a way I’ve never bothered to in the past.

Over the bank holiday weekend I managed to find the time to finish this off. So OS_SerialOp now works fine on the BB, and should be working on OMAP4 soon as well (as well as other platforms like the Pi). I’ve also added the SerialMouse module to the ROM, not that I doubt anyone will find a use for it!

Note that there’s a new OS_SerialOp call, OS_SerialOp 10, for determining the serial device name within DeviceFS. This is important if you want to open your own input/output streams.

At the moment there’s no way for the user to select which serial port is used for OS_SerialOp; the HAL dictates which port is used on startup.

That’s great, Jeffrey, many thanks for this. Does this mean that blockdriver code will work too for RX/TX (e.g. as used in your previously posted terminal prog) and that it will access the DB9 socket if set to port 0?

Just answered my own question. Downloaded the latest 5.19 Beagle ROM and tried running some test RX/TX code through the DB9 socket with a loopback plug fitted and ‘port 0’ set as target – everything operates normally (i.e. same results as running the code on an RPC).

Thanks again Jeffrey – I know you’ve been very busy on other stuff lately so it’s great that you found time to sort this.