Xinyuan-LilyGO / TTGO_TWatch_Library

MIT License
902 stars 289 forks source link

T-WATCH v.2 IRremote and the Screen lights off. #171

Closed Marshall100W closed 1 year ago

Marshall100W commented 2 years ago

T-WATCH v.2 IRremote and the Screen lights off.

Hi to everyone :-)

I have this issue sending an IR code. Everytime I send an IR, the screen lights off.

Here the code:

define LILYGO_WATCH_2020_V2

include

include

TTGOClass *ttgo;

uint16_t sAddress = 0x0; uint8_t sCommand = 0xC; uint8_t sRepeats = 0;

void setup() { Serial.begin(115200); IrSender.begin(2); ttgo = TTGOClass::getWatch(); ttgo->begin(); ttgo->openBL(); ttgo->setBrightness(50); ttgo->tft->fillScreen(TFT_BLACK); ttgo->tft->setTextColor(TFT_GREEN, TFT_BLACK); ttgo->tft->setCursor (0, 0); ttgo->tft->drawString("UP THE IRONS!", 0, 0, 2); delay(2000); }

void loop() { IrSender.sendRC6(sAddress, sCommand, sRepeats); delay(1000); }

Could someone help me?

Thank you very much.

codefaux commented 1 year ago

Actually, I just found out this is related to another currently known bug -- in this case, it's apparently a relatively easy fix.

First -- we need to know which IR library you're using. You've noted the header file name, but this is ambiguous.

EDIT: Some corrections.

Apparently per discussion adjacent LEDC channels use the same timer, or conflict in some way.

In any case -- your IR library uses, by default, the same LEDC channel or timer which the backlight's driver uses in TTGO_TWatch_Library -- which is also the same LEDC channel or timer as is used by the vibrator motor, which is why using the vibrator motor causes the backlight to dim and typically fail to return to full brightness.

TTGO_TWatch_Library uses LEDC channel 0 for Backlight, so we avoid 0/1. PR #146 splits the motor's channel to LEDC channel 4, so you may wish to avoid channel 4/5 to be respectful of this potential overlap.

Below is speculation. I'm being verbose because I'm making guesses, explaining why I think this way so people can identify potential mistakes. This is not historical experience, this is limited-experience speculation. Please consider that I may be incorrect. Please correct me if I am. Please be gentle.

My first thought with the IRremote.hpp header would be the Arduino-IRremote library. That library claims to not use a timer channel on ESP32 unless asked to, when told which platform it is using.

From Arduino-IRremote repo's IRTimer.hpp

#if defined(SEND_PWM_BY_TIMER) && ( (defined(ESP32) || defined(ARDUINO_ARCH_RP2040) || defined(PARTICLE)) || defined(ARDUINO_ARCH_MBED) )
#define SEND_PWM_DOES_NOT_USE_RECEIVE_TIMER // Receive timer and send generation are independent, so it is recommended to always define SEND_PWM_BY_TIMER
#endif

The note indicates it is recommended to ask for send to use a timer, which implies no timer by default, when it knows it's on ESP32.

Below further;

/**********************************************************
 * ESP32 boards - can use any pin for send PWM
 * Receive timer and send generation are independent,
 * so it is recommended to always define SEND_PWM_BY_TIMER
 **********************************************************/

Further implication that a timer is not enabled unless requested, when the library is configured correctly. It is also recommended for better signal generation, apparently. Timer and LEDC channel seem to be used indiscriminately to refer to the same object within the ESP32 context.

Below that, we see the important line, but before I get to that part -- this ONLY applies if you're using the library I assume you are.

#  if !defined(SEND_AND_RECEIVE_TIMER_LEDC_CHANNEL)
#define SEND_AND_RECEIVE_TIMER_LEDC_CHANNEL 0 // The channel used for PWM 0 to 7 are high speed PWM channels
#  endif

SO. To fix your code -- IF I'm right -- you need to inform the library which platform it's on, ask for a timer for better signal generation, and tell it to use a different LEDC channel.

ABOVE the #include <IRremote.hpp> line you should try adding;

#define ESP32
#define SEND_PWM_BY_TIMER
#define SEND_AND_RECEIVE_TIMER_LEDC_CHANNEL 2 // or 6?

According to Espressif LED Control documentation there are 16 channels. According to the comments from Arduino-IRremote library, channels 0-7 are "high speed PWM" -- according to the same Espressif document, the difference between High-speed and Low-speed mode is that Low-speed channels will have a momentary glitch when changing configuration, whereas High-speed channels do not. I'm not certain if this would effect IR transmission given the manner in which consumer IR remote protocols like RC5 modulate, but it's probably safer to use channels 0~7 just in case. And as I mentioned above, adjacent channels seem to use the same internal timer.

lewisxhe commented 1 year ago

Yes, you should note that the LEDC channel used cannot be the same as the screen