PINE64 - User contributions [en]

PineTime Hardware Wishlist

2020-12-02T18:42:56Z

Caligari: /* Hardware */ My hardware wishes

This page contains a list of things people wish PineTime did differently

=== Hardware ===

* Long pressing the button should power-cycle the watch without any software being involved
* Used sensors should be NDA-free and preferably also blob-free
* Other display tech could be explored. [//en.Wikipedia.org/wiki/Transflective_liquid-crystal_display A transflective LCD] would probably be a nice option. Or potentially OLED?
* Touchscreen should possibly have a configurable sensitivity level for both glove-wearing and droplet-resistance. Preferably it should still be a capacitive one, a resistive touchscreen would have too many trade-offs.
* A slightly bigger 256×256 pixel graphics display size is preferable for its binary alignment, affording some low-level simplicity – it has the property that its X and Y coördinates are each addressable with a single byte, with no out-of-bounds; its total number of pixels is 65536 (another power of 2), and each pixel is addressable with exactly 2 bytes, with perfect efficiency. The [http://Pelulamu.net/ibniz IBNIZ (Ideally Bare Numeric Impression giZmo) virtual machine], designed for fun minimalist demoscene graphics, has chosen 256×256 for its virtual display, and makes use of these simplicity advantages. If PineTime also chose 256×256 then it would be a target platform for unclipped IBNIZ demoscene programmes, which would be really fun to play around with on one's wrist!
* A full redraw on the display takes 120ms at the very least, which is 8Hz. A smooth scrolling/usage/animation experience would be 30Hz minimum, preferably 60. I heard a rumor that the SPI connection to the display is a bottleneck. Can this be fixed?
* Some sort of scroll wheel would be nice for convenience.
* Changed GPIO assignment so more functionality is available (i.e. NFC and VSYNC)
* Wireless charging, or Qi Charging capability
* An external RTC circuit saving the current time to allow the main MCU go to deep-sleep.
* nrf52840 update, that'll allow SPI x4 speed faster than nrf52832 and moreeeee RAM.
* A couple of pins on the programmer connector to allow UART while developing (currently there is a TX test point on PCB).
* Connect the pin of LCD controller that allows RD/WR from it in order to save RAM on the MCU.
* LCD must be centered on case. Currently is not and watchfaces seems different when clock is put on the other wrist.
* A NFC antenna around the case, connected to the NFC pins.
* BMA421 accelerometer doesn't have a datasheet (it seems private to some hardware integrators): take it off and put alternative with open documentation.

[[Category:PineTime]]

PineTime bootloader improvements

2020-11-30T04:17:30Z

Caligari: Link to the proposal of external flash partitioning

== Request for comments ==
In this page, I explain the changes and improvements I would like to implement to the MCUBoot bootloader to make it more reliable, and to allow bootloader upgrade and switch (mcuboot <-> wasp-bootloader, for example).
I try to explain why I made these choices too.

Do not hesitate to edit this page and add a new section if you want to add any comment to these points (if you agree, disagree, want to try something else,...).

== Introduction ==
This pages describes the improvements I propose to make to the bootloader and OTA to make the whole process more reliable.

My goals are:

* KISS : Keep It Stupid Simple. Simple code contains less bugs than complicated/complex code.
* As reliable as possible. 100% reliability is not feasible with the current hardware (no physical reset button, no bootloader in ROM code,...), but let's try to reach 99.9% reliability :)
* Provide a read-only factory image we'll be able to restore in case of unrecoverable errors during OTA
* Provide a way to upgrade the bootloader
* Provide a way to switch from MCUBoot to NRF bootloaders

== Current memory map ==

[[PineTime| Pinetime Devkit0]] is using a nRF52832-QFAA MCU with 512kB flash and a [https://datasheet.lcsc.com/szlcsc/2005251035_XTX-XT25F32BSOIGU-S_C558851.pdf XT25F32B SPI NOR external flash] with 4096kB.

[[File:MemoryMap.png]]

Internal flash (512Kb):
* Page size is 4Kb.
* Bootloader contains the MCUBoot bootloader.
* Boot log is currently not used. Can be use to provide reboot logs to the application
* App is the PRIMARY SLOT for MCUBoot : the firmware that is currently running.
* Scratch is used by MCUBoot as temporary storage for swap operation

External flash (4096Kb):
* Page size is 256 bytes.
* Bootloader assets : boot logo
* OTA : SECONDARY SLOT for MCUBoot. During OTA, this is where the new version of the firmware is stored.
* FS : space available for the application firmware.

This memory map allows a strong boundary between the bootloader and the application :
* The bootloader is ran by the MCU at reset time and loads its boot logo from the SPI flash
* The bootloader (MCUBoot) swaps images from primary and secondary slots if necessary
* The bootloader starts the watchdog
* The bootloader jumps to 0x8000 to run the application

The application don't know anything about the bootloader except that:
* it must be linked @0x8000
* it must refresh the watchdog periodically
* it must store the image for OTA at a specific location in the external SPI flash memory

In this configuration, the boot logo is part of the bootloader, not of the application : the same logo will be displayed whatever application firmware will be loaded.

== Changes ==

=== Factory image ===
The factory image is a 'light' build of InfiniTime that contains the bare minimum code to provide OTA to the user : basic UI, BLE and OTA. No apps, no fancy functionalities,...
This factory image will be stored in the "bootloader assets" area of the external flash memory.

This factory image will be restored either automatically, when the bootloader detect it cannot boot from primary slot (App in internal memory) and secondary slot (OTA from exeternal).
The user can also request to restore this factory image if necessary (using the button?).

=== Bootloader assets ===
Graphics can be compressed using a simple RLE encoding. RLE encoding on 1 bits (2 colors images) is very efficient (115200KB -> 1-5KB).

In order to simplify the code, the graphics will be stored into the bootloader code instead of storing them into the external flash:
- Less code.
- Easier to document : 1 specific logo = bootloader mode
- Do not have to worry about the dynamic size of the logo (the binary size of the graphics will vary with the content when they are RLE encoded).

=== Bootloader ===
* Display the bootloader version on the screen and expose the version to the application firmware
* Provide a way to revert the firmware to the last working version AND to the factory firmware
* Display status and progression (progress bar similar to wasp-reloader, color code,...)
* Test as much as possible

=== Bootloader workflow ===
[[File:PineTimeBootloaderWorkflow.png]]

=== Upgrade & Reloader ===
The reloader is a tool that allows to upgrade the current version of the bootloader AND to switch from MCUBoot to NRF and vice versa.

==== How does it work ? ====
* Upgrade
** The reloader is first OTAed like any firmware upgrade.
** When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader upgrade the current bootloader and resets the system. It does NOT flag the image as validated. It resets the MCU.
** The new version of MCUBoot notice that the last upgrade is not validated and reverts to the firmware that was running just before.
** Voilà, you're running your firmware and a new version of the bootloader

* Switch bootloader
** The reloader is first OTAed like any firmware upgrade.
** When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader overwrite the current bootloader with a new one and reset.
** The new bootloader is running.

* Switch
** From InfiniTime to wasp-os : the reloader contains the NRF Bootloader and Softdevice. This bootloader provides the OTA mecanism out of the box. Wasp-os is downloaded when the NRF bootloader is running
** From wasp-os to InfiniTime : the reloader contains the factory image (infinitime-factory). The complete version of InfiniTime will be OTAed when this factory image is running.

== Discussions ==
=== Boot Logo : embedded into the bootloader binary vs stored in the external SPI flash ===
Embedding (and compressing) the boot logo inside the bootloader binary brings many advantages:
* All the data are available in memory at runtime. No need to load them & check them, and no need to handle errors and invalid corrupted data.
* The data is available and can be sent directly to the display controller
* 1 unique logo for the bootloader : easier to document and explain to the user that this specific logo is the logo from the bootloader mode.

But it also has some disadvantages:
* 1-Bit RLE encoding (very effective compression) allows only 2 colors (background/foreground)
* The boot logo cannot be customized (unless you recompile and flash this new build of the bootloader)
* The size of the boot logo is limited (depending on the compression ratio)

My (JF) point is that the bootloader must be as reliable as possible. I would like to remove all part of the code than can fail. If we read the boot logo from the SPI flash, we will write something like this:
<nowiki>int ret;
boot_logo_info info;
ret = SpiNor_read(infoOffset, &info, sizeof(boot_logo_info));
if(ret != 0) {
// Something went wrong while reading image info
panic(); // ? reset ?
}

if(check_boot_logo_info(info) == false) {
// image info are invalid (ex : size > 240*240), we cannot use them
panic(); // ? reset ? Display nothing?
}
...
</nowiki>
We could find invalid image info if a firmware did not respect the memory map and erased/overwrote the external memory map. In this case, the bootloader couldn't run properly.
Of course, we can implement something smart in panic() (retry, use failover values,...), but again, this adds complexity and bug probability.

All these if's that call panic() can be avoided by using hard-coded values at build-time.

If the image is hard-coded, you won't be able to easily (not that easy, actually...) customize the boot logo. But remember that this logo is only display for a short time only when the device reset (manually or during an OTA).

=== Why not add OTA functionality to the bootloader ? ===
This is exactly how the NRF bootloader/SoftDevice works: the bootloader is a standalone firmware that provides OTA functionality thanks to the SoftDevice. The downside is that the BLE stack needed to provide OTA is quite big and uses a lot of space in flash memory (~124kB according to the documentation). This is roughly 1/4 of the available space in the internal flash memory.

Firmware based on the NRF SoftDevice share the BLE stack with the bootloader, it is mutualised between both entities.
The downside of this design is that firmwares developers are somewhat forced to use the NRF BLE stack. If they want to integrate another BLE stacak (NimBLE for example), these 120kB used by the SoftDevice would be wasted.

That's why we decided to make the MCUBoot bootloader a simple bootloader without OTA functionality. It's very lighweight (less than 20kB) and leaves the developers the right to choose the BLE stack they want.

=== Fixed vs dynamic memory map ===
A dynamic memory map, using a partition stored in a fixed place (at the beginning of the external flash, for example) would allow different firmware to customize the partition table, image sizes,... and use the memory for efficiently.

But it has the downside to add complexity and code that could fail.

See [[PineTime external flash partitioning]] proposal.

[[Category:PineTime]]

PineTime external flash partitioning

2020-11-30T04:17:05Z

Caligari: Partition table draft-#0

== The partition table ==

Partitions on a storage (disk of flash memory) have different sizes depending on the type of data they contain. Size and location for those partitions could vary along the time, specially if the operating systems ("firmware" on embedded systems) are changed or the same OS is upgraded and it has the need of reestructuring the partitions. In any case, an index has to describe the partition structure somewhere.

What is the basic info to know about a storage partitions?

* The offset address: indicates where the partion starts on the storage.
* The partition size: how long is the partition from its offset address.
* The partition type: identifies what is the usage of the data contents.

=== Where to store the partition entries ===

To put that index of partitions hardcoded with the firmware is a bad idea. How to know if those partitions are initializaded with the expected data type? What if the user decides to try another OS and it initializates the the partitions just like the developer has decided to do so? Installed OS has to check the rightness of the storage on every boot? Definitely, the index of partitions must be out of the own OS code in order to keep organized the data on the flash memory.

==== PC ====

Nowadays, personal computers use partition tables on every disk (see [https://en.wikipedia.org/wiki/GUID_Partition_Table GPT] and [https://en.wikipedia.org/wiki/Master_boot_record#PT MBR]). This partitions tables are located very close to the beginning of the disk (reserving some initial sector of bytes for old bootloaders). However, this partition tables are designed for very large disks and they have some complexity related to PC and its computer history, not really needed for flash memories.

==== SBC ====

Single board computers and embedded systems with the [https://en.wikipedia.org/wiki/Das_U-Boot U-Boot bootloader] store the partition index as parameters in the _mtdparts_ environment variable and it is passed to the OS as argument. This environment is hardcoded or stored in a defined partition as text. More recently, they use [https://en.wikipedia.org/wiki/Device_tree Device tree] but this is also stored in a partition.

==== ESP32 ====

[https://en.wikipedia.org/wiki/ESP32 ESP32] is a MCU managing partitions without hardcoded information and it is a good example to examine. It defines a [https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/partition-tables.html partition table] of 3Kb length at a fixed position with capacity to define 95 partitions. Maybe some excessive but the interesting thing is that partition table follow the pattern "offset-size-type" as basic information.

The summing-up is that every system using partion index and not hardcoded stores the partition entries in some storage space and, this partition table, can be considered a little partition too. It is located in a well-know offset address of the flash storage.

=== Paper ===

PineTime is a device under open development and it offers undreamed possibilities to develop and to flash several firmwares by users. It might be convenient that external storage (SPI flash) can be accessed by using a partition table so, different firmwares will be able to share partitions with user information, settings, bluetooth bindings, calibration parameters, etcetera...

For example, it is possible to organize the flash to save a logo shown by the bootloader. And it doesn't mean a mandatory requirement at the moment but bootloader or application can be changed and they will be able to found the logo to show or save a customized one.

What is the cost of managing a partition table? In this case, community (developers) should be discuss and publish a paper with a proposal for the partition table structures and implement in their firmware for the Pinetime. It must be simple and suitable in order to organize the flash storage in partitions without more overhead than read the partition table, look for the partitions those are interested in and use them.

== Partition table draft-#0 ==

Location of partition table: first page of external flash (256 bytes).

=== C structures ===

C code:

<pre>
#define OFFSET_T uint32_t
#define SIZE_T uint32_t

/* bits 0-7 is type, bits 8-15 is subtype, bits 16-31 are flags */
#define TYPE_T uint32_t

struct partition_entry_t {
OFFSET_T offset;
SIZE_T size;
TYPE_T type;
};

struct partition_table_t {
uint32_t magic_bytes; /* always 0x50494e45 ("PINE") */
uint32_t reserved[2]; /* reserved, do not use */
partition_entry_t entries[20]; /* 20*sizeof(partition_entry_t) == 240 */
uint32_t checksum; /* CRC-32 MPEG2 variant (used by MCU bootloader) */
};

#define PARTITION_TYPE_NOT_USED 0x00
#define PARTITION_TYPE_BOOT_LOGO 0x01
#define PARTITION_TYPE_FACTORY_IMG 0x02
#define PARTITION_TYPE_LITTLE_FS 0x03

</pre>

[[Category:PineTime]]

PineTime bootloader improvements

2020-11-28T13:43:38Z

Caligari: /* Current memory map */

== Request for comments ==
In this page, I explain the changes and improvements I would like to implement to the MCUBoot bootloader to make it more reliable, and to allow bootloader upgrade and switch (mcuboot <-> wasp-bootloader, for example).
I try to explain why I made these choices too.

Do not hesitate to edit this page and add a new section if you want to add any comment to these points (if you agree, disagree, want to try something else,...).

== Introduction ==
This pages describes the improvements I propose to make to the bootloader and OTA to make the whole process more reliable.

My goals are:

* KISS : Keep It Stupid Simple. Simple code contains less bugs than complicated/complex code.
* As reliable as possible. 100% reliability is not feasible with the current hardware (no physical reset button, no bootloader in ROM code,...), but let's try to reach 99.9% reliability :)
* Provide a read-only factory image we'll be able to restore in case of unrecoverable errors during OTA
* Provide a way to upgrade the bootloader
* Provide a way to switch from MCUBoot to NRF bootloaders

== Current memory map ==

[[PineTime| Pinetime Devkit0]] is using a nRF52832-QFAA MCU with 512kB flash and a [https://datasheet.lcsc.com/szlcsc/2005251035_XTX-XT25F32BSOIGU-S_C558851.pdf XT25F32B SPI NOR external flash] with 4096kB.

[[File:MemoryMap.png]]

Internal flash (512Kb):
* Page size is 4Kb.
* Bootloader contains the MCUBoot bootloader.
* Boot log is currently not used. Can be use to provide reboot logs to the application
* App is the PRIMARY SLOT for MCUBoot : the firmware that is currently running.
* Scratch is used by MCUBoot as temporary storage for swap operation

External flash (4096Kb):
* Page size is 256 bytes.
* Bootloader assets : boot logo
* OTA : SECONDARY SLOT for MCUBoot. During OTA, this is where the new version of the firmware is stored.
* FS : space available for the application firmware.

This memory map allows a strong boundary between the bootloader and the application :
* The bootloader is ran by the MCU at reset time and loads its boot logo from the SPI flash
* The bootloader (MCUBoot) swaps images from primary and secondary slots if necessary
* The bootloader starts the watchdog
* The bootloader jumps to 0x8000 to run the application

The application don't know anything about the bootloader except that:
* it must be linked @0x8000
* it must refresh the watchdog periodically
* it must store the image for OTA at a specific location in the external SPI flash memory

In this configuration, the boot logo is part of the bootloader, not of the application : the same logo will be displayed whatever application firmware will be loaded.

== Changes ==

=== Factory image ===
The factory image is a 'light' build of InfiniTime that contains the bare minimum code to provide OTA to the user : basic UI, BLE and OTA. No apps, no fancy functionalities,...
This factory image will be stored in the "bootloader assets" area of the external flash memory.

This factory image will be restored either automatically, when the bootloader detect it cannot boot from primary slot (App in internal memory) and secondary slot (OTA from exeternal).
The user can also request to restore this factory image if necessary (using the button?).

=== Bootloader assets ===
Graphics can be compressed using a simple RLE encoding. RLE encoding on 1 bits (2 colors images) is very efficient (115200KB -> 1-5KB).

In order to simplify the code, the graphics will be stored into the bootloader code instead of storing them into the external flash:
- Less code.
- Easier to document : 1 specific logo = bootloader mode
- Do not have to worry about the dynamic size of the logo (the binary size of the graphics will vary with the content when they are RLE encoded).

=== Bootloader ===
* Display the bootloader version on the screen and expose the version to the application firmware
* Provide a way to revert the firmware to the last working version AND to the factory firmware
* Display status and progression (progress bar similar to wasp-reloader, color code,...)
* Test as much as possible

=== Upgrade & Reloader ===
The reloader is a tool that allows to upgrade the current version of the bootloader AND to switch from MCUBoot to NRF and vice versa.

==== How does it work ? ====
* Upgrade
** The reloader is first OTAed like any firmware upgrade.
** When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader upgrade the current bootloader and resets the system. It does NOT flag the image as validated. It resets the MCU.
** The new version of MCUBoot notice that the last upgrade is not validated and reverts to the firmware that was running just before.
** Voilà, you're running your firmware and a new version of the bootloader

* Switch bootloader
** The reloader is first OTAed like any firmware upgrade.
** When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader overwrite the current bootloader with a new one and reset.
** The new bootloader is running.

* Switch
** From InfiniTime to wasp-os : the reloader contains the NRF Bootloader and Softdevice. This bootloader provides the OTA mecanism out of the box. Wasp-os is downloaded when the NRF bootloader is running
** From wasp-os to InfiniTime : the reloader contains the factory image (infinitime-factory). The complete version of InfiniTime will be OTAed when this factory image is running.

== Discussions ==
=== Boot Logo : embedded into the bootloader binary vs stored in the external SPI flash ===
Embedding (and compressing) the boot logo inside the bootloader binary brings many advantages:
* All the data are available in memory at runtime. No need to load them & check them, and no need to handle errors and invalid corrupted data.
* The data is available and can be sent directly to the display controller
* 1 unique logo for the bootloader : easier to document and explain to the user that this specific logo is the logo from the bootloader mode.

But it also has some disadvantages:
* 1-Bit RLE encoding (very effective compression) allows only 2 colors (background/foreground)
* The boot logo cannot be customized (unless you recompile and flash this new build of the bootloader)
* The size of the boot logo is limited (depending on the compression ratio)

My (JF) point is that the bootloader must be as reliable as possible. I would like to remove all part of the code than can fail. If we read the boot logo from the SPI flash, we will write something like this:
<nowiki>int ret;
boot_logo_info info;
ret = SpiNor_read(infoOffset, &info, sizeof(boot_logo_info));
if(ret != 0) {
// Something went wrong while reading image info
panic(); // ? reset ?
}

if(check_boot_logo_info(info) == false) {
// image info are invalid (ex : size > 240*240), we cannot use them
panic(); // ? reset ? Display nothing?
}
...
</nowiki>
We could find invalid image info if a firmware did not respect the memory map and erased/overwrote the external memory map. In this case, the bootloader couldn't run properly.
Of course, we can implement something smart in panic() (retry, use failover values,...), but again, this adds complexity and bug probability.

All these if's that call panic() can be avoided by using hard-coded values at build-time.

If the image is hard-coded, you won't be able to easily (not that easy, actually...) customize the boot logo. But remember that this logo is only display for a short time only when the device reset (manually or during an OTA).

=== Fixed vs dynamic memory map ===
A dynamic memory map, using a partition stored in a fixed place (at the beginning of the external flash, for example) would allow different firmware to customize the partition table, image sizes,... and use the memory for efficiently.

But it has the downside to add complexity and code that could fail.

[[Category:PineTime]]

File:MemoryMap.png

2020-11-28T13:07:56Z

Caligari: Caligari uploaded a new version of File:MemoryMap.png

== Summary ==
Current memory map of Pinetime using MCUBoot bootloader

PineTime bootloader improvements

2020-11-28T12:47:25Z

Caligari: /* Current memory map */

== Request for comments ==
In this page, I explain the changes and improvements I would like to implement to the MCUBoot bootloader to make it more reliable, and to allow bootloader upgrade and switch (mcuboot <-> wasp-bootloader, for example).
I try to explain why I made these choices too.

Do not hesitate to edit this page and add a new section if you want to add any comment to these points (if you agree, disagree, want to try something else,...).

== Introduction ==
This pages describes the improvements I propose to make to the bootloader and OTA to make the whole process more reliable.

My goals are:

* KISS : Keep It Stupid Simple. Simple code contains less bugs than complicated/complex code.
* As reliable as possible. 100% reliability is not feasible with the current hardware (no physical reset button, no bootloader in ROM code,...), but let's try to reach 99.9% reliability :)
* Provide a read-only factory image we'll be able to restore in case of unrecoverable errors during OTA
* Provide a way to upgrade the bootloader
* Provide a way to switch from MCUBoot to NRF bootloaders

== Current memory map ==

[[PineTime| Pinetime Devkit0]] is using a nRF52832-QFAA MCU with 512kB flash and a [https://datasheet.lcsc.com/szlcsc/2005251035_XTX-XT25F32BSOIGU-S_C558851.pdf XT25F32B SPI NOR external flash] with 4096kB.

[[File:MemoryMap.png]]

Internal flash (512Kb):
* Page size is 4Kb
* Bootloader contains the MCUBoot bootloader.
* Boot log is currently not used. Can be use to provide reboot logs to the application
* App is the PRIMARY SLOT for MCUBoot : the firmware that is currently running.
* Scratch is used by MCUBoot as temporary storage for swap operation

External flash (4096Kb):
* Bootloader assets : boot logo
* OTA : SECONDARY SLOT for MCUBoot. During OTA, this is where the new version of the firmware is stored.
* FS : space available for the application firmware.

This memory map allows a strong boundary between the bootloader and the application :
* The bootloader is ran by the MCU at reset time and loads its boot logo from the SPI flash
* The bootloader (MCUBoot) swaps images from primary and secondary slots if necessary
* The bootloader starts the watchdog
* The bootloader jumps to 0x8000 to run the application

The application don't know anything about the bootloader except that:
* it must be linked @0x8000
* it must refresh the watchdog periodically
* it must store the image for OTA at a specific location in the external SPI flash memory

In this configuration, the boot logo is part of the bootloader, not of the application : the same logo will be displayed whatever application firmware will be loaded.

== Changes ==

=== Factory image ===
The factory image is a 'light' build of InfiniTime that contains the bare minimum code to provide OTA to the user : basic UI, BLE and OTA. No apps, no fancy functionalities,...
This factory image will be stored in the "bootloader assets" area of the external flash memory.

This factory image will be restored either automatically, when the bootloader detect it cannot boot from primary slot (App in internal memory) and secondary slot (OTA from exeternal).
The user can also request to restore this factory image if necessary (using the button?).

=== Bootloader assets ===
Graphics can be compressed using a simple RLE encoding. RLE encoding on 1 bits (2 colors images) is very efficient (115200KB -> 1-5KB).

In order to simplify the code, the graphics will be stored into the bootloader code instead of storing them into the external flash:
- Less code.
- Easier to document : 1 specific logo = bootloader mode
- Do not have to worry about the dynamic size of the logo (the binary size of the graphics will vary with the content when they are RLE encoded).

=== Bootloader ===
* Display the bootloader version on the screen and expose the version to the application firmware
* Provide a way to revert the firmware to the last working version AND to the factory firmware
* Display status and progression (progress bar similar to wasp-reloader, color code,...)
* Test as much as possible

=== Upgrade & Reloader ===
The reloader is a tool that allows to upgrade the current version of the bootloader AND to switch from MCUBoot to NRF and vice versa.

==== How does it work ? ====
* Upgrade
** The reloader is first OTAed like any firmware upgrade.
** When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader upgrade the current bootloader and resets the system. It does NOT flag the image as validated. It resets the MCU.
** The new version of MCUBoot notice that the last upgrade is not validated and reverts to the firmware that was running just before.
** Voilà, you're running your firmware and a new version of the bootloader

* Switch bootloader
** The reloader is first OTAed like any firmware upgrade.
** When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader overwrite the current bootloader with a new one and reset.
** The new bootloader is running.

* Switch
** From InfiniTime to wasp-os : the reloader contains the NRF Bootloader and Softdevice. This bootloader provides the OTA mecanism out of the box. Wasp-os is downloaded when the NRF bootloader is running
** From wasp-os to InfiniTime : the reloader contains the factory image (infinitime-factory). The complete version of InfiniTime will be OTAed when this factory image is running.

== Discussions ==
=== Boot Logo : embedded into the bootloader binary vs stored in the external SPI flash ===
Embedding (and compressing) the boot logo inside the bootloader binary brings many advantages:
* All the data are available in memory at runtime. No need to load them & check them, and no need to handle errors and invalid corrupted data.
* The data is available and can be sent directly to the display controller
* 1 unique logo for the bootloader : easier to document and explain to the user that this specific logo is the logo from the bootloader mode.

But it also has some disadvantages:
* 1-Bit RLE encoding (very effective compression) allows only 2 colors (background/foreground)
* The boot logo cannot be customized (unless you recompile and flash this new build of the bootloader)
* The size of the boot logo is limited (depending on the compression ratio)

My (JF) point is that the bootloader must be as reliable as possible. I would like to remove all part of the code than can fail. If we read the boot logo from the SPI flash, we will write something like this:
<nowiki>int ret;
boot_logo_info info;
ret = SpiNor_read(infoOffset, &info, sizeof(boot_logo_info));
if(ret != 0) {
// Something went wrong while reading image info
panic(); // ? reset ?
}

if(check_boot_logo_info(info) == false) {
// image info are invalid (ex : size > 240*240), we cannot use them
panic(); // ? reset ? Display nothing?
}
...
</nowiki>
We could find invalid image info if a firmware did not respect the memory map and erased/overwrote the external memory map. In this case, the bootloader couldn't run properly.
Of course, we can implement something smart in panic() (retry, use failover values,...), but again, this adds complexity and bug probability.

All these if's that call panic() can be avoided by using hard-coded values at build-time.

If the image is hard-coded, you won't be able to easily (not that easy, actually...) customize the boot logo. But remember that this logo is only display for a short time only when the device reset (manually or during an OTA).

=== Fixed vs dynamic memory map ===
A dynamic memory map, using a partition stored in a fixed place (at the beginning of the external flash, for example) would allow different firmware to customize the partition table, image sizes,... and use the memory for efficiently.

But it has the downside to add complexity and code that could fail.

[[Category:PineTime]]

PineTime

2020-10-19T20:57:11Z

Caligari: /* Display */

== Frequently asked questions ==

'''Read these first!'''

* [[Frequently asked questions about the PineTime| Frequently Asked Questions about the devkit]]
* [[Reprogramming the PineTime|Reprogramming the PineTime (development kit)]]

== Default OS ==

The current default operating system on the PineTime is called [[InfiniTime]]. First devkits shipped with a proprietary custom firmware. The project was started by JF002 and is shipped with the latest edition of PineTime. You can use various companion apps with the OS, for example Gadgetbridge.

== Short overview ==
'''Dimensions:''' 37.5 x 40 x 11mm 
'''Weight:''' 38 grams 
'''IP Rating:''' IP67 (waterproof to 1 meter (sealed edition!)) 
'''Display:'''
: '''Size:''' 1.3 inches (33mm) diagonal
: '''Type:''' IPS capacitive touchscreen, RGB 65K colors
: '''Display Controller:''' ST7789
: '''Resolution:''' 240x240 pixels 
'''System on Chip:''' Nordic Semiconductor nRF52832 
'''Flash:''' 512KB with additional 4MB SPI NOR 
'''RAM:''' 64KB 
'''Bluetooth:''' [[PineTime_Bluetooth|5.0 (including Bluetooth Low Energy)]] 
'''Sensors:''' Accelerometer, Heart rate sensor 
'''Feedback:''' Vibration motor 
'''Battery:''' 170-180mAh LiPo

= Community =
* [https://forum.pine64.org/forumdisplay.php?fid=134 PineTime forum]
* [https://app.element.io/#/room/#pinetime:matrix.org Matrix Channel] (No login required to read)
* IRC Server: [ircs://irc.pine64.org#pinetime irc.pine64.org] Channel: PineTime
* [https://t.me/pinetime Telegram group]
* [https://discordapp.com/invite/DgB7kzr Discord server invite link]

== Development efforts ==

To read more about development on the PineTime, the projects available and more technical details, check out [[PineTime Development]]

== Useful articles and blog posts ==

If you want to dive in to the ecosystem, here's a short list of various articles and blog posts that can help you set up your soft- or hardware development environment.

* [https://medium.com/swlh/sneak-peek-of-pinetime-smart-watch-and-why-its-perfect-for-teaching-iot-81b74161c159 Sneak Peek of PineTime Smart Watch… And why it’s perfect for teaching IoT]

* [https://medium.com/@ly.lee/building-a-rust-driver-for-pinetimes-touch-controller-cbc1a5d5d3e9 Building a Rust Driver for PineTime’s Touch Controller]

* [https://medium.com/@ly.lee/porting-druid-rust-widgets-to-pinetime-smart-watch-7e1d5a5d977a Porting (druid) Rust Widgets to PineTime Smart Watch]

* [https://medium.com/@ly.lee/optimising-pinetimes-display-driver-with-rust-and-mynewt-3ba269ea2f5c Optimising PineTime’s Display Driver with Rust and Mynewt]

* [https://www.zephyrproject.org/getting-started-with-zephyr-rtos-on-nordic-nrf52832-hackable/ Getting Started with Zephyr RTOS on Nordic nRF52832 hackaBLE]

* [https://blog.aegrel.ee/absniffer-cmsis-dap-sniffer.html Removing the lock and installing another firmware on the nRF52832 using CMSIS-DAP dongle on Linux]

* [https://github.com/JF002/nrf52-baseproject/wiki/Build,-program-and-debug-NRF52-project-with-JLink,-CMake-and-CLion Build, program and debug NRF52 project with JLink, CMake and CLion]

* [https://www.nrbtech.io/blog/2020/1/4/using-clion-for-nordic-nrf52-projects Using CLion for Nordic nRF52 projects]

* [https://dev.to/aaronc81/flashing-your-pinetime-using-an-st-link-and-openocd-54dd Flashing your PineTime using an ST-Link and OpenOCD]

== Hardware ==

=== Display ===

Note: The factory-default software on the PineTime does not auto-detect the display being disconnected when it has already booted. That can cause garbled output, to fix it just restart the PineTime.

The display is driven using the ST7789 display controller. Use the following pins to drive the screen:

{| class="wikitable"
|-
! PineTime pin
! ST7789 pin
|-
| LCD_SCK (P0.02)
| SPI clock
|-
| LCD_SDI (P0.03)
| SPI MOSI
|-
| LCD_RS (P0.18)
| Command/Data pin (CD)
|-
| LCD_CS (P0.25)
| Chip select
|-
| LCD_RESET (P0.26)
| Display reset
|-
| LCD_BACKLIGHT_{LOW,MID,HIGH}
| Backlight (active low)
|}

Notes:

* Chip select must be held low while driving the display. It must be high when using other SPI devices on the same bus (such as external flash storage) so that the display controller won't respond to the wrong commands.
* SPI must be used in mode 3. Mode 0 (the default) won't work.
* LCD_DISPLAY_* is used to enable the backlight. Set at least one to low to see anything on the screen.
* Use SPI at 8MHz (the fastest clock available on the nRF52832) because otherwise refreshing will be super slow.

'''References''':

[https://github.com/adafruit/Adafruit-ST7735-Library/ Adafruit ST7789 driver in cpp]

=== Battery measurement ===

Reading whether the PineTime has power attached is easy: simply read the charge indication pin (P0.12). When it is high it is running on battery, when it is low it is charging.

Reading the battery voltage is a bit harder. For that you can use the battery voltage pin on P0.31 (AIN7). The returned value is 12 bits, which means it is 0..4095. You can get the measured voltage with the following formula, assuming a reference voltage of 3.3V (this is configurable in the ADC):

adcVoltage = adcValue / (4095 / 3.3)

The measured voltage is actually half of the actual battery voltage, because the ADC is connected between a voltage divider where both resistors are 1MΩ. This can be corrected by multiplying the value:

batteryVoltage = adcValue * 2 / (4095 / 3.3)

It's often better to avoid floating point values on embedded systems and in this case there is no reason to use float at all, we can just represent the value in millivolts. Therefore the formula can be simplified to:

batteryVoltage = adcValue * 2000 / (4095 / 3.3)
batteryVoltage = adcValue * 2000 / 1241

Converting this voltage to an estimated capacity in percent requires a more complicated algorithm, because Lithium-ion batteries have a non-linear discharge curve.

=== Button ===

The button on the side of the PineTime is disabled by default. To enable it, drive the button out pin (P0.15) high.

While enabled, the button in pin (P0.13) will be high when the button is pressed, and low when it is not pressed.

=== Touch panel ===

The touch panel is controlled by a Hynitron CST816S chips. Unfortunately, there is not much information about this chip on the internet apart from the datasheet below and a [https://github.com/lupyuen/hynitron_i2c_cst0xxse/ reference driver]. This is enough to implement a basic driver, but crucial information needed to implement advanced functionalities are missing (I²C protocol and registers, timings, power modes,...).

==== Pins ====

* P0.10 : Reset
* P0.28 : Interrupt (signal to the CPU when a touch event is detected)
* P0.06 : I²C SDA
* P0.07 : I²C SCL

==== I²C ====

* Device address : 0x15
* Frequency : from 10Khz to 400Khz

'''NOTE : ''' The controller go to sleep when no event is detected. In sleep mode, the controller does not communicate on the I²C bus (it appears disconnected). So, for the communication to work, you need to tap on the screen so that the chip wakes-up.

==== Touch events ====

Touch information is available from the 63 first registers of the controller. Remember: the device is in sleep mode when no touch event is detected. It means that you can read the register only when the touch controller detected an event. You can use the ''Interrupt'' pin to detect such event in the software.

These 63 bytes contain up to 10 touch point (X, Y, event type, pressure,...) :

{| class="wikitable"
! Byte
! Bit7
! Bit6
! Bit5
! Bit4
! Bit3
! Bit2
! Bit1
! Bit0
|-
|0
|colspan="8"|?
|-
|1
|colspan="8"|GestureID : (Gesture code ,

0x00: no gesture,

0x01: Slide down,

0x02: Slide up,

0x03: Slide left,

0x04: Slide right,

0x05: Single click,

0x0B: Double click,

0x0C: Long press)
|-
|2
|colspan="4"|?
|colspan="4"|Number of touch points
|-
|3
|colspan="2"|Event (0 = Down, 1 = Up, 2 = Contact)
|colspan="2"|?
|colspan="4"|X (MSB) coordinate
|-
|4
|colspan="8"|X (LSB) coordinate
|-
|5
|colspan="2"|?
|colspan="2"|Touch ID
|colspan="4"|Y (MSB) coordinate
|-
|6
|colspan="8"|Y (LSB) coordinate
|-
|7
|colspan="8"|Pressure (?)
|-
|8
|colspan="8"|Miscellaneous (?)
|}

Bytes 3 to 8 are repeated 10 times (10*6 + 3 = 63 bytes).

'''NOTES'''

* The touch controller seems to report only 1 touch point
* Fields X, Y, Number of touch points and touch ID are updated. The others are always 0.

==== Registers ====

The reference driver specifies some registers and value, but there is no information about them:

{| class="wikitable"

!Register
!Address
!Description
|-
|HYN_REG_INT_CNT
|0x8F
|
|-
|HYN_REG_FLOW_WORK_CNT
|0x91
|
|-
|HYN_REG_WORKMODE
|0x00
|0 = WORK, 0x40 = FACTORY
|-
|HYN_REG_CHIP_ID
|0xA3
|
|-
|HYN_REG_CHIP_ID2
|0x9F
|-
|HYN_REG_POWER_MODE
|0xA5
|0x03 = SLEEP (reset the touchpanel using the reset pin before using this register : pin_low, delay 5ms, pin_high, delay 50ms then write 3 to register 0xA5)
|-
|HYN_REG_FW_VER
|0xA6
|
|-
|HYN_REG_VENDOR_ID
|0xA8
|
|-
|HYN_REG_LCD_BUSY_NUM
|0xAB
|
|-
|HYN_REG_FACE_DEC_MODE_EN
|0xB0
|
|-
|HYN_REG_GLOVE_MODE_EN
|0xC0
|
|-
|HYN_REG_COVER_MODE_EN
|0xC1
|
|-
|HYN_REG_CHARGER_MODE_EN
|0x8B
|
|-
|HYN_REG_GESTURE_EN
|0xD0
|
|-
|HYN_REG_GESTURE_OUTPUT_ADDRESS
|0xD3
|
|-
|HYN_REG_ESD_SATURATE 0xED
|0xED
|
|}

'''WARNING : ''' <del>Writing the SLEEP command (write 0x05 in HYN_REG_POWER_MODE) seems to freeze the controller (it returns only static values) until the battery is totally drained and the whole system reset. Analysis and debugging is more than welcome!</del>

== Datasheets and Schematics ==

=== Schematics ===
* [http://files.pine64.org/doc/PineTime/PineTime%20Schematic-V1.0a-20191103.pdf PineTime Schematic ver1.0a]
* [http://files.pine64.org/doc/PineTime/PineTime%20Port%20Assignment%20rev1.0.pdf PineTime GPIO Port Assignment ver1.0]

Note: The part number for the SPI FLASH in the schematic diagram is not correct, the PineTime features a larger external FLASH device, see below.

=== Chip Datasheets ===
* NORDIC nRF52832 information:
** [http://files.pine64.org/doc/datasheet/pinetime/nRF52832%20product%20brief.pdf nRF52832 Product Brief]
** [https://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.1.pdf nRF52832 Product Specification v1.1]
* ARMv7-M information:
** [https://static.docs.arm.com/ddi0403/eb/DDI0403E_B_armv7m_arm.pdf ARMv7-M Architecture Reference Manual]

=== Component Datasheets ===
* PMU (Power Management Unit) information:
** [http://files.pine64.org/doc/datasheet/pinetime/SGM40561.pdf SGMicro SGM40561 Single Cell Charger Datasheet]
** [http://files.pine64.org/doc/datasheet/pinetime/SGMICRO-SGM2036.pdf SGMicro SGM2036 3.3V Low Power Low Dropout RF Linear Regulator Datasheet]
* SPI Flash information:
** [https://www.elnec.com/en/device/XTX/XT25F32B+%28QuadSPI%29+%5BSOP8-200%5D/ XTX XT25F32B 32Mb(4MB) SPI NOR Flash] (data sheets for this part are hard to find but it acts similar to other QuadSPI SPI NOR Flash such as [https://www.macronix.com/Lists/Datasheet/Attachments/7426/MX25L3233F,%203V,%2032Mb,%20v1.6.pdf Macronix 32Mb(4MB) SPI NOR Flash])
** IDs for XT25F32B are: manufacturer (0x0b), device (0x15), memory type (0x40), density (0x16)
* LCD Panel:
** [http://files.pine64.org/doc/datasheet/pinetime/PineTime%20LCD%20Panel.jpg 1.3" 240x240 IPS LCD Panel Specification for PineTime]
** [https://wiki.pine64.org/images/5/54/ST7789V_v1.6.pdf 11.6" Sitronix LCD Driver/Controller Datasheet]
* Touchpad information:
** [http://files.pine64.org/doc/datasheet/pinetime/PineTime%20Touch%20Panel.jpg Touchpad Specification for PineTimel]
** [http://files.pine64.org/doc/datasheet/pinetime/CST816S数据手册V1.1.pdf 11.6" Hynitron CST816S Capacitive Touch Controller Datasheet in Chinese]
*** [https://wiki.pine64.org/images/5/51/CST816S%E6%95%B0%E6%8D%AE%E6%89%8B%E5%86%8CV1.1.en.pdf English Translation]
* Sensor:
** [http://files.pine64.org/doc/datasheet/pinetime/BST-BMA421-FL000.pdf BOSCH BMA421 Triaxial VAcceleration Sensor Product Brief]
** [https://wiki.pine64.org/images/c/cc/Bst-bma400-ds000.pdf BOSCH BMA400 3-axes ultra-low power accelerometer datasheet]
** [http://files.pine64.org/doc/datasheet/pinetime/HRS3300%20Heart%20Rate%20Sensor.pdf TianYiHeXin HRS3300 PPG Heart Rate Sensor Data Sheet]

[[Category:PineTime]]

PineTime Development

2020-10-10T17:37:34Z

Caligari: /* Available firmware and projects */ sethitow/mbed-pinetime repository URL

== Reprogramming ==

[[PineTime devkit wiring|Wire it up]] and then [[Reprogramming the PineTime| flash something]].

== Available firmware and projects ==
{| class="wikitable"
!
! Project Homepage
! Project Source
! PineTime Implementations

|-
! FreeRTOS
|https://www.freertos.org
| https://sourceforge.net/projects/freertos/
|
{|
|[[InfiniTime]] ([https://github.com/JF002/Pinetime JF002/Pinetime])
|-
|[https://github.com/kaythe/pinetime-os kaythe/pinetime-os]
|}

|-
! Zephyr
| https://www.zephyrproject.org
| https://github.com/zephyrproject-rtos/zephyr
|
{|
|[https://github.com/najnesnaj/pinetime-zephyr najnesnaj/pinetime-zephyr]
|-
|[https://github.com/SuperPrower/pinetime_zephyr_sample_fw SuperPrower/pinetime_zephyr_sample_fw]
|-
|[https://github.com/Dejvino/pinetime-hermes-firmware Dejvino/pinetime-hermes-firmware]
|-
|[https://github.com/endian-albin/pinetime-hypnos endian-albin/pinetime-hypnos]
|}

|-
! mynewt
| https://mynewt.apache.org/about/
| https://github.com/apache/mynewt-core
|
{|
|[https://github.com/lupyuen/pinetime-rust-mynewt lupyuen/pinetime-rust-mynewt]
|-
|[https://gitlab.com/caspermeijn/klok caspermeijn/klok]
|}

|-
! MbedOS
| https://os.mbed.com
| https://github.com/ARMmbed/mbed-os
|
{|
|[https://github.com/sethitow/mbed-pinetime sethitow/mbed-pinetime]
|-
|[https://github.com/geoffrey-vl/mbed-pinetime geoffrey.vl/mbed-pinetime]
|}

|-
! RIOT
| http://riot-os.org/
| https://github.com/RIOT-OS/RIOT/
| [https://github.com/bosmoment/PineTime-apps bosmoment/PineTime-apps]

|-
! TinyGo
| https://tinygo.org
| https://github.com/tinygo-org/tinygo
| [https://github.com/aykevl/go-smartwatch aykevl/go-smartwatch]

|-
! wasp-os (MicroPython)
| https://wasp-os.readthedocs.io/
| https://github.com/daniel-thompson/wasp-os
| [https://wasp-os.readthedocs.io/en/latest/install.html#pine64-pinetime-developer-edition PineTime install guide]

|-
! Rust + RTFM
| https://rtfm.rs/
| [https://github.com/rtfm-rs/cortex-m-rtfm rtfm-rs/cortex-m-rtfm]
| https://github.com/dbrgn/pinetime-rtfm/

|-
! Bare Metal
|
|
{|
|https://github.com/xriss/timecake
|-
|https://github.com/Arc13/Pyrus
|}
|
{|
|[https://github.com/xriss/timecake xriss/timecake]
|-
|[https://github.com/Arc13/Pyrus Arc13/Pyrus]
|}
|-
! AdaFruit bootloader
|
| https://github.com/adafruit/Adafruit_nRF52_Bootloader
| [https://github.com/daniel-thompson/wasp-bootloader daniel-thompson/wasp-bootloader]
|-
! Useful drivers
|
| https://github.com/sethitow/mbed-pinetime
| [https://github.com/sethitow/mbed-pinetime/tree/master/drivers https://github.com/sethitow/mbed-pinetime]

|-
! UI concepts and drawings
|
|
| [https://gitlab.com/arteeh/pinetime-os arteeh/pinetime-os]
|-
! Linux companion app
|
|
| [https://gitlab.com/arteeh/pinetime-companion arteeh/pinetime-companion]
|-
! Android companion app
| https://gadgetbridge.org/
| https://codeberg.org/Freeyourgadget/Gadgetbridge
| [https://github.com/JF002/Pinetime InfiniTime] [https://codeberg.org/Freeyourgadget/Gadgetbridge/commit/9b8f4d329e49cafdfe0497ed38a715faa9f844c6 initial support added]
|-
! Arduino
| https://youtu.be/4aFDjymXjOw
| https://github.com/atc1441/ATCwatch
| https://github.com/atc1441/ATCwatch
|-
! OTA Update Flasher / DaFlasher
| https://youtu.be/gUVEz-pxhgg
| https://github.com/atc1441/DaFlasherFiles
| https://github.com/atc1441/DaFlasherFiles
|-
|}

=== Manuals ===

* [https://github.com/JF002/Pinetime InfiniTime installation]
* [https://github.com/najnesnaj/pinetime-zephyr Zephyr installation] Beginner manual which explains how to install Zephyr (by najnesnaj).
* [https://wasp-os.readthedocs.io/en/latest/ Wasp-OS installation] Full manual with install instructions and an application writer's guide.

== How to write battery friendly software? ==

The key to save battery is to enable only what you need when you need it. nRF52832 has a lot of functionalities allowing you to draw as little current as possible. Here are some tips and tricks:

* Disable / shutdown / put in sleep mode '''all devices around the MCU''' (display controller, touch controller, external memory,...).
* Disable all '''peripheral inside the MCU''' when you don't need them (SPI, TWI(I²C),...). The power management of the NRF52832 is very smart and will completely shut down (power off and disable the clock) the peripheral when the software disables it.
* Put the MCU to sleep as soon and as often as possible. If you are not using a RTOS, this is done by calling ''WFE'' (wait for event) instruction. Most of the time, RTOS implement this functionality. For example, FreeRTOS calls it the ''tickless mode'' : it puts the CPU in sleep mode when no task is planned for execution for more than a specified time, and wakes up as soon as an event is detected or when a task is ready to run.
* Do not use logging (JLink RTT, SWO, semihosting,...), it uses a lot of power.
* Ensure that the debug circuitry of the MCU is not enabled when you measuring the battery life. The debug peripheral is enabled as soon as you connect a debugger to the device, and '''is not automatically disabled''', even if you disconnect the debugger you will have to wait for the battery to go flat to disable to port. The software running in the NRF52832 cannot disable the debug peripheral. How to disable the debug circuitry:
- using ''nrfjprog --reset''
- using JLinkExe : issue the command ''writeDP 1 0''

or with OpenOCD
- issue the command ''halt''
- issue the command ''flash fillw 0x10001208 0xFFFFFF00 0x01''
- issue the command ''reset''

you can check if the debug port is enabled using the following code
DWT->CYCCNT ? "NO":"YES"
* Read [https://infocenter.nordicsemi.com/pdf/nRF52832_Rev_2_Errata_v1.1.pdf the errata sheet of the MCU] and apply workarounds if they apply to your software.

== Wishlist ==

In order to keep track of features and changes to the hardware people would like to see, check out this article: [[PineTime hardware wishlist]]

== Compatibility with other projects ==

Different firmware running using different bootloaders and Bluetooth stacks on the nRF52832 have different requirements on how they should be initialised and what should be placed where in the internal flash.

To keep track of what, how and why things work like they do across the different projects, check out the [[PineTime SD MCUBoot|PineTime SoftDevice and MCUBoot compatibility]] article.

== Compatibility with companions apps and Bluetooth communication ==

There are a lot of different firmware running on the Pinetime that implement different BLE APIs (time synchronization, notifications, ...). Companion apps must be able to differentiate between different firmware and forks of the same firmware. See [[PineTime Bluetooth]].

== PineTime equivalents and jailbreaking ==

This page contains a list of PineTime-like smartwatches that might be "jailbreakable" or a good source for ideas for the PineTime: [[PineTime Equivalents]]

PineTime RTOS Comparison

2019-12-22T13:33:03Z

Caligari: More implementations

{| class="wikitable"
!
! Project Homepage
! Project Source
! Sponsor
! Language
! PineTime Implementations

|-
! FreeRTOS
|https://www.freertos.org
| https://sourceforge.net/projects/freertos/
| [https://www.freertos.org/RTOS-contact-and-support.html Amazon Web Services]
| C
| [https://github.com/JF002/Pinetime JF002/Pinetime]
[https://github.com/kaythe/pinetime-os kaythe/pinetime-os]

|-
! Zephyr
| https://www.zephyrproject.org
| https://github.com/zephyrproject-rtos/zephyr
| Linux Foundation
| C/C++
| [https://github.com/najnesnaj/pinetime-zephyr najnesnaj/pinetime-zephyr]
[https://github.com/SuperPrower/pinetime_zephyr_sample_fw SuperPrower/pinetime_zephyr_sample_fw]

|-
! mynewt
| https://mynewt.apache.org/about/
| https://github.com/apache/mynewt-core
| Apache Foundation
| C
| [https://github.com/lupyuen/stm32bluepill-mynewt-sensor/tree/pinetime lupyuen/stm32bluepill-mynewt-sensor]

|-
! Tock
| https://www.tockos.org
| https://github.com/tock/tock
|
| Rust
|

|-
! MbedOS
| https://os.mbed.com
| https://github.com/ARMmbed/mbed-os
| ARM
| C/C++
| [https://github.com/sethitow/awesome-pinetime sethitow/mbed-pinetime]

|-
! TinyGo
| https://tinygo.org
| https://github.com/tinygo-org/tinygo
|
| Go
| [https://github.com/aykevl/go-smartwatch aykevl/go-smartwatch]
|-
|}

PineTime RTOS Comparison

2019-12-21T21:42:55Z

Caligari: Implementation links.

{| class="wikitable"
!
! Project Homepage
! Project Source
! Sponsor
! Language
! PineTime Implementations

|-
! FreeRTOS
|https://www.freertos.org
| https://sourceforge.net/projects/freertos/
| [https://www.freertos.org/RTOS-contact-and-support.html Amazon Web Services]
| C
| [https://github.com/JF002/Pinetime JF002/Pinetime]

|-
! Zephyr
| https://www.zephyrproject.org
| https://github.com/zephyrproject-rtos/zephyr
| Linux Foundation
| C
|

|-
! mynewt
| https://mynewt.apache.org/about/
| https://github.com/apache/mynewt-core
| Apache Foundation
| C
| [https://github.com/lupyuen/stm32bluepill-mynewt-sensor/tree/pinetime lupyuen/stm32bluepill-mynewt-sensor]

|-
! Tock
| https://www.tockos.org
| https://github.com/tock/tock
|
| Rust
|

|-
! MbedOS
| https://os.mbed.com
| https://github.com/ARMmbed/mbed-os
| ARM
| C/C++
|

|-
! TinyGo
| https://tinygo.org
| https://github.com/tinygo-org/tinygo
|
| Go
| [https://github.com/aykevl/go-smartwatch aykevl/go-smartwatch]
|-
|}