0

Questions about the ILI9341 2.8" TFT LCD and driving it with
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Questions about the ILI9341 2.8" TFT LCD and driving it with

by samwarez on Sat Feb 16, 2019 2:52 pm

Background: I have a larger project (a robot, basically) that I am working on that I have decided needed a small dedicated remote control (not for direct control, just for enabling different modes, setting parameters, and reporting status). The requirements would be:
  • Small, I already have some enclosures that I think are perfect form factor (4.5” x 2.5” x 0.5”)
  • Must have a graphical display of some sort, I am imagining the UI looking like an old Tamagotchi so graphics will be simple. Low resolution and 8-bit color would be fine. Monochrome will work if need be, but it needs to be responsive, 2 fps is fine, but I don’t want to see it roll from top to bottom as it draws each row of pixels.
  • NLOS communication. Robot will be enclosed in some sort of plush fabric so an IR sensor might be difficult. Also, if I design for Bluetooth, I can make an app version of the remote.
  • Low power, I want the battery’s to last a while, at least a few days of standby

The original idea was to use a membrane keypad and simple graphical display (like one of those tricolor e-ink displays or a monochrome LCD). I have the parts to do that (except the display) but now it’s a backup if I cant get my current plan to work.

My plan was to use the Adafruit 2.8" TFT LCD with Touchscreen Breakout Board w/MicroSD Socket - ILI9341 to display the status screen on the top third and have the controls as a grid of icons on the rest. Nice thing about that is I can have the controls change as needed to create sub menus, and I could just load the icons and frames of animation (for the Tamagotchi-esque status screen) into the onboard SD-Card. The problem was that while testing with my Arduino UNO I found that loading the images from the SD-Card was just too slow. I figured that since the screen is the only thing that will need GPIO pins that I could improve performance by hooking it up in 8bit mode, but without the SD card how do I send the graphics to display?

    Question 1
    a) With the TFT screen wired in 8bit mode (or SPI for that matter) how do I send graphics to the display without using the SD-Card?
    b) would it be possible to load the images from the SD-Card into ram somewhere to get around the SD-Card bottleneck?

The next part is the microcontroller. I chose the Adafruit Feather nRF52840 Express as its super low power, has BTLE and a battery controller built right in. Space is tight, even with this tiny feather I am going to have to remove the SWD and battery connecter and solder the battery leads to the board. I am having trouble finding information on how to hook things up to it. First is the ILI9341 code examples I find don’t allow me to change the pins used for the data lines, I would need to map the data lines to 5-13 and D2, and the control lines to A0-A3, and I am not sure how to do that.
The second thing is this QSPI chip on the board that has 2MB of flash. I am guessing from the Adafruit documentation I could use this to drive the display via its SPI interface and store the graphics there.

Question 2
    a) I am going to try hooking up the screen to the nRF52840 via SPI this afternoon but that leaves me with the problem of offloading the bitmaps (or whatever format I use) from the SD-card. Is there a way I can load the images into the 1MB of Flash (or even the 2MB of QSPI Flash) and use them from there?
    b) How do I get the graphics library to work with a modified pinout?
    c) Is there a better guide as to what pins can be used for what? Like where are the missing data pins (D0, D1, D4, D7, D8)? Can I use pins like SCL,SCA as data lines?

And the ultimate questions:
    a) Is this hardware even capable of doing what I want?
    b) Is it a matter of fitting a square peg in a round hole?
    c) Is there a hammer large enough to make it work?
    d) And if not want would you recommend? I am not totally sold on the display module, its thick and complete overkill for the 8-bit graphics it will be displaying. If you know of a anything that would fit my needs better, I would love to hear it.
Thank you.

samwarez
 
Posts: 8
Joined: Sat Feb 16, 2019 2:47 pm

Re: Questions about the ILI9341 2.8" TFT LCD and driving it

by adafruit_support_mike on Sun Feb 17, 2019 2:12 am

