DDD documentation

DDD manages the global variables of a component based embedded software project. Every component declares the variables it produces and consumes in a small json file; DDD checks that all components agree, generates the c code that allocates the data, and generates the ASAP2 (a2l) description that measurement and calibration tools read.

Using DDD

• Getting started
  • Installation
  • Your first project
  • When the components disagree
  • Where to go next
• Concept
  • Principles
  • Vocabulary
  • scope
  • Position in the build process
  • How the tool is put together
• File formats
  • What kind of file this is
  • Unknown keys are rejected
  • The schema is published
• Consistency checks
  • What a check is
  • Severity policy
  • The checks
  • The producing component wins
  • A project that does not check out
  • Exit codes and ci
• Comparing deliveries
  • Two questions, not one
  • Why the second question needs an archived dictionary
  • The workflow
  • The comparison checks
  • A worked example
  • Limits: widening is silent, narrowing is not
  • A rescaled conversion is an error
  • When the baseline is the wrong file
  • The baseline’s own findings are not findings of this run
  • In a build pipeline
• Generated artefacts
  • c code
  • a2l
• Templates
  • Why the templates belong to the project
  • The a2l file is not templated
  • Why jinja2
  • How the template directory is read
  • What a template receives
  • Helpers, and what a subdirectory is for
  • A mistake in a template stops the run
  • How the files reach the disk
  • Getting started
  • The example templates
• Command line interface
  • The commands
  • Severity options
  • The sources of a project
  • Reference
• Build integration
  • cmake
  • docker
• Editor integration
  • What the server offers
  • Which project a file belongs to
  • VS Code

Reference

• Data contracts
  • Validation at the boundary
  • Unknown fields are rejected
  • Identifiers are constrained
  • Numbers must be finite
  • Nothing changes behind a caller’s back
  • Publishing the schemas
  • Reference
• Data dictionary
  • What is already resolved
  • The format field
  • Consuming it from another tool
  • Reference
• Developer documentation
  • Layers
  • The split is enforced by a test
  • What a backend is
  • Diagnostics never raise
  • What the calibration tools actually implement
  • The coverage gate
  • Running the checks
  • Continuous integration
  • Building this documentation
  • Publishing this documentation
  • Publishing a release
  • Publishing the editor extension
• FAQ
  • Why must my description files be named *.ddd.json?
  • Can I check a single component before it is integrated?
  • What is the difference between ddd check and ddd compare?
  • Can I relax a check for one project?
  • Two components disagree - whose definition is generated?
  • Why does my consumer not get a definition-mismatch when it leaves the limits out?
  • Why do I have to write conversion when it is just the identity?
  • How do I stop every consumer from copying the same datatype and scaling?
  • How do I keep everybody spelling units the same way?
  • How do I place a variable in a particular memory section?
  • Where does my editor get the project and the severities from?
  • Why does DDD refuse my enum name?
  • How do I keep a variable out of the a2l?
  • Why is my axis in the a2l although I set export to false?
  • How do I get the real addresses into the a2l?
  • Why is the address of my variable still 0x00000000?
  • Which a2l version does DDD write?
  • How large may an array be?
  • How do I generate for two images built from the same components?
  • Why does regenerating not retrigger my build?
• Acronyms
  • Acronyms and abbreviations
  • a2l keywords

Indices and tables

• Index

• Module Index

• Search Page