Module Boundaries: boards

How to read the diagram

This Package Diagram centers on boards, showing the file size, symbol size, and cross-module dependencies observed when it serves as a project module boundary.
The arrows in the figure represent the cross-module relationships observed by the local warehouse evidence, which are mainly used to understand the direction of technical dependencies; it is not the business process sequence, nor the runtime message timing.
The main external dependencies currently observed include: apps/esp32_lvgl, apps/linux_cardputer_zero, apps/nrf52_node, apps/linux_uconsole_gtk, apps/linux_sim_shell, firmware.

Technical complexity analysis

Boards currently contains 92 files and 1952 symbols belonging to the technical organizational boundaries identified by the software architecture model.
The cross-module relationship is as follows: it is referenced or called 47 times by other modules, and it actively depends on or calls external modules 183 times, so it depends more on external modules.
More external dependencies may indicate that this module is responsible for orchestrating, aggregating or bridging multiple capabilities; it is currently handled as a candidate technology coupling center.

Relationship with business complexity

Boards are not the business story itself, but the technical boundaries that business capabilities may pass through when implemented.
If the evidence, entry or drill-down diagram of a Use Case in the organization/process model falls on boards, the Use Case should be linked back to this Package Diagram to indicate which engineering module the business story is hosted by.
The current association is still CANDIDATE: the technical boundaries can only be explained here based on warehouse evidence and cannot replace the confirmation of the business story, actors and business goals of the organizational/process model.

Governance Suggestions

When adding a new function, give priority to confirming that it belongs to the stable responsibility of the module, rather than falling into this module because of the convenience of calling.
If multiple changes in the future increase the external dependencies of this module, you should consider splitting the port, adapter or application service boundary.
When the business Use Case document refers to this module, the specific entry, call chain or configuration evidence should be recorded in the Use Case drill-down document.

UML/Technical Diagram

flowchart LR
  package_node["boards"]
  dependency_1["apps/esp32_lvgl"]
  package_node --> dependency_1
  dependency_2["apps/linux_cardputer_zero"]
  package_node --> dependency_2
  dependency_3["apps/nrf52_node"]
  package_node --> dependency_3
  dependency_4["apps/linux_uconsole_gtk"]
  package_node --> dependency_4
  dependency_5["apps/linux_sim_shell"]
  package_node --> dependency_5
  dependency_6["firmware"]
  package_node --> dependency_6

Coverage

Module path: boards
Number of files: 92
Number of symbols: 1952
Depends on or called by other modules: 47
Depends on or calls external modules: 183

Drill-down of semantic elements in the diagram

boards package
Boards is the central project boundary of the current Package Diagram, used to observe its own scale, dependency direction and drill-down technical complexity.

Technical role
Technical organization boundary: It aggregates files, symbols and cross-module relationships under boards into a discussable engineering unit.

Why it appears
The local repository evidence has enough files, symbols, or cross-module relationships observed under boards so that it deserves to be promoted to a package-level entry in the software structure model.

Relationship meaning
The arrows from boards to other nodes in the figure indicate that the current boundary depends on external packages/modules; it is dependent on or called 47 times by other modules, and depends on or called external modules 183 times, which is used to determine whether it is more like a stable reuse boundary or an orchestration/bridging boundary.

Drill-down intention
Drilling down on this node can continue to view the key components, structural collaboration slices, running links, deployment nodes and complexity hotspots within the boards to understand how this engineering boundary carries functional changes.

Business association
This node is not the business story itself, but the Use Case that falls on boards in the organization/process model can refer to this as the technology bearing boundary. The current association is still CANDIDATE.

Impact of change
Modifying the public entry, dependency direction or directory boundary of boards may affect the verification path of component diagrams, sequence fragments, deployment configurations and related business stories that reference it.

