Idea for a SerialUSB blockdriver

First up, apologies for the data dump. My RISC OS machine doesn’t have the software to connect to my website and I’m not starting the PC as it’s half past one and I plan to go to bed in the next ten minutes… ;-)

Anyway, THIS HAS NOT BEEN TESTED . . . at all.

I just want to make that clear. I looked at the blockdriver spec and wrote this. I would be very surprised if it doesn’t crash. In fact, I’d be surprised if it even builds.

It is intended to kick-start the idea of writing a serial blockdriver for Colin’s SerialUSB module. While it uses a weird interface (all that IOCtl stuff), there’s no real obstacle to there being a blockdriver for it, so… here’s a start.

Oh, and if there are any howlers in the code – the company I work for is having a very important audit on Tuesday, so it’s been a hell of a week getting everything all shiny. There’s only so much tea a person can drink…
…thank God it’s the weekend. I plan on doing nothing.

; A thrown-together blockdriver for Colin's SerialUSB.
; Written to conform to the old "revision 12" spec.
;
; By Rick Murray, Friday, 8th April 2016.


 [ C O D E   D E L E T E D ]

        END

Edit (2017/09/07): Code deleted. It had numerous “issues”. Scroll to the bottom of the page…

In fact, I’d be surprised if it even builds.

Prepare to be surprised: It builds!

(But it doesn’t link…)

(But it doesn’t link…)

How can it not link? It’s entirely self contained.

Oh, wait, you are linking it as a raw binary aren’t you? You don’t want to give it any sort of header (AIF, etc).

I was only building it as a curiosity; I didn’t actually try to understand it :)

; What the hell Hugo? What do you mean “hardware”?

As per the standard serial description. Hardware flow control used changes in the RTS/CTS, DTR/DSR as opposed to software flow control by sending X-On X-Off characters.

The fun part of the latter was when an XON got lost and the link locked up waiting for what had already been sent. Properly written stuff did retries on the flow control of course.

BTW. Quite impressed with the use of micro text to match the micro code :)

My version of the !ObjAsm doesn’t seem to like ‘orreq r0,#2_01’ etc – missing a r0.
Note if others havn’t !ObjAsm – the GCC ‘asasm’ assembler works.
Would it be possible to test the Blockdriver – with something like !Hearsay and a modem?

As per the standard serial description. Hardware flow control used changes in the RTS/CTS, DTR/DSR as opposed to

That’s the point I was making – “hardware” comes in two flavours, and there doesn’t seem to be any way of specifying whether it is supposed to be RTS/CTS or DTR/DSR…

My version of the !ObjAsm doesn’t seem to like ‘orreq r0,#2_01’ etc – missing a r0.

Yup. That’s a typo. Should be R0, R0…

…I didn’t realise because instead of saying an R0 was missing, it told me that I was using UAL instructions in non UAL code…

Serial specs

That’s the point I was making – “hardware” comes in two flavours, and there doesn’t seem to be any way of specifying whether it is supposed to be RTS/CTS or DTR/DSR…

;-)

BTW, here’s a more readable version: http://www.marutan.net/wikiref/Acorn%20Registered%20Developer%20REFERNC/RO4/API/HTML/SERIAL.HTM

I didn’t find a copy of the blockdriver spec online, so I have put revision 12 of Hugo’s document on my Pi server at http://heyrick.ddns.net/files/BlockSpec.txt

I didn’t find a copy of the blockdriver spec online

It is available at the more-or-less-now-official blockdriver page: inside http://www.xat.nl/riscos/sw/bd/rev12.zip

I should have said “a readable copy” I know it’s there in the archive (though I just pulled mine out of the local !SerialDev), but it’s not so easy to point to as a “here, read this” when it is in a zip file. ;-)

Of course, my copy may be unavailable tomorrow. If we go out I’m unplugging stuff as the forecast is for thunderstorms every other hour… Given we’re at the end of a long run of exposed low voltage (230V/400V) three phase and the end of around for and a half kilometres of overhead phone line, been there done that – now I err on the side of paranoid…

If you check inside this there is a StrongHelp version that I updated from one I found somewhere, originally converted by David Thomas.

I asked a couple of years ago for the BlockDriver module spec as well from Xat, but it was never forthcoming, so I hope you get them.

Is there a list of modules versions required for blockdriver/SerialUSB/USBDriver etc for the Iyonix?
Anyone come up with a way to load the USBDriver very early in the !Boot sequence?
Also Drucks ARMalyser reports:- is a nop required?

MSR CPSR_cxsf,R5 ;~ Not ARM2/3
LDMFD R13!,{R1-R7,PC} ;~ CAUTION: uses banked register. Function exit,Ends

Is there a list of modules versions required for blockdriver/SerialUSB/USBDriver etc for the Iyonix?

A recent beta ROM ought to have a new enough USB driver.
Colin’s SerialUSB just keeps improving. I think the current is v0.06.
Don’t rely on my blockdriver. I have not tested it (nor am I going to – my serial doodah is attached to the weather station).

Anyone come up with a way to load the USBDriver very early in the !Boot sequence?

I’d edit the Boot.Run file (no !s or textile will mess it up). That’s the first thing to run.

Also Drucks ARMalyser reports:- is a nop required?
MSR CPSR_cxsf,R5 ;~ Not ARM2/3
LDMFD R13!,{R1-R7,PC} ;~ CAUTION: uses banked register. Function exit,Ends

As the MSR instruction sets all parts of the PSR, it is quite possible that the R13 referred to may be in a different mode (if we’re in SVC mode and the flags are updated to specify a return to USR mode; the R13 following will be R13_usr not R13_svc).
In the early ARM versions it was important to have a non-instruction following any mode change and banked register access; but this hasn’t been an issue for a long time.

