Hi, Have you tried using the RecvTerminated function of Synaser? It provides input for a timeout aswell as the line terminator?
W On Mon, May 25, 2009 at 4:22 AM, Audiography (Peter Naus) < [email protected]> wrote: > Hi all, > > I've been trying to find a logical way of retrieving "lines" (string of > characters terminated by CR/LF or CR) from the serial port, but I'm having > terrible trouble, and it MUST be easier than this! > > > > I'm connecting to a remote system using "standard" serial port parameters - > hardware COM port, ASCII text sending/receiving, hardware handshaking. That > all works OK, I don't lose characters, the handshaking works perfectly, all > is good. > > > > My problem is, that the remote system is "asynchronous", that is, if I send > it a command (usually, but not always containing a CR at the end), it might > take up to 30 seconds to respond. And when it responds, it may send more > than one line of text (usually many). Some lines ARE terminated by CR/LF, > the rest are terminated by a specific (and unique) character. > > > > What's happening now is that I can't find any Synaser method to reliably > (and SIMPLY!) return a string terminated by a CR/LF when reading the port. > When I try to do that with any of the receive string methods, regardless of > the timeout, they either never return, or when they do, they have the CR/LF, > but also part of the next line. I'm sure that's just the way the com port > buffer works, but I can't seem to find out how to use Synaser to bypass all > that nasty stuff and just return strings or newlines. > > > > My workaround is to repeatedly call RecvByte() and append each byte (char) > received to a string, and keep doing that for up to 30-40 seconds after the > first null character received, in case there are more lines/chars as part of > the response that the remote system hasn't got to yet. > > > > Of course, then I must manually try to decipher which of the incoming > characters are echos of my own command, and then figure out if the last > CR/LF in the string is not at the very end of the string, and treat the > remaining string (after the last CR/LF) as a "pending" string. > > > > But since I'm not able to predict in advance how many lines or how many > characters I'm going to receive, I'm losing bits of strings, and the last 4 > hours I've spent trying to add received lines to a stringlist, and use that > as a FIFO "readln" stack, result in my brain hurting and no better way of > accessing the returned strings. There MUST be an easier way! > > > > As a complication, while MOST of the returned strings ARE delineated by > CR/LF, the most important strings don't, but they DO terminate in a unique > and known character - so in theory, I should be able to use a pattern > matching read, except that doesn't seem to work as I need. > > > > I started trying to understand the pattern-matching string receive > routines, but I had to do so much work changing from one "input string type" > to another, that I'm hopelessly lost with partial strings, multiple blank > lines (CR/LF/CR/LF pairs only), and I'm no closer to getting the information > back in a simple and robust form. > > > > The examples (as most new members know in this list) are extremely sparse > and mostly unhelpful for the real-world type application I'm needing, and > despite many people asking in the archives, after 3 hours of trolling the SF > archives, I still can't find any example of a simple 'ReadLn()' (or 'Read()) > result type using the Synaser library. > > > > What I'd like to do is call a generic read LINE routine, which simply keeps > waiting for a CR/LF pair, and then return that as the result. The problem > with that is, when I do that, I must still manage all the text BEFORE and UP > TO the CR/LF, and somehow "leave" the rest of the line intact (in a global > string variable, or ???), which then gets "appended" to by the subsequent > ReadLn. But that doesn't work well either. > > > > I'm sure this must be very simple and very, very easy, but I need some help > and ideas. Can Synaser do this? Can it do it without me reinventing the > wheel every time? Are there better alternatives? > > > > I've been considering just taking the brute force approach and after > sending a command, wait for 2-3 minutes for the serial input buffer to get > something, and then use that, but that's just silly. The problem seems to be > the time taken for the serial port input buffer to begin filling again - in > the middle of 200+ short CR/LF delimited lines, it can pause in the middle > for up to 40 seconds, all the time polling no characters at all, then > suddenly another 80 or more short lines appear. At 38.400 baud, that's > unacceptable, so I must be doing **something** very wrong! > > > > Thanks in advance for any help or suggestions. > > > > Cheers, > > PCPete > > > > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > synalist-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/synalist-public > >
------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
