ILI9341 mental support

[Jan Audio]

Thanks for your mega-reply again.
Those DIP adapters have dual row pin header, i dont know how to use it, if the rows was real 40DIP on both sides i will buy, cant find those on ebay right now.

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.

[Jan Audio]

(I have a couple of those displays, with a resistive touchscreen on top.  The SD card connector on them is usually not worth trying to use; I think the traces pick up too much noise from the actual display or something.)

O no, now my plan falls in the water, that is the nice part about these displays.
Maybe use 1 SPI, so there is no noise ?, stop updating while reading card, or you still have noise then ?

For ILI9431, setting the region to be updated by consecutive data sent to the display takes 10 bytes or pixels worth of data.  The D/CX pin controls whether a command or data is sent, so data and commands may be impossible to mix in DMA transfers; you'll need at least an interrupt in between to flip the D/CX pin.

So the best is to keep it running.

[Nominal Animal]

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 is

Pin	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.

[Jan Audio]

If i see one with flex-cable i dont want it.
I have problems with flex-cable and like my connections soldered.
I do see the benefits of having total control over the display.

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.

Thank you for the link, only why are those pins missing ?
Is there not anyone with 40 pins accessible ?

[Nominal Animal]

The holes for the middle ten pins would interfere with the chip.  If you put the chip in any other orientation, then the pin rows would be have to be further away apart.

I drew a proof-of-concept PCB here, intended for the 44-pin PIC32MX170B256D-I/PT:

The two rows skip four pin rows (and are thus half an inch apart), except at the center, where they skip six pin rows; i.e, at the center, they occupy three pin columns on each side of the divide on typical breadboards, and elsewhere two pin columns on each side of the divide.  In the editor, the button with a folder and a G will allow you to order it from JLCPCB, $5 for ten boards.  I wouldn't order it yet, though; I'd consider adding the crystal etc. to this board first.  You can freely edit and create derivatives of it; my design part of it is public domain.

As to flat flex, it's only the end you need to solder to the board, and it's easy with a chisel tip and thin soldering wire; just look up some Youtube videos.

[Jan Audio]

I would like female headers on the MCLR and programming pins, then those pins no need for as i/o, also can combine + and - add ceramic caps,
crystal also nice, internal will do,
at the end you have a normal chip again fully functional.
Nice idea.

I mean : cant you make it less skinny so the whole thing is 1 row bigger ?, instead of SPDIP-40 do DIP-40.

[Nominal Animal]

I would like female headers on the MCLR and programming pins, then those pins no need for as i/o, also can combine + and - add ceramic caps,
crystal also nice, internal will do, at the end you have a normal chip again fully functional.

Exactly; and that isn't at all hard to do in EasyEda, KiCad etc.

I mean : cant you make it less skinny so the whole thing is 1 row bigger ?, instead of SPDIP-40 do DIP-40.

Of course, but then there is really not much room on the breadboard left (one row on each side), so it would make more sense to just use male pins on it anyway, in any shape.  Instead of male-male jumpers, you'd use male-female ones.  There doesn't seem much sense for the board to sit on the breadboard if only one pin is exposed on either side!

BTW, that's why the existing TQFP44-DIP44 adapters don't have the 5+5 holes, only pads, in the center: that way it can be narrow enough to make breadboarding easier.  I wasn't sure if the MCUs have a ground pad underneath, so I avoided putting any vias underneath, but if the chosen MCU does not have a ground pad, then there's plenty of room to put vias inside the footprint, and route the signals on the other layer.  Even multi-layer boards don't cost too much nowadays, so using a four-layer board is another possibility -- although my traces are quite fat, much narrower traces will work fine for signals at least.

There is no requirement for the pin header pinout to be the same as the chip itself; there is quite a lot of room to route the signals, so if you have certain uses in mind for certain pins, it might make sense to group those, and mark them on the silkscreen.

Thing is, you should really consider which microcontroller to use for the graphics first.  If you already have a bunch of PIC32MX170B chips, then it might make a lot of sense using those, but personally I'd consider higher-memory (512k, preferably!) ones instead.  I myself am leaning towards SAM chips.

I'd also wire the USB connector to the chip, so that one can write the graphics processing in isolation first; providing the data via USB from a computer.  Not only do you get visual results faster, but you keep the development area small, so that when bugs do occur, you don't need to reach for your oscilloscope or logic analyzer first to find out where the bug is; you know it has to be in the graphics processing part, because the USB side of stuff is off-the-shelf stuff, unlikely to get wrong (unless you write your own USB stack, which I do not recommend!).