As an initial point, 8-bit color is harder to do than 16-bit or 24-bit color.

Even when 8-bit games roamed the Earth, the TV could display a much wider range of colors. The 8-bit scheme was a way to conserve RAM (which was scarce and expensive) instead of a way to cope with the limits of the display. All the graphics processing was done on a raster with 1 byte per pixel, and when it was time to generate output to the TV, the bytes were used as index values into a list of of 256 pre-selected color values.

The displays we carry, including the ILI9341, have their own built-in array of RAM to hold pixel color data. 8-bit palettes are no longer necessary.

If you want to use bitmap graphics and update at speed, you'll need to use one of our microcontrollers that has an onboard Flash storage array.. bascially any board whose name includes the word 'Express'. The major limit on screen updates is the time it takes to get information from the SD card. Our Express boards have at least 2MB of QSPI Flash, which has data channels operating in parallel. It only takes 2 ticks of the QSPI clock to transfer 1 byte, which is faster than you can send data to the display.

The TFT FeatherWing is designed to be plug-and-play compatible with our Feather development boards, including the nRF52840:

https://www.adafruit.com/product/3315

samwarez wrote:Is there a way I can load the images into the 1MB of Flash (or even the 2MB of QSPI Flash) and use them from there?

If you use CircuitPython to write the code, storing bitmaps in the QSPI Flash is trivial: you just drop them onto the USB Mass Storage device created by the built-in UF2 bootloader.

It's also possible to use the QSPI array from C, but it uses a different library. You'd have to write a sketch that reads the images from an SD card and writes them into the QSPI Flash ahead of time. That's certainly possible though, and the QSPI is nonvolatile. The bitmaps will still be there after you load new firmware into the microcontroller.

samwarez wrote:b) How do I get the graphics library to work with a modified pinout?

You'd have to rewrite that library.

The existing 8-bit code is written so bytes can be loaded directly into an ATmega328's PORTB register, setting 8 GPIO pins simultaneously. Changing the pins, the bit order, or the microcontroller fundamentally breaks the code.

That isn't as much of a limitation as it sounds when you switch up to a 32-bit microcontroller. The ATmega328 runs at 16MHz, but the nRF52840 runs at 64MHz. You could set 8 nRF52840 pins individually in about the same amount of time it takes to set the whole ATmega328 PORTB register. 32-bit microcontrollers also tend to have convenience registers for setting and clearing bits, so you can set any group of pins high or low with a single assignment. You'd have to shuffle bits around to move each bit of image data to the correct pin location, but it's technically possible.

Try using the SPI interface first though. Once you take the SD card out of the loop, your frame rates get much faster.

adafruit_support_mike
 
Posts: 57106
Joined: Thu Feb 11, 2010 2:51 pm

Re: Questions about the ILI9341 2.8" TFT LCD and driving it

by samwarez on Sun Feb 17, 2019 2:03 pm

Thank you for the information, I am going to give SPI a real shot again. My focus with the reduced color pallet was mainly for smaller file sizes, less data to move from the SD card to whatever. That purple.bmp file used in the examples becomes ~8 times smaller with a 4 bit (turns out that what I wanted) pallet.

I like the idea of dropping in the files via USB with Circuitpython but the whole point of this board is the BTLE capability and it seems that is arduino only for now. As to the pinouts; I am hoping to at least find out how the pins are called internally. I have already used up all the numbered pins with the display, I need to know which pins I can use for the touch interface.

samwarez
 
Posts: 8
Joined: Sat Feb 16, 2019 2:47 pm

Re: Questions about the ILI9341 2.8" TFT LCD and driving it

by adafruit_support_mike on Mon Feb 18, 2019 1:59 am

Take a look at the Adafruit_SPIFlash library:

https://github.com/adafruit/Adafruit_SPIFlash

It provides FAT filesystem support on QPSI Flash chips.

adafruit_support_mike
 
Posts: 57106
Joined: Thu Feb 11, 2010 2:51 pm

