Hosam-Eldin Mostafa
ec218bd5fe
The previous ASCII pipeline implied a single linear stack from gen_lin_api
down through FrameIO down through ecu_framework/lin/ldf.py — and showed
a static dependency from FrameIO to that module. Both are wrong.
What the code actually says (tests/hardware/frame_io.py:34):
from ecu_framework.lin.base import LinFrame, LinInterface
That's the only ecu_framework import in FrameIO. The `ldf` constructor
parameter is duck-typed — FrameIO never imports LdfDatabase and would
work against any object exposing `.frame(name)`. So `frame_io → lin/ldf`
is an injected runtime call, not a module dependency.
Replace the linear ASCII diagram with a Mermaid parallel-paths diagram
that surfaces the three independent ways a tester can address a frame:
- gen_lin_api typed wrapper (compile-time name check)
- FrameIO stringly-typed I/O (with raw send_raw/receive_raw escape
hatches that don't touch the ldf object at all)
- LdfDatabase used directly (schema-only — pack to bytes, no I/O)
…all converging at LinInterface. The prose around the diagram is
rewritten to match: each path's affordance, and what concrete capability
is lost by removing any of the three.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Documentation Index
A guided tour of the ECU testing framework. Start here:
01_run_sequence.md— End-to-end run sequence and call flow02_configuration_resolution.md— How configuration is loaded and merged03_reporting_and_metadata.md— How test documentation becomes report metadata11_conftest_plugin_overview.md— Custom pytest plugin: hooks, call sequence, and artifacts04_lin_interface_call_flow.md— LIN abstraction and adapter behavior (Mock, MUM, and the deprecated BabyLIN)05_architecture_overview.md— High-level architecture and components06_requirement_traceability.md— Requirement markers and coverage visuals07_flash_sequence.md— ECU flashing workflow and sequence diagram08_babylin_internals.md— BabyLIN SDK wrapper internals and call flow (DEPRECATED)16_mum_internals.md— MUM (Melexis Universal Master) adapter internals and call flow17_ldf_parser.md— LDF parser,ldffixture, and per-framepack/unpackhelpers18_test_catalog.md— Per-test catalog: purpose, markers, hardware needs, expected resultDEVELOPER_COMMIT_GUIDE.md— What to commit vs ignore, commands09_raspberry_pi_deployment.md— Run on Raspberry Pi (venv, service, hardware notes)10_build_custom_image.md— Build a custom Raspberry Pi OS image with the framework baked in12_using_the_framework.md— Practical usage: local, hardware (MUM, or the deprecated BabyLIN), CI, and Pi13_unit_testing_guide.md— Unit tests layout, markers, coverage, and tips14_power_supply.md— Owon PSU control, configuration, tests, and quick demo script15_report_properties_cheatsheet.md— Standardized keys for record_property/rp across suites19_frame_io_and_alm_helpers.md— Hardware-test helpers:FrameIO(generic LDF I/O) andAlmTester(ALM_Node domain), plus thetests/hardware/_test_case_template.pystarting point20_docker_image.md— Containerizing the framework: mock-only CI image, hardware-passthrough image, the Melexis-package obstacle, compose & CI examples21_yocto_image_for_raspberry_pi.md— Building a Yocto image that turns a Raspberry Pi into a self-contained test bench (BSP layout, recipes, network/USB config, deploy & maintenance)23_config_loader_internals.md— Howecu_framework/config/loader.pyis implemented: merge semantics, type coercion, schema quirks, and the PSU side-channel24_test_wiring.md— How tests are wired to the framework: fixture topology, session lifecycle, the polymorphism boundary onlin, and the playbook for adding a new framework component
Related references:
- Root project guide:
../README.md - Full framework guide:
../TESTING_FRAMEWORK_GUIDE.md - BabyLIN placement and integration:
../vendor/README.md(deprecated; only relevant for legacy rigs) - MUM source scripts and protocol details:
../vendor/automated_lin_test/README.md - PSU quick demo and scripts:
../vendor/Owon/