diff --git a/docs/tasks.txt b/docs/tasks.txt index e3d3841c..8b5b9a1d 100644 --- a/docs/tasks.txt +++ b/docs/tasks.txt @@ -10,7 +10,7 @@ Timers that are registered using our timer infrastructure are executed on this t "IDLE" - The idle task ---------------------- -This is a special task used by the FreeRTOS scheduler. It's defined at it's own priority level which is at the lowest priority. If no other task is ready to run, either due to waiting on a semaphore or waiting using vTaskDelay (or something like that), the idle task is chosen to run instead. +This is a special task used by the FreeRTOS scheduler. It's defined at its own priority level which is at the lowest priority. If no other task is ready to run, either due to waiting on a semaphore or waiting using vTaskDelay (or something like that), the idle task is chosen to run instead. We have modified FreeRTOS such that if we're in the idle task, we enter a lower power mode, either sleep or stop. Stop mode is special in that peripheral clocks are shut down when we go into stop and are not automatically turned back on when we leave stop mode. This means we have to go through and turn them all back on. This is what the `register_stop_mode_resume_callback` function does. It allows individual drivers to register callbacks that are called when we leave stop from the idle thread. This comes with a caveat though. Since the idle thread only ever runs when there's nothing else to run, the scheduler assumes that there is always a task to run. This means that if the idle task is stopped or delayed for any reason, the scheduler will explode. Therefore you are not permitted to do operations that may stop the task's execution from within the resume callback. @@ -34,4 +34,4 @@ This task is created for the currently running app. No task is created for the l Open Questions ============== -Which tasks are allowed to manipulate the window state? What if the launcher wants to push a notification window at the same time as an app pushes it's own window? +Which tasks are allowed to manipulate the window state? What if the launcher wants to push a notification window at the same time as an app pushes its own window? diff --git a/src/fw/applib/ui/dialogs/actionable_dialog.h b/src/fw/applib/ui/dialogs/actionable_dialog.h index 6a42ea8d..8ff0e73c 100644 --- a/src/fw/applib/ui/dialogs/actionable_dialog.h +++ b/src/fw/applib/ui/dialogs/actionable_dialog.h @@ -53,7 +53,7 @@ void actionable_dialog_set_action_bar_type(ActionableDialog *actionable_dialog, ActionBarLayer *action_bar); //! Sets the ClickConfigProvider of the action bar. If the dialog has a custom action bar then -//! this function has no effect. The action bar is responsible for setting up it's own click +//! this function has no effect. The action bar is responsible for setting up its own click //! config provider //! @param actionable_dialog Pointer to a \ref ActionableDialog to which to set the provider on //! @param click_config_provider The \ref ClickConfigProvider to set diff --git a/src/fw/applib/ui/progress_window.h b/src/fw/applib/ui/progress_window.h index f8cc46f8..d41fb6ae 100644 --- a/src/fw/applib/ui/progress_window.h +++ b/src/fw/applib/ui/progress_window.h @@ -27,7 +27,7 @@ //! //! A UI component that is a window that contains a progress bar. The state of the progress bar //! is updated using progress_window_set_progress. When the window is first pushed, the progress -//! bar will fill on it's own, faking progress until the max_fake_progress_percent threshold is +//! bar will fill on its own, faking progress until the max_fake_progress_percent threshold is //! hit. Once the client wishes to indicate success or failure, calling //! progress_window_set_progress_success or progress_window_set_progress_failure will cause the //! UI to animate out to indicate the result, followed by calling the .finished callback if diff --git a/src/fw/debug/legacy/flash_logging.c b/src/fw/debug/legacy/flash_logging.c index 720aff78..39947a51 100644 --- a/src/fw/debug/legacy/flash_logging.c +++ b/src/fw/debug/legacy/flash_logging.c @@ -36,11 +36,11 @@ //! Logs messages to SPI flash for later retreival. //! //! The different chunks allow us to implement a rolling log, where if we fill up all the chunks, we can erase the oldest -//! chunk to find us some more space. Each chunk gets it's own header at the top of the chunk to indicate the order in +//! chunk to find us some more space. Each chunk gets its own header at the top of the chunk to indicate the order in //! which the chunks should be reassembled. //! Make sure chunks are still an even number of flash subsectors. Our log space is 7 subsectors, so our NUM_CHUNKS -//! makes it so each chunk has it's own subsector. +//! makes it so each chunk has its own subsector. #define NUM_CHUNKS 7 #define CHUNK_SIZE_BYTES (SECTION_LOGS_SIZE_BYTES / NUM_CHUNKS) diff --git a/src/idl/nanopb/payload.proto b/src/idl/nanopb/payload.proto index e9486292..7f2a6dda 100644 --- a/src/idl/nanopb/payload.proto +++ b/src/idl/nanopb/payload.proto @@ -17,7 +17,7 @@ Payloads are how data should be sent and collected from devices. A simple normal flow would be for a watch to generate Events and Measurements, bundle them into a Payload that is sent to mobile. Mobile would then take that payload, as well as events and measurements generated on the mobile device -itself, and bundle them into it's own Payload message to send to the +itself, and bundle them into its own Payload message to send to the Pipeline API More complex patterns occur when the watch sends mupltiple Payloads, at