Real-Time Operating Systems: Firmware on an Open-Source Watch

1Objectives of the lab

• Understanding the difference between a main loop and a preemptive scheduler
• Applying schedulability criteria: utilization, the Rate Monotonic bound, EDF
• Building a complete, real firmware from source code
• Creating your own FreeRTOS task and correctly choosing its priority and stack size
• Showing on the watch the data produced by your own task and checking it in the system task list
• Communication between tasks through message queues, instead of global variables
• Triggering and fixing priority inversion
• The link between scheduling and consumption: why a poorly written task drains the battery

2About the project

We take the InfiniTime firmware - the system that runs on the PineTime watch - build it from source, add our own task and a new watchface, then flash it onto the watch over Bluetooth. At the end we measure what our addition cost, in consumption.

3Materials needed

• 1 PineTime (the sealed variant is enough)
• 1 Computer with Linux or WSL2
• 1 Docker installed
• 1 Phone with Gadgetbridge (Android) or InfiniLink (iOS) - see section 12
• 1 Magnetic charging cable (included with the watch)
• 1 ESP32-C6 from the previous lab (for the FreeRTOS-without-a-watch part)

4Why a main loop is not enough

A microcontroller program almost always starts like this:

void loop() {
  read_accelerometer();     // 2 ms
  update_display();         // 30 ms  <-- long
  handle_bluetooth();       //  5 ms
  count_seconds();          //  1 ms
}

It works until the moment one of the tasks becomes slow. While update_display() is drawing, the other three do not run. If a Bluetooth frame arrives during that interval, it is lost. And if the screen occasionally needs 200 ms, the watch visibly falls behind.

You can patch this with state machines and millis() checks - exactly the technique from the microcontroller lab. But by the fifth or sixth task, the code becomes impossible to follow. The industrial solution is a scheduler that interrupts a task partway through and gives the processor to another, more urgent one.

The vocabulary of scheduling

The two classic policies

5Scheduling simulator

Three periodic tasks, one processor. Move the sliders for the execution time and watch the diagram: the upward arrows are the release times, the colored rectangles are the actual execution, and a red ✕ marks a missed deadline. Switch between the two policies and compare.

6FreeRTOS tasks in practice

The code below runs unchanged on the ESP32-C6 and, with minimal changes, on any FreeRTOS system - including PineTime.

// FreeRTOS priorities: a BIGGER number = a HIGHER priority.
// We choose them by the Rate Monotonic rule: shorter period, higher priority.
#define PRIO_SENSOR     3        // period  20 ms
#define PRIO_BLUETOOTH  2        // period 100 ms
#define PRIO_DISPLAY    1        // period 200 ms

void sensorTask(void* param) {
  // vTaskDelayUntil keeps an EXACT period, no matter how long the work took.
  TickType_t last = xTaskGetTickCount();
  for (;;) {
    read_accelerometer();
    vTaskDelayUntil(&last, pdMS_TO_TICKS(20));
  }
}

void bluetoothTask(void* param) {
  TickType_t last = xTaskGetTickCount();
  for (;;) {
    handle_bluetooth();
    vTaskDelayUntil(&last, pdMS_TO_TICKS(100));
  }
}

void displayTask(void* param) {
  TickType_t last = xTaskGetTickCount();
  for (;;) {
    draw_display();              // may take 30 ms - will be interrupted by the sensor
    vTaskDelayUntil(&last, pdMS_TO_TICKS(200));
  }
}

void setup() {
  Serial.begin(115200);

  //            function        name         stack  param  priority       handle
  xTaskCreate(sensorTask,    "sensor",     2048,  NULL,  PRIO_SENSOR,    NULL);
  xTaskCreate(bluetoothTask, "bluetooth",  4096,  NULL,  PRIO_BLUETOOTH, NULL);
  xTaskCreate(displayTask,   "display",    4096,  NULL,  PRIO_DISPLAY,   NULL);
}

void loop() {
  // The main loop is itself a FreeRTOS task, at priority 1.
  // We let it sleep, so it does not steal processor time.
  vTaskDelay(pdMS_TO_TICKS(1000));
}

Three mistakes almost everyone makes

void diagnosticTask(void* param) {
  for (;;) {
    // Returns the minimum number of words that have remained FREE since startup.
    // If it approaches zero, the stack is undersized.
    UBaseType_t free_words = uxTaskGetStackHighWaterMark(NULL);
    Serial.printf("stack remaining: %u words (%u bytes)\n",
                  free_words, free_words * sizeof(StackType_t));
    vTaskDelay(pdMS_TO_TICKS(5000));
  }
}

