FullDuplexSerial: bit of a head-scratcher re: rxcheck

Mickster · 2013-06-07 02:34

I have a very simple loop where I am transmitting data to my Android device via RS232 and a Bluetooth adapter.

Although not currently receiving data, I have provided for it and it works very well, the following is in the same loop:

Case MC_Com.rxcheck
         -1:
         "A": 
              
         "B": 
              
         "C": 
   
etc., etc.

The problem is that when I disconnect the bluetooth link, using the menu selection "Disconnect" on my Android device, the Propeller programs stops looping.

If I remove the above ".rxcheck", the lockup doesn't occur, the Propeller program continues to loop and when I re-establish the BT connection using the menu selection "Connect" on my Android device, the Android program resumes receiving the transmitted data from the Prop.

Clearly something is upsetting the .rxcheck routine but the comments state that:

'' Check if byte received (never waits)
'' rxbyte returns -1 if no byte received, $00..$FF if byte

Any ideas would be appreciated.

Regards,

Mickster

SRLM · 2013-06-07 02:43

Can you post full source?

Some bluetooth modules send out characters when a connection status changes (ie, a status message). Maybe these characters are interfering with your routine?

Coley · 2013-06-07 05:30

Hi Mickster,
Why not insert some debug code to transmit via your prop plug to Parallax serial terminal (PST)?
You could start with adding other: to the case statement and tx out to the PST....
Is this the code for my board? I'll be happy to help if you set me up with the android app I have a couple of Bluetooth adapters.
Regards,
Coely

Mickster · 2013-06-07 06:06

@Coley: Yup it's your board and I just stripped-out the Pio and encoder reading objects to post the bare loop and, wouldn't you know it, the bare loop DOESN'T crash when I disconnect the BT. The loop WITH the other objects does crash unless I prevent the call to .rxcheck.

So the following DOES keep running, no matter what....let me include the other stuff, a bit at a time and I'll post the code that crashes.

CON
  _clkmode = xtal1 + pll16x
  _clkfreq = 80_000_000


  
  RS232RX_2     = 24
  RS232TX_2     = 25
  
  LED_1         = 27 ' LED 1
  LED_2         = 26 ' LED 2


  Mode          = 00
  Baud          = 19200
  BT_TimeOut    = 1000000


VAR
  long Scheduler,CntMem,BT_WatchDog
  byte GetOut,MainStop
  
OBJ


  MC_Com        : "FullDuplexSerial" 
  
PUB Start | char , rxchar, starttime, endtime


  MC_Com.Start(RS232RX_2,RS232TX_2,Mode,Baud)           


  'Term.rxflush
  MC_Com.rxflush    


    
  DIRA[LED_1..LED_2]~~                                                          ' Set LED1 and LED2 to be outputs
  OUTA[LED_1..LED_2] :=                                                      ' Turn on LED1


  
  Repeat 10
    !OUTA[LED_1..LED_2]                                                         ' Flash LED1 and LED alternately 10 times
    waitcnt(cnt+clkfreq/30)


  OUTA[LED_1..LED_2]~                                                           ' Turn off both LED's


  Scheduler:=0
  
  MainStop:=0
    
  Repeat until MainStop                                                                      
    Scheduler++
    Case Scheduler
        500:
               
        3500:!Outa[Led_1]
                
        3600:Scheduler:=0
             ++BT_WatchDog
             BT_WatchDog<#=BT_TimeOut
             MC_Com.str(String("DATA"))
             MC_Com.dec(BT_WatchDog)
             MC_Com.str(String(";"))
             
    
    Case MC_Com.rxcheck
         -1:
         "A": 
              
         "B": 
              
         "C": 
              
         "X": MainStop:=1
         
         Other:MC_Com.tx("?")

Thanks guys.

Regards,

Mickster

P.S. I already suspected that I could be getting a random "X" character which would also kill the loop but I already ruled this out.

Mike G · 2013-06-07 06:28

Do you need a pullup on the Propeller Rx line?

Mickster · 2013-06-07 07:28

Hmmm, I appear to have found the cause but it's still a bit of a puzzler:

As you can see, if the characters A or B or C (it actually keeps going through to H) appear then "GetBendData" is called. My current testing involves receiving nothing so this routine is never called. However, when I break the bluetooth link, "GetBendData" gets called and the hangup occurs because that next repeat loop won't quit until a ";" is received.

If I REM-out all of the calls to GetBendData, I can connect and disconnect without problems but if I un-REM ANY of the GetBendData calls, the program will call it when I disconnect the BT communication.

 Case MC_Com.rxcheck
         -1:
         "A": 
              GetBendData
              Bend[0]:=BendData
              MC_Com.dec(Bend[0])
              
         "B": 
              'GetBendData
              Bend[1]:=BendData
              MC_Com.dec(Bend[1])
              
         "C": 
              'GetBendData
              Bend[2]:=BendData
              MC_Com.dec(Bend[2])


PRI GetBendData
    BendData := 0
    GetOut := 0
    waitcnt(clkfreq/500+cnt)
    repeat until GetOut == 1
      case MC_Com.rxcheck
         "0": BendData := BendData * 10
         "1": BendData := BendData * 10 + 1
         "2": BendData := BendData * 10 + 2
         "3": BendData := BendData * 10 + 3
         "4": BendData := BendData * 10 + 4
         "5": BendData := BendData * 10 + 5
         "6": BendData := BendData * 10 + 6
         "7": BendData := BendData * 10 + 7
         "8": BendData := BendData * 10 + 8
         "9": BendData := BendData * 10 + 9
         ";": GetOut := 1

I will experiment further.

Regards,

Mickster

Mickster · 2013-06-07 08:37

Quick, before someone else points out my stupidity.....it's the darned AT commands isn't it!

Just so happens that they coincide with my Case conditions...DOH!, DOH!, DOH!

I'll get me coat :-)

Regards,

Mickster

FullDuplexSerial: bit of a head-scratcher re: rxcheck

Comments