Closed codecubepi closed 2 months ago
@npetersen2
Please review this PR when you have time to do so. Tagging #360 for relevance.
@npetersen2
I have pushed commits that include the work we did in the lab today, as well as a commit addressing most of your feedback. Anything I wasn't able to address I left unresolved for tomorrow's meeting (13 Feb 2024).
We have split the timing manager feature away from the FreeRTOS feature. So, let's merge this PR into a new v2-staging
and then we will treat v2-staging
as the stable FreeRTOS codebase.
PR Overview
This pull request includes my work on the FreeRTOS portion of the
v2
firmware intiative up to 08 Feb 2024.This includes the FreeRTOS source code v10.6.2 linked as a Git submodule, dual-core applications (without Inter-Core Communication), and a restructure of the
sdk
directory tree such that common system-level drivers can exist in a "shared" folder, which is linked into both dual-core applications (freertos_app_cpu0
andfreertos_app_cpu1
).Additionally, efforts have been made in this pull request to streamline the setup of SDK projects for new users by making all build paths in the
.cproject
workspace-relative instead of absolute.Dual-Core Apps
The dual-core applications
freertos_app_cpu0
andfreertos_app_cpu1
are to run on CPU0 and CPU1 respectively to demo basic FreeRTOS task and structure functionality. Both apps run independently of each other. Each app has its own Tx task, Rx task, and a Queue to send messages through. CPU0 operates the RGB LEDs, while messages are transmitting, they cycle red, and when messages have completed, all LEDs blink green (to showcase operation of theled.c
driver). Each CPU also has its ownFreeRTOSConfig.h
, which are mostly identical, but can be individually configured if needed.Using a live submodule of the FreeRTOS Kernel will ensure going forward that we can make use of the latest features in FreeRTOS, and updating the kernel is as easy as updating the submodule.
Merge Plan
The plan for merging is to Squash and Merge the stable FreeRTOS code in this branch into
v2-staging
. A Squash and Merge is ideal due to the existence of files created by a commit in this branch, and that are then deleted by a subsequent commit.