Raspberry pi serial port

Hi

If I use the simple code below on a beagle board I get serial output characters OK. When using the same code on the raspberry pi I get nothing out of pin 8 UART TX. I have tried different port numbers but with no success?.

Any Ideas
TIA

10 HAL_UARTTransmitByte=70
60 SYS "OS_Hardware",1,65,,,,,,,0,HAL_UARTTransmitByte
80 Q=INKEY(10)
81 PRINT "A"
90 GOTO 60
100 END

I’m not sure that drivers have been written for the Raspberry Pi’s serial port.
Or are you accessing the hardware directly?
Also AIUI RS232/RS423 uses 5V signalling, are you using level shifters?

Also AIUI RS232/RS423 uses 5V signalling, are you using level shifters?

Please, people, don’t make this mistake.

Pay attention now:

Serial running inside a microcontroller board is 0v (low) and +v (high) where high can be 1.8V, 3.3V, 5V etc as depending on the MCU. You will likely encounter this if your MCU’s I/O comes to a header with IIC, GPIO, Serial, etc etc on it.
This is usually fed into something like the MAX2232 chip to make it work with “the real world”.

TTL serial may be encountered. This is the same as above, but the high is more restricted (usually 4.7V-5.1V) so that it may interface with TTL logic. You may encounter this with certain typewriters, label printers and such that had peripherals designed to work specifically with that hardware. Otherwise, it isn’t so different to BBC Micro or ACIA serial in that it needs to be fed to a line driver (or MAX232) to make it work with “the real world”.

Here, we come to the RS-xxx protocols. These are the real world serial.
They swing both sides of the ground (0v) reference point so not only are they unsuitable for direct connection to processor or logic circuits, but they use voltage levels that are extremely unfriendly to them.
In short, if you wired an RS-something serial lead directly to your microcontroller’s serial lines, count in it never working again.

RS-423 is real world serial for the microcomputer generation. Logical low is represented by -5V and high by +5V. That’s a 10V swing. Many line driver chips could manage this from a 5V input so this was typically how it went. As a note on compatibility, RS-423 specifies an upper signalling level of +/-6V so will work with RS-232 equipment of similar characteristics, but would fail with some of the fruitier RS-232 setups. A mistake made by a fair few companies in the home micro days that said their serial ports were RS-232 but provided hardware that coped only with RS-423 level signalling.

RS-232 is worse. It is an older protocol, for connecting disparate terminals and such and some freaky ’60s era hardware. Typically RS-232 is between +/-5V and +/-15V (a swing of 30V); however the standard specifies that the smallest valid signal is +/-3V while the biggest valid signal is +/-25V (a swing of 50V).

I’m sure you can see why +/- 15V into a 3.3V signal is… a no-go.

You don’t want level shifters either for RS-432/232; you need a line driver (converts to/from the +/- swing).

Hi

Voltage is not a problem at the moment I am just looking at the output
using an oscillscope

just out of interest the output on the raspberry pi swings 0 to 3.3v
and the beagle board swings between 0 to 1.8

I have a beagle board running into a max232 using resistor dividers on the receive
pin to reduce the 5v to 1.8, the tx line connects directly to a max232 and switches
successfully because a standard MAX232 sees a high between 0.6 to 1.2v

Anyway it might mean I have to directly access the serial port but normally the serial
interface has been used when debugging RISCOS so I assumed that the low level
hal type calls would work but perhaps not?.

Actually thinking about it, as Adrian development and early demonstrations (before USB was implemented) were done using a keyboard connected via a PCs Serial Port, there must have been some support very early on!

n.b. The BeagleBoard and PandaBoard use 1.8v levels on their GPIO!

Terry,
Were you able to get any signal out of the UART TX yet? I’m looking to find a way to use MIDI through these pins myself.

I have been working mainly with the beagle board at the moment I will download the
new beta version and try that on Monday morning and let you know how I get on.

I’m looking to find a way to use MIDI through these pins myself.

