Rick's b.log - 2014/06/20
It is the 24th of November 2024 You are 18.119.161.216, pleased to meet you!

Pi Serial port

It arrived, on its own, with no instructions or driver or anything. I opened it up (simple clip together case) and nearly wept when I saw that it was a (Prolific) PL-2303HX. As it came from China and had a non-standard code on it, and used an Xtal between two "reserved" pins, it was pretty easy to assume that this chip was a clone.
The more recent Prolific drivers will do some sort of test and reject many clone chips. Thankfuilly the driver installed in my system was ancient and it "just worked". If you need an older driver, this one apparently works (but as it is from 2shared, virus test it before using!).

Being paranoid, I plugged it into the USB port with the serial end disconnected and probed it with the multimeter. 3.40V. Close enough to 3.3V that no magic smoke will appear. I was also able to determine that the wires are as follows:

• RED - 5V from USB port (leave disconnected - the device claims to consume 100mA, of which the serial chip claims maybe 30mA or so; as such you cannot run a Pi (or much of anything) from the 5V supply as any decent USB hub will should cut the power if the port takes more than its requested amount).
• BLACK - Ground, 0V (connect to GND on the Pi).
• WHITE - Data TO the host (connect to TXD on the Pi).
• GREEN - Data FROM the host (connect to RXD on the Pi).

The next hurdle was fitting the serial port. If we hold the Pi with the SD card on the left, then the correct locations of the pins on the upper row of the two are: GND is 3rd from the left, TXD (white) is 4th from the left, and RXD (green) is 5th from the left. If your GND is claimed with something else, there is another GND 4th from the right.

Unfortunately (for the purposes of fitting this thing), I have a CJE RTC/temp/PWR board which makes fitting the serial pins a little bit harder. As you can see, the CJE board is held in place with two 3×2 headers - the first is for the necessary electrical connections, the other is to add strength so the board doesn't work loose. The serial pins were actually free, not that there was space for both of the serial pins, nor the required clearance. As you can see, I took the approach of bending the Pi's serial GPIO pins slightly and ... well ... pushing.

I started up HyperTerminal and it told me it couldn't open COM9. I clicked on the phone icon to 'connect' and it did without an error. Go figure.

Then I powered up the Pi. Moment of truth!

HalStartup
HalQueryPl
0E100000 007F8000 HalQueryPldone
0E100000 HalStartup2
00008000
00000000 0E000000 ROM start, RAM start, RAM size
ROM relocated
HalStartup3 .. rst rend
00000000 0DB00000 HalStart from OS
0E000000 02000000 F7000000  HAL Init completed
HAL initialised
IICInit
HAL_KbdScanSetup
HAL_CleanerSpace
InitCMOSCache entry
InitCMOSCache done
IMB_Full done
Keyboard scan complete
InitDynamicAreas
InitVectors
InitIRQ1
IMB_Full
VduInit
ExecuteInit
KeyInit
MouseInit
OscliInit
Enabling IRQs
IRQs on
HAL_InitDevices
InitVariables
AMBControl_Init
ModuleInit

The next step is to send data from the Pi to the terminal on the PC. For some reason, HearSay2 freezes the machine when trying to talk to the serial device (sometimes Alt-Break might get you out of it). I don't really want to use HearSay2 to send data, I'm just mentioning this in case you try it.

What you will need is Tank's Pi Serial driver. The OS_SerialOp SWI does not work, and even if it did, sending byte by byte is a bother. At least Tank's module hides this from us so we can just point it at a string and let it do the boring work.

Therefore, start up the module, then do this in your program (or the equivalent in your preferred language) before you want to send data:

SYS "PiSerial_ResetUART"
SYS "PiSerial_Speed",,115200
SYS "PiSerial_Format",,%10000

Then, sending data is a matter of doing the following (assuming buffer% has been DIM'd somewhere prior):

$buffer% = "This is a test!"+CHR$(13)+CHR$(10)
SYS "PiSerial_TX",,buffer%,LEN($buffer%)+2

If you are using BASIC - it is strongly recommended to send short individual strings, one at a time. The reason for this is because if you send long multiline texts, you will need to work out some method of determining where the string ends, as LEN() will stop at the first CR. If you are using C, it's a doddle to drop in \r\n where you want newlines, and just use strlen() to get the amount to be sent.

If you are using HyperTerminal, or a decent terminal, then you ought to be able to get away with using ANSI codes to liven things up. Try this:

DIM buffer% 256
esc$=CHR$(27)
crlf$=CHR$(13)+CHR$(10)

$buffer% = esc$+"[0m"+esc$+"[2J"+esc$+"[1;33mThis is a "+esc$+"[32mtest"+esc$+"[33m! "+esc$+"[35m:-)"+crlf$
SYS "PiSerial_TX",,buffer%,LEN($buffer%)+2

You might wonder why I'm excited to be able to hook a serial port to my PC, given that serial comms are old hat.
Well, the first quote - the HAL startup - should have been a clue.

There are times (most times, actually) when something initialises in a way that prevents you from splattering rubbish all over the screen. Typically you would use DADebug in this situation, and then issue *DADPrint in a TaskWindow. But what if something crashes the machine? Should we try different things until we find a non-crashy combination and work from there (as a crashed machine means we can't read our debug messages!). No. Now we are sending our messages to another system so we can see what is going on, hopefully right into the crash [depends what crashes and if the serial TX remains alive until all data is sent - given on-chip buffering, we can hope for at least this much!].
I may try to mod the DADebug module to write to... wait... it looks as if it can already do this if you recompile it with "UseHAL" defined. [BCM2835Dev.castle.RiscOS.Sources.Programmer.DADebug.s.DADebug], and I just tested the HAL Debug interface is active on my machine with:

SYS "OS_Hardware",65,,,,,,,,0,86

Sweet. I'll built a serial version tomorrow. ☺

Your comments:

Rick, 4th July 2014, 20:57

I ought to mention, I have put together three UNOFFICIAL builds of DADebug:    1. Normal, use in a TaskWindow  2. Command via TaskWindow, outputs to serial  3. Outputs to serial and dumps its debug buffer every minute    If you are debugging something complicated that needs to run without on-screen cues (or like a service call handler that cannot write out), you can use the timed-dump serial version. If the machine should crash, check if moue and/or Caps Lock work. If they do, just wait until the timer expires and your debug log should be output (yes, even if the machine has crashed, the CallEvery works off of an IRQ handler).    http://www.heyrick.co.uk/random/dadebug.zip