Need help to read/write uart2 on a BB-XM

Been trying to read/write the alternative serial port (uart2) on a Beagleboard-XM’s GPIO pins via Basic. So far I haven’t had any luck receiving or sending (I’m monitoring the TX line on a scope).

The reason I’m looking at uart2 is that I’m attempting to sniff the protocol being used between a PC and a machine tool and need a pair of RX lines available on the XM so I can monitor the PC’s TX and RX lines simultaneously.

Using the XM’s DB9 socket, I’ve been able to monitor either of the PC’s TX or RX lines after hacking into the PC-machine cable, but I need to view the two-way traffic in realtime so I can see which commands are interlaced and when – hence the need for two RX lines.

Would anyone have any simple code snippets they’ve used in the past to access uart2 successfully? I’m just looking to transmit some chars on the TX line initially to generate a trace on my scope.

Does the 2nd port have a serial device interface?

filer_opendir devices:$

will show serial: serial1: or at least 2 serial ports if it does. If it does

echo test { > serial1: }

should work. If it locks up the machine try

echo test { > serial1#nohandshake: }

If all else fails, plan B could be to buy a PL2303 USB serial dongle (vellee cheap!) and use Rick Murray’s driver module. There’s a thread about it in Community Support.

Hi Dave. I haven’t been able to locate Rick’s module, it doesn’t seem to be on his website. I read in the thread that you have written a PL2303 module yourself that was working well – is yours available anywhere?

On xM I use The block driver for the serial interface. However, what is needed is the complete block driver (! SerialDev) by Paul Reuvers (XAT).
The SerialHAL driver works, thanks Willi, for all OMAPs (3, 4, 5).

and use Rick Murray’s driver module

It’s not mine. I’m just the guy that was asking. Colin did the hard work here.

buy a PL2303 USB serial dongle (vellee cheap!)

Something that appears to have come out of this (both here and sources of info for my weather station) is that a lot of dirt cheap serial interfaces don’t bother with “complicated” stuff…like the flow control pins. If I wanted a Tx/Rx only serial interface, pretty much every SoC on the market offers that much… so… you get what you pay for.

it doesn’t seem to be on his website

Ooh, a real non-bot visitor. If I’d known if have put the virtual kettle on.

It’s not mine. I’m just the guy that was asking. Colin did the hard work here.

My apologies to Colin and to Rick. That’s a complete and utter brain-fart on my part.

I read in the thread that you have written a PL2303 module yourself that was working well – is yours available anywhere?

It’s working well in my tests, but it’s not quite ready to hand out yet – nor is the documentation quite there, and, of course, without the documentation, you won’t know how to use it. I’m hoping that it will be fit to hand out for testing in a few days.

I got the SWI allocation today.

a lot of dirt cheap serial interfaces don’t bother with “complicated” stuff…like the flow control pins.

It’s interesting that Colin’s PL2303 dongle doesn’t have the input control lines, but mine does. I have no idea where I bought mine – it must have been at least a couple of years ago. I’ve ordered another one from eBay that looks identical to the one I already have. We’ll see what turns up.

It does mean that I’ve been able to write and test my module’s function to read the input control lines.

Mine’s not a dongle its a pic programmer. I removed the PIC16F628A it uses to control the programming and stuck a couple of wires in the socket where the chip’s tx and rx pins fitted and connected them up to a CP2102 TTL serial usb device. The other pl2303 pins are all held logic low but the DTR and RTS pins flickered enough when setting DTR/RTS to show that the set command worked. The only thing I can’t test is rts handshaking – xon/xoff works well enough.

I’ll release mine soon for anyone who is interested. Suppose its like buses, you wait for ages and then 2 come along. Dave is supporting the serialdev interface and I’m supporting the DeviceFS interface so it works like serial:.

Colin, *devices:. shows Serial1, Serial2, Serial3, on the BBxM I’m using.
I’ll try your echo suggestion later when I’ve got my scope up and report back.

Suppose its like buses, you wait for ages and then 2 come along. Dave is supporting the serialdev interface and I’m supporting the DeviceFS interface so it works like serial:.

One question, then, is: is it possible for one module to provide both interfaces?

Yes – but I didn’t like to say.

I’ve never looked at the SerialDev interface in anger so don’t know what is required. I thought SerialDev loaded a program which converts from one interface to the serialdev interface eg Internal32 – I didn’t think it needed a module for a serialdev. If you can create a serialdriver for ‘Serial:’ you should be able to produce a serialdev driver to my module without any additional changes to my module – changing Serial: to SerialUSB: in the driver would work. I think it would be easier that way around than me adding a DeviceFS interface to your module. What you won’t be able to do with usb serial devices is software flow control – I don’t know if serialdev does that.

Personally I find using the DeviceFS drivers easier in a program though possibly SerialDev has better backward compatibility – I don’t know.

I’m at work and typing complex stuff on a phone is problematic…
I’ll explain SerialDev this evening. (done)

If you have ever dabbled in the world of the PC, I’m sure you will understand one of the main reasons Windows walked in and blew away the competition.

Let’s consider WordPerfect 5.1. It wasn’t a bad word processor as far as such things go when you’re mostly working in DOS console mode. However one of the big problems that was experienced by the majority of the software of the day was that it needed drivers for a Hercules monitor, it needed drivers for a Kyorcera f-800 printer. Accordingly, most printers of the day would pretend to be an Epson fx80, an HP LaserJet II, or something of that ilk.

Along came Windows. There are obvious benefits in the multitasking abilities, that you can push the wordprocessor to the back while you fiddle with the calculator (or the card program, like everybody else in the world…), but the primary benefit to both software houses and users is that it totally nuked all that balls with drivers. Windows offered a generic graphics device interface (that’s what GDI stands for) and you draw to that to paint to a Window, and you draw to that to paint to a printer. It doesn’t matter whether it’s a high resolution monochrome monitor and a professional printing machine, or a bog-standard VGA monitor and cheap dot matrix. It’s all the same to you. You can even output colour and let the driver do with it what it wants (ignore, halftone, etc).

Why am I talking about Windows? Because this abstraction is exactly what SerialDev is. You see, when the Acorn machines first came along, they may (Archimedes) or may not (A3000) have had a serial port. You talked to it using OS_SerialOp SWIs. However, the port was famously buggy (leading to non-standard wiring) and famously crap – it was built using the 6551 ACIA, a serial chip from the mid ‘70s that wasn’t designed to go much beyond 19,200 baud (and being clocked with a 1.8432 Xtal, wouldn’t be able to even if it wanted) and offered no buffering.

This led to numerous outfits offering improved serial cards. One of the first was the SP_Dual (mine was an issue 2 board) originally designed and sold by Hugo Fiennes, later by Atomwide. Because, you know, The World Of Cryton would suck if it was a single line BBS running off the internal port. Then there was the Intelligent Interfaces card, but that didn’t go so fffast! There was another one too. Then the Atomwide card came in a three port variety, then for hardcore BBSing (Arcade style), it was possible to have up to eight “SP_Dual” serial ports running in the computer. Plus the internal port. Plus, I presume, any on an II card if it is also fitted. Or this beauty – daaaamn! Though I’m not aware of anybody back in the day who was willing to pay BT for that many phone lines.

[this one was never sold to us grockles… but an FPGA and blinky lights – epic!]

But – wait… Hang on. I know I had to dump ZAnsi when I got myself an SP_Dual, but… ARCbbs, ArmBBS, Archiboard, RiscBBS, ArcFax, Binkley, ArcTerm7, Hearsay2… are all these going to stop working too?

No. They aren’t.

Because of the blockdrivers.

You see, the “blockdriver” is not a serial driver. It is a small piece of code that is loaded to act as a veneer to calling the real serial hardware. Via OS_SerialOp for the Internal/InternalPC drivers, or usually via a driver module that is loaded from the podule when the system initialises for the expansion cards.
A little more complex in the case of the Pipe, Telnet, and various attempts at an Econet (!) driver.

The blockdriver is not intended to provide all the stuff necessary to deal with the hardware, it is just there to be like the Windows GDI and provide a consistent interface between the software (that can remain mostly agnostic) and whatever the actual hardware is.

It also has the benefit that the driver can be upgraded, or new drivers added and used, with no changes to the software.

Okay. There endeth the history lesson. ;-)

