TTGO T-Display ESP32 variant

[deftdawg]

Updated:

• TTGO T-Display ESP32 which will use an MCP2515 with remapped pins -> MOSI (33), MISO (32 via Voltage divider), CS (25), SCK (26)
• Display layout to shows uptime, RX, TX, FPS, Listening/Active, and NAG status
• Display brightness (default : 50%) and timeout settings (default: 60s from button/wake event)
• Button mappings GPIO0 -> Active/Listen Toggle; GPIO35 -> Display sleep/wake
• Have TX Count show ALL messages including Anti-Nag that are sent to the bus
• Split CAN Bus detection into Chip detection (SPI ack) and Signal detection (CAN H/L signal)
  • Periodically attempt to re-init every 30s if Chip is detected, but CAN signal is not.
• Error count is TX errors attempting to send to the CAN bus, not CRC errors
• Update handle_root (web server) to chunk response to improve reliability
• Translate Chinese messages in Web UI

TODO:

• Document TTGO T-Display ESP32 + MCP2515 w/ MISO pin voltage divider hardware setup
• FIXME: Add fsd_apply_hw_version(&g_state, TeslaHW_HW3); after fsd_state_init on line 498 to Force HW3

[deftdawg]

First successful test drive today with 2016 MX HW3 (fsd_apply_hw_version(&g_state, TeslaHW_HW3); applied) w/ FSD.

• Worked wonderfully once I got everything setup, took me a couple of tries to figure out how to wire everything and a couple of flash builds to get everything polished (i.e. TX was always 0 because Anti-Nag TX wasn't counted)
• Anti-Nag worked, though the starting spoof torque might be too low? (Nag flashing made it to 2 seconds)
• Red Hands Nags (when driving past orange construction barrels) still make a loud alert sadly. 😞
• Also seems there is Anti-Nag TX even when FSD is not active (maybe because of the force HW3?)

[hypery11]

@deftdawg Outstanding work — TTGO T-Display variant, successful test drive on 2016 MX HW3 with FSD, anti-nag working, AND the Force HW3 workaround we discussed in #38. This is exactly the kind of multi-front contribution that moves the project.

A few questions before review:

1. Does the TTGO T-Display path use a compile flag (e.g., -D BOARD_TTGO_T_DISPLAY) to switch between TWAI and MCP2515 drivers, so existing M5Stack TWAI builds aren't impacted?
2. Is the display code optional (behind a build env) or always-on?
3. On the Force HW3 — would you prefer to include a web dashboard toggle for it in this PR (5-min addition: checkbox + state field + apply on change), or split it out so PR TTGO T-Display ESP32 variant #62 stays focused on the hardware port?

On the test drive feedback:

• "Starting spoof torque might be too low (nag made it to 2 seconds)" — confirmed observation. The organic torque variation in v2.8+ starts at 1.00–2.40 Nm with grip pulses to 3.10–3.30 Nm every 5–9s. If Red Hands Nag is escalating to the 2-sec yellow level on your car, we may need to raise the baseline minimum. Want to capture this as a separate issue so we can tune it?
• "TX was always 0 because Anti-Nag TX wasn't counted" — solid fix. Glad you caught that.

Will read through the diff today.

[hypery11]

Reviewed the diff. Overall high-quality work — clean compile-flag isolation, MCP2515 driver hardening, modular display code, and the tx_count vs frames_modified split is exactly the right fix.

What I like:

• BOARD_TTGO_DISPLAY flag is properly threaded — no impact on M5Stack TWAI builds.
• Mcp2515Driver::hardwarePresent() + chip detection via setBitrate failure is a clean signal-of-life check that other boards will benefit from too. Worth considering whether to surface that in the web dashboard as a "no CAN chip detected" warning, but that can be follow-up.
• 30 s CAN_REINIT_INTERVAL_MS for periodic re-init is a smart hot-plug recovery path.
• Splitting frames_modified (autopilot patches only) from tx_count (all TX) is the correct fix for the "TX always 0" complaint.
• display_enabled / brightness / timeout saved in NVS — persistence is right.
• Voltage-divider warning in the MISO pin comment is exactly where someone wiring this will look.

On the Force HW3 workaround:

I see you applied fsd_apply_hw_version(&g_state, TeslaHW_HW3) locally during your test drive but it's not in the PR diff. Two paths:

1. Include in this PR — add a force_hw3 bool to FSDState, a checkbox in web_dashboard.cpp, NVS persistence in prefs.cpp, and a one-line apply in main.cpp setup. ~30 lines total across 4 files. PR stays focused on hardware + the natural home for the toggle.
2. Split out — I'll add the web toggle as a separate commit after this PR merges. Keeps PR TTGO T-Display ESP32 variant #62 strictly hardware-port.

Either is fine — your call.

Doc suggestion:

Could you add a TTGO T-Display section to esp32/README.md? Wiring (which MCP2515 pin → which ESP32 pin), the MISO voltage-divider note, and the button mappings would help next testers. Doesn't have to be elaborate.

Other than the Force HW3 decision and the doc add, this is ready to merge from my side. Let me know which path on Force HW3 and I'll process accordingly.

[deftdawg]

• Include in this PR — add a force_hw3 bool to FSDState, a checkbox in web_dashboard.cpp, NVS persistence in prefs.cpp, and a one-line apply in main.cpp setup. ~30 lines total across 4 files. PR stays focused on hardware + the natural home for the toggle.

• Split out — I'll add the web toggle as a separate commit after this PR merges. Keeps PR TTGO T-Display ESP32 variant TTGO T-Display ESP32 variant #62 strictly hardware-port.

I don't really have time to tackle FSDState stuff in a nice way, so probably best to split that into another PR for now.

I've reordered the pins to make diagramming a bit easier in Fritzing, but haven't had a chance to finish the diagram or test drive with the new flashed. You can merge the PR now or wait a couple of days for me to test and add a pretty diagram, but I think it's pretty well done. 🚀

[hypery11]

@deftdawg Sounds good — splitting out Force HW3 makes sense. I'll track it in #38 and pick it up after PR #62 lands; no extra work on your end.

On the merge timing: I'm happy to wait the few days for your Fritzing diagram — having the wiring diagram in the doc makes the next person's onboarding significantly easier, and it lives forever in the repo. Take your time, and ping me here when you've test-driven the reordered pin layout. No rush.