Debug.Print-ing issues

Started by Chris Odom May 26, 2007
I know it sounds stupid, but, yes, I am having trouble printing some
data to the PC's screen. No, I am not a newbie.

My students and I have been working on building an autonomous rover
that uses GPS to navigate our 215-acre campus. I am able to get data
from our GPS module (20 Channel EM-406A SiRF III receiver from
USGlobalSat) and the rover works just fine, but when we try to print
data to the PC's screen, the program often halts. I've been able to
work around it, but was curious if anyone knew why it was happening.

To provide some clues, here are my observations:

1. When printing a Single, I find that using Fmt(,) works when CStr()
doesn't. That is, if the program halts with this line:

Debug.Print CStr(SpeedMPS)

, it will work fine if I print like this:

Debug.Print Fmt(SpeedMPS, 3)

Using CStr often works just fine, but when it doesn't, Fmt does the
trick.
2. I've also found that the program sometimes halts at lines where
I've used the concatenation operator (&) to join strings. That is,
if the program halts when I print this line:

Debug.Print CStr(Latitude) & ", " & CStr(Longitude)

, it will work fine if I print the data this line:

Debug.Print CStr(Latitude) & ", " ;
Debug.Print CStr(Longitude)

Often concatenation works as expected, but when it doesn't, printing
to two lines seems to solve the problem. Don't you just love
intermittent problems?! Needless to say, it took me a while to
narrow down the problem this far.

The Maximum String Length for my project is 20 characters.

Does anyone (A) understand what I am trying to say; (B) know why the
BX is behaving this way; and/or (C) have another work-around to these
issues?

Thanks,
chris
Hi,

Try in this way :

debug,print? "Latitude = ";cstr(latitude); " ? "; "Longitude = ";cstr(longitude)

rosarite

-----Original Message-----
From: Chris Odom
To: b...
Sent: Sat, 26 May 2007 4:04 pm
Subject: [BasicX] Debug.Print-ing issues

I know it sounds stupid, but, yes, I am having trouble printing some

data to the PC's screen. No, I am not a newbie.

My students and I have been working on building an autonomous rover

that uses GPS to navigate our 215-acre campus. I am able to get data

from our GPS module (20 Channel EM-406A SiRF III receiver from

USGlobalSat) and the rover works just fine, but when we try to print

data to the PC's screen, the program often halts. I've been able to

work around it, but was curious if anyone knew why it was happening.

To provide some clues, here are my observations:

1. When printing a Single, I find that using Fmt(,) works when CStr()

doesn't. That is, if the program halts with this line:

Debug.Print CStr(SpeedMPS)

, it will work fine if I print like this:

Debug.Print Fmt(SpeedMPS, 3)

Using CStr often works just fine, but when it doesn't, Fmt does the

trick.

2. I've also found that the program sometimes halts at lines where

I've used the concatenation operator (&) to join strings. That is,

if the program halts when I print this line:

Debug.Print CStr(Latitude) & ", " & CStr(Longitude)

, it will work fine if I print the data this line:

Debug.Print CStr(Latitude) & ", " ;

Debug.Print CStr(Longitude)

Often concatenation works as expected, but when it doesn't, printing

to two lines seems to solve the problem. Don't you just love

intermittent problems?! Needless to say, it took me a while to

narrow down the problem this far.

The Maximum String Length for my project is 20 characters.

Does anyone (A) understand what I am trying to say; (B) know why the

BX is behaving this way; and/or (C) have another work-around to these

issues?

Thanks,

chris

________________________________________________________________________
AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.
Dear Chris, I am not sure about that 'cause I don't know exactly your code,
but It looks to me that your firmware could be complex enough to get too
close to the memory limit of the microcontroller (400 bytes for the BX-24P).
Usually the MCU halts if the operative system is in troubles when trying to
allocate space for some function call; for instance it could be that the
program stack simply overwrite some variable needed by the MCU to get back
to the point it was before calling the function ... stuffs like that ... The
problem with this kind of bug is that it is not easy to be discovered since
the effects on the program execution are usually unpredictable and
apparently unrelated to anything ...

I hope this comment can help solving the problem.

Bye.

Fabrizio

