EEVblog Electronics Community Forum

Products => Computers => Programming => Topic started by: Jan Audio on January 28, 2020, 03:24:52 pm

Title: ILI9341 mental support
Post by: Jan Audio on January 28, 2020, 03:24:52 pm

Hi, i am finally getting started with color display.
I got the touch screen to work and the SD-card.

I have 2 versions : 1 with touch screen and without SPI 3,2 inch, and one without touch screen and with SPI 2,8 inch.
Since i have no pins enough i go for the 2,8 SPI version for my project.

My goal : is make a game-boy like thing, a handheld game computer, based on a PIC32.
Yes there are librarys available, only i am not the arduino type.

How does it works and what does it offer ?
Or you all been downloading the librarys ?
I like to make use of all the functions inside, there is not enough space in my PIC32.
Can you write text on the backbuffer inside ?

I always have problems getting started and need some mental support.
This year i want to have it finished.

thanks

Title: Re: ILI9341 mental support
Post by: dmills on January 29, 2020, 03:22:37 am

There is no double buffer as such in the thing, and it basically understands setting pixels in memory regions to colours, it has no notion of fonts or text, you got to provide that in your processor.

I usually go for 4 wire mode so that there is an explicit command/data control line, as the PIC32 does not really do 9 bit SPI which is the other choice if not doing parallel.

Aggravatingly, 320 * 240 * 16 is more then 128k, so you cannot hold a frame buffer in the pic without getting sneaky.

It all in the (rather annoying) datasheet, which like all LCD driver datasheets omits how the gamma stuff really works, and does not give you the initialisation vector that is right for your panel (Usually you can get that off the panel vendor).

If the TE signal is available on your screen (They vary) it is worth hooking this to an interrupt line.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on January 29, 2020, 05:26:02 am