Confidence
high
Evidence
- package scope: boards
- Module path: boards
- Number of files: 92
- Number of symbols: 1952
- Depends on or called by other modules: 47
- Depends on or calls external modules: 183
- boards/cardputerzero/board_facts.h
- boards/cardputerzero/BOARD.md
Risk
- If you only regard this node as a directory name, you will miss its responsibility as a stable project boundary.
- If signs of dependency on external modules continue to increase, it may be a sign that the boundary is taking on too much orchestration or bridging responsibility.
Problem
- The current warehouse evidence has not yet explicitly traced the package to a Use Case; therefore, the business association remains a candidate.
apps/esp32_lvgl package
apps/esp32_lvgl is the external technical boundary dependency currently observed by boards; it indicates that the current module is not implemented in isolation, but requires the help of another set of engineering capabilities to complete its responsibilities.

Technical role
Cross-module technology dependency boundary: The current package requires another package/module to provide capabilities, contracts, configuration or operation support.

Why it appears
Local repository evidence observes a cross-module factual relationship between boards and apps/esp32_lvgl, so the dependency is put into the Package Diagram instead of just hidden in the code import/call.

Relationship meaning
boards -> apps/esp32_lvgl indicates that the local repository evidence observes cross-module relationships; it explains the technical dependency direction, but does not directly prove the business process.

Drill-down intention
Drill down into apps/esp32_lvgl to view its own Package Diagram, and then continue to enter its components, structures, sequences or hotspots to determine whether the current dependency falls on the entry, runtime, tool registration, model adaptation or infrastructure boundary.

Business association
boards If hosting a user-visible capability, the dependency on apps/esp32_lvgl may be the operating mechanism, extension point, or governance constraint of that capability. This business association needs to be confirmed by the Use Case evidence of the organization/process model.

Impact of change
Modifying the public interface, path or running mode of apps/esp32_lvgl may cause chain changes in the boards' call chain, packaging entry, agent workflow or UI behavior.

Confidence
high
Evidence
- dependency edge: boards -> apps/esp32_lvgl
- apps/esp32_lvgl/APP_SHELL_MANIFEST.md
- apps/esp32_lvgl/CMakeLists.txt
- apps/esp32_lvgl/library.json
- apps/esp32_lvgl/README.md
- apps/esp32_lvgl/src/esp32_lvgl_app_shell.cpp
- apps/esp32_lvgl/src/esp32_lvgl_app_shell.h
- apps/esp32_lvgl/src/esp32_lvgl_arduino_app_registry.cpp
Risk
- Cross-module dependencies can only prove technical relationships, but cannot directly prove business relationships.
- If this dependency only exists for implementation convenience, future changes may cause boundary drift or implicit public toolboxes.
Problem
- Current evidence does not prove that boards' dependency on apps/esp32_lvgl is directly related to a Use Case, runtime command, or configuration decision.
- The current dependency direction is a candidate according to the warehouse fact record, and no architectural decision document has been found to prove that it is a stable boundary.
apps/linux_cardputer_zero package
apps/linux_cardputer_zero is the external technical boundary dependency currently observed by boards; it indicates that the current module is not implemented in isolation, but requires the help of another set of engineering capabilities to complete its responsibilities.

Technical role
Cross-module technology dependency boundary: The current package requires another package/module to provide capabilities, contracts, configuration or operation support.

Why it appears
Local repository evidence observes a cross-module factual relationship between boards and apps/linux_cardputer_zero, so the dependency is put into the Package Diagram instead of just hidden in the code import/call.

Relationship meaning
boards -> apps/linux_cardputer_zero indicates local repository evidence of observed cross-module relationships; it explains technical dependency direction but does not directly prove business processes.

Drill-down intention
Drilling down apps/linux_cardputer_zero, you can view its own Package Diagram, and then continue to enter its components, structures, sequences or hotspots to determine whether the current dependency falls on the entrance, runtime, tool registration, model adaptation or infrastructure boundary.

Business association
Boards If hosting a user-visible capability, the dependency on apps/linux_cardputer_zero may be the operating mechanism, extension point, or governance constraint of that capability. This business association needs to be confirmed by the Use Case evidence of the organization/process model.

Impact of change
Modifying the public interface, path or running mode of apps/linux_cardputer_zero may cause chain changes in the boards' call chain, packaging entry, agent workflow or UI behavior.

