Raspberry pi serial port

Thanks for the heads up on the baud rate calculation.

My personal view is the operation of the serial port should be included
within the ROM build if possible. Most other systems (beagle board ) have
access to the serial port build in.

I am just pleased that someone got around to finishing off access to the serial port
to much to do here and not enough time.

Well Done :-)

Terry, that’s typical…
Just fired off a request for module chunk and name as no-one had voiced an opinion.

Well its just my opinion :-)

Any easy access to the serial port will be an improvement.

Regards

I’ve been working with single byte transfers and Terry’s drivers are fine, though I found certain certain BASIC structures in my program would stop the RX. The difference was subtle, using THEN instead of ELSE after some lines of code I would have thought would be skipped transparently.
I applied the PIserial swi’s on the same console job I have been doing with the various other drivers and found TX is fine, but RX does a 2step transfer. Every second key press pops up two characters. If I set the Buffer to 0 it does a single step but one character behind.
I imagine on a buffer transfer it might not be noticeable, though it might lose the last character occasionly.
Was there SWI’s for the Iyonix Internal32 driver similar to PISerial?
I’d like to improve my use of that one sometime.
Thanks

I applied the PIserial swi’s on the same console job I have been doing with the various other drivers and found TX is fine, but RX does a 2step transfer.

Ronald, Do you mean you can transmit(TX) OK but receive(RX) doubles up ?
Because I have no problems receiving…

Was there SWI’s for the Iyonix Internal32 driver similar to PISerial?

If you are using the !SerialDev drivers, then yes the same calls are available.
Using the module SWI’s is different.

P.S another update available from the same location

@Tank
Instead of a character being read on every keypress on the remote terminal, it waits for a second character and then releases two characters. I guess this means that even though it has received the first character it is still showing -1 until getting bumped with the second character,then somehow releases two.
Using OSCLI"PISerial_InBuffer 0" changed the behaviour to outputting a character at a time, but lagging behind one character.
I’ll have another look today with your new driver and a fresh reboot to see if anything has changed. We are 12 hours out of sync with you here.
I am using
SYS"PISerial_Speed",0,spd%
SYS"PISerial_Format",0,0
SYS"PISerial_Control",0,0,0
SYS"PISerial_TXPurge",0
SYS"PISerial_RXPurge",0
to initialise, and
SYS"PISerial_RX",0,0 TO ,k%
IF k% <> -1 THEN
To obtain the byte.
Regarding the Iyonix !SerialDev drivers, I am setting them using a hybrid of Fiennes example and the confix utility from !Enigma which appears to work but I am only talking to Serial:
Using same setup on my RiscPC (minus BlkDrv) and I can use
k%=FNd(DRIVER_POLL,0,0,0)
IF FNd(DRIVER_CHECKRX,0,0,0)>0 THEN
k%=FNd(DRIVER_GETBYTE,0,0,0)
I am using OPENIN and OPENOUT with “Serial:”
I can use the same method with the second port with the Devices# string, but I dont have the information to try another way.
Thanks

Ronald,

I see what you mean now…
That is a limitation of the FIFO interrupt system !
The trigger point for the interrupt can only be set at >=1/8 full at the lowest, and as the FIFO is 16 bytes…..
The FIFO’s cannot be separated either, so both on or off.
I’ll try a build with FIFO’s disabled, but that means more interrupts are generated.

Also, I have changed the SWI name to PiSerial_ for the allocation request, so you will need to change your code to suit if you try the new build.

If you wish to send me your email address, to webmaster@tankstage.co.uk I could use you as my test bed.., and we can keep the chatter here to a minimum.

With help from Ronald, I think most of the module will work now…
I have setup two Pi’s back to back and using both the blockdriver and direct calling of the SWI’s, all seems to work.
Also receiving from a device to one of the Pi’s works.
Ronald does seem to have a problem, so it would be nice if there are others who could try as well.
A cut down version of the !SerialDev app that XAT released is here that contains the module, the driver file, a modified BlockDrvs !StrongHelp manual and a small test app that sets the loop-back in the modem and sends and receives a block of data.
Source for the module and the driver is included and should compile with the ROOL build environment.
Module is now registered as well.

The said problem has been found and fixed. (by Tank) Looking at the timestamp, the latest has been uploaded, just check that the timestamp is 04:33:23 09 Jun 2013 or newer on your PiSerial module or download again.

Hello

Tried the module successfully with 115200 baud on external terminal connected to Pi.
On any other baudrate the test fails and I have no idea why.

Regards

Arno

Hi Arno, you haven’t described what test you use. I assume you know the speeds have to be set on both machines? If connecting to Raspian, the default is 115200.

Hi Ronald,
the test is simple, transmit and receive ascii characters from Pi to Win 7 PC with terminal program.
The setup on the PC is proven by some of my microcontrollers and the result is ok
when 115200 is used. When 19200 or any other baudrate is used I get a result that looks
like a connection with wrong baudrate.

OK, so you know for sure that the Win7 terminal is changing speed from connecting to other machines, that only leaves the method for setting the parameters with RISC OS Pi. I am still on RC8 so later I will install RC11 on my Pi and then I will re-run what I have used previously and report back with the results.

Thank you, RISC OS is RC11 here. In the meanwhile I tried the program from Terry with the speed calculation from Tank and had success.

I’ve installed RC11 and I can use 38400 with the blockdrivers. You could try setting the speed with this utility.
http://homepages.woosh.co.nz/ron.may/ser.zip
It needs the !Confix resource installed.
Have you found the stronghelp file for PiSerial Blockdrivers? Somebody like Tank may be able to tell you what you are getting wrong if you post your attempt.

