Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(GPIO)!: Complete rework of GPIO handler & Add additional features for GPIOs #154

Merged
merged 127 commits into from
Apr 16, 2024

Conversation

Slider0007
Copy link
Owner

@Slider0007 Slider0007 commented Apr 12, 2024

⚠️ BREAKING CHANGES

  1. Complete refactor of GPIO component
    --> Check parameter and API documentation (GPIO Parameter, GPIO REST API, GPIO MQTT API)

⚠️ Previous configuration cannot be migrated and needs to be reconfigured again after update!


  1. Hardware specific / Board specific GPIO WebUI visualization (Show spare GPIOs depended on board config in firmware (/includes/defines.h) instead of static declaration)
    • Show board specific spare GPIO pins without WebUI coding, only defintion in firmware -> Preparation to support further hardware with various hardware capabilities in an easy way
    • Visualize only GPIO mode related parameter set to make configuration more user friendly
      Examples:
      Flashlight Default, e.g. for board ESP32CAM -> GPIO4 (onboard flashlight, PWM controlled)
      image
      Flashlight smartLED, e.g. external or internal WS2812 intelligent LEDs
      image
  2. Add more functionality / add more flexibility of GPIO usage
    • Implemented GPIO modes (see also GPIO Mode Docu)
      Input Option Direction Description
      input input Use as input, internal pullup and pulldown resistor is disabled
      input pullup input Use as input, internal pullup resistor is enabled
      input pulldown input Use as input, internal pulldown resistor is enabled
      output output Use as output (digital states: 0, 1)
      -> controlable by REST API and/or MQTT
      output pwm output Use as output which controlable by PWM duty (duty cycle: 0 .. Max duty resolution depending on PWM frequency)
      -> controlable by REST API and/or MQTT
      flashlight default output This mode represents the board's default flashlight configuration, e.g. Default for board ESP32CAM -> GPIO4 as PWM controlled output. This mode is only visible on respective GPIO which is defined as default in firmware
      flashlight pwm output Use for flashlight operation with regular LEDs (PWM controlled intensity)
      flashlight smartled output Use for flashlight operation with smartLEDs
      flashlight digital output Use for flashlight opertation with regular LEDs (digital states: 0, 1)
      trigger cycle start input
      (pullup enabled)
      Trigger a cycle start
    • Every pin can be configured with all modes (be aware of system occupied pins in expert view -> default usage is mentioned in red)
    • Allow complete free configuration of even multiple flashlight mode combinations (more or less independend of GPIO pin and quantity)
    • One board specific default is named as flashlight default. This one is automatically derived from board definition in firmware.
      • Up to 8 smartLED GPIOs
      • Up to 8 PWM controlable outputs (Flashlight PWM outputs + Generic GPIO PWM outputs)
      • Up to 3 independent PWM duty frequencies can be configured (Flashlight PWM outputs + Generic GPIO PWM outputs)
    • Add GPIO specific flashlight intensity correction factor to align different flashlight intensities (only needed if more than one flashlight is connected)
    • Add debounce function for all GPIO input modes (only if captured by interrupt)
    • Rename of GPIOX Use Interrupt to GPIO Capture Mode. This parameter is only visible for input GPIO modes
    • Remove PWM Duty Cycle Resolution and replace with GPIO PWM Frequency. It makes more sense to have frequency adjustable. Max duty resolution is derived automatically from choosen frequency.
    • MQTT (if enabled):
      • All GPIO modes: Publish actual pin state (and pwm duty)
      • GPIO output / GPIO output PWM: Pin state can be controlled (state and/or pwm duty)
    • REST API (if enabled):
      • All GPIO modes: Request actual pin state (and pwm duty)
      • GPIO output / GPIO output PWM: Pin state can be controlled (state and/or pwm duty)
  3. Update smartleds component (https://github.com/RoboticsBrno/SmartLeds/releases/tag/v3.1.2) and add as esp-idf component

feat(webui): Add more content to system info page
refactor(REST API): Provide content of '/heap' as JSON + HTML
refactor(REST API)!: Remove handler starttime (use /info?type=DeviceStartTime)
refactor(REST API)!: Remove handler uptime  (use /info?type=Uptime)
refactor(REST API)!: Remove handler rssi (use /info?type=Uptime)
refactor(REST API)!: Remove handler rssi (use '/info?type=WlanRSSI')
refactor(REST API)!: Remove handler cputemp (use '/info?type=ChipTemp')
refactor(REST API)!: Remove handler sysinfo (use '/info' + '/heap')
refactor(REST API): Align time format (ISO)
Add 'datalogging sdcard' to '/info'
feat(REST API): Add legacy API by query parameter 'type'
refactor(REST API): Remove chip temp from 'overview' page. It's accessable from 'system' -> 'info' page
Use '/process_data?type=ProcessState'
Use '/process_data?type=ProcessError
Keeping same functionality, but with reduced APIs to save some RAM
Keeping same functionality, but with reduced APIs to save RAM
Use /process_data API instead

refactor(REST API): Merge parts of /value to /process_data
Use /process_data API instead

refactor(REST API): Rename remaining function of /value to /recognition_details
@Slider0007 Slider0007 changed the title feat(GPIO)!: Complete rework of GPIO handler & Additional features to GPIOs feat(GPIO)!: Complete rework of GPIO handler & Add additional features for GPIOs Apr 12, 2024
@Slider0007 Slider0007 merged commit 026c650 into develop Apr 16, 2024
@Slider0007 Slider0007 deleted the refactor-gpio branch April 16, 2024 09:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant