Closed JLBCS closed 6 months ago
I understand your pain! Arduino has a huge ecosystem of libraries (like this one!) written by hobbyists for doing almost anything. But bringing multiple libraries together always cause headaches because it's a huge ecosystem and it's impossible to test all possible combinations.
When I encounter such problems, I usually find that the ESP32 hardware is capable of performing the tasks together. In that case I had to drop down to lower-level API calls. Those Arduino libraries become sample code, I cut/paste code sections needed to assemble my creation and skip the uncooperative portions. Similar to how I cut/paste from ESP_8_BIT to create this library. Such stitching can usually be done in Arduino IDE, but sometimes I had to drop down to using the lower-level ESP-IDF development framework.
If it is acceptable to split the solution across multiple modules, I would recommend switching to hardware designed for video output. Would a Raspberry Pi be acceptable? They have all have I2C pins and can output composite video. (Well, I know Zero, 2, and 3 could. Not sure about the newer 4 or 5.) Or if "a larger screen" is the criteria and not necessarily composite video, it's easy to use their HDMI port.
If a Pi is undesirable due to network security concerns, SD card corruption concerns, boot-up time, etc. Staying in the microcontroller world this product might be of interest: (https://www.adafruit.com/product/5710) It generates a DVI signal from a RP2040 microcontroller. The DVI signal is HDMI compatible but can't be called HDMI due to licensing reasons.
Hello,
I did not have time to wait for a change in I2C to support broadcasting and use the same message on the LCD and on TV.
I simply added a serial instance and duplicate
my I2C message. An easy task when using the streaming service. On a ESP32-Wroom, I receive the message and send it to the s-video pin Working fine.
lcd.setCursor(0, 0);
lcd << _FMT("%/%/% % %:%:% ", _WIDTHZ(dd, 2), _WIDTHZ(mm, 2), _WIDTHZ((yy - 2000),2), _BYTE(reception),_WIDTHZ(hh,2), _WIDTHZ(mn, 2), _WIDTHZ(ss,2) );
svideo << _FMT("R1: %/%/% % %:%:% ", _WIDTHZ(dd, 2), _WIDTHZ(mm, 2), _WIDTHZ((yy - 2000),2), _BYTE(reception),_WIDTHZ(hh,2), _WIDTHZ(mn, 2), _WIDTHZ(ss,2) ) << endl;
Closing due to lack of activity. Feel free to reopen if there is new information.
I am working on a big project mixing up GPS, LCD 20x4, softwareserial,Wire ans Streaming. All work fine on Arduino Uno. A museum is interested in this development with a larger screen. TVOUT is out of age, so I looked at ESP_8_bit with the GFX library. Problem number 1 ESP_8_bit requires an ESP processor, so I moved my code toe ESP-Wroom.;; and hit the second problem. There seem to have incompatibility(ies) between all my #include. I then decided to split the application One processor to crunch the data, manage the LCD and transmit the data to an ESP processor capable of managing the TV screen. Now I have to decide of the protocol to use for the transfer. Ideally I2C is already in my code by mean of HD44780 if we simply broadcast to all the participants, LCD and the ESP processor. Question: when used in conjunction with STREAMING, is HD44780 broadcasting or addressing a single device? A physical test show that 2 LCDs can display the same data without problem. Second question/suggestion I need help (or working example) to receive the data on the ESP for large TV display Thankyou