This directory is the documentation entry point for contributors and users who need more detail than the project README.
| Goal | Read |
|---|---|
| Install or run VDS4E | Getting started |
| Build a first virtual peripheral | First virtual device tutorial |
| Automate/control the server | Control-plane API |
| Understand the architecture | Architecture |
| Work with SPI | SPI guide |
| Work with I²C | I²C guide |
| Work with GPIO | GPIO guide |
| Work with UART | UART guide |
| Connect device signals to GPIO | Topology guide |
| Create device packages | Device Package SDK |
| Author behavior flows | Behavior-flow reference |
| Run and understand tests | Testing guide |
| Build a release | Release guide |
| Diagnose a local setup problem | Troubleshooting |
| Contribute code | Contributing |
| Review design decisions | Architecture Decision Records |
| See planned work | Roadmap |
The project keeps documentation at three levels:
- README: product overview, quick start, supported interfaces and project boundaries.
- Guides and references: operational workflows, device-package authoring, testing, release procedures and troubleshooting.
- Architecture and ADRs: authoritative design constraints and the history behind architectural decisions.
If implementation and documentation disagree, treat VDS4E_ARCHITECTURE.md and accepted ADRs as the architectural source of truth, then update stale operational documentation with the implementation change.
Documentation changes should accompany changes to public commands, configuration, schemas, Linux ABI behavior, device-package contracts or release workflows. Avoid documenting future components as if they already execute. Planned capabilities belong in the roadmap.