Rick, why don’t you finish off your blockdriver? If you use the initialise driver parameter string as the filename or, if that isn’t used, use DeviceFSDriver$path (call the serialdev driver DeviceFSDriver) then you would only need the one serialdev driver for all RISCOS serial ports.

I don’t have a serial device other than my weather station and its peculiar requirements, so testing would be difficult. I was hoping that with the ground work done, somebody else could test it and teak anything that’s wrong…

Okay, I spent this evening working on the SerialUSB blockdriver, with a NULL modem cable, Connector on the RISC OS side, and HyperTerm on the PC.

It now works, fixed as 8N1 with no flow control (as per my version of the SerialUSB module (v0.06 said PL2303 was limited, and since my hardware is a PL2303…)). I have only lightly tested it, it may fail when, say, setting/reading control lines. I’ve not tested this as there’s no sensible way for me to do so – I’ve not had a serial breakout box in ~20 years!

http://heyrick.co.uk/random/susbblk002.zip

Here’s the !ReadMe:

SerialUSB block driver
======================

This is an experimental blockdriver for use with Colin Granville's SerialUSB driver.

It allows access to USB serial devices based upon the CP210x, CH340, or PL2303 chips.

My SerialUSB (v0.06) noted that PL2303 devices are fixed at 8N1 and no flow control. As
such, since trying to change word format would cause Connector to keep crashing, so I
have hardwired the blockdriver to 8N1 with no flow control.
There is a later version of SerialUSB, I've not tried this yet.

Get yours: <a href="http://www.ftpc.iconbar.com/usb/index.html">http://www.ftpc.iconbar.com/usb/index.html</a>


Okay - this blockdriver is EXPERIMENTAL. It has been used to send data to and from a
PC running HyperTerminal (with Connector in use on the RISC OS side), at 115200 baud 8N1,
using a null modem cable.
I have not tested the control lines support as I don't have a serial breakout box to
observe what is happening on the wire. It may or may not work.

* Block get/put has not been implemented.

* Getting buffer sizes may not work. It seems as if the receiver is 'dead' until
  an OS_GBPB operation has been used. Then OS_Args can return the extent (bytes
  waiting in the input buffer) and such.

* The driver opens two files - one for input, one for output. If your program crashes
  and/or does not correctly "finalise" the blockdriver, these files will be left open
  and you'll need to close them yourself.

* There are hooks for DADebug. Set "DEBUG = 1" to bring it in, then you can BL to
  "debug_write" to write the string pointed to by R0 (needs to end with CRLF and a
  NULL byte), or debug_writereg to print whatever is in R0 as an eight digit hex number.

* The blockdriver number is 123. This has NOT been allocated. Do NOT rely upon this.

* Setting "BLKDRVMOD = 1" provides rudimentary support for registering the driver with
  the BlockDriver module; so that some information will appear in the !Serial app.
  Note that this is a TRADITIONAL blockdriver, not a veneer for DeviceFS that passes
  everything on to BlockDriver. As such, it is built by standard to NOT talk to the
  BlockDriver module, so it will work fine on systems without it (with older versions
  of SerialDev).

* It is 32 bit, ARMv7 compatible.
  It is NOT 26 bit compatible (but ARM6+ has MSR/MRS so it might work on a RiscPC?).

* You have the source code. It is licenced under the EUPL v1.1 ONLY. Have fun!


Rick, Thursday, 7th September 2017.

Now I’m going to go catch up with Sagrada Reset on my tiny phone with it’s insane screen resolution. (^_^)

HeeBeeGeeBee

Nice one Rick.
Now to try and find my USB > RS232 dongle!!

One for Jeffery – are we supposed to but a NOP between :-

msr cpsr_cxsf,r5
ldmfd r13!,{r1-r7,pc}

are we supposed to but a NOP between

Only if you’re supporting legacy CPU’s (ARM6xx/7xx, possibly SA/X-Scale), its not required for ARMv5 or newer.

That was a paranoid return, restoring flags. It looks as if such a thing is not necessary, so I will remove it. It shouldn’t have mattered on older systems either as the driver does not change processor mode, so no issue regarding banked registers.

PS: is it just me or has the forum taken forever to respond these last couple of days?

PS: is it just me or has the forum taken forever to respond these last couple of days?

Not just you. It seems to me to be forum pages rather than the front page, although I recognise that mine is a small sample.

I reported it to the ROOL webmaster address, and I had a reply from Andrew Hodgkinson, who said it appeared to him to be OK after the automatic overnight restart – but it still seems to me to be an ongoing problem, although not consistent.

are we supposed to but a NOP between

Only if you’re supporting legacy CPU’s (ARM6xx/7xx, possibly SA/X-Scale), its not required for ARMv5 or newer.

I don’t think there’s ever been a need for a NOP in that case. IIRC the only time you need a NOP after an MSR CPSR_c is if the MSR was conditional (StrongARM bug, the instruction after the MSR may be executed twice)

PS: is it just me or has the forum taken forever to respond these last couple of days?

Yes, it’s been very slow for some periods of time. Other parts of the site seem fine.

THANK YOU RICK!

The blockdriver works fine for me. I use serial terminals a lot. I’m probably part of a very small minority of people in that respect. Just using it last night alone saved me many hours of fiddling around to test a binary on the OPiPC.

Unfortunately something to do with !Connector isn’t ARMv8 compatible, so I had to drop back to using the Pi B, but it’s still worth it just to be able to use serial on things again.

Before anyone asks, I ran PatchSWP over !Connector’s RunImage. It didn’t find anything. It is however an illegal instruction that is reported.

What is the date of your Connector’s RunImage?

Any error info – ie:

*showregs

*MemoryI pc-8

*MemoryI pc