...
A C programming tutorial. Although we have a number of videos on C programming, joining up in the hopes it’ll teach you programming is unlikely to get you very far. We really don’t have the resources to teach you programming right from scratch, and there are much more qualified people out on the internet to teach you the basics. Here is a link to get familiarized with the basic concepts of C.
An insult to your intelligence. Aside from C, there are plenty of other skills members may or may not have acquired through hobbies, co-ops, or classes. If you feel like we’re moving too slowly, try to work ahead, but these lessons are targeting the lowest common denominator.
All-encompassing. There’s so many diverse skills that are useful to have as a firmware member, so we’re gonna do our best to cover the important stuff, but you’ll definitely need to google for answers when you’re working on a projectuse the resources you have around you wisely. That means googling for answers, reading through documentation/datasheets, or speaking to your peers.
With that out of the way, let’s get started!
...
Software is a set of instructions that you run on a computer. For example, your favorite favourite video game or code editor is software. It’s normally stored on your hard drive, then when you want to execute it, your operating system (windows Windows or mac os Mac OS or linuxLinux) will grab those instructions, put them into working memory (RAM), and execute those instructions. Once you’re done with the program, they’ll be erased from RAM to make room for other things.
...
An example of some firmware can be found in your laptop: something called your BIOS (basic input/output system) is the first program that runs when you power on, which then loads your operating system.
In our firmware team, we work mainly on writing code for microcontrollers (like Arduino but we don’t use Arduino) that control or monitor the solar car. This an important aspect of firmware, which is that firmware focuses more on controlling a device’s hardware.
Why does it matter?
Firmware generally has a lot more restrictions than software. Firstly, the processor isn’t very fast and there isn’t much memory available, so our code needs to be simple and not too demanding. We partially get around this restriction by breaking the firmware into small projects and running it on different boards, each responsible for controlling a different part of the car. Breaking it down also helps us work on different parts at the same time.
...
At the end of the day, in midnight sunMidnight Sun, the firmware is there to support the hardware, not the other way around. This means we’re not the protagonist!
If you’re a budding software engineer with big dreams of making the world a better place through AI and block chain blockchain or whatever other buzzwords are trending nowadays, this team might not be for you. We keep things simple.
...
Each non-bolded line in the diagram represents a firmware project that controls a part of the car’s electrical system, grouped under the groupings headings in bold. Here’s a quick rundown of what each group of firmware projects project does:
Battery: Ensures the battery doesn’t explode.
Driver controls: Takes input from the driver and passes it on to the rest of the system.
Power distribution: Turns other boards on and off (think of it like turning off a normal car, but leaving the radio playingcontrols which boards are powered).
Drivetrain: Turns pedal presses into setting Converts the angle that the pedal is at to the current levels for the motors (so if you floor it the car will go faster).
Charging: Manages charging of the battery from an off-the-shelf wall electric car wall charger or from the solar array.
For the most part, our firmware projects are detailed in confluenceConfluence. Boards Each sub page subpage is the home for an electrical board’s documentation, most of which have a sub-page for the firmware.
How we’re working remotely
...
An important caveat here is that not all computers understand the same instructions. For example, the processor in your laptop understands instructions called x86 (instruction set for Intel processors), while the computer chips we run our firmware on understands instructions called ARM.
Compiling our code
To do things like turn lights headlights on or off and read voltages from our hardware components on the BMS (battery management system) through code, we use pieces of code that are called libraries. Our firmware projects implement the logic parts we need, like determining when and how often to flash a light, we want an LED to blink and then we use the library to actually talk to the light LED to turn it on or off. What this allows us to do is have different version versions of the libraries for different type types of computers:
...
This is the key to letting us work remotely! We can write all our C code and run it on our laptops, and never worry about actually touching the hardware, right?
...
Unfortunately, it’s not quite that simple. Some things are really hard to emulate on x86, especially things that are time-sensitive , since you don’t know what else your laptop might also be working onbe doing while you’re running the code. Microcontrollers have internal clocks which may differ from the one on your computer. However, it still gives us enough capability to write code and test our main logic.
Also, the hardware is still around, we’re just not close to it anymore. Good thing zoom, discord, and slack all exist! If we want to run our code on real hardware, we just have to call up the hardware member with the board and ask them to run it for us. Yes, this is more inconvenient, but it’s better than showing up a month later without having tested anything at all on hardware.
...
As for actually writing code, it’s important now more than ever that we follow a process for writing code , since it’s a little harder for me to peek over your shoulder and ask how you’re doing. Our process for writing firmware is as follows:
High-level design: we We come up with a high-level structure of the project that fulfills fulfils the requirementsrequirement.
Detail design: we sort out the specifics, like what events or messages need to be passed between modules of the project.
Implementation: we write the code.
Unit testing: we write tests that test specific parts of the code to make sure our logic works the way we think it does.
IO testing: input/output testing. We run the project on hardware, and make sure the hardware works the way we expect it to.
Integration testing: we connect multiple boards together and make sure they work together the way we expect them to.
...
The TL;DR of this is that we use GitHub and JIRA. We’ll be going over the detailed processes for these in later lessons, but otherwise, if you’re familiar with the basics, feel free to skip this section.
GitHub is a version control system that lets us have a master version of our firmware code as well as “branches”. Each branch can have modifications made to it in an isolated environment, then once the changes are checked and verified, they can be “merged” back into master. We use this as a way to give each member an isolated environment to work on their changes in. Excellent tutorials can be found here: https://www.atlassian.com/git/tutorials/using-branches
...