IRremoteESP8266 x Fabgl (VGA) Conflict

[fjmazur]

Version/revision of the library used

IRremoteESP8266 2.7.8 FAGL 0.8.0

Expected behavior

I trying to make ESP32 IR receiver (TSOP4838) work with VGA output (from Fabgl library). Installed both libraries, tested example codes, they work fine separately.

Actual behavior

When i call some drawing command with Fabgl i get random codes from the ir receiver:

59E6934E 2E556169 C52B914D 9C35FF24 54B910E F990ABC5 AD2693C6

All this data from the same pressed button on the controller. If i dont use any drawing command, the controller reads normaly.. Weird.

Example code used

include

include

include

include

include "fabgl.h"

fabgl::VGAController VGAController;

const uint16_t kRecvPin = 14; //IR

IRrecv irrecv(kRecvPin); //IR decode_results results; //IR

void setup() {

VGAController.begin(); VGAController.setResolution("\"800x300@60Hz\" 40 800 840 968 1056 300 301 303 314 -HSync -VSync DoubleScan");

Serial.begin(115200); irrecv.enableIRIn(); // Start the receiver while (!Serial) // Wait for the serial connection to be establised. delay(50); Serial.println(); Serial.print("IRrecvDemo is now running and waiting for IR message on Pin "); Serial.println(kRecvPin);

}

void loop() { if (irrecv.decode(&results)) {

serialPrintUint64(results.value, HEX);
Serial.println("");  
irrecv.resume();  // Receive the next value

}

Canvas cv(&VGAController); cv.drawRectangle(0, 0, 799, 299); }

Circuit diagram and hardware used (if applicable)

I tried to link direct to GPIOS, and using pull up resistor, same results.. Also tried another GPIO pins, same.

I have followed the steps in the Troubleshooting Guide & read the FAQ

Yes

Has this library/code previously worked as expected for you?

Separetely all work, IRremoteESP8266 library work fine, it receive codes from remote. Only when i join with the VGA library i get random codes..

Any help i will be really greatful.

Thank you

[crankyoldgit]

There are a large number of possibilities that could cause it. Without more info & data it's not easy to say what it might be.

Your current program, as it stands just prints results.value which could be anything. It could be unknown/random IR noise, or EM noise from your circuit. See: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Frequently-Asked-Questions#Occasionally_Im_getting_seemingly_random__unwanted_UNKNOWN_values_is_there_a_way_to_get_rid_of_them As you are not recording/displaying the value of results.decode_type. Which indicates what the protocol might be. Let alone what the actual contents of the message/capture might be. See https://github.com/crankyoldgit/IRremoteESP8266/blob/master/examples/IRrecvDumpV2/IRrecvDumpV2.ino for more info on displaying what is actually captured.

Without things like decode_type, rawlen, and the contents of rawbuf it's almost impossible for us to say what is going on.

You haven't even said if it receives NORMAL IR messages when both libraries are configured, so really, you haven't supplied enough data or info to allow us to help you meaningfully. i.e. We can't tell if there is some flat-out incompatibility between the libraries. e.g. This Library uses at least one of the hardware timers to perform an interrupt, and a simple interrupt on the GPIO pin to receive. It also runs on the main (first) cpu. No idea what the Fabgl library uses/requires.

[crankyoldgit]

Xref: https://github.com/fdivitto/FabGL/issues/68

[fjmazur]

Hi, thanks for answer.

Here is the IRrecvDump2 results:

NORMAL RESULT, with both libraries configured (but not using Fabgl):

Timestamp : 000020.129 Library : v2.7.8

Protocol : NEC Code : 0x1FE48B7 (32 Bits) uint16_t rawData[71] = {8966, 4518, 534, 598, 534, 596, 534, 572, 532, 600, 532, 598, 534, 572, 532, 600, 558, 1676, 536, 1706, 558, 1702, 536, 1702, 534, 1708, 556, 1702, 534, 1704, 558, 1684, 558, 572, 532, 600, 532, 1702, 534, 600, 532, 598, 536, 1702, 534, 598, 534, 572, 554, 576, 534, 1702, 534, 600, 534, 1702, 532, 1710, 556, 574, 530, 1708, 556, 1704, 536, 1702, 532, 39916, 8966, 2278, 536}; // NEC 1FE48B7 uint32_t address = 0x80; uint32_t command = 0x12; uint64_t data = 0x1FE48B7;

UNKNOWN RESULTS (Using Fabgl + IRremoteESP8266):

Timestamp : 000002.257 Library : v2.7.8