7Communication between tasks

Two tasks that write to the same global variable produce data corruption that is hard to reproduce. FreeRTOS's solution is the message queue: a protected circular buffer, into which one task puts data and another takes it out, without the two knowing about each other.

typedef struct {
  uint32_t timestamp_ms;
  float    x, y, z;
} Reading;

QueueHandle_t queue;

void sensorTask(void* param) {
  TickType_t last = xTaskGetTickCount();
  for (;;) {
    Reading r = { millis(), readX(), readY(), readZ() };

    // The third parameter is how long we wait if the queue is full.
    // With 0 we do not wait at all: better to lose a reading than to
    // delay a higher-priority task.
    if (xQueueSend(queue, &r, 0) != pdTRUE) {
      // A full queue means the reader is not keeping up - useful information.
      Serial.println("reading lost - the consumer is too slow");
    }
    vTaskDelayUntil(&last, pdMS_TO_TICKS(20));
  }
}

void displayTask(void* param) {
  Reading r;
  for (;;) {
    // portMAX_DELAY: the task sleeps until something arrives. While asleep,
    // it does NOT consume processor time - exactly what we need for the battery.
    if (xQueueReceive(queue, &r, portMAX_DELAY) == pdTRUE) {
      draw(r.x, r.y, r.z);
    }
  }
}

void setup() {
  Serial.begin(115200);
  queue = xQueueCreate(10, sizeof(Reading));   // 10 messages pending
  if (queue == NULL) {
    Serial.println("not enough memory for the queue");
    return;
  }
  xTaskCreate(sensorTask,  "sensor",  2048, NULL, 3, NULL);
  xTaskCreate(displayTask, "display", 4096, NULL, 1, NULL);
}

void loop() { vTaskDelay(pdMS_TO_TICKS(1000)); }

8Priority inversion

This is the most famous trap in real-time systems. It endangered the Mars Pathfinder mission in 1997: the rover on Mars kept rebooting on its own, at irregular intervals, and the cause was exactly the mechanism described below.

How it happens

1. A low-priority task takes a shared resource (for example the I²C bus).
2. A high-priority task needs the same resource and blocks, waiting for it.
3. A medium-priority task, which has nothing to do with the resource, becomes ready and preempts the low-priority one.
4. Result: the medium-priority task indirectly delays the high-priority one. The priority hierarchy has been inverted.

Trigger it yourself

SemaphoreHandle_t resource;

void busy_wait(uint32_t ms) {
  // ACTIVE wait loop: keeps the processor busy, like real processing.
  uint32_t t0 = millis();
  while (millis() - t0 < ms) { }
}

void lowTask(void* p) {                         // priority 1
  for (;;) {
    xSemaphoreTake(resource, portMAX_DELAY);
    Serial.println("  [low] took the resource");
    busy_wait(300);                              // works with the resource
    Serial.println("  [low] releasing the resource");
    xSemaphoreGive(resource);
    vTaskDelay(pdMS_TO_TICKS(1000));
  }
}

void mediumTask(void* p) {                       // priority 2
  vTaskDelay(pdMS_TO_TICKS(50));                 // starts after the low one
  for (;;) {
    Serial.println(" [medium] occupying the processor for 800 ms");
    busy_wait(800);                              // never touches the resource!
    vTaskDelay(pdMS_TO_TICKS(1000));
  }
}

void highTask(void* p) {                         // priority 3
  vTaskDelay(pdMS_TO_TICKS(100));                // requests the resource after the low one
  for (;;) {
    uint32_t t0 = millis();
    Serial.println("[HIGH] requesting the resource");
    xSemaphoreTake(resource, portMAX_DELAY);
    Serial.printf("[HIGH] waited %lu ms\n", millis() - t0);
    xSemaphoreGive(resource);
    vTaskDelay(pdMS_TO_TICKS(1000));
  }
}

void setup() {
  Serial.begin(115200);
  delay(500);

  // ---- CHANGE ONLY THIS LINE ----
  resource = xSemaphoreCreateBinary();          // WITHOUT priority inheritance
  xSemaphoreGive(resource);                     // binary semaphores start empty
  // resource = xSemaphoreCreateMutex();        // WITH priority inheritance
  // -------------------------------

  xTaskCreate(lowTask,    "low",    2048, NULL, 1, NULL);
  xTaskCreate(mediumTask, "medium", 2048, NULL, 2, NULL);
  xTaskCreate(highTask,   "high",   2048, NULL, 3, NULL);
}

