Skip to content

Conversation

brentru
Copy link
Member

@brentru brentru commented Oct 6, 2025

This pull request adds support for TFT and E-Ink Displays to the WipperSnapper firmware.

Major Changes:

  • Adds display component to WipperSnapper
    • display/controller - Handles routing and management of Protobuf messages between App and Hardware instances
    • display/hardware - Handles multiple types of display drivers
  • Adds Display Drivers - display/drivers/
    • display/drivers/dispDrvBase.h - Abstract base class for display drivers, provides a common interface for all display drivers,
    • display/drivers/dispDrvSt7789.h - Driver for ST7789-based TFT displays, such as Adafruit FunHouse and Adafruit Feather ESP32x TFT
    • display/drivers/dispDrvThinkInkGrayscale4Eaamfgn.h - Driver for ThinkInk 2.9" Grayscale 4-level EAAMFGN display (present on the 2025 version of the Adafruit MagTag)
    • display/drivers/dispDrvThinkInkGrayscale4T5.h - Driver for ThinkInk 2.9" Grayscale 4-level T5 display (present on the pre-2025 version of the Adafruit MagTag)
  • Removes LVGL build dependencies for FunHouse
  • Removes prior LVGL-based display component work from WipperSnapper including prints, structs, classes and icons

Resolves:
#792

@brentru brentru requested a review from tyeth October 6, 2025 20:46
WS.feedWDT();

// Process display controller events, if initialized
WS._displayController->update(getRSSI(), WS._mqtt->connected());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mqtt->connected didn't reliably return false when exploring previous issues, it might be worth rethinking or ANDing with wifi status connected.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a reliable way to check it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure that we do, and we call both runNetFSM and ping earlier in this method so we should be as correct in status as possible (mqtt-connected should be correct, IIRC it resets on failed ping / forced reconnect).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's my thinking, if it failed, NetFSM would have picked it up so by the time it gets to this call it would return false.

@tyeth
Copy link
Member

tyeth commented Oct 7, 2025

Looks good @brentru, just some minor things.
Also, I hadn't appreciated when writing the runNetFSM comments that any MQTT command/publish also counts for keep alive, so we do not need to ping after 5seconds if a recent publish happened (maybe sub ack too?). We could instead reset the last ping time after any successful publish.

@brentru brentru requested a review from tyeth October 7, 2025 17:23
Copy link
Member

@tyeth tyeth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

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.

2 participants