Confidence
high
Evidence
- dependency edge: boards -> apps/linux_cardputer_zero
- apps/linux_cardputer_zero/APP_SHELL_MANIFEST.md
- apps/linux_cardputer_zero/CMakeLists.txt
- apps/linux_cardputer_zero/packaging/trailmate-cardputer-zero-applaunch
- apps/linux_cardputer_zero/packaging/trailmate-cardputer-zero.desktop
- apps/linux_cardputer_zero/packaging/trailmate-cardputer-zero.png
- apps/linux_cardputer_zero/README.md
- apps/linux_cardputer_zero/src/cardputer_zero_input_method_port.cpp
Risk
- Cross-module dependencies can only prove technical relationships, but cannot directly prove business relationships.
- If this dependency only exists for implementation convenience, future changes may cause boundary drift or implicit public toolboxes.
Problem
- Current evidence does not prove that boards' dependence on apps/linux_cardputer_zero is directly related to a Use Case, runtime command, or configuration decision.
- The current dependency direction is a candidate according to the warehouse fact record, and no architectural decision document has been found to prove that it is a stable boundary.
apps/nrf52_node package
apps/nrf52_node is the external technical boundary dependency currently observed by boards; it indicates that the current module is not implemented in isolation, but requires the help of another set of engineering capabilities to complete its responsibilities.

Technical role
Cross-module technology dependency boundary: The current package requires another package/module to provide capabilities, contracts, configuration or operation support.

Why it appears
Local repository evidence observes a cross-module factual relationship between boards and apps/nrf52_node, so the dependency is put into the Package Diagram instead of just hidden in the code import/call.

Relationship meaning
boards -> apps/nrf52_node indicates that the local repository evidence observes cross-module relationships; it explains the technical dependency direction, but does not directly prove the business process.

Drill-down intention
Drilling down into apps/nrf52_node, you can view its own Package Diagram, and then continue to enter its components, structures, sequences or hotspots to determine whether the current dependency falls on the entry, runtime, tool registration, model adaptation or infrastructure boundary.

Business association
Boards If hosting a user-visible capability, the dependency on apps/nrf52_node may be the operating mechanism, extension point, or governance constraint of that capability. This business association needs to be confirmed by the Use Case evidence of the organization/process model.

Impact of change
Modifying the public interface, path or operation mode of apps/nrf52_node may cause chain changes in the boards' call chain, packaging entry, agent workflow or UI behavior.

Confidence
high
Evidence
- dependency edge: boards -> apps/nrf52_node
- apps/nrf52_node/APP_SHELL_MANIFEST.md
- apps/nrf52_node/library.json
- apps/nrf52_node/README.md
- apps/nrf52_node/src/nrf52_node_app_facade_runtime.cpp
- apps/nrf52_node/src/nrf52_node_app_facade_runtime.h
- apps/nrf52_node/src/nrf52_node_app_runtime_access.cpp
- apps/nrf52_node/src/nrf52_node_app_runtime_access.h
Risk
- Cross-module dependencies can only prove technical relationships, but cannot directly prove business relationships.
- If this dependency only exists for implementation convenience, future changes may cause boundary drift or implicit public toolboxes.
Problem
- Current evidence does not prove that boards' dependency on apps/nrf52_node is directly related to a Use Case, runtime command, or configuration decision.
- The current dependency direction is a candidate according to the warehouse fact record, and no architectural decision document has been found to prove that it is a stable boundary.
apps/linux_uconsole_gtk package
apps/linux_uconsole_gtk is the external technical boundary dependency currently observed by boards; it indicates that the current module is not implemented in isolation, but requires the help of another set of engineering capabilities to complete its responsibilities.

Technical role
Cross-module technology dependency boundary: The current package requires another package/module to provide capabilities, contracts, configuration or operation support.

Why it appears
Local repository evidence observes a cross-module factual relationship between boards and apps/linux_uconsole_gtk, so the dependency is put into the Package Diagram instead of just hidden in the code import/call.

Relationship meaning
boards -> apps/linux_uconsole_gtk represents local repository evidence of observed cross-module relationships; it explains technical dependency direction, but does not directly prove business processes.

Drill-down intention
Drilling down into apps/linux_uconsole_gtk, you can view its own Package Diagram, and then continue to enter its components, structures, sequences or hotspots to determine whether the current dependency falls on the entry, runtime, tool registration, model adaptation or infrastructure boundary.