As to overall support, you might wish to use two or three microcontrollers instead of just one: one for video processing (blitter (https://en.wikipedia.org/wiki/Blitter), or graphics tile processor, as most games use sprites and tiles as the basis for their graphics), one for audio processing (if wavetable synthesis and/or MP3 decoding for music is supported), and the master one for the game mechanics.

The underlying idea is that the graphics processor handles the display without tearing, and essentially contains the secondary video buffer; so having lots and lots of RAM on this one is much more important than its computational speed. You connect it to your primary processor using some sort of a serial protocol (UART with high baudrate, I2C, or SPI). Typically, it contains a buffer or list of tiles, rotated or mirrored (usually 8 options), with the tiles using a lookup table (often 4 or 8 bits per pixel in a tile, with the lookup table to a 16-bit RGB or 32-bit RGBA, selectable per tile). If you have enough memory for the tiles, you can use them for fonts too. At update time, the blitter builds each scan line, and sends it (often using DMA) to the actual display module. A single-cycle multiplication unit should let you implement per-tile and per-pixel partial transparency as well.

In simple terms, the main processor first defines some tiles (by sending their data, unless the graphics processor uses its own microSD for the data files), and then just tells the graphics processor which tiles to display and where; updating their locations and properties, and the palettes (code to RGB color mapping) as needed.

(I have a couple of Teensy 4's, which use an i.MX RT1062 crossover processor, with 2×512k of RAM, and enough pins for 9-bit parallel connection to a display, although the pins are not in consecutive bits in the same output GPIO port. One can use either a 1024-byte translation map (512×16 bits), or bit masks and shifts at runtime to adjust, though. Although the chip is not expensive, it is a BGA; fortunately, Teensy 4 only costs $20. I don't use PIC32s, but I see there are lots of models with 512k RAM in 64-pin TQFP at reasonable prices. Reserving half the memory for 4-bit 8x8 tiles gives you 8192 tiles; or 4096 tiles of 8x8 at 8 bits per pixel; or 2048 tiles of 16x16 at 4 bits per pixel; or 1024 tiles of 16x16 at 8 bits per pixel; or 512 tiles of 32x32 at 4 bits per pixel; or 256 tiles of 32x32 at 8 bits per pixel; with ample memory left for RGB color tables ("palettes"), scan line buffer, and the list of currently displayed tiles with their properties. In practice, you'll want to shoot for covering the entire display with three or four tiles per each pixel, so you can implement things like backgrounds and parallax scrolling, with ample tiles left for sprites.)

There are a few technical tricks that one can do to make the scan rendering much easier and faster. The main one is to have your scan line buffer start at -N, and end at W+N-1, where N is the size of your largest tiles (N×N), and W is the width of the scan line. This way each sprite is either entirely visible on the scan line, or not at all.

Similarly, to blend colors, you can start with a scan-line specific RGB color (allows nice color blended backgrounds without any tiles at all), but use 30 bits per pixel for the scan line, in format 0_B0000000RRRRR00000GGGGG00000BBBBB, where R, G, and B are the five-bit RGB components. If your color lookup tables also have the RGB colors in this format, then you can blend from C₀ to C₁ using p=0..17, inclusive, with (C₀×(16-p))+(C₁×p)>>5) & 0_B000000011111000001111100000; i.e. just two multiplications, one addition, one subtraction, one bit shift, and one AND. Of course, this limits you to 32k colors (15 bits).

On architectures with a single-cycle 32×32=64-bit multiplication, you can use full 6 bits per color (actually, up to 10 bits per color, for p=0..1025), for the extra cost of one add-with-carry (64-bit addition splits into one add and one add-with-carry), and the bit shifts and ANDs being on 64-bit value. Remember, the scan buffer does not need to hold the temporary result, as each tile/sprite is just blended on top.

(Note: p includes the upper limit of 2^c+1, using c bits per color component, because the maximum color component value is 2^c-1, and (2^c+1)×(2^c-1)=2^2c-1, i.e. all 2c bits set. In other words, if you have c bits per color component, you have 2^c+2 opacity levels: from 0 to 2^c-1, inclusive.)

Personally, I would probably use both 8×8 and 32×32 tiles, with 4 bits per pixel. Both tile sets I would split in half, so that lower half of tile maps use the low 4 bits, and upper half of tile maps use the upper 4 bits of each tile data byte. Then, I would render the sprites so that half of the 32×32 sprites are rendered first, then half of the 8×8 ones, then the rest of the 32×32, and finally the rest of the 8×8 ones, each set in increasing sprite numbers (no separate z). The small tiles can be used for fonts and projectiles and small stuff, and the large tiles for everything else. Both tile sets use the same 16-color palette sets, with the sprite (and not the tile) specifying the palette; say, among 256 different palettes. This not only makes the rasterizer straightforward, but allows pretty darn nice pixel graphics. If speed is an issue, I'd drop the alpha channel, and only allow 0/1 transparency.

Title: Re: ILI9341 mental support
Post by: Jan Audio on January 29, 2020, 04:13:12 pm

Quote from: dmills on January 29, 2020, 03:22:37 am

I usually go for 4 wire mode so that there is an explicit command/data control line, as the PIC32 does not really do 9 bit SPI which is the other choice if not doing parallel.

4 wire parralel, wont it be slower very much ?
btw : i see in this topic you can add another bit in software :
https://www.microchip.com/forums/m382024.aspx (https://www.microchip.com/forums/m382024.aspx)

Quote from: dmills on January 29, 2020, 03:22:37 am

Aggravatingly, 320 * 240 * 16 is more then 128k, so you cannot hold a frame buffer in the pic without getting sneaky.

I have SRAMs from 1Mbit, i hope this all can be done with DMA ( all new to me ).

Quote from: Nominal Animal on January 29, 2020, 05:26:02 am

As to overall support, you might wish to use two or three microcontrollers instead of just one: one for video processing (blitter (https://en.wikipedia.org/wiki/Blitter), or graphics tile processor, as most games use sprites and tiles as the basis for their graphics), one for audio processing (if wavetable synthesis and/or MP3 decoding for music is supported), and the master one for the game mechanics.

Yes only it still has to be hand-held.
I only use DIP packages, that is the reason i use PIC32.

First i are going to try in 1 chip for a 8-bit NES or 16-bit Sega, it should be possible.
The NES 8-bit chip is originally from 1976.

Title: Re: ILI9341 mental support
Post by: Jan Audio on January 29, 2020, 04:27:00 pm

Quote from: dmills on January 29, 2020, 03:22:37 am

If the TE signal is available on your screen (They vary) it is worth hooking this to an interrupt line.

What is a TE signal ?

Quote from: Nominal Animal on January 29, 2020, 05:26:02 am

There are a few technical tricks that one can do to make the scan rendering much easier and faster. The main one is to have your scan line buffer start at -N, and end at W+N-1, where N is the size of your largest tiles (N×N), and W is the width of the scan line. This way each sprite is either entirely visible on the scan line, or not at all.

You mean updating a section ?

Title: Re: ILI9341 mental support
Post by: Nominal Animal on January 29, 2020, 04:55:54 pm

Quote from: Jan Audio on January 29, 2020, 04:27:00 pm

You mean updating a section?

I mean, if you use a tile blitter, you do not need a framebuffer at all. Instead, you construct each scan line separately, and send it to the display module.
If the scan line buffer has a full tile of extra space before and after it, you always copy a full row of pixels from each tile, even when a tile is partially offscreen.

Or are you trying to emulate old consoles?

Title: Re: ILI9341 mental support
Post by: Jan Audio on January 29, 2020, 04:58:45 pm

Quote from: Nominal Animal on January 29, 2020, 04:55:54 pm

Or are you trying to emulate old consoles?

I also like to, it will be simpler to make my own games.
First i need it working @ 60fps, then i can see what i do.
I just want to build such a thing so i wont have to give expensive presents.

edit : i want 2 frame buffers, i am 2D scrolling fanboy.

Title: Re: ILI9341 mental support
Post by: Jan Audio on January 31, 2020, 02:11:55 pm

What do i need VSYNC or DE mode ?

Title: Re: ILI9341 mental support
Post by: Nominal Animal on January 31, 2020, 02:14:58 pm

Older consoles didn't actually have a direct framebuffer.

Consider the SNES video modes (https://en.wikipedia.org/wiki/Super_Nintendo_Entertainment_System#Video). In most modes, you have one to four stacked fixed grids of 8x8 tiles, where each grid can be scrolled separately (with the different grids having different number of bits per pixel), with 128 additional sprites (max. 32 on the same scan line). The tile grid is usually larger than the actual display, so that scrolling is achieved by just updating the offset.

Let's say you have a 128×64 tile map, each tile being 8×8 pixels, with 16 colors per tile. Each tile uses one of 16 palettes (each color chosen from 32768 possible colors), and can have 16 drawing modes (like mirrored and rotated). The tile map takes 8192 bytes, the tile definitions another 8192 bytes, the palette and drawing mode selectors 256 bytes, and the palettes 512 bytes, for a total of 17152 bytes.

Or, let's say you have three separate 128×64 tile maps, with 256 possible 8×8-pixel tiles, 16 colors per tile; and separate 24-bit palettes for each layer (6-bit RGBA, for transparency support). The tile maps take 3×8192 bytes, the tile definitions 8192 bytes, the palette and drawing mode selectors 3×256 bytes, and the palettes 3×256×24/8 bytes, for a total of 35840 bytes. (A fast renderer might internally use a buffer with 16 scan lines and 8 extra pixels before and after each scan line, so that each tile could be rendered at once to the buffer, without any need to check for partially shown tiles. That would be 7936 pixels for a 480-pixel wide display; or 31744 bytes for 32 bits per pixel, allowing for fast 6-bit color blending.)

To emulate existing games, the emulator part will do the blitting from somewhat similar structures on the emulated memory, to an actual framebuffer; then the framebuffer e.g. DMA'd to the ILI9341 display.

I have some nice 240×240 display modules with an IPS panel and ST7789 controllers. It does support 18-bit colors (262144), but the 15/16-bit interface is much easier and nicer to use.

Let's say I want to use a Teensy 4 (30mm×18mm) as a blitter for this display for my own handheld games. Four planes of 256×256 tiles of 8×8 pixels would need 262144 bytes. At 256 colors per tile, the tile data takes 65536 bytes. If each plane has their own palette (with 32-bit color entries), the palettes take 4096 bytes. Total, about 331776 bytes.

I also want sprites. Let's say 256 up to 32×32 pixel sprites, with 256 colors per sprite. Each sprite can be mirrored and rotated, and uses one of 32 possible palettes. The sprite data takes up to 262144 bytes, and the 32 palettes 32768 bytes. (Palette swapping is common "trick" to add variety to the graphics; and palette modification to change the "mood".)

At this point we're at around 626688 bytes, not including sprite coordinate tables, communication buffers to the master microcontroller and so on; but because Teensy 4 has 1024k (https://www.pjrc.com/store/teensy40.html) of RAM, this is quite possible. In fact, there is ample room for a (32+240+32)×(32+240+32) = 304×304-pixel and a 240×240-pixel 16-bit framebuffers, allowing tear-free updates to the TFT, without blocking communications to the microcontroller during a TFT update.

The 304×304-pixel framebuffer means all tiles and sprites are rendered in their entirety, which simplifies the blitting functions significantly; any sprite or tile that does not have all four corners within this framebuffer, is not visible at all.

Since Teensy 4.0 runs at 600 MHz, it has ample power to do the blitting, even allowing for completely free rotation of the tile grids and sprites, although without antialiasing, it tends to look quite jaggy. (Such blitters tend to be different, traversing either the tile map or the screen coordinates along odd directions, in which case a 256×256-pixel framebuffer would work better, as then the screen coordinates are exactly 8 bits.)

Reminescing time:

A quarter of a century ago I wrote a EGA/VGA "rotator" for 16-bit x86 (8086/80186/80286), that drew a scaled and rotated picture on-screen, casting a shadow in a fixed direction (up/down/left/right). The source was a 256×256 map, one byte per pixel. A 65536-byte/32768-entry (15 bits: 7 bits for current height, 8 bits for map data) determined the color of each displayed pixel and the current height for the next pixel; this to avoid conditional expressions. Essentially, the low 8 (4) bits of the result determined the final color, and the high 7 bits the current height for the next pixel. To traverse the map, I used 16-bit fixed-point integers, with 8 integer bits and 8 fractional bits. So, calculating each pixel involved just two additions (for the coordinates), one 8-bit lookup (from source map) and one 16-bit lookup (from the lookup table), and some register moves which were almost free since x86 splits its 16-bit registers into two 8-bit registers that can be modified separately. At the beginning of each scan line there was additional work (including setting various mask registers etc. for 16-color EGA/VGA), but the inner loop was fast enough to generate a smooth-ish rotation.

If you work out the code, everything just slots together nicely to powers of two, making it much simpler than one would otherwise guess.

One peculiarity of it was that even though you could "zoom" in, it would not lengthen the shadows, as it only applied to the XY plane and not the heights. Or, alternatively, the zoom level changed the angle of the light, with the light at angle arctan(scale). (To fix that, you'd need to recalculate the lookup table for each different zoom level.)

To change the direction of the shadows, one must traverse also the framebuffer in fractional pixel steps. Unsigned 16-bit fixed point, with 8 integer and 8 fractional bits, suffices for 240×240. If the framebuffer is double buffered, this causes no issues; otherwise worse artefacts than tearing will be visible.

In other words, you have two fixed-point coordinates for the framebuffer pixel, their constant deltas, two for the source map "pixel", their constant deltas, and a 16-bit register for the current "height" used with the 8-bit source map value to find out the new height and pixel color; or 9 registers. 16-bit x86 really only had six general purpose ones (ax, bx, cx, and dx, that split into ah/al, bh/bl, ch/cl, dh/dl; and di and si, 16-bit index registers), so I never implemented that (it would have been too slow). Now, even Cortex M0 and better have at least 11 32-bit ones that a GCC extended inline assembly code in e.g. Arduino environment can safely use: R0-R8, R10, R11.

(This approach cannot really be used to implement radial lighting, because rays from the center of the screen to the edge overlap; you'd do a lot of extra calculations. A variant that uses a temporary buffer for a row of heights can do a cone with central angle at most 90°, though; there the trick is that the temporary buffer is either expanded to the size of the next row, or traversed using two fixed-point registers.)

Title: Re: ILI9341 mental support
Post by: Jan Audio on January 31, 2020, 03:13:15 pm

That means DE mode then ?, whatever it is.

Title: Re: ILI9341 mental support
Post by: dmills on January 31, 2020, 03:27:31 pm

Hsync, Vsync, DE are signals used when running in parallel video mode, and are not used in SPI or microprocessor mode.

If you can do the parallel video thing using the PIC parallel master port that would allow easy and fast DMA operations, going down the SPI route requires either 9 bit SPI transactions or an extra physical connection to select between control and data modes.

TE is 'Tearing Effect' and is an output from the screen that indicates that its internal update is at start of frame, you use this to synchronise your drawing to avoid image tearing.

Title: Re: ILI9341 mental support
Post by: Jan Audio on January 31, 2020, 04:01:23 pm

Ah, thanks, so you dont really need a backbuffer to draw smoothly without flicker ?, nice.

Title: Re: ILI9341 mental support
Post by: Jan Audio on January 31, 2020, 04:13:00 pm

Ok, i have 2 versions, i like the 3,2inch with parallel only i dont know with a PIC32 with only 21 IO pins.

I have one SPI setup for the audio DAC, then i need on the other one to combine : TFT, SRAM, SD-card.
Maybe this is problematic, i have to figure out.

Easy DMA sounds good to me, i have to count pins, or find a way with more buttons on 1 ADC or something, i dont know if it is reactive enough ?

Ok, the SPI1 is 4 pins ( 8-bit + Data/Control pin )
+ another slave-select for the SRAM ( if this is possible on 1 SPI ? )
Audio DAC also 4 or was it 3.

Input buttons at least 8.
+ RX & TX pin for connect 2 computers.

I think there is no pins for parallel.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 01, 2020, 03:42:51 pm

So i set up SPI with BRG = 0, @ 24MHz, running 48MHz instruction clock.
Will it work on breadboard ?

MCC set up for enhanced mode, is it good or not ?

Now i have to send some instructions.
When i look at those librarys they send a whole lot of hexidecimal numbers without explain.
Did you copy those ?, or where can i find how the initialize works ?

In those librarys they also use read instructions, i dont want to read anything from a display, what is the use for this ?, it is not required or what ?

I made a picture of the version i have :
(https://www.eevblog.com/forum/programming/ili9341-mental-support/?action=dlattach;attach=919098;image)

I guess it is only for 8-bit SPI since it has a Data/Command pin.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 01, 2020, 04:12:15 pm

I calculated with this SPI speed :

( 1 / 24000000 ) * 240 *320 * 8 = 0,0256
It is not fast enough for 60fps, the reading from SRAM not even calculated.

Title: Re: ILI9341 mental support
Post by: RoGeorge on February 01, 2020, 04:37:23 pm

Quote from: Jan Audio on January 28, 2020, 03:24:52 pm

I always have problems getting started and need some mental support.

Slightly offtopic, but are you trying to say mentoring, or mental support?

Mentoring is about guidance and advice, while mental support is about helping people with brain disabilities. I don't get how an LCD could help with brain disorders. Is there another meaning of mental that I don't know?

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 01, 2020, 04:47:52 pm

I feel disabled at the moment.
Cant get 60 fps.

by the way : you dont need to be metal disabled, you can also be mentally strong.
please no negative comments.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 01, 2020, 09:35:34 pm

Quote from: RoGeorge on February 01, 2020, 04:37:23 pm

mental support is about helping people with brain disabilities

Cambridge dictionary (https://dictionary.cambridge.org/dictionary/english/sustenance) disagrees. "To support" means to help or encourage, and "mental" means relating to the mind, or involving the process of thinking. Although there is no direct entry for "mental support", Cambridge dictionary implies "ILI9341 mental support" simply means "helping with the process of thinking [about] [how to use] an ILI9341 [display module]".

Title: Re: ILI9341 mental support
Post by: chickenHeadKnob on February 02, 2020, 01:16:31 am

Quote from: Nominal Animal on February 01, 2020, 09:35:34 pm

Quote from: RoGeorge on February 01, 2020, 04:37:23 pm
mental support is about helping people with brain disabilities
Cambridge dictionary (https://dictionary.cambridge.org/dictionary/english/sustenance) disagrees. "To support" means to help or encourage, and "mental" means relating to the mind, or involving the process of thinking. Although there is no direct entry for "mental support", Cambridge dictionary implies "ILI9341 mental support" simply means "helping with the process of thinking [about] [how to use] an ILI9341 [display module]".

RoGeorge was not being negative. As a native speaker of English I find the phrase 'mental support' unusual and ambiguous. No native speaker uses it. People do use the phrase "emotional support" often, that directly means people sympathizing. Like when women gather and cry and hug each other and complain about men. I am going to guess Jan Audio didn't intend that meaning.
If as Nominal Animal suggests the intended meaning is " help me figure out the ILI9341 controller" then that would be the unambiguous way to phrase the thread title.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 02, 2020, 07:30:36 am

Quote from: chickenHeadKnob on February 02, 2020, 01:16:31 am

RoGeorge was not being negative.

Neither was I. I only pointed out that for us non-native speakers, the dictionary implies a non-mental-health-related meaning.

(That is, my intention was only to point that out in a neutral manner; that one might use the phrase in a non-mental-health way. No negativity or antagonism or unfriendlyness intended! I probably failed; but me fail English often. :-//)

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 02, 2020, 02:31:28 pm

Ok, i translate directly from dutch.

No one more information about the TFT display ?

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 02, 2020, 03:18:59 pm

Look here : https://vivonomicon.com/2018/06/17/drawing-to-a-small-tft-display-the-ili9341-and-stm32/

Code: [Select]

  // (Display off)
  //hspi_cmd(SPIx, 0x28);
  // Issue a series of initialization commands from the
  // Adafruit library for a simple 'known good' test.
  // (TODO: Add named macro definitions for these hex values.)
  hspi_cmd(SPIx, 0xEF);
  hspi_w8(SPIx, 0x03);
  hspi_w8(SPIx, 0x80);
  hspi_w8(SPIx, 0x02);
  hspi_cmd(SPIx, 0xCF);
  hspi_w8(SPIx, 0x00);
  hspi_w8(SPIx, 0xC1);
  hspi_w8(SPIx, 0x30);
  hspi_cmd(SPIx, 0xED);
  hspi_w8(SPIx, 0x64);
  hspi_w8(SPIx, 0x03);
  hspi_w8(SPIx, 0x12);
  hspi_w8(SPIx, 0x81);
  hspi_cmd(SPIx, 0xE8);
  hspi_w8(SPIx, 0x85);
  hspi_w8(SPIx, 0x00);
  hspi_w8(SPIx, 0x78);
  hspi_cmd(SPIx, 0xCB);
  hspi_w8(SPIx, 0x39);
  hspi_w8(SPIx, 0x2C);
  hspi_w8(SPIx, 0x00);
  hspi_w8(SPIx, 0x34);
  hspi_w8(SPIx, 0x02);
  hspi_cmd(SPIx, 0xF7);
  hspi_w8(SPIx, 0x20);
  hspi_cmd(SPIx, 0xEA);
  hspi_w8(SPIx, 0x00);
  hspi_w8(SPIx, 0x00);
  // PWCTR1
  hspi_cmd(SPIx, 0xC0);
  hspi_w8(SPIx, 0x23);
  // PWCTR2
  hspi_cmd(SPIx, 0xC1);
  hspi_w8(SPIx, 0x10);
  // VMCTR1
  hspi_cmd(SPIx, 0xC5);
  hspi_w8(SPIx, 0x3E);
  hspi_w8(SPIx, 0x28);
  // VMCTR2
  hspi_cmd(SPIx, 0xC7);
  hspi_w8(SPIx, 0x86);
  // MADCTL
  hspi_cmd(SPIx, 0x36);
  hspi_w8(SPIx, 0x48);
  // VSCRSADD
  hspi_cmd(SPIx, 0x37);
  hspi_w8(SPIx, 0x00);
  // PIXFMT
  hspi_cmd(SPIx, 0x3A);
  hspi_w8(SPIx, 0x55);
  // FRMCTR1
  hspi_cmd(SPIx, 0xB1);
  hspi_w8(SPIx, 0x00);
  hspi_w8(SPIx, 0x18);
  // DFUNCTR
  hspi_cmd(SPIx, 0xB6);
  hspi_w8(SPIx, 0x08);
  hspi_w8(SPIx, 0x82);
  hspi_w8(SPIx, 0x27);
  hspi_cmd(SPIx, 0xF2);
  hspi_w8(SPIx, 0x00);
  // GAMMASET
  hspi_cmd(SPIx, 0x26);
  hspi_w8(SPIx, 0x01);
  // (Actual gamma settings)
  hspi_cmd(SPIx, 0xE0);
  hspi_w8(SPIx, 0x0F);
  hspi_w8(SPIx, 0x31);
  hspi_w8(SPIx, 0x2B);
  hspi_w8(SPIx, 0x0C);
  hspi_w8(SPIx, 0x0E);
  hspi_w8(SPIx, 0x08);
  hspi_w8(SPIx, 0x4E);
  hspi_w8(SPIx, 0xF1);
  hspi_w8(SPIx, 0x37);
  hspi_w8(SPIx, 0x07);
  hspi_w8(SPIx, 0x10);
  hspi_w8(SPIx, 0x03);
  hspi_w8(SPIx, 0x0E);
  hspi_w8(SPIx, 0x09);
  hspi_w8(SPIx, 0x00);
  hspi_cmd(SPIx, 0xE1);
  hspi_w8(SPIx, 0x00);
  hspi_w8(SPIx, 0x0E);
  hspi_w8(SPIx, 0x14);
  hspi_w8(SPIx, 0x03);
  hspi_w8(SPIx, 0x11);
  hspi_w8(SPIx, 0x07);
  hspi_w8(SPIx, 0x31);
  hspi_w8(SPIx, 0xC1);
  hspi_w8(SPIx, 0x48);
  hspi_w8(SPIx, 0x08);
  hspi_w8(SPIx, 0x0F);
  hspi_w8(SPIx, 0x0C);
  hspi_w8(SPIx, 0x31);
  hspi_w8(SPIx, 0x36);
  hspi_w8(SPIx, 0x0F);
  // Exit sleep mode.
  hspi_cmd(SPIx, 0x11);
  delay_cycles(2000000);
  // Display on.
  hspi_cmd(SPIx, 0x29);
  delay_cycles(2000000);
  // 'Normal' display mode.
  hspi_cmd(SPIx, 0x13);

They say : we just copy some adafruit code.
That is why these displays are not available in regular shops ?, because there is no manual ?
I dont like copying other peoples code especially without comments for all the commands.
It looks like the whole world copy this "adafruit" code, whatever that is.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 02, 2020, 03:28:07 pm

Which exact PIC32 you use?

For 60 FPS at 320×240 using 16-bit color, you need 320×240×16/8=153,600 bytes for the framebuffer, and transfer 320×240×16×60=73,728,000 bits per second. In the serial mode, ILI9341 needs at least 100ns per write cycle, i.e. 10 MHz. Thus, according to the specs, you can get up to 10,000,000/(320×240×16)≃8 frames per second.

If you use 12 I/O pins for the display (8 data pins, WRX, RDX, CSX, D/CX), and your PIC32 supports 8-bit DMA in parallel to those pins, triggered by falling edge of WRX (also in your own control; the display latches the 8 pins on rising edge of WRX), you might be able to reach 60 FPS. According to the datasheet, 8-bit parallel WRX cycles must take at least 66ns, which corresponds to about 15 MHz. Your WRX pin in parallel mode would be toggled at a rate of about 4.6 MHz. (You might be able to use SPI output for this, with a second DMA channel generating the clock pulses from a single 0_b01010101 byte; noting that the length of the DMA data must then be a multiple of 4 bytes.)

Hopefully now you can see why I really believe using a dedicated microcontroller for the display alone is a good idea. It does not need a lot of computational power, but it does need RAM, DMA, and sufficient number of pins.

Since 32-bit microcontrollers with sufficient amount of RAM have ample computational power, it also makes it sensible to do the blitting (of tiles and sprites to the framebuffer) on that dedicated microcontroller, too. My previous posts have outlined some examples of the techniques used in games (and in 2D games libraries, like SDL; example (http://lazyfoo.net/tutorials/SDL/39_tiling/index.php)), that allow one to generate framebuffer scan line dynamically, without a full framebuffer; or with a dual framebuffer where one is DMA'd to the display while the other is being manipulated, so that there is no tearing, but a dynamic frame rate. Emulators need to access the framebuffer directly.

The ILI9341 controller datasheet contains the register and control information, and is freely available on the net. The one Adafruit folks used to write their library is here (http://www.adafruit.com/datasheets/ILI9341.pdf), and it includes all information you need. But first, you need to know how you'll be connecting to the ILI9341 controller; and to help with that, we'd need to know the STM32 you intend to use.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 02, 2020, 04:23:31 pm

The chip is PIC32MX170F256B, it should have everything on board.

Yes i am starting to see, i need a graphics chip for the parralel.
The SRAM has max 20MHz clock, a bigger problem.

This 3,2 inch display with parralel has a 2 row pin header, i need to add wired, thats why i favored the SPI, i can plug in breadboard.
I try getting the SPI working first, then i can see later for fast redraw.
For tetris and arknoid regions can be updated no problem.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 02, 2020, 08:41:35 pm

Quote from: Jan Audio on February 02, 2020, 04:23:31 pm

The chip is PIC32MX170F256B, it should have everything on board.

21 I/O pins is a restriction. The -D model, TQFP-44, would have been much easier, even if on an TQFP-44 to DIP adapter.

It looks like parallel I/O via DMA is only really possible using the Parallel Master Port (http://ww1.microchip.com/downloads/en/DeviceDoc/60001128H.pdf). (Do remember that I don't use PIC32s myself, so I am basing all this on datasheets and manuals; I could be wrong.)

On the 28-pin PIC32MX170F256B in SPDIP/SOIC/SSOP footprint, the data is on pins 23,22,21,18,17,16,15,14, the WRX strobe is pin 25, and RDX strobe is pin 24; these are all in port B. CSX and C/DX can be on any other I/O pins.

On the 44-pin PIC32MX170F256D TQFP, the data is on pins 10,9,8,1,44,43,42,41, the WRX strobe is pin 14, and RDX strobe is pin 11, all in port B. Since it has 35 I/O pins, you'd have 23 pins left over; including all of port A (0-4, 7-10) and all of port C (0-9); or including parallel master port address pins (0-10, port C 2,4-9, port A 7-10). (So, technically, you could use the parallel master port for both external RAM in 2048-byte "pages", DMA'd to the processor, and to DMA data to the display module. Assuming you use UART to communicate with the master controller, you have 10 bits left for "page" selection, or theoretically up to 2 Mbytes. This way you cannot directly access external RAM, but can select a 2048-byte page and DMA it (or any part of it) to memory while the processor is doing other stuff -- except transferring data to the display. For example, using an ISSI IS61WV5128EDBLL-10TLI 512k×8 SRAM, with 8 page pins for 256 pages, 2048 bytes each.)

A 64-pin TQFP (0.5mm spacing) PIC32MZ2048EFG064 (https://www.microchip.com/wwwproducts/en/PIC32MZ2048EFG064) has 512k of RAM and 46 I/O pins. The 8 parallel data pins are 58,61,62,63,64,1,2,3 (port E), the WRX strobe is pin 52 (port D), and RDX is pin 53 (port D). So, on top of the 8+4 pins to a display module using DMA'ble 8-bit parallel, you'd have 34 I/O pins left; including all 16 port B pins.

On the 100-pin PIC32MZ2048EFG100, you'd have full 16-bit parallel data port (port E, pins 91,94,98,99,100,3,4,5,88,87,86,85,79,80,77,78), with WRX strobe on pin 8 (port C), RDX strobe on pin 9 (port C). They are the same as EBI data pins, so it'd be a bit difficult to try and use EBI for external RAM; but 512k gives a lot of options already. Of course, a "paged" access (ie. any DMA within a 65536-byte/65536-word page) using the 16 parallel address bits, and some additional bits for the "page" selection, would let you expand the SRAM to as large as you can find a parallel SRAM chip for. (Say, IS61WV25616EDBLL-10TLI, for an additional 512k of SRAM, organized as 4 pages of 131072 bytes each; accessed in 16-bit aligned units.)

Quote from: Jan Audio on February 02, 2020, 04:23:31 pm

This 3,2 inch display with parralel has a 2 row pin header, i need to add wired, thats why i favored the SPI, i can plug in breadboard.
I try getting the SPI working first, then i can see later for fast redraw.

Note that most of the ILI9431 displays' boards are just connectors, with some passives like resistors, and possibly a 3.3V regulator, and rarely voltage level translators so that 5V systems can talk to the 3.3V logic the ILI9431 uses. 32-bit microcontrollers typically use 3.3V logic levels, so they don't need level shifting. You could probably rather easily design a replacement board for the display with your graphics microcontroller, so that the microcontroller pins go directly to the display flex cable. The ILI9431 chip itself is usually bonded to the flex cable.

(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.)

Quote from: Jan Audio on February 02, 2020, 04:23:31 pm

For tetris and arknoid regions can be updated no problem.

The technique to track which parts of the display have changed is often called "damage". Essentially, you use one bit per a fixed size unit/tile of the framebuffer, and whenever you draw to the framebuffer, you mark the tile the pixel(s) belong to used by setting the corresponding bits.

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.

To make the math easier, you'll probably want 4×4, 8×8, or 16×16 damage regions (or maybe rectangular ones). With 8×8 damage tiles, 320×200 has 40×30 damage tiles; putting the 30 damage tiles in each 8x240 slice in a 32-bit word, the damage map only needs 40 32-bit words, or 240 bytes: point (x,y) then belongs to damage word (x/8) bit (y/8). If damage word (i) bit (j) is set, then the 8x8-pixel region at (i×8,j×8) to (i×8+7,j×8+7), inclusive, must be updated.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 03, 2020, 02:13:39 pm

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.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 03, 2020, 02:25:07 pm

Quote from: Nominal Animal on February 02, 2020, 08:41:35 pm

(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 ?

Quote from: Nominal Animal on February 02, 2020, 08:41:35 pm

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.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 03, 2020, 08:05:49 pm

Quote from: Jan Audio on February 03, 2020, 02:13:39 pm

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€ (https://www.ebay.com/itm/5pcs-QFP44-SMD-SMT-Pin-Pitch-0-8mm-IC-to-DIP-44-Adapter-PCB-Board-Converter-F54/181333858466), 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.

Quote from: Jan Audio on February 03, 2020, 02:13:39 pm

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 (https://github.com/martnak/STM32-ILI9341), 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 (https://www.ebay.com/sch/i.html?_nkw=ili9341+320+240&_sop=15), 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 (https://github.com/myelin/tiny-tft/blob/master/TJC-024-9341-18-pin-SPI-240x320-ili9341-2.4-inch-touch/chinese-driver/TJC-024-9341.pdf)

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 (https://www.ebay.com/itm/2-4-inch-TFT-LCD-module-320x240-R61505V-touchpad-arduino-AVR-STM32-ILI9341/310629036135); as do most of the 3.2" ones (https://www.ebay.com/sch/i.html?_nkw=3.2+240+320+ili9341&_sop=15). 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 (https://drive.google.com/drive/folders/1HrhsoeIuBADP5YHDu5RRAZ5wvXFfarQ8), 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 (https://easyeda.com/NominalAnimal) 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. :P)

Quote from: Jan Audio on February 03, 2020, 02:25:07 pm

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!

Quote from: Jan Audio on February 03, 2020, 02:13:39 pm

Quote from: Nominal Animal on February 02, 2020, 08:41:35 pm
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.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 04, 2020, 02:46:09 pm

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.

Quote from: Nominal Animal on February 03, 2020, 08:05:49 pm

There is for example QFP44 0.8mm pitch to 44-pin DIP adapter, 5 adapters for 3.77€ (https://www.ebay.com/itm/5pcs-QFP44-SMD-SMT-Pin-Pitch-0-8mm-IC-to-DIP-44-Adapter-PCB-Board-Converter-F54/181333858466), 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 ?

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 04, 2020, 05:52:11 pm

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 (https://easyeda.com/NominalAnimal/tqfp44-0-8-to-dip-adapter), intended for the 44-pin PIC32MX170B256D-I/PT:
[attachimg=1]
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.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 05, 2020, 01:38:47 pm

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.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 05, 2020, 05:43:49 pm

Quote from: Jan Audio on February 05, 2020, 01:38:47 pm

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.

Quote from: Jan Audio on February 05, 2020, 01:38:47 pm

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 (https://easyeda.com/NominalAnimal/Pro_Micro_Gamepad-2d47443dcfb5418f80b3a0fa6085b277) 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.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 06, 2020, 04:59:36 pm

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.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 06, 2020, 05:55:57 pm

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

Here is my 2.8" SPI 320x240 ILI9341 display:[attachimg=1]

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.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 07, 2020, 02:32:12 pm

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.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 07, 2020, 05:44:47 pm

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:
[attach=1]
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:
[attach=2]
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).

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 07, 2020, 09:23:13 pm

As it happens, another box I had overlooked contained an 2.8" 320x240 IPS panel with ILI9325 (https://www.ebay.com/itm/113152292332) 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 (https://www.buydisplay.com/2-8-inch-240x320-ips-tft-lcd-display-panel-optional-touch-panel-wide-view) 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 (https://easyeda.com/NominalAnimal).

Oh, and apologies for "spamming" this thread.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 07, 2020, 11:01:00 pm

I also modified the TQFP44-DIP adapter (https://easyeda.com/NominalAnimal/tqfp44-0-8-to-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:
[attachimg=1]
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!

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 08, 2020, 02:33:30 pm

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

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 08, 2020, 02:37:23 pm

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.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 08, 2020, 03:59:42 pm

In the Open Hardware sub-forum, RoadRunner aka CircuitValley.com showed a 64-pin breadboardable PIC32MZ board (https://www.eevblog.com/forum/oshw/open-source-breadboardable-pic32mz-board/), Zwei2 (https://www.circuitvalley.com/2019/04/breadboardable-microchip-pic32mz-diy-ardunio-usb-hs.html), 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... >:D

If you wanted to make e.g. my TQFP44-0.8 to DIP adapter (https://easyeda.com/NominalAnimal/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 (https://jlcpcb.com/quote/), 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 (https://www.pcbway.com/orderonline.aspx), 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 (https://github.com/circuitvalley/Zwei2_Breadboardable_PIC32MZ_Board/tree/master/Board/Gerber), 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 (https://youtu.be/6PB0u8irn-4) 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.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 08, 2020, 04:01:35 pm

(https://www.eevblog.com/forum/programming/ili9341-mental-support/?action=dlattach;attach=924040;image)

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 08, 2020, 04:08:41 pm

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. ;D

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.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 08, 2020, 04:31:02 pm

This display is only for parralel or not ?

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 08, 2020, 05:26:00 pm

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?

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 09, 2020, 02:23:47 pm

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.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 09, 2020, 04:26:53 pm

Quote from: Jan Audio on February 09, 2020, 02:23:47 pm

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.

Quote from: Jan Audio on February 09, 2020, 02:23:47 pm

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.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 09, 2020, 05:44:22 pm

(https://www.eevblog.com/forum/programming/ili9341-mental-support/?action=dlattach;attach=924766;image)

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 09, 2020, 07:52:25 pm

It is the same display as this (https://forum.arduino.cc/index.php?topic=592558.0) 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.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 10, 2020, 11:38:05 am

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

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 10, 2020, 01:48:27 pm

Ok i am gonna ditch the SPI version for now.
Going to solder a small thing, get everything connected for testing when the storm here is over.

I am going for a tiled graphics processor, i hope the UART input will be fast enough for a simple game.
Like you sayd, get the datas in over UART when loading a game from the SD card.
It will work.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 10, 2020, 03:11:54 pm

I was reading this PIC32 datasheet and read about the : Parallel Master Port, i wonder how it can help me ?

The Parallel Master Port (PMP) is a parallel 8-bit/16-bit I/O module specifically designed to
communicate with a wide variety of parallel devices such as communications peripherals, LCDs,
external memory devices and microcontrollers. Because the interfaces to parallel peripherals
vary significantly, the PMP module is highly configurable. The key features of the PMP module
include:
• Up to 24 programmable address lines
• Up to two Chip Select lines with two alternate Chip Selects for extended addressing
• Programmable strobe options:
- Individual read and write strobes or Read/write strobe with enable strobe
• Address auto-increment/auto-decrement
• Programmable address/data multiplexing
• Programmable polarity on control signals
• Legacy parallel slave port support
• Enhanced parallel slave support:
- Address support
- 4 bytes deep, auto-incrementing buffer
• Schmitt Trigger or TTL input buffers
• Programmable Wait states
• Freeze option for in-circuit debugging
• Separate config

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 10, 2020, 08:04:36 pm

Quote from: Jan Audio on February 10, 2020, 11:38:05 am

No chance for errors when CS tied to ground then?

Not really, even the datasheet says you can tie CS to ground.

The real reason you might want to use a separate CS pin, is if you wanted to use the same microcontroller pins for something else too. When the display sees CS high, it ignores the data pins.

Quote from: Jan Audio on February 10, 2020, 01:48:27 pm

I am going for a tiled graphics processor, i hope the UART input will be fast enough for a simple game.

You should be able to use 2Mbaud for example; that translates to 200,000 bytes per second. Even higher baud rates are possible too.
Or you can use SPI at say 25 MHz; that translates to 3,125,000 bytes per second.

Quote from: Jan Audio on February 10, 2020, 03:11:54 pm

I was reading this PIC32 datasheet and read about the : Parallel Master Port, i wonder how it can help me ?

The Parallel Master Port documentation for PIC32 microcontrollers is here (http://ww1.microchip.com/downloads/en/DeviceDoc/60001128H.pdf).

The 28-pin PIC32MX170F256B has 8 PMP data pins, and 2 address pins.
The 44-pin PIC32MX170F256D has 8 PMP data pins, and 10 address pins.
The 64-pin PIC32MZ1024EFG064 has 8 PMP data pins, and 16 address pins.
The 100-pin PIC32MZ1024EFG100 has 16 PMP data pins, and 16 address pins.

I have looked at the PMP, but I don't see any way the address pins are useful here.

When reading from or writing data via the PMP, it can do the RD/WR strobe. However, the 28/44/64-pin chips have only 8 PMP data pins, so it can only be used in 8-bit parallel mode; you'd need the 100-pin PIC32MZ to have 9 or 16 parallel bits.

On 28-pin PIC32MX170F256B, the PMP data pins are 20,19,18,15,14,13,12,11, read strobe is pin 21, and write strobe is pin 22.
On 44-pin PIC32MX170F256D, the PMP data pins are 10,9,8,1,44,43,42,41, read strobe is pin 11, and write strobe is pin 14.
On 64-pin PIC32MZ1024EFG-064, the PMP data pins are 58,61,62,63,64,1,2,3, read strobe is pin 53, and write strobe is pin 52.
On 100-pin PIC32MZ1024EFG-100, the PMP data pins are 91,94,98,99,100,3,4,5, 88,87,86,85,79,80,77,78, read strobe is pin 9, and write strobe is pin 8.

Look at figures 13-16 and 13-17 on page 34 to see the timing outline. (The RD/WR strobes would be inverted for display communications, but that is just a register value change.) The timing is somewhat restricted, as the peripheral bus clock is the system clock SYSCLK, SYSCLK/2, SYSCLK/4, or SYSCLK/8. For the ILI9341, B≃t_ast can be zero, M≃t_wrl is 15ns or longer, and E≃t_wrh is 15ns or longer; the repeated process must take 66ns or longer.

If you run at 50 MHz (maximum for PIC32MX170F256), using PBCLK=SYSCLK gives a 50MHz peripheral clock, with each cycle taking 1000/50MHz = 20ns. Using 1 cycle for B, 2 cycles for M, and 1 cycle for E should work. (Remember, the total cycle must take at least 66ns for ILI4988.)

If you run at 200 MHz (maximum for PIC32MZ1024), the maximum peripheral clock is 100 MHz (PBCLK=SYSCLK/2). Then, each cycle takes 10ns, and we could use 1 cycle for B, 4 cycles for M, and 2 cycles for E should work. (1/3/2 might also work, perhaps even 1/2/2, depending on how the PIC32 feeds the data to the PMP; there is bound to be some latency there too.)

DMA to the PMP (data register) is supported, and not very complicated.

My worry is that since this is a separate module in PIC32, there are internal wait states, making the timing a bit of a trial-and-error thing. One must examine the generated pulse trains and their timing with an oscilloscope. I only have an Analog Discovery 2, which has at best 30 MHz bandwidth, and really isn't sufficient for this. An oscilloscope with 100MHz or 200MHz bandwidth scope, even a DS1054Z, would help a lot.

If instead of PMP, on PIC32MX170F256, you use GPIO port B, you can have up to 16 bits in parallel. While there is no direct hardware support for generating the write strobe, or time the DMA transfers, I believe one can work around that by using additional two pins, one of which is an interrupt pin. The interrupt pin triggers at falling edge, causing the DMA to set the port B data. At its rising edge, the display will latch that data. So, the interrupt pin, an input, is essentially the WR strobe to the display then, but also the DMA trigger. To generate the 1000MHz/66ns ≃ 15 MHz signal needed, I was thinking of using a SPI clock pin, because the PIC32MX170F256 have two SPIs. Then, another DMA channel can feed dummy data to generate the desired number of sets of 8 pulses. Alternatively, a SPI data pin could be used to generate a non-50%-50% pulse train. I don't like the idea of using PWM for this, because the exact number of pulses generated is relatively important; the display will see extra "garbage" data if we send more pulses than we have DMA data for.

So, in summary, the PMP can generate the wait states and write strobes for you, although the timing might take a bit of work to get right. It is quite useful with DMA, if it has sufficient data bits for you.

Because I want to play with 9-bit parallel transfers, I'd have to use either the 100-pin PIC32MZ for PMP, or use GPIO port B on PIC32MX170F256B/D or PIC32MZ1024EFG064. I prefer the latter, that's all.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 11, 2020, 02:43:14 pm

Ok, i wont use the PMP, it will work with using the port normally, dont need any module for that.
SPI i have no pins left for, UART 200,000 bytes sounds enough.
I am wondering what i can do with the 2 pins that are left.
I dont use R/W register, write only.

Then i can program the thing without problems.
Theoreticly it should work.

Going with the PIC32MX170F256B DIP.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 11, 2020, 10:33:49 pm

The UART does go up to 12.5 Mbps (about 1,250,000 bytes/sec) according to the datasheet, when running at full 50 MHz; it depends on what the peripheral bus clock frequency is (depends on main system clock, but programmable), which microcontroller you have at the other end (whether it can support the same baud rate), and how well the wires are shielded.

The possible baud rates are limited; see page Table 21-2 on page 14 onwards in the PIC32 UART manual (http://ww1.microchip.com/downloads/en/DeviceDoc/60001107H.pdf).
High speed UART baud rates (BRGH=1) of F_PBCLK/(4+4×BRG) are also possible, where F_PBCLK is the peripheral bus clock frequency, and BRG is the integer baud rate generator divisor.

The two microcontrollers must use the same baud rate within a few percent, say within 4% or so, to work robustly in practice. (Some Arduino boards cannot do all standard baud rates without several percent error, and that is a problem: they work fine with each other, but not so well with other devices when using those particular baud rates!)

I only now realized that both SPI ports' clock pins (SCK1 and SCK2) on the PIC32MX170F256B conflict with the B port (PB14 and PB15, specifically); and so do both I2C ports pins (SCL1, SDA1, SCL2, and SDA2), which means both I2C and SPI are out with 16-bit parallel. (You can do one-directional SPI using just the SCK and either MOSI or MISO, just two pins.) Then again, UART should definitely suffice; it's just a matter of getting the RX and TX wired well enough to work at the baud rate you need.

Title: Re: ILI9341 mental support
Post by: Nominal Animal on February 12, 2020, 08:09:35 am

I went slightly mad, and created a schematic (no board yet) for PIC32MX170F256D-I/PT, the 44-pin TQFP with 0.8mm pitch, here (https://easyeda.com/NominalAnimal/pic32mx170f2560d-i-pt-breakout-board). Needs review, though, before I'll create the board based on it.

There are basically six sets of pins:
Two 5-12V inputs with Schottky diodes (whichever has higher voltage will be used). Perhaps a barrel connector and an USB micro connector?
3.3V output, can also be used to supply regulated 3.3V.
ICSP/JTAG pins for programming and debugging (VDD, GND, PGED, PGEC for ICSP; VDD, GND, /MCLR, TCK, TMS, TDO, TDI for JTAG).
Port B: 16 consecutive I/O pins.
Port C: 9 consecutive I/O pins.
Port A: 7 non-consecutive I/O pins, four of which (A7-A10) must be detached while programming or debugging.

That is, 28 permanently routable I/O pins, plus four you need to remove when programming/debugging.

Two P-channel MOSFETs are used for reverse voltage protection. Q1 allows /MCLR to be pulled up whenever an external power supply is used, but controlled by /MCLR pad when powered from 3.3V OUT or PROG_VDD. Q2 protects the voltage regulator when powered from 3.3V OUT or PROG_VDD. The voltage drop over each MOSFET is tiny, less than 0.1V at maximum current, something like 0.03V at typical currents needed.

	Use	Possible pins (excluding Bn)
	UART1 RX	A4, C1, C3, C6
	UART1 TX	A0, C0, C5, C7
	UART2 RX	A1, A8, A9, C8
	UART2 TX	C2, C4, C9
	INT1 input	C2, C4, C9
	INT2 input	A4, C1, C3, C6
	INT3 input	A1, A8, A9, C8
	INT4 input	A0, C0, C5, C7
	Timer2 clock input (T2CK)	A0, C0, C5, C7
	Timer3 clock input (T3CK)	A1, A8, A9, C8
	Timer4 clock input (T4CK)	A4, C1, C3, C6
	Timer5 clock input (T5CK)	C2, C4, C9
	Output compare 1 (OC1)	A0, C0, C5, C7
	Output compare 2 (OC2)	A1, A8, A9, C8
	Output compare 3 (OC3)	C2, C4, C9
	Output compare 4 (OC4)	A4, C1, C3, C6
	Output compare 5 (OC5)	A4, C1, C3, C6
	SPI1 data output (SDO1)	A1, A8, A9, C1, C3, C6, C8
	SPI2 data output (SDO2)	A1, A8, A9, C1, C3, C6, C8

While the SPI clock pins collide with Bn, you can still use the SPI data outputs without a corresponding clock output pin, for example via a DMA channel sending a suitable bit pattern (10101010₂ for example) to the SPI transmit buffer. At 25 MHz peripheral clock frequency, that yields a 12.5 MHz pulse stream (80ns period), and the number of pulses generated can be controlled exactly, to a multiple of four.

Output compare units can be used to generate such clocks, but making sure only the exact desired number of pulses are generated is complicated. They are best suited for PWM outputs, in my opinion.

For DMA to an ILI9341 using parallel transfers, an OCn or SDOn generates a pulse stream at 15 MHz or less (66ns period or longer). It is connected to the WR strobe on the display. It is also connected to an INTm input, with a high-to-low transition generating an interrupt. A DMA channel is used to load the parallel data to port B, triggered by that interrupt. If D/C (aka RS) pin is not one of the Bn pins, then only parameters and pixel data can be transferred (while D/C aka RS is high); the command byte is transferred in the interrupt handler or code that sets up the parameter/data/pixel data DMA transfer.

Title: Re: ILI9341 mental support
Post by: Jan Audio on February 12, 2020, 02:11:34 pm

Funny with 2 UARTS even better.

SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder
SMFAds for Free Forums | Powered by SMFPacks Advanced Attachments Uploader Mod