need SERIAL COMM prop to prop finished code

stargazer2050 · 2014-04-09 14:27

Quickstart boards X2
Would like to hook them together serially with wire

Have been using 3 i/o parallel for a year bec. cant understand first thing about serial.
Tried simple serial, fullduplecserial, etc. makes no sense.
Bought xbees, got them today and they work already (need to get three digits or just two digits to transfer.)

Requesting clockloop to post his solution now please!

JonnyMac · 2014-04-09 15:07

Using FullDuplexSerial in half-duplex mode is very easy -- but only if you'll dig in a little and give it a try.

serial.start(SIO, SIO, %1100, BAUD)

This uses "open true" mode so you need to add a pull-up (3.3K suggested) between 3.3v and the serial IO line (one side will do). It's best to let one side control the conversation, but using open mode will prevent an electrical issue if both sides try to "talk" at the same time.

If you've got a BASIC Stamp manual nearby have a look at the SERIN and SEROUT commands; there's a great explanation of the use of open baud modes.

stargazer2050 · 2014-04-10 15:35

Hi jm, ill set this up. Half duplex eh?
Got the stamp manual, dont know that i can get anywhere with it though.
Am using xb.rxtime(250) on xbee, switch it to serial.rxtime() ?
Turns out xbees are way slower than my 3 io asynchronous parallel because of bootup time.
Im using pulsing on each pin and just counting them with a debouncer. Might try your freq_counter.spin to speed that up.

JonnyMac · 2014-04-10 15:48

If you can use two pins then go full-duplex. I still recommend open baudmode as this saves the system from a programming accident.

Note that if you use .rxtime() with a parameter of 250, you system could wait up to 250 milliseconds for a response. That seems like a lot of time.

stargazer2050 · 2014-04-10 18:24

The three io's are 3.3k series and 10k grd.
Comm is one way so far

Ill lower the 250, see what happens.

JonnyMac · 2014-04-11 08:57

If you've got resistors in the line you can use driven mode and not have to worry about accidents. Just make sure that the TX pin on one connects to the RX pin on the other and vice-versa.

Clock Loop · 2014-04-12 03:49

stargazer2050 wrote: »

Quickstart boards X2
Would like to hook them together serially with wire

Have been using 3 i/o parallel for a year bec. cant understand first thing about serial.
Tried simple serial, fullduplecserial, etc. makes no sense.
Bought xbees, got them today and they work already (need to get three digits or just two digits to transfer.)

Requesting clockloop to post his solution now please!

In the message, I specifically stated that you need to:
Include the FULL code you need help with.

Johnny mac is right, you shouldn't use xb.rxtime(250)
Change it to

repeat
   variable := xb.rxtime(1)

And have your program repeat attempts at getting data.

Or make it wait forever.

repeat
   variable := xb.rx

Also, how are you getting the data?
you don't show that you are putting the data anywhere, you are just doing this--> xb.rxtime(250)

This is the correct way to get data from the serial object and place it into a variable, and also i put in a REPEAT, to make repeated attempts at getting the data in case the first one didn't work.

repeat
    variable :=  xb.rxtime(250)

With out you posting your full code, you will NOT get the kind of help you are requesting.

JonnyMac · 2014-04-12 07:41

When you're using .rxtime() you need to validate the returned value; it it's 0 or higher it's a character, if it's -1 then the method timed-out.

stargazer2050 · 2014-04-13 04:21

Hi jm and clock loop
im getting a number on the screen of 65525 or FF or 11
still unclear how to visualize learning this.

Q1 is it safe to turn on the Monitor and USB and be on pins 30 and 31?
or does this happen on 20 and 21?

CON 
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
    #1, HOME, #8, BKSP, TAB, LF, CLREOL, CLRDN, CR, #16, CLS      ' PST formmatting control   
OBJ
  term    :  "FullDuplexSerial"
  serial  :  "FullDuplexSerial"  
  rcTime  :  "RCTime"               'qti          '
VAR
  LONG MONstack[30]
  Long RCValue
  Long rxtime
  Word QTI1
  Word TXvar
  Word RXvar
  Word flowvar
  Word Value

PUB Main
  flowvar := 2
  
  if flowvar == 1
     P1serial
  elseif flowvar == 2
     P2serial
  
PUB P1serial
  term.start(31,30, 0, 9600)
   
  repeat
    term.tx(Home)
    term.tx(CLS)
    rcTime.rctime(8, 1, @RCValue)   'QTI
    QTI1 := RCValue/100
    term.str(string("QTI1"))    
    waitcnt(clkfreq/10 + cnt)  

PUB P2serial
   'term.start(21, 20, 00, 9600)
   term.start(31,30, 0, 9600)             'the input wires from P1 are swapped
   repeat
    term.tx(Home)
    term.tx(CLS)   
     RXvar := serial.rxtime(1)
       if RXvar > -1
          QTI1 := RXvar
          'QTI1 := QTI1/1000
          term.str(string("QTI1"))    
          term.str(string("   "))
          term.dec(QTI1)
          term.str(string("   "))
          term.dec(QTI1)
          term.str(string("   "))    
          term.hex(QTI1,2)
          term.str(string("   "))    
          term.bin(QTI1,2)
  'repeat
  '  RXvar := serial.rx         'repeat forever
    WaitCnt(ClkFreq / 40 + Cnt)

JonnyMac · 2014-04-13 08:23

In my opinion you should not use the Propellers programming pins (P31 and P30) for anything but debugging.