Protocol : UNKNOWN Code : 0x196373F0 (36 Bits) uint16_t rawData[71] = {9070, 4412, 636, 494, 588, 544, 612, 496, 636, 494, 588, 544, 608, 498, 634, 496, 590, 1650, 638, 1624, 784, 1454, 596, 1646, 638, 1622, 612, 1624, 594, 1646, 636, 1624, 612, 498, 658, 470, 594, 1646, 636, 494, 594, 536, 610, 1626, 596, 538, 610, 498, 632, 496, 594, 1646, 632, 496, 592, 1648, 632, 1860, 376, 502, 630, 1628, 608, 1628, 594, 1648, 628, 39822, 9026, 2214, 568}; // UNKNOWN 196373F0

Timestamp : 000005.688 Library : v2.7.8

Protocol : UNKNOWN Code : 0x122D1862 (36 Bits) uint16_t rawData[71] = {9026, 4458, 594, 540, 606, 504, 628, 498, 592, 542, 606, 502, 628, 498, 592, 540, 1034, 1204, 594, 1648, 630, 1630, 608, 1630, 594, 1648, 630, 1630, 608, 1628, 596, 1646, 630, 500, 594, 536, 610, 1626, 622, 512, 608, 500, 632, 1626, 610, 502, 630, 496, 594, 538, 608, 1628, 596, 1018, 128, 1628, 620, 1622, 632, 496, 594, 1646, 632, 1628, 612, 1626, 622, 39828, 9028, 2218, 614}; // UNKNOWN 122D1862

Timestamp : 000007.362 Library : v2.7.8

Protocol : UNKNOWN Code : 0x34118CB9 (36 Bits) uint16_t rawData[71] = {9032, 4454, 598, 536, 612, 496, 636, 492, 596, 536, 614, 974, 158, 492, 622, 510, 612, 1624, 624, 1618, 636, 1624, 616, 1622, 598, 1644, 638, 1622, 1310, 928, 622, 1620, 636, 494, 596, 534, 616, 1622, 596, 536, 614, 494, 634, 1624, 614, 496, 636, 492, 624, 508, 1034, 1202, 596, 536, 616, 1622, 622, 1620, 636, 492, 598, 1644, 636, 1622, 616, 1622, 624, 39826, 9028, 2218, 614}; // UNKNOWN 34118CB9

That help?

Thank you

[crankyoldgit]

That help?

Yes, it does.

So the data you've collected indicates to me, that the device is getting the NEC message via the IR demodulator correctly. However, there is significant processing load on the ESP as to slow down/delay handing the interrupts produced by the IR hardware. In short, having the VGA library and the IR library running on the same CPU is too much for the poor ESP32.

The IR library is fairly light (cpu-wise) on the interrupt receiving side, but it is massively influenced by any delays to servicing the interrupts. Any delays mean the timing values get skewed. The longer it takes before it can service the GPIO interrupt, the bigger the error in capture timing data.

You've got a few options as I see it:

1. Increase the IR decoding tolerance value. See IRrecv::setTolerance(percent) The default tolerance (kTolerance) is 25 (%). You'll need to experiment with what values work best for you.

2. (Recommended solution) Try to split the VGA and IR tasks onto separate processors on the ESP32, if possible. See the FAQ on this: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Frequently-Asked-Questions#Some_other_library_eg_Bluetooth_is_interfering_with_IRsend_What_can_I_do_ESP32

3. Very left-field and probably won't have any effect. Try moving the declaration of the IRrecv irrecv(kRecvPin); before fabgl::VGAController VGAController; and irrecv.enableIRIn(); // Start the receiver before VGAController.begin();. i.e. IR stuff before the VGA. Just on the off chance you're running out of IRAM and that is causing it (IR) to run slow. I doubt this will work, but it's worth a try.

Good luck!

[crankyoldgit]

Oh, I probably didn't make it clear, the problem is the added delays causes the timing to be larger than expected for the given protocols to match correctly. i.e. The ESP sees a message that is out of spec for a protocol. That delay is due to the ESP CPU being too busy to handle the GPIO interrupt in a timely-enough manor. Option 1) is try to be more relaxed about the timings (which can have it's own problems) and Option 2) is try to stop the CPU being as busy.

[crankyoldgit]

Did you have any luck with those suggestions/approaches?

[fjmazur]

Hello,

After many testing and fails i maked it work! I used two ESP32 (with serial transfer between then), i can't manage to make tasks work on separated ESP32 cores..

After that, the IR readings are really slow, took about 5s to apear on the VGA screen! I changed to BItluni VGA ESP32Lib and now its fine! Fast and reliable. Not the most elegant solution, but worked for me..

Next step is to make work with only one ESP32..

Thank you for all

[crankyoldgit]

FYI This may have been fixed with #1351