16:9 WVGA 800 x 480 pixels 16-bit, 64k colors possible on P2?

T Chap

I need to find a solution to upgrade out of the P1 to higher res LCD touch panel graphics. How possible is this spec on P2? Or is a video controller going to be needed?

JRetSapDoog posted this a few days back for 640x480.

640x480 @ 16 bpp (65536 colors)
640x480 @ 8 bpp (256 colors) with an additional frame buffer
640x480 @ 4 bpp (16 colors) with 4 separate "frames"

All of these consume 614400 bytes and leave a sizable 172032 bytes for code space.

http://www.newhavendisplay.com/nhd70800480efasxvctp-p-9500.html

jmg

T Chap wrote: »

16:9 WVGA 800 x 480 pixels 16-bit, 64k colors possible on P2?

How possible is this spec on P2? Or is a video controller going to be needed?

Simple litmus check says 800*480*16/8 = 768000
So no, not quite directly, to that resolution.

If you halve the pixels to 400, then yes, it then fits, or if you do 400x240 on that display, it is also practical.

Do you need every one of 800x480 pixels ?

T Chap

I could live with a plain color background, but I want to be able to place icons for various controls spread out over the screen. If the BG is a black, then that should not require any memory from the P2? Only actual graphics? I was hoping to do a solid blue BG. I was really hoping to do higher resolution, ie 800x480. So you are saying I need to get a controller with RAM and use the P2 to transmit the graphics as needed to the controller.

http://www.techtoys.com.hk/Components/SSD1963QL9/SSD1963QL9.htm

macca

Use smaller tiles. 800x480 with 8x8 tiles gives you 100x60 tiles, with 16 bits for each tile descriptor, you need 12k for the whole screen. Each tile can be 8x8 with 8-16 or even 24 bpp, if you need it, just organize your graphics so it can be built with repeating tiles, like fonts, borders, etc. Paletted tiles helps reducing the memory requirement for objects that only changes the colors like buttons when pressed.
P1 has a lot of examples related to videogame development.

jmg

T Chap wrote: »

I could live with a plain color background, but I want to be able to place icons for various controls spread out over the screen. If the BG is a black, then that should not require any memory from the P2? Only actual graphics? I was hoping to do a solid blue BG. I was really hoping to do higher resolution, ie 800x480. So you are saying I need to get a controller with RAM and use the P2 to transmit the graphics as needed to the controller.

If you want a Pixel memory map, you are stuck with the basic maths.
Some systems do skirt this, with a display list processor which can work ok with a large stable background.
P2 could probably do that quite well as it needs to run at BG until it hits a icon boundary, then flip to icon playback, then revert to BG.
Needs some nimble timing, but only has to store the unique Icons, and for that you can do the simple area ratio calc.
Gets complex quickly if you have many Icons, and overlapping Icons are non trivial, but for simple HMI this might do ?

Another approach I wondered about, for a Pixel-Image ram, was to push the Streamer and LUT operating points, to make best use of the P2 resource.

eg reading 3 pixels LUT index from ever 32b, and indexing a 1024 x 16 LUT, would give you 65k colours from a decent palette of 1024, and need
either
a) Simple 3 pixels per 32b, not packed, wastes 2b
2^19-(800*480*32/8/3) = 12288 bytes spare HUB

b) Packed 10b pixel index - frees up quite a bit of HUB RAM
2^19-(800*480*10/8) = 44288 bytes spare HUB

Problem is, neither has direct silicon support at the moment, I think there is only 1,2,4,8 LUT indexing

Adding 3 x 10 in 32b is probably very little logic, but has ~6% waste.

A packed 10b would need to start on a 32b boundary, and keep a 10b cache it adds 2b to, and every 5 reads, it can output that, and pause 1 read.
More logic, but not a lot more - it buys you 32000 bytes of HUB ( a whole P1 !)

16 pixels (10b palette) pack into every 5 32b locations, & most displays are some multiple of 16

jmg

T Chap wrote: »

I need to find a solution to upgrade out of the P1 to higher res LCD touch panel graphics. How possible is this spec on P2? Or is a video controller going to be needed?

Note that P2 is still some ways of, so you might be better to look at the FTDI EVE series, which have just bumped to 800x480, and squeeze a bit more life out of your P1 design.
Easy enough to flip to a P2 if you need to later...

Rayman

I've done this with SSD1963. WVGA at 800x480 and 24 bpp.

It has 1 MB of video RAM

JRetSapDoog

Are you sure you couldn't live with 8-bit color (a byte per pixel, such as in a fixed R3/G3/B2 format or, more flexibly, using the color lookup table (LUT) to get whatever set of 256 colors you wanted)? 256 colors is a lot of colors for an information-based display (and even many images look okay with the right pallet). For 800x480 resolution, one byte per pixel would "only" take 384000 bytes of the P2's 512KB, leaving 140288 for code. The hypothetical 768KB that I referred to in my post would be nice, but we can't count on such an increase to HUB RAM happening. That didn't stop me from pestering the Chef, though.

T Chap

