Add heltec v4-tft code.

[Quency-D]

The previous commit #1118 for V4-tft enabled macros related to the env sensor, causing the OLED version to freeze at startup. Testing revealed this was due to issues with I2C usage, which has been fixed in #1456. Therefore, the v4-tft code has been resubmitted.

[Socalix]

@Quency-D Do you know if this PR could be impacting power consumption of the board?
@towerviewcams noted a difference with the new 1.12.0 builds in the PR-1398 for v4 RX register patch, and the one change I see between old and new that's related to v4 board and power is this display PR.

This line specifically is different from all other boards (variants/heltec_v4/target.cpp - Line 27):
https://github.com/meshcore-dev/MeshCore/pull/1486/changes#diff-cb585c120ca24d200c69942d855dcb4f7836fd5b015585f7bedcab36dba25a1bR27

Could it be that the display keeps drawing power with this PR?

[Quency-D]

@Quency-D Do you know if this PR could be impacting power consumption of the board? @towerviewcams noted a difference with the new 1.12.0 builds in the PR-1398 for v4 RX register patch, and the one change I see between old and new that's related to v4 board and power is this display PR.

This line specifically is different from all other boards (variants/heltec_v4/target.cpp - Line 27): https://github.com/meshcore-dev/MeshCore/pull/1486/changes#diff-cb585c120ca24d200c69942d855dcb4f7836fd5b015585f7bedcab36dba25a1bR27

Could it be that the display keeps drawing power with this PR?

In theory, it shouldn't affect power consumption, but just in case, you could explain how you specifically tested the power consumption so we can test it ourselves, or you could measure the state of the power control pin PIN_VEXT_EN=36 at low power consumption to see if it's correct.

[IoTThinks]

@Quency-D For Heltec v4, VEXT needs to be HIGH or LOW to power on the OLED and pepherials?

So this should be -D PIN_VEXT_EN_ACTIVE=HIGH instead of LOW.
However, when we set -D PIN_VEXT_EN_ACTIVE=HIGH, the OLED is always off.
If we set -D PIN_VEXT_EN_ACTIVE=LOW, the OLED keeps drawing power forever even when the screen is off.

You may use a power meter or usb power meter to test.

[Quency-D]

HI @IoTThinks , According to the schematic of v4.2, the control pin needs to be pulled low to enable the LDO and power the subsequent devices.
Could you please send me a link to the manual you're looking at? I'll have my colleague update it.

[IoTThinks]

@Quency-D Here you go
https://resource.heltec.cn/download/WiFi_LoRa_32_V4/datasheet/WiFi_LoRa_32_V4.2.0.pdf

Page 12.

[IoTThinks]

Only when I set pin to LOW , the power is back to normal (50mA).
Seems LOW = vext off.

[Quency-D]

Only when I set pin to LOW , the power is back to normal (50mA). Seems LOW = vext off.

Thank you very much. There might be a problem with this part of the logic. Let's verify it.

[towerviewcams]

@Socalix sent me a test firm on the 1.12 firmware with the v4 display PR fixed and it works. back to 11.2mA
@IoTThinks I think you have verified this also?

I'll let him share the firm when ready.

[IoTThinks]

This hot fix works.
You may consider it as a start as I'm not so familiar with the code for the OLED screen.

 void release() {
    if (_claims == 0) {
      digitalWrite(_pin, !_active);
    } else {
      _claims--;
    }
  }

[Socalix]

@Socalix sent me a test firm on the 1.12 firmware with the v4 display PR fixed and it works. back to 11.2mA @IoTThinks I think you have verified this also?

I'll let him share the firm when ready.

My quick fix for confirming this display PR is the cause for higher power consumption was simply turning off the DISPLAY_CLASS flag. I figured since it's for a repeater, @towerviewcams wouldn't mind it being off anyway. 😄

I think @IoTThinks is on the right path for a more global fix.

[towerviewcams]

@Socalix yes it worked and I dont mind the display off. We only use the display basal for the wifi antenna for OTA. All is working well until @IoTThinks has the professional fix.

Thanks again for doing that, its playing so nicely at a high level repeater site.