Does this library work with the ST7735S driven 128x160 TFT displays?

As far as the LCD spin out goes, I only put that there as I've not used a 20x4 display so wasn't 100% sure they were all identical. I'd guessed they were as the backpacks work on those two, but safer to have the OP make sure. ;-)

Hopefully he'll report back if it's worked for him. I know some people can get tremely frustrated when things don't work and get the 'it's no good, I'm fed up, it's rubbish' red mist. I have a couple of mates with low patience levels like that.

You can't just send a schematic, unless someone else is also going to design the PCB for you.

To send a PCB to be made then you need to design it, convert to the appropriate format for the tab house (usually Gerber files) and send them.

TBH, do I need to do anything unless I actually add code, or use libraries that make use of the INPUT_PULLUP option.

No, you don't. I thought you were doing this because you did need INPUT_PULLUP supported.

No, it was because the sketch that used keypad.h wouldn't compile when I changed my board from Uno to 1284P.

The library itself was looking at Arduino version and expecting define of INPUT_PULLUP for IDE versions over 1.0.

I'm not using INPUT_PULLUP myself at all.

lefty, I might just try what you did and copy the cores across for my 1284P and 644P entries. I'll back up what I have first.

I've got astripboard with 6 RGB LEDs assembled on it. Each set of 6 Red, 6 Green, 6 Blue are controlled by an NPN tranistor, from a PWM pin on the MCU.

I've modified the fade sketch to test PWM and I'm fading each one up and down between 0 and 255 with a 30ms interval.

The only difference is they are out of sync. Red starts at 0, Green starts at 100, Blue starts at 200.

If I have an LCD still active, from a previous sketch so no LCD reset, I notice the LCD flicker. This is to do with the way the 3 signals are out of sync as it goes at a slower rate than any individual LED, but you can see the effect as regular, so it's some kind of modulation or harmonic issue with the three PWM's out of sync.

The LCD is mounted on an I2C backpack with a PCF8574.

Now, I have 0.1uF caps on across the MCU supplies right next to the pins. I've also tried 0.1uF cap across the supply to the backpack/LCD (where the leads plug into the breadboard).

This seems to have no effect.

I don't have access to an o-scope.

Could it be that I need a decoupling cap closer to the PCF8574 on the backpack and/or decouplng on the supply lines at the stripboard with the LEDs on?

It's just occured to me that it may be to do with different PWM frequencies too. This is on a 1284P and I'm using PIns 30, 8 and 9 on Bobuino variant. That translates to PD4 (OC1B), PD5(OC1A) and PD6(OC2B) Could it be that the two timers are different PWM frequencies and it's interacting?

I'll have a try with different PWM pins ot see if it makes any difference too.

TBH, do I need to do anything unless I actually add code, or use libraries that make use of the INPUT_PULLUP option.

As far as I can see, keypad.h doesn't do that as it already had that masking of the issue for pre 1.0.

OR, are there other 'if defined(ARDUINO) && ARDUINO < 101' that make use of INPUT_PULLUP when the IDE version is 1.0 or above?

It compile OK, but it doesn't do the same thing. All you have accomplished there is to make INPUT_PULLUP equivalent to INPUT. The _PULLUP extension is lost.

Ah, I understand.

So all it does is change a written

Code:

pinMode(pin, INPUT_PULLUP);

to

Code:

pinMode(pin, INPUT);

But the internal pullup isn't enabled.

OK, so how about  an actual fix to the cores?

In arduino.h I do

Code:

#define INPUT_PULLUP 0x20

and in wiring_digital.c under the pinMode(uint8_t pin, uint8_t mode) function I change

Code:

if (mode == INPUT) {
uint8_t oldSREG = SREG;
                cli();
*reg &= ~bit;
SREG = oldSREG;
} else {
uint8_t oldSREG = SREG;
                cli();
*reg |= bit;
SREG = oldSREG;
}

To

