@ Mr. John Smith - Should i use Thread.Sleep() for some timing or just Switching the GPIOs on/off?
ILI9341 is quite easy to drive, at least using SPI.
To send a command, you set the d/c pin low and then you send your command through SPI.
To send data, you set the d/c pin high and then you send your data through SPI.
You could create two methods : SendCommand(byte cmd) and SendData(byte data) (for example) and the pseudo-code could look like this :
SendCommand(0x3A); // Pixel format
SendData(0x55); //16-bits per pixel
@ Bec a Fuel - That’s what i aleady did 
But NETMF offers SPI.WriteRead(buffer in, buffer out)…
During the performance of Write and Read, which is combined in one method, i have to switch the data/command pin, which i can’t because i have to know exactly when the SPI finished writing…
Why would you want to use SPI.WriteRead() ?! SPI.Write() is enough since there is no data back from the display.
@ Bec a Fuel - yes but as Dave already mentioned, we have to find out if the SPI interface is even responding…
If the display actually changes from white to what you show, it would indicate that the SPI is working. If you put a break point on the SPI write and single step this, do you see the display change at that point? Always good to confirm your commands actually are what is changing the display and not something else.
Can you show us the code you use to init the display?
At that point the display should be responding to the LCD timing. What are you trying to show on the LCD to confirm this? The best way is to draw a bitmap to the screen at 0,0 and the width and height so you can check if the timing is correct.
I think your timing settings are wrong in regards to polarity.
I am assuming you used the SPI to set the interface as 18 bit and DE mode?
Change the OutputEnablePolarity to true as the timing shows this as active high.
See how that goes.
private void Initialize()
{
HardReset();
SendCommand(Commands.SoftwareReset);
Thread.Sleep(100);
SendCommand(Commands.DisplayOff);
SendCommand(Commands.PixelFormatSet);
SendData(0x66); //DPI[1:0] = bin(1,0)
SendCommand(Commands.RgbInterfaceSignalControl);
SendData(0x70); // RCM[1:0] = bin(1,1) (Sync)
SendCommand(Commands.SleepOut);
Thread.Sleep(150);
SendCommand(Commands.DisplayOn);
Thread.Sleep(100);
SetDataMode();
}
This i my initialization routine now…
And this are my LCD settings
Display.Width = 240;
Display.Height = 320;
Display.HorizontalSyncPulseWidth = 10;
Display.HorizontalBackPorch = 20;
Display.HorizontalFrontPorch = 10;
Display.VerticalSyncPulseWidth = 2;
Display.VerticalBackPorch = 2;
Display.VerticalFrontPorch = 4;
Display.PixelClockRateKHz = 6350;
Display.OutputEnableIsFixed = true;
Display.OutputEnablePolarity = true;
Display.HorizontalSyncPolarity = false;
Display.VerticalSyncPolarity = false;
Display.PixelPolarity = true;
Display.Type = Display.DisplayType.Lcd;
Display.CurrentRotation = Display.Rotation.Clockwise90;
if (Display.Save())
{
PowerState.RebootDevice(false);
}
And the display shows nothing…
normally it should show a GUI which has been designed already and which was working on the G400D dev board
Try this init sequence :
private void Initialize()
{
HardReset();
WriteCommand(SWRESET);
Thread.Sleep(10);
WriteCommand(DISPOFF);
WriteCommand(MADCTL);
WriteData(0x08 | 0x40);
WriteCommand(PIXFMT);
WriteData(0x55);
WriteCommand(FRMCTR1);
WriteData(0x00, 0x1B);
WriteCommand(GAMMASET);
WriteData(0x01);
WriteCommand(CASET);
WriteData(0x00, 0x00, 0x00, 0xEF);
WriteCommand(PASET);
WriteData(0x00, 0x00, 0x01, 0x3F);
WriteCommand(EMSET);
WriteData(0x07);
WriteCommand(DFUNCTR);
WriteData(0x0A, 0x82, 0x27, 0x00);
WriteCommand(SLPOUT);
Thread.Sleep(120);
WriteCommand(DISPON);
Thread.Sleep(100);
WriteCommand(RAMWR);
}
}
2 Likes
I can’t find a cmd that’s name is similar to MADCTL…
1 Like
@ Bec a Fuel - And the parameters used in the methods are right for RGB ? or do i have to change them first ?
And could you send me the value behinf the FRMCTR1
Those parameters are indeed working for RGB565.
Regarding the FRMCTR1 register, those are the default values. We simply put them in the init sequence to be consistent if we happen to change it later during normal use.
See the attached picture.
Nope, nothing 
Why is it sooo complicated setting up a f*****g TFT ?!
Could you please show your entire code, including the SPI initialization ?
Really, you need to ask that question? That’s the reason the standard Gadgeteer devices exist, so an end user doesn’t need to worry. There’s standard screens, known and controlled. Who know if your problem is physical wiring, your logic level shifters that we discussed last week, or a dodgy screen? At least with a few “known” things we can eliminate them - your troubleshooting here is unfortunately something you need to do and while everyone can help point you in the right direction, we can’t be certain we understand everything about your setup
Can I also just suggest you use the ILI9341 via SPI to prove the display works - there’s a number of projects that show that working