Electrostatic-Sandbox

Preface:

An electronic monstrosity workstation designed to examine and develop systems for distributed simulations by providing an integrated environment housing the basic nostalgic communication protocols (i.e., Serial and Parallel COMs), the abstract networking interfaces, and a range of other electronic modules providing standards for controller interfaces, and sensor modules (e.g., the underdeveloped ShiftAvr, and Arduinos).

This electronic monstrosity features and leverages a powerful system-engineering infrastructure framework, the Electrostatic-Sandbox Framework for distributed simulation systems, a complete SDK suite written purely in C programming language with a JNI binding based on the IEEE-1516 HLA Spec. and NASA DSES.

Hardware-Software specification overview:

Item	Explanation
Problem Definition	Obtaining an integrated environment to efficiently integrate embedded systems with other resources like graphics-based applications and games, with an essential predicate of providing the blend of the old communication protocols, and externally pluggable electronic modules.
Scientific Recall of the Problem	Using the abstract Set Theory and Predicate Logic annotations, the main problem can be described as a universal set of predicates. In other words, the main problem is the universe set $P_{Env.}$; where P designates a problem universe set, and Env. stands for the environment. Now, $P_{Graphics}$ represents another requirement set of graphics-based applications, and $P_{COM}$ represents the problem set of COM protocols and finally $P_{Modules}$ designating a problem set of pluggable electronic modules including sensor modules that are indirectly established with the $P_{Env.}$. Thus, the general scientific model for the problem is $P_{Env.} = [ P_{Motherboard}, P_{Graphics}, P_{COM}, P_{Modules} ]$, and then recall their binary relations set in a duplex transmission system as $$R_{Env.} = [(P_{Motherboard}, P_{Motherboard}), (P_{Motherboard}, P_{Graphics}), (P_{Motherboard}, P_{COM}), (P_{Motherboard}, P_{Modules}), (P_{Motherboard}, P_{Null}),$$ $$(P_{Graphics}, P_{Motherboard}), (P_{Graphics}, P_{Graphics}), (P_{Graphics}, P_{COM}), (P_{Graphics}, P_{Modules}), (P_{Graphics}, P_{Null}),$$ $$(P_{COM}, P_{Motherboard}), (P_{COM}, P_{Graphics}), (P_{COM}, P_{COM}), (P_{COM}, P_{Modules}), (P_{COM}, P_{Null}),$$ $$(P_{Modules}, P_{Motherboard}), (P_{Modules}, P_{Graphics}), (P_{Modules}, P_{COM}), (P_{Modules}, P_{Modules}), (P_{Modules}, P_{Null})]$$, with a cardinality of $|R_{Env.}| = P^{e} + R_{Null} = 4^2 + 4 = 20$; where $P$ is the number of problems in the $R_{Env}$ set, $e$ is the number of problems per relation, and $R_{Null}$ is the number of null relations. Thus the final analogy of the problem is: $$P_{Env.} = [ P_{Motherboard}\ U\ P_{Graphics}\ U\ P_{COM}\ U\ P_{Modules} \ |\ R_{Env.}\ {\neq}\ {\phi}]$$
General Approach	The general approach entails buying one of the available workstations or toolkits for embedded systems.
Draw Backs of the General Approach	The problem with the general solution that it didn't address providing an efficient realtime graphics simulation environment, so the performance is quite poor when advanced graphics-based applications are required to be tested in conjunction with the communication protocols and the electronic modules.
Specific Minimal Approach	The minimal approach utilizes this simplistic model that uses the Set Theory. Nonetheless, we are merely concerned about the relation set $R_{Env.}$ inside the integrated environment, as it maps the behavior we are seeking from the system.
Upgrading the system	Theoretically, the previously mentioned scientific model includes the complements of the problem elements described, therefore for instance, the $P_{Modules}$ has its complement $P'_{Modules}$ which means that we can add expansion modules designated as complements for the pre-existing modules to our system, as well. The practicability of this is well-demonstrated, but half-revealed in a way that it's very much related to the original equation: Which motherboard are we going to use? AND Which type of COM and modules are utilized in this set? Are they really compatible? We will see about these details when we scope down on the circuit-design level...
Scientific Recall of the solution	Again, using the Set Theory and the Group Theory, envision the environment to build is a universe set E with a main board known as GA standing for Gigabyte, a set of peripherals P, and a set of communication modules providing communication protocols COM, and a set of external electronic modules M; thus the final scientific model will be $E = [GA, P, COM, M]$; where COM = {com | "com" is a communication protocol provided by a SoC module providing the relations between "GA", "P" and "M" sets}, P = {p | "p" is a peripheral device connected directly to the "GA" motherboard}, and M = {m | "m" is an electronic module connected indirectly to the "GA" motherboard using one or more of the board communication protocols "com"}.

The main board	General layout	Scheme

Table of content (WIP):

Hardware:

• General Components.
• General Circuitry scheme layout.
• Substantial Circuitry description (i.e., main board, peripherals, and modules).

