¿Cómo se depura software embebido en Arduino sin usar Serial.print()?

More AI-generated nonsense. Please DO NOT help LinkedIn crowdsource work to improve its AI bilge-water. Here are some more characters.

LEDs and buttons are a great way to debug your program because they serve as an interface between users and the software. Buttons can be used as input devices to change the state of the code and LEDs can be used as status to know what's going on inside code. Combining these two can help in logical debugging of the code.

Well we can use LEDs as visual indicators which can be used to get state information or else as an error flags. on the other hand buttons can be used as reset triggers or like mode selection or else for debugging purpose.

More AI-generated nonsense. Please DO NOT help LinkedIn crowdsource work to improve its AI bilge-water. Here are some more characters.

You can't use Serial plotter without Serial.print(). The original question was about alternate ways of debugging. But with serial plotter we can keep track of continuously changing signal.

well absolutely it helps us to observe changes in variables over time, making it easier to identify trends and patterns. One can analyze data to gain insights into our code's performance and behavior.

More AI-generated nonsense. Please DO NOT help LinkedIn crowdsource work to improve its AI bilge-water. Here are some more characters.

I use this whenever available, usually with a JTAG adapter. It makes the print method look like stones knives and bearskins. Special care must be taken to accommodate multiple cores and the effects on timing sensitive operations.

If you’re using a more advanced development environment that supports breakpoints and watches, you can pause the execution of your program at specific points to inspect the state of variables and memory. Watches allow you to monitor variables' values as the program runs, providing deeper insight into your code’s behavior. This method can be more precise and informative than Serial.print(), especially when debugging complex logic.

If you can get hold of a debugger, there is nothing better than that. However getting a debugger or working with one might be difficult for the majority of Arduino users. But again, if the user can put extra bucks and effort into getting the debugger, this is the best thing that an embedded programmer can get.

Breakpoints allow you to pause execution at specific points, while watches continuously monitor variable values. I have shared a approach one should start taking by Select a debugging tool like Visual Studio Code or PlatformIO. Set up the tool to connect to Arduino board. Place breakpoints at suspicious locations in your code and then define variables or expressions to monitor. I always sue this in T32, it helps a lot.

With the low cost of Logic Analysers today ($10 - $500) this is without a doubt the best debug tool you can have. Setting breakpoints in your code is helpful, but is less than useful when you are directly interacting with external hardware in an interrupt driven environment. A logic analyzer and a few free DIO pins can make debuging really complex MCU solutions a breeze and the protocol analysers built in let you view your I2C and SPI transactions in detail. For any PCBs I make I invariably add a 10pin connector to allow one of the cheap LAs to plug directly into the board for bringup.

Which is why I developed DeDe, an Arduino UNO debug and development platform, to begin with. Probing the UNO can be painful when you don’t have easy access to the pins. Having red & green LEDs to see the state of each of the IOs is sometimes enough to debug problems like we did during the good old days of logic probes. The development side of it, the breadboard area, was added because I didn’t want to waste the board space.

I used an oscilloscope to monitor PWM signals and feedback from encoders. By analyzing signal waveforms and timing relationships, I could pinpoint issues such as incorrect duty cycles or encoder counts, aiding in precise debugging. In another project involving I2C, a logic analyzer became indispensable. I could capture data transactions, examine start/stop conditions, and check for ACK/NACK responses. This allowed me to quickly identify protocol-related problems and optimize performance. Ultimately, treating Arduino as an AVR microcontroller and embracing standard embedded debugging techniques empowers you to efficiently diagnose and resolve complex issues, ensuring robust and reliable real-time embedded software.

To test software related stuff, all other options are good. But to test hardware-related things like PWM, interrupts, precise timing measurements, signal noise, etc, Oscilloscope is a must. This is a must-have if you are looking at serious embedded work.

I have used Logic analyzer like it helps us to Examine digital signals, including communication protocols, interrupts, and pulse width modulation and based on that we can measure the timing relationships between different digital signals. By incorporating oscilloscopes and logic analyzers into your debugging toolkit, you can gain a comprehensive understanding of your Arduino project's electrical behavior and identify issues that may be difficult to diagnose using software-based methods alone.

Like i have never used simulator for the arduino but by leveraging simulators and emulators, you can streamline your development process, reduce the risk of hardware damage, and ensure the reliability of your Arduino code.

There are no great emulators available for Arduino. To some extent, you can use simulators to test basic stuff. But simulators have limited capabilities and don't produce precise timing outputs.

Provided you are using a board with the SAMD21 processor (like the Arduino Zero) the Arduino IDE version 2 has a built in debugger with all of the features you expect in any debugger. Watch for my article in the July edition of Circuit Cellar which explores these features (and bugs). I wrote the article after I could not find any detailed explanation of the debugger

When all else fails or your platform can’t be debugged in a traditional way there’s always 1-bit UART with a logic analyzer. Just add GPIO toggles to the code you want to debug. For instance to see when branches are being hit or how long an operation takes, or if you’re hitting some unexpected condition.

The logic analyzer is my favorite power tool. Probing buses or GPIOs is very powerful. You can code GPIO pulses with information on single or multiple pins. You can also implement async serial protocol very easily on a single GPIO. So you can "add" a UART. Then read with analyzer, or even FTDI-style serial to USB adapter.