Compilation failures after updating to v3.x ESP32 Arduino Core

[Roger-random]

Symptom:

After updating to v3.x ESP32 Arduino Core, the first compilation error will be:

ESP_8_BIT_composite.cpp:45:55: error: invalid conversion from 'const volatile void*' to 'volatile void*' [-fpermissive]

HOWEVER, this is not the core issue, it's just the first breaking change to cause a error. (Default compiler flags changed in v2.x to v3.x.)

Downstream are deeper problems with this library's dependency on deprecated ESP32 legacy DAC driver, which has been (or will soon be) removed. Replacement DAC driver does not expose the same functionality.

Reference:

Espressif's documentation on breaking changes: https://docs.espressif.com/projects/arduino-esp32/en/latest/migration_guides/2.x_to_3.0.html

Workaround:

The current workaround is to downgrade ESP32 Arduino Core to an earlier version in the v2.x lineage. I understand this is not a satisfactory long-term solution.

Why did Espressif do this?

The following is my observation/hypothesis/guess and not from Espressif.

Espressif seized upon the fame of the successful "ESP32" name and has released many variants. Some are VERY different from the original chip, but they are all supported by ESP-IDF which ESP32 Arduino Core is built upon. ESP-IDF has the job of keeping things in sync across the entire ESP32 library, so software developers won't have to worry about details of hardware differences between variants.

Unfortunately, this means ESP-IDF is restricted to the subset supported by all ESP variations on a peripheral. Creative hacks like the ESP_8_BIT composite video code (which this library is built from) depended on features outside of that lowest-common-denominator subset. So while the original ESP32 (no suffix) DAC can do this, but newer ESP32-[???] variation DAC could not, so it was removed from ESP-IDF.

[ithinu]

By using the modification from #50, I was able to get it working with 3.X, but only on a NodeMCU-32S board. A small catch was that enable() needed to be called before coeff_set() or nothing was generated. The image on my PAL analog CRT was a bit jumpy, but this was corrected by setting:

    //_hsync_long = usec(30);
    _hsync_long = usec(63.555-4.7);

That is, I simply took the value from NTSC.

Then, that board stopped generating anything. I do not know why. So I tried two other boards, both DOIT ESP32 DEVKIT but from different manufacturers. They both generated the same strange dotted pattern.

Maybe someone here could check if the code attached works with their board, especially with the NodeMCU-32S? Maybe it is not about the board type but differences in the library versions used by these boards. For example, there are some defaults in rtc.h, maybe they have changed. Or perhaps something in the Arduino IDE was updated in the meantime.

I have attached the code, which once worked with 3.X. There are small tunings to center the image on my particular PAL monitor, but I guess that does not matter.

HelloWorld.tar.gz

[Roger-random]

Thank you for your time helping with this! May I see the details of your code changes? I looked on your GitHub profile and I didn't see a fork of this repository.

[ithinu]

I got it working fork.

The issue turned out to be the following modification

    //_hsync_long = usec(30);
    _hsync_long = usec(63.555-4.7);

While this change appeared to fix the unstable picture, it also caused memory corruption because the PAL sync lines in this library are constructed in two halves. Strangely, the picture is now stable at usec(30) on the same CRT.

In addition to upgrading ESP_8_BIT_composite.cpp to esp 3.0.7, I made a small change in GFX_HelloWorld.ino:

  // Clear screen
  videoOut.fillScreen(10);

This modifies the background from black to a dark color, making it easier to spot potential frame geometry issues.

All this does not explain the initial picture instability. Maybe someone can confirm whether the PAL image is stable on an analog CRT as it is now?

[Roger-random]

Thank you for putting some code changes online. I see changes to conform to new requirements on data types but I don't see changes to remove use of deprecated DAC driver. Is that in another repository?

[ithinu]

The changes update the library to the latest 3.X legacy API only. It compiles fine now if only the Espressif library is installed and thus solves this particular bug.

Effectively, that legacy API may eventually be dropped. I'd suggest opening a new issue for that.