>From: "Chris Odom"
>Reply-To: b...
>To: b...
>Subject: [BasicX] Debug.Print-ing issues
>Date: Sat, 26 May 2007 21:04:03 -0000
>
>I know it sounds stupid, but, yes, I am having trouble printing some
>data to the PC's screen. No, I am not a newbie.
>
>My students and I have been working on building an autonomous rover
>that uses GPS to navigate our 215-acre campus. I am able to get data
>from our GPS module (20 Channel EM-406A SiRF III receiver from
>USGlobalSat) and the rover works just fine, but when we try to print
>data to the PC's screen, the program often halts. I've been able to
>work around it, but was curious if anyone knew why it was happening.
>
>To provide some clues, here are my observations:
>
>1. When printing a Single, I find that using Fmt(,) works when CStr()
>doesn't. That is, if the program halts with this line:
>
> Debug.Print CStr(SpeedMPS)
>
>, it will work fine if I print like this:
>
> Debug.Print Fmt(SpeedMPS, 3)
>
>Using CStr often works just fine, but when it doesn't, Fmt does the
>trick.
>2. I've also found that the program sometimes halts at lines where
>I've used the concatenation operator (&) to join strings. That is,
>if the program halts when I print this line:
>
> Debug.Print CStr(Latitude) & ", " & CStr(Longitude)
>
>, it will work fine if I print the data this line:
>
> Debug.Print CStr(Latitude) & ", " ;
> Debug.Print CStr(Longitude)
>
>Often concatenation works as expected, but when it doesn't, printing
>to two lines seems to solve the problem. Don't you just love
>intermittent problems?! Needless to say, it took me a while to
>narrow down the problem this far.
>
>The Maximum String Length for my project is 20 characters.
>
>Does anyone (A) understand what I am trying to say; (B) know why the
>BX is behaving this way; and/or (C) have another work-around to these
>issues?
>
>Thanks,
>chris
>

_________________________________________________________________
Scarica Windows Live Messenger e chiama gratis in tutto il mondo!
http://www.messenger.it/connessione.html
Thanks for your message, Fabrizio.

I was thinking the same thing -- that my problem is memory related.
However, the program's MAP file tells me I am nowhere near the RAM
limit: it requires only 159 bytes to run and consumes only 7804 bytes
of EEPROM. So there should be plenty of RAM and Code memory
available, right?

I am really getting frustrated with this problem.

chris

--- In b..., "Fabrizio Sellone"
wrote:
> Dear Chris, I am not sure about that 'cause I don't know exactly
your code,
> but It looks to me that your firmware could be complex enough to
get too
> close to the memory limit of the microcontroller (400 bytes for the
BX-24P).
> Usually the MCU halts if the operative system is in troubles when
trying to
> allocate space for some function call; for instance it could be
that the
> program stack simply overwrite some variable needed by the MCU to
get back
> to the point it was before calling the function ... stuffs like
that ... The
> problem with this kind of bug is that it is not easy to be
discovered since
> the effects on the program execution are usually unpredictable and
> apparently unrelated to anything ...
>
> I hope this comment can help solving the problem.
>
> Bye.
>
> Fabrizio
> ... memory related.

The symptoms certainly sound like you're crashing the stack, Chris.

In the past when I've apparently run out of stack, the first thing
I've done is look to cut back on string space. Reducing the maximum
string length in the IDE to the longest you really need is often
useful to recover significant stack space. Several string functions
are also heavy stack users and might be avoided where possible.
Concatentation, in particular, is suspect, but you'll find that Fmt
and CStr use significant stack, too. I've often used Mid to construct
a formatted string, avoiding Fmt. And Debug.Print, also a big stack
user, can be avoided with an output queue sent to COM1.
Tom
BTW, Mike Perks' BXDism is a great tool to help with memory problems.
Tom
Although it does sound like the Stack and the Heap are colliding,
perhaps the application is hanging not from memory problems, but from
communications problems. I'm not sure what the queue length is for
Debug.Print, but I'm guessing that it's fairly small. Depending on
the baud rate, the call to Debug.Print may be waiting to send all of
the data to the queue before it relinquishes control to the calling sub.

Try defining your own queues of generous size, and use PutQueueStr to
send the data to the com port. If I remember correctly, the call to
PutQueueStr returns immediately if the queue cannot accept more data,
thereby retuning control to the caller.

-Don
> ... If I remember correctly, the call to PutQueueStr returns
immediately if the queue cannot accept more data...

No, that's not correct. PutQueueStr will wait until sufficient queue
space is available for its contribution. If the queue is too small,
it will never return.
Tom
Thanks for the correction Tom. In that case, a sufficiently large
queue size should be used to avoid an application hang.

-Don

--- In b..., "Tom Becker" wrote:
>
> > ... If I remember correctly, the call to PutQueueStr returns
> immediately if the queue cannot accept more data...
>
> No, that's not correct. PutQueueStr will wait until sufficient queue
> space is available for its contribution. If the queue is too small,
> it will never return.
> Tom
>