Hi All,
I have connected a 2.2" 240x320 SPI display to the Cerberus.
The API docs say:
Ok, so my display is larger than the N18 display. I handle all the display setup and setting up the draw windows etc, but the Bitmap.Flush does not output any data on the SPI bus if the Display.Width or Display.Height is set to anything other than the N18.
Is the above quoted statement then incorrect? Does the SPI LCD driver NOT work with larger displays?
Thank you,
E
@ CC -
There are 2 major things different between 2 LCD screen even they are SPI.
I think the current SPI driver is for N18, or any LCD has similar commands with N18. Different commands I don’t think it work.
Also, the document says “RS pin”, it is control pin, not reset pin.
You can write your driver in case they are so much different.
@ CC - I’ve got a 2.2" 240*320 Display running on a cerbuino using SPI.
using System;
using Microsoft.SPOT;
using Vecc.Netduino.Drivers.Ili9341;
using Vecc.Netduino.Drivers.Ili9341.NetduinoHelperFonts;
using System.Threading;
namespace olBuino
{
public class Program
{
public static void Main()
{
var tft = new Driver(false,
Pins.D5,
Pins.D6,
Pins.D7,
Pins.D8,
20000,
Microsoft.SPOT.Hardware.SPI.SPI_module.SPI1);
var font = new NetduinoHelpersFont(VerdanaBold14.Bitmaps,
VerdanaBold14.Descriptors,
VerdanaBold14.Height,
VerdanaBold14.FontSpace);
tft.ClearScreen();
tft.DrawString(050, 045, " .NetMF Rocks!", 0xF800, font);
tft.DrawString(100, 082, " By", 0xFFFF, font);
tft.DrawString(100, 120, " Cerbuino", 0x009C, font);
tft.DrawRectangle(48, 033, 184, 119, 0x5515);
tft.DrawRectangle(49, 034, 182, 117, 0x8838);
tft.DrawRectangle(50, 035, 180, 115, 0xFF7F);
tft.BacklightOn = true;
// We wait a bit
while (true)
{
Thread.Sleep(2000);
}
}
}
}
The display driver can be found here [url]https://github.com/veccsolutions/Vecc.Netduino.Drivers.Ili9341/tree/master/src/Vecc.Netduino.Drivers.Ili9341[/url]
Or have a look at this [url]https://www.ghielectronics.com/community/forum/topic?id=22192&page=1#msg207021[/url]
The project is run in VS2015 Update 1 and for netmf 4.3.1
@ Dat -
I am aware of the differences. The thing is that the Bitmap.Flush produces no SPI activity at all if the Display size is different to the N18. I have verified this with a logic analyzer. Thus the quoted API doc about a larger display is misleading, even if it does have the same commands as the N18.
It would be nice if the Bitmap class can pump out the raw pixel data in the format defined by the BitmapFormat property, without trying to control the LCD. This way all the low bandwidth stuff like registers could be done in slow C# and the Bitmap class could transfer the high bandwidth pixel data.
That way any SPI display can be handled with some c# code added. IE:
public void Flush(Bitmap b, ushort x, ushort y)
{
Address_set(x, y, (ushort)(x + b.Width),(ushort)( y + b.Height));
pinCS.Write(false);
b.Flush();
pinCS.Write(true);
}
@ Peter -
Thank you for the code, but I have already written a similar driver for ansi C and I have the display running on another board. I wanded to try c#'s bitmap class with the display. 
@ CC - I think this is a known bug where the spi display support is locked to n18 display size. John knows more about this.
@ Gus - Ahh, things are starting to make sense.
This also applies to the display attributes. But the Display.Width and Height does not really have any effect and does not limit anything if I don’t set the rest of the display’s control pins. This way the driver thinks it is an N18, but without control pins it doesn’t try to control the display, it only spits out RGB data.
Is this correct?
@ CC - The latest pre-release SDK actually allows you to set the width and height to be different than 128 and 160.
@ John - Unfortunately it does not.
I used 2016 R1 Pre-Release 1, Built 2015-12-22. If the LCD’s width/Height is not 128/160 then there is no activity on the SPI. If the bitmap’s width/height is not 128/160 then there is also no activity on SPI.
I think this is the most annoying as the LCD size can be anything because it does not affect anything. But the bitmap fixed size is a pain as, either one must update the whole display(not enough ram for a 320/240 on cerberus), or one must update the display on a per element basis, but that is not possible with the 128/160 limit
Thank you,
Errol
@ CC - Can you post the code you are using with the latest pre-release SDK where the full size LCD and bitmap are not working?
This code outputs the RGB data as expected. See image:
using System;
using Microsoft.SPOT;
using GHI.Processor;
using GHI.Utilities;
using Microsoft.SPOT.Hardware;
namespace LCDTest
{
public class Program
{
public static void Main()
{
Debug.Print(Resources.GetString(Resources.StringResources.String1));
Display.Type = Display.DisplayType.Spi;
//Display.Width = 240;
//Display.Height = 320;
Display.Width = 128;
Display.Height = 160;
Display.BitmapFormat = Bitmaps.Format.Bpp16RgbLe;
Display.CurrentRotation = Display.Rotation.Normal;
Display.SpiConfiguration = new SPI.Configuration(Cpu.Pin.GPIO_NONE, false, 0, 0, false, true, 8000, SPI.SPI_module.SPI1 );
Display.BacklightPin = Cpu.Pin.GPIO_NONE;
Display.ResetPin = Cpu.Pin.GPIO_NONE;
Display.ControlPin = Cpu.Pin.GPIO_NONE;
Display.Save();
Bitmap b = new Bitmap(128, 160);
b.Flush();
}
}
}
If I change the LCD size to the commented values then no data appears on the SPI pins.
If I leave the LCD size as the working example above but change the bitmap to 100x100 then also no data appears on the SPI pins.
I don’t know if there is a later pre-release than 22 December?
@ CC - Bitmap.Flush only works when the bitmap size is the size of the screen, regardless of whether it is over the RGB interface or over SPI. When you set Display.Width and Height to 320 and 240, you must also set the bitmap to that size.
Unfortunately, the Cerberus cannot allocate a bitmap that large so you’ll have to make a smaller bitmap and LCD and draw it multiple times.
:wall:
Ok. That explains a lot. Thank you.