void loop() { vTaskDelay(pdMS_TO_TICKS(1000)); }

9Building the InfiniTime firmware

We move from examples to a complete firmware. InfiniTime has over a hundred thousand lines of code and runs on FreeRTOS with the LVGL graphical interface.

1. Download the source code
   downloadcopy

   git clone https://github.com/InfiniTimeOrg/InfiniTime.git
   cd InfiniTime
   git submodule update --init --recursive

2. Build using the official Docker image

   This is the recommended path: it brings along the ARM compiler and the Nordic SDK, so you do not need to install anything else.

   buildcopy

   docker run --rm -it \
     -v "$(pwd)":/sources \
     -u $(id -u):$(id -g) \
     infinitime/infinitime-build

   The first run takes a while, because it downloads the image. The result appears in build/output/ - the file with a .zip extension and the -dfu suffix is the package that gets loaded over Bluetooth.

3. Explore the project structure
   orientationcopy

   ls src/systemtask/          # the central task, which coordinates the others
   ls src/displayapp/          # the display task and the apps
   ls src/components/          # the drivers: battery, screen, sensors, Bluetooth
   grep -rn "xTaskCreate" src/ # where the tasks are created
   grep -rn "configTOTAL_HEAP_SIZE" src/FreeRTOSConfig.h

4. The watch-free alternative: the simulator

   InfiniSim builds the same interface code for the computer and displays it in a window, with an emulated screen and touch. It is the fastest way to develop a watchface.

   simulatorcopy

   git clone https://github.com/InfiniTimeOrg/InfiniSim.git
   cd InfiniSim && git submodule update --init --recursive
   # follow the instructions in the README for the SDL2 dependencies

Anatomy of the system

Once the code is built, look for the xTaskCreate calls. You will find a clear pattern:

10Adding your own task

We add to InfiniTime a task that counts the steps taken in every hour of the day, and we show the result on the watch, in the steps app. The example is small, but it sets three tasks in motion and uses both communication mechanisms from section 7:

1. SystemTask reads the accelerometer and, whenever the step total changes, sends a report through a queue. The queue carries events: "something happened".
2. statistics, our task, sleeps blocked on the queue. On each report it wakes up, works out how many steps were added, records them in the per-hour table, then goes back to sleep.
3. DisplayApp reads the table when it draws the screen. The table is shared state, so reading and writing it are protected by a critical section.

#pragma once
#include <FreeRTOS.h>
#include <task.h>
#include <queue.h>
#include <array>
#include <cstdint>
#include "components/datetime/DateTimeController.h"

namespace Pinetime {
  namespace Components {

    class Statistics {
    public:
      struct Report {
        uint8_t  hour;     // 0...23
        uint32_t steps;    // the day's total, as the sensor gives it
      };

      explicit Statistics(Controllers::DateTime& dateTime) : dateTime {dateTime} {}

      void Start();                          // creates the queue and the task
      void ReportSteps(uint32_t steps);      // called from the system task
      uint32_t StepsInHour(uint8_t hour);    // called from the display task

    private:
      static void Task(void* param);         // the task function
      void Loop();

      Controllers::DateTime& dateTime;       // where we read the current hour from
      TaskHandle_t  handle = nullptr;
      QueueHandle_t queue = nullptr;

      uint32_t lastSent = 0;                 // used ONLY by the system task
      uint32_t lastReceived = 0;             // used ONLY by the statistics task
      bool     haveBaseline = false;         // used ONLY by the statistics task
      std::array<uint32_t, 24> per_hour {};  // written by statistics, read by display
    };
  }
}

#include "Statistics.h"

using namespace Pinetime::Components;

void Statistics::Start() {
  // The queue is small: we only keep a few reports pending.
  queue = xQueueCreate(4, sizeof(Report));
  if (queue == nullptr) {
    return;                  // no memory even for the queue
  }

  // A 512-word stack = 2 KB. The task does not use LVGL and has no
  // large buffers, so this is enough for it. Check with
  // uxTaskGetStackHighWaterMark before treating this as the final value.
  if (xTaskCreate(Task, "statistics", 512, this,
                  tskIDLE_PRIORITY + 1, &handle) != pdPASS) {
    handle = nullptr;        // no memory for the stack
  }
}

