Differences

This shows you the differences between two versions of the page.

--- software_tools [2020/05/12 10:03] – [binutils] admin
+++ software_tools [2024/03/20 12:11] (current) – [Documentation] admin
@@ Line 1: / Line 1: @@
 [[https://projects.eclipse.org/projects/tools.tracecompass|Eclipse Trace Compass]]
+====== Static analysis tools  ======
+https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html?mc_cid=3835da293a&mc_eid=UNIQID
+https://clang.llvm.org/docs/ThreadSanitizer.html?mc_cid=3835da293a&mc_eid=UNIQID
+https://clang.llvm.org/docs/AddressSanitizer.html?mc_cid=3835da293a&mc_eid=UNIQID
+====== Running embedded software in the host ======
+From the Embedded Artistry newsletter:
+We have had a number of discussions this month about the idea of running as much code off-target as possible. Some of this is prompted by the Designing Embedded Software for Change course, where we frequently discuss ideas around breaking dependencies on the underlying hardware/OS. In other cases, it is prompted by a common question about testing: why should I bother writing tests off-target when I can run a unit testing framework on my device?
+Let's focus on the testing aspect first. At the most basic level, the benefits of running unit and integration tests off-target are:
+. You eliminate the lengthy flashing cycle from the equation.
+. Your build machine has much more processing power, so you can run more tests in a shorter amount of time.
+. Given that you are largely free of your embedded resource constraints, you can pull in additional frameworks and use testing strategies that may not even be feasible to support on your embedded target.
+Taking a recent client project as an example, we can perform an incremental build and complete unit test cycle off-target in less than two seconds. The same incremental build operation with the tests running on the target hardware takes 35 seconds. This difference in execution time really matters. If the test feedback cycle is short, you're going to run the tests much more often. Longer test cycles also add up over the course of a workday - if you run the tests 100 times, a 2 second test cycle would consume ~3.5 minutes total, while the 35 second version would consume ~58.5 minutes. And we cannot overlook the fact that longer cycles increase the probability of you becoming distracted and losing even more time.
+The natural next step from off-target testing is creating a simulator program. After all, you've already put in the requisite work. All that remains is to create simulator implementations for the missing pieces. You might talk to actual peripheral hardware over a USB debug adapter. You might also simulate them by playing back recorded data, providing a fixed value, or generating random data. You can draw your display in a Qt window instead of the display hardware. You might connect to another simulated system through a local TCP/IP port. These capabilities give you the power to iterate much faster and more comfortably than on the target hardware.
+When you can run your code off-target, whether through tests or a simulator, you also gain access to more tools and capabilities. Take the free example discussed above - if you're using MacOS or Linux with the provided standard libraries, you can get that support for free using glibc's MALLOC_PERTURB_ or MacOS's malloc debugging variables (or without any extra work if you're using an appropriate OS version). Even better, you can run your code through Valgrind and catch more errors than what malloc scribbling will reveal. You can link against sanitizers, which help you expose, diagnose, and resolve problems quickly - ThreadSanitizer (to catch data races), UndefinedBehaviorSanitizer (to catch undefined-behavior during program execution, which usually manifest in hard-to-debug issues when optimizations are enabled), AddressSanitizer (to catch memory errors like use-after-free, out-of-bounds accesses, and double-free), and LeakSanitizer (to catch memory leaks). You can build with compiler options, like full stack smashing protection or GCC's _FORTIFY_SOURCE=3, that would impact memory usage or performance too drastically to be useful on the target.
+We think these benefits are well worth the investment. This does not mean we ignore the target hardware - there should still be regular (automated) tests run on actual devices and internal "dogfooding" of the system. But our goal is to deliver higher quality software at a faster pace, and the tools and capabilities described above allow us to do that in a repeatable way.
 ====== Editors ======
 [[vim]]
@@ Line 33: / Line 59: @@
 [[https://blog.regehr.org/archives/1653|Article with ascii data structure visualizations (Embedded in academia)]]
+https://mermaid-js.github.io/mermaid/#/
 ===== Diagramming =====
+<color /#FFff00>**__[[https://app.diagrams.net/ | draw.io]]__**</color>
+<color /#FFff00>**__[[https://excalidraw.com/ | excalidraw]]__**</color>
 https://www.sequencediagram.org
@@ Line 61: / Line 93: @@
 [[https://joplin.cozic.net/|Joplin - opensource Evernote clone]]
+<color /#FFff00>**__[[https://docs.stashpad.com | stashpad]]__**</color>
+===== Markdown =====
+https://marker.pages.dev/
 ====== Issue tracking ======
 http://zserge.com/blog/agile-issue-tracker.html
@@ Line 167: / Line 204: @@
 https://jvns.ca/blog/2014/09/06/how-to-read-an-executable/
+[[https://www.youtube.com/watch?v=dOfucXtyEsU|CppCon 2018: Matt Godbolt “The Bits Between the Bits: How We Get to main()”]]
 ====== Project/work management ======
 https://asana.com