A document going over the parameters and requirements for a runtime to drive the physical core unit hardware.
This document will closely follow, without being redundant to, the Hardware Architecture Manifesto, and will take into consideration any decisions of architecture expressed therein. Additionally, it will outline how the firmware intends to connect to the internet, communicate with the backend, and relay data to the mobile app.
Determinations of programming language / framework / libraries, and handling the asynchronous environment of the hardware will be discussed and finalized here as well. We have preliminarily decided on Swift, and this decision as well as its implications will be discussed.
Additionally, the manifesto should have a battle plan for making the code platform-independent to allow for testing on Travis, on x86 platforms, and on ARM platforms. The code should use something like flags to use different strategies to either use hardware-bound code or mock code.
YichenDuan
commented
6 years ago
A document going over the parameters and requirements for a runtime to drive the physical core unit hardware.
This document will closely follow, without being redundant to, the Hardware Architecture Manifesto, and will take into consideration any decisions of architecture expressed therein. Additionally, it will outline how the firmware intends to connect to the internet, communicate with the backend, and relay data to the mobile app.
Determinations of programming language / framework / libraries, and handling the asynchronous environment of the hardware will be discussed and finalized here as well. We have preliminarily decided on Swift, and this decision as well as its implications will be discussed.
Additionally, the manifesto should have a battle plan for making the code platform-independent to allow for testing on Travis, on x86 platforms, and on ARM platforms. The code should use something like flags to use different strategies to either use hardware-bound code or mock code.