void Statistics::Task(void* param) {
  static_cast<Statistics*>(param)->Loop();
}

void Statistics::Loop() {
  Report r;
  for (;;) {
    // The task SLEEPS here until a report arrives. While waiting it costs
    // nothing, and the idle task can stop the processor's clock.
    if (xQueueReceive(queue, &r, portMAX_DELAY) != pdTRUE) {
      continue;
    }

    // The first report after boot only gives the starting point: we do not
    // know in which hour the steps taken before the reboot happened.
    if (!haveBaseline) {
      lastReceived = r.steps;
      haveBaseline = true;
      continue;
    }

    // The sensor gives the day's total; the difference from the previous
    // total is the number of steps taken in between.
    uint32_t added;
    if (r.steps >= lastReceived) {
      added = r.steps - lastReceived;
    } else {
      // The total went down: midnight has passed and the counter restarted
      // from zero. We begin a new day of statistics.
      added = r.steps;
      taskENTER_CRITICAL();
      per_hour.fill(0);
      taskEXIT_CRITICAL();
    }
    lastReceived = r.steps;

    if (r.hour < per_hour.size()) {
      taskENTER_CRITICAL();              // the display may read the table at any time
      per_hour[r.hour] += added;
      taskEXIT_CRITICAL();
    }
  }
}

void Statistics::ReportSteps(uint32_t steps) {
  // Only send when something changed - otherwise we fill the queue for nothing.
  if (queue == nullptr || steps == lastSent) {
    return;
  }
  Report r {dateTime.Hours(), steps};
  // No waiting: if the queue is full, the report is lost. No steps are lost,
  // though - the next report again carries the day's total.
  if (xQueueSend(queue, &r, 0) == pdTRUE) {
    lastSent = steps;
  }
}

uint32_t Statistics::StepsInHour(uint8_t hour) {
  if (hour >= per_hour.size()) {
    return 0;
  }
  taskENTER_CRITICAL();
  uint32_t value = per_hour[hour];
  taskEXIT_CRITICAL();
  return value;
}

11Wiring the task in and rebuilding

The two files from the previous section do nothing yet. If you copy them into the project and build, the build succeeds with no error, the watch boots, and the task does not exist. The reason: the compiler does not know the new file has to be compiled, nobody creates the object or calls its Start(), and nothing displays the result. Four steps follow, then a rebuild.

1. Register the new file with CMake

   Open src/CMakeLists.txt and add the path of the .cpp file, relative to src/, next to the other components. The .h file does not go in the list. Careful: the line has to go into two lists, not one.

   Besides the normal firmware, InfiniTime also builds a recovery firmware - a minimal image the bootloader loads if the main application no longer starts. It contains SystemTask.cpp too, so it also calls Start() and ReportSteps(). Its source list is called RECOVERY_SOURCE_FILES. If you add the file to SOURCE_FILES only, compilation succeeds but linking the recovery firmware stops with undefined reference to Pinetime::Components::Statistics::Start().

   src/CMakeLists.txtcopy

   # 1. the normal firmware
   list(APPEND SOURCE_FILES
     ...
     components/datetime/DateTimeController.cpp
     components/statistics/Statistics.cpp      # <-- the added line
     ...
   )
   
   # 2. the recovery firmware - further down in the same file
   list(APPEND RECOVERY_SOURCE_FILES
     ...
     components/datetime/DateTimeController.cpp
     components/statistics/Statistics.cpp      # <-- the same line, once more
     ...
   )

2. Create the object in the system task

   Our task needs the date-and-time controller to know the current hour (see the constructor in Statistics.h). SystemTask already holds a reference to it, so the object is declared there. Order matters: class members are constructed in the order they are declared, so statistics must be declared after dateTimeController. The GetStatistics() function gives the steps app access to the object, in step 4.

   Be careful where you put it: right below enum class SystemTaskState starts the declaration of the SystemTask(...) constructor, which spans about 20 lines. If the function ends up inside its parameter list, the compiler reports hundreds of errors (expected ')' before '{' token, then uninitialized reference member for every member), even though the mistake is a single line. Put it after PushMessage, as below.

   src/systemtask/SystemTask.hcopy

   #include "systemtask/Messages.h"
   #include "components/statistics/Statistics.h"     // <-- added
   
   // ... in the public section, RIGHT AFTER the PushMessage declaration.
   //     CAREFUL: not inside the parameter list of the SystemTask(...) constructor,
   //     which spans about 20 lines just above and ends with ");"
         void Start();
         void PushMessage(Messages msg);
         Pinetime::Components::Statistics& GetStatistics() { return statistics; }
   
   // ... in the private section, RIGHT AFTER the dateTimeController line:
         Pinetime::Controllers::DateTime& dateTimeController;
         Pinetime::Components::Statistics statistics {dateTimeController};

