Extended_FDSerial Question...

Sniper King

Below is the Method that just wont work.·

ExtendedSerial.RxStrtime(5000,@buf)


Here is the method that runs the above statement above.·

** Code **

PUB RxStrTime (ms,stringptr) : Value | ptr, temp
{{
· Accepts a string of characters - up to 15 - to be passed by reference
· Allow timeout value.
· String acceptance terminates with a carriage return or defined delimter character.
· Will accept up to 15 characters before passing back.
· Serial.RxstrTime(200,@MyStr)··· ' accept
· serial.str(@MyStr)············· ' transmit
·}}
··· ptr:=0
··· bytefill(@dataIn,0,70)
··· bytefill(stringptr,0,70)····························
·· temp :=· RxTime(ms)·······
·· if temp <> -1
····· dataIn[noparse][[/noparse]ptr] := temp
····· ptr++··················································
····· repeat while (((DataIn[noparse][[/noparse]ptr-1] <> 13) and (DataIn[noparse][[/noparse]ptr-1] <> Delimiter)) and (ptr < 71))·······················
········· temp :=· RxTime(ms)···
········· if temp == -1
············ ptr++
············ quit···
········· dataIn[noparse][[/noparse]ptr] := temp
·········
········· ptr++
····· dataIn[noparse][[/noparse]ptr-1]:=0·······································
····· byteMove(stringptr,@datain,ptr-1)··

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Was it pin 11 or 26?· Hmmm....··I think the smell of smoke tells the whole story.· Must be 26.



Michael King
Application Engineer
R&D
Digital Technology Group

Mike Green

What do you mean by "doesn't work"?

Why the BYTEFILLs? Did you change them? They clear "dataIn" and the "buf" for 70 bytes each. Why 70 bytes?

Sniper King

OK here is the full breakdown. I am having serious problems receiving serial data reliably. For instance, I can receive one of two packets and then it all freezes. an off and an on later it will do the same thing. the bytefills are my attempts at rectifying the problem. However it is still a no-go. This is for a wireless texting system using wireless modems. I have looked everywhere for fixes and the forums are my last hope.

I know I am getting data in because I can display the data but only for a couple of packets and then it stoppes working. Any suggestions?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·- Was it pin 11 or 26?· Hmmm....··I think the smell of smoke tells the whole story.· Must be 26.



Michael King
Application Engineer
R&D
Digital Technology Group

Ron Sutcliffe

You say packets ?

As in
Packet Radio , the old AX25
Microtor
Sitor
Pactor
Plain old RTTY
Wireless networking (I think not, but maybe you are using PINK)
Some other obscure mode often used with STL's
GMDSS also comes to mind another nasty piece of work !!
etc...etc...etc


It sounds more like a modem configuration problem to me. Only guessing but we don't have a lot the work with. I presume it is a modem and not a TNC. I am sure there are many who can help, once the problem is fully understood.

Ron

Mike Green

Other than the fact that your BYTEFILLs are overwriting some other variables, it's impossible to tell from what you've posted. Problems like you describe are usually due to one routine accidentally overwriting the variables or stack space of another routine, either because of an array subscript out of range or a stack overflow (from too many calls without returns) or, with the multiprocessing Propeller, one cog modifying a variable used by another cog when it's not expected.

You will need to post your entire program (please ... as an attachment, not as the text of a message).

The routine you posted, other than the mismatch between the comment description and how the code works, looks ok. If you're using FullDuplexSerial, you may be having problems with buffer overflow since the default buffer size is only 16 bytes and, if you don't empty it soon enough, it will just wrap around. You can increase the buffer to any power of 2 by changing a few lines of code. There are some alternate versions of FullDuplexSerial in the Object Exchange that already have this done.

Post Edited (Mike Green) : 6/26/2008 5:03:14 PM GMT