Business association
Boards If hosting a user-visible capability, the dependency on apps/linux_uconsole_gtk may be the operating mechanism, extension point, or governance constraint of that capability. This business association needs to be confirmed by the Use Case evidence of the organization/process model.

Impact of change
Modifying the public interface, path or running mode of apps/linux_uconsole_gtk may cause chain changes in the boards' call chain, packaging entry, agent workflow or UI behavior.

Confidence
high
Evidence
- dependency edge: boards -> apps/linux_uconsole_gtk
- apps/linux_uconsole_gtk/APP_SHELL_MANIFEST.md
- apps/linux_uconsole_gtk/CMakeLists.txt
- apps/linux_uconsole_gtk/packaging/trailmate-uconsole.desktop
- apps/linux_uconsole_gtk/packaging/trailmate-uconsole.png
- apps/linux_uconsole_gtk/README.md
- apps/linux_uconsole_gtk/src/linux_uconsole_gtk_app_shell.cpp
- apps/linux_uconsole_gtk/src/linux_uconsole_gtk_app_shell.h
Risk
- Cross-module dependencies can only prove technical relationships, but cannot directly prove business relationships.
- If this dependency only exists for implementation convenience, future changes may cause boundary drift or implicit public toolboxes.
Problem
- Current evidence does not prove that boards' dependence on apps/linux_uconsole_gtk is directly related to a Use Case, runtime command, or configuration decision.
- The current dependency direction is a candidate according to the warehouse fact record, and no architectural decision document has been found to prove that it is a stable boundary.
apps/linux_sim_shell package
apps/linux_sim_shell is the external technical boundary dependency currently observed by boards; it indicates that the current module is not implemented in isolation, but requires the help of another set of engineering capabilities to complete its responsibilities.

Technical role
Cross-module technology dependency boundary: The current package requires another package/module to provide capabilities, contracts, configuration or operation support.

Why it appears
Local repository evidence observes a cross-module factual relationship between boards and apps/linux_sim_shell, so the dependency is put into the Package Diagram instead of just hidden in the code import/call.

Relationship meaning
boards -> apps/linux_sim_shell indicates that local repository evidence observes cross-module relationships; it explains the technical dependency direction, but does not directly prove the business process.

Drill-down intention
Drilling down into apps/linux_sim_shell, you can view its own Package Diagram, and then continue to enter its components, structures, sequences or hotspots to determine whether the current dependency falls on the entry, runtime, tool registration, model adaptation or infrastructure boundary.

Business association
boards If hosting a user-visible capability, the dependency on apps/linux_sim_shell may be the operating mechanism, extension point, or governance constraint of that capability. This business association needs to be confirmed by the Use Case evidence of the organization/process model.

Impact of change
Modifying the public interface, path or running mode of apps/linux_sim_shell may cause chain changes in the boards' call chain, packaging entry, agent workflow or UI behavior.

Confidence
high
Evidence
- dependency edge: boards -> apps/linux_sim_shell
- apps/linux_sim_shell/APP_SHELL_MANIFEST.md
- apps/linux_sim_shell/CMakeLists.txt
- apps/linux_sim_shell/README.md
- apps/linux_sim_shell/src/linux_sim_app_shell.cpp
- apps/linux_sim_shell/src/linux_sim_app_shell.h
- apps/linux_sim_shell/src/linux_sim_runtime_entry_adoption_probe.cpp
- apps/linux_sim_shell/src/linux_sim_runtime_entry_adoption_probe.h
Risk
- Cross-module dependencies can only prove technical relationships, but cannot directly prove business relationships.
- If this dependency only exists for implementation convenience, future changes may cause boundary drift or implicit public toolboxes.
Problem
- Current evidence does not prove that boards' dependence on apps/linux_sim_shell is directly related to a Use Case, runtime command, or configuration decision.
- The current dependency direction is a candidate according to the warehouse fact record, and no architectural decision document has been found to prove that it is a stable boundary.
firmware package
Firmware is the external technical boundary dependency currently observed by boards; it indicates that the current module is not implemented in isolation, but requires the help of another set of engineering capabilities to complete its responsibilities.