If I do a real version of this, I'll definitely do one with 16-bit parallel data with pads for a flex connector, so that only the "extra" pins are routed out; with at least one SPI bus used for microSD card socket, and the USB connector also populated.  I can help you do yours, but if you are serious about finishing your project, doing some experimental boards using EasyEda/KiCad early will open up things you might not have considered yet.  For example, you might wish to use the board for the display and graphics processor as a structural unit in your console; see my Pro Micro Gamepad as an example.  (It's a < 10cm×10cm board, that gets snapped in half, giving you a top and a bottom panel for a 8-button gamepad with a small 128×32 OLED display, GND-VCC-SCL-SDA pinout, about 2€ at eBay.  Pro Micro clones are programmed as Arduino Leonardos in the Arduino environment, and have an Atmel ATmega32u4 microcontroller, with native full-speed (12 Mbit/s) USB support, so this gamepad can be a true USB HID device, and doesn't need any drivers for any OS.)

At this moment, it looks like I don't have a (non-ancient) display module with a flat flex with parallel on it, so I'm not even sure which display module (which driver type - ILI9341, ILI9488, ST7789) to target myself.  I'd prefer to have at least two or three of the displays, because I'm pretty sure I'll bumble and burn at least one, possibly more.

[Jan Audio]

I know i will ruin it with the flex connector.
Maybe my display is broken, getting paranoid here, the code is just wrong.
Yes i am serious only after days of trying i have more things to do.
Maybe i try with a trustee 8-bit chip, new to PIC32.

[Nominal Animal]

Do you have a picture of or a link to the 3.2" (parallel) display?

Here is my 2.8" SPI 320x240 ILI9341 display:

Is it this one, or the 3.2" that you are having trouble getting anything working with?
This one only supports SPI.

To use this one with a microcontroller with 3.3V logic levels, it is best to bridge the J1 pads, and supply 3.3V to the VCC (bottom) pin, especially if the pins on your microcontroller are not 5V tolerant.  (The SD card connector should only be used with 3.3V logic level boards.)
GND is ground, connected to the ground on your microcontroller.
CS pin is low (0) when active.
RESET pin should be high (1); and pulled low (0) to reset the display.
D/C pin is low (0) for command (and only for the command byte), high (1) for data (including command parameters).
SDI/MOSI is the SPI data signal from the microcontroller to the display (MOSI).
SCK is the SPI clock signal from the microcontroller to the display.
LED controls the backlight; I'm not 100% sure if it is on when high or low.  There should be a transistor or MOSFET there, affecting the logic.
SDO/MISO is the SPI data signal from the display to the microcontroller (MISO).

The upper 5 pins (lower right corner in the picture) are a second SPI bus for the touch controller; the black chip is an XPT2046, a SPI ADC used for the resistive touchscreen.
The right side (left side in the picture) four pins are the third SPI bus for the SD card.  There is literally no logic on that, just the connector.

I do not think this will work on a breadboard, because of the stray capacitances with the connections.  You should use jumpers directly.

[Jan Audio]

Ah, i thought i could slow down the clock maybe for testing first ?, or dont it react to to slow clock speeds ?

For the rest i got all that and like to note there should be a big resistor on the LED, not just a 1K, it can have a higher value resistor.

[Nominal Animal]

I haven't verified how slow the display can go, but the datasheet does not list any maximums (minimum frequencies), other than rise and fall times.
So yeah, you can use a slow core clock, and/or add extra delays in the code.

Hmmm... Should I do a small flat flex to DIP adapter?  Drag soldering with a chisel tip, with properly tinned and fluxed pads on board, is not supposed to be difficult.  I most worry about not moving the flat flex too much; I'm afraid the traces will fracture from fatique.


