Introduction 

Welcome to the Northeastern Electric Racing Embedded Software Launchpad! Launchpad was designed to teach new members the skills they need to excel on the embedded team in a scalable, paced, and fun way. This semester, you will be designing a virtual car with wireless telemetry on an embedded system using the methods and tools that we use on this team. By the end of Launchpad, you will be able to actively contribute to the code that will be running on the car, and you will have learned key skills for working in industry. 

Launchpad is broken up into multiple steps to keep learning happening at a steady pace and provide students with a direction from week to week. It is expected that each step is completed by the week specified in the schedule, however it is ok to fall behind and/or complete Launchpad late. What matters is that you complete Launchpad and understand the concepts of embedded programming that are essential to contributing to this team. To keep up with Launchpad, it is expected that you will attend team meetings and bay times while you are still learning to learn more about the team, touch base with leads on progress, and ask any questions you may have. Launchpad will be conducted through GitHub Classroom, a service provided by GitHub that allows for students to upload their code to be reviewed by leads at every step of Launchpad. Since you will be programming an embedded system, you will need to venture to the bay, which is in the basement of Richards Hall (054), to test your code on the club’s ESP32 microcontrollers. Note that hardware access will be limited, especially during bay time, so students should plan to test their code at times other than bay time, and they may reserve time with hardware in the team’ Slack channel (#fw_launchpad). 

Environment Setup 

Before any coding can happen, you first must set up your development environment. A development environment is a virtual workshop where all the tools needed to write code for this team are located. Follow the instructions on this page to set up your dev environment, and make sure you do the part where it says to set up a shell alias. 

1. Setting Up

To do the final preperations, in your terminal (with the venv active), simply run

You should be greeted with a bunch of installs- and this sets up the ESP32 specific tooling. In order for these changes to be recognized, you should deactivate and then reactivate the ner-venv. Also note, you may see some things “error”, but the install continues. This is generally okay, so feel free to ignore.

2. Clone the github classroom repo.

https://classroom.github.com/a/T9csPaFk

main.c - the application main code, with task/thread definitions and functional logic.

api.h/.c - These are the function calls you may need to use. While you should be able to complete the task using just this and other simple calls, you do not necessarily need to if you do not want. The purpose of this was to hide some of the messy syntax from you, and instead provide more clear APIs. Again, you do not need to edit this, but I encourage you to see what these do, since you' have to make calls to these functions. On top of the APIs defined there, I’ve included a comment in api.h with some more function signatures that you have access to that I found helpful to complete the task. Note: I did not create APis to hide FreeRTOS stuff, since you should become familiar with them !

3. Set up your Altium Account

To view how the circuit board works and what your code will need to interact with, you need to view our online plan (called a schematic) of the board. To do that, first enter your northeastern email into the thread in #fw_launchpad then follow the account creation instructions sent to your email. You should be good to go.

4. Testing

Once your code is ready to build, and assuming you’ve run “launchpad install” in the venv, you can do so with the following command:

To upload the built code to the board, connect over MicroUSB to the board, and run

To view logs

To view the Bluetooth data (optional until later on), download the NRF connect app on your phone. In the scanner, you should see an ESP device. Connect to that and you should be able to see the message!

Similarly you

5. Tips/keep in mind

• The value returned from the sensor is a raw ADC value. This means it is a unitless value, understood as a strength “percentage”. To understand this value, the resolution of the ADC needs to be known. For this device, the default resolution is 12 bits. This value is simply the number of bits used to depict this percentage - the more bits, the higher the precision you are able to achieve.

• When Using multiple threads like in an RTOS application, data atomicity is important. If a piece of data is accessed from multiple threads, it is important to use a locking mechanism, like a mutex or semaphore, to make sure that sharing this data is done safely

• Explore your tools: We use the dependency command platformio. The above ner lp commands are simply shortcuts. Feel free to try other platformio commands to further test, debug, or learn more about what you are building.

Begin

Ok you know all of the basics, check out Part 1 to get started!