showing data in realtime debugging?

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have some code the reads a couple of sensors and does some a analysis of the data. I would like to dump the data to the monitor while the program is running in debug mode. Similar to what you would see if the data was sent to terminal over uart. How can I get a similar result with the data from the watch window? It's important to me to see the previous data as well to observe the change and stability.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't think you can.

The debugger cannot keep up with operation. After all, it is transferred to the host computer over a serial link. When the code reaches a break point, pertinent data is sent from the target to the host.

You are probably better off sending the data you want to observe via asyc serial to the host terminal.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well clearly you can do something like:

char readings[256];
char rd_ptr;

int main(void) {
  while(1) {
    readings[rd_ptr++] = take_reading();
  }
}

Then after running for a while stop and see what the array contains. Even use upload/download memory to take a copy of the readings to a file on disk if you want.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An alternative method is to clock the environment with the clock of the core. Then cpu_time == your_time and all the problem of real-time is gone :)

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could set a breakpoint after the value is updated and then set the breakpoint properties to update the watch window and continue operation. Not quite real time but not sure how quick your application is

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rev wrote:
You could set a breakpoint after the value is updated and then set the breakpoint properties to update the watch window and continue operation. Not quite real time but not sure how quick your application is

This is what I am doing right now, the problem is that I am not able to see the previous values on the monitor in the same time. What I would like is to see a long list that keeps on scrolling as the processes runs. I understood that there's a small chance to do this without UART so I ordered parts to build a convertor using a MAX232.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then as clawson suggested why not create an array and then you can look at a list of the values.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rev wrote:
You could set a breakpoint after the value is updated and then set the breakpoint properties to update the watch window and continue operation. Not quite real time but not sure how quick your application is

Hi all,

thanks a lot for very usefull information in this forum.

I would like to watch "running" data too. Can you explain how it is possible to update watch window and continue with breakpoints? I have tried transforming them in tracepoint but actually I am able to print a message in output command (such some variables) window only. :(

Thanks in advance,
Alessandro

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Write a macro that updates your Watch window and then continues.
No, I have never done it with AS6.

I guess that this will be relatively slow since AS6 will probably download everything from the MCU each time that it hits the breakpoint.

Using regular printf() debug statements to an external terminal is probably going to be faster.

Whichever way you do things, bear in mind that any extra code or debug intrusion will alter your embedded execution.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I guess that this will be relatively slow since AS6 will probably download everything from the MCU each time that it hits the breakpoint.

As4 used to have a "kid's toy" that did exactly this. It was very slow because it had to do exactly that. Imagine what'd be like with an Xmega that had to pull hundreds of SFRs over the PDI link at every stop!
Quote:

Whichever way you do things, bear in mind that any extra code or debug intrusion will alter your embedded execution.

Schroedinger killed his cat that way ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

slow_rider wrote:
This is what I am doing right now, the problem is that I am not able to see the previous values on the monitor in the same time. What I would like is to see a long list that keeps on scrolling as the processes runs. I understood that there's a small chance to do this without UART so I ordered parts to build a convertor using a MAX232.

You can buy USB to TTL serial cables from digikey, no need to build your own.

http://www.digikey.com/product-d...

I use these all the time.

I also have something I designed before these were available which have an open collector TX and HCT buffer on the RX. Useful for battery powered devices where you don't want to back feed voltage into the unit under test. For instance when trying to measure the current consumption down to uA's

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was having the same issues with variables that change really fast. I found this topic and was kind of disappointed there wasn't a clear solution for this.

Breakpoints were not acceptable for me, as I was asserving a motor, and these variables depended on the turning of the motor.

Printing to the console didn't work too well, because there was too much information.

So I did some googling and I found this thing called Live Tuning: http://www.objectis-software.com...

They have a trial version available which has the necessary tools to run what they call Ocf. Basically, you put a small "Ocf server" on your target and choose which variables you want to "share" (it's really just a few lines of code and it's standard C).

Then you run Live Tuning and you can see all the variables you published, almost in real time.

I followed their tutorial here: http://www.objectis-software.com...

It says it's for C++ but it works just as well with C.

Hope that helps :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That post looks a LOT like spam to me!

Moderator.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
That post looks a LOT like spam to me!

+1.
But I prefer that from kitchening.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, sorry to sound so spammy. I guess when I look at it now it kind of does.

Nonetheless, that solution actually worked for me and I'm pretty statisfied. I just wanted to share it since I had the same problems and this particular app solved mine.