Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| software_tools [2019/04/11 09:28] – [Git] admin | software_tools [2024/03/20 12:11] (current) – [Documentation] admin | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | |||
| [[https:// | [[https:// | ||
| + | |||
| + | ====== Static analysis tools ====== | ||
| + | |||
| + | https:// | ||
| + | https:// | ||
| + | https:// | ||
| + | |||
| + | ====== 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/ | ||
| + | |||
| + | Let's focus on the testing aspect first. At the most basic level, the benefits of running unit and integration tests off-target are: | ||
| + | |||
| + | 1. You eliminate the lengthy flashing cycle from the equation. | ||
| + | 2. Your build machine has much more processing power, so you can run more tests in a shorter amount of time. | ||
| + | 3. Given that you are largely free of your embedded resource constraints, | ||
| + | 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' | ||
| + | |||
| + | 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 " | ||
| + | |||
| ====== Editors ====== | ====== Editors ====== | ||
| + | |||
| [[vim]] | [[vim]] | ||
| Line 28: | Line 54: | ||
| http:// | http:// | ||
| - | http://asciiflow.com/ | + | <color # |
| <color # | <color # | ||
| + | |||
| + | [[https:// | ||
| + | |||
| + | https:// | ||
| ===== Diagramming ===== | ===== Diagramming ===== | ||
| + | |||
| + | <color /# | ||
| + | |||
| + | <color /# | ||
| + | |||
| + | https:// | ||
| https:// | https:// | ||
| Line 47: | Line 83: | ||
| http:// | http:// | ||
| - | https://www.yworks.com/ | + | <color # |
| ====== Documentation ====== | ====== Documentation ====== | ||
| [[http:// | [[http:// | ||
| Line 56: | Line 93: | ||
| [[https:// | [[https:// | ||
| + | |||
| + | <color /# | ||
| + | |||
| + | ===== Markdown ===== | ||
| + | https:// | ||
| ====== Issue tracking ====== | ====== Issue tracking ====== | ||
| http:// | http:// | ||
| Line 87: | Line 129: | ||
| * git checkout < | * git checkout < | ||
| * git branch #list of local branches (-a to show also remote branches) | * git branch #list of local branches (-a to show also remote branches) | ||
| - | * | + | * git push origin origin/< |
| Working with a specific release: | Working with a specific release: | ||
| * git checkout -f $VERSION | * git checkout -f $VERSION | ||
| * git checkout master | * git checkout master | ||
| * git checkout -f #undo all local changes, reseting working copy to latest version in repository | * git checkout -f #undo all local changes, reseting working copy to latest version in repository | ||
| - | * #changes the name of a remote branch: | ||
| - | * git push origin origin/< | ||
| Workflow: | Workflow: | ||
| Line 150: | Line 191: | ||
| ====== binutils ====== | ====== binutils ====== | ||
| + | |||
| + | objdump --no-show-raw-insn -dC < | ||
| nm -a --demangle --print-size --size-sort -t d my_obj.o | nm -a --demangle --print-size --size-sort -t d my_obj.o | ||
| Line 158: | Line 201: | ||
| readelf -S and readelf -s to view section & symbol info | readelf -S and readelf -s to view section & symbol info | ||
| + | https:// | ||
| + | |||
| + | https:// | ||
| + | |||
| + | [[https:// | ||
| ====== Project/ | ====== Project/ | ||