Jump to content
43oh

2.2" 320x240 Color LCD Booster Pack


Recommended Posts

  • 1 month later...
  • 6 months later...

New version is available.


New in v3:


- no MOSI/MISO config


- no optional memory


- 4 configuration jumpers CS_Display, CS_SD, D/C, and BKG (choose legacy pinout or compliant with new LPs.)



Pos/Pin CS_Dis CS_SD D/C BKG
New(1) P2.5 P2.4 P1.3 P2.0
Legacy(2) P1.0 P2.5 P1.4 P2.2
Link to post
Share on other sites

Quick review of the V2 board I got this weekend. 

 

Porting an existing TFT driver from a similar board (say google for TFT01-2.2SP) was trivial. Only 2 sticky points were that the RESET signal was not hooked up (no idea whether this is a problem, but it's easy enough to do with a solder bridge), and that the LEDA input that was available to be driven via GPIO on the other TFT was tied to VCC all the time (although rereading the specs, I am also not that sure whether it's wise to tie LEDA to a GPIO ;-)). Otherwise it just came up with only the necessary changes for the GPIO pins in use. The ILI9341 seemed to work at 13.333MHz, but the spec says it should be only using up to 10MHz. With the other TFT I could not read back data from the ILI9341, so this needs to be seen with this device.

 

The ILI9341 is a rather cool controller, except that I have been unable to find any source out there that would make use of it's advanced features. Especially the gamma correction and the adaptive brightness filtering seem to be of interest. 

 

My file system code that originally was using SSI0 also came up the first time after changing the port settings. Only tricky part is that the V2 board shares one SPI between 3 devices (my board has a 25AA512 on it (BIG, GREAT, THANX TO ROBG !!!). So all of them need to be tied to H during initialization. The microSD slot is just awesome. On the before mentioned TFT I had issues going beyond 10MHz, but with this BP it worked right out of the box @ 20MHz. Haven't done a throughput test, but this should allow for about 2.2MB/sec read/write speed.

 

Haven't played yet with the 25AA512, due to a lack of time. Really looking forward to that part, as it allows me to do data logging (my target is an autonomous rover for AVC 2014), without having the potential long delays that a SD card has. So it's kind of my black box.

 

What do I not like about the board ? Mainly that DC is on PORT E (same for V3), which all the other relevant signals other than SSI2 are on PORT A. Would have been nice to have DC on PA5 for the Stellaris Launchpad.  

 

What do I like about the board ? Everything. It's formfactor is a biggy for me. It allows for installation with stackable headers. So instead of having wire all around it cleanly fits ontop of the Launchpad. Less things that can go wrong. For my specific task it's a 3-in-1.

 

- Thomas

 

PS: I'll put up some TFT code this week. Perhaps it's useful for other folks using this great booster pack.

Link to post
Share on other sites

Thanks for the review @@BizzaBoy!

 

 

...Only 2 sticky points were that the RESET signal was not hooked up (no idea whether this is a problem, but it's easy enough to do with a solder bridge), and that the LEDA input that was available to be driven via GPIO on the other TFT was tied to VCC all the time (although rereading the specs, I am also not that sure whether it's wise to tie LEDA to a GPIO ;-)). Otherwise it just came up with only the necessary changes for the GPIO pins in

 

1. LCD's RST uses RC (to free up one pin, original G2 LP had very few of them) but there's a jumper which will connect it to MCU.

2. Driving backlight LEDs(4) from Tiva's GPIO is not a good idea :)

 

...Haven't played yet with the 25AA512, due to a lack of time. Really looking forward to that part, as it allows me to do data logging (my target is an autonomous rover for AVC 2014), without having the potential long delays that a SD card has. So it's kind of my black box.

 

3. I have memory library that I am using with this BP, see 43oh forum.

 

 

...What do I not like about the board ? Mainly that DC is on PORT E (same for V3), which all the other relevant signals other than SSI2 are on PORT A. Would have been nice to have DC on PA5 for the Stellaris Launchpad.

 

4. On v2 board, DC is tied to J1.06 (PE5 or P1.4 on G2) because it was the best option at the time (G2 was the first LP.)

5. On v3, I moved DC to J1.05 to comply with BoosterPack pinout standard (use GPIO pin instead of Analog pin,) but you can still use J1.06. In fact, since DC is connected to pins via 3 way solder jumper, you can unsolder it and run a jumper wire to any other pin.

 

...The ILI9341 seemed to work at 13.333MHz, but the spec says it should be only using up to 10MHz. With the other TFT I could not read back data from the ILI9341, so this needs to be seen with this device.

 

6. I am running ILI9341 @16MHz and it works fine. BTW, ILI9340 is 15.15MHz, so I wonder if 10MHz spec is a typo.

