Book Image

The Insider's Guide to Arm Cortex-M Development

By : Zachary Lasiuk, Pareena Verma, Jason Andrews
Book Image

The Insider's Guide to Arm Cortex-M Development

By: Zachary Lasiuk, Pareena Verma, Jason Andrews

Overview of this book

Cortex-M has been around since 2004, so why a new book now? With new microcontrollers based on the Cortex-M55 and Cortex-M85 being introduced this year, Cortex-M continues to expand. New software concepts, such as standardized software reuse, have emerged alongside new topics including security and machine learning. Development methodologies have also significantly advanced, with more embedded development taking place in the cloud and increased levels of automation. Due to these advances, a single engineer can no longer understand an entire project and requires new skills to be successful. This book provides a unique view of how to navigate and apply the latest concepts in microcontroller development. The book is split into two parts. First, you’ll be guided through how to select the ideal set of hardware, software, and tools for your specific project. Next, you’ll explore how to implement essential topics for modern embedded developers. Throughout the book, there are examples for you to learn by working with real Cortex-M devices with all software available on GitHub. You will gain experience with the small Cortex-M0+, the powerful Cortex-M55, and more Cortex-M processors. By the end of this book, you’ll be able to practically apply modern Cortex-M software development concepts.
Table of Contents (15 chapters)
1
Part 1: Get Set Up
5
Part 2: Sharpen Your Skills

Understanding the value of CI

CI is a best-practice framework for software development that aims to improve software quality while reducing development time and cost. It can best be described by contrasting it with the typical embedded software development flow, which we call desktop development.

In the desktop development situation, a team of software developers all works on the same code base at the same time, typically using GitHub or a private code repository. As each developer works, they send their modified code through their own non-standardized custom suite of tests with the hardware board on their desk, about once per day. This code is merged into a shared branch with their team. Developers then pull the shared branch back to their local environment to obtain changes from their team. At this point, the code may or may not be in a working state, and it is sometimes hard to identify the source of bugs that have been introduced by the interaction of different changes.

This...