| View file | ||
|---|---|---|
|
Introduction
Welcome to the firmware team! We’re glad to have you.
In this lesson we’ll be covering:
What firmware is
An overview of our firmware system
...
What our process for writing firmware is
Just a quick note before we jump into the content. All of our modules assume that you have some familiarity with programming, specifically the C language. You unfortunately won’t be able to do much until you have some familiarity with the language (specifically pointers, functions and structures).
C Language Resources:
Midnight sun specific Intro to C programming (Shoutout Arshan Khanifar)
Interactive tutorial - Learn-C.org. If you’ve programmed before in other languages before, the most important parts for our team are listed below:
...
In our firmware team, we work mainly on writing code for microcontrollers (think Arduino) that control electrical signals or monitor the solar car. Microcontrollers are essentially just computers but much smaller, and directly connected to hardware components.way cooler!
Why does it matter?
Firmware generally has a lot more restrictions than software. The processor we use isn’t (comparatively) very fast and there isn’t much memory available, so our code needs to be simple and not too demanding. We can 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 timeprojects in parallel.
Systems overview
Here’s a diagram of the car’s electrical system:
...
Hardware and Firmware
Our team coexists with hardware and it is mandatory for you to be interested and willing to learn electronic basics. This is what makes firmware super cool! It isn’t just software and it isn’t just hardware. We bring life to PCBs and give our vehicle functionality.
Systems overview
Here’s a diagram of the car’s electrical system:
...
If this scares you, don’t worry! It scares us too. Thankfully, implementing what’s in this diagram is the hardware team’s job, not ours!
Firmware system overview
...
Each non-bolded line in the diagram represents a firmware project that controls a part of the car’s electrical system, grouped under the headings in bold. Here’s a quick rundown of what each firmware 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 (controls which boards are powered).
Drivetrain: 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.
Your PC vs a Microcontroller
...
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 be 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 hardwarefrom the one on your computer. However, it still gives us enough capability to write code and test our main logic.
Our Process
Writing Code
Our firmware runs in safety-critical situations, and as such it can be dangerous if it goes wrong. To help prevent this we have a structure for creating and testing our firmware.
High-level design: We come up with a high-level structure of the project that fulfils the requirement.
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/Hardware validation: 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.
Notice how much testing we go through! This is really important. In firmware, writing the code is often only half the battle, and there can be many unforeseen delays when you actually start interacting with hardware.
...
Thanks for sticking through! In conclusion, here’s what you should come away from reading this with an understanding of:
What firmware is
What our firmware systems do at a high level
How we’re able to work on firmware without direct access to the hardware
Our process for completing firmware projects
Next in firmware 102, we’ll go into more depth on our firmware system, controller boards, our project structure, testing and validation, and our collaboration platforms. We hope to see you there!
...
There are several tasks that need to be completed as part of this module:
Learn about Git and the Command Line by watching/reading the following tutorials
Git Tutorial Videos (part 1 and 2) and branching lesson
Command Line Tutorials (Part 1 and 2)
Get your environment set up by following the instructions listed at Setup
Write your very own Hello World program!
1. Intro Videos
These videos give an introduction to two of the main tools we use on our team, Git and the shell command line. We suggest watching them if you aren’t very experienced in one or the other, since the rest of the onboarding content will rely heavily on these concepts. However, we also do explain it as we go, so feel free to continue on even if you still haven’t fully grasped the concepts, and use these resources when you get stuck.
...
You will need to use a few things from our code base for this project.
Include the “log.h” library. We have our own version of printf which allows us to safely print to the console. You can use it the exact same way as printf, just replacing it with LOG_DEBUG, ie:
LOG_DEBUG("Hello World %d\n", my_int);
Run the program using the scons command from above (with a different project name).This program should run forever in a while true loop.
...