Question about FullDuplexSerial (from obex by Chip Gracey, Jeff Martin)

Comments

• kuroneko Posts: 3,623

  2011-06-27 19:10 edited 2011-06-27 19:10

  What is this rxcount method you speak of? Said object doesn't have one of those ...
  
  Also, you're using tmp1 >= $00 which isn't a comparison (greater or equal). In SPIN that's an assignment (like +=). You want tmp1 => $00.
• marzec309 Posts: 146

  2011-06-27 19:52 edited 2011-06-27 19:52

  As pulled from my version of FULL DUPLEX SERIAL, I don't ever remember adding it.
  

  PUB rxcount : count
  
  '' Check for bytes in receivebuffer (never waits)
  '' returns the number of bytes 
  
    count := (rx_head - rx_tail) & 15
    if count == 0
      count := -1
  
• kuroneko Posts: 3,623

  2011-06-27 20:18 edited 2011-06-27 20:18

  I'm still a bit fuzzy as to what the exact problem is. Did you fix the operator issue? Also, not having this method available I used something like this:

  CON
    _clkmode = XTAL1|PLL16X
    _xinfreq = 5_000_000
  
  OBJ
    serial: "FullDuplexSerial"
  
  VAR
    byte  Buff[32]
    
  PUB null | tmp0, tmp1
  
    serial.start(31, 30, %0000, 115200)
    
    dira[16]~~
    dira[17]~~
  
    tmp0~
    
    repeat 6
      outa[16]~~
      outa[16]~
      repeat
        outa[17]~~
        outa[17]~
        waitcnt(cnt + clkfreq / 10000)
      until (tmp1 := serial.rxcheck) <> -1
      Buff[tmp0++] := tmp1
  
    repeat tmp0 from 0 to 5
      serial.tx(Buff[tmp0])
      
  DAT
  

  This demo stays in the inner loop until it gets a character then breaks out, stores it and repeats. After having collected 6 characters it sends them back through the serial link. HTH
• marzec309 Posts: 146

  2011-06-27 20:35 edited 2011-06-27 20:35

  I give your use of rxcheck a try and thanks for spotting my operator typo. My problem is that my code as posted earlier, wouldn't wait in the loop with rxcount. it seem to time out @ 1mS, I'm debugging with a logic analyzer, thus explaining the outa[] in each repeat cycle. It would enter the inner most repeat and stay put for ~1mS then drop out before it receive a byte.
  
  Thanks
• kuroneko Posts: 3,623

  2011-06-27 20:41 edited 2011-06-27 20:41

  I admit the behaviour is puzzling. Do you have a way of tracing rxcount (to serial) when it apparently forces the loop to exit?
  
  For the sake of it I added an rxcount method and ran this test

  repeat
      !outa[16]
      waitcnt(cnt + clkfreq / 10)
    until serial.rxcount > 0
  

  Which stays in that loop until I press a key.
  
  Does your serial link work otherwise, i.e. do you get what you expect from normal interactions with a terminal?
• marzec309 Posts: 146

  2011-06-28 19:14 edited 2011-06-28 19:14

  I found the gremlin causing my troubles. After trying your code, the loop was still falling through prematurely. After, I started to dig around else where, found the problem in the call to serial.start(rx,tx,mode,baud), i was setting mode with 1, not realizing it wanted four bits, like you set it on your call. No more falling through the loop YAY.
  
  thanks Kuroneko