Good point on starting with P1 and controller then migrating it later. The controllers are very cheap so why not take advantage of 24b color. I would assume the SPIN code with assembly SPI engine would easily translate to P2. EVE show 1MB RAM for graphics and other needs. Looks like you would create bitmaps for everything and park them on SD, then load to the controllers RAM on boot.

T Chap

I could probably live with 8 bits, it is just been a long time being confined to Red, Green, Blue, Purple, Light Blue, Yellow on P1 so I am itching to not have further limitations. For Icons, 256 colors is a ton. Still, on a P2 if there are multiple screens, if one screen if graphics is 384k, where do the graphics get parked and managed. Seems too slow to park everything on SD and load as required as menus or screens are called up. This would require some RAM for fast updates right? This also needs to have silicon right now, trying to add an FPGA temporary solution might be too much trouble. With no experience with the controller IC, at a glance I kind of like the idea of developing on P1 in full color, using the controller RAM, while simultaneously migrating to the FPGA P2 until such time as it is ready. I don't know enough about graphics engines yet to fully understand, but from what I can only assume, if using the P2 alone, it could only hold enough grapics in RAM to display a single screen at 800x480 x 8 bits = 384k. If there were a color BG, and a number of icons, it seems that it would be required to have a SDRAM or other method to rapidly update the P2's internal frame buffer with a new screen set. So if there must be a buffer of some sort, why not use the controller which has 1MB RAM built in?

JRetSapDoog

For SSD1963-based stuff, forum member Rayman has done a lot, as disclosed on this forum and at his site: http://www.rayslogic.com/. Now in order to buffer more than one screen with the '63 you'd have to drop the color depth.

If you want something that can store several screens, you might consider the MD070SD LCD module that uses a CPLD + SDRAM, if it's still available, that is. I've not used it, but it seems like it would be a dream to use. However, if memory serves correctly, it needs 16 data lines, whereas the SSD1963 can get by with 8 (at a slower image transfer rate, of course). But if you've got the pins, you could flip through your stored screens instantly (it has 8MB of memory, so I guess you could have at least 8 WVGA, full-color screens). Be careful when searching on EBAY for this, as some of the modules advertised may be SSD1963-based rather than the CPLD + SDRAM design. Here's one link for the CPLD-based module that shows some pictures:

http://www.ebay.com/itm/7-inch-Touch-TFT-LCD-Module-MCU-Bus-Super-Anti-jamming-MD070SD-/271631068277?hash=item3f3e792c75:g:NngAAOSwU9xUNoWY

Again, I haven't tried this, but I like its advertised capability and ease-of-use. Actually, I came upon this at least two years ago, and I'm not sure about its current availability. Another place to search is Taobao.

PS: I believe this is (or was) available with either 5" and 7" LCD screens.

T Chap

Thanks for that info. I suppose I should add that on occasions of touching icons, I don't always need a full screen change, but rather icon animation to show it was touched, which only relates to swapping out the icon for that change only, then if the command calls for a new screen then the new screen or some graphics would change. As I do it now on P1, all icons, buttons, menus etc appear a la carte as needed, the BG is always static black on a 480x272 LCD. Graphics are limited to cog size. This would likely be the same case on the 800x480, static BG so only the icons and other text/graphics need to be changed as needed. I was only assuming that using any color BG vs black would require every pixel to then be part of the frame buffer, whereas on P1 only the certain graphics displayed at any time are taking up RAM.

rjo__

SDRAM is the resolution wild card. It seems reasonable that streamer/smartpin functionality will be used to
support displays directly from SDRAM. At 160MHz clkfreq, I can easily imagine using line buffers in HUB ram to support display output. Without an intermediary CPLD, this will consume a lot of pins, but we have a lot pins:)

We won't know what the limits are until we have SDRAM integrated into the current design.

And we don't know whether Parallax's first P2 boards will deliver SDRAM.

Rayman

Anybody know what part# sdram is best for P2?

Maybe I'd add one to the USB board I'm thinking about for A9...

T Chap

Just ran all this by Newhaven, they strongly suggested the EVE2, eval board connects direct to their 7" displays.

http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_VM810C.pdf

Connect with SPI, then you'd have to use the I2C cap touch direct to your P1/2 as it does not currently have an FPC connector for that. I like this concept as I can be using the 7" displays now on products without waiting. Theoretically. They recommended this of the 63. I will get one and see what is involved. What I yet to understand is how to quickly load in a new fully scree or specific graphics. They said if I am using a color BG, then you are refreshing the full screen at 60FPS, and will need to reload the full frame buffer if you want to change any part of it. So even if making a change to one icon, I understand that you have to load in the full screen data to the controller. TBD How fast can P1/2 load out 800x480 x 18 bits on SPI? Where is P1/2 getting the data SD/SDRAM?

JRetSapDoog