Can’t [Beagle]; needs fiddling [RPi].

The MIDI specification says the serial link runs at 31.25kbps. The Beagle offers 28.8kbps and 38.4kbps (as it is divided down from a master timebase).

So, you’ll either need very tolerant MIDI hardware that works outside of the defined MIDI spec, or looking to talk to a PIC or similar via GPIO that then generates the 31.25kbps data stream.

I had a brief look at the OMAP3 TRM. It looks as if McBSP #5 can do MIDI, though I don’t know if its pins are accessible anywhere or otherwise used for alternative purposes. p3064 – p3223 describes it in brain-aching detail.

Things appear to be better on a RaspberryPi as you appear to be able to specify a custom timebase; so you slow the main UART clock down and then open serial comms at 38400bps (which is actually running at the slower MIDI speed by now). Details here: http://www.siliconstuff.com/2012/08/serial-port-midi-on-raspberry-pi.html It is for Linux, but a person with know-how might be able to offer some code to do the same under RISC OS. It is a better solution than a microcontroller, or (god help you) trying to bit-bang MIDI out of two GPIO pins!

It’s rPi I’m talking, sorry I didn’t clarify since the forum topic was rPi.. Yeah I’ve read this slowing (via config file) of the baud-rate but of course on Linux, and don’t know what is possible in RISC. I’ll start a new forum topic I guess, I corresponded with Tank and he said something about a pain-in-the-@ bit-bang (even though I dont know that term) as well.

Just A quick update I now have bytes transmitting out of the serial port
using the program at the start of this subject.

It seems I cannot change the serial BAUD rate?
I have tried using:-

HAL_UARTRate=73
rate%=9600
SYS"OS_Hardware",1,rate%*16,,,,,,,0,HAL_UARTRate

and

SYS"OS_SerialOp",6,0

None of the above seem to work

Just out of interest the SYS"OS_Hardware type call works on a beagle board
but the SerialOp does not work on a beagle board.

The raspberry seems to default to a fast baud rate I have not worked out the speed
but its probably 19200

Unless something’s changed SYS only uses registers 0-7 in BASIC. I use an assembler routine in BASIC to call OS_Hardware as you need access to registers 8 and 9.

I cant see that being the problem as the SYS commands
work OK on the beagle board.

SYS has passed registers R0 to R9 for a very long time, probably since RO3. The information in the PRM and Manual has been outdated for as long. My BASIC StrongHelp manual has the correct information.

Hmmm something has changed then. Anyway I looked at mixed/RiscOS/Sources/HAL/BCM2835/s/UART in cvs and it seems that HAL_UARTRate doesn’t do anything.

Just tried using the program from the first post and monitoring pin 8 with an oscilloscope I get one transmission speed.

Then, from the link Rick provided above, I add the following three lines to CONFIG/TXT:-

“# For MIDI
init_uart_clock=2441406
init_uart_baud=38400

Ignore the first quotes, I couldn’t get just a hash!

Reboot and run the same program. There is a definite reduction in bit rate and it looks of the right order, but I haven’t conducted an accurate measurement yet. Will have to dig out the DB50XG card! :)

Using Raspberry Pi with todays new release and nothing else changed yet.

My BASIC StrongHelp manual has the correct information.

And you can read it on Windows too ! :-)

I have written a little assembly / BASIC program to allow access to the Raspberry PI
serial port it allows the following :-
Set Baud rate 300,1200,2400,4800,9600,19200,57600,115200
Transmit and receive bytes
Its fairly simple to use and I have commented the code it is by no means
complete but if someone wants to try the serial port at different
baud rates it seems to work OK.

Just out of interest when setting the baud rate to 115200 the calculation
does not work I have added a little bodge to allow the setting at this faster speed
It may be that this speed is close to the maximum with FUART set to 3MHz whitch I believe
is the standard clocked speed for the UART.

