Skip to content
Snippets Groups Projects
Commit c1f60c69 authored by Henrik Tjäder's avatar Henrik Tjäder
Browse files

Discussing some...

parent 41190c94
Branches
No related tags found
No related merge requests found
......@@ -84,6 +84,33 @@ The final result of the project, in regards to fulfilled goals, is as follows:
Some uncertainties with the HAL libraries and other functionality was easiest resolved this way, among other general questions regarding development.
This, combined with regular meetings each week allowed us to integrate our work more smoothly, as we were all present anyway.
\subsectionauthor{Author: Henrik Tjäder}
Many things not directly related to the project, but invaluable to the project's progress lies in the available tools and in the experince of those
who wield said tools.
With all of us having previous knowledge of STM32 hardware, few had delved deeper into the inner workings of how the toolchain manages to take all those source files
and in the end produce a flashable executable. There exists many "pre-made" toolchains available from different vendors. To name a few,
Atollic TrueSTUDIO, Kiel uVision, IAR EWARM, SW4STM32, lpcexpresso. Most of these come with their own IDE, either basing it on some opensource project such as Eclipse
or implementing their own thing. Picking any one of these is by some means a way of getting trapped in a vendor lock-in since it is usually not trivial to maintain compatibility
with more than one toolchain at a time or change between them.
Then how to do it without these huge dependencies? The answer: GNU Make.
As the project progressed the \texttt{Makefile} got improved and further functionality such as automating flashing and starting debugging sessions via OpenOCD + GDB were added.
This gave each of us the freedom to pick our own preferred working environment, such as working directly with the files via \texttt{vim}, \texttt{sublime} or through a full-fledged
IDE such as \texttt{Eclipse}.
Having \texttt{git} made working together a breeze. It is easy to test things out in a new branch and then if things went as expected just merge the changes back to the main branch.
With such modern hardware we would often need to run the very latest and in some cases even development versions of tools ta have proper support. Six out of seven group members
chose to install and run an \texttt{Arch Linux}-based system for programming and debugging. This was thanks to the bleeding edge nature of the distribution and the extensive software library available.
Even the very latest bleeding edge version of \texttt{arm-none-eabi} from the Debian \texttt{Sid} repository lagged behind the Arch-default version by a whole version: \texttt{5.4.1} vs \texttt{6.2.0}
The reason this was of concern was that all versions available in Debian failed compiling due to lack of MCU specific floating point support.
TODO: Add details from Timers, IMU, SONAR maybe?
TODO: Continue this section!
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment