3.5" Color LCD code example

[Demon]

Wow, very interesting.

I'm a flight sim enthusiast and plan on building a panel, soon. I'm still debating between using a full size LCD monitor with an overlay panel, or going with multiple small LCDs.

The nice thing with the monitor is that you can get a 19" for under $100 and can have several instrument displays on it; more economical than small LCDs at current prices. And the monitor can be driven directly from the PC at HD quality graphics.

Example panel; a 19" monitor on the left could extend under the 3 smaller dials and a 15" monitor would be sufficient on the right:



As much as I'd love to PIC-my-ride, it's still not cost-efficient yet.

[Art]

Hi, Thanks heaps
If I do look into a gfx LCD I'll probably begin with this one.

The circle drawing routine needs to check if the value for radius is less than 3.
If it is allowed to draw the circle too small it messes up the display,
and also addresses the screen buffer out of bounds, potentially crashing
if either you or the display software isn't checking bounds.

[Art]

Wow! This thing is HUGE!

Is anyone here that can compile and run this demo currently?
Since I stole the circles, it's only fair that I put back diagonal lines
I think it's a very simple mod on what's in my small LCD code.
The screen coords need to be words instead of bytes,
and the midpoint adjusted for words, but it is already unsigned integer math.

[DaveC3]

Art

Are you referring to the clock project I posted in 2011. If so, yes it is big, I have not played with it for a while. Most of my project have no long term purpose. I tinker with things just to see if I can do it. It compiled and ran fine on a 18F4550.


take care

Dave

[Art]

Hi Dave,
You haven't called it a clock:

@ printstr2 25,20, "SSD2119 Controller"
@ printstr2 25,28, "Dave Cutliff "
@ printstr2 25,36, "TFT Color LCD Model Rev 1.0"
@ printstr2 25,44, "320xRGBx240"
@ printstr2 25,60, "PicBasic Pro6.0 "
@ printstr2 25,68, "Sept 8,2010"

It looks like a general demo how to talk to the LCD,
and SD Card, etc. (Quite a head start)
nor do I see any clock code or line draw routines
but I do see circles and straight lines for rectangles.
I assumed you ran into the same problem with integer math,
because normally the diagonal lines come first, then other 2D routines.

[Demon]

Wow, he has PBP 6.0 !

Robert

[DaveC3]

Art

OK, I have another post using the same glcd as a analog clock http://www.picbasic.co.uk/forum/cont...t-Analog-clock

I don't don't recall any problems with the math. You can call any of the graphic routines in any sequence. You need to use a glcd that the display ram can be read. In this case I use the glcd in 8-bit parallel. If you SPI you can not read the display ram so objects get over written. Also with a display this big it is faster to run with parallel rather than SPI.

[Art]

Wow, he has PBP 6.0 !

Probably disappeared writing for chips we don't have either.

Art

OK, I have another post using the same glcd as a analog clock http://www.picbasic.co.uk/forum/cont...t-Analog-clock

I don't don't recall any problems with the math. You can call any of the graphic routines in any sequence. You need to use a glcd that the display ram can be read. In this case I use the glcd in 8-bit parallel. If you SPI you can not read the display ram so objects get over written. Also with a display this big it is faster to run with parallel rather than SPI.

I'll look at the clock, you must have got lines then.
I don't want to look at the LCD RAM, hopefully..
Take a look at my recent posts, the way I did double buffering
was set aside a RAM array of the capacity of a screen frame,
and draw (your circles etc.) to the RAM array, then copy the RAM array to display
RAM as fast as PBP can do it, then begin drawing the next frame to your RAM
array while the current frame is being displayed.
In that case the second buffer is the LCD's RAM.
(So no raster, and you can't see any drawing).

The big BUT is 320x240x3 colour components might be
asking a lot of RAM even of the most modern pics.
I'll need to be looking into that I guess.

However, there's no law saying the first buffer has to be the full size
of a screen frame, and cannot move around the physical screen.