Skip to content

Commit

Permalink
wip
Browse files Browse the repository at this point in the history
  • Loading branch information
maxd-nordic committed May 8, 2024
1 parent 74be550 commit df14420
Show file tree
Hide file tree
Showing 2 changed files with 46 additions and 0 deletions.
43 changes: 43 additions & 0 deletions app/src/modules/intentions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
# Notes from inside the machine room

There is no real spec on what each part of the application does,
but we shall note down the intentions we had when building them
so we can create tests to check if we fullfil those intentions.

## App Module

This module manages the settings of the application.
It initializes the `simple_config` library, waits until it gets a cloud connection and then runs `simple_config_update` to tell the cloud the current config and fetch updates. After this initial part, it waits for trigger events to run `simple_config_update` again. It shall only call this function if there is an active cloud connection.

This is implemented with it's own thread since there is initialization to do.
To react to events, a simple subscriber is used. There might be value in changing this to a listener for less memory usage.

## Error Module

This tiny module has been copied verbatim from the MQTT sample. It uses a listener to react to error events. Depending on a config, the application is restarted on fatal errors.

## FOTA Module

This module shall react to trigger events to check for available FOTA updates.
Only check for updates if we are connected to cloud.
After successful initialization, mark the current image as confirmed. (Idea: This means we should be able to do another FOTA, which is the main thing to confirm.)
A listener is used here to stop other activity while processing the trigger.

This publishes a bool on the FOTA_ONGOING_CHAN to tell the rest of the app not to disturb the fota that's in progress. TODO: what about mfw and bootloader fota? Does that work?

## LED Module

This module listens to the LED_CHAN and applies the led state to LED1 on the board. Currently, the format is a simple int, controlling the red led.

## Location Module

This module shall react to trigger events to process location requests.
It has its own thread because location requests take a while to process.
Note: if we intend to use GNSS tracking, we need data transmission to shut up for a while.
A listener is used to trigger internal semaphores. TODO: this could also be done with a subscriber.

## Network module

This module tries to keep the device online and informs the rest of the application about the current network status on ZBUS. It offloads the heavy lifting to connection manager and forwards net_mgmt events.

##
3 changes: 3 additions & 0 deletions app/src/modules/location/location.c
Original file line number Diff line number Diff line change
Expand Up @@ -172,6 +172,9 @@ static void location_event_handler(const struct location_event_data *event_data)
case LOCATION_EVT_ERROR:
LOG_WRN("Getting location failed");
break;
case LOCATION_EVT_STARTED:
LOG_DBG("Getting location started");
break;
default:
LOG_DBG("Getting location: Unknown event %d", event_data->id);
break;
Expand Down

0 comments on commit df14420

Please sign in to comment.