99 lines
3.5 KiB
Markdown
99 lines
3.5 KiB
Markdown
# Bridge
|
|
|
|
**Path**: [src/modbus/Bridge.h](../../../src/modbus/Bridge.h)
|
|
|
|
**Revision History**:
|
|
- Initial documentation
|
|
|
|
A Bridge component that enables inter-component messaging and remote method invocation in an ESP32-based system. It allows components to register member functions that can be called via a message passing mechanism, typically triggered by Modbus commands.
|
|
|
|
## REQUIREMENTS
|
|
|
|
- No specific hardware pins required
|
|
- Software dependencies for messaging and component management
|
|
|
|
## PROVIDES
|
|
|
|
- `SComponentInfo`: A structure that stores information about registered component methods
|
|
- Stores component key, instance pointer, method name, and function pointer
|
|
- `Bridge`: Main class that manages component method registration and message handling
|
|
- Inherits from `Component` base class
|
|
|
|
## FEATURES
|
|
|
|
- Register component member functions for remote invocation
|
|
- Message routing between components
|
|
- Method lookup by component ID and method name
|
|
- Debug support for listing registered methods
|
|
- Support for component discovery for Modbus management
|
|
|
|
## DEPENDENCIES
|
|
|
|
- [Component](./Component.md): Base class for all components
|
|
- [WString](https://github.com/espressif/arduino-esp32): String manipulation
|
|
- [xtypes](./xtypes.md): Type definitions
|
|
- [enums](./enums.md): Enumeration definitions
|
|
- [macros](./macros.md): Macro definitions
|
|
- [Vector](./Vector.md): Container for storing component information
|
|
- [Streaming](./Streaming.md): Stream output utilities
|
|
|
|
```mermaid
|
|
graph TD
|
|
Bridge --> Component
|
|
Bridge --> WString
|
|
Bridge --> xtypes
|
|
Bridge --> enums
|
|
Bridge --> macros
|
|
Bridge --> Vector
|
|
Bridge --> Streaming
|
|
```
|
|
|
|
## BEHAVIOUR
|
|
|
|
The Bridge acts as a message router between components. It maintains a registry of component methods and handles method invocation based on message parameters.
|
|
|
|
```mermaid
|
|
sequenceDiagram
|
|
participant Caller
|
|
participant Bridge
|
|
participant Component
|
|
|
|
Caller->>Bridge: onMessage(id, verb, flags, user, src)
|
|
alt EC_METHOD verb
|
|
Bridge->>Bridge: Parse method parameters
|
|
Bridge->>Bridge: hasMethod(id, methodName)
|
|
alt Method found
|
|
Bridge->>Component: Invoke method
|
|
Component-->>Bridge: Return result
|
|
Bridge-->>Caller: Return result
|
|
else Method not found
|
|
Bridge-->>Caller: Return E_NOT_FOUND
|
|
end
|
|
else Other verbs
|
|
Bridge-->>Caller: Return E_OK
|
|
end
|
|
```
|
|
|
|
## TODOS
|
|
|
|
### PERFORMANCE
|
|
|
|
- The current implementation uses dynamic memory allocation for component registration which could lead to heap fragmentation. Consider using a fixed-size pool for `SComponentInfo` objects.
|
|
- Message parsing could be optimized for cases with large numbers of registered components.
|
|
|
|
### SECURITY
|
|
|
|
- There is no authentication mechanism for method invocation. Consider adding a permission system.
|
|
- Method invocation through Modbus should be validated to prevent buffer overflows and other security issues.
|
|
|
|
### COMPLIANCE
|
|
|
|
- Ensure proper memory management to comply with embedded system best practices.
|
|
- Test for compliance with industrial communication standards when used with Modbus.
|
|
|
|
### RECOMMENDATIONS
|
|
|
|
- Use descriptive method names and consistent component IDs to make debugging easier.
|
|
- Keep registered method count below the `MAX_COMPONENTS` limit (defined in configuration).
|
|
- When adding new components, always register their methods during initialization.
|
|
- Consider implementing an unregister mechanism for dynamically loaded/unloaded components. |