2.2" 320x240 Color LCD Booster Pack

[RobG 1,892]

I am using 2N7002 (SOT-23) but you could use NPN BJT.

If you use 2N7002, you could use small gate resistor, something like 82 ohms, but it is not necessary (you can short it.)

If you use BJT, MMBT3904 for example, base resistor should be 1k-2.2k

[draconisys 0]

Thanks for the great response!

 

Also, which memory would be a good fit? I've got a bunch of CAT25C256 and CAT24C256 (also have the 128k versions) parts in stock. I also have a a coiuple of 23A1024s in stock. Will any of those work? I saw the schematic, but it didn't really specify what kind of memory would work, or if there was a size you had in mind. If there's a specific chip you designed for, I can probably sample that next month, if I don't already have it.

 

Thanks again!

 

Have a great holiday.

[abecedarian 330]

Thanks for the great response!

 

Also, which memory would be a good fit? I've got a bunch of CAT25C256 and CAT24C256 (also have the 128k versions) parts in stock. I also have a a coiuple of 23A1024s in stock. Will any of those work? I saw the schematic, but it didn't really specify what kind of memory would work, or if there was a size you had in mind. If there's a specific chip you designed for, I can probably sample that next month, if I don't already have it.

 

Thanks again!

 

Have a great holiday.

Rob's design is around a 23K256SN, it appears. The 25c256 might work but pin 3 on that chip is !WP (Write Protect), and pin 3 on the 23K256 is "No Connection" so that could cause an issue.

[RobG 1,892]

Rob's design is around a 23K256SN, it appears. The 25c256 might work but pin 3 on that chip is !WP (Write Protect), and pin 3 on the 23K256 is "No Connection" so that could cause an issue.

@@draconisys, as @@abecedarian already wrote, my board was designed to work with 23Kxxx and 25AAxxx. If pin 3 is used for !WP function, you can solder a jumper to Vcc (pin 3 is NC.)

[nemetila 12]

Probably it's a noob question:

 

Why is not necessary to use current limiting resistors(R2..R5) to limit the LEDs' currents?

(Your circuit uses shorts by default)

I know it works, because i have test it, but the TM022HDH26 datasheet shows the maximum forward current is 25mA@3.4V for each LED,

and the MSP-EXP430G2 LaunchPad's Vcc can be slightly above 3.4V

 

Thanks in advance

[TDHofstetter 1]

Any chance of finding a faster display? I've optimized everything I can in code, and due to the blocking nature of the serial calls into the display's internal controller, the fastest I can repaint the display is twice per second. That's with a simple repaint, a clearScreen(1) followed by a single pixel paint per X (X is on the 320-pixel axis, Y is on the 240-pixel axis).

 

-- Tim --

[RobG 1,892]

Why is not necessary to use current limiting resistors(R2..R5) to limit the LEDs' currents?

(Your circuit uses shorts by default)

I know it works, because i have test it, but the TM022HDH26 datasheet shows the maximum forward current is 25mA@3.4V for each LED,

and the MSP-EXP430G2 LaunchPad's Vcc can be slightly above 3.4V

 

 

From my experience, If does not approach it's max value in those displays, so I do not use resistors (I only had to do it for some 5110 LCDs.)

@3.6V, all LEDs consume about 40mA, so it's 10mA per LED.

[RobG 1,892]

Any chance of finding a faster display? I've optimized everything I can in code, and due to the blocking nature of the serial calls into the display's internal controller, the fastest I can repaint the display is twice per second. That's with a simple repaint, a clearScreen(1) followed by a single pixel paint per X (X is on the 320-pixel axis, Y is on the 240-pixel axis).

 

-- Tim --

 

In theory, you should be able to get up to 13fps when drawing full screen.

The only possible way to speed things up is to redraw your shapes with background color instead of using clearScreen.

 

If you want faster display, you should look for LCD with parallel connection, there are few of them available.

[TDHofstetter 1]

In theory, you should be able to get up to 13fps when drawing full screen.

The only possible way to speed things up is to redraw your shapes with background color instead of using clearScreen.

 

If you want faster display, you should look for LCD with parallel connection, there are few of them available.

Unfortunately, the shape data is random on every screen refresh, so I really need to wipe ahead of myself to eliminate any artifacts from the previous frame.

 

Now... would it help to install the LaunchPad's 32KHz crystal? I've read (but can't verify) that doing so would bump up the MSP430's clock rate, which might get me into the ballpark I'm shooting for. Have you tried running one of these displays on a crystal-installed LaunchPad? If installing the crystal WOULD bump up the LaunchPad's execution rate, I'm all for it. After all, clearing (or washing with some color) the screen does involve pushing 153,600 bytes across the serial bus to the display - a pretty heavy workload.

 

Thinking...

 

Lessee if I can find speed up the library code, optimizing strictly for this application.

 

Oh, and... lest I forget or neglect... thanks, Rob! These little displays are VERY NEAT.    8)

[RobG 1,892]

No, using crystal will not help.

 

Make sure your DCO is set to 16MHz, you are using hardware SPI, and USCI clock is 1:1.

[TDHofstetter 1]

Yep, definitely set to 16MHz (G2553); CCS recognizes the #define.

 

EDIT: There's an improvement - I modified your clearScreen() a little, and got some better performance:

void clearScreen(u_char blackWhite) {
    setArea(0, 0, getScreenWidth() - 1, getScreenHeight() - 1);
    setBackgroundColor(blackWhite ? 0x0000 : 0xFFFF);
    u_int w = getScreenWidth();
    u_int h = getScreenHeight();
    u_int Y = w;
    while (h != 0) {
        Y = w;
        while (Y != 0) {
            writeData(bgColorHighByte);
            writeData(bgColorLowByte);
            Y--;
        }
        h--;
    }
}

Note that I'm not calling getScreenWidth() on each h; instead, I'm using a single stored value.

 

EDIT II: It's a very SLIGHT improvement - all it's doing is eliminating one call (which eliminates some stack activity), but it's an improvement.

 

EDIT III: Got it. Your code is pretty tight, Rob... so I changed things a little by using only the upper 180 (of 240) pixel rows, wiping it with fillRect instead of clearScreen. Now I'm barely within my 150fpm (2.5fps) frame rate design limit. Now it's time to do the COOL stuff.    8)

 

I can use the lower 60 rows for other stuff, like a once-per-frame textual display.

[RobG 1,892]

Is anyone interested in creating Energia library for this BP? 

[Rei Vilo 695]

Is anyone interested in creating Energia library for this BP?

Sure, but I'd need one screen to proceed with the tests...

[RobG 1,892]

Sounds good. Can you email me your address?

[RobG 1,892]

New batch in store now.