Debugging Arduino Code in Crystal
Many of those who make projects a bit harder for “Hello, World!” For microcontrollers, sooner or later face the problem of debugging code. In such situations, as a rule, debugging information represents the output to the console, or a certain number of "myrgs" by some kind of LED. Those who have been debugged with printf, prinln and others like them do not need to explain that even knowing where to put the debug output is sometimes a problem, interpreting the result and understanding where the error is even more difficult.
Relatively recently, I came across a software that allows you to debug Arduino code directly in the crystal in a way that is very similar to the usual debugging of code to which you can connect a more or less advanced debugger. To whom it is interesting, you are welcome under the cat.
In order to avoid misinterpretations, I will say that the topic is by no means advertizing, but aims to share with the community my experience in debugging the code for the Arduino and the qualitative leap that this experience underwent due to my finding VisualMicro (www.visualmicro.com) . Just want to immediately warn comments like "aha, put a VisualStudio monster to write small firmware for small controllers ...". I myself am a VisualStudio user with an experience of 15 years, I already have it in my cerebellum (even if it is objectively inconvenient somewhere, I don’t notice it anyway due to habit). So the unification of the debugging process for the Arduino and the code that I usually write in VS makes me wildly enthusiastic: I need the same, “adult debugging” for the “little piece of iron”. With regard to "monstrosity" I have to say the following. Yes, VS is much larger than the Arduino IDE, but space on the screw is now cheaper than oats. Having a dvuhterabaytny hard drive, to be greedy gigabytes - moveton. Yes, it loads longer, but if you calculate the difference between the increased load time and the time saved on debugging, you get a decent profit. I load the studio once a day (so this is +20 seconds of loading per day on my not very clever home laptop on the Core i3 of the first generation), but I spend hours debugging on debugging. In addition, after a very short time, the Arduino IDE for a non-beginner in programming becomes cramped and you begin to wonder how to break the framework that it imposes. Well, the last argument against such a setup for debugging Arduino - VS costs horse money. Yes, this is true, but there are several "but":
So, VisualMicro is a plugin for VisualStudio (and, as a result, for AtmelStudio), which has:
There are two versions of the plugin - freeware, which implements the first three points, and paid, debugging support. It is relatively expensive - about $ 29, but the developers promise a free license to beta testers, and just to people who have somehow invested in the project .
The product has a lot of opportunities and they are described quite well in the Wiki , and the article does not claim to be a guide for use, so I will describe only those that I managed to use, namely:
The first thing to say is that no magic happens. The possibility of debugging appears due to the instrumentation of the code (I did not find direct evidence in the form of mentions in the same Wiki, the code did not disassemble, but an increase in the size of the “debagible” code compared to the original one speaks for itself). Those. when compiling with debugging support, the plugin embeds chunks into the code that allow debugging. Naturally, the size of the code grows. On the other hand, when you throw out all the println debugs from your code, you will be happy to find that as a result, even with the instrumentation, the code has become smaller. The second point concerns the difference between debugging using this plugin and the process of “normal debugging”. Everyone is used to the fact that the code is compiled once and then at runtime, with the debugger connected, you can set breakpoints and watch any kind of memory. Here it is not. The breakpoint must be set before the start of the debugging process, because only those code fragments are exposed to the instrumentation I have mentioned, for which the user's desire to stop at them is already known. When viewing variable values, the situation is similar: you must let the plugin know in advance which variables and in which places you are going to view / change. The blessing is not too difficult.
Suppose that you know how to sew a sketch through an Arduino IDE (well, you never know ...), i.e. With the firmware you have no problems. Suppose you have already installed the plugin, i.e. went through the setup procedure . Suppose you already have a sketch that you prepared in the Arduino IDE. In this case, creating a project in VS comes down to opening a sketch through File-> Open-> Sketch project. For the created project you need to set the MicroDebug option to Full. After that, you have two options - the classic for VS “Start without debugging” and “Start debugging”. The first compiles the code and fills it in Arduino. The second is compiling the code with instrumentation and starting the debugging session. By default, by the way, the plugin does not allow the program to stop, even if you set a breakpoint. This has its own logic. Since the Arduino is used, for example, in robotic projects, a shutdown can lead to dire consequences. Imagine you turned on the engines of the robot, it began to move, and you stopped the program. What will happen? Fall down the stairs? Bump into a wall? In the cat? In leg? In order to enable a stop at breakpoints, you need to set the Enable Break / Pause option to True in the project properties.
It should be noted that when you start a debug session, a series of windows opens. The window of the monitor of the serial port and a number of others necessarily open, the composition of which depends on the settings of the current session. The session ends by closing the monitor window. As long as the window is open, Visual Micro will assume that you are debugging.
Now consider the arsenal of debugging tools that I used.
The so-called trace points, i.e. points of the program for which you would like to know some state of the program, but would not like to interrupt its execution. From the VS point of view, the trace point is a normal breakpoint, but for which there is a “Continue execution” checkbox in the “When breakpoint is hit” window (just in case, you can get there by right-clicking on the breakpoint's kryzhik:
). Tracing in VisualMicro is done by writing the corresponding message in the same window. In this case, to output variables from the program, you need to use special macros of the form {XXX}, where XXX is the variable name.
In general, as can be seen from the screenshot, any expression that returns the result can be inserted into brackets.
After you set up the trace points and run the firmware in debug mode, you can watch as you pass through the installation locations in the MicroDebugTrace window
The messages of the format you set contain the variables and expressions you requested. In addition, the requested variables are also displayed in a special window Expressions.
Breakpoints are very similar to trace points. They are configured in exactly the same way, the only difference is that there is no need to put a checkmark “Continue execution”, while upon reaching the breakpoint the execution of the sketch is suspended. Here it is necessary to note one feature of Visual Micro. Unlike adult debuggers, the line on which the breakpoint is set will be executed before the debugger stops. This is due to the features of the code instrumentation. After the debugger has stopped the execution of the sketch, it is possible to view the status of the program at the time of the shutdown (but only in the part you specified: only those variables that you requested will be displayed, that is, you specified same way as specified for the trace point). You can change the values of variables as in an adult debugger, but again, only if you declared such a need. If in order for the debugger to take away variables from the MC, they had to be specified in the form {XXX} in the trace line, then in order to be able to change, you must specify them in the form {XXX =?}. Variables that can be changed are marked in yellow in the Expressions window. In addition, the usual features of breakpoints are supported - hit counter and conditional stop.
')
Out of the box, Visual Micro supports three types of reports: analog inputs, digital inputs, and the amount of free RAM.
The first two were not actively exploited, since they are not suitable for debugging fast processes (the first one has low time resolution, the second generally indicates the current logic level on the pin), so I use an oscilloscope / logic analyzer. Debugging of slow-running processes is almost always possible in terms of variables associated with the findings.
But I found the report on the amount of free memory extremely useful, because I had already run into a situation when the memory was running out several times. Finding such a problem is not an easy task, since the spectrum of symptoms is very wide - from spontaneous reset of the MC to incorrect behavior "which can never be."
Visual Micro has a bunch of features that list neither sense nor possibility. I will note only those that I considered potentially useful for myself:
Relatively recently, I came across a software that allows you to debug Arduino code directly in the crystal in a way that is very similar to the usual debugging of code to which you can connect a more or less advanced debugger. To whom it is interesting, you are welcome under the cat.
Introduction
In order to avoid misinterpretations, I will say that the topic is by no means advertizing, but aims to share with the community my experience in debugging the code for the Arduino and the qualitative leap that this experience underwent due to my finding VisualMicro (www.visualmicro.com) . Just want to immediately warn comments like "aha, put a VisualStudio monster to write small firmware for small controllers ...". I myself am a VisualStudio user with an experience of 15 years, I already have it in my cerebellum (even if it is objectively inconvenient somewhere, I don’t notice it anyway due to habit). So the unification of the debugging process for the Arduino and the code that I usually write in VS makes me wildly enthusiastic: I need the same, “adult debugging” for the “little piece of iron”. With regard to "monstrosity" I have to say the following. Yes, VS is much larger than the Arduino IDE, but space on the screw is now cheaper than oats. Having a dvuhterabaytny hard drive, to be greedy gigabytes - moveton. Yes, it loads longer, but if you calculate the difference between the increased load time and the time saved on debugging, you get a decent profit. I load the studio once a day (so this is +20 seconds of loading per day on my not very clever home laptop on the Core i3 of the first generation), but I spend hours debugging on debugging. In addition, after a very short time, the Arduino IDE for a non-beginner in programming becomes cramped and you begin to wonder how to break the framework that it imposes. Well, the last argument against such a setup for debugging Arduino - VS costs horse money. Yes, this is true, but there are several "but":
- Sometimes it's free ( pruflink )
- Sometimes he already has
- And now the most lethal: Atmel distributes VisualStudio 2010 as a rebranded product called AtmelStudio. Is free. Moreover, it includes VisualAssist, a plugin for refactoring, also for free
So, VisualMicro is a plugin for VisualStudio (and, as a result, for AtmelStudio), which has:
- Organization of the project in a way familiar to users of VisualStudio
- Support for native VS IntelliSense buns
- Compiling and firmware MK directly from VS
- Debugging code in crystal
There are two versions of the plugin - freeware, which implements the first three points, and paid, debugging support. It is relatively expensive - about $ 29, but the developers promise a free license to beta testers, and just to people who have somehow invested in the project .
The product has a lot of opportunities and they are described quite well in the Wiki , and the article does not claim to be a guide for use, so I will describe only those that I managed to use, namely:
- Crystal loading compilation
- Tracepoints and Breakpoints
- Monitoring pin and RAM status
Actually, the process
The first thing to say is that no magic happens. The possibility of debugging appears due to the instrumentation of the code (I did not find direct evidence in the form of mentions in the same Wiki, the code did not disassemble, but an increase in the size of the “debagible” code compared to the original one speaks for itself). Those. when compiling with debugging support, the plugin embeds chunks into the code that allow debugging. Naturally, the size of the code grows. On the other hand, when you throw out all the println debugs from your code, you will be happy to find that as a result, even with the instrumentation, the code has become smaller. The second point concerns the difference between debugging using this plugin and the process of “normal debugging”. Everyone is used to the fact that the code is compiled once and then at runtime, with the debugger connected, you can set breakpoints and watch any kind of memory. Here it is not. The breakpoint must be set before the start of the debugging process, because only those code fragments are exposed to the instrumentation I have mentioned, for which the user's desire to stop at them is already known. When viewing variable values, the situation is similar: you must let the plugin know in advance which variables and in which places you are going to view / change. The blessing is not too difficult.
Suppose that you know how to sew a sketch through an Arduino IDE (well, you never know ...), i.e. With the firmware you have no problems. Suppose you have already installed the plugin, i.e. went through the setup procedure . Suppose you already have a sketch that you prepared in the Arduino IDE. In this case, creating a project in VS comes down to opening a sketch through File-> Open-> Sketch project. For the created project you need to set the MicroDebug option to Full. After that, you have two options - the classic for VS “Start without debugging” and “Start debugging”. The first compiles the code and fills it in Arduino. The second is compiling the code with instrumentation and starting the debugging session. By default, by the way, the plugin does not allow the program to stop, even if you set a breakpoint. This has its own logic. Since the Arduino is used, for example, in robotic projects, a shutdown can lead to dire consequences. Imagine you turned on the engines of the robot, it began to move, and you stopped the program. What will happen? Fall down the stairs? Bump into a wall? In the cat? In leg? In order to enable a stop at breakpoints, you need to set the Enable Break / Pause option to True in the project properties.
It should be noted that when you start a debug session, a series of windows opens. The window of the monitor of the serial port and a number of others necessarily open, the composition of which depends on the settings of the current session. The session ends by closing the monitor window. As long as the window is open, Visual Micro will assume that you are debugging.
Now consider the arsenal of debugging tools that I used.
Tracepoints
The so-called trace points, i.e. points of the program for which you would like to know some state of the program, but would not like to interrupt its execution. From the VS point of view, the trace point is a normal breakpoint, but for which there is a “Continue execution” checkbox in the “When breakpoint is hit” window (just in case, you can get there by right-clicking on the breakpoint's kryzhik:
). Tracing in VisualMicro is done by writing the corresponding message in the same window. In this case, to output variables from the program, you need to use special macros of the form {XXX}, where XXX is the variable name.In general, as can be seen from the screenshot, any expression that returns the result can be inserted into brackets.
After you set up the trace points and run the firmware in debug mode, you can watch as you pass through the installation locations in the MicroDebugTrace window
The messages of the format you set contain the variables and expressions you requested. In addition, the requested variables are also displayed in a special window Expressions.
Breakpoints
Breakpoints are very similar to trace points. They are configured in exactly the same way, the only difference is that there is no need to put a checkmark “Continue execution”, while upon reaching the breakpoint the execution of the sketch is suspended. Here it is necessary to note one feature of Visual Micro. Unlike adult debuggers, the line on which the breakpoint is set will be executed before the debugger stops. This is due to the features of the code instrumentation. After the debugger has stopped the execution of the sketch, it is possible to view the status of the program at the time of the shutdown (but only in the part you specified: only those variables that you requested will be displayed, that is, you specified same way as specified for the trace point). You can change the values of variables as in an adult debugger, but again, only if you declared such a need. If in order for the debugger to take away variables from the MC, they had to be specified in the form {XXX} in the trace line, then in order to be able to change, you must specify them in the form {XXX =?}. Variables that can be changed are marked in yellow in the Expressions window. In addition, the usual features of breakpoints are supported - hit counter and conditional stop.
')
Reports
Out of the box, Visual Micro supports three types of reports: analog inputs, digital inputs, and the amount of free RAM.
The first two were not actively exploited, since they are not suitable for debugging fast processes (the first one has low time resolution, the second generally indicates the current logic level on the pin), so I use an oscilloscope / logic analyzer. Debugging of slow-running processes is almost always possible in terms of variables associated with the findings.
But I found the report on the amount of free memory extremely useful, because I had already run into a situation when the memory was running out several times. Finding such a problem is not an easy task, since the spectrum of symptoms is very wide - from spontaneous reset of the MC to incorrect behavior "which can never be."
Other features
Visual Micro has a bunch of features that list neither sense nor possibility. I will note only those that I considered potentially useful for myself:
- The presence of a framework for expansion. You can fasten some visualization specific to the project.Example
- Debugging not only via serial port, but also via Bluetooth, XBee, IP, software serial
- Support Teensy, Attiny, avrIO, Intel Galileo, Texas Instruments StellarPad, LaunchPad, ChipKIT / Pic32, STM32
Source: https://habr.com/ru/post/216029/
All Articles