Re: Questions about the ILI9341 2.8" TFT LCD and driving it

by samwarez on Tue Feb 19, 2019 1:21 am

Thank you, I am starting to make progress again. One strange thing I have discovered is that in order to program it I have to double tap on the reset button, and when I do so the feather shows up as a mass storage device on my computer (with a couple files on it). The really weird part is that it reports as being 4mb in size, but the documentation does not list any memory on the board that large. What is this? Its it the QSPI memory?

Also where can I find information on how to address the pins on this board? What are they called in the code? I have everything coming off the GPIO pins (including CLK and RST) because that's the only ones I have figured out how to address (just the number)

What I have now:
Code: Select all | TOGGLE FULL SIZE
#define TFT_DC 9
#define TFT_CS 10
#define TFT_MOSI 11
#define TFT_MISO 12
#define TFT_CLK 13
#define TFT_RST 5


But how do I address the MOSI, MISO, CLK, RST and the other pins?

samwarez
 
Posts: 8
Joined: Sat Feb 16, 2019 2:47 pm

Re: Questions about the ILI9341 2.8" TFT LCD and driving it

by adafruit_support_mike on Tue Feb 19, 2019 1:49 am

samwarez wrote:What is this? Its it the QSPI memory?

Not exactly.. it's the bootloader.

The UF2 bootloader hijacks the USB Mass Storage protocol to communicate with the computer. The bootloader creates what looks like a filesystem to the computer, but when the computer sends "give me a file listing" or "save a file here" messages, the bootloader shuffles things around and saves the data where it wants. Some information might go into the microcontroller's program memory, while other information might be stored on the QSPI Flash chip.

samwarez wrote:Also where can I find information on how to address the pins on this board? What are they called in the code?

The Pinout page in the tutorial lists everything:

https://learn.adafruit.com/introducing- ... er/pinouts

Generally speaking, the labels on the silkscreen are what you use in code. Digital pins are identified by number, while analog pins are identified by A0, A1, and so on. Pins with other functions, like MISO, MOSI, SCK, SDA, SCL, TX, and RX are handled as a group by the SPI, Wire, and Serial libraries. You don't talk to any of those directly, you just need to know their IDs so you can make the right wiring connections.

adafruit_support_mike
 
Posts: 57106
Joined: Thu Feb 11, 2010 2:51 pm

Re: Questions about the ILI9341 2.8" TFT LCD and driving it

by samwarez on Tue Feb 19, 2019 10:47 pm

So if I drop some bitmap files on there it will "shuffle" them to the QSPI?

I was asking about the pins because the examples I tried would not work unless I mapped those pins to the GPIO.

samwarez
 
Posts: 8
Joined: Sat Feb 16, 2019 2:47 pm

Re: Questions about the ILI9341 2.8" TFT LCD and driving it

by adafruit_support_mike on Thu Feb 21, 2019 2:07 am

samwarez wrote:So if I drop some bitmap files on there it will "shuffle" them to the QSPI?

Yes, but in a form designed to work with the CircuitPython interpreter. That isn't automatically the same as a FAT filesystem designed to work with C code.

samwarez wrote:I was asking about the pins because the examples I tried would not work unless I mapped those pins to the GPIO.

SPI uses a signal called CS to tell peripherals when to pay attention to what's happening on MOSI and MISO. If a device's CS pin is high, it ignores those lines. If its CS pin is low, it talks to the microcontroller.

The microcontroller needs one CS pin per SPI device it needs to control, but that pin only needs to go low when the microcontroller wants to start talking to a specific device, and go high when the microcontroller is done talking to that device. Any GPIO pin will work.

RST pins are hardware reset signals for external devices. Those also work on simple 'go low then go high' terms, and can be assigned to any of a microcontroller's GPIO pins.

adafruit_support_mike
 
Posts: 57106
Joined: Thu Feb 11, 2010 2:51 pm

Please be positive and constructive with your questions and comments.