+ Reorder code to match the widgets order in the UI.
+ Moved all objects (rows) into a container
+ Use InfintimeTheme Colors instead of hardcoded hex values
+ Added a new InfinitimeTheme color: gray, using it to turn certain
values gray when they contain no data
+ Implement @vkareh's [variable battery icon](https://github.com/InfiniTimeOrg/InfiniTime/pull/1964)
color to the battery percentage text.
+ Replaced the 'You have mail.' notification message with the message
'[1]+ Notify' to better fit the terminal lore.
The timer app issues a short buzz once and then disappears. There is no
trace left that the timer finished or how long ago. This change makes
the motor start ringing and presents a timer counter.
The timer stops buzzing after 10 seconds, and finally resets after
1 minute.
* redesign UI for firmware validation settings page
* remove period for the sake of uniformity
* remove unnecessary symbol I added for testing purposes
* remove unnecessary whitespace
* formatting
* temporarily comment out circle radius until we deicde
* change label from Reset to Rollback
* remove commented out lines
* more consistent function names
* lapCapacity as constexpr
* LastLap returns std::optional
* simplified handling of TickType_t values
* removed unused methods
* minor fix in lap rendering
The --user argument attempts to map the uid of the user inside the
container to the user in the host. This works if docker is running as
root, but is docker is running as the current user, then the uid in the
container is mapped to a surrogate uid on the host, and this surrogate
user does not have permissions to complete the build process.
Clarify that the --user flag is only required when running docker as
root. It is also likely not required by users using podman as a docker
drop-in replacement, since podman always runs in rootless mode.
The docker build section points to another page with instructions on how
to clone the repository, but this same page already contains these same
instructions in the previous section.
`docker build` warns of deprecated syntax:
1 warning found (use docker --debug to expand):
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 71)
Update Dockerfile, removing the deprecated syntax usage.
The first section explains how to clone the repository, the second how
to build Infinitime with the docker image, but the details on actually
provisioning the image are at the end, despite this step taking place
before the build itself.
Move the sections into the order in which the steps should be followed.
* Expose SystemTask dependency controllers
Expose NotificationManager and Settings for use by the feature in next commit.
This is a memory efficient way for accessing SystemTask dependencies from
controllers that have SystemTask injected as a dependency.
Looks like each direct dependency injection uses 4 bytes RAM.
As InfiniTime is close to running out of RAM (using 16 more bytes causes build
to fail with "ld: region RAM overflowed with stack") it might be helpful to use
this approach more.
* Add setting to disable DFU and FS access
Commit 0aead42fdf51 ("navigation: Add is available (#1847)") added the
ability to draw the app icon in grey and in a disabled state when some
prerequisits were not met. Only the Navigation app was using this mechanism
due to its icons being stored in the external memory and possibly missing.
Commit 63e0c4f4efb0 ("Application selection at build time") broke this by
always setting the state as true:
for (const auto& userApp : userApps) {
apps[i++] = Screens::Tile::Applications {userApp.icon, userApp.app, true};
}
Fix this by creating an isAvailable() strcuture in the app classes, similar
to how the Watchfaces handle the same problem of checking availability.
Same change as done in c3295d6d2a
But for get-base-ref-size job
The variable substitution I introduced are bash features. So they don't work with sh.
Update the size job to use `bash` instead of `sh` as shell
Firmware build works. But the build size job afterwards fails.
The firmware build uses `shell: bash --noprofile --norc -e -o pipefail {0}` as shell.
The size job uses `shell: sh -e {0}`
The variable substitution I introduced are bash features. So they don't work with sh.
Update the size job to use `bash` instead of `sh` as shell
The upstream NRF-SDK download url and zip archive filename changed,
which was fixed with https://github.com/InfiniTimeOrg/InfiniTime/pull/2270
But the archive contents stayed the same, with the "old" folder name.
After #2270 we have basically the same docker-container as before the PR,
but the `GetNrfSdk` function of the `build.sh` script is called again during
firmware build time as the expected foldername for the SDK isn't the same as
the zip filename:
```sh
[ ! -d "$TOOLS_DIR/$NRF_SDK_VER" ] && GetNrfSdk
```
Then during the build the `buils.sh` script tries to execute `GetNrfSdk` again,
which fails as the files already exist resulting in the following error:
```
replace /opt/nRF5_SDK_15.3.0_59ac345/components/802_15_4/api/HAL/hal_atomic.h? [y]es, [n]o, [A]ll, [N]one, [r]ename: NULL
```
Fix this by reverting the `NRF_SDK_VER` to the folder name in the zip
archive and by some character replacement generate the download URL from
the above (the download is in lower-case without the `_` and `.`
characters).
Furthermore add safeguards to check after the `GetNrfSdk` call if the
expected folder is really created. Then we have an error early during
container image creation if the contents of the zip-archive are
unexpected.
There was a newline at the end of the last line on the third screen,
which was causing the label to not be centered vertically.
Removing it fixes the centering.
* DisplayApp.cpp: Remove the vibration from OnChargingEvent
This fixes a bug where the vibration interupts the physical connection with the charger and therefore triggers a new charging event and vibration, ending in a cycle of vibrations while charging.
* remove OnChargingEvent message from DisplayApp
---------
Co-authored-by: minacode <minamoto9@web.de>
Redesign BatteryInfo App using an Arch widget instead of a bar.
The colors I used are as follows:
- Discharging (default): green
- Charging: lime
- Battery full: blue
- Battery low (<10%): red
Optimise the battery animation to not use 100% CPU (which causes DisplayApp to spin forever with AOD)
(DisplayApp also needs to be fixed in the future so it cannot spin infinitely)
Simplify alarm alerting screen and fix bug with
alerting on time value change
SetAlerting creates an lv_task to automatically call StopAlerting after one minute. This task will call an invalid function reference and lead to a crash under the following condition:
All exit paths but the time value change (so not considering this fix) call StopAlerting themselves, which also terminates the lv_task.
However, the value change callback only calls DisableAlarm, because its normal use case is for setting up an alarm, where you have to re-confirm enabling the alarm after every change you make.
DisableAlarm still sets isAlerting in the alarmController to false, probably because someone thought a currently alerting but also disabled alarm makes no sense, this was introduced in a0cd439.
That causes the destructor of Alarm to think there is nothing to do regarding the alerting when the alarm screen is dismissed.
Therefore it does not call StopAlerting and the lv_task is left with an invalid function pointer, because Alarm does not exist anymore once the lv_task finally goes to call the callback function
Fix error when compiling the Pinetime using the Docker image.
If done with Docker, the container does not trust the /sources
folder, leading to a blank response of the command that grabs
the git commit `git rev-parse --short HEAD`.
```
fatal: detected dubious ownership in repository at '/sources'
To add an exception for this directory, call:
git config --global --add safe.directory /sources
PROJECT_GIT_COMMIT_HASH_SUCCESS? 128
BUILD CONFIGURATION
-------------------
* Mode : Release
* Version : 1.3.0
* Toolchain : /opt/gcc-arm-none-eabi-10.3-2021.10
* GitRef(S) :
* NRF52 SDK : /opt/nRF5_SDK_15.3.0_59ac345
* Target device : PINETIME
* Build DFU (using adafruit-nrfutil) : Enabled
* Build resources : Enabled
```
If the `git config --global --add safe.directory /sources` is
added to the Dockerfile, the problem is solved and the hash is
added correctly.
The openrepos contain obsolete version (description on the openrepos page says that). New SailfishOS version is in chum repo. Additionally, there is Ubuntu Touch and Flatpak version.
There is now a Temperature struct in the weather service, which holds
the internal representation. There is also a temperature struct in the
Applications namespace, which holds the temperature in either Celsius or
Fahrenheit.
not <vector> as that is what is actually used.
Fixes build failure
InfiniTime/src/components/ble/SimpleWeatherService.h:86:18: error: field ‘location’ has incomplete type ‘Pinetime::Controllers::SimpleWeatherService::Location’ {aka ‘std::array<char, 33>’
In the screens that use `DisplayApp *app` and pass it to a child item,
or use the reference just in the constructor. Afterwards the `app`
member is not used. So remove it from the private member variables.
Completely remove `app` parameter from `SettingDisplay` constructor as
it is unused.
* AlarmController: Add saving alarm time to file
Save the set alarm time to the SPI NOR flash, so it does not reset to
the default value when the watch resets, e.g. due to watchdog timeout
or reflashing of a new version of InfiniTime.
Just like the `Settings.h` `LoadSettingsFromFile()` the previous alarm
at boot (if available) and `SaveSettingsToFile()` the current alarm when
the `Alarm.h` screen is closed (only if the settings have changed).
The alarm-settings file is stored in `.system/alarm.dat`. The `.system`
folder is created if it doesn't yet exist.
Fixes: https://github.com/InfiniTimeOrg/InfiniTime/issues/1330
* alarmController: close .system dir after usage
Close the `lfs_dir` object for the `.system` dir after usage. Otherwise
on the second changed alarm the system will lockup because the `.system`
dir is already open and was never closed.
---------
Co-authored-by: Galdor Takacs <g@ldor.de>
Fix for Hrs3300 PR about Atomic HRS reads:
https://github.com/InfiniTimeOrg/InfiniTime/pull/1845
We use `std::begin` and `std::end`, but we don't include one of the
headers that define those functions.
See https://en.cppreference.com/w/cpp/iterator/begin for a list of
headers that define `std::begin` and `std::end`.
Starting with GCC 14 this leads to a compilation error presumably
because they cleaned up their headers.
Fix code by inlcuding `<iterator>`
- Combine the reading of all `HRS3300` registers into one I2C read so data is not partial
- Downsizes both HRS and ALS to 16bit as the sensor does not generate larger than
16bit values in its current configuration
- Increasing the resolution by 1 bit doubles the sensor acquisition time,
since we are already at 10Hz we are never going to use a higher resolution
- The PPG algorithm buffers for ALS/HRS are already 16bit anyway
- Remove functions for setting gain / drive that are unused throughout the codebase
- Calculate constants with constexpr
State transitions now happen immediately where possible
This simplifies state management in general,
and prevents bugs such as the chime issue from occurring in the first place
Set `running` to false to flag end of watchface when there are no more
notifications left to display.
I found it slightly annoying that dismissing all notifications leaves me with
a "No notification to display" message. Instead of dismissing to a relatively
useless message, dismiss to watchface.
When turning off the screen, if there is no actual app loaded (i.e. we
are still in the Launcher, Notifications, QuickSettings, or Settings
screens) we should just reload the Clock app directly.
Add documentation about watch faces and applications.
Update getting started documentation.
Co-authored-by: tituscmd <154823939+tituscmd@users.noreply.github.com>
Add TODO.md in src/components/datetime. This file give detailed information about a refactoring of the DateTimeController that would be nice to do in the future.
* Only use one Dockerfile and build.sh script for both docker and devcontainer
* Remove all now unneccessary tasks and scripts
* Update to clang-format-14
* Move devcontainer.json into root folder
* Fix conditional statements in Dockerfile
* Move .devcontainer/README into doc/usingDevcontainers
* Remove obsolete VSCode Task
* Change standard compiler path to the correct compiler
* Set GDB Path for debugging
* Hide broken buttons from CMake Extension
* Refactor .devcontainer
* Remove unneccessary postBuildCommand
* Add devcontainer dependencies to all docker images
* Add Devcontainer Debug launch config
* Add an additional c_cpp_properties config as a fallback for devcontainer
* Remove obsolete Docker Argument
* Fix wrong C/Cpp versions
* Fix silent fail of gdb, add libncurses5
This fixes an issue where the BLE connected logo would disappear when opening and closing the BLE setting (without changing it) while InfiniTime was already connected to a companion app.
Co-authored-by: JustScott <development@justscott.me>
This prevents the application list from loading in the last used screen
and instead goes back to the first screen whenever the watch face is
loaded.
Fixes#2006
If a DFU is restarted, the write indices aren't reset causing the image to be written out of bounds. The CRC check prevents the faulty image from booting but LittleFS still gets nuked.
The weather widget is too high and could overlap the status icons.
Moving it to match the rest of the face avoids this issue and makes it
align with the rest of the theme.
Add new App `Dice.h` to randomly roll the dice(s).
The number of dice can range from 1-9 (default 1), and the sides can
range from d2-d99 (default d2).
To have a haptic feedback we make Dice vibrate on roll.
Regarding the use of C++ `<random>` library:
There are known problems with `rand()` and `srand()` (see https://en.cppreference.com/w/cpp/numeric/random/rand)
and the `<random>` library is preferred for this reason. The function used from
`<random>` also avoids a very rare bias that would occur using `rand()` and modulo,
when `RAND_MAX` is not a multiple of `d` and the initially generated number falls in
the last "short" segment. This commit also updates the seed to derive entropy
(via `seed_seq`) from a mix of the system tick count and the x,y,z components of the
PineTime motion controller -- taking inspiration from and with credit to @w4tsn
(https://github.com/InfiniTimeOrg/InfiniTime/pull/1199)
Thanks for suggestions:
* in Dice, when rolling 1d2, also show "HEADS" or "TAILS" -- suggestion by @medeyko
* ui adjustments and result realignment -- suggestion by @Boteium
---------
Co-authored-by: NeroBurner <pyro4hell@gmail.com>
Co-authored-by: Riku Isokoski <riksu9000@gmail.com>
Co-authored-by: Paul Weiß <45500341+Poohl@users.noreply.github.com>
Co-authored-by: FintasticMan <finlay.neon.kid@gmail.com>
Support other image modes like `P`, which uses 8 bits per pixel and a
color palette to save space.
Luckily the Pillow module can do the mode conversion for us.
Fixes: https://github.com/InfiniTimeOrg/InfiniTime/issues/1985
Since returning a valid weather is always considered an updated value,
if the current weather is empty, the face will attempt to display the
temperature and icon as empty values, rather than clearing the labels.
Improve wording and replace "watchface" by "watch face" in Apps.md.
Improve CMake readability regarding watch face selection
Co-authored-by: Reinhold Gschweicher <pyro4hell@gmail.com>
The list of watch face to build into the firmware is now set by CMake (-DENABLE_WATCHFACES).
Fix SettingWatchFace : convert to index to/from WatchFace when needed.
Restore the default list of apps to compile. The ordering was changed in
the changeset to make the app-list configurable through a CMake-variable
in https://github.com/InfiniTimeOrg/InfiniTime/pull/1928
In the process have one app per line to create the default app list in
CMake. This makes git diffs easer and more readable.
In the documentation, specify that the timestamp is expressed in seconds from epoch (instead of nanoseconds).
SimpleWeatherService now uses "localtime" (GetCurrentDateTime()) instead of UTC time.
Use CMake's configure_file() functionality to generate the list of User Applications.
All the apps included in current versions of InfiniTime are enabled by default, but this can now be overridden by setting variables ENABLE_APP_XXX to True or False.
CMake CMP0140 is set to NEW to enable the return PROPAGATE functionality.
Move the function GetIcon that converts SimpleWeatherService::Icons to char (symbol) into a new header file so that it can be used by other apps and companion apps.
Code improvements : icon fields are now typed as Icons, move the location string when creating a new instance of CurrentWeather, fix SimpleWeatherService::CurrentWeather::operator== (location was missing from the comparison).
Add missing icons (heavy clouds, thunderstorm, snow).
Remove unneeded comparison operator (!=), improve conversion of Timestamp and MessageType, order includes.
Fix typo in documentation.
Remove not related change in StopWatch.
This new implementation of the weather feature provides a new BLE API and a new weather service.
The API uses a single characteristic that allows companion apps to write the weather conditions (current and forecast for the next 5 days).
The SimpleWeather service exposes those data as std::optional fields.
This new implementation replaces the previous WeahterService.
The API is documented in docs/SimpleWeatherService.md.
Watch faces can now be selected at buid time. It's implemented in a similar way than the selection of user apps, using a list of watch face description that is generated at build time (consteval, constexpr)
Building with a TARGET_DEVICE set to any of the P8 variants' names
caused the build to fail, because they contained hyphens.
The build defines a macro `TARGET_DEVICE_$VARIANT`, which fails if
`$VARIANT` contains a hyphen.
1. Replace sprintf with snprintf, which is safer
2. An unsigned int or unsigned long int requires 11 bytes to print
(including the null terminator)
3. Use PRIu16 macro to print uint16_t
4. Format string "#%2d %2d:%02d:%02d.%02d\n" in
StopWatch::stopLapBtnEventHandler() requires at least 17 bytes.
The 16-byte buffer would clearly be overrun if sprintf were used.
Update documentation about the apps (Apps.md) : fix obsolete information, add doc about user/system apps and update the part about the implementation of a new app.
A list of "user applications" is built at compile time. It contains all the info needed to create the application at runtime (ptr to a create() function) and to display the app in the application menu. All applications declare a TypeTrait with these information.
When a new app must be loaded, DisplayApp first check if this app is a System app (in which case it creates it like it did before). If it's not a System app, it looks for the app in the list of User applications and creates it if it found it.
Those changes allow to more easily add new app and to select which app must be built into the firmware.
Switch to C++20 (and fix a few issues in SpiMaster.cpp and Watchdog.cpp.
When a notification is received, SystemTask sends messages to DisplayApp, which loads the Notifications apps that sends a few messages to SystemApp.
When notification are received too quickly, DisplayApp and SystemTask cannot process those messages fast enough (probably because of the time it takes to refresh the display) and the message queues fill up. When they are full, the current implementation just waits until there's room available to store the event. In this case, since both tasks exchange messages, they end up in a deadlock.
This fix consists in setting the timeout value to 0 (non-blocking mode) for the NewNotification messages on the DisplayApp side. This will prevent the SystemTask from being blocked (which would result in the watchdog reseting the watch). A more generic approach should be design in the future.
Create a minimal python port of the node.js module `lv_img_conv`. Only
the currently in use color formats `CF_INDEXED_1_BIT` and
`CF_TRUE_COLOR_ALPHA` are implemented.
Output only as binary with format `ARGB8565_RBSWAP`.
This is enough to create the `resources-1.13.0.zip`.
Python3 implements "propper" "banker's rounding" by rounding to the nearest
even number. Javascript rounds to the nearest integer.
To have the same output as the original JavaScript implementation add a custom
rounding function, which does "school" rounding (to the nearest integer)
Update CMake file in `resources` folder to call `lv_img_conf.py` instead of
node module.
For docker-files install `python3-pil` package for `lv_img_conv.py` script.
And remove the `lv_img_conv` node installation.
---
gen_img: special handling for python lv_img_conv script
Not needed on Linux systems, as the shebang of the python script is read
and used. But just to be sure use the python interpreter found by CMake.
Also helps if tried to run on Windows host.
---
doc: buildAndProgram: remove node script lv_img_conv mention
Remove node script `lv_img_conv` mention and replace it for
runtime-depency `python3-pil` of python script `lv_img_conv.py`.
Navigation app now needs 2 images to be loaded from the resources on the external filesystem. This PR adds an 'enabled' field to the Applications struct. This field is true for all applications expect for Navigation which calls Navigation::IsAvailable(). This methods returns true if the 2 files are available in the resources.
The application list disables the application (draws it in grey, disables the touch callback) if the enable flag is not set.
The TTF font used by the navigation app is ~20KB and is stored in internal flash memory.
To free this space, the TTF font is now converted in 2 "atlas pictures" (pictures that contain multiple concatenated images) stored in the external flash memory. The navigation app now accesses one of those 2 files and apply an offset to display the desired picture.
The corresponding documentation has also been updated.
Add comments about the layout of the pictures that contain the icon and about the indexing of those icons.
In documentation (buildAndProgram.md), edit the section about the debug compilation mode. Remove the part about removing the Navigation app to free some memory (since it's not relevant anymore) and explain how to selectively build parts of the firmware in Debug mode.
This new algorithm calculates the number of degrees that the wrist has
rolled, and checks if that is above a threshold.
First it checks if the wrist is still enough for the acceleration values
to be considered mostly from gravity. It does this by calculating the
mean over the past 2 SystemTask loops, and checking that the variance
from that mean is below a threshold.
Then it calculates the angle the wrist is being held at, and calculates
the difference from the angle some time ago. If this difference is above
the threshold, it wakes the watch.
The accumulated speed was calculated by dividing first and multiplying
after, which results in more rounding errors than if you multiply first
and then divide. The values aren't big enough to overflow.
* change background image to widgets
This commit removes the background image for the WatchFaceAnalog and replaces it with lvgl widgets. It aims to keep the original look.
* remove comments and background image
---------
Co-authored-by: minacode <minamoto9@web.de>
This commit changes the order for the notification struct fields to allow the creation of notifications using a string literal.
```cpp
NotificationManager::Notifiation notification {
"String literal with notification text",
42,
NotificationManager::Categories::SimpleAlert
};
```
Co-authored-by: minacode <minamoto9@web.de>
* ShakeWake: Fixed instant wake after sleep issue in certain positions
Add lastX var to track the previous x acceleration for correct calculation of speed.
Reorder axes for clarity.
---------
Co-authored-by: Isaac <114504394+isaacc27@users.noreply.github.com>
Co-authored-by: FintasticMan <52415484+FintasticMan@users.noreply.github.com>
The mcuboot imgtool uses the python module `cbor`.
An equivalent and updated package `cbor2` requires Python 3.7 or newer.
The arch packages provide a package `python-cbor2`, but no package for
`cbor`.
This patch makes it possible to use the system package by adding
support for the `cbor2` package additionally to the `cbor` package.
Calls to Spi::Init() are not needed, pin initialization is already done in ctor().
Remove calls to Spi::Sleep()/Spi::Wakeup() to ensure that SPI CS pins are kept high even in sleep mode.
Ensure that all pins are set to their default configuration during sleep mode.
Disable the workaround for FTPAN58 (SPI freezes when transfering a single byte) at the end of the transfer. This disables the resources needed for the workaround.
Those changes reduce the power usage by 430-490µA.
The DC/DC regulator reduce the power consumption of the MCU compared to the default LDO regulator. The DC/DC regulator needs additional HW that is mounted on the PineTime.
This change reduces the power usage by 380µA during fast advertising, by 200µA during slow advertising and by 186µA when BLE is disabled.
Put the HRS3300 to sleep mode when InfiniTime is going to sleep. This change reduces the power consumption by 130µA when the heart rate sensor is disabled.
LVGL supports custom implementation of malloc() and free() so using pvPortMalloc() and vPortFree() is just a matter of setting the right variables.
Other libraries (NimBLE, LittleFS) and InfiniTime code (new) call malloc() and free() from stdlib. InfiniTime now provides the file stdlib.c that provides a custom implementation for malloc(), free(), calloc() and realloc(). This ensures that all calls to the standard allocator are redirected to the FreeRTOS memory manager.
Note that realloc() is needed by NimBLE.
* Refactor and document the Watchdog driver to make it more readable.
Fix the configuration of the behaviours configuration that was not properly implemented (but it didn't cause any side effect since the correct value was eventually set in NRF_WDT->CONFIG).
Fix the wrong interpretation of the reset reasons caused by implicit conversions of int to bool.
New implementation of the heart rate sensor data processing using a frequency based PPG algorithm.
The HRS3300 settings are fine-tuned for better signal to noise at 10Hz.
The measurement delay is now set to 100ms.
Enable and use the ambient light sensor.
FFT implementation based on ArduinoFFT (https://github.com/kosme/arduinoFFT, GPLv3.0).
Replace custom FreeRTOS inactivity timers with LVGL inactivity timers.
DisplayApp: Trigger display activity on timer done.
inactivity: Add additional checks
The backlight could be turned on by RestoreBrightness() on ble connect
event.
inactivity: Trigger activity on screen switch
A notification timing out could put the watch to sleep immediately.
While this could be ideal behaviour, it was caused by delay in
processing the EnableSleeping event and pushing RestoreBrightness to
DisplayApp.
Prevents reading uninitialised memory if notification gets cut off due
to being more than 100 chars. The last character is assumed to be \0, but
it is actually uninitialised.
Fixes#1467 "Double tapping PineTimeStyle steps style button sends watch to sleep"
Double tap is disabled on the color settings screen by checking if the Rnd button is visible, but this didn't work for the options screen as the Rnd button isn't visible. I've changed it to check if the Close button is visible instead, which is used on both settings screens, and resolves the bug. I also changed the button used to disable the long press behaviour which was an as-yet-undiscovered bug which would have allowed the long press action to be used when the options screen was visible.
I don't think this badge has shown the actual status of the current
workflows for a long time. The real status can easily be seen by
clicking on the checkmark or cross icon on the front page. It's also
supposed to show the status of the master branch, not develop (default).
Previously, the LVGL driver for the filesystem was initialized in the class FS. However, since 6f942e2, the order of the initializations was incorrect : the driver was initialized (FS::LVGLFileSystemInit()) before LVGL (LittleVgl.Init()), which means that the driver registration was probably dropped when LVGL was initialized.
The LVGL driver is now initialized in LittleVgl.Init(), which seems to make much more sense, since all LVGL drivers are initialized there. This way, we ensure that the initialization of the drivers is consistent.
LVGL is only a part of the main DisplayApp. Other "DisplayApps" can be
implemented without LVGL.
DummyLittleVgl isn't needed anymore and has been removed
The DisplayApp class isn't used in the Screen base class and most
screens, so requiring it is pointless.
In this commit, DisplayApp pointers were added to screens which use it
and the explicit Screen constructor was removed in those screens.
Long pressing will change the value by 1000, whereas clicks will change
it by 500. This allows setting more precise values, while also making it
easier to set any value.
The time used to be yellow while paused. Changing it to white made the
paused state less distinct. Blinking the time while paused makes the
state distinct again.
The workflow checks that the buildsize comparison succeeds. The download
artifact step also checks that all of the main workflow succeeds. This
isn't necessary, and causes the comment not to be created when the
simulator build fails. This change disabled the success conclusion
requirement.
The previous version failed, because it looked for the check from the
branch in the fork, but looked for it in the main repo. Now uses the sha
to get the commit on which checks were run.
Previous description
This works by uploading the data from the main workflow with low
permissions as an artifact, then downloading the data in a workflow with
higher permissions to post the comment.
Third party actions are fixed at a commit, in case they get compromised.
Also set the build-firmware VM to ubuntu-22.04, which was missed when
updating workflow deps earlier.
This works by uploading the data from the main workflow with low
permissions as an artifact, then downloading the data in a workflow with
higher permissions to post the comment.
Third party actions are fixed at a commit, in case they get compromised.
Also set the build-firmware VM to ubuntu-22.04, which was missed when
updating workflow deps earlier.
The only change between the 2 linker scripts is the ORIGIN address of the flash memory allocated to InfiniTime. The MCUBoot one starts at 0x8000, which is the address that will be loaded by MCUBoot after the boot process. This linker script allow to run the application without MCUBoot by setting the origin address to 0x00. The APP_SIZE is the same for both linker scripts, but it could be set to a higher value in this one for development purposes.
The github.event.pull_request.base.sha in the workflow doesn't get
updated when there are new commits in the base branch. Instead always
checkout the branch to check the sha manually and cache only the build.
The ownership fix seems to still be necessary
Replace separate SettingSetDate and SettingSetTime with a combined screenlist.
Add DotIndicators. Similar to PageIndicator, but for use when separating screens instead of pages of a list.
Co-authored-by: Riku Isokoski <riksu9000@gmail.com>
When people suggest a solution to a generic issue they encounter, they have to open a feature request, which is not optimal. Submitting an issue through this new form will require writing about the issue that led to the idea, which will make it easier to discuss different solutions.
* Update workflow dependencies
ubuntu-latest vm has been updated from 20.04 to 22.04.
To avoid sudden issues, use 22.04 explicitly.
CMake doesn't need to be updated on 22.04, but ninja must be installed separately in the simulator workflow.
actions/checkout@v2 uses deprecated Node.js 12.
Update to v3 which uses 16
Add .github/workflows/getSize.sh to extract sizes of sections from the
objfile
build-firmware uses getSize.sh to output the section sizes.
get-base-ref-size job added, which builds the base branch of the PR and
outputs the section sizes. Caches are used to avoid unnecessary builds
when the base branch hasn't been updated.
leave-build-size-comment job added, which creates or updates a comment
on the PR with the build size information from other jobs.
Each opened app (screen) is pushed on a stack, which is then popped from
when returning instead of hard coded "previous apps". Return swipe and
refresh directions are automatically determined from the app transition.
Removed/simplified some generator expressions that had more repeated
elements than they needed to. Extracted some repeated sets of options
into separate variables as well.
Return the build status as return code from the `main` helper function.
In the process convert the handling if the file was sourced or directly
executed into an explicit if/else statement to make the intent clearer.
In case of an build error the error is now reported at the build step,
where the error happened.
Fixes: https://github.com/InfiniTimeOrg/InfiniTime/issues/1292
Add linear approximation class and use it to better model the non-linear
discharge curve of the battery.
Changed the minimum voltage level to 3.5V and the maximum to 4.18V. For
reference the maximum observed voltage is 4.21V during charging.
value_str is a way to add text on a button without a separate label.
This saves having an extra label object, but uses more memory and is
removed in LVGL8
* System Info: Use YYYY-MM-DD
The date format with the slashes has different meaning in different regions
* Terminal Watchface: Use dashes as date separator
Using the popular ISO 8601 format instead
Co-authored-by: Riku Isokoski <riksu9000@gmail.com>
* Reset timer by long pressing on the button
* Consider press_lost as released
Otherwise the bar would keep increasing if the finger slid off the
button
Also fix issue where workflow fails on pull requests when the
user who made the pull request doesn't have the secrets set.
Also allow other workflows to be triggered manually.
Also don't trigger any workflows on pull requests to master, as
there shouldn't be any pull requests against master.
This configures Nimble to enable the HFCLOCK and other
Bluetooth peripherals only when needed, but 1500 us in advance.
This time is recommended by the Mynewt docs.
Add a new interface `NotificationManager::Dismiss(id)` to delete a
notification with the specified `id`.
The animate the notification dismiss the `RightAnim` transition to a
black screen is used. After the dismiss the new message is swiped in
from below or above.
If we dismiss the oldest message (when we are at 5/5, or 3/3), then the
new message after a dismiss should appear to come from below.
Otherwise (when we are at 2/3) the new message after a dismiss should
appear to come from above.
Rework the index code to show the index of the currently viewed
notification. Instead of calculating the index relative to the oldest
`id` introduce a new interface `NotificationManager::IndexOf(id)`. This
is done because the `id` of the notifications in the buffer aren't
continuous anymore (as some messages could have been dismissed).
Rework notification ring buffer to have a beginIdx and a size
internally to make the dismissal of notifications easier.
Fixes: https://github.com/InfiniTimeOrg/InfiniTime/issues/176
Co-authored-by: Simon Willshire <me@simonwillshire.com>
Co-authored-by: Reinhold Gschweicher <pyro4hell@gmail.com>
This feature is not needed and is probably more likely to cause issues. It's better to just use brightnessController.Set(settingsController.GetBrightness());
* Use FreeRTOS timer for AlarmController
* Use FreeRTOS timer for MotorController
* Remove app_timer component from compilation as we now solely use
FreeROTS timer
* Simplify variable and text names for AlarmController and MotorController timers
* Call ScheduleAlarm directly from StopAlerting, for recurring timers
Co-authored-by: Riku Isokoski <riksu9000@gmail.com>
Co-authored-by: NeroBurner <pyro4hell@gmail.com>
This should ensure better readability of the pin setup procedure,
as well as allow the configuration of the hardware button enable pin
and the accelerometer interrupt pin via the pin mapping header.
In https://github.com/InfiniTimeOrg/InfiniTime/pull/1097 new font
generation capabilites were added. Generalize the font creation to
make it possible to reuse the `displayapp/fonts/CMakeLists.txt` file
for `InfiniSim` and just add the new cmake file to the project and
link against the new `infinitime_fonts` target.
In the following a list of changes.
Allow non-global installed `lv_font_conv` executable installed with
```sh
npm install lv_font_conv@1.5.2
```
In CMake we search for `lv_font_conv` executable. Add the found
executable to the python script `generate.py`, to remove the need for
`lv_font_conv` to be in the path.
Search for `python3` executable, if CMake version 3.12 is available.
Otherwise use `python` as hard coded executable.
Instead of adding the generated fonts to `SOURCE_FILES` variable, create
a static library `infinitime_fonts`. Link this library to the
executables instead.
Use `add_custom_target()` together with `add_custom_command()` to
generate the font.c files once (like the original PR does).
Also, removed feature existance cheking (since it now depends on a font,
so may end up being inside (only) a font not being used currently -
which is an allowed usage)
The scrollbar would go out of bounds if DROPDOWN_PART_LIST had uneven
padding. Also enable clip_corner feature to stop the selected item from
overflowing.
When the screen switches, the full screen needs to be refreshed for the
hardware scrolling to work. This was enforced with backgroundLabels, but
is simpler to do with a rounder function.
List.h uses `std::array` as container, but is missing the `<array>`
include. Add it to make the header self contained.
The `memory` include is unused and can be removed.
There is a large step in brightness from level zero to level one.
After experimenting with various ST7789 options, I found that
decreasing VDV to 0x10 (-0.4V) fixes this issue.
The gamma change reduced the average error in brightness, but with the
underlying issue fixed, the gamma change has been reverted.
`SpiNorFlash.h` is a C++ header, but the `Identification` struct is
created in a C style using `typedef struct`. Clang issues a warining
about this discrepancy:
```
In file included from /home/nero/repos/pinetime/InfiniSim/InfiniTime/src/systemtask/SystemTask.cpp:13:
/home/nero/repos/pinetime/InfiniSim/sim/drivers/SpiNorFlash.h:16:21: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef struct __attribute__((packed)) {
^
Identification
/home/nero/repos/pinetime/InfiniSim/sim/drivers/SpiNorFlash.h:17:9: note: type is not C-compatible due to this default member initializer
uint8_t manufacturer = 0;
^~~~~~~~~~~~~~~~~~~~
/home/nero/repos/pinetime/InfiniSim/sim/drivers/SpiNorFlash.h:20:9: note: type is given name 'Identification' for linkage purposes by this typedef declaration
} Identification;
^
1 warning generated.
```
The easy fix is to use a C++ style struct.
Also includes code style fix from Riksu9000
Co-authored-by: Riku Isokoski <riksu9000@gmail.com>
Let the TouchHandler::GestureGet() function return a TouchEvent instead
of the touchpanel-driver specific enum.
This helps to move the driver specific helper function `ConvertGesture`
from `DisplayApp` into `TouchHandler`.
In cases where any other task takes too much time to execute (it can happen in Display Task, see https://github.com/InfiniTimeOrg/InfiniTime/issues/825), the timer task does not have the opportunity to run fast enough to detect and debounce presses on the button.
This commit sets the following priorities:
- [0] : Display Task
- [1] : Timer and System tasks
- [2] : BLE Host
- [3] : BLE LL
This way, we ensure that button presses will always be detected, even if the rendering of the display takes a huge amount of time.
We have a comparison like `if (( a == b ))`, which is a parenthesis too
much, which generates the following warning
```
InfiniTime/src/displayapp/screens/Twos.cpp:133:35: warning: equality comparison with extraneous parentheses [-Wparentheses-equality]
if ((grid[newRow][newCol].value == grid[oldRow][oldCol].value)) {
~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
InfiniTime/src/displayapp/screens/Twos.cpp:133:35: note: remove extraneous parentheses around the comparison to silence this warning
if ((grid[newRow][newCol].value == grid[oldRow][oldCol].value)) {
~ ^ ~
```
Clang warns on `OnTouchEvent()` function, which is overridden, but is
missing the `override` keyword
```
In file included from InfiniTime/src/displayapp/screens/Music.cpp:18:
InfiniTime/src/displayapp/screens/Music.h:43:14: warning: 'OnTouchEvent' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
bool OnTouchEvent(TouchEvents event);
^
```
There are 3 options, but the array-size is set to 2. This leads to
memory corruption in the initialization of the SettingChimes screen when
assigning the third option object pointer.
Found in https://github.com/InfiniTimeOrg/InfiniSim/issues/11
InfiniSim PR https://github.com/InfiniTimeOrg/InfiniSim/pull/10 adds
support for screenshots in png/bmp format using `libpng` submodule.
This new submodule must be added to the lv_sim workflow as well.
Split SystemMonitor into h and cpp file and move the logging code of the
`Process` function into the cpp file.
Depending of the `configUSE_TRACE_FACILITY` define from
`src/FreeRTOSConfig.h` create either a "FreeRtosMonitor" or a
"DummyMonitor".
Make the `Process()` function non-const, as the FreeRtosMonitor changes
the member variable `lastTick`.
In `SystemTask.h` we then only need to use `SystemMonitor`, without
knowledge of the `configUSE_TRACE_FACILITY` define.
Some components were missing a `nrf_log.h` include. This missing
include was accidentally provided by the SystemMonitor.h header, which
was included by Systemtask.h
For each filesystem interaction be more specific if we want to read from
the file or write to it.
Doing a non-creating read on the loading of the settings file, otherwise
an empty file could be created, and when reading that empty file for the
initial settings I would expect an error (or random data) when reading.
The variable `title` is defined as `const char*`, which means, that
`strchr()` returns a `const char*` as well according to
https://www.cplusplus.com/reference/cstring/strchr/
But in the same line the return value is assigned to a non-const
`char*`, which shouldn't be allowed (error with `-pedantic`).
Because the `lv_label` creates an internal copy of the title sting, just
modify that one instead and replace newline in the copied string.
Apply a few changes that were requested in the PR during the review.
# Conflicts:
# src/CMakeLists.txt
# src/displayapp/Apps.h
# src/displayapp/DisplayApp.cpp
# src/displayapp/Messages.h
# src/displayapp/screens/settings/Settings.cpp
For the simulator I need a way to get to the brightnessController object
and handle the set brightness-levels accoringly.
This is done by the constructor expecting a brightnessController object
instead of initializing one itself
For ease of use the simulator uses a globbing expression to get all
screens source files. This one was picked up as well and lead to a
compilation error.
SystemTask.h included BatteryController.h, and BatteryController.h
included SystemTask.h. If unlucky the class SystemTask isn't created yet
when BatteryController wants to use it.
Fix that cyclic dependency by forward declaring the BatteryController
class and including it in the SystemTask.cpp file, where it is needed.
SettingShakeThreshold.h uses SystemTask, but doesn't include the header.
Fixing that for the simulator.
For consistency make the header include a relative to src include.
The static_cast syntax requires brackets around the input variable. The
implementation worked because the used input are defines, which add the
missing brackets like the following:
```cpp
#define GPIO_PIN_CNF_SENSE_Low (3UL)
```
In the first `Music::Refresh` call the lastLength and totalLength are
not initialized. The `lastLength` value is read first from the
musicService. Naturally in the first itereation that is changed and
`UpdateLength()` is called. There the variable `totalLength` is used as
well, but that variable isn't initialed to a sensible value yet. This
leads to sometimes the `Music.h` screen segfaulting (depending on the
random uninitialized data in the `lastLength` variable)
really just debugging. I want to make it more configurable then high med low.
Position of setting needs a new location...dynamicly adding it currently at the end. Which honestly im fine with.
Rather than using generator-specific build commands (ex. `make` or `ninja`), the CI build now uses `cmake --build` for a more modern, best practices approach.
Implements 'Airplane mode' feature to disable and enable bluetooth/ble
Adds airplaneMode as a non-persisted setting
Adds a setting menu for switching airplane mode on and off
Displays an airplane symbol on the Digital watch face and the
PineTimeStyle watch face when airplane mode is enabled
Always enables bluetooth/ble on boot (disable airplane mode)
Alphabetizes the settings menu options
Style cleanups
Closes#632
Save bond information in the FS after a disconnect or encryption change
if the bond is not already stored. The bond is restored on boot enabling
automatic reconnection to a previously bonded central.
Two consecutive watch reboots with the central out of range (or BLE off)
will remove the stored bond from the watch.
When a passkey is displayed, screen on or off, and another
passkey is displayed the screen may become scrambled. Fix
the issue by insuring the whole screen is drawn every time.
This commit adds the following:
Passkey pairing - passkey is displayed on watch
Swipe down to clear passkey screen
Connection encryption
Connection bonding
Automatic reconnects to a bonded peripheral
Trusted device on Android
Note that persisting the bond between reboots is NOT included in
this commit. Therefore, rebooting the watch will cause reconnect failures.
You must delete the bond from the phone to reconnect/pair.
Add missing include in `Clock.cpp` for `Settings.h`. The Settings class
is forward declared in the header file, but it needs to be included in
the cpp file.
To make the game a bit more challenging an less predictable add a little
bit of randomness to the `dy` value. When hitting the right wall add a random
number (one of [-1, 0, 1]) to the `dy` value.
To keep the difficulty level managable limit the dy value to be in the
range from -5 to 5.
Remove unused `ScreenList.h` include.
For `std::abs()` add needed include `<cmath>`.
For the forward declared Settings-Controller add the `Settings.h`
include to the cpp file.
Don't use relative imports like `../foo.h` as those depend on the
relative position of both files. Rather than that use imports relative
to the `src` directory, which explicitly is part of the include
directories.
Fix the comment as the comparison checks if the ball is at the right
side of the screen.
Compare the x coordinate of the ball with the horizontal resolution of
the screen, instead of the vertical resolution. On the PinePhone this
does make no difference as we have square 240x240 screen. Change it
anyways to be completely correct.
The script `tools/mcuboot/imgtool/main.py` imports the python packages
`click` and `cryptography` to create the target `pinetime-mcuboot-app`.
Add it tothe build instructions, as it was not installed on my system.
6f9f0e8b0e/tools/mcuboot/imgtool/main.py (L19)6f9f0e8b0e/tools/mcuboot/imgtool/keys/__init__.py (L19)
Also add the commands to install the python requirements into a python
venv virtual environment.
Previously, pressing the back button would close the alarm app anyway. Now if you press on it and the popup with information is open, it will first close and the second press will close the application
Always returning 0 (when `MYNEWT_VAL_BLE_LL_RFMGMT_ENABLE_TIME` is not defined), rather than a time near to the current tick, causes an issue in at least one place: `ble_ll_adv_sm_start()`, where the calculation of `delta` overflows when the system timer is at 0x80000000 or above -- causing an incorrect, huge adjustment to be made to the scheduled time, ultimately stopping adverts from being sent.
This issue was caused by DateTime::SetCurrentTime() that would not update the internal state of the class : dayOfWeek, Month, Year were not properly updated according to the current time.
`xTaskGetTickCount()` returns a `TickType_t`, which is defined as an
`uint32_t`. This is compared to the `bpm` variable, which is a `int16_t`
in the range of 40 to 220 as defined in the constructor.
```cpp
lv_arc_set_range(bpmArc, 40, 220);
```
Just assume that `bpm` is greater than 0, as this
would result in a divison by zero or negative values, which would
unintentionally underflow to a very large number.
* docs: Fix a few typos
There are small typos in:
- doc/versioning.md
- src/components/ble/NimbleController.cpp
- src/libs/mynewt-nimble/CODING_STANDARDS.md
- src/libs/mynewt-nimble/docs/btshell/btshell_GAP.rst
- src/systemtask/SystemTask.cpp
Fixes:
- Should read `milliseconds` rather than `miliseconds`.
- Should read `unnecessary` rather than `uncesseray`.
- Should read `target` rather than `tharget`.
- Should read `project` rather than `projct`.
- Should read `preferred` rather than `prefered`.
- Should read `functioning` rather than `functionning`.
- Should read `forever` rather than `forver`.
- Should read `existing` rather than `exisiting`.
On power up, advertise aggressively for at least 30 seconds then switch
to a longer interval to conserve battery life. This fast/slow pattern
is designed to balance connection response time and battery life.
When a disconnect event is received restart the fast/slow pattern.
When a failed connect event is received, restart the fast/slow pattern.
When the screen is activated and ble is not connected, restart the fast/slow pattern.
This pattern is consistent with Apple's BLE developer standards (QA 1931).
Start advertising aggressively when powered on then
slow down linearly over 75 seconds. This will conserve
battery by not advertising rapidly the whole time we
are seeking a connection. The slowest rate is
approximately once every 4.5 seconds to balance
responsiveness and battery life.
We use a fixed advertising duration of 5 seconds and start
with a 62.5 ms advertising interval. Every 5 seconds
(the advertising duration) we step up to a larger
advertising interval (slower advertising). We continue
to increase the advertising interval linearly for
75 seconds from the start of advertising. At 75 seconds
we have an advertising interval of 4.44 seconds which we
keep until connected. A reboot will restart the sequence.
When we receive a disconnect event we restart the sequence
with fast advertising and then slow down as described above.
Note that we are not using the BLE high duty cycle setting to
change the advertising rate. The rate is managed by repeatedly
setting the minimum and maximum intervals.
The linear rate of decrease and the slowest interval size
were determined experimentally by the author. The 5.3 Core
spec suggests that you not advertise slower than once
every 1.2 seconds to preserve responsiveness but we
ignored that suggestion.
PTS/SettingsPTS : Convert to/from LVGL color and Settings::Color, add functions to reduce code duplication.
Adapt SettingPineTimeStyle with the last Screen Interface
Instead of casting the UUID object to the ble_uuid_t* used throughout
the NimBLE API just pass the address of the ble_uuid_t member that's at
the start of each of the UUID structs.
Fixed mismatch between the service and characteristic IDs in the
navigation service comments and documentation. They had old values not
reflecting the current code and changes in doc/ble.md
* Make firmware updating more foolproof and fix bugs
* No need to manually handle overflow
* Make startTime TickType_t
* Don't process TouchEvents::None
* Fix sleep getting re-enabled issue more directly
* Allow multiple wakeup modes at the same time.
This commit adds multiple wakeup modes support.
It does so by storing them as a uint8_t bitfield enum.
It changes the following functions:
Since multiple modes can be on now, older version would not cut it:
WakeUpMode getWakeupMode() -> std::bitset<3> getWakeUpModes()
Where each bit corresponds to a WakeUpMode
We still need a way to check whether a specific wakeup mode is on, so:
bool isWakeUpModeOn(const WakeUpMode mode)
This function was changed to work correctly with the new implementation.
setWakeUpMode(WakeupMode mode, bool enable)
Previously, systemtask would exit SystemTask::OnTouchEvent() if the wake
up mode was None or RaiseWrist, to prevent waking up when a touch was
received. However, after enabling using multiple WakeUpModes, this
caused a bug where when RaiseWrist was checked with SingleTap or
DoubleTap, the tap detection wouldn't work.
This commit fixes that bug.
Next commit will update the settings WakeUpMode select UI to reflect these changes.
Signed-off-by: Kozova1 <mug66kk@gmail.com>
* Updated UI to reflect multiple WakeUp sources being available.
Signed-off-by: Kozova1 <mug66kk@gmail.com>
Replaced the use of the standard library trig functions with a LUT-based
implementation instead. The standard library implementations produce
more accurate results but the usage here doesn't need that. This ends up
saving nearly 7kB of binary size.
* add submodule littlefs
* base fs
* Save settings using littlefs
* Small fixes and suggestions from PR
* More small fixes from PR suggestions
* Code clean up
* Change SpiNorFlash functions to be private in FS
* PineTimeStyle
* Move GPL license header
* Add step count gauge - replaces heartrate in sidebar
* Enable 12/24h functionality
* Set step gauge outer to be white when step goal is reached
* Add font source file
* Move static needle_colors array to member variable
* Add documentation on generating a font
* Replace .ttf with Google version, add link to font page
Co-authored-by: JF002 <JF002@users.noreply.github.com>
* Retrieve and display bootloader version
- Display bootloader version on System Info screen
- Enable SPI flash sleep mode if bootloader version >= 1.0.0
* Wait for SPI flash to wakeup before starting OTA DFU
* update font with jetbrains mono v2.225 and the current converter
* added the tff file for JetBrains Mono to ensure everybody is using the same version
Co-authored-by: Florian <florian@florian-thinkpad.local>
Changed type of encodedBufferIndex to size_t to eliminate warning. It is
fine as a size_t as its only ever compared to another size_t and used as
an array index.
Was causing compiler warning for unused constant variable when being
compiled. This feel is directly included where it's needed so it doesn't
need to be separately compiled anyways.
* add basic metronome app
* add bpb, tap to bpm, update widgets
* use event pressed for bpm tap
* move case statement break to the right place
* narrow bpm selection range, override touch events
* fix arc knob style
* re-enable sleeping in destructor
* Add note about getting GadgetBridge from F-Droid
Hopefully this is useful and will save folks some frustration
* Add note that GadgetBridge should be downloaded via F-Droid
There's an "unofficial" version on the Play Store that is outdated and doesn't have PineTime support
* Fix typo
* Add starting version, reword a bit
Initial support version is a little fuzzy, 0.47 states it's "not yet usable" but changelog doesn't specify when we've crossed the "usable" threshold.
* Add the following compilation flags:
* -fno-exceptions and -fno-non-call-exceptions : disable exception handling
* -fno-rtti : disable run time type information (needed by dynamic_cast, for example)
These flags reduce the binary size by about 100KB!
Also, -fstack-usage generate debug info (not in final binary) to allow tools like Puncover to do a stack analysis.
* Remove unused CMake variables in CMake_nRF5x.cmake (duplicated in src/CMakeLists.txt).
Replace -O0 by -Og in DEBUG builds. This generates a smaller binary (small enough for the internal memory) that is debugger friendly.
* Navigation app:
- Renaming and reformatting according to coding conventions
- declare iconMap as constexpr and use char* instead of std::string
This reduces the flash usage from 424644B to 419344B (-5300B)!
* built timer app
* Style improvements
* making sure buttons stay hidden when the app is reopened and reappear after the timer runs out
* more sensible calculations of time deltas. eliminated that mysterious scaling factor
* changing the timer icon
The lv_obj_del is called on btnStopLap when transitioning to the
initial state, however the variable isn't then set to null. A subsequent
call to Refresh would attempt to delete the already freed object. This
could be triggered by stopping the stop watch, then pressing the
physical button on the watch.
Fixes https://github.com/JF002/InfiniTime/issues/315
Gitpod workspace path is based on repo name... it was `/workspace/Pinetime`,
but after the repo rename it's now `/workspace/InfiniTime`.
Also added second pip call as it's in the main dockerfile.
I had issues building InfiniTime for the first time because the instructions never mentioned needing these Python modules. Including them in the build documentation will help people not be confused like I was.
I recommend adding all needed modules to this list. I only added the ones I knew I was missing.
More memory for freertos heap and timer stack
Fix warning in watchface
Fix number of bytes read by cst816
Debug app to show freertos tasks
Increased the number of bytes of the twi write buffer
- Enable LVGL animation (and disable groups, which were not used), and set the speed.
- Fix disc animation and progress display by initializing lastIncrement at 0 (a random value will be used otherwise, in release build)
NOTE: Axis remapping from the SDK do not apply to the "raw" X/Y/Z values returned to the sensor. According to the doc, the remapping is only applied to features, but I cannot check if it has any effect on step counting (I'm not sure I use it correctly, doc is not complete enough about this feature).
If the buffer does not contain any \0, the whole buffer is considered to be the message of the notification. A default title will be displayed in the notification app.
new navigation
add some color to the apps
redesign menus
new settings menu
new quick settings
code clean up
size reduction by converting navigation images to font
and more...
This new FW is build on the same codebasse than the actual InfiniTime. Only the display task is different (this allows to remove lvgl from the recovery fw, which is very heavy).
CMake builds and docker have been modified accordingly.
Note than the fw is converted into an image and then into a DFU in the cmake build (previously, it was only done in the
Fixes a discrepancy with config file naming. The config files it tells you to create end in ocd, but the example flash command uses a filename ending in cfg
When installing Cmake you get Error: The add-path command is deprecated and will be disabled on November 16th...
And the file pinetime-mcuboot-app-dfu.zip was being generated as pinetime-mcuboot-app-dfu.zip.zip
description:Before submitting a bug report, check if similar issues already exist and use those issues to provide your feedback instead.
options:
- label:I searched for similar bug reports (including closed issues) and found none was relevant.
required:true
- type:input
id:desc-brief
attributes:
label:What happened?
description:A one-line description of the bug.
placeholder:"Ex. I woke up as a Kafkian insect this morning."
validations:
required:true
- type:input
id:desc-expected
attributes:
label:What should happen instead?
description:The behaviour you were expecting to see.
placeholder:"Ex. I was expecting to wake up as a human."
- type:textarea
id:desc-steps
attributes:
label:Reproduction steps
description:"How do you trigger this bug? Please walk us through it step by step."
validations:
required:true
- type:textarea
id:desc-long
attributes:
label:More details?
description:Give us more details about the bug and any personal attempts you made to fix it.
placeholder:Tell us more!
- type:input
id:version
attributes:
label:Version
description:|
What [version of the firmware](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/doc/gettingStarted/updating-software.md#checking-the-version-of-infinitime) are you running?
If you are running an older version, please consider [updating to the latest firmware](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/doc/gettingStarted/updating-software.md#updating-with-companion-apps).
If you are running directly from git, specify the branch or the commit hash directly.
placeholder:"Ex. v1.11.0 or main or fc922b60"
validations:
required:true
- type:input
id:companion-app
attributes:
label:Companion app
description:Which companion app are you using (if relevant)?
placeholder:"Ex. Gadgetbridge v0.60.0, Siglo v0.9.4"
description:Before submitting an issue, check if similar issues already exist and use those issues to provide your feedback instead.
options:
- label:I searched for similar issues (including closed issues) and found none was relevant.
required:true
- type:textarea
attributes:
label:Introduce the issue
description:Explain why it is an issue if necessary.
validations:
required:true
- type:textarea
attributes:
label:Preferred solution
description:You can suggest a solution to the issue here.
placeholder:Optional
- type:input
attributes:
label:Version
description:|
What [version of the firmware](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/doc/gettingStarted/updating-software.md#checking-the-version-of-infinitime) are you running?
If you are running an older version, please consider [updating to the latest firmware](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/doc/gettingStarted/updating-software.md#updating-with-companion-apps).
If you are running directly from git, specify the branch or the commit hash directly.
- [Report bugs or issues](https://github.com/InfiniTimeOrg/InfiniTime/issues/new/choose)
- [Write and improve documentation](#documentation)
- [Fix bugs, add functionalities and improve the code](#how-to-create-a-pull-request)
- Participate in the discussions within issues and PRs. Your feedback is appreciated!
- Review pull requests. Follow the instructions [here](doc/maintainer-guide.md#reviewing-prs)
## Documentation
Documentation might be incomplete,
or not clear enough,
and it is always possible to improve it with better wording, pictures, videos,...
As the documentation is part of the source code,
you can submit changes to the documentation by creating a [pull request](#how-to-create-a-pull-request)
## How to create a pull request?
The workflow is based on [GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow).
To create a pull request,
you need a [fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) of the repo.
Create a new [branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches) from main,
and create a [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request).
### PR checklist
When making changes to the firmware:
- Consider if your feature aligns with the [InfiniTime vision](doc/InfiniTimeVision.md)
- Test your changes on a PineTime or InfiniSim
- Make sure the code conforms to the [coding conventions](doc/coding-convention.md)
You can also check the [maintainer's guide](doc/maintainer-guide.md)
for what maintainers will look at in PRs.
### Commit conventions
- Every commit must contain a title and description,
that sufficiently explains all the changes in the commit
- Commits that fix mistakes from previous commits must be squashed
- Conflicts must be resolved by rebasing,
instead of merging
### Commit format
The preferred format for commits is the following:
```
module: Short description
A more thorough description of all changes in this commit if necessary.
```
where module can be the name of the file,
with or without extension,
or a single word explaining the scope of the changes.
> The PineTime is a free and open source smartwatch capable of running custom-built open operating systems. Some of the notable features include a heart rate monitor, a week-long battery as well as a capacitive touch IPS display that is legible in direct sunlight. It is a fully community driven side-project, which means that it will ultimately be up to the developers and end-users to determine when they deem the PineTime ready to ship.
> We envision the PineTime as a companion for not only your PinePhone but also for your favorite devices — any phone, tablet, or even PC.
The **Pinetime** smartwatch is built around the NRF52832 MCU (512KB Flash, 64KB RAM), a 240*240 LCD display driven by the ST7789 controller, an accelerometer, a heart rate sensor, and a vibration motor.
> *InfiniTimeExplorer is only compatible with web browsers that support Web BLE. Current fully supported browsers include Chrome and Microsoft Edge.*
>
> *We removed mentions to NRFConnect as this app is closed source and recent versions do not work anymore with InfiniTime (the last version known to work is 4.24.3). If you used NRFConnect in the past, we recommend you switch to [Gadgetbridge](https://gadgetbridge.org/).*
## Development
- [InfiniTime Vision](doc/InfiniTimeVision.md)
- [Rough structure of the code](doc/code/Intro.md)
- [How to implement an application](doc/code/Apps.md)
- [Generate the fonts and symbols](src/displayapp/fonts/README.md)
- [Tips on designing an app UI](doc/ui_guidelines.md)
- [Bootloader, OTA and DFU](bootloader/README.md)
- [External resources](doc/ExternalResources.md)
### Contributing
- [How to contribute](CONTRIBUTING.md)
- [Coding conventions](doc/coding-convention.md)
### Build, flash and debug
### Build, flash and debug
- [Project branches](doc/branches.md)
- [Versioning](doc/versioning.md)
- [Files included in the release notes](doc/filesInReleaseNotes.md)
- [Build the project](doc/buildAndProgram.md)
- [Flash the firmware using OpenOCD and STLinkV2](doc/openOCD.md)
- [Build the project with Docker](doc/buildWithDocker.md)
- [Bootloader, OTA and DFU](./bootloader/README.md)
- [Stub using NRF52-DK](./doc/PinetimeStubWithNrf52DK.md)
- Add more BLE functionalities : call notifications, agenda, configuration, data logging,...
- [Files included in the release notes](doc/filesInReleaseNotes.md)
- Measure power consumption and improve battery life
- [Files needed by the factory](doc/files-needed-by-factory.md)
- Improve documentation, take better pictures and video than mine
- Improve the UI
- Create companion app for multiple OSes (Linux, Android, iOS) and platforms (desktop, ARM, mobile). Do not forget the other devices from Pine64 like [the Pinephone](https://www.pine64.org/pinephone/) and the [Pinebook Pro](https://www.pine64.org/pinebook-pro/).
- Design a simple CI (preferably self-hosted and easy to reproduce).
Do not hesitate to clone/fork the code, hack it and create pull-requests. I'll do my best to review and merge them :)
## Licenses
## Licenses
This project is released under the GNU General Public License version 3 or, at your option, any later version.
This project is released under the GNU General Public License version 3 or, at your option, any later version.
It integrates the following projects:
It integrates the following projects:
- RTOS : **[FreeRTOS](https://freertos.org)** under the MIT license
- UI : **[LittleVGL/LVGL](https://lvgl.io/)** under the MIT license
- RTOS: **[FreeRTOS](https://freertos.org)** under the MIT license
- BLE stack : **[NimBLE](https://github.com/apache/mynewt-nimble)** under the Apache 2.0 license
- UI: **[LittleVGL/LVGL](https://lvgl.io/)** under the MIT license
- Font : **[Jetbrains Mono](https://www.jetbrains.com/fr-fr/lp/mono/)** under the Apache 2.0 license
- BLE stack: **[NimBLE](https://github.com/apache/mynewt-nimble)** under the Apache 2.0 license
- Font: **[Jetbrains Mono](https://www.jetbrains.com/fr-fr/lp/mono/)** under the Apache 2.0 license
## Credits
I’m not working alone on this project. First, many people create PR for this projects. Then, there is the whole #pinetime community : a lot of people all around the world who are hacking, searching, experimenting and programming the Pinetime. We exchange our ideas, experiments and code in the chat rooms and forums.
## Credits
I’m not working alone on this project. First, many people create pull requests for this project. Then, there is the whole #pinetime community: a lot of people all around the world who are hacking, searching, experimenting and programming the Pinetime. We exchange our ideas, experiments and code in the chat rooms and forums.
Here are some people I would like to highlight:
Here are some people I would like to highlight:
- [Atc1441](https://github.com/atc1441/) : He works on an Arduino based firmware for the Pinetime and many other smartwatches based on similar hardware. He was of great help when I was implementing support for the BMA421 motion sensor and I²C driver.
- [Atc1441](https://github.com/atc1441/): He works on an Arduino based firmware for the Pinetime and many other smartwatches based on similar hardware. He was of great help when I was implementing support for the BMA421 motion sensor and I²C driver.
- [Koen](https://github.com/bosmoment) : He’s working on a firmware based on RiotOS. He integrated similar libs as me : NimBLE, LittleVGL,… His help was invaluable too!
- [Koen](https://github.com/bosmoment): He’s working on a firmware based on RiotOS. He integrated similar libs as me: NimBLE, LittleVGL,… His help was invaluable too!
- [Lup Yuen Lee](https://github.com/lupyuen) : He is everywhere: he works on a Rust firmware, builds a MCUBoot based bootloader for the Pinetime, designs a Flutter based companion app for smartphones and writes a lot of articles about the Pinetime!
- [Lup Yuen Lee](https://github.com/lupyuen): He is everywhere: he works on a Rust firmware, builds a MCUBoot based bootloader for the Pinetime, designs a Flutter based companion app for smartphones and writes a lot of articles about the Pinetime!
*If you feel like you should appear on this list, just get in touch with me or submit a PR :)*
The [bootloader](https://github.com/lupyuen/pinetime-rust-mynewt/tree/master/libs/pinetime_boot/src) is mostly developed by [Lup Yuen](https://github.com/lupyuen). It is based on [MCUBoot](https://juullabs-oss.github.io/mcuboot/) and [Mynewt](https://mynewt.apache.org/).
The [bootloader](https://github.com/lupyuen/pinetime-rust-mynewt/tree/master/libs/pinetime_boot/src) is mostly developed by [Lup Yuen](https://github.com/lupyuen). It is based on [MCUBoot](https://www.mcuboot.com) and [Mynewt](https://mynewt.apache.org/).
The goal of this project is to provide a common bootloader for multiple (all?) Pinetime projects. It allows to upgrade the current bootloader and even replace the current application by another one that supports the same bootloader.
The goal of this project is to provide a common bootloader for multiple (all?) Pinetime projects. It allows to upgrade the current bootloader and even replace the current application by another one that supports the same bootloader.
As we wanted this bootloader to be as universal as possible, we decided that it should **not** integrate a BLE stack and provide OTA capabilities.
As we wanted this bootloader to be as universal as possible, we decided that it should **not** integrate a BLE stack and provide OTA capabilities.
Integrating a BLE stack for the OTA functionality would have used to much memory space and/or forced all the firmware developers to use the same BLE stack as the bootloader.
Integrating a BLE stack for the OTA functionality would have used to much memory space and/or forced all the firmware developers to use the same BLE stack as the bootloader.
When it is run, this bootloader looks in the SPI flash memory if a new firmware is available. It there is one, it *swaps* the current firmware with the new one (the new one is copied in the main flash memory, and the current one is copied in the SPI flash memory) and run the new one. If the new one fails to run properly, the bootloader is able to revert to the old one and mark the new one as not working.
When it is run, this bootloader looks in the SPI flash memory if a new firmware is available. It there is one, it *swaps* the current firmware with the new one (the new one is copied in the main flash memory, and the current one is copied in the SPI flash memory) and run the new one. If the new one fails to run properly, the bootloader is able to revert to the old one and mark the new one as not working.
As this bootloader does not provide any OTA capability, it is not able to actually download a new version of the application. Providing OTA functionality is thus the responsability of the application firmware.
As this bootloader does not provide any OTA capability, it is not able to actually download a new version of the application. Providing OTA functionality is thus the responsibility of the application firmware.
# About MCUBoot
# About MCUBoot
MCUBoot is run at boot time. In normal operation, it just jumps to the reset handler of the application firmware to run it. Once the application firmware is running, MCUBoot does not run at all.
MCUBoot is run at boot time. In normal operation, it just jumps to the reset handler of the application firmware to run it. Once the application firmware is running, MCUBoot does not run at all.
But MCUBoot does much more than that : it can upgrade the firmware that is currently running by a new one, and it is also able to revert to the previous version of the firmware in case the new one does not run propertly.
But MCUBoot does much more than that : it can upgrade the firmware that is currently running by a new one, and it is also able to revert to the previous version of the firmware in case the new one does not run properly.
To do this, it uses 2 memory 'slots' :
To do this, it uses 2 memory 'slots' :
- **The primary slot** : it contains the current firmware, the one that will be executed by MCUBoot
- **The secondary slot** : it is used to store the upgraded version of the firmware, when available.
- **The primary slot** : it contains the current firmware, the one that will be executed by MCUBoot
- **The secondary slot** : it is used to store the upgraded version of the firmware, when available.
At boot time, MCUBoot detects that a new version of the firmware is available in the secondary slot and swaps them : the current version of the firmware is copied from the primary to the secondary slot and vice-versa.
At boot time, MCUBoot detects that a new version of the firmware is available in the secondary slot and swaps them : the current version of the firmware is copied from the primary to the secondary slot and vice-versa.
@ -35,89 +38,89 @@ The next time MCUBoot will be run (after a MCU reset), MCUBoot will check if the
Note than MCUBoot **does not** provide any means to download and store the new version of the firmware into the secondary slot. This must be implemented by the application firmware.
Note than MCUBoot **does not** provide any means to download and store the new version of the firmware into the secondary slot. This must be implemented by the application firmware.
# Degraded cases
# Degraded cases
This chapter describes degraded cases that are handled by our bootloader and those that are not supported.
This chapter describes degraded cases that are handled by our bootloader and those that are not supported.
Data got corrupted during file transfert | [OK] Application firmware does a CRC check before applying the update, and does not proceed if it fails. | N/A
Data got corrupted during file transfer | [OK] Application firmware does a CRC check before applying the update, and does not proceed if it fails. | N/A
New firmware does not run at all (bad file) (1) | [NOK] MCU executes unknown instructions and will most likely end up in an infinite loop or freeze in an error handler. The bootloader does not run, it can do nothing, the MCU is stucked until next reset | [OK] The bootloader starts the watchdog just before running the new firmware. This way, the watchdog will reset the MCU after ~7s because the firmware does not refresh it. Bootloader reverts to the previous version of the firmware during the reset.
New firmware does not run at all (bad file) (1) | [NOK] MCU executes unknown instructions and will most likely end up in an infinite loop or freeze in an error handler. The bootloader does not run, it can do nothing, the MCU is stuck until next reset | [OK] The bootloader starts the watchdog just before running the new firmware. This way, the watchdog will reset the MCU after ~7s because the firmware does not refresh it. Bootloader reverts to the previous version of the firmware during the reset.
New firmware runs, does not set the valid bit and does not refresh the watchdog | [NOK] The new firmware runs until the next reset. The bootloader will be able to revert to the previous firmware only during the next reset. If the new firmware does not run properly and does not reset, the bootloader can do nothing until the next reset | [OK] The bootloader starts the watchdog just before running the new firmware. This way, the watchdog will reset the MCU after ~7s because the firmware does not refresh it. Bootloader reverts to the previous version of the firmware during the reset.
New firmware runs, does not set the valid bit and does not refresh the watchdog | [NOK] The new firmware runs until the next reset. The bootloader will be able to revert to the previous firmware only during the next reset. If the new firmware does not run properly and does not reset, the bootloader can do nothing until the next reset | [OK] The bootloader starts the watchdog just before running the new firmware. This way, the watchdog will reset the MCU after ~7s because the firmware does not refresh it. Bootloader reverts to the previous version of the firmware during the reset.
New firmware does not run properly, does not set the valid bit but refreshes the watchdog | [NOK] The bootloader will be able to revert to the previous firmware only during the next reset. If the new firmware does not run properly and does not reset, the bootloader can do nothing until the next reset | [~] Wait for the battery to drain. The CPU will reset the next time the device is charged and will be able to rollback to the previous version.
New firmware does not run properly, does not set the valid bit but refreshes the watchdog | [NOK] The bootloader will be able to revert to the previous firmware only during the next reset. If the new firmware does not run properly and does not reset, the bootloader can do nothing until the next reset | [~] Wait for the battery to drain. The CPU will reset the next time the device is charged and will be able to rollback to the previous version.
New firmware does not run properly but sets the valid bit and refreshes the watchdog | [NOK] The bootloader won't revert to the previous version because the valid flag is set | [~] Wait for the battery to drain. The CPU will reset the next time the device is charged. Then, the bootloader must provide a way for the user to force the rollback to the previous version
New firmware does not run properly but sets the valid bit and refreshes the watchdog | [NOK] The bootloader won't revert to the previous version because the valid flag is set | [~] Wait for the battery to drain. The CPU will reset the next time the device is charged. Then, the bootloader must provide a way for the user to force the rollback to the previous version
*(1) I've observed this when I tried to run a firmware built to run from offset 0 while it was flashed at offset 0x8000 in memory (bad vector table).*
*(1) I've observed this when I tried to run a firmware built to run from offset 0 while it was flashed at offset 0x8000 in memory (bad vector table).*
# Using the bootloader
# Using the bootloader
## Bootloader graphic
## Bootloader graphic
The bootloader loads a graphic (Pinetime logo) from the SPI Flash memory. If this graphic is not loaded in the memory, the LCD will display garbage (the content of the SPI flash memory).
The bootloader loads a graphic (Pinetime logo) from the SPI Flash memory. If this graphic is not loaded in the memory, the LCD will display garbage (the content of the SPI flash memory).
The SPI Flash memory is not accessible via the SWD debugger. Use the firmware 'pinetime-graphics' to load the graphic into memory. All you have to do is build it and program it at address 0x00 :
The SPI Flash memory is not accessible via the SWD debugger. Use the firmware 'pinetime-graphics' to load the graphic into memory. All you have to do is build it and program it at address 0x00 :
- Build:
- Build:
```
$ make pinetime-graphics
```sh
make pinetime-graphics
```
```
- Program (using OpenOCD for example) :
- Program (using OpenOCD for example) :
```
```
program pinetime-graphics.bin 0
program pinetime-graphics.bin 0
```
```
- Let it run for ~10s (it does nothing for 5 seconds, then write the logo into the SPI memory, then (slowly) displays it on the LCD).
- Let it run for ~10s (it does nothing for 5 seconds, then write the logo into the SPI memory, then (slowly) displays it on the LCD).
## Bootloader binary
## Bootloader binary
The binary comes from https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v5.0.4
The binary comes from https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v5.0.4
It must be flash at address **0x00** in the internal flash memory.
It must be flash at address **0x00** in the internal flash memory.
Using OpenOCD:
Using OpenOCD:
`
`program bootloader-5.0.4.bin 0`
program bootloader-5.0.4.bin 0
`
## Application firmware image
## Application firmware image
Build the binary compatible with the booloader:
Build the binary compatible with the booloader:
`
`make pinetime-mcuboot-app`
make pinetime-mcuboot-app
`
The binary is located in *<build directory>/src/pinetime-mcuboot-app.bin*.
The binary is located in *<build directory>/src/pinetime-mcuboot-app.bin*.
It must me converted into a MCUBoot image using *imgtool.py* from [MCUBoot](https://github.com/JuulLabs-OSS/mcuboot/tree/master/scripts). Simply checkout the project and run the script <mcubootroot>/scripts/imgtool.py with the following command line:
It must me converted into a MCUBoot image using *imgtool.py* from [MCUBoot](https://github.com/mcu-tools/mcuboot/tree/master/scripts). Simply checkout the project and run the script <mcubootroot>/scripts/imgtool.py with the following command line:
Use NRFConnect or dfu.py (in <projectroot>/bootloader/ota-dfu-python) to upload the zip file to the device:
Use NRFConnect or dfu.py (in <projectroot>/bootloader/ota-dfu-python) to upload the zip file to the device:
`
```sh
sudo dfu.py -z /home/jf/nrf52/bootloader/dfu.zip -a <pinetimeMACaddress> --legacy
sudo dfu.py -z /home/jf/nrf52/bootloader/dfu.zip -a <pinetimeMACaddress> --legacy
`
```
**Note** : dfu.py is a slightly modified version of [this repo](https://github.com/daniel-thompson/ota-dfu-python).
**Note** : dfu.py is a slightly modified version of [this repo](https://github.com/daniel-thompson/ota-dfu-python).
See [this page](../doc/CompanionApps/NrfconnectOTA.md) for more info about OTA with NRFConect
### Firmware validation
### Firmware validation
Once the OTA is done, InfiniTime will reset the watch to apply the update. When the watch reboots, the new firmware is running.
Once the OTA is done, InfiniTime will reset the watch to apply the update. When the watch reboots, the new firmware is running.
One last step is needed to finalize the upgrade : the new firmware must be manually validated. If the watch resets while the image is not validated, the bootloader will automatically revert to the previous version of the firmware.
One last step is needed to finalize the upgrade : the new firmware must be manually validated. If the watch resets while the image is not validated, the bootloader will automatically revert to the previous version of the firmware.
@ -126,12 +129,12 @@ If the new firmware is working correctly, open the application menu and tap on t
@ -17,24 +17,24 @@ This is a Python program that uses `gatttool` (provided with the Linux BlueZ dri
### Main features:
### Main features:
* Perform OTA DFU to an nRF5 peripheral without an external USB BLE dongle.
- Perform OTA DFU to an nRF5 peripheral without an external USB BLE dongle.
* Ability to detect if the peripheral is running in application mode or bootloader, and automatically switch if needed (buttonless).
- Ability to detect if the peripheral is running in application mode or bootloader, and automatically switch if needed (buttonless).
* Support for both Legacy (SDK <= 11) and Secure (SDK >= 12) bootloader.
- Support for both Legacy (SDK <= 11) and Secure (SDK >= 12) bootloader.
Before using this utility the nRF5 peripheral device needs to be programmed with a DFU bootloader (see Nordic Semiconductor documentation/examples for instructions on that).
Before using this utility the nRF5 peripheral device needs to be programmed with a DFU bootloader (see Nordic Semiconductor documentation/examples for instructions on that).
## Prerequisites
## Prerequisites
* BlueZ 5.4 or above
- BlueZ 5.4 or above
* Python 3.6
- Python 3.6
* Python `pexpect` module (available via pip)
- Python `pexpect` module (available via pip)
* Python `intelhex` module (available via pip)
- Python `intelhex` module (available via pip)
## Firmware Build Requirement
## Firmware Build Requirement
* Your nRF5 peripheral firmware build method will produce a firmware file ending with either `*.hex` or `*.bin`.
- Your nRF5 peripheral firmware build method will produce a firmware file ending with either `*.hex` or `*.bin`.
* Your nRF5 firmware build method will produce an Init file ending with `.dat`.
- Your nRF5 firmware build method will produce an Init file ending with `.dat`.
* The typical naming convention is `application.bin` and `application.dat`, but this utility will accept other names.
- The typical naming convention is `application.bin` and `application.dat`, but this utility will accept other names.
## Generating init files
## Generating init files
@ -75,14 +75,13 @@ You can use the `hcitool lescan` to figure out the address of a DFU target, for
CD:E3:4A:47:1C:E4 <TARGET_NAME>
CD:E3:4A:47:1C:E4 <TARGET_NAME>
CD:E3:4A:47:1C:E4 (unknown)
CD:E3:4A:47:1C:E4 (unknown)
## Example Output
## Example Output
================================
================================
== ==
== ==
== DFU Server ==
== DFU Server ==
== ==
== ==
================================
================================
Sending file application.bin to CD:E3:4A:47:1C:E4
Sending file application.bin to CD:E3:4A:47:1C:E4
bin array size: 60788
bin array size: 60788
@ -105,14 +104,14 @@ You can use the `hcitool lescan` to figure out the address of a DFU target, for
## TODO:
## TODO:
* Implement link-loss procedure for Legacy Controller.
- Implement link-loss procedure for Legacy Controller.
@ -7,7 +7,7 @@ Cmake script for projects targeting Nordic Semiconductor nRF5x series devices us
The script makes use of the following tools:
The script makes use of the following tools:
- nRF5x SDK by Nordic Semiconductor - SoC specific drivers and libraries (also includes a lot of examples)
- nRF5x SDK by Nordic Semiconductor - SoC specific drivers and libraries (also includes a lot of examples)
- JLink by Segger - interface software for the JLink familiy of programmers
- JLink by Segger - interface software for the JLink family of programmers
- nrfjprog by Nordic Semiconductor - Wrapper utility around JLink
- nrfjprog by Nordic Semiconductor - Wrapper utility around JLink
- arm-non-eabi-gcc by ARM and the GCC Team - compiler toolchain for embedded (= bare metal) ARM chips
- arm-non-eabi-gcc by ARM and the GCC Team - compiler toolchain for embedded (= bare metal) ARM chips
@ -15,11 +15,11 @@ The script makes use of the following tools:
1. Download this repo (or add as submodule) to the directory `cmake-nRF5x` in your project
1. Download this repo (or add as submodule) to the directory `cmake-nRF5x` in your project
1. Search the SDK `example` directory for a `sdk_config.h`, `main.c` and a linker script (normally named `<project_name>_gcc_<chip familly>.ld`) that fits your chip and project needs.
1. Search the SDK `example` directory for a `sdk_config.h`, `main.c` and a linker script (normally named `<project_name>_gcc_<chip family>.ld`) that fits your chip and project needs.
1. Copy the `sdk_config.h` and the project `main.c` into a new directory `src`. Modify them as required for your project.
1. Copy the `sdk_config.h` and the project `main.c` into a new directory `src`. Modify them as required for your project.
1. Copy the linker script into the root of your project. Rename it to just `gcc_<chip familly>.ld` For example:
1. Copy the linker script into the root of your project. Rename it to just `gcc_<chip family>.ld` For example:
```
```
gcc_nrf51.ld
gcc_nrf51.ld
@ -98,7 +98,7 @@ The script makes use of the following tools:
After setup you can use cmake as usual:
After setup you can use cmake as usual:
1. Generate the actual build files (out-of-source builds are strongly recomended):
1. Generate the actual build files (out-of-source builds are strongly recommended):
The BLE FS protocol in InfiniTime is mostly Adafruit's BLE file transfer protocol, as described in [adafruit/Adafruit_CircuitPython_BLE_File_Transfer](https://github.com/adafruit/Adafruit_CircuitPython_BLE_File_Transfer). There are some deviations, such as the status codes. These will be described later in the document.
---
## UUIDs
There are two relevant UUIDs in this protocol: the version characteristic, and the raw transfer characteristic.
### Version
UUID: `adaf0100-4669-6c65-5472-616e73666572`
The version characteristic returns the version of the protocol to which the sender adheres. It returns a single unsigned 32-bit integer. The latest version at the time of writing this is 4.
### Transfer
UUID: `adaf0200-4669-6c65-5472-616e73666572`
The transfer characteristic is responsible for all the data transfer between the client and the watch. It supports write and notify. Writing a packet on the characteristic results in a response via notify.
---
## Usage
The separator for paths is `/`, and absolute paths must start with `/`.
All of the following commands and responses are transferred via the transfer characteristic
### Read file
To begin reading a file, a header must first be sent. The header packet should be formatted like so:
- Command (single byte): `0x10`
- 1 byte of padding
- Unsigned 16-bit integer encoding the length of the file path.
- Unsigned 32-bit integer encoding the location at which to start reading the first chunk.
- Unsigned 32-bit integer encoding the amount of bytes to be read.
- File path: UTF-8 encoded string that is _not_ null terminated.
To continue reading the file after this initial packet, the following packet should be sent until all the data has been received. No close command is required after the data has been received.
- Command (single byte): `0x12`
- Status: `0x01`
- 2 bytes of padding
- Unsigned 32-bit integer encoding the location at which to start reading the next chunk.
- Unsigned 32-bit integer encoding the amount of bytes to be read. This may be different from the size in the header.
Both of these commands receive the following response:
- Command (single byte): `0x11`
- Status (signed 8-bit integer)
- 2 bytes of padding
- Unsigned 32-bit integer encoding the offset of this chunk
- Unsigned 32-bit integer encoding the total size of the file
- Unsigned 32-bit integer encoding the amount of data in the current chunk
- Contents of the current chunk
### Write file
To begin writing to a file, a header must first be sent. The header packet should be formatted like so:
- Command (single byte): `0x20`
- 1 byte of padding
- Unsigned 16-bit integer encoding the length of the file path.
- Unsigned 32-bit integer encoding the location at which to start writing to the file.
- Unsigned 64-bit integer encoding the unix timestamp with nanosecond resolution. This will be used as the modification time. At the time of writing, this is not implemented in InfiniTime, but may be in the future.
- Unsigned 32-bit integer encoding the size of the file that will be sent
- File path: UTF-8 encoded string that is _not_ null terminated.
To continue reading the file after this initial packet, the following packet should be sent until all the data has been sent and a response had been received with 0 free space. No close command is required after the data has been received.
- Command (single byte): `0x22`
- Status: `0x01`
- 2 bytes of padding.
- Unsigned 32-bit integer encoding the location at which to write the next chunk.
- Unsigned 32-bit integer encoding the amount of bytes to be written.
- Data
Both of these commands receive the following response:
- Command (single byte): `0x21`
- Status (signed 8-bit integer)
- 2 bytes of padding
- Unsigned 32-bit integer encoding the current offset in the file
- Unsigned 64-bit integer encoding the unix timestamp with nanosecond resolution. This will be used as the modification time. At the time of writing, this is not implemented in InfiniTime, but may be in the future.
- Unsigned 32-bit integer encoding the amount of data the client can send until the file is full.
### Delete file
- Command (single byte): `0x30`
- 1 byte of padding
- Unsigned 16-bit integer encoding the length of the file path.
- File path: UTF-8 encoded string that is _not_ null terminated.
The response to this packet will be as follows:
- Command (single byte): `0x31`
- Status (signed 8-bit integer)
### Make directory
- Command (single byte): `0x40`
- 1 byte of padding
- Unsigned 16-bit integer encoding the length of the file path.
- 4 bytes of padding
- Unsigned 64-bit integer encoding the unix timestamp with nanosecond resolution.
- File path: UTF-8 encoded string that is _not_ null terminated.
The response to this packet will be as follows:
- Command (single byte): `0x41`
- Status (signed 8-bit integer)
- 6 bytes of padding
- Unsigned 64-bit integer encoding the unix timestamp with nanosecond resolution.
### List directory
Paths returned by this command are relative to the path given in the request
- Command (single byte): `0x50`
- 1 byte of padding
- Unsigned 16-bit integer encoding the length of the file path.
- File path: UTF-8 encoded string that is _not_ null terminated.
The response to this packet will be as follows. Responses will be sent until the final entry, which will have entry number == total entries
- Command (single byte): `0x51`
- Status (signed 8-bit integer)
- Unsigned 16-bit integer encoding the length of the file path.
- Unsigned 32-bit integer encoding the entry number
- Unsigned 32-bit integer encoding the total amount of entries
- Flags: unsigned 32-bit integer
- Bit 0: Set when entry is a directory
- Bits 1-7: Reserved
- Unsigned 64-bit integer encoding the unix timestamp of the modification time with nanosecond resolution
- Unsigned 32-bit integer encoding the size of the file
- Path: UTF-8 encoded string that is _not_ null terminated.
### Move file or directory
- Command (single byte): `0x60`
- 1 byte of padding
- Unsigned 16-bit integer encoding the length of the old path
- Unsigned 16-bit integer encoding the length of the new path
- Old path: UTF-8 encoded string that is _not_ null terminated.
- 1 byte of padding
- Newpath: UTF-8 encoded string that is _not_ null terminated.
The response to this packet will be as follows:
- Command (single byte): `0x61`
- Status (signed 8-bit integer)
---
## Deviations
This section describes the differences between Adafruit's spec and InfiniTime's implementation.
### Status codes
The status codes returned by InfiniTime are a signed 8-bit integer, rather than an unsigned one as described in the spec.
InfiniTime uses LittleFS error codes rather than the ones described in the spec. Those codes can be found in [lfs.h](https://github.com/littlefs-project/littlefs/blob/master/lfs.h#L70).
Since InfiniTime 1.11 apps and watchfaces can benefit from the external flash memory to store images and fonts.
This external memory is a lot bigger (4MB) than the internal memory that contains the firmware (512KB).
This page describes how the resources are integrated in InfiniTime from a developer perspective. [This page](gettingStarted/updating-software.md) explains how to install and update the external resources using companion apps.
## Resources generation
Resources are generated at build time via the [CMake target `Generate Resources`](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/src/resources/CMakeLists.txt#L19).
It runs 3 Python scripts that respectively convert the fonts to binary format, convert the images to binary format and package everything in a .zip file.
The resulting file `infinitime-resources-x.y.z.zip` contains the images and fonts converted in binary `.bin` files and a JSON file `resources.json`.
Companion apps use this file to upload the files to the watch.
```
{
"resources": [
{
"filename": "lv_font_dots_40.bin",
"path": "/fonts/lv_font_dots_40.bin"
}
],
"obsolete_files": [
{
"path": "/example-of-obsolete-file.bin",
"since": "1.11.0"
}
]
}
```
The resource JSON file describes an array of resources and an array of obsolete files :
- `resources` : a resource is a file that must be flashed to the watch
- `filename`: name of the resources in the zip file.
- `path` : file path and name where the file must be flashed in the watch FS.
- `obsolete_files` : files that are not needed anymore in the memory of the watch that can be deleted during the update procedure.
- `path` : path of the file in the watch FS
- `since` : version of InfiniTime that made this file obsolete.
## Resources update procedure
The update procedure is based on the [BLE FS API](BLEFS.md). The companion app simply write the binary files to the watch FS using information from the file `resources.json`.
## Working with external resources in the code
Load a picture from the external resources:
```
lv_obj_t* logo = lv_img_create(lv_scr_act(), nullptr);
lv_img_set_src(logo, "F:/images/logo.bin");
```
Load a font from the external resources: you first need to check that the file actually exists. LVGL will crash when trying to open a font that doesn't exist.
```
lv_font_t* font_teko = nullptr;
if (filesystem.FileOpen(&f, "/fonts/font.bin", LFS_O_RDONLY) >= 0) {
The PineTime is equipped with the following memories:
- The internal RAM : **64KB**
- The internal Flash : **512KB**
- The external (SPI) Flash : **4MB**
Note that the NRF52832 cannot execute code stored in the external flash : we need to store the whole firmware in the internal flash memory, and use the external one to store graphicals assets, fonts...
This document describes how the RAM and Flash memories are used in InfiniTime and how to analyze and monitor their usage. It was written in the context of [this memory analysis effort](https://github.com/InfiniTimeOrg/InfiniTime/issues/313).
## Code sections
A binary is composed of multiple sections. Most of the time, these sections are : .text, .rodata, .data and .bss but more sections can be defined in the linker script.
Here is a small description of these sections and where they end up in memory:
- **TEXT** = code (FLASH)
- **RODATA** = constants (FLASH)
- **DATA** = initialized variables (FLASH + RAM)
- **BSS** = uninitialized variables (RAM)
## Internal FLASH
The internal flash memory stores the whole firmware: code, variable that are not default-initialized, constants...
The content of the flash memory can be easily analyzed thanks to the MAP file generated by the compiler. This file lists all the symbols from the program along with their size and location (section and addresses) in RAM and FLASH.

As you can see on the picture above, this file contains a lot of information and is not easily readable by a human being. Fortunately, you can easily find tools that parse and display the content of the MAP file in a more understandable way.
In this analysis, I used [Linkermapviz](https://github.com/PromyLOPh/linkermapviz).
### Linkermapviz
[Linkermapviz](https://github.com/PromyLOPh/linkermapviz) parses the MAP file and displays its content on an HTML page as a graphic:
Using this tool, you can compare the relative size of symbols. This can be helpful for checking memory usage at a glance.
Also, as Linkermapviz is written in Python, you can easily modify and adapt it to your firmware or export data in another format. For example, [here it is modified to parse the contents of the MAP file and export it in a CSV file](https://github.com/InfiniTimeOrg/InfiniTime/issues/313#issuecomment-842338620). This file could later be opened in LibreOffice Calc where sort/filter functionality could be used to search for specific symbols in specific files...
### Puncover
[Puncover](https://github.com/HBehrens/puncover) is another useful tools that analyses the binary file generated by the compiler (the .out file that contains all debug information). It provides valuable information about the symbols (data and code): name, position, size, max stack of each functions, callers, callees...
- `/path/to/gcc-arm-none-eabi-10.3-2021.10/bin` with the path to your gcc-arm-none-eabi toolchain
- `/path/to/build/directory/src/pinetime-app-1.1.0.out` with the path to the binary generated by GCC (.out file)
- `/path/to/sources` with the path to the root folder of the sources (checkout directory)
- `/path/to/build/directory` with the path to the build directory
- Launch a browser at http://localhost:5000/
### Analysis
Using the MAP file and tools, we can easily see what symbols are using most of the flash memory. In this case, unsurprisingly, fonts and graphics are the largest use of flash memory.
This way, you can easily check what needs to be optimized. We should find a way to store big static data (like fonts and graphics) in the external flash memory, for example.
It's always a good idea to check the flash memory space when working on the project. This way, you can easily check that your developments are using a reasonable amount of space.
### Links
- Analysis with linkermapviz : https://github.com/InfiniTimeOrg/InfiniTime/issues/313#issuecomment-842338620
- Analysis with Puncover : https://github.com/InfiniTimeOrg/InfiniTime/issues/313#issuecomment-847311392
## RAM
RAM memory contains all the data that can be modified at run-time: variables, stack, heap...
### Data
RAM memory can be *statically* allocated, meaning that the size and position of the data are known at compile-time:
You can easily analyze the memory used by variables declared in the global scope using the MAP. You'll find them in the .BSS or .DATA sections. Linkermapviz and Puncover can be used to analyze their memory usage.
Variables declared in the scope of a function will be allocated on the stack. It means that the stack usage will vary according to the state of the program, and cannot be easily analyzed at compile time.
```
uint8_t buffer[1024]
int main() {
int a;
}
```
#### Analysis
In Infinitime 1.1, the biggest buffers are the buffers allocated for LVGL (14KB) and the one for FreeRTOS (16KB). Nimble also allocated 9KB of RAM.
### Stack
The stack will be used for everything except tasks, which have their own stack allocated by FreeRTOS. The stack is 8192B and is allocated in the [linker script](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/nrf_common.ld#L148).
An easy way to monitor its usage is by filling the section with a known pattern at boot time, then use the firmware and dump the memory. You can then check the maximum stack usage by checking the address from the beginning of the stack that were overwritten.
#### Fill the stack section by a known pattern:
Edit <NRFSDK>/modules/nrfx/mdk/gcc_startup_nrf52.S and add the following code after the copy of the data from read only memory to RAM at around line 243:
```
/* Loop to copy data from read only memory to RAM.
* The ranges of copy from/to are specified by following symbols:
* __etext: LMA of start of the section to copy from. Usually end of text
* __data_start__: VMA of start of the section to copy to.
* __bss_start__: VMA of end of the section to copy to. Normally __data_end__ is used, but by using __bss_start__
* the user can add their own initialized data section before BSS section with the INTERT AFTER command.
*
* All addresses must be aligned to 4 bytes boundary.
*/
ldr r1, =__etext
ldr r2, =__data_start__
ldr r3, =__bss_start__
subs r3, r3, r2
ble .L_loop1_done
.L_loop1:
subs r3, r3, #4
ldr r0, [r1,r3]
str r0, [r2,r3]
bgt .L_loop1
.L_loop1_done:
/* Add this code to fill the stack section with 0xFFEEDDBB */
ldr r0, =__StackLimit
ldr r1, =8192
ldr r2, =0xFFEEDDBB
.L_fill:
str r2, [r0]
adds r0, 4
subs r1, 4
bne .L_fill
/* -- */
```
#### Dump RAM memory and check usage
Dumping the content of the ram is easy using JLink debugger and `nrfjprog`:
```
nrfjprog --readram ram.bin
```
You can then display the file using objdump:
```
hexdump ram.bin -v | less
```
The stack is positioned at the end of the RAM -> 0xFFFF. Its size is 8192 bytes, so the end of the stack is at 0xE000.
On the following dump, the maximum stack usage is 520 bytes (0xFFFF - 0xFDF8):
```
000fdb0 ddbb ffee ddbb ffee ddbb ffee ddbb ffee
000fdc0 ddbb ffee ddbb ffee ddbb ffee ddbb ffee
000fdd0 ddbb ffee ddbb ffee ddbb ffee ddbb ffee
000fde0 ddbb ffee ddbb ffee ddbb ffee ddbb ffee
000fdf0 ddbb ffee ddbb ffee ffff ffff c24b 0003
000fe00 ffff ffff ffff ffff ffff ffff 0000 0000
000fe10 0018 0000 0000 0000 0000 0000 fe58 2000
000fe20 0000 0000 0000 00ff ddbb 00ff 0018 0000
000fe30 929c 2000 0000 0000 0018 0000 0000 0000
000fe40 92c4 2000 0458 2000 0000 0000 80e7 0003
000fe50 0000 0000 8cd9 0003 ddbb ffee ddbb ffee
000fe60 00dc 2000 92c4 2000 0005 0000 929c 2000
000fe70 007f 0000 feb0 2000 92c4 2000 feb8 2000
000fe80 ddbb ffee 0005 0000 929c 2000 0000 0000
000fe90 aca0 2000 0000 0000 0028 0000 418b 0005
000fea0 02f4 2000 001f 0000 0000 0000 0013 0000
000feb0 b5a8 2000 2199 0005 b5a8 2000 2201 0005
000fec0 b5a8 2000 001e 0000 0000 0000 0013 0000
000fed0 b5b0 2000 0fe0 0006 b5a8 2000 0000 0000
000fee0 0013 0000 2319 0005 0013 0000 0000 0000
000fef0 0000 0000 3b1c 2000 3b1c 2000 d0e3 0000
000ff00 4b70 2000 54ac 2000 4b70 2000 ffff ffff
000ff10 0000 0000 1379 0003 6578 2000 0d75 0003
000ff20 6578 2000 ffff ffff 0000 0000 1379 0003
000ff30 000c 0000 cfeb 0002 39a1 2000 a824 2000
000ff40 0015 0000 cfeb 0002 39a1 2000 a824 2000
000ff50 39a1 2000 0015 0000 001b 0000 b4b9 0002
000ff60 0000 0000 a9f4 2000 4b70 2000 0d75 0003
000ff70 4b70 2000 ffff ffff 0000 0000 1379 0003
000ff80 ed00 e000 a820 2000 1000 4001 7fc0 2000
000ff90 7f64 2000 75a7 0001 a884 2000 7b04 2000
000ffa0 a8c0 2000 0000 0000 0000 0000 0000 0000
000ffb0 7fc0 2000 7f64 2000 8024 2000 a5a5 a5a5
000ffc0 ed00 e000 3fd5 0001 0000 0000 72c0 2000
000ffd0 0000 0000 72e4 2000 3f65 0001 7f64 2000
000ffe0 0000 2001 0000 0000 ef30 e000 0010 0000
000fff0 7fc0 2000 4217 0001 3f0a 0001 0000 6100
```
#### Analysis
According to my experimentations, we don't use the stack that much, and 8192 bytes is probably way too big for InfiniTime!
The heap is declared in the [linker script](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/nrf_common.ld#L136) and its current size is 8192 bytes. The heap is used for dynamic memory allocation(`malloc()`, `new`...).
Heap monitoring is not easy, but it seems that we can use the following code to know the current usage of the heap:
```
auto m = mallinfo();
NRF_LOG_INFO("heap : %d", m.uordblks);
```
#### Analysis
According to my experimentation, InfiniTime uses ~6000bytes of heap most of the time. Except when the Navigation app is launched, where the heap usage exceeds 9500 bytes (meaning that the heap overflows and could potentially corrupt the stack). This is a bug that should be fixed in #362.
To know exactly what's consuming heap memory, you can `wrap` functions like `malloc()` into your own functions. In this wrapper, you can add logging code or put breakpoints:
- Add ` -Wl,-wrap,malloc` to the cmake variable `LINK_FLAGS` of the target you want to debug (pinetime-app, most probably)
- Add the following code in `main.cpp`
```
extern "C" {
void *__real_malloc (size_t);
void* __wrap_malloc(size_t size) {
return __real_malloc(size);
}
}
```
Now, your function `__wrap_malloc()` will be called instead of `malloc()`. You can call the actual malloc from the stdlib by calling `__real_malloc()`.
Using this technique, I was able to trace all malloc calls at boot (boot -> digital watch face):
- system task = 3464 bytes (SystemTask could potentially be declared as a global variable to avoid heap allocation here)
- string music = 31 (maybe we should not use std::string when not needed, as it does heap allocation)
The most interesting metric is `mon.max_used` which specifies the maximum number of bytes used from this buffer since the initialization of lvgl.
According to my measurements, initializing the theme, display/touch driver and screens cost **4752** bytes!
Then, initializing the digital clock face costs **1541 bytes**.
For example a simple lv_label needs **~140 bytes** of memory.
I tried to monitor this max value while going through all the apps of InfiniTime 1.1 : the max value I've seen is **5660 bytes**. It means that we could probably **reduce the size of the buffer from 14KB to 6 - 10 KB** (we have to take the fragmentation of the memory into account).
FreeRTOS statically allocate its own heap buffer in a global variable named `ucHeap`. This is an array of *uint8_t*. Its size is specified by the definition `configTOTAL_HEAP_SIZE` in *FreeRTOSConfig.h*
FreeRTOS statically allocate its own heap buffer in a global variable named `ucHeap`. This is an array of *uint8_t*. Its size is specified by the definition `configTOTAL_HEAP_SIZE` in *FreeRTOSConfig.h*
FreeRTOS uses this buffer to allocate memory for tasks stack and all the RTOS object created during runtime (timers, mutexes,...).
FreeRTOS uses this buffer to allocate memory for tasks stack and all the RTOS object created during runtime (timers, mutexes...).
The function `xPortGetFreeHeapSize()` returns the amount of memory available in this *ucHeap* buffer. If this value reaches 0, FreeRTOS runs out of memory.
The function `xPortGetFreeHeapSize()` returns the amount of memory available in this *ucHeap* buffer. If this value reaches 0, FreeRTOS runs out of memory.
@ -9,7 +298,6 @@ The function `xPortGetFreeHeapSize()` returns the amount of memory available in
The function `uxTaskGetSystemState()` fetches some information about the running tasks like its name and the minimum amount of stack space that has remained for the task since the task was created:
The function `uxTaskGetSystemState()` fetches some information about the running tasks like its name and the minimum amount of stack space that has remained for the task since the task was created:
```
```
@ -18,61 +306,3 @@ auto nb = uxTaskGetSystemState(tasksStatus, 10, NULL);
Heap is used for **dynamic memory allocation (malloc() / new)**. NRF SDK defaults the heap size to 8KB. The size of the heap can be specified by defining `__HEAP_SIZE=8192` in *src/CMakeLists.txt*:
```
add_definitions(-D__HEAP_SIZE=8192)
```
You can trace the dynamic memory allocation by using the flag `--wrap` of the linker. When this flag is enabled, the linker will replace the calls to a specific function by a call to __wrap_the_function(). For example, if you specify `-Wl,-wrap,malloc` in the linker flags, the linker will replace all calls to `void* malloc(size_t)` by calls to `void* __wrap_malloc(size_t)`. This is a function you'll have to define in your code. In this function, you can call `__real_malloc()` to call the actual `malloc()' function.
This technic allows you to wrap all calls to malloc() with you own code.
This function sums all the memory that is allocated during the runtime. You can monitor or log this value. You can also place breakpoints in this function to determine where the dynamic memory allocation occurs in your code.
# Global stack
The stack is used to allocate memory used by functions : **parameters and local variables**. NRF SDK defaults the heap size to 8KB. The size of the heap can be specified by defining `__STACK_SIZE=8192` in *src/CMakeLists.txt*:
```
add_definitions(-D__STACK_SIZE=8192)
```
*NOTE*: FreeRTOS uses its own stack buffer. Thus, the global stack is only used for main() and IRQ handlers. It should be possible to reduce its size to a much lower value.
**NOTE**: [?] How to track the global stack usage?
#LittleVGL buffer
*TODO*
#NimBLE buffers
*TODO*
#Tools
- https://github.com/eliotstock/memory : display the memory usage (FLASH/RAM) using the .map file from GCC.
The navigation ble service provides 4 characteristics to allow the watch to display navigation instructions from a companion application. This service is intended to be used when performing some outdoor activities, for example running or cycling.
The 4 characteristics are:
flag (string) - Upcoming icon name
narrative (string) - Textual description of instruction
manDist (string) - Manouvre Distance, the distance to the upcoming change
progress (uint8) - Percent complete of total route, value 0-100
## Service
The service UUID is 00010000-78fc-48fe-8e23-433b3a1942d0
All included icons are from pure-maps, which provides the actual routing from the client. The icon names ultimately come from the mapbox project "direction-icons", See https://github.com/rinigus/pure-maps/tree/master/qml/icons/navigation See the end of this document for the full list of supported icon names.
[NRF52-DK](https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52-DK) is the official developpment kit for NRF52832 SoC from Nordic Semiconductor.
It can be very useful for PineTime developpment:
[NRF52-DK](https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52-DK) is the official development kit for the NRF52832 SoC from Nordic Semiconductor used in the PineTime.
* You can use it embedded JLink SWD programmer/debugger to program and debug you code on the PineTime
* As it's based on the same SoC than the PineTime, you can program it to actually run the same code than the PineTime.
This page is about the 2nd point : we will build a stub that will allow us to run the same code than the one you could run on the PineTime. This will allow you to work more easily if you don't have a PineTime dev kit around, if you don't want to modify your dev kit for SWD programming, or if you want to use some feature from the DK (like power measurement).
This stub only implements the display, the button and the BLE radio. The other features from the pintime are missing:
This development kit can be very useful for PineTime development:
* heart rate sensor
* SPI flash
- You can use its embedded JLink SWD programmer/debugger to program and debug your code on the PineTime
* touchpad
- As it's based on the same SoC than the PineTime, you can program it to actually run the same code as the PineTime.
* accelerometer
This page is about the 2nd point. We will build a stub that will allow us to run the same code you can run on the PineTime. This will allow you to work more easily if you don't have a PineTime dev kit around, if you don't want to modify your dev kit for SWD programming, or if you want to use some feature from the NRF52-DK (like power measurement).
This stub only implements the display, the button and the BLE radio. The other features from the pintime are missing:
- heart rate sensor
- SPI flash
- touchpad
- accelerometer
These devices could be added on this stub, but I do not have the parts to try them out for now.
These devices could be added on this stub, but I do not have the parts to try them out for now.
The LCD controller that drive the display of the Pinetime is the Sitronix ST7789V. This controller is easy to integrate with an MCU thanks to its SPI interface, and has some interesting features like:
The LCD controller that drives the display of the Pinetime is the [Sitronix ST7789V](https://wiki.pine64.org/images/5/54/ST7789V_v1.6.pdf). This controller is easy to integrate with an MCU thanks to its SPI interface, and has some interesting features like:
- an on-chip display data RAM that can store the whole framebuffer
- an on-chip display data RAM that can store the whole framebuffer
- partial screen update
- partial screen update
- hardware assisted vertical scrolling
- hardware assisted vertical scrolling
- interrupt pin, allowing to drive the display with DMA and IRQ
- interrupt pin, allowing to drive the display with DMA and IRQ
- ...
- ...
When you want to write a device driver for a specific component, its datasheet is your holy bible. This document contains a lot of information about the chip, its specification, characteristics, features and functionalities.
When you want to write a device driver for a specific component, its datasheet is your holy bible. This document contains a lot of information about the chip, its specification, characteristics, features and functionalities.
Luckily for us, the datasheet of the ST7789 is great! It contains everything we need to write a nice driver for our beloved Pinetime.
Luckily for us, the datasheet of the ST7789 is great! It contains everything we need to write a nice driver for our beloved Pinetime.
In this document, I'll try to explain the process I've followed to write a device driver for the LCD. There were multiple iterations:
In this document, I'll try to explain the process I've followed to write a device driver for the LCD. There were multiple iterations:
- First, I tried to find the correct initialization sequence so that the controller is configured correctly according to the hardware configuration;
- First, I tried to find the correct initialization sequence so that the controller is configured correctly according to the hardware configuration;
- Then, I tried to display some pixels on the screen;
- Then, I tried to display some pixels on the screen;
- Next, I wanted to display squares, colors and text;
- Next, I wanted to display squares, colors and text;
@ -20,12 +24,14 @@ In this document, I'll try to explain the process I've followed to write a devic
I'll describe all these steps in the following chapters.
I'll describe all these steps in the following chapters.
## The datasheet
## The datasheet
As I said in the introduction, the datasheet will be your bedside book during your journey as a device driver designer. You'll read it from the beginning to the end once, twice, maybe ten times. Then, each time you'll want to do something new, you'll reopen the file and search for that specific paragraph or diagram than explains how the controller works so that you can figure out how to use it.
As I said in the introduction, the datasheet will be your bedside book during your journey as a device driver designer. You'll read it from the beginning to the end once, twice, maybe ten times. Then, each time you'll want to do something new, you'll reopen the file and search for that specific paragraph or diagram than explains how the controller works so that you can figure out how to use it.
The schematic of your board (the Pinetime schematics in this case) will also be very important, as you'll need to know how the LCD controller is physically connected to the MCU.
The schematic of your board (the Pinetime schematics in this case) will also be very important, as you'll need to know how the LCD controller is physically connected to the MCU.
How to read the datasheet? I recommend to read it from the beginning to the end (no joke) at least once. You certainly do not need to read everything in details, but it's good to know what information is available and where in the document. It'll be very useful during the development phase.
How to read the datasheet? I recommend to read it from the beginning to the end (no joke) at least once. You certainly do not need to read everything in details, but it's good to know what information is available and where in the document. It'll be very useful during the development phase.
You'll want to read some part with more attention :
You'll want to read some part with more attention :
- Data color coding in 4-Line Serial Interface : how to send the pixel to be display to the controller
- Data color coding in 4-Line Serial Interface : how to send the pixel to be display to the controller
- Display Data Ram : how is the memory organized
- Display Data Ram : how is the memory organized
- Power On/Off sequence
- Power On/Off sequence
@ -33,7 +39,6 @@ You'll want to read some part with more attention :
## One Pixel at a time
## One Pixel at a time
## Bulk transfers
## Bulk transfers
## DMA
## DMA
@ -41,6 +46,7 @@ You'll want to read some part with more attention :
## IRQ
## IRQ
## Bare metal integration
## Bare metal integration
Integration customisée dans la lib GFX que j'ai écrite
Integration customisée dans la lib GFX que j'ai écrite
Download the files **bootloader.bin**, **image-x.y.z.bin** and **pinetime-graphics-x.y.z.bin** from the release page:

The bootloader reads a boot logo from the external SPI flash memory. The first step consists of flashing a tool in the MCU that will flash the boot logo into this SPI flash memory. This first step is optional but recommended (the bootloader will display garbage on screen for a few second if you don't do it).
Using your SWD tool, flash **pinetime-graphics-x.y.z.bin** at offset **0x0000**. Reset the MCU and wait for a few seconds until the logo is completely drawn on the display.
Then, using your SWD tool, flash these file at the following offsets:
- bootloader.bin : **0x0000**
- image-x.y.z.bin : **0x8000**
Reset and voilà, you're running InfiniTime on your PineTime!
The Simple Weather Service provides a simple and straightforward API to specify the current weather and the forecast for the next 5 days.
It effectively replaces the original Weather Service (from InfiniTime 1.8) since InfiniTime 1.14.
## Service
The service UUID is `00050000-78fc-48fe-8e23-433b3a1942d0`.
## Characteristics
## Weather data (UUID 00050001-78fc-48fe-8e23-433b3a1942d0)
The host uses this characteristic to update the current weather information and the forecast for the next 5 days.
This characteristics accepts a byte array with the following 2-Bytes header:
- [0] Message Type :
- `0` : Current weather
- `1` : Forecast
- [1] Message Version :
- `0` : Currently supported
- `1` : Adds support for sunrise and sunset
### Current Weather
The byte array must contain the following data:
- [0] : Message type = `0`
- [1] : Message version = `1`
- [2][3][4][5][6][7][8][9] : Timestamp (64 bits UNIX timestamp, number of seconds elapsed since 1 JAN 1970) in local time (the same timezone as the one used to set the time)
- [10, 11] : Current temperature (°C * 100)
- [12, 13] : Minimum temperature (°C * 100)
- [14, 15] : Maximum temperature (°C * 100)
- [16]..[47] : location (string, unused characters should be set to `0`)
- [48] : icon ID
- 0 = Sun, clear sky
- 1 = Few clouds
- 2 = Clouds
- 3 = Heavy clouds
- 4 = Clouds & rain
- 5 = Rain
- 6 = Thunderstorm
- 7 = Snow
- 8 = Mist, smog
- [49, 50] : Sunrise (number of minutes elapsed since midnight)
- `0` sun already up when day starts
- `-1` unknown
- `-2` no sunrise (e.g. polar night)
- [51, 52] : Sunset (number of minutes elapsed since midnight)
- `-1` unknown
- `-2` no sunset (e.g. polar day)
### Forecast
The byte array must contain the following data:
- [0] : Message type = `1`
- [1] : Message version = `0`
- [2][3][4][5][6][7][8][9] : Timestamp (64 bits UNIX timestamp, number of seconds elapsed since 1 JAN 1970) in local time (the same timezone as the one used to set the time)
- [10] Number of days (Max 5, fields for unused days should be set to `0`)
This page describes the BLE implementation and API built in this firmware.
This page describes the BLE implementation and API built in this firmware.
**Note** : I'm a beginner in BLE related technologies and the information of this document reflect my current knowledge and understanding of the BLE stack. These informations might be erroneous or incomplete. Feel free to submit a PR if you think you can improve these.
---
### Table of Contents
- [BLE Connection](#ble-connection)
- [BLE FS](#ble-fs)
- [BLE UUIDs](#ble-uuids)
- [BLE Services](#ble-services)
- [CTS](#cts)
- [ANS](#ans)
- [Getting Information](#getting-information)
- [Firmware Version](#firmware-version)
- [Battery Level](#battery-level)
- [Heart Rate](#heart-rate)
- [Notifications](#notifications)
- [New Alert](#new-alert)
- [Notification Event](#notification-event)
- [Firmware Upgrades](#firmware-upgrades)
- [Step one](#step-one)
- [Step two](#step-two)
- [Step three](#step-three)
- [Step four](#step-four)
- [Step five](#step-five)
- [Step six](#step-six)
- [Step seven](#step-seven)
- [Step eight](#step-eight)
- [Step nine](#step-nine)
- [Music Control](#music-control)
- [Events](#events)
- [Status](#status)
- [Artist, Track, and Album](#artist-track-and-album)
- [Time](#time)
---
## BLE Connection
## BLE Connection
When starting the firmware start a BLE advertising : it send small messages that can be received by any *central* device in range. This allows the device to announce its presence to other devices.
A companion application (running on a PC, RasberryPi, smartphone) which received this avertising packet can request a connection to the device. This connection procedure allows the 2 devices to negociate communication parameters, security keys,...
When starting, the firmware starts BLE advertising. It sends small messages that can be received by any *central* device in range. This allows the device to announce its presence to other devices.
When the connection is established, the pinetime will try to discover services running on the companion application. For now **CTS** (**C**urrent **T**ime **S**ervice) and **ANS** (**A**lert **N**otification **S**ervice) are supported.
A companion application (running on a PC, Raspberry Pi, smartphone, etc.) which receives this advertising packet can request a connection to the device. This connection procedure allows the 2 devices to negotiate communication parameters, security keys, etc.
When the connection is established, the PineTime will try to discover services running on the companion application. For now **CTS** (**C**urrent **T**ime **S**ervice) and **ANS** (**A**lert **N**otification **S**ervice) are supported.
If **CTS** is detected, it'll request the current time to the companion application. If **ANS** is detected, it will listen to new notifications coming from the companion application.
If **CTS** is detected, it'll request the current time to the companion application. If **ANS** is detected, it will listen to new notifications coming from the companion application.
When possible, InfiniTime tries to implement BLE services defined by the BLE specification.
When the service does not exist in the BLE specification, InfiniTime implements custom services. Custom services are identified by a UUID, as are all BLE services. Here is how to define the UUID of custom services in InfiniTime:
```
- Base UUID : xxxxxxxx-78fc-48fe-8e23-433b3a1942d0
- Service UUID : SSSS0000-78fc-48fe-8e23-433b3a1942d0 where SSSS is the service ID
- Characteristic UUID : SSSSCCCC-78fc-48fe-8e23-433b3a1942d0 where CCCC is the characteristic ID for the service SSSS and is different than 0
```
The following custom services are implemented in InfiniTime:
- Since InfiniTime 0.8:
- Music Service : `00000000-78fc-48fe-8e23-433b3a1942d0`
Reading a value from the firmware version characteristic will yield a UTF-8 encoded string containing the version of InfiniTime being run on the device. Example: `1.6.0`.
#### Battery Level
Reading from the battery level characteristic yields a single byte of data. This byte can be converted to an unsigned 8-bit integer which will be the battery percentage. This characteristic allows notifications for updates as the value changes.
#### Heart Rate
Reading from the heart rate characteristic yields two bytes of data. I am not sure of the function of the first byte. It appears to always be zero. The second byte can be converted to an unsigned 8-bit integer which is the current heart rate. This characteristic also allows notifications for updates as the value changes.
---
### Notifications
InfiniTime uses the Alert Notification Service (ANS) for notifications. The relevant UUIDs are as follows:
- New Alert: `00002a46-0000-1000-8000-00805f9b34fb`
The new alert characteristic allows sending new notifications to InfiniTime. It requires the following format:
```
<category><amount>\x00<\x00-separateddata>
```
For example, here is what a normal notification looks like in Golang (language of `itd`):
```go
// \x00 is the category for simple alert, and there is one new notification, hence \x01.
"\x00\x01\x00Test Title\x00Test Body"
```
A call notification looks like so:
```go
// \x03 is the category for calls, and there is one new call notification, hence \x01.
"\x03\x01\x00Mary"
```
The `\x00` stands for hexadecimal `00` which means null.
Here is the list of categories and commands:
- Simple Alert: `0`
- Email: `1`
- News: `2`
- Call Notification: `3`
- Missed Call: `4`
- SMS/MMS: `5`
- Voicemail: `6`
- Schedule: `7`
- High Prioritized Alert: `8`
- Instant Message: `9`
- All Alerts: `0xFF`
These lists and information were retrieved from the following pages in the Nordic docs:
- [Alert Notification Service Client](https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v12.2.0%2Fgroup__ble__ans__c.html)
A call notification in InfiniTime contains three buttons. Decline, Accept, and Mute. The notification event characteristic contains the button tapped by the user on a call notification. This characteristic only allows notify, **not** read.
Enabling notifications from this characteristic, you get a single byte whenever the user taps a button on the call notification. This byte is an unsigned 8-bit integer that signifies one of the buttons. The numbers are as follows:
- 0: Declined
- 1: Accepted
- 2: Muted
---
### Firmware Upgrades
Firmware upgrades in InfiniTime are probably the most complex of the BLE operations. It is a nine step process requiring multiple commands be sent to multiple characteristics. The relevant UUIDs are as follows:
- Control Point: `00001531-1212-efde-1523-785feabcd123`
- Packet: `00001532-1212-efde-1523-785feabcd123`
A DFU upgrade archive for InfiniTime consists of multiple files. The most important being the .bin and .dat files. The first is the actual firmware, while the second is a packet that initializes DFU. Both are needed for a DFU upgrade.
The first thing to do is to enable notifications on the control point characteristic. This will be needed for verifying that the proper responses are being sent back from InfiniTime.
#### Step one
For the first step, write `0x01`, `0x04` to the control point characteristic. This will signal InfiniTime that a DFU upgrade is to be started.
#### Step two
In step two, send the total size in bytes of the firmware file to the packet characteristic. This value should be an unsigned 32-bit integer encoded as little-endian. In front of this integer should be 8 null bytes. This is because there are three items that can be updated and each 4 bytes is for one of those. The last four are for the InfiniTime application, so those are the ones that need to be set.
#### Step three
Before running step three, wait for a response from the control point. This response should be `0x10`, `0x01`, `0x01` which indicates a successful DFU start. In step three, send `0x02`, `0x00` to the control point. This will signal InfiniTime to expect the init packet on the packet characteristic.
#### Step four
The previous step prepared InfiniTime for this one. In this step, send the contents of the .dat init packet file to the packet characteristic. After this, send `0x02`, `0x01` indicating that the packet has been sent.
#### Step five
Before running this step, wait to receive `0x10`, `0x02`, `0x01` which indicates that the packet has been received. During this step, send the packet receipt interval to the control point. The firmware file will be sent in segments of 20 bytes each. The packet receipt interval indicates how many segments should be received before sending a receipt containing the amount of bytes received so that it can be confirmed to be the same as the amount sent. This is very useful for detecting packet loss. `itd` uses `0x08`, `0x0A` which indicates 10 segments.
#### Step six
In step six, write `0x03` to the control point, indicating that the firmware will be sent next on the packet characteristic.
#### Step seven
This step is the most difficult. Here, the actual firmware is sent to InfiniTime.
As mentioned before, the firmware file must be split up into segments of 20 bytes each and sent to the packet characteristic one by one. Every 10 segments (or whatever you have set the interval to), check for a response starting with `0x11`. The rest of the response will be the amount of bytes received encoded as a little-endian unsigned 32-bit integer. Confirm that this matches the amount of bytes sent, and then continue sending more segments.
#### Step eight
Before running this step, wait to receive `0x10`, `0x03`, `0x01` which indicates a successful receipt of the firmware image. In this step, write `0x04` to the control point to signal InfiniTime to validate the image it has received.
#### Step nine
Before running this step, wait to receive `0x10`, `0x04`, `0x01` which indicates that the image has been validated. In this step, send `0x05` to the control point as a command with no response. This signals InfiniTime to activate the new firmware and reboot.
Once all of these steps are complete, the DFU is complete. Don't forget to validate the firmware in the settings.
---
### Music Control
InfiniTime contains a music controller app which is meant to control the music playback and volume through the companion.
The following UUIDs are relevant to this:
- Events: `00000001-78fc-48fe-8e23-433b3a1942d0`
- Status: `00000002-78fc-48fe-8e23-433b3a1942d0`
- Artist: `00000003-78fc-48fe-8e23-433b3a1942d0`
- Track: `00000004-78fc-48fe-8e23-433b3a1942d0`
- Album: `00000005-78fc-48fe-8e23-433b3a1942d0`
#### Events
The events characteristic is meant to respond to user input in the music controller app.
Enabling notifications on this characteristic gives you a single byte upon any event. This byte can be converted to an unsigned 8-bit integer which corresponds to each possible event. Here are the events:
- App Opened: `0xe0`
- Play: `0x00`
- Pause: `0x01`
- Next: `0x03`
- Previous: `0x04`
- Volume up: `0x05`
- Volume down: `0x06`
#### Status
The status characteristic allows setting the playing status of music. Send `0x01` to the status characteristic for playing, and `0x00` for paused.
#### Artist, Track, and Album
These characteristics all work the same way. Simply send a UTF-8 encoded string to the relevant characteristic in order to set the value in the app.
---
### Time
InfiniTime allows setting its time via the Current Time Service (CTS)
The UUID for the current time characteristic is: `00002a2b-0000-1000-8000-00805f9b34fb`
This characteristic expects a particular format:
- Year (`uint16`)
- Month (`uint8`)
- Day (`uint8`)
- Hour (`uint8`)
- Minute (`uint8`)
- Second (`uint8`)
- Weekday (`uint8`)
- Microsecond divided by `1e6*256` (`uint8`)
- Binary 0001 (`uint8`)
Write all of these together, encoded as little-endian, to the current time characteristic.
The branching model of this project is based on the workflow named [Git flow](https://nvie.com/posts/a-successful-git-branching-model/).
It is based on 2 main branches:
The project has 1 main branch, aptly called **main**.
- **master** : this branch is always ready to be reployed. It means that at any time, we should be able to build the branch and release a new version of the application.
This branch contains the latest development that will be tagged for the next release once it's considered stable.
- **develop** : this branch contains the latest development that will be integrated in the next release once it's considered as stable.
New features should be implemented in **feature branches** created from **develop**. When the feature is ready, a pull-request is created and it'll be merge into **develop** when it is succesfully reviewed and accepted.
New features should be implemented in **feature branches** created from **main**.
When the feature is ready, a pull request is created and it'll be merged into **main** when it is successfully reviewed and accepted.
To release a new version of the application, when develop is considered stable, a **release** branch is created from **develop**. This can be considered as a *release candidate* branch. When everything is OK, this release branch is merged into **master** and the release is generated (a tag is applied to git, the release note is finalized, binaries are built,...) from **master**.
To release a new version of the application, when main is considered stable, a tag is created on the version bump commit in **main** and the release is generated (a tag is applied to git, the release note is finalized, binaries are built,...).
Git flow also supports the creation of **hotfix** branches when a bug is discovered in a released version. The **hotfix** branch is created from **master** and will be used only to implement a fix to this bug. Multiple hotfix branches can be created for the same release if more than one bugs are discovered.
We also supports the creation of **hotfix** branches when a bug is discovered in a released version. The **hotfix** branch is created from the latest tag and will be used only to implement a fix to this bug.
Multiple hotfix branches can be created for the same release if multiple bugs are discovered.
- A cross-compiler : [ARM-GCC (9-2020-q2-update)](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads/9-2020-q2-update)
- The NRF52 SDK 15.3.0 : [nRF-SDK v15.3.0](https://developer.nordicsemi.com/nRF5_SDK/nRF5_SDK_v15.x.x/nRF5_SDK_15.3.0_59ac345.zip)
- A reasonably recent version of CMake (I use 3.16.5)
## Build steps
## Dependencies
To build this project, you'll need:
- A cross-compiler : [ARM-GCC (10.3-2021.10)](https://developer.arm.com/downloads/-/gnu-rm)
- The NRF52 SDK 15.3.0 : [nRF-SDK v15.3.0](https://nsscprodmedia.blob.core.windows.net/prod/software-and-other-downloads/sdks/nrf5/binaries/nrf5sdk153059ac345.zip)
- The Python 3 modules `cbor`, `intelhex`, `click` and `cryptography` modules for the `mcuboot` tool (see [requirements.txt](../tools/mcuboot/requirements.txt))
- To keep the system clean, you can install python modules into a python virtual environment (`venv`)
CMake configures the project according to variables you specify the command line. The variables are:
CMake configures the project according to variables you specify the command line. The variables are:
Variable | Description | Example|
Variable | Description | Example|
----------|-------------|--------|
----------|-------------|--------|
**ARM_NONE_EABI_TOOLCHAIN_PATH**|path to the toolchain directory|`-DARM_NONE_EABI_TOOLCHAIN_PATH=/home/jf/nrf52/gcc-arm-none-eabi-9-2020-q2-update/`|
**ARM_NONE_EABI_TOOLCHAIN_PATH**|path to the toolchain directory|`-DARM_NONE_EABI_TOOLCHAIN_PATH=/home/jf/nrf52/gcc-arm-none-eabi-10.3-2021.10/`|
**NRF5_SDK_PATH**|path to the NRF52 SDK|`-DNRF5_SDK_PATH=/home/jf/nrf52/Pinetime/sdk`|
**NRF5_SDK_PATH**|path to the NRF52 SDK|`-DNRF5_SDK_PATH=/home/jf/nrf52/Pinetime/sdk`|
**USE_JLINK, USE_GDB_CLIENT and USE_OPENOCD**|Enable *JLink* mode, *GDB Client* (Black Magic Probe) mode or *OpenOCD* mode (set the one you want to use to `1`)|`-DUSE_JLINK=1`
**CMAKE_BUILD_TYPE (\*)**| Build type (Release or Debug). Release is applied by default if this variable is not specified.|`-DCMAKE_BUILD_TYPE=Debug`
**CMAKE_BUILD_TYPE**| Build type (Release or Debug). Release is applied by default if this variable is not specified.|`-DCMAKE_BUILD_TYPE=Debug`
**BUILD_DFU (\*\*)**|Build DFU files while building (needs [adafruit-nrfutil](https://github.com/adafruit/Adafruit_nRF52_nrfutil)).|`-DBUILD_DFU=1`
**NRFJPROG**|Path to the NRFJProg executable. Used only if `USE_JLINK` is 1.|`-DNRFJPROG=/opt/nrfjprog/nrfjprog`
**BUILD_RESOURCES (\*\*)**| Generate external resource while building (needs [lv_font_conv](https://github.com/lvgl/lv_font_conv) and [python3-pil/pillow](https://pillow.readthedocs.io) module). |`-DBUILD_RESOURCES=1`
**GDB_CLIENT_BIN_PATH**|Path to arm-none-eabi-gdb executable. Used only if `USE_GDB_CLIENT` is 1.|`-DGDB_CLIENT_BIN_PATH=/home/jf/nrf52/gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-gdb`
**TARGET_DEVICE**|Target device, used for hardware configuration. Allowed: `PINETIME, MOY_TFK5, MOY_TIN5, MOY_TON5, MOY_UNK`|`-DTARGET_DEVICE=PINETIME` (Default)
**GDB_CLIENT_TARGET_REMOTE**|Target remote connection string. Used only if `USE_GDB_CLIENT` is 1.|`-DGDB_CLIENT_TARGET_REMOTE=/dev/ttyACM0`
#### (\*) Note about **CMAKE_BUILD_TYPE**
By default, this variable is set to *Release*. It compiles the code with size and speed optimizations. We use this value for all the binaries we publish when we [release](https://github.com/InfiniTimeOrg/InfiniTime/releases) new versions of InfiniTime.
The *Debug* mode disables all optimizations, which makes the code easier to debug. However, the binary size will likely be too big to fit in the internal flash memory. If you want to build and debug a *Debug* binary, you can disable some parts of the code that are not needed for the test you want to achieve. You can also apply the *Debug* mode selectively on parts of the application by applying the `DEBUG_FLAGS` only for the part (CMake target) you want to debug. For example, let's say you want to debug code related to LittleFS, simply set the compilation options for the RELEASE configuration of the target to `DEBUG_FLAGS` (in `src/CMakeLists.txt`). This will force the compilation of that target in *Debug* mode while the rest of the project will be built in *Release* mode. Example:
$<$<CONFIG:RELEASE>: ${DEBUG_FLAGS}> # Change from RELEASE_FLAGS to DEBUG_FLAGS
$<$<COMPILE_LANGUAGE:CXX>: ${CXX_FLAGS}>
$<$<COMPILE_LANGUAGE:ASM>: ${ASM_FLAGS}>
)
```
```
#### CMake command line for GDB Client (Black Magic Probe)
#### (\*\*) Note about **BUILD_DFU**
```
DFU files are the files you'll need to install your build of InfiniTime using OTA (over-the-air) mechanism. To generate the DFU file, the Python tool [adafruit-nrfutil](https://github.com/adafruit/Adafruit_nRF52_nrfutil) is needed on your system. Check that this tool is properly installed before enabling this option.
During the project generation, CMake created the following targets:
- FLASH_ERASE : mass erase the flash memory of the NRF52.
- FLASH_pinetime-app : flash the firmware into the NRF52.
- pinetime-app : build the standalone (without bootloader support) version of the firmware.
- pinetime-mcuboot-app : build the firmware with the support of the bootloader (based on MCUBoot).
- pinetime-graphics : small firmware that writes the boot graphics into the SPI flash.
If you just want to build the project and run it on the Pinetime, using *pinetime-app* is recommanded. See [this page](../bootloader/README.md) for more info about bootloader support.
During the project generation, CMake created the following targets:
- **pinetime-app** : build the standalone (without bootloader support) version of the firmware.
- **pinetime-recovery** : build the standalone recovery version of infinitime (light firmware that only supports OTA and basic UI)
- **pinetime-recovery-loader** : build the standalone tool that flashes the recovery firmware into the external SPI flash
- **pinetime-mcuboot-app** : build the firmware with the support of the bootloader (based on MCUBoot).
- **pinetime-mcuboot-recovery** : build pinetime-recovery with bootloader support
- **pinetime-mcuboot-recovery-loader** : build pinetime-recovery-loader with bootloader support
If you just want to build the project and run it on the Pinetime, using *pinetime-app* is recommended. See [this page](../bootloader/README.md) for more info about bootloader support.
Build:
Build:
```
```
make -j pinetime-app
make -j4 pinetime-app
```
```
List of files generated:
List of files generated:
Binary files are generated into the folder `src`:
Binary files are generated into the folder `src`:
- **pinetime-app.bin, .hex and .out** : standalone firmware in bin, hex and out formats.
- **pinetime-app.map** : map file
- **pinetime-mcuboot-app.bin, .hex and .out** : firmware with bootloader support in bin, hex and out formats.
- **pinetime-mcuboot-app.map** : map file
- **pinetime-graphics.bin, .hex and .out** : firmware for the boot graphic in bin, hex and out formats.
- **pinetime-graphics.map** : map file
### Program and run
#### Using CMake targets
These target have been configured during the project generation by CMake according to the parameters you provided to the command line.
Mass erase:
- **pinetime-app.bin, .hex and .out** : standalone firmware in bin, hex and out formats.
```
- **pinetime-app.map** : map file
make FLASH_ERASE
- **pinetime-mcuboot-app.bin, .hex and .out** : firmware with bootloader support in bin, hex and out formats.
```
- **pinetime-mcuboot-app.map** : map file
- **pinetime-mcuboot-app-image** : MCUBoot image of the firmware
- **pinetime-mcuboot-app-dfu** : DFU file of the firmware
Flash the application:
The same files are generated for **pinetime-recovery** and **pinetime-recovery-loader**
Use the command loadfile to program the .hex file:
```
J-Link>loadfile pinetime-app.hex
Downloading file [pinetime-app.hex]...
Comparing flash [100%] Done.
Erasing flash [100%] Done.
Programming flash [100%] Done.
Verifying flash [100%] Done.
J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (4096 bytes)
J-Link: Flash download: Total time needed: 0.322s (Prepare: 0.043s, Compare: 0.202s, Erase: 0.003s, Program: 0.064s, Verify: 0.000s, Restore: 0.007s)
O.K.
```
Then reset (r) and start (g) the CPU:
```
J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
J-Link>g
```
#### JLink RTT
RTT is a feature from Segger's JLink devices that allows bidirectionnal communication between the debugger and the target. This feature can be used to get the logs from the embedded software on the development computer.
A [Docker image (Dockerfile)](../docker) containing all the build environment is available for X86_64 and AMD64 architectures. This image makes the build of the firmware and the generation of the DFU file for OTA.
## Build the image
A [Docker image (Dockerfile)](../docker) containing all the build environment is available for X86_64 and ARM64 architectures.
The image is not (yet) available on DockerHub, you need to build it yourself, which is quite easy. The following commands must be run from the root of the project.
These images make the build of the firmware and the generation of the DFU file for OTA quite easy, as well as preventing clashes with any other toolchains or development environments you may have installed.
If you are running on a x86_64 computer :
Based on Ubuntu 22.04 with the following build dependencies:
Before continuing, the build image needs to be either build locally or pulled
from Docker Hub, as described in the two sections below:
### Build the image
You can build the image yourself if you like!
The following commands must be run from the root of the project. This operation
will take some time but, when done, a new image named `infinitime-build` is
available.
```sh
docker build -t infinitime-build ./docker
```
```
This operation will take some time. It builds a Docker image based on Ubuntu, install some packages, download the ARM toolchain, the NRF SDK, MCUBoot and adafruit-nrfutil.
### Pull the image from Docker Hub
When this is done, a new image named *infinitime-build* is available.
The image is available via Docker Hub for both the amd64 and arm64v8 architectures at
Replace *<project_root>* by the path of the root of the project on your computer. For example:
The default `latest` tag *should* automatically identify the correct image architecture, but if for some reason Docker does not, you can specify it manually:
```
- For AMD64 (x86_64) systems: `docker pull --platform linux/amd64 infinitime/infinitime-build`
docker run --rm -v /home/jf/git/PineTime:/sources infinitime-build
- For ARM64v8 (ARM64/aarch64) systems: `docker pull --platform linux/arm64 infinitime/infinitime-build`
## Run a container to build the project
The `infinitime-build` image contains all the dependencies you need.
The default `CMD` will compile sources found in `/sources`, so you need only mount your code.
This example will build the firmware, generate the MCUBoot image and generate the DFU file.
Outputs will be written to **<project_root>/build/output**:
```sh
cd <project_root> # e.g. cd ./work/Pinetime
docker run --rm -it -v ${PWD}:/sources infinitime-build
```
```
This will start a container, build the firmware and generate the MCUBoot image and the DFU file. The output of the build is stored in **<project_root>/built/output**.
If the docker service is running as `root`, the build process inside the
container also runs as `root`, which is not convenient as all the files
generated by the build will also belong to `root`. The parameter `--user`
overrides this behaviour. The command below ensures that all files are created
The .VS Code folder contains configuration files for developing InfiniTime with VS Code. Effort was made to have these rely on Environment variables instead of hardcoded paths.
## Environment Setup
To support as many setups as possible the VS Code configuration files expect there to be certain environment variables to be set.
Variable | Description | Example
----------|-------------|--------
**ARM_NONE_EABI_TOOLCHAIN_PATH**|path to the toolchain directory|`export ARM_NONE_EABI_TOOLCHAIN_PATH=/opt/gcc-arm-none-eabi-10.3-2021.10`
**NRF5_SDK_PATH**|path to the NRF52 SDK|`export NRF5_SDK_PATH=/opt/nRF5_SDK_15.3.0_59ac345`
## VS Code Extensions
We leverage a few VS Code extensions for ease of development.
#### Required Extensions
- [C/C++](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools) - C/C++ IntelliSense, debugging, and code browsing.
- [CMake Tools](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools) - Extended CMake support in Visual Studio Code
#### Optional Extensions
[Cortex-Debug](https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug) - ARM Cortex-M GDB Debugger support for VS Code
Cortex-Debug is only required for interactive debugging using VS Codes built in GDB support.
## VS Code/Docker DevContainer
The .devcontainer folder contains the configuration and scripts for using a Docker dev container for building InfiniTime
Using the [Remote-Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) extension is recommended. It will handle configuring the Docker virtual machine and setting everything up.
More documentation is available in the [readme in .devcontainer](usingDevcontainers.md)
### DevContainer on Ubuntu
To use the DevContainer configuration on Ubuntu based systems two changes need to be made:
1. Modify the file `.devcontainer/devcontainer.json` and add the argument `"--net=host"` to the `"runArgs"` parameter making the line look like this:
2. Modify the file `.vscode/launch.json` and change the argument of `"gdbTarget"` to `"127.0.0.1:3333"`, making the line look like:
`"gdbTarget": "127.0.0.1:3333",`
3. To start debugging launch openocd on your host system with the appropriate configuration, for example with a stlink-v2 the command is:
`openocd -f interface/stlink.cfg -f target/nrf52.cfg`. This launches openocd with the default ports `3333`, `4444` and `6666`.
4. In VsCode go to the Debug pane on the left of the screen and select the configuration `Debug - Openocd docker Remote` and hit the play button on the left.
The user interface of InfiniTime is made up of **screens**.
Screens that are opened from the app launcher are considered **apps**.
Every app in InfiniTime is its own class.
An instance of the class is created when the app is launched, and destroyed when the user exits the app.
Apps run inside the `DisplayApp` task (briefly discussed [here](./Intro.md)).
Apps are responsible for everything drawn on the screen when they are running.
Apps can be refreshed periodically and reacts to external events (touch or button).
## Interface
Every app class is declared inside the namespace `Pinetime::Applications::Screens`
and inherits
from [`Pinetime::Applications::Screens::Screen`](https://github.com/InfiniTimeOrg/InfiniTime/blob/main/src/displayapp/screens/Screen.h).
Each app defines its own constructor.
The constructors mostly take references to InfiniTime `Controllers` (ex: Alarm, DateTime, BLE services, Settings,...)
the app needs for its operations. The constructor is responsible for initializing the UI of the app.
The **destructor** cleans up LVGL and restores any changes (for example re-enable sleeping).
App classes can override `bool OnButtonPushed()`, `bool OnTouchEvent(TouchEvents event)`
and `bool OnTouchEvent(uint16_t x, uint16_t y)` to implement their own functionality for those events.
Apps that need to be refreshed periodically create an `lv_task` (using `lv_task_create()`)
that will call the method `Refresh()` periodically.
## App types
There are basically 3 types of applications : **system** apps and **user** apps and **watch faces**.
**System** applications are always built into InfiniTime, and InfiniTime cannot work properly without those apps.
Settings, notifications and the application launcher are examples of such system applications.
**User** applications are optionally built into the firmware. They extend the functionalities of the system.
**Watch faces** are very similar to the **user** apps, they are optional, but at least one must be built into the firmware.
The distinction between **system** apps, **user** apps and watch faces allows for more flexibility and customization.
This allows to easily select which user applications and watch faces must be built into the firmware
without overflowing the system memory.
## Apps and watch faces initialization
Apps are created by `DisplayApp` in `DisplayApp::LoadScreen()`.
This method simply call the creates an instance of the class that corresponds to the app specified in parameters.
The constructor of **system** apps is called directly. If the application is a **user** app,
the corresponding `AppDescription` is first retrieved from `userApps`
and then the function `create` is called to create an instance of the app.
Watch faces are handled in a very similar way as the **user** apps : they are created by `DisplayApp` in the method `DisplayApp::LoadScreen()` when the application type is `Apps::Clock`.
## User application selection at build time
The list of user applications is generated at build time by the `consteval` function `CreateAppDescriptions()`
in `UserApps.h`. This method takes the list of applications that must be built into the firmware image.
This list of applications is defined as a list `Apps` enum values named `UserAppTypes` in `Apps.h`.
For each application listed in `UserAppTypes`, an entry of type `AppDescription` is added to the array `userApps`.
This entry is created by using the information provided by a template `AppTraits`
that is customized for every user application.
Here is an example of an AppTraits customized for the Alarm application.
It defines the type of application, its icon and a function that returns an instance of the application.
Both of these files should be in [displayapp/screens/](/src/displayapp/screens/).
Now we have our very own app, but InfiniTime does not know about it yet.
The first step is to include your `MyApp.cpp` (or any new cpp files for that matter)
in the compilation by adding it to [CMakeLists.txt](/CMakeLists.txt).
The next step to making it launch-able is to give your app an id.
To do this, add an entry in the enum class `Pinetime::Applications::Apps` ([displayapp/apps/Apps.h](/src/displayapp/apps/Apps.h.in)).
Name this entry after your app. Add `#include "displayapp/screens/MyApp.h"`
to the file [displayapp/DisplayApp.cpp](/src/displayapp/DisplayApp.cpp).
If your application is a **system** application, go to the function `DisplayApp::LoadScreen`
and add another case to the switch statement.
The case will be the id you gave your app earlier.
If your app needs any additional arguments, this is the place to pass them.
If your application is a **user** application, you don't need to add anything in DisplayApp,
everything will be automatically generated for you.
The user application will also be automatically be added to the app launcher menu.
Since the list of **user** application is generated by CMake, you need to add the variable `ENABLE_USERAPPS` to the command line of CMake.
This variable must be set with a string composed of an ordered list of the **user** applications that must be built into the firmware.
The items of the list are fields from the enumeration `Apps`.
Ex : build the firmware with 3 user application : Alarm, Timer and MyApp (the application will be listed in this specific order in the application menu).
This page is meant to guide you through the source code, so you can find the relevant files for what you're working on.
## FreeRTOS
Infinitime is based on FreeRTOS, a real-time operating system.
FreeRTOS provides several quality of life abstractions (for example easy software timers)
and most importantly supports multiple tasks.
If you want to read up on real-time operating systems, you can look [here](https://www.freertos.org/implementation/a00002.html) and [here](https://www.freertos.org/features.html).
The main "process" creates at least one task and then starts the FreeRTOS task scheduler.
This main "process" is the standard main() function inside [main.cpp](/src/main.cpp).
The task scheduler is responsible for giving every task enough cpu time.
As there is only one core on the SoC of the PineTime, real concurrency is impossible and the scheduler has to swap tasks in and out to emulate it.
### Tasks
Tasks are created by calling `xTaskCreate` and passing a function with the signature `void functionName(void*)`.
For more info on task creation see the [FreeRTOS Documentation](https://www.freertos.org/a00125.html).
In our case, main calls `systemTask.Start()`, which creates the **"MAIN" task**.
The function running inside that task is `SystemTask::Work()`.
You may also see this task being referred to as the **work task**.
Both functions are located inside [systemtask/SystemTask.cpp](/src/systemtask/SystemTask.cpp). `SystemTask::Work()` initializes all the driver and controller objects.
It also starts the **task "displayapp"**, which is responsible for launching and running apps, controlling the screen and handling touch events (or forwarding them to the active app).
You can find the "displayapp" task inside [displayapp/DisplayApp.cpp](/src/displayapp/DisplayApp.cpp).
There are also other tasks that are responsible for Bluetooth ("ll" and "ble" inside [libs/mynewt-nimble/porting/npl/freertos/src/nimble_port_freertos.c](/src/libs/mynewt-nimble/porting/npl/freertos/src/nimble_port_freertos.c))
and periodic tasks like heartrate measurements ([heartratetask/HeartRateTask.cpp](/src/heartratetask/HeartRateTask.cpp)).
While it is possible for you to create your own task when you need it, it is recommended to just add functionality to `SystemTask::Work()` if possible.
If you absolutely need to create another task, try to estimate how much [stack space](https://www.freertos.org/FAQMem.html#StackSize) (in words/4-byte packets)
it will need instead of just typing in a large-ish number.
You can use `configMINIMAL_STACK_SIZE` which is currently set to 120 words.
## Controllers
Controllers in InfiniTime are singleton objects that can provide access to certain resources to apps.
Some of them interface with drivers, others are the driver for the resource.
The resources provided don't have to be hardware-based.
They are declared in main.cpp and initialized in [systemtask/SystemTask.cpp](/src/systemtask/SystemTask.cpp).
Some controllers can be passed by reference to apps that need access to the resource (for example vibration motor).
They reside in [components/](/src/components/) inside their own subfolder.
## Apps
For more detail see the [Apps page](./Apps.md)
## Bluetooth
Header files with short documentation for the functions are inside [libs/mynewt-nimble/nimble/host/include/host/](/src/libs/mynewt-nimble/nimble/host/include/host/).
- files from the project : `#include "relative/path/to/the/file.h"`
- external files and std : `#include <file.h>`
- use includes relative to included directories like `src`, not relative to the current file. Don't do: `#include "../file.h"`
- Only use [primary spellings for operators and tokens](https://en.cppreference.com/w/cpp/language/operator_alternative)
- Use `auto` sparingly. Don't use `auto` for [fundamental/built-in types](https://en.cppreference.com/w/cpp/language/types) and [fixed width integer types](https://en.cppreference.com/w/cpp/types/integer), except when initializing with a cast to avoid duplicating the type name.
[Amazfish](https://openrepos.net/content/piggz/amazfish) is a companion app that supports many smartwatches and activity trackers running on [SailfishOS](https://sailfishos.org/).
## Features
The following features are implemented:
- Scanning & detection of Pinetime-JF / InfiniTime
- Connection / disconnection
- Time synchronization
- Notifications
- Music control
## Demo
[This video](https://seafile.codingfield.com/f/21c5d023452740279e36/) shows how to connect to the Pinetime and control the playback of the music on the phone.
Amazfish and Sailfish OS are running on the [Pinephone](https://www.pine64.org/pinephone/), another awesome device from Pine64.
[Gadgetbridge](https://gadgetbridge.org/) is an Android application that supports many smartwatches and fitness trackers.
The integration of InfiniTime (previously Pinetime-JF) is now merged into the master branch (https://codeberg.org/Freeyourgadget/Gadgetbridge/).
## Features
The following features are implemented:
- Scanning & detection of Pinetime-JF / InfiniTime
- Connection / disconnection
- Notifications
## Demo
[This video](https://seafile.codingfield.com/f/0a2920b9d765462385e4/) shows how to scan, connect, send notification (using the debug screen) and disconnect from the Pinetime.
[NRFConnect](https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Connect-for-mobile) is a powerful application (running on Android and iOS) which allows to scan and connect to BLE devices.
## Features
- Scanning, connect, disconnect
- Time synchronization
- OTA
InfiniTime implements the Nordic DFU protocol for the OTA functionality. NRFConnect also supports this protocol.
# Demo
[This video](https://seafile.codingfield.com/f/a52b69683a05472a90c7/) shows how to use NRFConnect to update the firmware running on the Pinetime.
You use your Pinetime and find a bug in the firmware? [Create an issue on Github](https://github.com/JF002/Pinetime/issues) explaining the bug, how to reproduce it, the version of the firmware you use...
## Write and improve documentation
Documentation might be incomplete, or not clear enough, and it is always possible to improve it with better wording, pictures, photo, video,...
As the documentation is part of the source code, you can submit your improvements to the documentation by submitting a pull request (see below).
## Fix bugs, add functionalities and improve the code
You want to fix a bug, add a cool new functionality or improve the code? See *How to submit a pull request below*.
## Spread the word
Pinetime is a cool open source project that deserves to be know. Talk about it around you, on social networks, on your blog,... and let people know that we are working on an open-source firmware for a smartwatch!
# How to submit a pull request ?
Your contribution is more than welcome!
If you want to fix a bug, add a functionality or improve the code, you'll first need to create a branch from the **develop** branch (see [this page about the branching model](./branches.md)). This branch is called a feature branch, and you should choose a name that explains what you are working on (ex: "add-doc-about-contributions"). In this branch, try to focus on only one topic, bug or feature. For example, if you created this branch to work on the UI of a specific application, do not commit modifications about the SPI driver. If you want to work on multiple topics, create one branch per topic.
When your feature branch is ready, make sure it actually works and do not forget to write documentation about it if necessary.
Then, you can submit a pull-request for review. Try to describe your pull request as much as possible: what did you do in this branch, how does it work, how is it designed, are there any limitations,... This will help the contributors to understand and review your code easily.
Other contributors can post comments about the pull request, maybe ask for more info or adjustements in the code.
Once the pull request is reviewed an accepted, it'll be merge in **develop** and will be released in the next release version of the firmware.
# Coding convention
## Language
The language of this project is **C++**, and all new code must be written in C++. (Modern) C++ provides a lot of useful tools and functionalities that are beneficial for embedded software development like `constexpr`, `template` and anything that provides zero-cost abstraction.
It's OK to include C code if this code comes from another library like FreeRTOS, NimBLE, LVGL or the NRF-SDK.
## Coding style
The most important rule to follow is to try to keep the code as easy to read and maintain as possible.
- **Identation** : 2 spaces, no tabulation
- **Opening brace** at the end of the line
- **Naming** : Choose self-describing variable name
- **class** : PascalCase
- **namespace** : PascalCase
- **variable** : camelCase, **no** prefix/suffix ('_', 'm_',...) for class members
These files are needed by the Pine64 factory to flash InfiniTime as the default firmware on the PineTimes.
Two files are needed: an **HEX (.hex)** file that contains the content of the internal flash memory (bootloader + InfiniTime) and a **binary (.bin)** file that contains the content of the external flash memory (recovery firmware).
where `bootloader.bin` is the [last stable version](https://github.com/JF002/pinetime-mcuboot-bootloader/releases) of the [bootloader](https://github.com/JF002/pinetime-mcuboot-bootloader).
where `pinetime-mcuboot-app-image-1.6.0.bin` is [the bin of the last MCUBoot image](https://github.com/InfiniTimeOrg/InfiniTime/releases) of [InfiniTime](https://github.com/InfiniTimeOrg/InfiniTime).
Pay attention to the parameter `--change-addresses 0x8000`. It's needed to ensure the image will be flashed at the offset expected by the bootloader (0x8000).
This file must be flashed at offset **0x00** of the internal memory of the NRF52832.
## spinor.bin
This file is the MCUBoot image of the last stable version of the recovery firmware. It must be flashed at offset **0x00** of the external SPINOR flash memory.
For each new *stable* version of Pinetime, a [release note](https://github.com/JF002/Pinetime/releases) is created. It contains a description of the main changes in the release and some files you can use to flash the firmware in your Pinetime.
For each new *stable* version of IniniTime, a [release note](https://github.com/InfiniTimeOrg/InfiniTime/releases) is created. It contains a description of the main changes in the release and some files you can use to flash the firmware to your Pinetime.
This page describes the files from the release notes and how to use them.
This page describes the files from the release notes and how to use them.
**NOTE :** the files included in different could be different. This page describes the release note of [version 0.7.1](https://github.com/JF002/Pinetime/releases/tag/0.7.1), which is the version that'll probably be pre-programmed at the factory for the next batch of Pinetime devkits.
**NOTE :** the files included in different Releases could be different. This page describes the release notes of [version 0.7.1](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/0.7.1), which is the version that is pre-programmed for the last batches of pinetimes but will be replaced with [1.0.0](https://github.com/jF002/infiniTime/releases/tag/1.0.0) around june 2021.
## Files included in the release note
## Files included in the release notes
### Standalone firmware
### Standalone firmware
This firmware is standalone, meaning that it does not need a bootloader to actually run. It is intended to be flash at offset 0, meaning it will erase any bootloader that might be present in memory.
- **pinetime-app.out** : Output file of GCC containing debug symbols, useful is you want to debug the firmware using GDB.
This firmware is standalone, meaning that it does not need a bootloader to actually run. It is intended to be flashed at offset 0, meaning it will erase any bootloader that might be present in memory.
- **pinetime-app.hex** : Firmware in Intel HEX file format. Easier to use because it contains the offset in memory where it must be flashed, you don't need to specify it.
- **pintime-app.bin** : Firmware in binary format. When programming it, you have to specify the offset (0x00) in memory where it must be flashed.
- **pinetime-app.out** : Output file of GCC containing debug symbols, useful if you want to debug the firmware using GDB.
- **pinetime-app.map** : Map file containing all the symbols, addresses in memory,...
- **pinetime-app.hex** : Firmware in Intel HEX file format. Easier to use because it contains the offset in memory where it must be flashed, you don't need to specify it.
- **pintime-app.bin** : Firmware in binary format. When programming it, you have to specify the offset (0x00) in memory where it must be flashed.
- **pinetime-app.map** : Map file containing all the symbols, addresses in memory,...
**This firmware must be flashed at address 0x00 in the main flash memory**
**This firmware must be flashed at address 0x00 in the main flash memory**
### Bootloader
### Bootloader
The bootloader is maintained by [lupyuen](https://github.com/lupyuen) and is a binary version of [this release](https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v5.0.4).
- **bootloader.hex** : Firmware in Intel HEX file format.
The bootloader is maintained by [lupyuen](https://github.com/lupyuen) and is a binary version of [this release](https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v5.0.4).
**This firmware must be flashed at address 0x00 in the main flash memory**
- **bootloader.hex** : Firmware in Intel HEX file format.
**This firmware must be flashed at address 0x00 in the main flash memory**
### Graphics firmware
### Graphics firmware
This firmware is a small utility firmware that writes the boot graphic in the external SPI flash memory. You need it if you want to use the [bootloader](../bootloader/README.md).
This firmware is a small utility firmware that writes the boot graphic in the external SPI flash memory. You need it if you want to use the [bootloader](../bootloader/README.md).
- **pinetime-graphics.out** : Output file of GCC containing debug symbols, useful is you want to debug the firmware using GDB.
- **pinetime-graphics.out** : Output file of GCC containing debug symbols, useful is you want to debug the firmware using GDB.
- **pinetime-graphics.hex** : Firmware in Intel HEX file format. Easier to use because it contains the offset in memory where it must be flashed, you don't need to specify it.
- **pinetime-graphics.hex** : Firmware in Intel HEX file format. Easier to use because it contains the offset in memory where it must be flashed, you don't need to specify it.
- **pintime-graphics.bin** : Firmware in binary format. When programming it, you have to specify the offset (0x00) in memory where it must be flashed.
- **pintime-graphics.bin** : Firmware in binary format. When programming it, you have to specify the offset (0x00) in memory where it must be flashed.
- **pinetime-graphics.map** : Map file containing all the symbols, addresses in memory,...
- **pinetime-graphics.map** : Map file containing all the symbols, addresses in memory,...
**This firmware must be flashed at address 0x00 in the main flash memory**
**This firmware must be flashed at address 0x00 in the main flash memory**
### Firmware with bootloader
### Firmware with bootloader
This firmware is intended to be used with our [MCUBoot-based bootloader](../bootloader/README.md).
This firmware is intended to be used with our [MCUBoot-based bootloader](../bootloader/README.md).
- **pinetime-mcuboot-app-image.hex**: Firmware wrapped into an MCUBoot image. This is **the** file that must be flashed **@ 0x8000** into flash memory. If the [bootloader](../bootloader/README.md) has been successfully programmed, it should run this firmware after the next reset.
- **pinetime-mcuboot-app-image.hex**: Firmware wrapped into an MCUBoot image. This is **the** file that must be flashed at **0x8000** into the flash memory. If the [bootloader](../bootloader/README.md) has been successfully programmed, it should run this firmware after the next reset.
The following files are not directly usable by the bootloader:
The following files are not directly usable by the bootloader:
- **pinetime-mcuboot-app.out** : Output file of GCC containing debug symbols, useful is you want to debug the firmware using GDB.
- **pinetime-mcuboot-app.out** : Output file of GCC containing debug symbols, useful is you want to debug the firmware using GDB.
- **pinetime-mcuboot-app.hex** : Firmware in Intel HEX file format.
- **pinetime-mcuboot-app.hex** : Firmware in Intel HEX file format.
- **pinetime-mcuboot-app.bin** : Firmware in binary format.
- **pinetime-mcuboot-app.bin** : Firmware in binary format.
- **pinetime-mcuboot-app.map** : Map file containing all the symbols, addresses in memory,...
- **pinetime-mcuboot-app.map** : Map file containing all the symbols, addresses in memory,...
### OTA (Update the firmware Over-The-Air)
### OTA (Update the firmware Over-The-Air)
Once the bootloader and application firmware are running, it is possible to update the current firmware or even replace it with another firmware **that uses the same bootloader based on MCUBoot**.
Once the bootloader and application firmware are running, it is possible to update the current firmware or even replace it with another firmware **that uses the same bootloader based on MCUBoot**.
**NOTE :** Use this file **only** if you programmed our [MCUBoot-based bootloader](../bootloader/README.md). This file is not compatible with other bootloaders like the one that is based on the closed source NRF SoftDevice !
**NOTE :** Use this file **only** if you programmed our [MCUBoot-based bootloader](../bootloader/README.md). This file is not compatible with other bootloaders like the one that is based on the closed source NRF SoftDevice !
- **pinetime-app-dfu.zip** : This is the file you must provide toNRFConnect to update the firmware over BLE.
- **pinetime-app-dfu.zip** : This is the file you must provide toNRFConnect to update the firmware over BLE.
# Firmware, InfiniTime, Bootloader, Recovery firmware, OTA, DFU... What is it?
You may have already encountered these words by reading the announcement, release notes, or [the wiki guide](https://wiki.pine64.org/wiki/Upgrade_PineTime_to_InfiniTime_1.0.0) and you may find them confusing if you're not familiar with the project.
A **firmware** is software running on the embedded hardware of a device.
InfiniTime has three distinct firmwares:
- **[InfiniTime](https://github.com/InfiniTimeOrg/InfiniTime)** is the operating system.
- **[The bootloader](https://github.com/JF002/pinetime-mcuboot-bootloader)** is responsible for safely applying firmware updates and runs before booting into InfiniTime.
- **The recovery firmware** is a special *application firmware* than can be loaded by the bootloader on user request. This firmware can be useful in case of serious issue, when the main application firmware cannot perform an OTA update correctly.
**OTA** (**O**ver **T**he **A**ir) refers to updating of the firmware over BLE (**B**luetooth **L**ow **E**nergy). This is a functionality that allows the user to update the firmware on their device wirelessly.
**DFU** (**D**evice **F**irmware **U**pdate) is the file format and protocol used to send the update of the firmware to the watch over-the-air. InfiniTime implements the (legacy) DFU protocol from Nordic Semiconductor (NRF).
## Bootloader
Most of the time, the bootloader just runs without your intervention (updating and loading the firmware).
However, you can use the bootloader to rollback to the previous firmware, or load the recovery firmware using the push button:
- Press and hold the button until the pine cone is drawn in **blue** to force the rollback of the previous version of the firmware, even if you've already validated the current one.
- Press and hold the button until the pine cone is drawn in **red** to load the recovery firmware. This recovery firmware only provides BLE connectivity and OTA functionality.
More info about the bootloader in [its project page](https://github.com/JF002/pinetime-mcuboot-bootloader/blob/master/README.md).
On April 22, 2021, InfiniTime and Pine64 [announced the release of InfiniTime 1.0.0](https://www.pine64.org/2021/04/22/its-time-infinitime-1-0/) and the availability of PineTime smartwatches as an *enthusiast grade end-user product*. This page aims to guide you with your first step with your new PineTime.
It is highly recommended to update the firmware to the latest version when you receive your watch and when a new InfiniTime version is released. More information on updating the firmware [here](/doc/gettingStarted/updating-software.md).
## InfiniTime quick user guide
### Setting the time
By default, InfiniTime starts on the digital watch face. It'll probably display the epoch time (1 Jan 1970, 00:00).
You can sync the time using companion apps.
- Gadgetbridge automatically synchronizes the time when you connect it to your watch. More information on Gadgetbridge [here](/doc/gettingStarted/ota-gadgetbridge.md)
- [Sync the time with NRFConnect](/doc/gettingStarted/time-nrfconnect.md)
- [Sync the time with your browser](https://hubmartin.github.io/WebBLEWatch/)
You can also set the time in the settings without a companion app. (version >1.7.0)
InfiniTime doesn't handle daylight savings automatically, so make sure to set the correct time or sync it with a companion app.
### Digital watch face

This is what the default digital watch face looks like. You can change watch faces in the settings.
The indicator on the top left is visible if you have unread notifications
On the top right, there are status icons
- The battery icon shows roughly how much charge is remaining
- The Bluetooth icon is visible when the watch is connected to a companion app
- A plug icon is shown when the watch is plugged into a charger.
On the bottom left, you can see your heart rate if you have the measurement enabled in the heart rate app.
On the bottom right, you can see how many steps you have taken today.
### Navigation in the menu




- Swipe **up** to display the application menus. Apps (stopwatch, music, step, games,...) can be started from this menu.
- Swipe **down** to display the notification panel. Notifications sent by your companion app will be displayed here.
- Swipe **right** to display the Quick Actions menu. This menu allows you to
- Set the brightness of the display
- Start the **flashlight** app
- Enable/disable notifications (Do Not Disturb mode)
- Enter the **settings** menu
- Swipe up and down to see all options
- Click the button to go back a screen.
- You can hold the button for a short time to return to the watch face. (version >1.7.0)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.