firmware-base/docs/Component.md

title	description	keywords
Component Class	Base class for all firmware components with standard behavior and lifecycle management	component, base class, framework, firmware, modbus, ESP32

Component

Path: src/Component.h

Revision History:

• Initial documentation

The Component class serves as the foundational building block for all firmware components in the system. It provides standardized interfaces for component initialization, execution, and communication via Modbus and other protocols. It's designed to work within an industrial application environment using Modbus-485.

Requirements

• No specific hardware pins required as this is a base class
• Software dependencies:
  • Arduino framework
  • WString.h
  • ArduinoLog.h
  • Vector.h

Features

• Standardized component lifecycle management (setup, loop)
• Configurable execution flags for controlling component behavior
• Modbus integration capabilities for industrial communication
• Component ownership hierarchy for resource management
• Component type categorization for organizational purposes
• Support for ESP32 platform

Dependencies

• WString.h
• ArduinoLog.h
• Vector.h
• enums.h
• constants.h
• error_codes.h
• macros.h
• xtypes.h

graph TD
    Component --> WString
    Component --> ArduinoLog
    Component --> Vector
    Component --> enums
    Component --> constants
    Component --> error_codes
    Component --> macros
    Component --> xtypes
    Bridge --> Component
    ModbusTCP --> Component
    ModbusBlockView --> Component
    MB_Registers --> Component
    RS485 --> Component

Behaviour

The Component class follows a standard lifecycle pattern controlled by flags:

stateDiagram-v2
    Start --> Construct
    Construct --> Setup: E_OF_SETUP flag
    Setup --> Loop: E_OF_LOOP flag
    Loop --> Loop: Main program loop
    Loop --> Destruct: Program ends
    Setup --> Destruct: No E_OF_LOOP flag
    Construct --> Disabled: E_OF_DISABLED flag
    Disabled --> Destruct
    Destruct --> End

TODOs

Performance

• Consider memory optimization for resource-constrained ESP32 platforms
• Review constructor implementations for redundant operations
• Optimize Modbus-485 communication for industrial applications

Security

• Implement validation for component IDs to prevent conflicts
• Consider access control mechanisms for critical components
• Ensure secure Modbus communication in industrial environments

Compliance

• Ensure compliance with MISRA C++ coding standards
• Maintain compatibility with Arduino's component model
• Verify compliance with industrial Modbus protocol standards

Recommendations

• Follow the component ownership hierarchy for proper resource management
• Use the appropriate flags to control component lifecycle
• Implement specific component types by extending this base class
• Ensure all derived components properly initialize the base class
• When using with ESP32, consider platform-specific optimizations

Example

The Component class is typically extended rather than used directly. Here's an example of how a derived component might be constructed and mounted:

#ifdef PIN_LED_FEEDBACK_0
  ledFeedback_0 = new LEDFeedback(
      this,                  // owner
      PIN_LED_FEEDBACK_0,    // pin
      LED_PIXEL_COUNT_0,     // pixelCount
      ID_LED_FEEDBACK_0,     // id
      LED_FEEDBACK_0_MB_ADDR // modbusAddress
  );
  if (ledFeedback_0)
  {
    components.push_back(ledFeedback_0);
    Log.infoln(F("LEDFeedback_0 initialized. Pin:%d, Count:%d, ID:%d, MB:%d"),
               PIN_LED_FEEDBACK_0, LED_PIXEL_COUNT_0,
               ID_LED_FEEDBACK_0, LED_FEEDBACK_0_MB_ADDR);
  }
  else
  {
    Log.errorln(F("LEDFeedback_0 initialization failed."));
  }
#endif

References

• Component flags are defined in the OBJECT_RUN_FLAGS enum in enums.h
• Component types are defined in the COMPONENT_TYPE enum in enums.h
• Error codes are defined in error_codes.h
• Default component configuration is specified with COMPONENT_DEFAULT