On 14 Aug, 22:05, John Henderson <jhenRemoveT...@talk21.com> wrote:.
> My approach is to put everything from the device onto the end of
> a string variable, which I'll refer to by its name, "outb".
> This variable is dynamic in that it is allowed to grow as
> required, and gets trimmed (one way or another) as data is
> removed.
Yes I do that as well. Everything that comes off the serial port is
put onto the end of a string and I begin parsing. Once I have
recognised a command my parser goes into the waiting for parameters
state where I actually begin looking for the end delimiter. Once I
get that I take the parameters out and delete the whole command from
the string.
> When parsing outb, I look for result identifiers, like "+CBM: "
> and "+CSQ: ", and store the positions of the first instances of
[quoted text clipped - 3 lines]
> cbmpos = strstr(outb, "+CBM: ");
> csqpos = strstr(outb, "+CSQ: ");
Again similar. I look for the identifiers.
> Then I'll usually find which of these positions is the earliest
> (smaller address offset), and process that one first in a
> routine specific to its data.
Sounds familar
Then I'll destroy the identifier
> within outb (by changing "+CSQ: " to "-CSQ: " for example).
> Then I'll repeat the above piece of code, find the next result,
> and process it. When no identifier is to be found, I'll empty
> outb:
>
> outb[0] = 0;
Mine differs here slightly in that I delete the command from the
string when I have recieved and processed it.
> This approach implies lingering long enough on reading the input
> buffer to wait for results to arrive fully and intact.
[quoted text clipped - 9 lines]
> so I'm not concerned here about trailing <cr> or <lf> characters
> at all.
My reason for using the CRLF characters is to find the end of a result
string. And my reason for that is because some of the results have
variable length parameters and some parameters are optional. If the
parameters following the identifier were fixed length then I would not
be interested in an end delimiter for the result string I would just
wait for that number of bytes from the serial port.
> I find the above works well for most mixes of immediate and
> unsolicited-result commands. Minor exceptions include the
[quoted text clipped - 29 lines]
>
> - Show quoted text -
Thanks. Your use of sscanf is key there. I think some of the
problems I am experiencing are due to 'rogue responses' that do not
follow the pattern of CRLF that others do. I am going to try to
become independent of CRLR.
How about echo? I use hyperterminal to send commands adhoc. I have
used it with echo off (but I cannot see what I am typing) so I choose
either echo on or echo key presses locally. I don't see any responses
prefixed with at. However in my app I do and I specifically send an
echo off command. I have a suspicion that hyperterminal is not
presenting me with exactly what comes from the serial port. Do you
think so?
Thanks again,
Richard
John Henderson - 15 Aug 2008 21:19 GMT
Hi Richard,
> My reason for using the CRLF characters is to find the end of
> a result string. And my reason for that is because some of
[quoted text clipped - 3 lines]
> an end delimiter for the result string I would just wait for
> that number of bytes from the serial port.
Likewise, much of the data I get is of unpredictable length.
For example, I read and display device make, model number, and
firmware revision during startup. I wrote that particular
routine before I started using sscanf, so my code is a little
obscure to me (written over 5 years ago). A sscanf reading the
string from the result identifier up to the first <cr>
character would be much more compact, comprehensible and
elegant.
> How about echo? I use hyperterminal to send commands adhoc.
> I have used it with echo off (but I cannot see what I am
[quoted text clipped - 4 lines]
> exactly what comes from the serial port.
> Do you think so?
I generally switch echo off, for a number of reasons which have
more to do with elegance than necessity.
But some commands result in a data response without a result
identifier. For those, I turn echo on, to give me a handle to
find the data (it's expected just after the echoed command).
Reading the IMEI, as per my last reply, is a case in point.
In the times I used Hyperterminal, I did not think it was
interfering with the data stream.
Normally, I use Linux and minicom instead of Hyperterminal. But
my netmonitoring programs run as DOS programs so that they'll
work from any DOS boot disk (not even Windows) in a vehicle. I
soon modified the program at page 22 of this pdf file, and used
it instead of hyperterminal:
http://www.beyondlogic.org/serial/serial.pdf
John