7. You can read data from this LCD but it's tricky. See my ugl16 library on 43oh forum, there are few read functions in that lib.

Link to post
Share on other sites

6. I am running ILI9341 @16MHz and it works fine. BTW, ILI9340 is 15.15MHz, so I wonder if 10MHz spec is a typo.

7. You can read data from this LCD but it's tricky. See my ugl16 library on 43oh forum, there are few read functions in that lib.

 

Not sure about whether this is a typo. The other timing parameters (SCL low, SCL high) got adjusted as well ... BTW, how do you get 16MHz on SSI ? Running of PIOSC ?

 

The readback is ULTRA tricky. The data sheet for the ILI9341 states that the SCL cycle time needs to be 150ns (not 100ns) for read operations. So you need to switch SSI setup between read and write. That ontop of having to switch between TFT (10MHz) and SDCARD (20MHz) anyway. I'm not sure whether the complexity is worth it. 

 

Thanx for pointing out the booster pack standard. A great help for my own project GPIO assignment (so that I don't trample on possible booster packs that I may want to use).

 

- Thomas

Link to post
Share on other sites

Well, from my experience, datasheets created by CN manufacturers are full of mistakes (copy/pasted sections from other products, different datasheets/specs for the same product, etc.,) so nothing surprises me anymore.

 

I get 16MHz SPI on MSP430. In fact, I have used it with even faster clock (25MHz on F5529)

 

When reading from LCD (in my MSP430 lib,) I change SPI clock to /2 and then back to /1 when done reading, so no big deal. CS has to be asserted during the entire read process. Pixel data is returned in 24bit RGB format, so you have to convert it to 16bit 5-6-5 format. Reading ID is where the tricky part begins, standard procedure or registers do not work (it's possible that datasheet provides steps for vanilla version of the chip and not for vendor specific or it could simply be inaccurate datasheet.) You have to add extra steps for reading external registers.

Link to post
Share on other sites

Here some quick and dirty code the the BP. Perhaps this is useful for other folks.

 

API:

 

extern void tft_init(uint32_t yt, uint32_t yb, const tft_font_t *font);
extern void tft_terminal(const char *s);
extern void tft_draw_point(uint32_t x, uint32_t y, uint16_t color);
extern void tft_draw_line(uint32_t x1, uint32_t y1, uint32_t x2, uint32_t y2, uint16_t color);
extern void tft_draw_rectangle(uint32_t x, uint32_t y, uint32_t w, uint32_t h, uint16_t color);
extern void tft_draw_string(uint32_t x, uint32_t y, const char *string, uint32_t length, const tft_font_t *font, uint16_t color0, uint16_t color1, int transparent);
extern void tft_fill_rectangle(uint32_t x, uint32_t y, uint32_t w, uint32_t h, uint16_t color);
extern void tft_write_image(uint32_t x, uint32_t y, uint32_t w, uint32_t h, const uint8_t *data, const uint16_t *palette, int compressed);
 
The key thing is that with tft_init() you pass a "yt" and "yb". The area between those 2 y-coordinates is used for an ANSI terminal emulator that uses "font" for drawing. tft_terminal() simply outputs a '\0' terminated string. It does scroll, and it does support pretty much whatever the old MS-DOS ANSI.SYS supports (and xterm and gone-terminal, and cmd.exe ;-)). That's kind of important to my project as part of the TFT will be used simply for logging information, just like a serial terminal.
 
There are right now 3 fonts, 6x8, 8x10 and 12x16. The font bitmaps are bit packed, MSB first.
 
tft_write_image() can write normal 8bpp images, whereby a palette is used. Or it can write RLE compressed images, ala TGA spec (not the convoluted BMP spec). I'd assume I'll use that to have GUI elements that get thrown onto the TFT.
 
Colors are 16 bits, RGB565 (i.e. red is in the upper bits). There is a tft_xlate_color() function to make the r/g/b values to this packed format.
 
In the sources there is <kernel.h> and dly_tsk() used. This is for my uITRON RTOS, and basically I left it there so everybody stumbles over it and realizes that "dly_tsk" is needed to add a 120ms delay after the power on reset ;-)
 
The SPI port setup is somewhat tricky. One needs the 8MA drive setting, or there is noise on the line from an SDCARD (that took me a tad of time to debug). The MOTOROLA format uses SPH/SPO over the standard to get rid of the extra clock cycle at the end of a 8/16 bit transmission. I did exclude the code that has RTOS style SPI port locking, but it's easy to guess where the mutexes would go. However the support for SPI port sharing is already there.
 
The rest of the code is fairly standard ...
 
- Thomas

tft.c

tft.h

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...