Code:

        if (mode == INPUT) {
uint8_t oldSREG = SREG;
                cli();
*reg &= ~bit;
*out &= ~bit;
SREG = oldSREG;
} else if (mode == INPUT_PULLUP) {
uint8_t oldSREG = SREG;
                cli();
*reg &= ~bit;
*out |= bit;
SREG = oldSREG;
} else {
uint8_t oldSREG = SREG;
                cli();
*reg |= bit;
SREG = oldSREG;
}

The only difference I can see is the reference to *out pointer, so I'm not 100% sure if that is a new variable somewhere else?

OK, this certainly seems to fix the error.

As explained in my response to your PM, I had applied a fix in my 1284P arduino.h file.

I removed that and tried compiling and got the original error.

I then added the keypad.h fix like this

Code:

//#if defined(ARDUINO) && ARDUINO < 101
#ifndef INPUT_PULLUP // fix for MCU with custom bootloaders/cores that don't have the update, like 1284P
#define INPUT_PULLUP INPUT
#endif

This now compiles fine with the following custom MCU entries:-

Mighty1284P with Optiboot, using maniacbug, bobuino and avrdude variants
Custom 644P with Optiboot, using bobuino variant

Mark, I'll give that a try for you shortly.

What I had done as a quick fix was alter the arduino.h file, in my 1284P cores folder, to add #define INPUT_PULLUP 0x02

I'm guessing it was dirty though as there is probably some code in another file (like suggested with wiring.h) where INPUT_PULLUP is mapped to the two normal pinMode and digitalWrite operations.

I'll remove the line and try your fix and report back. If it works then it would fix it for all permutations, whether the 1284P cores get fully updated or not. It'll either be fixed in the cores and your fix doesn't take effect, or your fix covers it if no INPUT_PULLUP defined.

I'll report back shortly.

Many thanks for taking the time to respond and PM me that you had done so.

That configuration is working perfectly to handle the TFT. What about the card reader? 

If using the card reader then you need to connect it to SPI. MOSI, MISO and SCK to respective lines. I used D4 for the SD Card CS. If you connect the TFT to hardware SPI too (much faster update) then what I did was connect the SD card through to hardware SPI (11, 12, 13 on UNO) and then connect the TFT SDA to the SD MOSI, TFT SCL to SD SCK, then TFT CD & AO to your defined pins.

I'll try and find time to put a more comprehensive example together of how to connect it all shortly.

With LCD screens, especially higher pixel counts, speed is going to count, so look for the connection method.

You also need to see if there is a library and good code examples for you to work from.

For these I'd think hardware SPI is the best connection method, but check any library to see what speed you are interfacing at. You can go up to half the MCU clock speed with SPI so a clock divider of 2.

For example, the 128 x 160 TFT I just bought workers with an Adafruit library. The library specifies a clock divide of 4. This can be changed to 2 and double the data rate onspeed up display.

This is just my own take on finding the right method and code. I'm sure there are some more experienced members that could tell you any hardware pros and cons of the actual controller chips themselves.

I'd guess one will be what data rate thy could handle on SPI, to see if you can change the SPI clock divider as I mentioned above.

Then what's the use of an external 16mhz if an internal 8mhz would do by itself?

A microprocessor that runs at up to 16MIPS, instead of 8MIPS.

If your sketch is light load then maybe 8Mhz is fine for you. Maybe even lower, in which case there are power savings that can be made, since requirements are lower at lower speeds. You could go as far down as 1Mhz.

If you have already tried the LCD then I'm assuming you checked to see if there is an onboard resistor for the backlight LED.

With those type of trimmers, I gently bend them over the opposite way, so that they part hang of the board and are accessible when the backpack is on the LCD. It's a lot easier to adjust the contrast whilst the LCD is connected and on. Just keep turning until you get characters.

Sometimes cheap is fine ;-)