I found a couple more displays I thought I had, but had secreted away (okay, they were in a box I didn't check).
One is a mcufriend 2.4" TFT LCD shield, with a button and a microSD socket at one end, and Arduino-compatible pin rows on the sides:

Note that this one is the model without a 3.3V regulator, and I'm not exactly sure which controller it uses.  The resistive touchscreen 4-pin flat flex connects to the display flat flex cable, which ends with a 44-pin connector with a 0.8mm pitch.

The other is a very similar 3.5" TFT LCD Shield:

This one does have a 3.3V regulator, and I'm similarly not sure which controller it uses.  This one is fairly hard to disassemble, because it uses wide strips of thick two-sided adhesive (instead of the standard thin strips).  The glue does not come off, it can only be pushed aside.  After a lot of carefulling, I managed to release the display module.  It too has a 44-pin connector with a 0.8mm pitch.

The controllers on mine can be ILI9486, ILI9486L, ILI9488, HX8357D or MZ61581, and although the pinout should be the same, there are no guarantees.

What I'd like, is a 320x240 or 320x480 display with an IPS panel, and the ability to do 9-bit transfers.  I could use up to 16 pins on the same port, with the WR and RD strobes connected to (different) SPI data lines, also connected to the interrupt pins that allow an IRQ at a falling edge.  Then, a DMA sending dummy data to that SPI port triggers the IRQ on its falling edge, which in turn triggers a DMA transfer to an 16-bit I/O port (at least 10 pins used, 9 of which must be continuous).  A high bit of that port is connected to the C/D pin, so I could do DMA to the display using parallel mode.  It would need 32 bits (4 bytes) of DMA buffer per 18-bit pixel, and 16 bits (2 bytes) to transfer each command or parameter or register byte.

Of course the same also works with 8-bit parallel modes, where you'd use 32 bits/4 bytes of buffer per pixel, and 16 bits/2 bytes of buffer per command or parameter byte, 32 bits/4 bytes per command or parameter byte when mixed with data, but I feel the 2x overhead a bit heavy; at least with 9 bits you get 18-bit color instead of 16-bit color.  12-bit parallel would be even better (for 24-bit color), but I haven't seen any controllers that support that (at least not for these kinds of display sizes).

[Nominal Animal]

As it happens, another box I had overlooked contained an 2.8" 320x240 IPS panel with ILI9325 controller with a 37-pin "standard" flat flex.  I am not absolutely certain whether this is 8/16-bit only (IM0 exposed, with IM1-IM3 all ) or whether it can do 9-bit also: it is unclear whether pin 21 is IM3, FMARK, or not connected.  I've left a question for the seller, but we'll see.  (The flat flex cable itself has two suspicious-looking unpopulated resistors also on inside; those could be IMx also.  No hope of finding that out from the seller, though...)

Some spelunking around the web indicates that ILI9341 displays with a 45-pin or 50-pin flat flex cable have the IM0-IM3 pins exposed, so that the comms mode can be selected.  In particular, 'buydisplay' sells such displays, and they have pretty good documentation, too.  So, when the virus craze blows over, I think I might buy this one without touch panel, but with the ZIF connector.  The zero-insertion-force connector has the same footprint, so it isn't any easier or harder to solder, but at least then one doesn't need to solder the flat flex directly.  I think the scheme I outlined in my previous message, with this display and a PIC32MZ1024EFG-064, for 16/18-bit color and DMA (although using 32bits of RAM per pixel, 16bits per command/parameter byte), would work.  If I make anything, it'll be public domain, and shown on my EasyEda page.

Oh, and apologies for "spamming" this thread.

[Nominal Animal]

I also modified the TQFP44-DIP adapter; now it is rectangular, 8-by-22 units (board 0.9" by 2.3"), and completely single-sided.  The only 'trick' is that there are four pairs of pins that are swapped, so you need to be careful with the pin ordering:

You'll probably want to solder the chip before soldering any pins.

Again, it is in public domain, so if you want to make your own derivative or have it made, feel free!

[Jan Audio]

Well, where can i buy it ?
I make foto today.

[Jan Audio]

I really would like it smaller with less pins, with a female header for programming, smaller is better.
You could also have a grounded DIP switch in case of a leftover pin.

The + and - are multiple pins, all can be combined to 2 pins with a 2 x ceramic 100n on the print, also the VCAP 10U.

[Nominal Animal]

In the Open Hardware sub-forum, RoadRunner aka CircuitValley.com showed a 64-pin breadboardable PIC32MZ board, Zwei2, that can take any 64-pin TQFP PIC32MZ's.  He even sells unpopulated boards (for 10€ as of 2020-02-08).

I already asked permission, and got it, so I'll see how hard it is to adapt that for 44-pin PIC32MX170F256D-I/PT (44-pin TQFP with 0.8mm pitch) for you; but note that the Zwei2 is already tested and known to work, so perhaps it would be better to just switch to PIC32MZ instead (PIC32MZ1024EFG064-I/PT, 64-pin TQFP with 0.5mm pitch would be my choice.  If I end up doing that blitter board at some point, this is most likely the MCU I'd use; I'd also target PlatformIO with ChipKit core for PIC32MZ.)

How about using pads instead of through holes for the PIC32MX170F256D-I/PT, so one could solder standard ribbon cable ends, parallel to the board, instead of pins?  Because they are only on one side of the board, it might make the design easier; they definitely take less space.  Typical ribbon cables have 50mil pitch, or 1.27mm per wire.  Besides, there has to be something interesting/new in the approach for it to be worth poring over the datasheets and such... 

If you wanted to make e.g. my TQFP44-0.8 to DIP adapter, click the Open in editor button under the board. That opens it in the EasyEda editor.  There is a row of icons at the top.  The one with the G in it, Generate Fabrication File (Gerber), allows you to either generate the gerbers (for board production anywhere), or directly order the board from JLCPCB.  (The DRC check is Design Rules Check, that verifies that traces are not too close to each other and so on; it's a good idea to always run it.)

Another way is to generate the gerbers, by pressing the Generate Gerber button at the bottom of the subwindow.  This starts a download of a ZIP file, that contains the various Gerber layers.  Just save this file.  Then, go to the board manufacturer you prefer.  At JLCPCB, use the Order now button in upper right corner.  You'll get a view with a Add your Gerber button; click that, and select the ZIP file containing the Gerber layers.  As it has uploaded, you'll see a rendering of the board front and back, and you can choose the options.
As of 2020-02-08, five boards delivered to Finland costs 1.83€ + 9.51€ shipping via ePacket, so this is not expensive at all.  Of course, the virus craze is hampering everything, so I personally would wait until it blows over.

At PCBWay, the process is similar, just in a different order.  It starts with the PCB Instant Quote.  You supply the board details and settings (this one is 55.9mm by 20.3mm), shipping, your e-mail address, and add it to the cart; then upload the Gerbers in the same way.  The quoted cost for this board is USD $12 for five boards, but again, the virus craze is hampering everything.

There are other board fabricators with similar web interfaces, too; even a broke-ass uncle bumblefuck like me can afford this as a hobby.

Although I'd personally gladly pay RoadRunner/CircuitValley.com for the PIC32MZ boards, as they are Open Source Hardware, you can just grab the Gerbers from the GitHub repo, make a ZIP archive out of them, and just order the boards yourself.

Designing ones ownt boards can be intimidating, especially for the first one, but a LOT of fun too.  Usually, it's the footprints that one gets wrong... That's why I've been very careful to specify the 44-pin TQFP with 0.8mm pitch for PIC32MX170F256D-I/PT and 64-pin TQFP with 0.5mm pitch for PIC32MZ1024EFG064-I/PT; I do not just trust the editor or libraries, but check the actual measurements.  Also, on a dense board, you'll want to think about the order in which components can be soldered, if you prefer a soldering iron instead of a hot air gun or a reflow over like I do.  The soldering iron tip is relatively big compared to the pins, and a thicker chisel tip (and flux and solder wick for removing extra globs) is easier than a thin tip; good leaded solder (lower melting temperature) and a temperature-controlled iron makes a world of difference to me.  When I used an Antex 25W iron, although it is not a bad iron, I did manage to rip off a pad (leadfree solder and whatnot) of a rather expensive early Linux SBC.

TQFP and flat flex connectors can be drag soldered with a chisel tip; this youtube video shows how.
(Kimwipes are lint-free cleaning wipes.  Instead of IPA (isopropyl alcohol), I use pure acetone, low-lint paper towels, and cotton swabs; the kind that you're not allowed to put in your ear, but everyone uses to clean their ears with.  I like eutectic 63-37 leaded solder, as it melts at a low temperature and solidifies uniformly; it helps me not burn delicate components. Liquid, or gooey flux like Louis Rossmann uses, helps: solder "sticks" better, and you get better joints.  Solder wick/braid helps remove excess solder; using thinner soldering wire helps using less solder at once.)

I'm telling you, if I can do it, you can do it too.

[Jan Audio]

[Nominal Animal]

I would recommend dropping the SD and Touch pins for initial testing, connecting only the minimum necessary for the display to work.

The reason is, I'm such a sausage finger that I must reduce the possible sources for bugs when I develop stuff.  That way, I don't need to worry about too many things, and bugs are most likely to occur in the section I'm working on.  (Sometimes there are interactions, but they are surprisingly rare.)

This is close to "unit testing" in the software world.  I'm not recommending it because it is fashionable; I'm only recommending it because if it helps me make things successfully, it works. 


Hey, you don't have the CS pin connected!  It must be pulled low (GND) for the display to react to communications; when it is high (or floating/not connected, I suspect), the display assumes the data on the pins is intended for somebody else.

[Jan Audio]

This display is only for parralel or not ?

[Nominal Animal]

Looks like it is 16-bit parallel only, because I don't see anything resembling the IMx pins.
The T_ pins are for the touch controller; I believe it could be an XPT2046 or similar SPI ADC.
The SD_ pins are for the SD card.

It is possible for the T_ pins to be shared with the TFT, in which case F_CS is the TFT SPI Chip Select pin.  I can't tell for sure, because I don't see how the traces go.  If they terminate in the XPT2046/similar ADC chip, without vias on the same traces, then there is no SPI support for the display itself.  If the traces do go past, then there likely are some unpopulated pads, similar to J1, that are actually connected to the IMx pins on the ILI9341, so that one can choose which one is being used.  Again, otherwise no SPI support for the TFT.

Can you post a full image of the board, or a link to where you got it, so I can check?

I believe you need to connect the following pins for 16-bit parallel:

TFT pin	PIC32 pin	Purpose
REST	Any output pin	Reset. When pulled LOW/0 for a few milliseconds, the display is reset.  During normal operation, keep HIGH/1.
CS	Any output pin	Chip Select. TFT only cares about other pins (except REST) when this is LOW/0.
RS	Any output pin	Register/Data. This is LOW/0 for the command byte, HIGH/1 for parameters and pixel data.
WR	Any output pin	Write strobe.  The TFT will latch data pins on a rising edge (LOW/0 to HIGH/1).
RD	Any output pin	Read strobe. The TFT will start setting up the data pins on a falling edge (HIGH/1 to LOW/0), and the MCU is supposed to latch the data pins on a rising edge (LOW/0 to HIGH/1).
DB0..DB7	Low 8 I/O pins	Pins used for commands and parameters; and five blue bits and three least significant green bits for pixel data.
DB8..DB15	High 8 I/O pins	Pins used for the three most significant green bits and five red bits for pixel data.
GND	GND	Ground
VCC	3.3V	Bridge the J1 pads near the 3-pin voltage regulator.  This ensures the logic levels do not exceed 3.3V.

I would use port B for the DB0..15 pins.  On the 28-pin SOIC, they are pins 4,5,6,7,11,14,15,16, 17,18,21,22,23,24,25,26.  On the 44-pin TQFP, they are pins 21,22,23,24,33,41,42,43, 44,1,8,9,10,11,14,15.  You can just wire CS directly to GND, and save one output pin; then, the TFT is the only device listening to the MCU on those pins, listening all the time.  Similarly, you can put say a 10kOhm resistor between VCC and REST, and wire a push button between REST and GND.  That way you can reset the display by hand, and save another output pin.  It is safe to just power-cycle the display, though; the reset signal isn't really useful outside of development and debugging, in my opinion.

Do you need some pseudocode for the sending and receiving part?

[Jan Audio]

Why would you want to receive ?
I am planning write only.

Thanks dont need no code, just some color in my screen.
You can always post it if you like, always nice.

btw : 10 dollar for a DIP converter is to much.

[Nominal Animal]

Why would you want to receive ?

At the initialization stage, you can obtain the display ID; that way the same microcontroller/board firmware can support multiple near-compatible displays.

btw : 10 dollar for a DIP converter is to much.

Zwei isn't a DIP converter, it is a full development board for 64-pin TQFP PIC32MZ's.

Also, that is the reason it makes sense to make a board that is not just a DIP converter, but contains the desired passives (decoupling capacitors, crystal) and connectors (USB, programming, display et cetera) in desired footprints.

[Jan Audio]

[Nominal Animal]

It is the same display as this over at the Arduino forums, a TFT_320QDT_9341.

If you detach the display from the board, it has a 37-pin flat flex cable soldered to the board.  It is most likely that the pin 11 is IM0, and is being pulled to VCC via one of the resistors on board; the resistor could, unfortunately, also be on the flat flex cable.  Changing that to GND will change it to 8-bit parallel.

Because it has the "standard" 37-pin interface (the pinouts do seem to vary a bit -- one can check a few of the pins on the board with a multimeter in continuity/beep mode, to see which pinout it is), it does only seem to support parallel connection, and not serial at all.

At this point, I'd say you can only use this display in 16-bit parallel mode, using 16+2 (DB0..DB15, RS, WR) output pins minimum (plus GND and VCC, with CS on the TFT tied to GND).  I would use 16+4, for DB0..DB15, RS, WR, RD, and REST, tying CS on the TFT to GND.

[Jan Audio]

No chance for errors when CS tied to ground then ?, i got this advice from someone to always use the CS pin.