Technical role
Cross-module technology dependency boundary: The current package requires another package/module to provide capabilities, contracts, configuration or operation support.

Why it appears
The local repository evidence observes a cross-module factual relationship between boards and firmware, so the dependency is put into the Package Diagram instead of just hidden in the code import/call.

Relationship meaning
boards -> firmware represents local repository evidence of observed cross-module relationships; it explains technical dependency direction but does not directly prove business processes.

Drill-down intention
Drilling down into the firmware, you can view its own Package Diagram, and then continue to enter its components, structures, sequences or hotspots to determine whether the current dependencies fall on the entrance, runtime, tool registration, model adaptation or infrastructure boundary.

Business association
Boards If they host a user-visible capability, the dependency on firmware may be the operating mechanism, extension point, or governance constraint of that capability. This business association needs to be confirmed by the Use Case evidence of the organization/process model.

Impact of change
Modifying the public interface, path or operation mode of firmware may cause chain changes in the boards' call chain, packaging entry, agent workflow or UI behavior.

Confidence
high
Evidence
- dependency edge: boards -> firmware
- firmware/c6_companion/CMakeLists.txt
- firmware/c6_companion/components/tm_ble/CMakeLists.txt
- firmware/c6_companion/components/tm_ble/include/tm_ble.h
- firmware/c6_companion/components/tm_ble/tm_ble.c
- firmware/c6_companion/components/tm_diag/CMakeLists.txt
- firmware/c6_companion/components/tm_diag/include/tm_diag.h
- firmware/c6_companion/components/tm_diag/tm_diag.c
Risk
- Cross-module dependencies can only prove technical relationships, but cannot directly prove business relationships.
- If this dependency only exists for implementation convenience, future changes may cause boundary drift or implicit public toolboxes.
Problem
- Current evidence does not prove that boards' dependence on firmware is directly related to a Use Case, runtime command, or configuration decision.
- The current dependency direction is a candidate according to the warehouse fact record, and no architectural decision document has been found to prove that it is a stable boundary.

Drill-down UML

Function node: makeBoardProfile component · contains

Open the function node: makeBoardProfile to confirm which specific object within the boards is responsible for entry, orchestration, adaptation, contract or sharing responsibilities. Focus on checking the code anchor boards/t_echo_lite/include/boards/t_echo_lite/board_profile.h, and whether its referenced/calling relationship and external dependency/calling relationship mean that changes will spread.

function is located at boards/t_echo_lite/include/boards/t_echo_lite/board_profile.h#L188, coordinates multiple external objects or capabilities, and is used to explain technical collaboration and change impact areas.

Function node: pinNum component · contains

Open the function node: pinNum to confirm which specific object within the boards is responsible for entry, orchestration, adaptation, contract or sharing responsibilities. Focus on checking the code anchor boards/t_echo_lite/include/boards/t_echo_lite/board_profile.h, and whether its referenced/calling relationship and external dependency/calling relationship mean that changes will spread.

The function is located in boards/t_echo_lite/include/boards/t_echo_lite/board_profile.h#L8. It is reused or relied on by multiple objects and is used to explain technical collaboration and change impact.

Structural collaboration: structural slicing boards · gat562_mesh_evb_pro/include/boards class_structural · structural_context

Open structural collaboration: structural slicing boards · gat562_mesh_evb_pro/include/boards is to explain boards from the perspective of object collaboration: which objects are like entrances, which are like orchestration cores, which are like adaptation/sharing boundaries; it helps to judge that the complexity comes from the distribution of responsibilities, not just the number of files.

Explain how the classes, interfaces, components or value objects in the structural slice boards/gat562_mesh_evb_pro/include/boards share the structural responsibilities in the structural slice boards; candidates include Gat562Board, SX1262, Sx1262RadioPacketIo, Gat562Board::I2cGuard, GpsRuntime.

Structural collaboration: structural slice boards · t_echo_lite/include/boards class_structural · structural_context

Open structural collaboration: structural slicing boards · t_echo_lite/include/boards is to explain boards from the perspective of object collaboration: which objects are like entrances, which are like orchestration cores, and which are like adaptation/sharing boundaries; it helps to judge that complexity comes from responsibility distribution, not just the number of files.

