BFPOWER/physical
2
0
Fork 0
Code Issues 2 Pull Requests Releases Activity

README updates.

Browse Source
This commit is contained in:
Zachary Levy
2022-10-07 09:42:47 -07:00
parent 407aaa951c
commit 886fbf0020
1 changed files with 9 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
README.md
View File

@ -34,15 +34,19 @@ As this is a broad purpose physical is intended to run on or interact with a wid
* In physical, all configuration must be done ahead of time. That is once the device build phase of the program is complete, there cannot be any change to the configuration. * In physical, all configuration must be done ahead of time. That is once the device build phase of the program is complete, there cannot be any change to the configuration.
* Peripherals cannot be added or removed. * Peripherals cannot be added or removed.
* I/O settings cannot be changes. * I/O settings cannot be changed.
* The only allowed "change" is to change the value of an output (like setting a digital output to high instead of low). * The only allowed "change" is to change the value of an output (like setting a digital output to high instead of low).
## Roadmap ## Roadmap
- [ ] Minimal implementation of physical for hosts. 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.
## Questions ## Questions
* Nested hosts - Should there be abstractions built in to physical for setting one host to be the master of another. Use cases: * Nested hosts - Should there be abstractions built in to physical for setting one host to be the master of another.
* Very large systems where we want to distribute some of the data processing or have some sort of "intermediate host" which is more capable of real time tasks that are too intensive to run on the peripheral itself. * 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.
* Need to use a more complex communication protocol than can be easily supported in a peripheral (such as ethernet) to get to the master host.