Difference between revisions of "Debug Stream"

From ROBOTC API Guide
Jump to: navigation, search
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{| style="font-family:Verdana, Genega, sans-sarif; font-size:80%;color:gray;" width="100%" cellpadding="0%" cellspacing="0" border="0"
+
<yambe:breadcrumb self="Debug Stream">General|General Programming</yambe:breadcrumb>
|-
+
<br />
|
+
'''Dexter Industries''' has created a great introductory blog post on the debug stream, which can be [http://dexterindustries.com/howto/using-debugger-stream-in-robotc-for-lego found here].
''[[Main_Page|Main]] >> [[Debug_Stream|Debug Stream]] ''
+
|-
+
|}
+
  
  
{|
+
{{tl|1|1}}
|-
+
<br />
|style="vertical-align:top"| __TOC__
+
|style="vertical-align:top"|
+
{| width="100" cellpadding="2" cellspacing="0" style="border-collapse: collapse; border-width: 1px; border-style: solid; border-color: #000"
+
!colspan="2" class="wikiHeader"|Color Key
+
|-
+
|class="wikiText" width="75%" style="border-style: solid; border-width: 1px 0px 0px 0px"|Function:
+
|width="25%" style="border-style: solid; border-width: 1px 0px 0px 0px;" class="colorKeyFunc"|
+
|-
+
|class="wikiText" width="75%" style="border-style: solid; border-width: 0px 0px 0px 0px"|Variable:
+
|width="25%" style="border-style: solid; border-width: 0px 0px 0px 0px;" class="colorKeyVar"|
+
|}
+
|-
+
|}
+
 
+
  
 
== “Traditional” Debugging Techniques ==
 
== “Traditional” Debugging Techniques ==
 
{| class="wikiText"
 
{| class="wikiText"
 
|-
 
|-
| Debugging a program – finding the errors and correcting them – can be a slow process in solutions without a run-time debugger. Without a debugger you may have to resort to different techniques like:
+
| Debugging a program – finding the errors and correcting them – can be a slow process in solutions without a run-time debugger. Without a debugger you may have to resort to different techniques such as:
  
 
*There’s no way to determine if your program is executing the intended logic. So you add code to play different tones/sounds to your program as it executes different “blocks” of code. You determine from the sound what is being executed within your program.
 
*There’s no way to determine if your program is executing the intended logic. So you add code to play different tones/sounds to your program as it executes different “blocks” of code. You determine from the sound what is being executed within your program.
 
*If your robot platform supports a display device (which could be a serial link to your PC or an LCD display on the robot) then you would have to add “print” statements to your program code at various points in your program. By examining the display, you can (hopefully) determine what’s happened in your program's execution by the display.
 
*If your robot platform supports a display device (which could be a serial link to your PC or an LCD display on the robot) then you would have to add “print” statements to your program code at various points in your program. By examining the display, you can (hopefully) determine what’s happened in your program's execution by the display.
Both of the above techniques are available in ROBOTC. However, a real-time debugger eliminates the need to resort to them. There’s no need to add code for debugging to your program. A built-in debugger provides better functionality without ever having to modify your source code!
+
Both of the above techniques are available in ROBOTC; however, a real-time debugger eliminates the need to resort to them. There’s no need to add code for debugging to your program. A built-in debugger provides better functionality without ever having to modify your source code!
  
 
There is also a built-in Debug Stream that you can use to keep track of your program from behind the scenes.  For example, you could print a message to the Debug Stream when you enter and exit loops, functions, etc.  Then you can view the cached Debug Stream to help in the debugging process.
 
There is also a built-in Debug Stream that you can use to keep track of your program from behind the scenes.  For example, you could print a message to the Debug Stream when you enter and exit loops, functions, etc.  Then you can view the cached Debug Stream to help in the debugging process.
Line 38: Line 21:
 
|-
 
|-
 
|}
 
|}
 
  
 
== writeDebugStream ==
 
== writeDebugStream ==

Latest revision as of 16:53, 20 July 2012

General Programming → Debug Stream


Dexter Industries has created a great introductory blog post on the debug stream, which can be found here.


Color Key
Function:
Variable:


“Traditional” Debugging Techniques

Debugging a program – finding the errors and correcting them – can be a slow process in solutions without a run-time debugger. Without a debugger you may have to resort to different techniques such as:
  • There’s no way to determine if your program is executing the intended logic. So you add code to play different tones/sounds to your program as it executes different “blocks” of code. You determine from the sound what is being executed within your program.
  • If your robot platform supports a display device (which could be a serial link to your PC or an LCD display on the robot) then you would have to add “print” statements to your program code at various points in your program. By examining the display, you can (hopefully) determine what’s happened in your program's execution by the display.

Both of the above techniques are available in ROBOTC; however, a real-time debugger eliminates the need to resort to them. There’s no need to add code for debugging to your program. A built-in debugger provides better functionality without ever having to modify your source code!

There is also a built-in Debug Stream that you can use to keep track of your program from behind the scenes. For example, you could print a message to the Debug Stream when you enter and exit loops, functions, etc. Then you can view the cached Debug Stream to help in the debugging process.

Debug stream 3.png

writeDebugStream

void writeDebugStream(const string sFormatString, ...)
(void) Writes a String to the Debug Stream.
Parameter Explanation Data Type
sFormatString A string to write to the debug stream
(can be formatted!)
string
writeDebugStream("int x is: %d", x);  // writes the current value of int 'x' to the debug stream


writeDebugStreamLine

void writeDebugStreamLine(const string sFormatString, ...)
(void) Writes a String to the Debug Stream starting on a new line.
Parameter Explanation Data Type
sFormatString A string to write to the debug stream
(can be formatted!)
string
writeDebugStreamLine("int x is: %d", x);  // writes the current value of int 'x' to the debug stream on a new line.