If you can create a serialdriver for ‘Serial:’ you should be able to produce a serialdev driver to my module without any additional changes to my module – changing Serial: to SerialUSB:

Maybe. How much do you support the IOCtl reason codes?

Don’t panic – this stuff isn’t insurmountable!

The normal method of initialising a blockdriver is as follows:

• Load it, call the Init entry to start up the driver.
• (that which follows can be in pretty much any order)
• Set the Tx and Rx speeds.
• Set the flow control.
• Set the word format.
• If anything else I’ve missed, set that too.

The problem comes that your driver, as it is, takes magic values passed in the file open call. My weather program, for example, is “SerialUSB#noblock;nohandshake;baud=2400;data=8;stop=1;noparity”.
Now, it would be logical to open the send and receive file handles at the SerialDev Init entry. Well, what happens if the program then wants to run at 1200 baud, with a 7E1 format?

What you would need to do to permit a blockdriver to be written is to provide hooks to allow these things to be altered after the device has been opened; plus reading the control lines.

Take a look at the blockdriver specification document, that’ll give you an idea of what is expected. Obviously some things may be of less relevance (like sending a break).

From the code you send me, it seems that setting the control lines is performed via OS_Args IOCtl. Do you support the other IOCtl operations as well? If so, then that may be what is needed to permit a blockdriver to be written.

