Large LCD with Panda II

I’m trying to put together a Duemilanove compatible pinout board with a large LCD … for example the 3.5" LCD.

That won’t work with the Panda? Are there any large displays that will?

My main goal is a large, multi-color text display with some light graphics - as long as the graphics controller is offloaded I think I can do this with the Panda.

I’m trying to display some status for a reef tank, and want to turn some indicators yellow or red if parameters are off. The screen should be readable or at least the red indicator from across a room so the 2.8 inch displays are a tad too small.

Most serial character LCD’s are single color.

Why the Panda instead of the Cobra? There is an Arduino shield controller board that fits all my I/O requirements here:

need temp and a couple of BNC inputs, and a number of digital I/O lines for float controllers. I don’t see too many BNC inputs for the Gadgeteer or Cobra line. I could probably prototype it but getting them to work with PH and ORP probes is a little twitchy, so the prebuilt board would be nice.

II also need about 10-12 PWM outputs to dim high power LED lighting modules.

I would really like to work with .Net if possible, this my interest in the Panda II line - I just need a bigger display.

Thoughts?

Thank you,

          == John ==

P.S. I poked around with search but didn’t see anything - please forgive me if I missed a thread.

The Cobra graphics is based upon a bitmap.

The 3.5 lcd that GHI sells is 320x240. Multiply the two dimension and you will see that the bitmap takes more memory than what the Panda has…

Besides, the Panda supporting software does not include the Bitmap class.

Of course you could write your own drivers for the display that does not require all the pixels to be in memory.

You could use a serial lcd display and a big red and green LED to indicate status. If the red led is on you could move to the serial lcd and read the problem.

You mention there are no BNC connectors on the FEZ line. That is true. BNC connectors are a requirement of something externally that you would be connecting to the FEZ. What would the BNC connect to?

Ok, got it on the Cobra. It didn’t really say that on the product page.

I’ve seen several serial LCD QVGA displays that don’t require a memory map for the display. That’s mainly what I wanted to do, output some commands to a separate display, and let that display controller manage the display.

Regarding BNC connectors on the FEZ line - I meant available as an external module / plugin / breakout board / shield, etc. (you get the idea of what I mean by shield). Did you check out the link I pasted? Something like that. The idea is to connect a PH probe and an ORP probe.

== John ==

I think you are the first person to ever ask about a BNC connector in any form.

With a soldering iron you have lots of options for attaching BNC and other types of connectors to a FEZ.

Sure, but it would be a lot easier to just go the Arduino route and forget the FEZ, and get something off the shelf :slight_smile:

I’ll look around for other LCD’s too. Could go either route, but at least now I understand the GHI LCD’s are memory mapped and won’t work directly.

Thanks for the clarification

== John ==

I never said that GHI LCDs were memory mapped.

The Fez Touch display isn’t mem mapped and the LCD controller is offloaded. It is only 2.4" but you do get 3.5" lcd in the same design.

Why not use the Panda 2 + touch screen and make the whole back color of the screen the status indicator?

Hmm … well, no offense but the phrase “The Cobra graphics is based upon a bitmap”

and

"The 3.5 lcd that GHI sells is 320x240. Multiply the two dimension and you will see that the bitmap takes more memory than what the Panda has… "

certainly sounds memory mapped.

Guess that wasn’t clear. I don’t need to store a bitmap, just do some A/D, clock reading, and send some text to the screen, as well as draw a line for a PH reading over the day.

It is only 2.4" but you do get 3.5" lcd in the same design.<<

Does that mean I can buy the controller and hook up the 3.5 to it separatly? I didn’t see those listed as separate parts.

I don’t need to store/decode JPG’s, mostly I would be drawing lines and characters at specific positions. So I don’t need to keep a bitmap in memory. If I do need to load an image, I could copy it as is from an SD Card probably, but it isn’t a requirement at this point.

Why not use the Panda 2 + touch screen and make the whole back color of the screen the status indicator?<<

That was one idea but I wanted something larger than 2.4". It’s a process control application, and the operator needs to be able to see critical issues at a glance from 8-12 feet away. Larger would be better.

4D labs has a nice 3.2 display that just takes VCC, TX, RX, GND, RESET to interface.

Still looking at alternatives,

Thanks,

== John ==

To me, memory mapped means you write to memory and the results appear on the LCD.

This is not what happens… The current support in the EMX and ChipWorkX has the user build a bitmap in memory, draws into the bitmap and then flush the bitmap to the screen. The flushing is done by dumping the bitmap to the LCD via a parallel interface.

The 4D display you mentioned has a serial interface, which is a easy way to attach a display. It would not be fun writting a driver to interface with a parallel interface.

The serial interface is not as fast as a parallel interface, but I think it would work fine for your application. You could have it running in hours… or less…

Some LCD basics: An LCD must be constantly redrawn, line by line. If you stop the updating then the image fades and you risk damaging the LCD. To be able to constantly refresh the LCD you must have enough ram somewhere to store the whole image. That is called a frame buffer because it stores one LCD frame, or screen.

The cobra’s LCD is memory mapped, directly or indirectly. The LCD controller is part of the CPU and the LCD controller steals some of the main SDRAM for the frame buffer. The LCD controller constantly reads this frame buffer, line by line, to refresh the LCD. Thus if you write to the correct place in ram then you WILL write to the LCD as the LCD will be refreshed with the new changes included.

The Panda’s CPU doesn’t have the LCD controller built in, and if it did it still doesn’t have enough ram to steal for the frame buffer.(320 * 240 * 2(16 bits for color) gives you a frame buffer of 153600 bytes)

The Fez Touch LCD has the controller and frame buffer ram built into the LCD itself, so the CPU must download any changes to the LCD, which in turn writes the changes to it’s own frame buffer thus updating the LCD.

What I meant was that you can look around, there are other LCDs with built in controllers. ITEAD sells a 3.2" wide LCD with built in controller, the snag is that it has a 16 bit interface which you will have to bit-bang(slow). And I have seen 3.2" lcds on ebay with 8 bit interfaces.

The EMX user an RGB LCD, not parallel. If you look at the LCD interface then you will see that it consists of 6(?) each of Red, Green and Blue for a total of 18 bit color, a horizontal sync, vertical sync and some other ancillary connections. That is a video interface, not a parallel interface with Data, Read and write lines.

With relatively little work(converting the digital 6 bits for each color to analog) you can connect the EMX LCD interface to an analog VGA monitor.