Thanks for your mega-reply again.
It's just my verbose output, can't help it. Some dislike it a lot; I'm glad you find them helpful.
There is for example QFP44 0.8mm pitch to 44-pin DIP adapter,
5 adapters for 3.77€, although you need to use both straight and bent (90 degree) male pin headers, as there is no room for the middle ten pin holes. The pads are wide enough for bent pins. Just solder the holed ones first, then place the bent pins roughly at the right positions, attach female pin headers to the pins so they align the bent male pins, apply flux, and solder the bent pins in place. Easy-peasy. I would solder and clean and inspect the pins before soldering the chip.
I was counting pins, and can go for the 16-bit parralel mode, then i have PORTB for the 16 bits, and PORTA for the strobe + DC and UART.
For now i am trying the SPI version, and i can not get any result, i copyd all the initialize codes and it wont work.
What development environment (compiler and libraries) are you using?
(You might wish to look at e.g.
martnak's STM32-ILI9341 library, just to see if there are fundamental differences to your code.)
I took a look at my display modules with 2×20-pin header block at the end. I didn't realize how old they were
as they actually use the SSD1963 controller (a big chip on the actual board). (I even have the same/similar display, HannStar HSD043I9W1, with only a flat flex cable with some passives on it, and no controller.) The one ILI9341 display I have, has only a 14-pin connector on one end, and a 4-pin one on the other.
So, I'm afraid I
do not have an ILI9341 display I can connect using parallel, after all.
If you take a look at the ILI9341 320x240 display modules
at eBay, the 2.4" ones are listed first, and they have 18 pins on a flex cable. The end is 15.6mm wide, with the 18 pins at 0.8mm pitch, each pin 0.4mm wide.
The pinout isPin | Description | Pin | Description | Pin | Description |
1 | GND | 7 | SDO | 13 | LED-3 |
2 | /RESET | 8 | GND | 14 | LED-4 |
3 | SCL | 9 | VDD | 15 | XL (Touch) |
4 | RS | 10 | LED+ | 16 | YU (Touch) |
5 | /CS | 11 | LED-1 | 17 | XR (Touch) |
6 | SDA | 12 | LED-2 | 18 | YB (Touch) |
So, as you can see, only SPI is possible on these.
Some of the ones have a 37-pin flat flex cable, like
this one; as do most of the
3.2" ones. The end is 41.70mm wide, with 37 pins at 1mm pitch centered on it; each pin being 0.5mm wide. Their datasheet I found
here, and the pinout is
Pin | Description | Pin | Description | Pin | Description |
1 | GND | 13 | D4 | 25 | GND |
2 | VDD | 14 | D5 | 26 | Y- (Touch) |
3 | VDD | 15 | D6 | 27 | X- (Touch) |
4 | /CS | 16 | D7 | 28 | Y+ (Touch) |
5 | C/D | 17 | D8 | 29 | X+ (Touch) |
6 | WR | 18 | D9 | 30 | LED-1 |
7 | RD | 19 | D10 | 31 | LED-2 |
8 | /RESET | 20 | D11 | 32 | LED-3 |
9 | D0 | 21 | D12 | 33 | LED-4 |
10 | D1 | 22 | D13 | 34 | LED-5 |
11 | D2 | 23 | D14 | 35 | LED-6 |
12 | D3 | 24 | D15 | 36 | LED+ |
| | | | 37 | GND |
As you can see, these ones do not expose the SPI lines at all, only 16-bit parallel mode.
In both cases this is because the connectors do not expose all the ILI9341/ILI9341V signal lines, especially the IM0,IM1,IM2,IM3 lines that are used to select the communications method.
(The Touch pins are usually not connected to the ILI9341 at all, but to a separate narrow flat flex cable that goes to the resistive overlay on top of the display. Essentially, by reading the resistance using e.g. a simple voltage divider configuration and two ADC pins, you can detect touch by a significant reduction in resistance, with the exact resistance telling the position on the display.)
Since the boards are quite simple and relatively large, routing the signals is no problem, even for a beginner like me in say EasyEda or KiCad (both completely free); and you can get five boards made by jlcpcb for $2 + shipping, for less than 10€ total if you don't mind waiting. (The cheap shipping takes a couple of weeks at least to Europe; the DHL shipping costs more, but was quite nice, at least to Finland. I've only made some
silly stuff yet myself.)
In my opinion, rather than try to breadboard this, I'd just make a carrier board with an STM32MZ2048EFG064 (64-pin TQFP with 0.5mm pitch), the oscillator, the decoupling capacitors and oscillator capacitors, ICSP connector (PGE* pins), and Micro-USB female connector, all based on the STM32MZ family datasheet and reference manuals and application notes; a 3.3V low-drop regulator or better a DC-DC converter (noting that the display and your microcontroller may need quite a bit of power, so I'd shoot for 2A current capability at least; and the DC-DC converter is better if you intend battery operation) with at least two sources (USB 5V and another one), using either Schottky diodes or better yet, P-MOSFETs in reverse voltage protection configuration; plus the 37-pin
0.8 1.0 mm pitch connector for the flat cable.
I would use the parallel master port for DMA'ing commands/data from the master microcontroller in parallel form, in addition to a well-routed (for several megabaud) UART, and use the 16 port B pins to connect to the display. This way, the DMA would be used to receive and buffer data from the master controller (whether using 8+1 parallel pins or UART; or USB when testing), and the main loop would try to keep the display update faster than its refresh rate, and split its time between parsing commands/data from the main microcontroller, and updating the actual display.
The MicroSD card connector is trivial, because at 3.3V logic levels, you simply connect the pins directly to the microcontroller: microSD cards expose a SPI interface! If it is not close to the microcontroller at all, you might add a 100nF bypass capacitor for the VDD line near the connector, but that's it. I wouldn't put it near the display, but somewhere closer to the main microcontroller.
(Note: I did not pull the text for this message out from thin air, or for this post alone; like I said, I've been thinking about this, except for using a different microcontroller, Teensy 4.0, with a NXP i.MX RT1062 "microcontroller" (they call it a crossover processor), that PJRC.com provides a very nice (but not yet complete) Arduino Core for, Teensyduino. I've even thought about a middleman expander processor, using some cheap 8-bit AVR or similar, that could expand 1-8 bit input (serial or parallel, dunno) to 18-bit parallel output via palettes, so that a main processor would only need a few data lines to the middleman processor, send it the various palettes the tiles need, then send all graphics data to the middleman processor in say 8x8 pixel chunks (1-8 bits per pixel, so 64 to 512 bits), in a simple message style that contains the tile location (at pixel precision), palette identifier, and the data depth. The middleman processor then expands that data to the full 16/18-bit data with proper command-data sequence as fast as it can. It wouldn't need that much memory, just 128 bytes for a full 8×8 pixel chunk, some memory for the palettes (the more the better), and a bit of a buffer for data coming from the master processor. So, I've thought about this some.
)
O no, now my plan falls in the water, that is the nice part about these displays.
Eh? PIC32MX and PIC32MZ both use 3.3V signal levels (although some pins are 5V tolerant), so you can just wire a microSD card connector directly to the microcontroller pins. No components of any kind needed:
MicroSD Pin | Description (SPI mode) | Connect to PIC32 |
1 | NC | No connection |
2 | /CS | SPI Chip Select pin |
3 | DI | SPI MOSI (data out on PIC32) pin |
4 | VDD | 3.3V |
5 | CLK | SPI Clock pin |
6 | VSS | GND |
7 | DO | SPI MISO (data in on PIC32) pin |
8 | RV | No connection |
Again, if the VDD is far from the supply bypass capacitors, add a 100nF ceramic capacitor near the connector between VDD and VSS. Normally it is not needed, so I would have a suitable footprint for a 0805 cap, but leave it unpopulated for now.
If the DI-MOSI and/or DO-MISO lines are long, isolating them with ground around them is a good idea. If you use cables, some kind of shielded cable, with with the shield connected to the connector shield but not to the VSS/GND pin on the connector (that is, not making an antenna loop of it!) and to GND on the microcontroller side, would probably work. I might use twisted pairs for the DI-MOSI, DO-MISO, CLK, and /CS lines, with their ground wire of each pair only connected at the microSD card connector end, and there to the VSS/GND pin. Essentially, the shield would be an extension of the ground plane on your boards, with the GND going on a separate wire to the connector VSS/GND pin, and there connected to the ground lines of the twisted pairs of the signal lines. At the connector end, the shield and the VSS/GND might be at slightly different potentials, but correctly referenced wrt. signal levels from the microSD card perspective. Or better yet, ask the Gurus here about how to do such a shielded short cable grounding properly!
For ILI9431, setting the region to be updated by consecutive data sent to the display takes 10 bytes or pixels worth of data.
So the best is to keep it running.
Yes. That is, sending small damaged regions is not fast because the overhead is large, about 10 pixels, but also stops DMA. If you use DMA for receiving data from the master processor, so the graphics processor main routines work on processing and sending the data to the display module (interspersed with parsing and handling the commands from the master processor from already-received buffers), then it matters less; really, only about 11 pixels. So in that case, 4×4-pixel damage regions might work even better, although then the math gets nastier (as you need more than one word for all damage bits in one row/column of the display, increasing the "cost" of
marking damage)... so maybe 8×8-pixel damage regions work better for 320x240 displays.