Are the serial IOCtl operations documented anywhere? StrongHelp lists the reason codes, but not what data is expected.

What you won’t be able to do with usb serial devices is software flow control – I don’t know if serialdev does that.

That is up the the end-program. SerialDev is, as the name implies, a “serial device”. ;-)

Personally I find using the DeviceFS drivers easier in a program though possibly SerialDev has better backward compatibility – I don’t know.

DeviceFS does not exist in RISC OS 2.
Read the PDF PRM for OS_Args (p2-59 actual in my copy) and you’ll see no mention of an IOCtl reason. This didn’t exist in RISC OS 3.10.
This is the world in which SerialDev was born…

I hope this helps. Used to run a BBS and wrote a crappy comms program, plus run up some obscenely ridiculous phone bills, so… yeah… I’ve dabbled with SerialDev back in the dark dim and distant past.

However, the port was famously buggy (leading to non-standard wiring) and famously crap

Actually that rather describes the, then, state of serial comms on the PC as well.
In fact you had to something of a guru/smartass to get things working between two PeeCees never mind two different platforms (IBMmainframe / Dec mainframe /PeeCee etc)

The blockdriver is not intended to provide all the stuff necessary to deal with the hardware, it is just there to be like the Windows GDI and provide a consistent interface between the software (that can remain mostly agnostic) and whatever the actual hardware is.

Serial HAL :)

In fact you had to something of a guru/smartass to get things working between two PeeCees

Oh, that was actually quite simple in most cases. Read the datasheet, write for the lowest common denominator (like assume no FIFO unless you can specifically tell otherwise) and talk to the hardware directly.

Where it all fell apart horribly was when people just, you know, expected the BIOS serial routines to work. They usually didn’t, and those that did tended to fail at anything over 9600-19200bps. And we’re talking a ~50MHz 486 here, so not a slouch (in its day). The BIOS routines were just about as rubbish as rubbish could be¹. Some naff TurboC code was infinitely better than the BIOS rubbish¹. Did I mention that the rubbish was rubbish? Yes, it really was that rubbish.
Okay, enough of that.

With mainframes, wouldn’t you have character set issues as well? Or had EBCDIC died out by then?

Professor: "So the American government went to IBM to come up with an encryption
           standard, and they came up with—"
Student:   "EBCDIC!"

Serial HAL :)

Exactly. :)

¹ Technical: The BIOS polls the serial port. Yes, really. TurboC can set up an interrupt handler so the port can let the program know when it needs attention. The difference is enormous.

I know why blockdrivers came about but the standard RO interface is via DeviceFS and has been for a lifetime. I only see a use for blockdrivers for backwards compatability. They shouldn’t be needed any more for new programs.

Maybe. How much do you support the IOCtl reason codes?

