Hosam-Eldin Mostafa
7392272a5b
A reader asked where FrameIO gets its list of known frame names from —
because looking at `fio.send("ALM_Req_A", ...)` it seems like the class
must hold a registry somewhere. It doesn't: FrameIO is a broker that
forwards an incoming string to the LDF object it was constructed with,
and the string lives either in the test source (Path A) or in the
generated wrapper class (Path B).
Adds section 2 "How frame names reach FrameIO" to
docs/19_frame_io_and_alm_helpers.md, between the "Three layers of
access" overview (section 1) and the API reference (formerly section 2,
now section 3). The new section contains:
- A table of where the names actually live: LDF file on disk,
LdfDatabase after parsing, caller source code. FrameIO is explicitly
NOT in that table.
- The FrameIO class skeleton showing the empty _frames cache.
- A concrete ASCII call trace of `fio.send("ALM_Req_A", ...)` from
test source -> FrameIO -> LdfDatabase -> ldfparser -> byte layout.
- Path A (stringly-typed) vs Path B (typed wrapper from gen_lin_api),
with the trade-off (typo caught at runtime vs at import time).
- The cache lifecycle (starts empty, fills lazily, one entry per
unique frame name passed in).
- A "mental model" summary calling FrameIO a generic glue layer.
Sections 3-9 renumbered to make room (3->4, 4->5, ..., 8->9). The 7.x
sub-sections under "Writing a new test" become 8.x. Updates the
stale anchor link in 14_power_supply.md
(#72-the-four-phase-test-pattern -> #82-the-four-phase-test-pattern).
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/