In this article, we communicate our embedded cortex-m with the PC during debug session using a trick called semihosting. This trick provides access to host IO (console, filesystem, shell execution) remotely from our embedded device.
In the previous articles, you learned how to write initialization code and put it in the correct place in the processor memory. Now you will learn how to generate the proper binary for send to ROM and will see various tricks to simplify your live with gnu make and Makefile.
In the previous article, we learned how to write an efficient startup code and play with the options of the compiler to produce the desired code from C, but it is still necessary to put the code in the correct memory locations to produce an executable suitable for the cortex-m.
In the present article, we will work with the linker script to join all our code into a single well structured executable.
One of the most successful families of microcontrollers has been the cortex-m in its different versions (m0, m0+, m3, m4, m7, m33, etc), and one of the main reasons of its success is its simple boot process. In this article, we will travel through the magical land of code writing and look around the different implementations across some vendors, culminating with a proposed vendor-neutral startup schema with many advantages for your projects.
In this series of articles I will try to explain the tricks around code compilation, linker scripts and build systems, proposing a vendor neutral startup system for your cortex-m project.
Perfect, you’ve created your embedded system, provided it with an external storage system, created a serial terminal to test things out, and then started your journey through routine… testing as if you were sitting on an old 70’s ticker while you listen to “Sheer Heart Attack” by Queen (a plus for the sound without a synth)
Copyright (c) 2020, OurEmbeddeds; all rights reserved.
Template by Bootstrapious. Ported to Hugo by DevCows.