For a bit-mapped screen, a background pixel takes the same amount of memory as taken for a pixel in an icon or image, assuming the full screen has to be stored somewhere (and assuming no compression tricks). But, of course, one could draw just the icons on-the-fly with a solid background behind, in which case the background takes no memory (other than that for the color value, whatever color you choose). Icons can either be built from graphic primitives or, more likely, stored as small bitmaps. But drawing on-the-fly likely puts demands on the video driver and generally requires a custom one. So, it depends on your approach as to whether you get the background for free. If your video driver generates your screens on-the-fly, you could save a lot of memory. For example, with a color depth of 8 bits (256 colors), 3 rows of 4 icons (12 icons in total) at 32x32 size only needs 12x1024 = 12288 bytes if your video driver fills in the background, whereas buffering the full screen would require 384000 bytes. Huge difference! However, bump that up to 49152 bytes for icons in the 64x64 size, which is still a significant savings (about 87%). Meanwhile, if you're drawing your text in a tile-map fashion on-the-fly, its storage demands are pretty low (but if not, all bets are off). It sounds like you are or will be drawing the screen on-the-fly for text and icons, with your icons (and text font) being stored (instead of generated). Anyway, if you just need to "repaint" a small icon, flashing is minimal and your probably won't need to double-buffer the icons.

JRetSapDoog

EVE or EVE2 definitely sounds like a good way to go if you don't mind having to learn the object-creation protocol it uses (or whatever it's called). EVE represents a whole other class of power, as its graphics elements are calculated and drawn on-the-fly making animation a breeze. I believe it works similarly to Macromedia's/Adobe's FLASH animation technology used for web pages (though slowly being replaced by HTML 5). That is, I think it uses a vector (not raster) approach to drawing (with the likely exception of images) I believe Rayman was looking into EVE when it first came out. I'd love to try it but two things scare me: needing to adapt to its object-creation protocol and the price of the chip. But if the design its going into is not price-sensitive, it sounds like a slick way to go. Alternatively, if your animation needs are simpler, perhaps the P2 will be to handle the manipulation on its own.

Rayman

Well, P2 is still probably a year away... So, if you want something now, sounds like EVE is good.

On the other hand, you can also buy displays with SSD1963 chips onboard and I've posted code for P1 to make them work. Downside is that full screen updates aren't particularly fast.

Eve would give you the advantage of faster screen updates.

Brian Fairchild

I've not delved into the datasheet to see how tweakable the resolution is but this looks a very interesting chip for video...

http://www.vlsi.fi/en/products/vs23s010.html

jmg

T Chap wrote: »

Just ran all this by Newhaven, they strongly suggested the EVE2, eval board connects direct to their 7" displays.

http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_VM810C.pdf

Connect with SPI, ..

Yes the EVE2 is a good match, as it is designed for Microcontrollers and has a SPI link

T Chap wrote: »

... What I yet to understand is how to quickly load in a new fully scree or specific graphics. They said if I am using a color BG, then you are refreshing the full screen at 60FPS, and will need to reload the full frame buffer if you want to change any part of it. So even if making a change to one icon, ?

I'm not sure that is true ?
It is often easiest to refresh if you are doing many changes, but provided you keep the bounding box the same, something like a pulse-on-touch icon should need just that area changed ?

T Chap

I am trying to understand how the graphics drivers work, what I have been using is an adapted VGA driver for the LCD. I don't quite understand how this stuff works really, I was understanding that the graphics you see are constantly refreshed at a rate by whatever controller or micro is attached. This could be wrong of course. Is the micro/controller idle on it's RGB outputs when there is nothing to change? On the LCD stuff we are doing now which Ray adapted from the stock VGA object, the BG is always black, and you can updated any area of the screen( any button/icon) independently of others. If you want the button/icon to go away, you either have to refresh the whole screen or write a mask over the area to reset that area. It would be nice if on the EVE2 you can only draw an area that you want to, including masking that area to reset it to the BG color.

Rayman

Last I looked at EVE, you just defined a bunch of objects that you want shown on the screen. Objects can be text or graphics. For graphics you send over the data to memory. They you create the object with position and pointer to memory. Then, EVE adds to the pile of other things to show. It creates each scan line on the fly by adding the contribution from each object.

It's pretty clever actually, because it eliminates the need for a screen buffer.

At least, that's the way I understood it.

T Chap

Yes the EVE2 is looking really slick. This looks like how I might prefer to go even on P2 as well since it is very simple to drive with SPI. They are using the Arduino IDE to program it their Atmel controller. Hopefully that can be replicated on the P1, probably they are just using the Atmel as a method to transfer the preconfigured screen objects, but since they already have it dialed in maybe a header on my own boards and Arduino USB module might be a quick easy way to go.

jmg

Rayman wrote: »

Last I looked at EVE, you just defined a bunch of objects that you want shown on the screen. Objects can be text or graphics. For graphics you send over the data to memory. They you create the object with position and pointer to memory. Then, EVE adds to the pile of other things to show. It creates each scan line on the fly by adding the contribution from each object.

It's pretty clever actually, because it eliminates the need for a screen buffer.

At least, that's the way I understood it.

I think that is correct, ie rather than a pixel-ceiling the EVE devices have a Display-List limit.
Docs say : "The display list length must be less than 2048 instructions"