Explain how the classes, interfaces, components or value objects in this structural slice share the structural responsibilities in the structural slice boards boards/t_echo_lite/include/boards; candidates include TEchoLiteBoard, Sx1262RadioPacketIo, TEchoLiteBoard::I2cGuard, GpsRuntime, Module.

Structural collaboration: structural slicing boards · tab5/include/boards class_structural · structural_context

Open Structural Collaboration: Structural Slicing boards · tab5/include/boards is to explain boards from the perspective of object collaboration: which objects are like entrances, which are like orchestration cores, which are like adaptation/sharing boundaries; it helps to judge that the complexity comes from the distribution of responsibilities, not just the number of files.

Explain how classes, interfaces, components or value objects in the structural slice boards/tab5/include/boards share structural responsibilities in the structural slice boards; candidates include Tab5Board, Tab5Board::ManagedSystemI2cGuard, Tab5Board::SysI2cGuard, and CodecCompat.

Structure collaboration: structure slicing boards · t_display_p4/include/boards class_structural · structural_context

Open structural collaboration: structural slicing boards · t_display_p4/include/boards is to explain boards from the perspective of object collaboration: which objects are like entrances, which are like orchestration cores, and which are like adaptation/sharing boundaries; it helps to judge that complexity comes from responsibility distribution, not just the number of files.

Explain how the classes, interfaces, components or value objects in the structural slice boards/t_display_p4/include/boards share the structural responsibilities in the structural slice boards; candidates include TDisplayP4Board, TDisplayP4Board::ManagedSystemI2cGuard.

Structural collaboration: structural slicing boards · tlora_pager/include/boards class_structural · structural_context

Open Structural Collaboration: Structural Slicing boards · tlora_pager/include/boards is to explain boards from the perspective of object collaboration: which objects are like entrances, which are like orchestration cores, and which are like adaptation/sharing boundaries; it helps to judge that the complexity comes from the distribution of responsibilities, not just the number of files.

Explain how the classes, interfaces, components or value objects in the structural slice boards/tlora_pager/include/boards share the structural responsibilities in the structural slice boards; candidates include TLoRaPagerBoard, SX1262Access, AppContext.

Dependency cluster: boards technology hotspots technical_hotspot · risk_detail

Check dependency cluster: boards technology hotspot. Whether this complexity signal will increase the cost of reading, modifying, testing or regression of boards.

This module relies on multiple external boundaries and is currently processed as a candidate technology coupling center; only the dependency directions and boundaries that have been observed by warehouse evidence are retained in the figure.

Candidates for external collaboration: boards/tlora_pager/src/tlora_pager_board.cpp Technology Hotspots technical_hotspot · risk_detail

View candidates for external collaboration: boards/tlora_pager/src/tlora_pager_board.cpp Technical Hotspots Whether this complexity signal will increase the cost of reading, modifying, testing or regression of boards.

This symbol connects multiple external objects or capabilities and may have orchestration, aggregation, or override responsibilities.

Evidence

boards/cardputerzero/board_facts.h
boards/cardputerzero/BOARD.md
boards/gat562_mesh_evb_pro.json
boards/gat562_mesh_evb_pro/board_facts.h
boards/gat562_mesh_evb_pro/BOARD.md
boards/gat562_mesh_evb_pro/include/boards/gat562_mesh_evb_pro/board_profile.h
boards/gat562_mesh_evb_pro/include/boards/gat562_mesh_evb_pro/gat562_board.h
boards/gat562_mesh_evb_pro/include/boards/gat562_mesh_evb_pro/gps_runtime.h

Problem

There are no open issues yet.

How to read the diagram

Technical complexity analysis

Relationship with business complexity

Governance Suggestions

UML/Technical Diagram

Coverage

Drill-down of semantic elements in the diagram

Evidence

Risk

Problem

Evidence

Risk

Problem

Evidence

Risk

Problem

Evidence

Risk

Problem

Evidence

Risk

Problem

Evidence

Risk

Problem

Evidence

Risk

Problem

Drill-down UML

Evidence

Problem