Bridge

Path: 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: Base class for all components
WString: String manipulation
xtypes: Type definitions
enums: Enumeration definitions
macros: Macro definitions
Vector: Container for storing component information
Streaming: Stream output utilities

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.

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.

3.5 KiB Raw Blame History