Thank you for the tool. I was able to set the speed with Terry’s program and work with the
blockdriver then. I still have no chance to set the speed with SYS “PiSerial_Speed” in Tank’s module.
I’m sure the problem is how I use PiSerial_Speed.

@ Ronald:
It’s been solved. With the help of your LDConf file I locate my fault.
Now the module is in use!

Arno, sorry I didn’t have time to help you earlier, but it seems Ronald sorted you anyway….
Hope it does what you want!

Tank, there is a change to RISC OS 5.20 that has added OS_SerialOp 10, (get devicefs name). some details I have from the 5.20 changelog.
I am trying to update my StrongHelp but I’m only guessing so far.

OS_SerialOp 10 (5.20+)
#parent OS_SerialOp
=> R0 = 10 (reason code)
<= R0 preserved
<= R1 = pointer to device name string
#tab;line

It appears to be used with serial mouse detection, and I don’t know if reason code 10 is of any other use yet.
I noticed the change has been tested on BB-xm, are all SerialOp codes valid on the BB-xM?
The other case to check SerialOp codes on would be RISC OS 5.21 on the RiscPC I guess. The SerialOp codes I am using with Iyonix port0 and RiscPC 3.7 so far, and should work on older hardware, but the Fiennes
Blockdrivers commands can do both the RasPi blockdrivers and Acorn hardware/blockdrivers.(but not Iyonix)

Tank, there is a change to RISC OS 5.20 that has added OS_SerialOp 10, (get devicefs name). some details I have from the 5.20 changelog. I am trying to update my StrongHelp but I’m only guessing so far.

Your guess at the call details is pretty much correct. There’s some “official” docs on the wiki: https://www.riscosopen.org/wiki/documentation/show/OS_SerialOp%2010

I noticed the change has been tested on BB-xm, are all SerialOp codes valid on the BB-xM?

Yes – or at least as much as the hardware allows. e.g. the BB & BB-xM only have the RX & TX lines connected, so hardware flow control and modem lines won’t work.

My memory is a bit hazy, but IIRC the OS serial device drivers break down as follows:

• The SerialSupport module implements OS_SerialOp, but doesn’t talk to any hardware directly. Instead it talks to serial drivers via a DeviceFS interface. I don’t think there are any official docs for this interface, but see the SerialDeviceDriver sources for the original implementation.
• On RiscPC and Iyonix, the SerialDeviceDriver module provides an implementation of the DeviceFS interface and talks to the hardware directly. However, SerialDeviceDriver is only used for one of the serial ports on the Iyonix. SerialDeviceDriver knows how to talk to 82C710-like serial ports (as used in RiscPC and above) and 6551-like serial ports (as used in the Arc).
• On Iyonix (for the 2nd serial port) and OMAP3/OMAP4, the HAL UART API talks to the hardware, and the DualSerial module talks to the HAL. Although DualSerial did register the serial ports with DeviceFS, it didn’t use the same DeviceFS interface that SerialSupport/SerialDeviceDriver used – it used a completely different IOCtl-based interface. So when I added OS_SerialOp support to the BB-xM I went down the route of adding support for SerialSupport’s DeviceFS interface to DualSerial. This also required the addition of OS_SerialOp 10, as the DeviceFS device was no longer always named “DeviceFS::$.Serial”. Note that although OS_SerialOp can be used just by itself to talk to the serial port, some bits of the OS were using OS_SerialOp to configure the serial port and then accessing the DeviceFS file directly – so obviously need to know the correct file name to be using.
• The “Internal32” serial block driver uses either OS_SerialOp or the DualSerial IOCtl interface, depending on what port number you request.
• For the Pi, it looks like the HAL interface and DualSerial are in place, but SerialSupport isn’t being included in the ROM. So maybe if that was added everything would work without the need for extra software? Edit – Closer inspection shows that the HAL calls are only partially implemented, so it looks like those will need finishing up before DualSerial+SerialSupport can be used.

See also this thread for a bit more background on the OS_SerialOp/DualSerial changes.

Thanks for the helpful overview, Jeffrey.
Today I got RISC OS 5.20 with the new boot structure going on my RiscPC. I had a bit of trouble around Toolbox modules, till I found them unplugged. Anyway, My little serial terminal program built to work on Iyonix port0 using SerialOp commands worked equally as well on the RiscPC. (connected to a minicom terminal)
I used the Internal32 blockdrivers and tried a couple of speeds with no errors.
I dont have a BB-xM, but from the previous posts it appears that I would use SerialOps to do everything (including setup) and it has to be port 3 rather than 0.

Tank,
For your PiSerial module to work correctly, what setting of
init_uart_clock are you using please?

Kim,
I have no setting in my Config/Txt file, so the default will be used (3Mhz).

Fitted a little USB→3.3V serial to my Pi. Chinese clone chip, bought cheap from Amazon. Thankfully the Prolific driver in my XP box was too ancient to attempt to verify the chip was ‘real’.
Given the CJE module in place, it was a tight fit (as in bending some of the GPIO pins to fit!). (^_^)

Tank’s module works nicely, can send debug messages from an app.

Serial blockdriver + HearSay2 = task freeze (Alt-ESCable), not sure why.

Looks like I can build a version of DADebug that will write out to serial using the HAL’s debug. Nice!

http://www.heyrick.co.uk/blog/index.php?diary=20140620