Prerequisites

...

First, let's set up our hardware:

Feature Branches - Git

cd ~/shared/firmware
# Create a new branch off of master
git checkout master
git checkout -b wip_getting_started

...

You should see "hello world" appear twice - once when running on x86, and once in minicom! As you can see, our build system and HAL (hardware abstraction layer) allow us to build applications that can run natively on mutliple platforms. In this case, LOG_DEBUG is targeted to stdout on x86 (standard output) and UART1 on STM32. This makes testing a lot easier, and allows us to develop application code even without access to the hardware.

...

With your code workring, we want to make sure your code matches our Coding Standards. We use two tools for that:

...

# Runs clang-format
make format
# Runs lint.py (cpplint) and pylint
make lint

Committing Changes - Git

First, we want to make sNow that your code (hopefully) meets our standards, let's save your work. You should commit your changes relatively often. The goal is to have each commit represent a cohesive chunk of work. Basically, if you hit a point where you think you might want to come back to your work later, you should probably commit.

# Stage all changes
git add .
# Commit staged changes to the local repo
git commit -m "WIP: Adds working hello world project"

This time, we've used the -m argument to add a message directly on the command line. Alternatively, you can use git commit (no -m). This should result in a temporary COMMIT_EDITMSG being opened in your editor of choice. This method is recommended for multiline commit messages.

Notice how the commit message followed the format "WIP: ...". Similarly to branch naming, we follow a convention of "ELEC-[ticket number]: ..." for our commit messages. For example, "ELEC-281: Added part 1 of getting started guides".

Using a version control system (VCS) such as git allows you to keep track of changes over time and revert back if necessary. Feature branches allow you to organize your work and keep different projects separate from each other.

Since git is a distributed VCS, you have a local copy of the repository that needs to be synced with the remote server (GitHub). This means you can commit and make branches without internet access. Normally, we recommend you push your changes to GitHub as often as possible (git push), but since this is a tutorial, we won't bother with that.

Summary

We covered:

• Basic Git workflow
• Creating a new project
• Printing over UART
• HAL support for x86 and STM32
• Code cleanliness