I have an Arduino UNO board which is carrying a 2.4" TFT LCD display shield (RM68090 driver) that I’m trying to use as a host display platform. My problem is that pretty much all of the I/O space on the UNO is gobbled up by the shield and I need to bring data into the UNO for didplay
My plan is to use a second Uno or Nano as a co-processor and feed the data to the UNO which is hosting the display shield. Half a dozen bytes or so every 100ms. What’s the best way to interface this to an external co-processor given that UNO’s resources will be slim?
It looks like the I2C pins seem to be unavailable (A4 on UNO is used as LCD_RESET on shield). TX and RX seem to be open on the UNO, but using this is unclear to me. I will not be using the micro SD card on the display module so maybe SPI on the pins dedicated to the SD? My co-processor will be doing most all the heavy lifting and all I need is a way to port a bit of data over every 100 ms or so.
Has anyone any thoughts on this? Surely it’s come up as a challenge to others. I’m just wondering how to best slay this dragon. - Regards, Mark
Please post a link to the actual display that you bought. e.g. Ebay Sale page.
It takes 10 seconds from your life.
We don't have to guess. You get an accurate reply.
What external data do you want? e.g. SPI devices, I2C devices, switches, ...
Yes. I understand and I'm sorry but I don't have any specific information on this board. It's an inexpensive Chinese import part and has no name, or documentation of any sort. It can be found through a web search for "banggood 1428291". Two boards there. For now, concern only with the 2.8". though they behave identically.
The only other things know about this are that
- UNO pins A5, DO(rx) and D1(tx) appear un-labeled on shield screen with no visible traces and may be pinned just for additional mechanical support. All other pins have a functional assignment associated in the silkscreen. I'm GUESSING these are available to me.
- ID returned is 9341 when polled
- non comp silkscreen simply says "2.8" TFT LCD shield (RM68090)". No further information available
- The board is capable of running the demos given with your library MCUFRIEND_kbv on my UNO host.
My plan is to interface this to another UNO board and keeping the task of the shield host UNO strictly to display the data it is fed by an external UNO. I ran across another thread in the forum that mentions a library for arduino called "bitBang_I2C", and this may allow me to gin up a two-wire utilizing the DO and D1 GPIO lines (assumed to be available) on the UNO that's sporting the shield. Does this seem like a plausible solution?
I understand the need to be complete in descriptions given here on the forum, but unfortunately I just didn't have much information from the vendor to relay. I was hoping that these shields were somewhat generic in terms of electrical interface. I can say that it runs fine under your MCUFRIEND library, so that's encouraging.
I don't want to search. I want you to provide a proper link.
Is this the link that you could have posted?
If you are not using the SD card pins 10, 11, 12, 13, A5 are available.
If this is not enough pins, I suggest that you buy a Mega2560 or a Due.
It seems crazy to add a whole MCU board.
Yes, David. That's it. One thought I originally had posted was to commandeer the SD card pins, so I guess that's what I'll do. Too many additional I/O required to do this on one UNO, and MEGA2560 has logic level translation issues, so I think I'll go with the master MCU and use this as a display slave.
It would be nice to know though if D0 and D1 are available. The display substrate board looks like a two-layer FR4 board with no internal layers and there are NO traces running to these two pins, and nothing on the silkscreen indicating their function in the interface. There are header pins there, but that may just be for additional mechanical support and not electrical interface. Perhaps you know if your MCUFRIEND_kbv library makes any use of these ports at low level interface. I suppose I could just yank the pins out of the header and see if it still plays.
In any case, thanks very much for your help and I will continue to dig into I2C options.
D0 and D1 are probably not used because those are the Rx and Tx lines for the Serial/USB interface, and having a peripheral on those pins can interfere with uploading code, as well as prevent the use of the serial monitor for debugging. If the board is not going to be using serial communications over the USB, then you could use those for communicating between the boards.
I've used the I2C interface with a similar display by bending the header pin for A4 out to the side and wiring it to the RESET pin on the Arduino through a resistor. In that case A4 was being used for the display reset line.
Thanks for your input. I went ahead and tried routing theUNO MCU reset to the LCD_Reset pin on the shield. Easy rework, and did the trick. I just pulled the A4 pin from the shield and ran a short jumper on the shield from UNO reset pin (J4-1 to J3-5). Seems to work great and this frees up both the A4 and A5 UNO lines (SDA, SCL). This may allow me to just use the WIRE library directly for TWI. I'll have to insure there are no collisions on LCD_reset asserted on A4 and my later use of it in the TWI, but I Think I should be OK. Thanks again for the idea.
I'll have to insure there are no collisions on LCD_reset asserted on A4 and my later use of it in the TWI, but I Think I should be OK. Thanks again for the idea.
I found the following post by david_prentice made about three years ago:
The constructor arguments are all dummies.
The A4 pin is always driven as OUTPUT_HIGH by the tft.reset() and the tft.begin() methods.
But this is only ever called once in setup(). None of the other methods touch the TFT_RST.
So a subsequent Wire.begin() will reconfigure A4 as OPEN_DRAIN. And your I2C bus should be fine.
Looks like there should not be a problem. There is also a comment in one of the library example sketches about using an Adafruit_TFTLCD constructor if you need to actually change the pins, but I've never tried that and cannot find any examples of its use.
Thanks again. As it stands, I don't believe I will need to reallocate the SCL and SDA pins from A4, A5. I should be able to use the WIRE library directly. From what I've seen, I don't anticipate any problems, but I'd like to look into the implications of utilizing the MCU reset as a surrogate for the LCR_reset asserted on A4. Anyway, MCU_reset seems to do the trick. If Wire.begin() will reconfigure A4 to open drain, then I should be good! I'll post here again when I have results.
...... (a couple hours later)
This works great! No problems with collisions on A4 and no issue using the MCU_Reset as a surrogate LCD reset. There may be a "gotcha" lurking in the back there somewhere, but I'm pretty sure I'm in the clear.
I included the Wire library resource in Arduino and loaded the example files on two UNO boards. Master (listener) was my board with display shield, and Slave (sender) was on the second UNO. Worked as advertised!
Thanks again david_2018 for your valuable input!
This topic was automatically closed after 120 days. New replies are no longer allowed.