pcFullDuplexSerial4FC Challenge-Response Frequency Problem

4Alex

Hi all,

I have a problem with a communications link between a PC and a Propeller and I can't find its origin! Here's what is happening: in my home automation project, I am polling a sensor every 2 seconds using a Challenge-Response approach. Baudrate is relatively slow at 19200. I send a challenge string of exactly 32 characters from a PC and the propeller respond back with a message of exactly 32 characters. I send this string via usb for now but I eventually intend to use Nordic wireless (hence the 32 bytes message). My problem is that after 20 exchanges, always 20, the propeller stop responding back. It doesn't matter if I poll every 5 seconds or longer, its still the same problem. 20 exchanges maximum.

Basically, I have a PC linked to a propeller using usb through pcFullDuplexSerial4FC.spin written by Chip Gracey and modified by Tim Moore. On the propeller side, I have a sensor linked through I2C. I have pinpointed the problem to the receiving side of the pcFullDuplexSerial4FC object by elimination process: if I put a loop in the transmission of the 32 bytes message (query the sensor, send the message, wait 2 seconds, query sensor again, etc), it runs without any problem and data are well received on the PC. If I send the command via the serial port, then if work only 20 times. Its almost like I saturate a send buffer that matches 640 bytes!

Any help would be greatly appreciated.

Cheers,

Alex

Erik Friesen

It would be good to post your code. Perhaps you are receiving one more byte than you realize, which fills your buffer? You could set up some receive code that runs in another cog to monitor it, if you can figure out how to debug the data.

dwelve

Funny thing I was just testing the pcFullDuplexSerial4FC object you speak of and was having problems receiving data, also.

I switched back to the original FullDuplexSerial object and receiving works just fine (though I modified it to a buffer size of 256 bytes). Could there be a problem with the pcFullDuplexSerial4FC object?

(Side note, I somehow couldn't get a full 256 byte tx buffer (or even anything above 16 bytes) hacked into the FullDuplexSerial object to work, so I'm actually using pcFullDuplexSerial4FC to config my serial device and then switching back to the FullDuplexSerial to receive... it's not pretty but it works... for now...).

4Alex

@Erik:
Thanks for your reply. I didn't posted any code a the comms is so trivial and straightforward.

@dwelve:
Interesting. Perhaps the following could help you pinpointing the problem. While trying to solve the receiving issue, I found an object for GPS routine written by Perry James Mole (2007) and apparently modified/adapted by Tim Moore in 2008 that uses the pcFullDuplexSerial4FC object. In a nutshell, a cog is dedicated to poll a gps and a camera in the background. Clever. The routine GetNEMA indicate the following warning:

"Needs to be called often enough that uart rx buffer doesn't overflow
May never return if serial receive rate is faster than processing rate"

So perhaps there is a problem with the serial object. Like I said, it really looks like there is some sort of buffer overflow or something. Can anyone tell me how to prevent an uart rx overflow? Mike Green? Tim Moore?

Cheers,

4Alex

Phil Pilgrim (PhiPi)

This sounds like either a stack overflow problem or an issue with the serial buffer enqueuing/dequeuing algorithm.

-Phil

4Alex

@Phil:

Thank you for your reply. My stack value is set at 150. Changing it to a higher value did not corrected the problem. Perhaps then it has to do with the 'enqueuing/dequeuing algorithm', as you suggested. But it beats me on how to correct this!

BTW, how does someone calculate the value needed for a stack?

Cheers,

4Alex

Ken Peterson

4Alex:

I think I saw someone post some code that would help you measure your stack usage. It's still trial and error. There's apparently no easy formula to figure it out ahead of time.

If you are just counting bytes as your protocol, how do you make sure that your messages aren't misaligned with your receive window?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."

- Bjarne Stroustrup

Post Edited (Ken Peterson) : 3/3/2009 5:51:33 PM GMT

4Alex

@Ken:
Thanks for your reply. I've seen 'somewhere' that code too and I did had the impression that it was MORE of a trial and error thing. So this is why I put a quite large stack. I'm can't say that I'm too proud of my approach, though...

As for the messenging algorithm, I use a start character. I picked a high value byte so I can use my start character also as the first byte of the Nordic header. From the receive buffer, I scan until I get this first character and then I store the message for further analysis. I can't use an end-of-message character as the Nordic compute a 16-bit crc as char 31 and 32. The body of the message is subdivided into meaningful operations, data, etc. A meaningless portion scraps the message.

Back to the problem at hand, I made a shorter message, looped the challenge-response, and not too surprisingly I do get a few events... totalling close to 640 bytes before it jams again.

I am fiddling with the code at this point.

Cheers,

4Alex

4Alex

Hi all,

I am happy to report that I've solved the Challenge-Response problem. It had nothing to do with pcFullDuplexSerial4FC. For the record, it was caused by a stack overflow. In a nutshell, I used a combo of locks and a RETURN instruction at each level. I know that the manual says that RETURN is implied and automatically added by the compiler but I can tell you that there's a few spots in my code where I overflow if I don't specifically add it. In the serial port receiving handling routine, I added a 1ms pause within the buffer reading loop before the next iteration and it works consistently.

Thanks all for your help.

Cheers,

4Alex

Lawson

Huh, this sounds like an interesting code trap. By any chance do you think you could make a simple example with this specific stack bug and post it to the "Propeller tricks and traps" sticky?

Thanks,
Lawson

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?