Cargo.toml

@@ -0,0 +1,22 @@
+[workspace]
+members = [
+    "master"
+]
+
+[workspace.package]
+version = "0.1.0"
+edition = "2021"
+repository = "https://git.bfpower.io/BFPOWER/physical"
+readme = "README.md"
+license = "MIT"
+
+[workspace.dependencies]
+thiserror = "1.0.*"
+uom = "0.33.*"
+
+# Logging
+log = "0.4.*"
+env_logger = "0.9.*"
+
+# Async
+tokio = "1.21.*"

README.md

@@ -11,15 +11,16 @@ As this is a broad purpose physical is intended to run on or interact with a wid
 
 ## Computer Hardware Layers
 
-* Peripherals - A peripheral is a minimal set of hardware and firmware that directly interfaces with sensors or controllers (in fact it may be a single hardwired sensor or controller).
+* Peripherals - A peripheral is a minimal set of hardware and firmware that directly interfaces with sensors or controllers (in fact it may be a single hardwired sensor or controller). Depending on the peripheral, it may be able to run standalone or connected to a master.
     * Peripherals are always where analog to digital conversion takes place in the case of inputs and digital to analog conversion takes place in the case of outputs.
     * Peripherals are things that run extremely minimal software, either with no dedicated operating system at all or a minimal RTOS such as [Embassy](https://embassy.dev/).
-    * Peripherals should do very little data processing, usually directly sending collected data to the host in the case of inputs or adjusting electronics components in response to output settings. Potentially a peripheral could have some very simple logic built in for things that need extremely fast response times such as closing a gate between two evacuated solar collectors when one loses vacuum.
-    * Physical is designed to work with peripherals running arbitrary firmware, i.e. peripherals do not need to be running any components from physical. However, it will eventually be possible for to make firmware for peripherals using firmware.
+    * Peripherals should do very little data processing, usually directly sending collected data to the master in the case of inputs or adjusting electronics components in response to output settings. Potentially a peripheral could have some very simple logic built in for things that need extremely fast response times such as closing a gate between two evacuated solar collectors when one loses vacuum.
+    * Physical on the master device is designed to work with peripherals running arbitrary firmware, i.e. peripherals do not need to be running any components from physical. However, it will eventually be possible for to make firmware for peripherals using physical.
 
-* Hosts - A host is the computer peripherals are connected to. A host may be a fairly low power single board computer like a raspberry pi 0, all the way up to a 128 core supercomputer.
-    * Hosts are intended to run full fledged multi-process operating systems such as GNU/Linux.
-    * Hosts are intended to do the heavy lifting of data processing and decision making for the system being controlled.
+* Masters - A master is the computer peripherals are connected to. A master may be a fairly low power single board 
+  computer like a raspberry pi 0, all the way up to a 128 core supercomputer.
+    * Masters are intended to run full fledged multi-process operating systems such as GNU/Linux but could potentially be run on a fairly lightweight RTOS as well. They do need to run in an environment with Rust std support.
+    * Masters are intended to do the heavy lifting of data processing and decision making for the system being controlled.
 
 ## Software Abstractions
 
@@ -28,7 +29,7 @@ As this is a broad purpose physical is intended to run on or interact with a wid
 * Transformation - Some way of transforming data coming from inputs and going to outputs. E.g. transforming an analog input to a type K thermocouple. Transformations are for I/O where many different physical sensors or devices could be plugged into an input or output and need some algorithm applied to the direct data for it to be useful. E.g. analog input reads voltage whether a thermocouple or pressure sensor is connected to it. Transformation will transform the voltage to temperature or pressure.
 * Peripheral - Software representation of what's described in "Computer Hardware Layers".
     * Peripherals host inputs and outputs.
-* Connection - Peripherals could be connected to the host in various ways (SPI, I²C, USB, etc.) different connection methods must be supported in physical.
+* Connection - Peripherals could be connected to the master in various ways (SPI, I²C, USB, etc.) different connection methods must be supported in physical.
 
 ## Device Builder
 
@@ -39,14 +40,14 @@ As this is a broad purpose physical is intended to run on or interact with a wid
 
 ## Roadmap
 
-- [ ] Minimal implementation of physical for hosts. Think about what components can be separated out and reused for peripherals.
+- [ ] Minimal implementation of physical for masters. Think about what components can be separated out and reused for peripherals.
 - [ ] Add support for more peripherals (basically aiming to add support for what's needed for early BFPOWER systems).
 - [ ] Common abstractions for system control (recording, PID control, etc.)
 - [ ] Implementation of physical running directly on peripherals.
-- [ ] Kotlin embedded DSL and general API to make simple programs to be run on a physical host (optional). 
-- [ ] GUI to be run on a physical host to do simple data collection, control, and analysis.
+- [ ] Kotlin embedded DSL and general API to make simple programs to be run on a physical master (optional). 
+- [ ] GUI to be run on a physical master to do simple data collection, control, and analysis.
 
 ## Questions
 
-* Nested hosts - Should there be abstractions built in to physical for setting one host to be the master of another.
-    * Leaning towards not having this. Would be better to have slightly more sophisticated peripherals running a RTOS then to have the added complexity of nested hosts.
+* Nested masters - Should there be abstractions built in to physical for setting one master to be the master of another.
+    * Leaning towards not having this. Would be better to have slightly more sophisticated peripherals running a RTOS then to have the added complexity of nested masters.

master/Cargo.toml

@@ -0,0 +1,15 @@
+[package]
+name = "physical-master"
+description = "Physical is a library for interacting with the physical world. The master physical computer is the computer peripherals are connected to and is intended to do the heavy lifting of data processing and decision making for the system being controlled"
+version.workspace = true
+edition.workspace = true
+repository.workspace = true
+readme.workspace = true
+license.workspace = true
+
+[dependencies]
+thiserror.workspace = true
+uom.workspace = true
+log.workspace = true
+env_logger.workspace = true
+tokio = { workspace = true, features = ["full"] }