There are two versions (at least) of the mjkdz board. The one you have is the 22 turn trimmer and has address 0x20 by default. The other one has a single turn pot and is 0x27 by default. I have both and have worked through connection issues just like you.

First, download the New Liquid Crystal library - https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads

Make sure you remove the existing standard LiquidCrystal and LiquidCrystal_I2C libraries. Don't just rename them, you have to remove them from the 'libraries' folder completely or there will be a conflict.

If your LCD connections are (Left to Right) - VSS, VDD, VO, RS, RW, E, D0, D1, D2, D3, D4, D5, D6, D7, A (or LED+), K (or LED-) then the connection goes to the following bits on the I2C chip

RS - 6
RW - 5
E - 4
D4 - 0
D5 - 1
D6 - 2
D7 - 3
Backlight - 7

This makes your constructor 4,5,6,0,1,2,3,7 so use the following example sketch:-

Code:

#include <Wire.h>
#include <LiquidCrystal_I2C.h>

#define lcdAddr 0x20 // set the address of the I2C device the LCD is connected to

// create an lcd instance with correct constructor for how the lcd is wired to the I2C chip
LiquidCrystal_I2C lcd(lcdAdrr, 4, 5, 6, 0, 1, 2, 3, 7, NEGATIVE); // addr, EN, RW, RS, D4, D5, D6, D7, Backlight, POLARITY

// Creat a set of new characters
const uint8_t charBitmap[][8] = {
   { 0xc, 0x12, 0x12, 0xc, 0, 0, 0, 0 },
   { 0x6, 0x9, 0x9, 0x6, 0, 0, 0, 0 },
   { 0x0, 0x6, 0x9, 0x9, 0x6, 0, 0, 0x0 },
   { 0x0, 0xc, 0x12, 0x12, 0xc, 0, 0, 0x0 },
   { 0x0, 0x0, 0xc, 0x12, 0x12, 0xc, 0, 0x0 },
   { 0x0, 0x0, 0x6, 0x9, 0x9, 0x6, 0, 0x0 },
   { 0x0, 0x0, 0x0, 0x6, 0x9, 0x9, 0x6, 0x0 },
   { 0x0, 0x0, 0x0, 0xc, 0x12, 0x12, 0xc, 0x0 }
  
};

void setup()
{
   int charBitmapSize = (sizeof(charBitmap ) / sizeof (charBitmap[0]));

  lcd.begin(20,4);  // initialize the lcd as 20x4 (16,2 for 16x2)
  
  lcd.setBacklight(1); // switch on the backlight

  for ( int i = 0; i < charBitmapSize; i++ )
   {
      lcd.createChar ( i, (uint8_t *)charBitmap[i] );
   }

  lcd.home ();  // go home to character 0 on line 0 (1st line)
  lcd.print("Hello, ARDUINO ");  
  lcd.setCursor(0,1);  // character 0 on line 1 (2nd line)
  lcd.print (" FORUM - fm   ");
  lcd.setCursor(0,2) // character 0 on line 2 (3rd line)
  lcd.print("This is line 3");
  lcd.setCursor(0,3) // character 0 on line 3 (4th line)
  lcd.print("This is line 3");
  delay(1000);
}

void loop()
{
   lcd.clear()
   lcd.home ();
   // Do a little animation by writing to the same location
   for ( int i = 0; i < 2; i++ )
   {
      for ( int j = 0; j < 16; j++ )
      {
         lcd.print (char(random(7)));
      }
      lcd.setCursor ( 0, 1 );
   }
   delay (200);
}

I've just modified that on the fly (mine are 16x2 LCD's) so hopefully it will work straight off for you. If not then look on it as a learning exercise to fix it, now you have the example ;-)

This is just one that was posted in another thread (on the 1.8" cheap TFT's)

http://item.mobileweb.ebay.co.uk/viewitem?itemId=181008290930

It's touch screen too, but you could just not use that function.

It meets your other criteria; size, aspect ratio, price.

HTH