Software:

• Basic Environment Setup.
• Electrostatic-Sandbox Tools (i.e., development tools, frameworks, and APIs).
• Electrostatic-Sandbox Framework (a set of APIs blending Serial4j, Socket4j, ShiftAvr, and Parallel4j for building distributed simulation systems).

Main Attachments:

• GA-H61M-S2P Rev-2.0
• Kingstone 4GB DIMM
• PCI-e USB Card.

DIY Tutorial:

Find the do-it-yourself tutorial at diy-tutorial.

General progress:

API used:

• Serial4j.
• Articular-ES.
• Automata4j.
• Jector.
• ShiftAvr.
• Parallel4j.
• Socket4j.
• Electrostatic-sandbox-framework.

Environment Setup:

• setup-tools scripting.
• setup-framework scripting.

Electrostatic-sandbox framework:

• Electroserial API: wraps Serial4j API providing a generic boundary to the Electrocomponent API.
• Electroparallel API: wraps Parallel4j API providing a generic boundary to the Electrocomponent API.
• Electrosocket API: wraps Socket4j API providing a generic boundary to the Electrocomponent API.
• Electrocomponent API: provides the vertical HAL for interacting with devices through device managers based on the scientific model provided by the Set Theory.
• Electrostatic-sandbox-examples: examples and techdemos utilizing the HAL API directly to interact with peripheral devices and/or use one of the above core APIs.
• Deployment to Maven Central.
• Build the framework into an SDK.

Circuitry Explanation:

• GA-H61M-S2P Rev-2.0 circuit connections details.
• Scientific modelling to the circuitry and connection details.
• ShiftAvr circuitry explanation.
• Digital electronics and digital design.

References (Direct links to useful topics):

Operational:

• GNU/Linux glibc reference manual on terminal I/O
• GNU/Linux glibc reference manual on low-level I/O
• Linux Kernel Userspace APIs
• Linux Manual Page Generic IO using IOCTL
• Linux Generic IOCTL Functions to control data routing
• Linux Manual Page Serial IOCTL
• Linux Serial IOCTL Magic Macros
• Linux Parallel IOCTL Magic Macros
• Linux IOCTL CDROM Magic Macros
• Linux IOCTL PCI-e Magic Macros
• Linux IOCTL USB FS Magic Macros
• Linux Kernel Test Hashing

Theoretical papers:

• TWOs Discrete Event Simulation
• VME TWOs Discrete Event Simulation
• NASA Distributed System simulation
• C/C++ IBM Language Reference
• GNU C Language Reference Manual
• GCC Compiler Reference Manual
• libstdc++ Reference Manual
• GNU libc Reference Manual
• Java-20 APIs Documentation Oracle
• Java-20 JNI API Documentation
• Java-20 Language Reference Oracle
• Java-20 VM Oracle
• NASA C/C++ Native Coding Style
• Java Google Coding Style
• Ubuntu-bionic Internals

Technical Books:

• Serial Port Complete by Jan Axelson's
• Parallel Port Complete by Jan Axelson's
• USB Complete by Jan Axelson's
• USB Embedded Hosts Complete by Jan Axelson's
• USB Mass Storage Complete by Jan Axelson's
• Embedded Ethernet and Internet Complete by Jan Axelson's
• The Microcontroller Idea Book
• Making Printed Circuit Boards
• PCI-e Programming
• AVR Microcontroller Programming
• In-serial Programmer software protocol
• Parallel Programmer software protocol

Credits:

Credits should go to these products and platforms for being open-source and widely available with no constraints, hooray to them:

• The Java Platform.
• Oracle Corporation.
• The CMake Building Framework.
• The jMonkeyEngine game engine.
• The Gradle API.
• The GraalVM team.
• The Linux Kernel.
• The GNU/Linux Operating Systems.
• The Avrdude tool.
• The Arduino Platform.
• The OpenAI API (GPT-3) mainly for scripting and project management.
• The Gigabyte Company (not open-source, but the main board depends on).
• Zorin OS (the main OS currently in-use).
• SanDisk (flash drive).
• Microchip & ATMEL (for AVR microcontrollers).
• The Linux Man Page & Micheal Kerrisk's Linux Interfacing Book.
• The GNU/Linux glibc and the interfacing libraries.
• IEEE for providing the standards of I/O Communication interfaces.
• The Universal Serial Bus (USB) Corporation.
• The Microsoft Corp. for providing VsCode, an easy-to-use code editor.
• The Jetbrains Corp. for providing Intellij-IDEA IDE.
• The NASA Technical Reports Server (NTRS) for providing open publications from their distributed simulation systems.
• Maven Central, Sonatype and JIRA services for hosting open-source APIs.
• Springer Nature for providing Mathematics books and publications on predicate calculus and logic analysis.
• The ACM digital library for providing publications about distributed simulation systems.
• The GitHub Platform and Git VCS for hosting this project.
• The KiCad project.
• The Fritzing project.

And, To others who I didn't mention, and were essential predicates for the success of this project.