What are you trying to accomplish? Blindly throwing serial data around is not helpful. You should establish a protocol (even a very simple one) so that you have a set of rules for both sides. Not knowing what you want to accomplish, I can't suggest anything further.

stargazer2050 · 2014-04-13 10:55

Thats good, so i should stay the heck off 30 and 31
So you cant just connect two computers an read rx tx back and fo rth.
Ill stick with my simple thing.

Tnx again

JonnyMac · 2014-04-13 12:33

It's best to stay off P31 and P30 as you need those for downloading a new program. That said, some people do in fact use them -- I don't (except for programming and debugging). It's no sweat at all to define a second set of serial pins. With the pins you already have you end up with bidirectional communications. The additional up-side is that FDS and other serial drivers buffer the input so your program can be busy doing something else while serial data is moving in and out.

stargazer2050 · 2014-04-14 04:58

simplifying, now just sending a '3'
am receiving a '96' with the monitor turned on with 30 and 31 on that cognew AND
theres a '3' hidden behind it but can't figure where its coming from or what a '96' is

CON 
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
    #1, HOME, #8, BKSP, TAB, LF, CLREOL, CLRDN, CR, #16, CLS
    
OBJ
  term    :  "FullDuplexSerial"
  serial  :  "FullDuplexSerial"  
VAR
  LONG MONstack[30]
  Long rxtime
  Word RXvar
  Word flowvar
PUB Main
  flowvar := 2
  
  if flowvar == 1
     P1serial
  elseif flowvar == 2
     P2serial
  
PUB P1serial
  serial.start(21,20, 0, 9600)
  'serial.start(21, 20, %1100, 9600)
   
  repeat
    serial.tx(3)
PUB P2serial
   cognew(Monitor, @monStack)
   waitcnt(clkfreq / 25 + cnt)
   'serial.start(21, 20, %1100, 9600)     'input wires from P1 are swapped
   serial.start(21, 20, 0, 9600)
   repeat
     serial.tx(Home)
     serial.tx(CLS)   
     RXvar := serial.rxtime(1)
     ' RXvar := serial.rx
       if RXvar > -1
       '   if RXvar == 3
             serial.dec(RXvar)
        
      'repeat
      '  RXvar := serial.rx         'repeat forever
      '  serial.dec(RXvar)        
     WaitCnt(ClkFreq / 40 + Cnt)
PUB Monitor
  term.Start(31, 30, 0, 9600)
   repeat
     term.tx(HOME)
     term.tx(CLS)
     term.dec(RXvar)
     WaitCnt(ClkFreq / 40 + Cnt)

JonnyMac · 2014-04-14 08:16

When I use a serial object, I do these things:

-- start the object
-- wait a few ms to let everything get going
-- flush the receive buffer

It's possible that the extra value you're seeing is trash in the buffer from start-up.

Have a look at this:

PUB P1serial
  serial.start(21,20, 0, 9600)
  'serial.start(21, 20, %1100, 9600)
   
  repeat
    serial.tx(3)

If you think about what's happening, you're filling the transmit buffer with 3 and never letting up. If you want two devices to be able to talk back and forth, you need to give each side some breathing room. In the MODBUS RTU protocol, for example, they use 3.5 byte periods of no traffic to define the space between messages. When the receiver sees this idle period it nows that the next byte in is the start of a message.

JonnyMac · 2014-04-14 08:24

Consider something like this:

pub main | c

  ' master side

  term.start(RX1, TX1, %0000, 115_200)
  serial.start(RX2, TX2, %0000, 9_600)
  pause(10)

  term.rxflush
  serial.rxflush

  repeat
    repeat c from "0" to "9"
      term.tx(c)
      serial.tx(c)
      waitcnt(cnt + clkfreq / 10)
      
    term.tx(CR)  
    serial.tx(CR)

pub main | c

  ' slave side

  serial.start(RX2, TX2, %0000, 9_600)
  term.start(RX1, TX1, %0000, 115_200)
  pause(10)

  serial.rxflush
  term.rxflush

  repeat
    c := serial.rxtime(1000)
    if (c < 0)
      term.str(string(CR, "Timeout", CR))
    else
      term.tx(c)

... just to start to get the hang of communicating between two Propellers. Once you get this, then you can put together a command/response packet.

stargazer2050 · 2014-04-15 05:52

hi, i notice if i send the dec command, the numbers roll through on the other side nicely
Q1: how do I assemble them into a "dec" on the other side? multi digits

  repeat 
     term.tx(Home)
     term.tx(CLS)    
     term.dec(631)                
     serial.dec(631)
     waitcnt(clkfreq / 10  + cnt)

JonnyMac · 2014-04-15 11:40

It's not hard to do but you must have a delimiter (non-digit character). Why send values that are formatted for humans to read when the other side is a machine? You're just creating extra work for yourself.

I'm repeating here, but once you create a protocol (i.e., define what you want to send back and forth), it will be easier to show you some code. I tend to stick with long values, but you don't have to -- but your receiver needs to know what to expect. For example, sometimes I do this:

pub tx_number(number, nbytes) : b

  repeat nbytes
    serial.tx(number.byte[b++]

This lets you send numbers (binary form) in Little Endian format. Again, the receiver side needs to know what's coming.

stargazer2050 · 2014-04-15 13:23

Hi, last one might be too rich for me blood.
But i notice i can receive ascii hex 2 digits and use that would give me plenty.

So thankyou so very very for getting my serial knowledge up 'n running!!!

need SERIAL COMM prop to prop finished code

Comments