Using two serial ports.....

Potato · 2010-03-09 07:13

I am writing a program which uses TWO serial ports, One Port is connected to Pins 31 and 30 and is used to debug and monitor the program. The other port uses pins 5 and 6, they are connected to a RS232 level converter and talk to a PC using the PC's serial port. I am now using FullDuplexSerialPlus.spin. to talk to Parallax Serial terminal using pins 31 and 30 (works great). I am using simple serial to talk to the PC through pins 5 and 6. I can send characters to the PC (works great).
The problem is, when I want to get characters from the PC SimpleSerial blocks my calling code until a byte is received. This brings my program to a halt until the PC sends a character. I need to use FullDuplexSerialPlus so I can use its buffering ability. If no character is sent by the PC, my program needs to continue on. My program will check it again, after doing some other tasks (Loop). Can I use two instances of FullDuplexSerialPlus? Do I need to use two if the only difference is the pins which are used (the baud rate of the PC and Parallax Serial Terminal are the same). What would you do?

Thanks for your input.

P.S. I guess we could say WWCD (What Would Chip Do)

Peter Jakacki · 2010-03-09 07:42

Just declare the two objects using the same object file and use them just as you would normally. There is an object that can handle 4 serial ports in the one cog if you prefer but try FullDuplexSerial first and get it functional.

obj
   com1 : "FullDuplexSerial"
   com2 : "FullDuplexSerial"

pub demo
   com1.start(31,30,0,19200)
   com2.start(5,6,0,19200)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

MagIO2 · 2010-03-09 08:10

Instantiating FullDuplexSerial twice means that you need 2 COGs. There is a Object in the Object exchange which gives you up to 4 serial interfaces with one COG. So, if your project is bigger or might grow, you should better use that from the beginning.

Peter Jakacki · 2010-03-09 08:31

@MagIO2: The point about using something that is more familiar to a beginner from the beginning is so that they can begin. The 4-in-1 object is different enough in it's initialization and use that it might cause a problem understanding how to get it to work. However after progressing from SimpleSerial to FullDuplexSerial AND getting it stable the next hop can be much easier for a beginner.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

MagIO2 · 2010-03-09 10:38

I only wanted to mention it. I like to give answers which also tell people what effects/side-effects the given suggestion has.

What makes you believe that Potato is such kind of a beginner that can't cope with that other object? He's a retired engineer ...

Peter Jakacki · 2010-03-09 12:36

Well it's the type of question plus the fact that we are all beginners at something no matter how much experience we have in other areas. So if someone is wading around in shallow waters (SimpleSerial) and asking about what it's like in the deeper end we could say from our point of view "great, jump in", but somebody would have to fish them back out again. So much then for our advice.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

Dr_Acula · 2010-03-09 12:51

Nah, wade right in and if the tide comes in a bit fast, run like hell!

I've been using this brilliant bit of code by Tim Moore for many months now obex.parallax.com/objects/340/

One cog.

4 serial drivers in one object. 64 byte buffers for each serial port, so plenty of time to read in bytes and process them when you are ready. And if you want, very easy to add a few lines of spin to test for a byte without reading it (I can help you with that if you need it).

This is pretty simple to use.
define the object in a OBJ section of code

  UART          : "pcFullDuplexSerial4FC"    ' 4 port serial driver in one cog.

set it up at the beginning of the code

   UART.AddPort(0,31,30,-1,-1,0,0,19200)                 ' set up port 0 at 19200 on pins 31,30
   UART.AddPort(1,25,24,-1,-1,0,0,1200)                 ' set up port 1 baud 1200 on pins 25,24
   UART.Start ' start the object

Send a byte

uart.tx(1,65) ' send A to port 1
uart.tx(0,66) ' send B to port 0

get a byte

    io_data := UART.rx(0)                                  ' get the byte from port 0

test for a byte

  if UART.rxavail(1)
    io_data := UART.rx(1)                                  ' get the byte from port 1

and all ports work independently and nothing hangs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

Post Edited (Dr_Acula) : 3/9/2010 12:59:17 PM GMT

Peter Jakacki · 2010-03-09 13:02

See drac, deeper water, now you have to keep holding his hand

I know there is the sink or swim approach to learning but trouble is, some sink.

But you are right, it's a brilliant bit of code that I have used myself for lower speed serial coms especially when I've been short on cogs (what, only 8 cores!).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

Dr_Acula · 2010-03-09 13:26

Yea, I know Peter. Now I'll have to stay up all night waiting for a response. 'tis only 11:57pm here...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

MagIO2 · 2010-03-09 14:11

you just have to keep the propeller hat upwards and it's impossible to sink ;o)

kwinn · 2010-03-09 14:19

I have to agree with Dr_Acula. If you can figure out FDS then the 4 port serial object is not much if any harder to understand. All of the functions (rx, rxtime, rxcheck, tx, str, etc) that the other objects have are there as well. After initialization the only real difference is that the commands have to specify which of the 4 ports to use.

Potato · 2010-03-09 15:17

It Works ! Thank You, Thank You, Thank You...

I decided to go wading first, so now off to the deep end of the pool !

Using two serial ports.....

Comments