So, this is my understanding of the current hardware situation and task goals (extrapolated from conversations on PHABRICATOR and the [[ https://wiki.apertus.org/index.php/Mission_Briefings | Mission Briefing ]]). This is just my spec proposal, and I would like to have feedback before I begin implementation - or teams are built to take on individual tasks.
# WebGUI dependencies: REST, camera control daemon, automated firmware builds
**Please help me to correct erroneous / missing information by editing this directly **
##The CONTROLLER must:
- be absolutely error free and buttery smooth from day one and forever after
- work perfectly on a well-defined set of devices, OS's and browsers
- gracefully fall back from touchscreen to mouse to keyboard to kicking and screaming
- implement existing graphic design work
- be highly reactive (max 33ms until DAEMON reacts to a command, 99ms for initial job state feedback from INTERFACE)
- //I know this is utopian. Just the network stacks on each end each need 10-15ms but I think its possible when the system is tuned.//
- act as display for:
- toast / alert / alarm notifications
- system status including daemon's registered components
- user interaction feedback
- debounce user input
- register and certify user device to interface by using the nonce created by the system INTERFACE when it downloaded its code
- work on one or more user-provided device(s)
- smartphone mounted to enclosure
- focus puller remote
- hdmi touchscreen monitor (is this out of scope?)
- allow for a user to lock out other potential users
- Owner: RW
- Others: RO / none / dump / blacklist
- work without requiring internet uplink at all, however it must connect to the camera via wifi or USB and pull its code at session begin (or on nonce invalidity)
- Connecting to the camera should be easy (but is out of scope for the CONTROLLER)
- Having LED feedback on the camera would be excellent
- send no more than one packet of MTU per command
- including user nonce as "key"
- maintain user's preferences and current "nonce"
- include documentation and video how-to
- include tests
##The system INTERFACE must:
- have a CLI interface for remote (or headless) management and debugging (build this first, then open to the controller over TCP)
- enable TCP-IP communication via classical port 80
- accept well-formed curl / wget commands
- be callable from within the system for e.g. touchscreen events, broadcasts, DAEMON emergency calls
- offer nonce'd controller client code (html, js, css)
- assume that DAEMON always succeeds in certain cases and reply with the "assumed" message - which would then be overwritten in case DAEMON says so (because DAEMON is always right)
- react to physical User Switch / Reset Switch
- enable easy registry of new features (via DAEMON module publish strategy)
- be a thin layer for communication between CONTROLLER <-> DAEMON
- just like a classical I/O pipe: take an input from CONTROLLER, parse it, send it to DAEMON, watch for DAEMON's response and forward that back as output
- maintain a low-security user-registry of preferences (via nonce tracking / locking)
- be self-documenting
##The DAEMON must:
- use fifo instead of files or database as control structure
- be isolated from user input (at tcp, stack and environment levels) i.e. a polling service looking for well-formed commands that land on fifo.in (that should live in a small wordsize ideally in the L2 Cache - namely exactly at MTU of ≤ 536 bytes)
- monitor, kill and restart its spawn when needed
- as a mission critical interface have high `nice` priority
- manage the state of the hardware (absolute highest priority)
- read from fifo.in (highest priority)
- write results to ram-backed storage (fifo.out) high priority
- report on state of the hardware (normal priority)
- maintain a logrotate in non-volatile storage (low priority - NOT SD!)
- watch file I/O, disk, network, battery health (lowest priority)
- publish its currently available modules and their status as registered on boot (init priority)
- include documentation
- include tests
----
**CURRENT BUILD STATE (BETA 2)**
- Hardware host: Xilinx Zynq 7020 based MicroZed
- Data sheet: [[ http://zedboard.org/sites/default/files/product_briefs/PB-AES-Z7MB-7Z010-G-V2.pdf | microzed.org ]] | [[ https://www.avnet.com/shop/us/products/avnet-engineering-services/aes-z7mb-7z020-som-g-3074457345628965473/ | Tech Specs ]] (Please pull these resources and make available locally)
- SOC: AES-Z7MB-7Z020-SOM-G (Z7MB-720x0-ASY Revision Board)
- Clock: 33.33 Mhz Oscillator
- Hardware Clock Speed:
- Processors: Dual ARM® Cortex®-A9 MPCore™ with CoreSight™
- Dual Core A9 32 bit (NEON instructions 64 bit)
- `cat /proc/cpuinfo` output:
- Cache: 512-KB L2 Unified Cache with ECC
- GPU/VPU: none
- RTC: none
- Ram: 1 GB of DDR3 SDRAM (what is the clock speed)
- microSD: 8gb class 10 (What purpose does the SD card serve? First time boot? Nand flashing?)
- Nand: 128 Mb of QSPI Flash (Is this the boot source? Are logs written to /var here?)
- SSD: User Mod (make, model, size?)
- USB: USB-OTG, USB 2.0
- Wifi: None onboard [[ https://www.olimex.com/Products/USB-Modules/MOD-WIFI-AR9271-ANT/ | my recommendation ]] or [[ https://www.olimex.com/Products/USB-Modules/MOD-WIFI-AR9271-ANT/ | long-range ]]
- Communication: Ethernet (ssh / tcp), UART, USB 2.0, JTAG
- Physical switches: 2 (reset / user defined) -> what are we using it for?
- Voltage: 5V (over USB micro) possible also via PoE, PoUSB or (maybe) J4
- Battery: None, possible with [[ https://www.olimex.com/Products/Power/BATTERY-LIPO4400mAh/ | LiPo ]] and [[ https://www.olimex.com/Products/Power/USB-uLiPo/open-source-hardware | charger ]] plugged into the beta power adapter???
- Additional boards:
- https://wiki.apertus.org/index.php/Beta_CMV12K_ZIF_Sensor_Board
- https://wiki.apertus.org/index.php/Beta_Interface_Dummy_Board
- https://wiki.apertus.org/index.php/PMOD_LED_Matrix_Debug_Module
- https://wiki.apertus.org/index.php/Beta_HDMI_Plugin_Module
- https://wiki.apertus.org/index.php/Beta_1x_PMOD_Plugin_Module
- https://wiki.apertus.org/index.php/Beta_Debug_Shield
- https://wiki.apertus.org/index.php/Beta_Power_Board
- https://wiki.apertus.org/index.php/Beta_Main_Board
- https://wiki.apertus.org/index.php/Beta_Power_Adapter_Board
- OS: [[ https://gitlab.com/apertus/beta-software/-/jobs/artifacts/master/download?job=final_artifacts | Arch Linux ]] based on http://stefan.konink.de/contrib/apertus/
- Version Management: git (managed externally)
- Live Build System: `dd if=..` or [[ https://etcher.io/ | etcher ]] -> SD Card
- Firmware Build System: https://lab.apertus.org/T697
- Virtual Machine Image: none
- Screen Buffers: VDPAU I assume, via HDMI?
- Hardened: no SELinux
- Available code environments: /usr/lib/* linked and precompiled assembly, c, c++ binaries; python 2.7, ...
- Available shells: bash, sh
- Use #!/usr/bin/env: no
- Available permissions: granular, inheritable but root is available
- Disallowed builtins: none
- User Management: none (arch default) apertus:apertus
- Container Management: none
- Process Management: none (other than PID / top)
- Resource Management: per script, no central lookup table
- Benchmarking: none
**ERRATA**
- https://wiki.apertus.org/index.php/Useful_Links
- https://wiki.apertus.org/index.php/Mission_Briefings
- https://gitlab.com/apertus
- NEON STUFF - [[ https://stackoverflow.com/questions/4097034/arm-cortex-a8-whats-the-difference-between-vfp-and-neon?rq=1 | You have 3 possibilities to use Neon:]]
- use intrinsics functions #include "arm_neon.h"
- inline the assembly code
- let the gcc to do the optimisations for you by providing -mfpu=neon as argument (gcc 4.5 is good on this)
- https://stackoverflow.com/a/38775842
- http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204h/Bcfhfbga.html