Serial Comms via USB or otherwise: Summary of Status?

I believe this to be an important ‘Wish List’ item concerning a fundamental aspect of the BBC Micro heritage which may or may not be currently supported’; it is certainly lacking any coherant ‘current’ documentation. Once the current situation is clarified, hopefully an appropriate target and progress path can be identified to the benefit of all:

Can someone clarify with a meaningful single-location summary or thread (linked from here??), and ultimately ‘current’ documention on this site; what the current status is on Serial Comms with the current release and modern hardware boards – whether by bi-directional RS232 format, Serial-over-USB, GPI i/o or perhaps I2C… or more limited 1-way solutions.(primarily, in my interest, the RaspberryPi, but applicable to ALL since the original ModelB)

I find only ‘dead ends’ or ‘blank holding pages’ for what, in the wake of the BBC Micro legacy onwards, appears to be a fundemental absense of ability, or explanation, of how to connect to the real ‘outside world’ with the longstanding serial comms found on so many pieces of equipment for ‘real world’ computing: the opposite of the BBC Micro! – and more akin to a Spectrum 8-(

There ‘used to be’ a few basic FX commands to set up a serial port … I find threads mentioning higher than Acorn documented speeds being obtained on the RPi… Alternatives, which sound ‘processor intensive’ (?) are using a GPI I/O bit by bit! Some of these are used 1 way only. But no definitive and updated reference point. Old links which are Error404.

‘Pseudo Keyboard Entry USB from RFid Tags’: Working
===========
‘USB RFid Readers’ (CoreRFID and cheap Chinese USB readers) WORK when plugged in, and the data appears as if a keyboard entry….. so I/we can at least use 1 reader at a time, unless I can also identify which USB port each came from.

[Using a ‘MERG Concentrator kit’, I can merge 8+ identifiable RFid readers (CoreRFid OR Chinese) in realtime – but this has RS232, 1 directional output …. I would like to feed this in through one of the existing solutions, preferably a Serial-over USB solution.

Similarly, I have an NCE ‘track dcc reader’ which provides me with continuous monitoring of all commands being sent to the track – again as RS232 1 way.

(If you hadn’t guessed, this is for a model railway monitoring program, which I would ultimately like to be able to output seria/serial-over-USB commands to act as another (Expressnet) handset.

I also have a modern Oscilloscope which can save its data, and connect via Serial (or Network) …

I am sure that others can add many other control devices which are simply waiting for the fundamental basic serial comms to be operable by all.

Somewhere, there was mention of adapting open-source Linux drivers which exist already for Serial-over USB converters … is there any prospect of this being the way forward?

Dave Higton has produced many examples of USB adaptions such as the Vellemann8055 USB board, and USB Missile Launchers etc … perhaps a tutorial based on his successes, to explain how others might be added??

For the Raspberry Pi, try this . In the zip file is a module and blockdriver for the main serial interface.
Remember the interface is only 3V3 on the header, so you need to convert to talk to RS232.

I believe this to be an important ‘Wish List’ item concerning a fundamental aspect of the BBC Micro heritage which may or may not be currently supported’;

Once upon a time, serial ports were ubiquitous. Even silly home computers that couldn’t do much of anything had a serial port.
Sadly, time has moved on and it is actually quite difficult to find a serial port on a modern computer. There isn’t really much need, nobody much does comms and fax like that any more (and with an increasing amount of VoIP traffic, such things wouldn’t work even if you had the hardware.
Consider this the first problem.

The second problem is that while most of the ARM SoCs provide a serial implementation, it is 3.3V logic. Some devices (such as the Beagle xM) provide level converters and a standard serial plug. Other devices (such as the Pi) do not.

The third problem is that the ARM SoC serial ports are used for debugging. Maybe a dumb console under Linux. As such, it is wired Tx/Rx/Gnd. Nothing at all fancy. I had thought it would be cool to rework the Psion stuff Theo did for the Pi, but it would require a fair bit of farting around to support other GPIO pins to provide the missing pins that were used for various forms of signalling (you know, DCD, CTS, etc).

documention on this site; what the current status is on Serial Comms with the current release and modern hardware boards – whether by bi-directional RS232 format, Serial-over-USB, GPI i/o or perhaps I2C… or more limited 1-way solutions.(primarily, in my interest, the RaspberryPi, but applicable to ALL since the original ModelB)

The RISC OS HAL does talk to the hardware serial port. As the machine boots, it spits out some debugging information.

As noted above, Tank has written a serial blockdriver to allow the Pi’s serial port to be used. The OS_SerialOp SWIs don’t work on this hardware, it seems.

how to connect to the real ‘outside world’ with the longstanding serial comms found on so many pieces of equipment for ‘real world’ computing:

For me, I just wanted to link the Pi’s serial port to a netbook that has NO serial port. I bought a cheap little USB to 3.3V serial dongle.
This:

The red wire is left unconnected, it is 5V from the USB. The black, white, and green are the Gnd, Tx, Rx respectively which are fitted to the appropriate places in the Pi’s big row o’ shiny pins. The rubber band keeps the wire tidy and the clothes peg is so I can clip it to the bookshelf.

More information and some example code on my blog.

If you would rather have a serial connection to permit other serial devices to be used, you will need to have a level changer to convert raw serial to something the Pi can work with. There’s some information on somebody else’s blog. ;-)

There ‘used to be’ a few basic FX commands to set up a serial port …

Won’t work. If SerialOp doesn’t work, the *FX commands won’t.

I find threads mentioning higher than Acorn documented speeds being obtained on the RPi…

Eh? Acorn documented as in what? The BBC Micro was a 2MHz processor so would probably top out at around 9600bps. The RiscPC, on the other hand, can do 115kbps, and possibly even faster, though I’m not sure if the “official” API supports that.
The Pi, on the other hand, is modern and far after anything Acorn-era. As such, while the Mini-UART normally runs at 115k, it can be pushed to 1Mbaud and some sources indicate that it can go up to 32Mbaud, but because the buffer is small, such speeds will clobber the system.
There is another, better specified, serial port that offers some flow control (RTS and CTS only). This is isn’t, as far as I can tell, used by default. Info and comparison here.

Alternatives, which sound ‘processor intensive’ (?) are using a GPI I/O bit by bit!

On a Pi? Why? It has hardware serial, it has hardware SPI, it has hardware IIC… It doesn’t make sense to ignore the onboard hardware and big-bang an interface that is already provided.
I think one only needs to bit-bang if they’re trying to implement something fruity like CAN or LANC…

Thomas Milius wrote a driver for FTDI Serial-USB converters:
http://www.thomas-milius.privat.t-online.de/Download/Freeware/FTDI.zip

This works via DeviceFS. Maybe someone could extend it to SerialOp and provide a blockdriver?

Finding a suitable “USB to RS232” adaptor that worked well might be a problem- it rather depends on what you want to control.
I was looking for one that worked with Windows so I could add/plugin a Morse Key.