3. Start the task and feed it data

   Start() is called once, at boot, after the other initialisation in SystemTask::Work(). The steps come from the function that reads the accelerometer, UpdateMotion() - that is where we pass them on through the queue.

   src/systemtask/SystemTask.cppcopy

   void SystemTask::Work() {
     // ... existing initialisation ...
     motionController.Init(motionSensor.DeviceType());
     settingsController.Init();
     statistics.Start();                              // <-- starts our task
     // ...
   }
   
   void SystemTask::UpdateMotion() {
     // ...
     auto motionValues = motionSensor.Process();
   
     motionController.Update(motionValues.x, motionValues.y, motionValues.z, motionValues.steps);
     statistics.ReportSteps(motionValues.steps);      // <-- the day's total, into the queue
     // ... the rest of the function is unchanged ...
   }

4. Show the result in the steps app

   The Steps app (the shoe icon) receives the object through AppControllers, which already holds a pointer to SystemTask, and adds a new line at the top of the screen. The Refresh() function runs in the display task ten times a second while the app is open - that is where the table is read, through StepsInHour().

   There are four changes in Steps.h, marked (a)–(d). The easiest one to forget is the first, the #include at the top. Without it the compiler does not know what Statistics is and reports 'Pinetime::Components::Statistics' has not been declared, then invalid use of incomplete type 'class Pinetime::System::SystemTask' - that is, it knows SystemTask exists but has not yet seen its definition.

   src/displayapp/screens/Steps.hcopy

   // (a) AT THE TOP, with the includes - without it, Steps.h does not know
   //     what Statistics is, nor what SystemTask contains:
   #include "Symbols.h"
   #include "systemtask/SystemTask.h"                 // <-- added
   
   // (b) the constructor takes two more references:
           Steps(Controllers::MotionController& motionController,
                 Controllers::Settings& settingsController,
                 Components::Statistics& statistics,
                 Controllers::DateTime& dateTime);
   
   // (c) in the private section, below settingsController:
           Controllers::Settings& settingsController;
           Components::Statistics& statistics;
           Controllers::DateTime& dateTime;
           lv_obj_t* lHour;
   
   // (d) and in AppTraits<Apps::Steps>, the Create function becomes:
         static Screens::Screen* Create(AppControllers& controllers) {
           return new Screens::Steps(controllers.motionController,
                                     controllers.settingsController,
                                     controllers.systemTask->GetStatistics(),
                                     controllers.dateTimeController);
         };

   src/displayapp/screens/Steps.cppcopy

   Steps::Steps(Controllers::MotionController& motionController,
                Controllers::Settings& settingsController,
                Components::Statistics& statistics,
                Controllers::DateTime& dateTime)
     : motionController {motionController}, settingsController {settingsController}, statistics {statistics}, dateTime {dateTime} {
   
     // ... all the existing constructor code ...
   
     // the new label, at the top of the screen - right before lv_task_create:
     lHour = lv_label_create(lv_scr_act(), nullptr);
     lv_obj_set_style_local_text_color(lHour, LV_LABEL_PART_MAIN, LV_STATE_DEFAULT, Colors::orange);
     lv_label_set_text_static(lHour, "");
     lv_obj_align(lHour, nullptr, LV_ALIGN_IN_TOP_MID, 0, 25);
   
     taskRefresh = lv_task_create(RefreshTaskCallback, 100, LV_TASK_PRIO_MID, this);
   }
   
   void Steps::Refresh() {
     // ... existing code ...
     lv_arc_set_value(stepsArc, int16_t(500 * stepsCount / settingsController.GetStepsGoal()));
   
     uint8_t hour = dateTime.Hours();
     lv_label_set_text_fmt(lHour, "Hour %02d: %lu", int(hour), statistics.StepsInHour(hour));
     lv_obj_align(lHour, nullptr, LV_ALIGN_IN_TOP_MID, 0, 25);
   }

