How to use LCD display (touchscreen) with cerberus

I want try a graphic lcd (touch screen) on the cerberus board. Anyone have any idea?

The Gadgeteer LCD display requires R, G, and B sockets. Touch uses an T socket.

Cerberus has none of those.

So you can’t use a standard LCD with standard touch interface.

You could get the OLED display and figure out how to add a touch interface to that. That would use the S interface and potentially two of your A sockets.

You otherwise would need to find a display with an SPI interface and some other touch controller.

I’m new to these modules as well, and was interested in doing the same thing. Would there be anyway to extend the capabilites of the device to support the display, perhaps without the touch?

There is already a display that works, the OLED display that uses S socket.

Keep in mind that Cerberus has plenty of memory to do anything but graphics are very much RAM hungry. I suggest you invest a bit more money and get a board whit more RAM if you want real graphics. Like using Glide library …etc.

A very small image 128x64pixel image is about 16KBytes which is large part of Cerberus 112Kbytes heap but if you use hydra or spider then you have over 8000KBytes. See the difference :slight_smile:

Welcome to the community.

Is there a managed driver for OLED Display? Or do we have to write by our own?
Isn’t that possible to use Touch, if we modify pin map on existing driver provided by community and wire it manualy to Cerberus?
Sorry for newbie questions.

@ ce -

Check these code submissions:

and Gadgeteer OLED Module driveron codeplex.

These are very similar.

@ Architect
Thanks a lot. I wasn’t aware of codeplex one. This will answer lots of my questions. =)

Why is there not a display for Gadgeteer like the FEZ Touch?

The Cerberus has roughtly 3 times the memory of Panda, so why not? :slight_smile:

@ GMod(Errol) - there is one the OLED display and as Gus said GHI has a display in the works. There’s just no TFT for it.

I think this display can be used with Cerberus. It communicates over SPI, might be gadgeteer compatible S type socket.

Not that there is no off the shelf code for the OLED. I haven’t hacked one up yet.


You don’t really even need to really modify the code; just copy out the driver and place in the SPI info and you’re done. I got that module running on my cerb40 in about 5min.

Hmm… the resolution is incorrect, which means so are the buffer sizes right? The OLED module is 128x128, that code is 128x64.


I’m not sure about the buffer size; I ripped the buffer out in favor of PicoBitmap.

Those are sortof conflicting statements… :slight_smile:

You can’t just copy the driver, as it relies on the Bitmap class, which the Cerberus doesn’t have, as far as I know. The driver also assumes that it can allocate 98KB of ram when flushing the bitmap to the display, which might or might not be possible on the Cerberus. It also relies on WPF.

  1. doesn’t need bitmap class but can work with it
  2. Cerb does have bitmap class at the moment may go (according to Gus)
  3. WPF isn’t required either it’s allowed
  4. Buffer Can be allocated once at the Beginning

Try this create a byte buffer 1281282 fill it with 0xFF00 and call the write data method; you’ll see a color flushed to your screen. You can also use GHIs method of converting a bitmap to an array.

I’m looking at the OLED source from codeplex, I don’t know if things have changed.

The instantiator looks like this:

public OledDisplay(int socketNumber)
 : base(WPFRenderOptions.Intercept)

Doesn’t that imply a depedance on WPF?

You can’t allocate the buffer at the start of the program, not with the driver as it is. Currently the buffer is created in the Paint function:

[quote] protected override void Paint(Bitmap bitmap)
byte bitmapbytes = bitmap.GetBitmap();

            GTM.Module.Mainboard.NativeBitmapConverter(bitmapbytes, vram, Mainboard.BPP.BPP16_BGR_BE);
            Send(Cmd.WriteRAMCommand0, vram);

Is that the “Send(Cmd.WriteRAMCommand0, vram);” command?

On another note. What is so slow with the seeed driver? Is it the whole bitmap thing? I’m getting around 1fps, so I can’t even demo my captouch module using the OLED display… :frowning:

[em]Doesn’t that imply a depedance on WPF?[/em]
Nope that’s the Gadgeteer base graphics interface…ignore it

[em]You can’t allocate the buffer at the start of the program, not with the driver as it is. Currently the buffer is created in the Paint function:[/em]
Sure you can

vram = new byte[Width * Height * 2];

Just kill any references of that and set it as

private byte[] vram = new byte[32768];

to begin with

[em]Is that the “Send(Cmd.WriteRAMCommand0, vram);” command?[/em]
Yup that’s the one.

[em]What is so slow with the seeed driver? Is it the whole bitmap thing?[/em]
Yes; GTM.Module.Mainboard.NativeBitmapConverter(bitmapbytes, vram, Mainboard.BPP.BPP16_BGR_BE); takes a LOT of time.

If you can wait a couple of weeks PicoMax will be released and can run the Seeed OLED at >30FPS

Ooh! 30fps would be very nice on the OLED. I’ve been using it on my IR heli project, and the display just can’t keep up with the updates I’m sending it (roughly every 200ms).

Thanks :smiley: I think the max I saw was 36FPS, but that was doing nothing more than flipping between a couple of PicoBitmaps. If you’re familiar with Spiral at all, PicoMax will have all the same graphics methods, plus more. It can even paints from one PicoBitmap to another, save to a normal BMP file, and even do partial and streaming loads to save on memory.

I’ve put everything I’ve learned over the past 3 years into the replacements for Spiral & .NET Clix. I think you’ll be pleasantly surprised at the results.

Oh and there’s a GUI tool coming out too.