I have not got access set up to the sources to RISCOS so cannot add the changes
but this little program might be useful until the sources are updated.
Download from www.mbelect.demon.co.uk/uart.zip

Just for the record, I tried the Pi_uart program this afternoon, writing to a Textstar LCD display ¹ at 9600 with Tx and Rx connected to GPIO pins 14 and 15. Worked first time without any problems at all. I’ll have a go at reading from it as well at some point.

¹ http://www.coolcomponents.co.uk/catalog/textstar-serial-display-p-428.html

I downloaded Terry’s program and it works ok but there’s seems to be an awful lot of assembly code in there.

I know it’s necessary to set up speed and format once but isn’t there an easier / quicker way to just send output data to the serial port ?

I see this command:
SYS “OS_Hardware”,1,65,,,,,,,0,HAL_UARTTransmitByte
But I’m not sure what it’s doing.

Thanks for any help.

Howard

Hi I’m afraid the assembly language is needed to allow
RISCOS to access the serial port directly , this is the sort of thing
That the operating system normally hides from you until someone
Updates the sources it’s the only way I know of accessing the serial
Port. The sys command will probably work but you would still need
Assembly to setup the baud rates at the moment.

SYS “OS_Hardware”,1,65,,,,,,,0,HAL_UARTTransmitByte

The above sys command sends bytes to the serial port in this
Case a capital A which is ASCII code 65 just change this value
To send different characters.

old thread resurrection !!
I am trying to write a module to access UART0 on the Pi.
I can set it up, add the interrupt routine, enable interrupts and receive data into an external buffer.
The only problem is I can only get the first character from the received data. This is then repeated until my external buffer is full.
This is with FIFO’s enabled. With the FIFO disabled, I only get the single character.
The only other thing I can now think of is the relationship between PCLK and UARTCLK.
I have tried various UARTCLK speeds (upto 100000000), but the PL011 manual states that the PCLK must be at most 3/5 least 5/3 of the UARTCLK for the reliable transfer of data from the holding register to the FIFO.
So, does anyone know the PCLK value ?
Is it changeable in the Config file ?
GOOGLE seems to not be my friend in this case…..

Running Terry’s program does work with the hardware I have connected, but does drop characters sometimes.

If anyone wants to see the source to find my mistake just look here

P.S the module is NOT registered yet, so I am using the same SWI numbers as my PCISerial module whilst testing.

Your figure for UARTCLK sounds more like what is used for init_emmc-clock.
http://elinux.org/RPi_config.txt
The default used for 115200 is 3Mhz and 100Mhz for the init_emmc_clock, though other pages have suggested 50Mhz for init_emc_clock.
Regarding Terry’s routine, I found the 38400 wasn’t working very good and set the speed with
IF baud%=38400:I%=4:F%=44
and got a better result.
I hope to try the PiSerial module soon.

Ronald,
I have tried a few different UARTCLK settings, as I thought the serial hardware may need to run faster to allow the FIFO to collect the data reliably, but it seems PCLK is as important as well.
The code Terry uses to calculate the I% and F% values is as shown on the BCM2835 datasheet, but on the PL011 datasheet, this is the calculation

sum=UARTCLK/(16*baud%)
I%=sum
F%=((sum-I%)*64)+0.5

and this gives you I%=4 F%=57

By the way, I can now get the first 16 characters of data but then it drops a bunch before getting more……

Well, one moment of clarity and BOOM…. I now get all my data as expected !!

I now have a Current Cost Envi CC128 connected to the Pi and an app that presents the data.
So RX works fine.
TX I think works, but I cannot test as easily ATM.

here is the source and a !SerialDev so if anyone could test it and pass any problems back to me.

Not yet working are DRIVER_CONTROLLINES, DRIVER_MODEMCONTROL, DRIVER_WORDFORMAT, DRIVER_FLOWCONTROL.

The format is set at 8 bit no parity.

When I have it fully working, should this be a module that I register myself, or should it be changed and added to the ROM build as the standard serial port ?