Receive errors on Debug port using "fullDuplexSerial4port.spin" with 2 RX ports and 1 TX port

lab_ges

I am a new user to the Propeller processors (but have done some programming in PICs in the past) and am having a problem with a Serial data program I am writing on a Propeller Development board. Hopefully someone here might be able to help me with a steep learning curve.

Given the number of serial ports involved I thought that "fullDuplexSerial4port.spin" could be useful.

Briefly my development board has the standard Debug serial port + 2 other Receive only serial ports.
My aim is to receive 9600 baud data (at 1hz for the moment) on 2 lines and then send both those "strings" out to the Debug port.
Eventually I want to combine these 2 strings into a single string but that's for later.

I have tried various things but in all cases I end up with rubbish data between the real data.

Sending any ASCII out to the Debug (or the other 2 ports for that matter) works fine, so the problem would appear to be with reading data in from the 2 incoming ports.

I stripped my program down to bare bones, IE. RX one string one character at and time and then output those characters straight to the Debug port but only the first string seems OK the rest have a heap of "FF" hex bytes before / after each genuine data packet.
It looks like this in Parallax serial terminal or Real Term (I can copy and paste from Realterm), the following is what I am getting, it just repeats.

starting... 
                                                                  
starting... 
                                                                  
starting... 
                                                                  
starting... 
                                                                  
starting... 
                                                                  
$ 45678.901,1234
                                                               
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ$ 45678.901,1234
                         
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ$ 45678.901,1234
        
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ$ 45678.901,1234

The number of "FF" at the start varies a bit but the latter ones seem to have about 850 odd "FF"'s.
I am guessing this must be related to garbage filling the buffer somehow but can't explain how, I am not sure ;(
Below is the coded I use to generate the above, nothing here is original, I "borrowed" from several programs shown here on the forum.

CON
        _clkmode = xtal1 + pll16x   ''Set PLL = x16 
        _xinfreq = 5_000_000        ''Crystal 5.0 Mhz ;Thus System Freq. =16x5=80Mhz

  '' Pin asignments
  _LedPin = 3                   ' Indicator LED

  _RxApin = 4                   ' RxCM[P3] Data from Cm221
  _TxApin = 5                   ' TxCM[P2] Send to Cm221
  
  _RxBpin = 6                   ' RxALT[P10] Altimeter RX Data 9600 bd
  _TxBpin = 7                   ' TxALT[P8] <won't normally use >
    
  _DebugTxPin = 30              ' Debug / programming port 
  _DebugRxPin = 31              ' Debug / programming port

  _Debug = 0      ' DEBUG port number, for FullDuplexSerial4port 
  _A = 1          ' Serial "A" port number, for FullDuplexSerial4port
  _B = 2          ' Serial "A" port number, for FullDuplexSerial4port

  
  _CR = 13
  _LF = 10
  _SP = 32

  _Baud = 9600

   
VAR

  byte char1
  byte char2
  
OBJ

  Com0 : "fullDuplexSerial4port.spin"
  Led1 : "Flash"                                         ' uses one cog (not really needed)

  
PUB Main 

  Led1.Start(_LedPin, 150, 0)                            'Status LED blinks to show Propeller is working

  '' AddPort(port,rxpin,txpin,ctspin,rtspin,rtsthreshold,mode,baudrate)  
  Com0.Init 

  Com0.AddPort(_Debug, _DebugRxPin, _DebugTxPin, -1, -1, 0, 0, _Baud)     'Debug Port (Console)   
  Com0.AddPort(_A, _RxApin, -1 , -1, -1, 0, 0, _Baud)                     'We only need to receive 
  Com0.AddPort(_B, _RxBpin, -1 , -1, -1, 0, 0, _Baud)                     'We only need to receive 

  Com0.Start
  
  pause(3000)
  
  repeat 5                                                       'do it 5 times so I can see it on comms program
    Com0.str(_DEBUG,string("starting... ",_CR,_LF))              'sends string to _Debug
    pause(100)                                                   'wait 100ms

  repeat
    repeat                                                 ' read Data string from Port data and send it out to Debug  
      char1 := Com0.rxCheck(_A)                            ' non-blocking, read input port      
      if char1 <> -1                                       ' -1 is no character, otherwise ascii code of character
          Com0.tx(_DEBUG,char1)                            ' so send it right out the debug port
    until char1==_CR
    Com0.rxflush(_A)    


PUB pause(ms)
  waitcnt(clkfreq/1000*ms + cnt)
          

I even tried to flush the serial buffer {Com0.rxflush(_A) line above} but that did nothing usefull.

Can anyone see what I am doing wrong?
It is probably obvious to those with experience in this area but I have been unable to make any progress with this.

Thanks in advance for any hints.

Tracy Allen

The char1 should be a long, otherwise, as a byte, it can never equal -1.

if char1 <> -1                                       ' -1 is no character, otherwise ascii code of character

What are your size settings in CONstants for the RX buffers on ports A and B?

lab_ges

Hi Tracey, thanks you your comments, and for your work on "fullDuplexSerial4port.spin", I seem to remember seeing your name in the comments.

I left the buffers at their default lengths, RX are all 80, since I was only using simulated data that was fairly short to start with, at least one will need to be made longer once I get things working.

Since the byte can never be -1 ( dah!), I guess it is cycling through the buffer space, since there is always new data if you can't have -1.
I don't understand why the buffers seem to be so long, given the defines of 80?.

Will try this tomorrow but it is fairly logical to me that that is at least one of my more obvious mistakes. Thanks again.

Tracy Allen

And good luck with your project. I'm happy to see the object in use.

The -1 is a flag returned when there is no data at all in the buffer, but your routine is turning the flag into $FF and reporting it as data. The number of $FFs simply shows execution of the repeat loop during the interim between the real data strings.

lab_ges

Many thanks Tracy.

The LONG has indeed fixed my program, the Propeller is starting to make a little more sense to me.

In the end, after looking back at some of the examples I had "borrowed" code from, I moved my "char" strings from "VAR" and put them as "local variables" under MAIN.

PUB Main | char1, char2

I had not understood the meaning of the "|" and the variables after it before, but apparently they are always LONGS!

On the bright side my mistake effectively shows is a map of the free "time" between receiving my data strings, that could be a useful diagnostic technique at some time in the future now that I can see what is happening as it can be difficult to get a visual idea of how much data is being handled.

Tracy Allen

Yes, that's the best way to handle it, with those local longs. You didn't show yet how you will use char2 to receive data from your second rx port and merge it into the output. Do feel free to ask questions here if you run into difficulties. I'm very happy to see that you are starting off with Spin. It is a very effective language close to the heart of the Propeller.

lab_ges

Thanks for your help, I haven't really worked out the code for the next part yet.
I do have some simple code that does an inline replace of the <cr> from the first string with a comma then just runs another "repeat / until" loop similar to the first for testing.
While it works OK as a proof of concept it also means of course, that if the second stream isn't there the whole loop gets stuck waiting for it to appear, which isn't great.

In the long run I was thinking of using another COG to put the other string into a public variable perhaps even an array as there is a slight possibility that the second string will arrive slightly less frequently than the first and I don't want to tie the first up by waiting for the second.

Further developments would involve adding more strings to the first couple as eventually I would need to combine some I2C (sensor) data and maybe SPI (ADC) data to the end of the string as well, all these will be slower update times than the first string as their data is less time critical.

After all that I would need to make the Baud rate for the main string (at least) flexible as there are a few possible baud rates other then 9600 it might be set too, I have no idea at this time how I will go about doing that bit but it is early days yet.