34
edits
Setting up an Embedded Development Environment: Difference between revisions
Setting up an Embedded Development Environment (edit)
Revision as of 18:59, 3 October 2024
, 3 October 2024no edit summary
No edit summary |
No edit summary |
||
|
As of time of writing, we use two MCUs: an STM32G0B1RE, and an STM32G431CB. Both of them use a 32-bit ARM CPU, so that is our target architecture. Arm and other companies use a standardized ABI for their embedded processors, called the '''Embedded ABI''' (EABI), and that is the ABI we use. Thus, the name of our compiler is <code>arm-none-eabi-gcc</code> (and now you know where the name comes from).
=== Downloads for Our Board ===
===== General Compilation Tools =====
We first need higher-level tools that help automate the compilation of any C or C++ program. To do this, run the command
<code>cmake</code> is a program that builds Makefiles for <code>make</code> to call. It is simply another layer of abstraction that, in a sense, makes <code>make</code> more readable and easier to edit. We may use <code>cmake</code> later on for building some projects.
===== Binary Utilities =====
The collection of the compiler, assembler, linker, and various programs for manipulating compiled binaries make up a toolkit called the '''Binary Utilities''' (or binutils). Since the provided compiler for your desktop/laptop is very likely not going to work for our embedded devices we need the binutils for that architecture.
* For x86_64 hosts: [https://developer.arm.com/-/media/Files/downloads/gnu/11.3.rel1/binrel/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi.tar.xz]
* For aarch64 hosts (ARM Macs, etc.): [https://developer.arm.com/-/media/Files/downloads/gnu/11.3.rel1/binrel/arm-gnu-toolchain-11.3.rel1-aarch64-arm-none-eabi.tar.xz?rev=82c9a3730e454ab6b8101952cd700cda&hash=A484F380E7D73DF3C5F13CA6EBB954D5]
==== Debugging Tools ====
Like programming for any other environment, a debugger is a crucial tool for developing software. The technology behind debugging an embedded application is really interesting. If you call <code>gdb</code> on your desktop for a program running on your desktop, it is relatively straightforward to picture how that works. At a high level, your operating system provides certain features to let you pause the execution of a program and analyze the state of memory or registers in your program at any given time. But our embedded device doesn't have an operating system... '''it's not even on our computer'''! How does one debug an application that is not even running on the same machine you are debugging from? The answer is that there is specialized hardware on the chip and a little bit of software provided by the manufacturer which enables the debugger to pause the hardware in execution and inspect memory or registers. The program that we use is called <code>openocd</code>, or Open On-Chip Debugger. It takes advantage of an underlying standard called JTAG, which is beyond the scope of this lesson.
To install, run the command:
<code>sudo apt install openocd gdb</code>
==== Flasher ====
TBD
| |||