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