5. Rebuild

   Exactly the same command as in section 9. The build is incremental: only the changed files and whatever depends on them are recompiled, so it usually takes under a minute, not as long as the first time.

   rebuildcopy

   # from the root of the InfiniTime repository
   docker run --rm -it \
     -v "$(pwd)":/sources \
     -u $(id -u):$(id -g) \
     infinitime/infinitime-build
   
   # where the package for the phone ended up:
   find build -name "*-dfu*.zip"

   If you get an error, read the first error in the list - the others are usually consequences of it. If you changed CMakeLists.txt and the build seems to ignore it, delete the build/ directory and build again from scratch.

12Flashing the watch

The watch is updated over Bluetooth, with no wires and no programmer. The bootloader keeps the previous version and automatically falls back to it if the new firmware does not confirm that it started correctly. The procedure differs slightly between Android and iOS - pick the column that applies to your phone.

1. Fully charge the watch

   An update interrupted by a drained battery is the most realistic way to brick a PineTime. The battery must be above 50%.

2. Install the companion app that matches your phone

   	Android	iOS (iPhone / iPad)
   App	Gadgetbridge	InfiniLink
   Source	F-Droid (free, open source)	App Store (free, open source)
   What else it can do	notifications, weather, music control	time/date, battery, heart rate, steps, Apple Music, HealthKit

   One name to avoid: nRF Connect for iOS It is the app that shows up most often in searches for flashing Nordic boards, but it no longer works for PineTime: versions after 4.24.3 broke compatibility, and the App Store always installs the latest version. There is no easy way to install the older version that used to work. Use InfiniLink.
3. Transfer the .zip package to your phone

   The file is in build/output/ and has the -dfu suffix. Do not unzip it - the archived format is what the bootloader expects. On an iPhone, the simplest way is to send it to the Files app (AirDrop from your computer, or a direct download in Safari) - InfiniLink can load it directly from there.

4. Start the update

   Android (Gadgetbridge): connect the watch, then Firmware/App install and choose the file.
   iOS (InfiniLink): connect the watch from the main screen, then from the firmware menu choose "Update from file" and select the .zip archive from Files. Alternatively, InfiniLink can check the InfiniTime releases page on GitHub itself and offer the latest version directly, without downloading anything manually.
   The transfer takes a few minutes on any platform. Do not move the phone away from the watch during this time.

5. Confirm the new version

   After rebooting, the watch asks for confirmation that the firmware works. If you do not confirm, the bootloader reverts to the previous version on the next reboot - an elegant safety net, worth studying as a mechanism in its own right.

13Assignments

1. Using the simulator from section 5, determine the maximum utilization at which the set of three tasks remains schedulable under RM. Compare it with the theoretical bound and explain the difference.
2. Find a configuration where RM misses deadlines and EDF does not. Copy both diagrams into your report and explain exactly what different decision EDF makes.
3. Upload basic_tasks.ino to the ESP32-C6. Modify displayTask to take 250 ms (longer than its period) and describe what happens to the other tasks.
4. Add diagnosticTask and note the remaining stack for each task. Shrink the allocations down to the safe limit and calculate how much memory you recovered.
5. Run inversion.ino in both variants. Note the high-priority task's wait time in each case and explain the difference through the priority-inheritance mechanism.
6. Build InfiniTime. Find every xTaskCreate call and produce a table of the system's tasks: name, priority, stack size and the role of each.
7. Look up the configUSE_TICKLESS_IDLE option in FreeRTOSConfig.h and explain, based on the code, what happens when every task is asleep.
8. Add the statistics task following sections 10 and 11, flash the firmware onto the watch and photograph the Steps app screen before and after a few dozen steps.
9. In Settings → About, screen 4, write down the value in the Free column for the sta task. Choose a stack size that keeps a 25 % margin over what was actually used, rebuild and check again. How many bytes of RAM did you recover compared with 512 words?
10. Explain why losing a report from the queue does not lose any steps. What would happen if ReportSteps() sent only the difference from the previous report, instead of the day's total?

14Deeper-dive challenge

15Self-check questions

16Resources

• Chapter 7 - Execution models and scheduling in real time
• Chapter 8 - Synchronization, kernel architectures and RTOSes
• InfiniTime - the firmware's source code
• InfiniSim - the computer-based simulator
• PineTime - hardware documentation
• FreeRTOS documentation