changing 2.4 tft reset from A4 to 1 causing conflict with SD library

Working on my latest project and could use some suggestions and/or help. I’m using a cheap 2.4" tftLCD on my UNO R3 and I want to modify the LCD board to move the reset line off of A4 and over to pin 1. Eventually I want to add a BMP180 pressure sensor, and I’ll need A4 and A5 to interface with the sensor using the specific library for that sensor.

In my project I also want to access the micro SD card, and I started learning how to use the SD with the Adafruit example sketch (tftbmp) that comes with the Adafruit TFT library. (NOTE: the sensor name: BMP180 has nothing to do with the image file type that the example code loads from the SD card (*.bmp)).

This is the cheap LCD I have (http://www.ebay.com/itm/US-Ship-Arduino-UNO-LCD-Shield-w-2-4-TFT-SD-Reader-Touch-Screen-Module/321991686388).

It requires the breakout board pinout and it also needs overriding the identifier with this added piece of code:

  if(identifier==0x0101)
      identifier=0x9341;     //this is the ID override for the Xyltech TFT_LCD

I have two of the tftLCDs, one has been modified to move the reset to pin 1 which required cutting a trace on the top of the printed circuit board and soldering a wire to replace the connection so it goes to pin 1 instead. The other unmodified tftLCD retains the A4 reset.

I thought that changing the reset pin location in the setup line of the Adafruit sketch along with the identifier override is all that is needed. But this modification has broken the LCD updates, and all I get is a white screen on the LCD with the LCD reset on pin 1. However, the serial messages in this sketch are still good (this is true with either LCD board). With the altered LCD reset line on pin 1 the SD card is still being read, but the screen is white. There is the blip when the screen is supposed to be updated, but that is all.

The unmodified tftLCD card with its reset on A4 works as intended, the bmp image from the SD card is displayed very nicely on the screen.

Note that I’m using an older SD library (1.0.6), newer libraries don’t seem to work at all with either tftLCD card and I’m not sure why not. I get the: Initializing SD card…failed with the newer SD libraries.

Below is the slightly modified Adafruit example code with the identifier override on line 53-54, and the TFTLCD pinout choice is either line 43 (unmodified) or line 44 (modified reset).

I’m stuck trying to figure out why the reset pin assignment is affecting the LCD, there should be no pin conflicts. On the tftLCD boards I have, pins 0, 1, and A5 should be free.

I have tried a version of the code where I comment out all the SD access lines and just draw a rectangle on the screen using tft.drawRect, etc. This works on either card so long as the reset is set to the right pin for the card being tested. So I’ve concluded that something in the SD library is affected by the move of the LCD reset line from A4 to pin 1.

But that makes no sense!

Modified example sketch is attached to avoid character limit.

tftbmp_rst_on_1.ino (9.07 KB)

Your display is a regular 2.4" Mcufriend Uno Shield. The link "says" that it provides technical support. It does not say which library.

The ILI9341 has a Software Reset command. So the TFT_RESET pin is not necessary (if your library uses the Software Reset command). However you need to solder a 10k external pullup resistor to the shield signal.

If you really want to re-wire it to the Serial_TX pin, this would work. But every time you use the Serial, the TFT will reset to a White screen.

David.

David, thank you very much for that reply.

I understand now that the serial_TX pin is resetting the LCD. Duh, I should have remembered that possible conflict.

I won't be needing serial once the project is finished, but its handy to have when debugging code for an LCD :slight_smile:

So, I think I'll check out the software reset to see if that's possible. I don't think this LCD shield can share the SPI with the SD card to free up the parallel pins for other uses, but if I'm wrong on that conclusion let me know.

I just commented out all the Serial statements in the sketch I posted and now I get a black screen instead of a white screen. Funny, I'm getting a blank black screen on both boards now???

If you attach an external pullup to the TFT_RST pin and the library uses the Software Reset command (0x01):

Serial uses D0..D1
TFT uses D2..D9, A0..A3
microSD uses D10..D13
BMP180 uses A4..A5

The Touch Panel shares D6..D7, A1..A2 with the TFT. Just remember to reset the pinMode() after any TouchScreen calls.

Obviously you could have many I2C devices as well as the BMP180.

David.

David,

I've reached the same conclusion after reviewing the Mcufriend pinout. Obviously I can't easily change the mode pins for the LCD to use SPI shared with the SD card. For my project that would be ideal as I don't need the LCD update speed. I'm tempted to pry up one of my LCDs to see what could be reworked, but it looks like the LCD is taped or glued down to the board.

I don't think the ADAfruit library can do software reset as I have not been able to get the library to ignore the hardware reset entirely.

I either have to learn how to do that configuration, or change the library to something else. Any suggestions on library setup?

Thanks again, -Dave

I explained what peripherals you can run with the Shield. e.g. multiple I2C devices.
If you want to run multiple SPI devices, you will have to forgo I2C.

If you write down the pin budget for your project, you will get some sensible advice.
I suggest that you don't disasemble your Shield.

David.

I’ve solved my original problem and now have pin A4 available to use for I2C sensors. Before I explain what I did let me quickly respond to David’s last post above.

The pin budget for my projects is as listed in David’s post, 4th of this topic:

Serial uses D0..D1
TFT uses D2..D9, A0..A3
microSD uses D10..D13
BMP180 uses A4..A5

All the pins are being used, exactly as listed above. I was simply exploring all the options for modifying my LCD shield to implement a SPI interface to the LCD as was demonstrated in the spitftbitmap.ino example.

Of course modifying the Mcufriend LCD shield is not an easy task and I’ll just buy a breakout board if I ever need more pins while using this style of LCD in the future.

For now, I have what I originally wanted with the pin list above. I modified the Adafruit_TFTLCD library files to eliminate the A4 pin/port from the code. I also changed the reset function in ADAfruit_TFTLCD.cpp to use a software reset. I’m not 100% sure yet that this software reset is working, but I’ll try to test this when I next have a chance to work on my project.

In any case the LCD shield with the cut trace to pin A4 is now displaying my bmp files from the SD card. I simply moved the rework wire that connected the reset line to pin 1 and instead connected it to the UNO’s reset as suggested by the comment in the example code I’m working with. The rework wire is now next to the power pin on the LCD shield and connects to the input pin of the voltage translator that used to receive pin A4. I had to use magnet wire to attach to the voltage translator’s pin. Not easy, but its doable with eye magnifiers and a sharp soldering iron.

Below is the snippet of code where I modified the reset function in the *.cpp library file. The commented out lines are the original code. Let me know if something is wrong with this.

#else

//see newer post and disregard this
  CS_ACTIVE;
  //writeRegister8(ILI9341_SOFTRESET, 1);
  //delay(2);
  writeRegister8(ILI9341_SOFTRESET, 0);
  delay(120);

  //if(_reset) {
    //digitalWrite(_reset, LOW);
    //delay(2);
    //digitalWrite(_reset, HIGH);
  //}
#endif

I’ve attached three new files. The new .ino project file and two new (.h and *.cpp) library files. Check these out and let me know what I could do better. Its much appreciated.

Finally, I have a new problem. If you comment out all the Serial statements from the attached *.ino file, the LCD only displays a black screen with barely visible scan lines. I suspect that without the Serial statements the SD card will not provide the *.bmp files.

Without Serial, its hard to debug but I’m convinced that the SD opens without errors but the data isn’t being read. In any case I now need to spend time in the Storage forum to figure this out, but let me know if you have any suggestions as to why there is a dependency on Serial to read from the SD card.

-Dave

Adafruit_TFTLCD.h (3.13 KB)

tftbmp_rst_on_1.ino (9.12 KB)

Adafruit_TFTLCD.cpp (28.9 KB)

I would be a lot happier with a link to the original library code. e.g. Adafruit on GitHub

There are many hacked versions of the Adafruit code. How do I know what you are using?

Yes, you can attach the Shield LCD_RST to the Arduino's RESET pin (next to 3V3 pin)
Personally, I would just use a 10k pullup resistor from LCD_RST to 5V.

I would be pretty certain that even hacked libraries would use the correct Software Reset sequence i.e.

    CS_ACTIVE;
    writeRegister8(ILI9341_SOFTRESET, 0);
    delay(120);     //you need more than 50ms if it was Asleep
    writeRegister8(ILI9341_DISPLAYOFF, 0);
    ...

I do not know where you have been getting all your "theories" from.
Start with proven Adafruit code. Make notes about every "change" that you make.

Yes, there are a few improvements that can be made to the Adafruit code. But it is wise to start from the same playing field.

David.

David, That’s a strange reply there.

I did exactly as you suggested to the best of my abilities, changed the HW reset to a SW reset without additional references or examples from you. And it worked. But my reward is to be told I didn’t give you a link to the library code, or that my theories are probably bunk??? Weird, I haven’t had a reply like that since the last time I was on Usenet with my 56k.

More info as requested:
IDE 1.6.13
Adafruit GFX is 1.1.5
Adafruit TFTLCD is 1.0.5 (now using the modified files posted earlier)
SD 1.1.0

My R3 UNO is a licensed board, not that I think it matters.

Library stuff is from the IDE updater, so off of GitHub to the best of my knowledge.

You imply in your reply that the SW reset I implemented is not correct. Well, geez, please say how so with some specifics. Without a data sheet for the controller, which I’m not even sure is a real 9341 or just some China clone, I can only go on my prior experience. Which is digital ASICs for the last 20 years. We have reset registers everywhere in our parts and all we do is have SW toggle them. That’s what I was trying to do.

The code snip you posted from the *.cpp file is of the begin function:

void Adafruit_TFTLCD::begin(uint16_t id) {
  uint8_t i = 0;

  reset();

  delay(200);

  if((id == 0x9325) || (id == 0x9328)) {

    uint16_t a, d;
    driver = ID_932X;
    CS_ACTIVE;
    while(i < sizeof(ILI932x_regValues) / sizeof(uint16_t)) {
      a = pgm_read_word(&ILI932x_regValues[i++]);
      d = pgm_read_word(&ILI932x_regValues[i++]);
      if(a == TFTLCD_DELAY) delay(d);
      else                  writeRegister16(a, d);
    }
    setRotation(rotation);
    setAddrWindow(0, 0, TFTWIDTH-1, TFTHEIGHT-1);

  } else if (id == 0x9341) {

    uint16_t a, d;
    driver = ID_9341;
    CS_ACTIVE;
    writeRegister8(ILI9341_SOFTRESET, 0);
    delay(50);
    writeRegister8(ILI9341_DISPLAYOFF, 0);

rest of function snipped

That is where I picked up the register identifier for the reset control. My read of that begin function is that the SOFTRESET writeReg line is only being set to ‘0’. So I didn’t think it was a toggle, but rather just a initial setting.

What thought I did do is replace the HW toggle (now commented out) with a SW toggle in the reset function in post #6. Note that the begin function calls the reset function at the beginning. Wouldn’t it be best to modify the reset function to replace the HW reset with the SW reset?

But hey, I last used Turbo C++ on a Very Small Computer that uses an 8088 25+ years ago. I’m sure you know the Arduino better, and I know it would be better for this forum if we had only 4 posts of great info instead of more of my mistakes.

My original question on how to liberate the A4 pin on the 2.4 LCD has been asked (and not answered to my knowledge) on other forums, for at least a year. Which is the main reason I asked for help here. Other users would probably benefit from this info given the low cost of the 2.4 LCD shield. I’ll bet I’m not the only one who wants to use it to display I2C sensor output.

The problem I was having with the Serial being commented out was SD related. There are some multiple Serial calls on some of the lines in the example sketch where the SD call is inside the Serial call.

I am the author of MCUFRIEND_kbv library. I have answered the A4 question many times on this Forum.

I am sorry if I have offended you. I was a little surprised by your "confidence" in the "move LCD_RST to D1" theory.
Your writeRegister8(ILI9341_SOFTRESET, 1); makes no sense.
The ILI9341_SOFTRESET command takes no arguments. And the Datasheet explains the timing restrictrions.

I make no apologies for asking for the links. It is an essential part of posting questions.

It also means that you can often get a solution within one reply.

I can find this Adafruit library on GitHub.
Is that the one that you are using?
Note that there are many hacked versions of Adafruit code. There might even be a "more official" repository from Adafruit.

The readID() from that link gives 0xC0C0 for a genuine ILI9341 controller.
I am sure that some of the hacked versions return 0x9341 as expected.

If you want to know which controller that you have, run the LCD_ID_readreg.ino sketch and copy-paste the output from the Serial Terminal.

David.

Yes, that is the Adafruit library I updated to within the IDE, and then modified for the SW reset.

You say that the A4 question has been answered many times on the forum. In my internet searches one afternoon before I asked, I only found one discussion here with the suggestion to replace A4 with A6 in the sketch code. That’s not what I wanted to do.

If the A4 pin has been liberated before now, and the libraries already updated for this mod, then I would have greatly appreciated a link to the discussion and code…a few posts back. Do you have a link to this?

The readID() from your GitHub library/examples at: GitHub - prenticedavid/MCUFRIEND_kbv: MCUFRIEND_kbv Library for Uno 2.4, 2.8, 3.5, 3.6, 3.95 inch mcufriend Shields gives the following on my unmodified board from the zyltech vendor:

Read Registers on MCUFRIEND UNO shield
controllers either read as single 16-bit
e.g. the ID is at readReg(0)
or as a sequence of 8-bit values
in special locations (first is dummy)

reg(0x0000) 00 00 ID: ILI9320, ILI9325, ILI9335, ...
reg(0x0004) 00 00 00 00 Manufacturer ID
reg(0x0009) 00 00 61 00 00 Status Register
reg(0x000A) 00 08 Get Powsr Mode
reg(0x000C) 00 06 Get Pixel Format
reg(0x0061) 00 00 RDID1 HX8347-G
reg(0x0062) 00 00 RDID2 HX8347-G
reg(0x0063) 00 00 RDID3 HX8347-G
reg(0x0064) 00 00 RDID1 HX8347-A
reg(0x0065) 00 00 RDID2 HX8347-A
reg(0x0066) 00 00 RDID3 HX8347-A
reg(0x0067) 00 00 RDID Himax HX8347-A
reg(0x0070) 00 00 Panel Himax HX8347-A
reg(0x00A1) 00 00 00 00 00 RD_DDB SSD1963
reg(0x00B0) 00 00 RGB Interface Signal Control
reg(0x00B4) 00 02 Inversion Control
reg(0x00B6) 00 0A 82 27 04 Display Control
reg(0x00B7) 00 06 Entry Mode Set
reg(0x00BF) 00 00 00 00 00 00 ILI9481, HX8357-B
reg(0x00C0) 00 21 00 00 00 00 00 00 00 Panel Control
reg(0x00C8) 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA
reg(0x00CC) 00 71 Panel Control
reg(0x00D0) 00 00 00 Power Control
reg(0x00D2) 00 00 00 03 03 NVM Read
reg(0x00D3) 00 00 93 41 ILI9341, ILI9488
reg(0x00DA) 00 00 RDID1
reg(0x00DB) 00 00 RDID2
reg(0x00DC) 00 00 RDID3
reg(0x00E0) 00 0F 16 14 0A 0D 06 43 75 33 06 0E 00 0C 09 08 GAMMA-P
reg(0x00E1) 00 08 2B 2D 04 10 04 3E 24 4E 04 0F 0E 35 38 0F GAMMA-N
reg(0x00EF) 00 03 80 02 02 02 ILI9327
reg(0x00F2) 00 02 02 02 02 02 02 02 02 02 02 02 Adjust Control 2
reg(0x00F6) 00 01 00 00 Interface Control

I went ahead and did more in-depth testing of the SW reset using the phone example sketch. I did the testing on a unmodified LCD shield and compared the behavior of the Hardware reset to the Software reset. It appears to work as described in the datasheet linked below with the caveat that I’m not sure I have the 9341.

Phone sketch and library files attached

phonecal.ino (12 KB)

Adafruit_TFTLCD.cpp (28.9 KB)

Adafruit_TFTLCD.h (3.13 KB)

You have a regular ILI9341V controller. You can find both datasheet and App Notes for ILI9341 from Ilitek.

I just Googled for references to me advising about LCD_RST pin:

You say that the A4 question has been answered many times on the forum. In my internet searches one afternoon before I asked, I only found one discussion here with the suggestion to replace A4 with A6 in the sketch code. That's not what I wanted to do.

Please find this reference. Even Einstein would notice that the DIP Uno does not have an A6 pin. And even though the SMD Uno clones possess an A6 pin, it is Analog only. So you could wobble it as much as you like, you will not be able to do a Hardware Reset. You need a Digital pin for this. (A4 can be both Analog AND Digital)

Regarding your attached files. Look at it from the reader's point of view.

  1. are they genuine Adafruit_TFTLCD.* files from GitHub?
  2. or have you hacked them?
  3. if you explain your "edits", then I can just compare with GitHub.
  4. if I don't know what you have done, I would have to download from GitHub and diff "your files"
  5. yes, I can do that. but it is a lot of unnecessary work.
  6. likewise, your sketch requires "your" hardware modification. Many readers will "try" software mods. I am reluctant to do hardware mods.

David.

The phonecal sketch doesn't require hardware mods. Only needs swapping out the library files to switch between SW and HW reset. I am not reluctant to do any mods, SW or HW so long as I know what to do :slight_smile:

I'm not a hacker. LOL. The library files are from GitHub to the best of my knowledge.

Look at post #8 here for the 'A6' suggestion:

Thanks for the links, I'm now including "Mcufriend" in my searches for more information. And I'll try to check out the library when I have a free moment.

Sorry for not adding more info about the test sketch, I was tired from work.

The phonecal.ino example sketch came from the lcd shield vendor's web site, its not my code.

It puts some numbered buttons on the screen like an older phone and has a text rectangle at the top. When you push a number button it prints that number in the text box. There are also Send, Clr, and End buttons. The Clr button will erase the last number printed to the screen. The Send and End buttons just print a very small font sized message. Its just a test sketch to demonstrate touchscreen use.

This is the only touchscreen example I've looked at and it seemed simple and suitable enough to learn what I need for my project.

More info on what I did to the code:

  1. Adafruit_TFTLCD.h
  • eliminated references to pin A4. I did this by leaving out the reset pin in the sketch
    Adafruit_TFTLCD tft(LCD_CS, LCD_CD, LCD_WR, LCD_RD);
    And then let the compiler tell me where to make the edits to remove the reset pin. I only removed the ones needed for my setup, so there are still some references in other, non used places of the .h file. At least that is what I was trying to accomplish.
  1. Adafruit_TFTLCD.cpp
  • also eliminated the reset pin refs and modified the tft.reset() function to use the code snip in post #7
    I then did some iterative tests and confirmed the reset behavior differences between a hardware reset and the new SW reset using the phonecal.ino sketch. The only lines of code that are go/nogo critical are these two:

CS_ACTIVE;
writeRegister8(ILI9341_SOFTRESET, 0);

I added the delay based upon the ILI9341V spec max delay from sec 8.2.2 (if in sleep mode which was larger at 120ms, and no, I don't know if it can be put in sleep mode on the Arduino UNO)

  1. phonecal.ino

-removed pin A4 references. Added pinMode(A4, INPUT_PULLUP); to pull up pin A4 so that it could be tested on an unmodified card without having a jumper wire handy. I then added the tft.reset(); call to the END button along with a delay(1000).

So this example sketch works as before except now when you press the 'End' button, the lcd is reset. I did try to add useful comments to the code.

With the SW reset, you can see the screen is blanked and won't respond to anything other than the UNO's hard reset button, which reloads and restores the program.

Then its a relatively simple matter to restore the library files and put the A4 back into the Adafruit_TFTLCD tft statement of the phonecal sketch and observe the same behavior when pressing the 'End' button with one important exception:

The frame memory is not changed with the software reset (sec 15.1 in the spec). I observe this condition because any numbers printed to the text rectangle are briefly seen upon reloading the program after pressing the UNO's reset button only when testing the SW reset.

The hardware reset with the original library files doesn't retain any numbers entered.

Clear as mud? Probably, but I'm tired again and have to work tomorrow. Let me know where I went off the rails.

Quick question if anybody had made it this far: do any of the libraries ignore the A4 pin if you don't specify it? I'll be happy to test other libraries with my phonecal sketch since there is an observable difference between the HW and SW reset.

This all matters to me because I don't think the BMP180 is 5V tolerant on the tiny breakout boards I have. So I need to be sure that no digitalWrite High is done to pin A4 with the BMP180 attached.

Adafruit sells several displays. Both as a Shield and as a Breakout.

As far as I know, Adafruit always provides a "pullup" on the TFT_RST pin, OLED_RST pin, ...
Adafruit libraries generally have a full fat constructor that includes a RST pin.
Adafruit examples often use a shortform of constructor that omits the RST pin.

Mcufriend Shields do NOT have a pullup on the RST pin. Nor do most Chinese TFT modules, LCD modules, OLED modules, ...

So I always advise people to specifically include the RST pin in the full fat constructor.

As discussed earlier, you can hardwire a pullup to the LCD_RST pin/trace on an Mcufriend Shield. Or hardwire it to the RESET pin (next to 3V3 pin)

Hardwiring to the RESET pin (as advised by Adafruit) should work with old fashioned controllers but I would be cautious.
On a modern controller like the ILI9341, you can rely on the SOFTWARE_RESET command (with suitable timing)

Anyway, I still do not think that you understand the idea behind "explaining software edits".
You could quote line numbers of your edits.
You could add a "signature comment". I add ".kbv" to my comment field.
You could provide a "Patch" file that automates the edit process.
You could use GitHub or other service.

Yes, I could try to follow your explanations. I am reluctant.
However, I did take your phonecal.ino sketch. Used a proper constructor with the official Adafruit_TFTLCD library.

Built and ran the sketch on a regular 2.8" Blue Mcufriend shield. My Touch Panel is wired differently:

#define YP A1  //.kbv was A3 must be an analog pin, use "An" notation!
#define XM A2  // must be an analog pin, use "An" notation!
#define YM 7   //9 can be a digital pin
#define XP 6   //8 can be a digital pin

#define TS_MINX 920 //.kbv was 150
#define TS_MINY 940 //120
#define TS_MAXX 150 //920
#define TS_MAXY 120 //940

And sure enough, the sketch works fine.

David.

David, Let’s be clear about what “the sketch works fine” actually means.

You downloaded the phonecal sketch, made the necessary changes for your LCD shield, then it ran without errors?

If that’s all, then that’s not the test. The test is to check for the momentary presence or absence of numbers when restarting the code with a hard UNO reset button press. That indicates whether or not it was a SW or HW reset.

I asked: “do any of the libraries ignore the A4 pin if you don’t specify it?”

I switched to the MCUfriend library and ran the test, and it compiled with the RST omitted from the constructor statement, but it still toggles the A4 pin using a HW reset. I guess you mean to say that I have to modify any/all of the TFTLCD.cpp libraries in order to switch to a SW reset, and free up the A4 pin?

For a better proof of concept test, I took the unmodified LCD shield and bent the A4 pin out 90degrees, isolating it from the UNO.

-Then I attached a 10k pullup between 5V and the newly bent LCD reset input lead. LCD can only be reset by SW.

-Then I inserted a 1K pulldown in the SDA/A4 location on the other side of the R3 UNO board next to AREF. The LCD shield does not cover that pin, thankfully.

-Finally, I attached a pair oscilloscope probes to the SDA/A4 pin (with the 1K pull down using oscope channel1) and also to the UNO’s HW reset line (oscope channel2).

I had to add a tft.setRotation(2); to get the buttons to align with the MPUfriend library. I used a constructor that didn’t have the RST: MCUFRIEND_kbv tft (LCD_CS, LCD_CD, LCD_WR, LCD_RD);

I deleted the pinMode(A4, INPUT_PULLUP); in the phonecal sketch since there is a pull down on that pin now.

This compiled and ran fine. However it fails my project requirements because the A4 pin is being driven high to 4.88 V. That’s out of the max spec for the BMP180 which is a 3.3V device with a max pin voltage of 4.25V. The BMP180 mini boards I bought directly connect the sensor IC to pins A4 and A5. I don’t want to forward bias the protection diode.

See attached screen shot of the MPUfriend’s HW reset pulse when you press the ‘End’ button in the phonecal.ino sketch. The HW reset pulse is 100ms wide, and high when inactive at 4.88V.

My modified libraries files (Adafruit_TFTLCD.h and Adafruit_TFTLCD.cpp) do not affect the A4 pin when running the phonecal.ino test sketch. I took your suggestion to heart and eliminated the HW reset. The constructor for the modified files is just: Adafruit_TFTLCD tft(LCD_CS, LCD_CD, LCD_WR, LCD_RD);

With the modded library, the Oscilloscope never triggers on the A4 pin. Its always at LOW logic level for the above described setup, but you can observe the SW reset working on the LCD screen.

This is what I wanted. So I think I’m good to move forward with my project now.

Regarding regular TFT libraries:

tft.reset() will do a hardware Reset. i.e. wobble the TFT_RST pin
tft.begin() will perform a software Reset and initialise the TFT registers for library use.
This is normally done in setup()

If you want to perform software or hardware Reset in the loop() area of a sketch, you must call tft.begin() too.

The Arduino Reset button (or DTR pulse) will reset the AVR chip registers, inspect the bootloader, start the application with a WatchDog Reset. This resets the AVR registers (again). Clears BSS area, copies initialised data from Flash, ... runs the application as normal.

If your TFT_RST pin is connected to the AVR RESET pin, the controller will get a hardware Reset from the button/DTR. It will get a software Reset as part of the tft.begin() in setup().

Yes, the MCUFRIEND_kbv library wobbles the A4 pin the first time that readID() is called.
The MCUFRIEND_kbv library should produce PORTRAIT with setRotation(0). Just like the Adafruit_TFTLCD library.
MCUFRIEND_kbv ignores all the arguments in the constructor. They exist purely for "compatibility" with Adafruit_TFTLCD constructor syntax.
If you have snipped off the TFT_RST pin, any A4 wobbles will never reach the TFT controller.
You simply call Wire.begin() after tft.begin().

The phonecal.ino sketch is a good example for showing you how to use the TouchScreen class and GFX_Button class.

However, your mapping is not very intuitive:

    p.x = map(p.x, TS_MINX, TS_MAXX, tft.width(), 0);

Surely you would use:

    p.x = map(p.x, TS_LEFT, TS_RIGHT, 0, tft.width());  //map to screen coordinates
    p.y = map(p.y, TS_TOP, TS_BOT, 0, tft.height());

You can write whatever TFT libraries you like. You can modify hardware as much as you like. You can map Touch values backwards if that is what you want.

I can not understand why anyone would put a pulldown on the I2C bus. This violates the protocol.

I will abandon this thread. You and I will never agree.

David.

Sigh…

Back from Holiday.

For everybody else who might still be reading this thread:

I have no idea what David and I are supposed to agree on. Maybe there is a language translator involved that is making communication difficult?

I do agree with David that putting a pull down resistor on the I2C pins when you are communicating with an I2C device would be a bad thing to do.

Good news: I didn’t do that.
And I’m not recommending anybody else do that when you are trying to use an I2C device.

The pull down is just for testing the LCD library with the demonstration phonecal.ino sketch (which was not originally written by me, I downloaded it from the LCD vendor’s web site). No I2C devices are attached in this setup and I didn’t include the Wire library for this test.

If I add a passive pull down or load resistor to A4, and then observe a HIGH level on A4 using test equipment that can capture pulses (and levels), then I know the UNO’s program is setting/driving that pin HIGH.

We don’t want to do that since the BMP180 is a 3.3V part and its not tolerant to 5V. Even small blips can shorten the lifespan of a part that is not 5V tolerant.

Here is the helpful added information I was able to pull out of the last post with regards to the A4 pin:

Using David’ MCUFRIEND_kbv library:

  1. Do not use either: tft.reset(), or tft.readID() in your sketch.
    NOTE: you must hardcode the identifier variable if not using the readID call.

  2. Add the <Wire.h> library and make sure you call Wire.begin() right after tft.begin()

I tested this on my bent A4 pin/oscilloscope setup. After commenting out the reset and readID calls, hardcoding the identifier, and adding the wire library with the Wire.begin call right after tft.begin.

Unfortunately, I still get a 5V pulse to the A4 pin at startup. See attached oscilloscope photo. This is not the condition I’m looking for, and it doesn’t answer the question I’m trying to ask in this thread.

If I comment out the Wire.begin() statement and re-test the above setup, then the A4 pin is driven HIGH and it is left HIGH.

There are no HIGH writes (5V) to pin A4 with the earlier posted modified Adafruit library files with the ILI9341. If anybody wishes to try it, I suggest leaving off any 3.3V I2C devices and testing/measuring to be sure it doesn’t overdrive A4. Yes, you will need to rework the LCD reset with a pullup resistor, or connect the LCD reset to the Arduino’s reset (DTR), which is what I did.

I don’t really want to abandon my own thread, but at least now there is a post that states all that I’ve learned here.
I’m thankful I’ve gotten this far. Next, I’ll take a look at the wire library and do some testing with 10K pullup resistors to 3.3V with the oscilloscope…before attaching my BMP180 modules.