ILI9341 mental support

[Jan Audio]

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.

[Jan Audio]

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

[Nominal Animal]

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.

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.

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.

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.

[Jan Audio]

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.

[Nominal Animal]

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

[Nominal Animal]

I went slightly mad, and created a schematic (no board yet) for PIC32MX170F256D-I/PT, the 44-pin TQFP with 0.8mm pitch, here.  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.

[Jan Audio]

Funny with 2 UARTS even better.