Serial port on Beagleboard

Hi

First of all I would like to thank everyone that was involved in the creation of RISCOS for the beagleboard.

I have been trying to use the serial port with the basic program below, I get no output on the terminal window but if I press F12 and then return I get random characters on the terminal screen which is strange.

I know that the serial port works because when the beagleboard boots up I get the bootup standard text.

I am using the beagle rom dated 2010-11-13

REM SYS”OS_SerialOp,0,180,0 SYS “OS_SerialOp”,0,44,0 SYS “OS_SerialOp”,1,0 : SYS “OS_SerialOp”,6,4 :REM 1200 baud SYS “OS_SerialOp”,3,65 :REM output A SYS “OS_SerialOp”,3,13 :REM output 13

It may be that RISCOS cannot talk to the serial port yet in which case I will try and program it directly.

Thanks in advance

Terry

At the moment the main use of the serial port is for getting debug messages from the HAL/RISC OS. For a number of reasons this uses its own custom code rather than going through the standard RISC OS serial drivers.

Code does exist to allow RISC OS to use the serial port via OS_SerialOp, but I haven’t tested it yet, so it’s possible that there’s a bug or two that’s stopping it from working. In fact my own experience with using OS_SerialOp to access the serial port of a RiscPC or Iyonix has been quite mixed, so when I do get round to testing the Beagleboard code I’ll first have to sit down and work out how to use OS_SerialOp properly in the first place!

• Even if OS_SerialOp did work, you’d have to put up with the occasional bit of debug output generated by RISC OS. At the moment I think the only bit of debug output you should normally see is from the video driver when you change screen mode. If that’s going to be a problem for you then let me know and I can work out a solution.
• The serial port on the beagleboard is a simple 3 wire affair – RX, TX, and ground. So some settings (e.g. hardware flow control) won’t work. If that’s a problem for you then I think there’s an extra serial port on one of the expansion headers which has more signals available. Although I think you’d need a level shifter to be able to use it (or you can buy a ready-made expansion board). And of course the extra serial ports have had no testing under RISC OS whatsoever :)

Someone in this forum has posted about using FTDI USB-Serial bridge solutions. As far as I remember he claims that it works. I just tried a quick search in the forum but could not find it. I’ll look again.

Got it! HTH.

http://www.riscosopen.org/forum/forums/5/topics/122

At the moment the main use of the serial port is for getting debug messages from the HAL/RISC OS. For a number of reasons this uses its bq. own custom code rather than going through the standard RISC OS serial drivers.

Ok no problem at least I know whats going on :-)

Code does exist to allow RISC OS to use the serial port via OS_SerialOp, but I haven’t tested it yet, so it’s possible that there’s a bug bq. or two that’s stopping it from working. In fact my own experience with using OS_SerialOp to access the serial port of a RiscPC or Iyonix bq. has been quite mixed, so when I do get round to testing the Beagleboard code I’ll first have to sit down and work out how to use bq. OS_SerialOp properly in the first place!

Funny you should say that! I didnt have much luck with SerialOp when trying the BASIC code on an Iyonix which is why I posted here because I could not tell if it was a software or hardware problem maybe a bit of both :-)

I only need a very simple serial port, only using the basic three wires all handshaking is achieved through software. I cant see the video change being a great problem.

Looks like I am going to be looking at section 17 of the spruf98k file for details of the addresses of the UARTs so I can program them directly for now. any pointers you have regarding this would be greatfully received.

I am also looking at accessing the GPIO pins I have had a quick look at CPUspeed which seems to show a way of mapping in external memory and accessing it from RISCOS, I program micro-controllers for a living and have some knowledge of RISCOS but have never used the two at the same time :-)

anyway thanks for the replies.

Terry

If I want a simple BASIC program to work with the serial port I something like Connector to set the serial port up (baudrate etc). Quit it and just use the SerialOp calls to read and write bytes.

Its a bit of work to set all the registers to the correct values to get the serial port starting, this way, you can just skip that.

Good luck, Peter

Looks like I am going to be looking at section 17 of the spruf98k file for details of the addresses of the UARTs so I can program them directly for now. any pointers you have regarding this would be greatfully received.

If you want you could try using the HAL calls directly via OS_Hardware

E.g. HAL_DebugTX and HAL_DebugRX are the two calls used for all the debug I/O. Or there’s the HAL UART API, which is the one that RISC OS uses for its serial I/O (when it works!). The OMAP3 code for that was basically just a copy and paste of the Iyonix code, so if you make the calls directly you might find that they work and that it was just OS_SerialOp being stubborn.

Just to give some feedback the calls via OS_Hardware seem to work well TXing bytes via the serial port.

BUT…

SYS “OS_Hardware”,,,,,,,,,0,65 TO numports Returns 3 on the beagle board Returns 1 on the Iyonix ?

To get any output from the Iyonix I have to use the serial port labelled 2

SYS “OS_Hardware”,port,65,,,,,,,0,70 :REM TX “A”

the port setting on the Iyonix seems to be ignored all output goes out on the second serial port connector regardless.

On the Beagleboard the port setting seems to have an effect

port=0 gives output on the terminal program port=1 give no output (i assume that the second port is being used,not tested)

Since I only intend to use these commands on the Beagleboard everything seems to work well I have included the Iyonix details in case they are useful to someone.

Anyway many thanks for your help I am now going to delve into GPIO access.

Alternatively, you can use DeviceFS. E.g. run this sort of program in a Task Window:

  REM Error handling
  in% = 0
  out% = 0
  ON ERROR PROCerror

  REM Flush some buffers
  *FX 7 8
  *FX 8 8

  REM Identify the hardware platform and open serial input and output streams
  SYS "OS_Byte", 129, 0, 255 TO , hw%
  IF hw% < &AA THEN
    REM Pre-Iyonix uses serial
    in%  = OPENIN"devices#baud19200;sleep:$.Serial" 
    out% = OPENOUT"devices#baud19200;sleep:$.Serial" 
  ELSE
    REM Iyonix uses serial1 - Iyonix has dual serial
    in%  = OPENIN"devices#baud19200;sleep:$.Serial1" 
    out% = OPENOUT"devices#baud19200;sleep:$.Serial1" 
  ENDIF

  REM Create a buffer
  DIM buf% 256

  REM Send something
  $(buf%) = "hello" 
  SYS "OS_GBPB", 2, out%, buf%, LEN $(buf%)

  REM Receive something (a byte)
  SYS "OS_GBPB", 4, in%, buf%, 1

  REM Or (untested) poll for input
  WHILE NOT EOF#in%
    PRINT GET$#in%
  ENDWHILE

  REM Close the streams
  CLOSE#in%
  CLOSE#out%
  QUIT

  DEF PROCerror
    ON ERROR OFF
    PRINT'REPORT$" at line ";ERL
    IF in% THEN CLOSE#in%
    IF out% THEN CLOSE#out%
    QUIT
  ENDPROC

This code is untested. Try at your own risk! :)