Repository navigation
feature: support 2.1" gc9b72 display - #89
Open
lmoiseichuk wants to merge 4 commits into
Open
lmoiseichuk wants to merge 4 commits into
lmoiseichuk wants to merge 4 commits into
Conversation
Every length in radar_theme.h was a constexpr tuned for a 240x240 panel. They are now variables that initMetrics() computes from tft.width() and tft.height(), scaled against a 240 reference, so a different panel gets the same design rather than a second set of hand-tuned constants. Values that are not lengths -- the ring count, the track horizon in seconds, the reference range in km, plain ratios -- stay constexpr. The k-prefixed names and their storage in the header keep the shape the colours in this file have always had, so no call site changes. status_screens.cpp gets the same treatment: centre, spinner radius, text panel width, line gaps and VLW point sizes all scale. No behaviour change on the 240x240 build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Selected with -DPLANE_RADAR_PANEL_GC9B72, env supermini_gc9b72. The default supermini env and the GC9A01 wiring are untouched. LovyanGFX gained Panel_GC9B72 in 1.2.28, so the lib_deps floor moves up from ^1.2.7. The panel needs a backlight line, which the 1.28" modules tie on at the module: it sits on GPIO5 through Light_PWM so it can be dimmed if the 3V3 rail sags under WiFi transmit -- a 2.1" backlight draws several times what the 1.28" one does. LEDC channel 0, because the C3 has only six channels and the 7 used in most LovyanGFX examples is out of range on it. The 360x360 frame buffer is 259,200 B at 16 bits, which does not fit on an ESP32-C3 once WiFi is up -- measured, 188,404 B largest free block. The frame sprite now walks a depth ladder and lands on 8-bit RGB332 at 129,600 B. There is deliberately no 4bpp rung: LovyanGFX has no RGB-to-palette-index converter, so a blended write to a palette sprite goes through copy_bit_affine and corrupts every antialiased primitive we draw, fillSmoothCircle and drawWideLine among them. RGB332 keeps them. Unlike the GC9A01 modules this panel must not be inverted; its init sequence does not set inversion itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both were hard-coded off. They are now per-panel pins in config.h, defaulting to -1 on the GC9A01 where neither is broken out. kDisplayPinMiso feeds LovyanGFX's bus config. It makes the panel readable, which the antialiased primitives need on the direct-to-panel path taken when no frame sprite fits, and it silences the "SPI Does not have default pins on ESP32C3" error that -1 provoked at every boot. kDisplayPinTe is polled by displayWaitForFrameStart() before each pushSprite. No SPI panel in LovyanGFX consumes TE -- getScanLine() returns -1 for all of them -- so the edge is caught here instead. A full 360x360 frame is 259,200 B on the wire, roughly 104 ms at 20 MHz, which is long enough to tear without it. The wait gives up after 25 ms so a miswired line cannot stall the main loop. Also drops the ESP32-C6 material from the README. It was documenting hardware that is not supported yet and needs a PlatformIO platform this project does not use; the wiring table is now the one board that works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Brings in upstream's ADS-B pipeline, dead reckoning at 4 Hz, the TLS fix, the portal re-render and the RGB332 frame buffer. One conflict, in ensureFrameSprite(): this branch tried 16bpp first and fell back to 8bpp; upstream (MatixYo#100) now always uses RGB332 to free the frame's 57 KB at 240x240. Resolved in upstream's favour -- one byte a pixel on every panel, which at 360x360 is 129,600 B instead of 259,200 -- keeping this branch's fallback to drawing straight to the panel when even that does not fit, and its note on why no palette depth is tried. Both supermini and supermini_gc9b72 build. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DL3fMjXoiVk9VGMHmQkfyW
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tried to use this excellent radar but too little display for me, so a little changes to make side option to support larger screen, focusing on 4bpp mode but Claude hints about 8bpp which seems more then enough:
esp32c3 handles ~130KB buffer fine.