IOCtl is supported. If you can write a driver for Serial: it will work for SerialUSB:

but the standard RO interface is via DeviceFS and has been for a lifetime.

I beg to differ. OS_Args #9 is not present in either PRM book 2 or 5a. I’m not sure when it was introduced, however this document http://www.marutan.net/wikiref/Acorn%20Registered%20Developer%20REFERNC/RO4/API/HTML/SERIAL.HTM carries a date of 1998, which puts it in line for a Phoebe extension, meaning it likely isn’t a part of any Acorn-released versions of RISC OS.

• Update: Done some more digging. OS_Args IOCtl was added to FileSwitch as of the RISC OS 3.71 release; and support for it in DeviceFS was added for the NCOS / RISC OS 3.80 versions.
  So it’s SerialDev up until the RiscPC era then…

IOCtl is supported. If you can write a driver for Serial: it will work for SerialUSB:

That’s good to know. ;-)

With mainframes, wouldn’t you have character set issues as well? Or had EBCDIC died out by then?

Contrary to popular belief, neither mainframes nor EBCDIC have died out yet. When doing an IBM ASF migration project, we found out that the default codepage for DB2 tablespace on z/OS is still 273…not even 1141.

I’ve always regarded the serial blockdrivers as being the only complete, consistent and simply documented interface across all serial interfaces, which is why I wrote my PL2303 module with an interface that lends itself very easily to being called by a blockdriver shim. But it doesn’t have to be used with a blockdriver.

Contrary to popular belief, neither mainframes nor EBCDIC have died out yet.

Indeed, only a few months ago I got caught out by this. I have trained myself to switch to binary mode when using command-line FTP and found I was getting what looked like meaningless garbage instead of a plain text file. The machine at the other end was using EBCDIC. I now know that ASCII mode does more than convert line endings.

Back on the subject of BeagleBoard UARTs: It’s possible the default pin mux settings aren’t exposing the serial port(s). You’d have to check the BB reference manual and the OMAP TRM to work out what the correct settings should be.

I was going to look to updating the blockdriver specification to cover some aspects of the newer hardware, only XAT has got there ahead of me – http://www.xat.nl/en/riscos/sw/bd/

Problem is, the actual blockdriver spec doesn’t appear to have been published yet. So I have sent an email to ask if it can be.

I think his modifications are going to be more involved than mine would have been. I was planning to add the following – and this is off the top of my head so may be subject to revision:

• Flag 32 bit (so 26 bit code can be rejected)
• Flag SVC safe (it preserves R14 around SWI calls – not all SerialDevs do)
• Flag an extended jump table (see below).
• Flag the device as being potentially removable.
• Flag the device as potentially having zero to multiple interfaces available (must enumerate first).
• Flag the device as “simple serial” (Tx and Rx only), so accordingly won’t support hardware flow control.
• Flag that the output buffer must be emptied (or flushed) before being closed.
• Flag that the device must be correctly closed down on exit (DeviceFS, has file handles active, etc…).

If the extended jump table is available, then there would be additional entry points for setting the block/noblock status of the port, plus a call to enumerate the hardware to update information on ports available. This is primarily for USB devices.

Some sort of tweak to the existing API to flag if a port in use has been disconnected.

That’s more or less what I had in mind. Let’s see how things turn out…

Flag the device as “simple serial” (Tx and Rx only), so accordingly won’t support hardware flow control

Under what conditions can you get this information and rely on it? I don’t think you can read it from the device. I believe there may be USB serial dongles out there that appear identical, but only some of which have the handshake lines fully implemented. You wouldn’t be able to tell the difference over USB. So I’m not convinced that the flag can be reliably implemented – and, if it can’t, then it’s useless.

Note that I said “there may be” – I may equally be wrong and thus guilty of spreading FUD.

I was thinking more of the internal ports of the SoCs (Beagle, Pi, etc) which in their usual implementation only support that which is necessary for a console.

USB devices, more problematic. I wonder if some empirical tests might show some sort of pattern? I don’t know – it may be that the chip is quite capable of hardware flow control but the manufacturer cheaped out with the serial wiring so just didn’t bother to wire up those pins? If this is the case, telling the devices apart may be practically impossible?