4.3" LCD with P2 (working already!)
Rayman
Posts: 14,640
Just whipped out a little bit-banged 4.3" LCD driver this morning...
Using an old breakout and just plugging it into P123 header, basically using even numbered I/O pins.
The attached code is very simple, but it works
Refresh rate is ~40 Hz, which is a little lower than the nominal 60 Hz.
That shouldn't be an issue for the real P2, since clock speed with probably be 2..4 times faster.
Using an old breakout and just plugging it into P123 header, basically using even numbered I/O pins.
The attached code is very simple, but it works
Refresh rate is ~40 Hz, which is a little lower than the nominal 60 Hz.
That shouldn't be an issue for the real P2, since clock speed with probably be 2..4 times faster.
640 x 480 - 98K
Comments
Can connect a display for very little cost.
Doesn't need LCD interface chip or external memory...
There are still some open questions on the LUT details for LCDs.
IIRC I think 8:24b has been covered, and 8:16b, but there are also 18b, and to squeeze some more out of the limited 512k, there could also be ?
32b -> 4 x 8bpp -> LCD Bus(24.18.16.8) 2 x 256 LUT possible ? (separate SW path select)
32b -> 5 x 6bpp -> LCD Bus(24.16.8) This can include 4 x 64 LUT Tables via upper 2 bits ?
32b -> 6 x 5bpp -> LCD Bus(24.16.8) This can include 4 x 32 LUT Tables via upper 2 bits ?
32b -> 8 x 4bpp -> LCD Bus(24.16.8) SW needs to manage multiple x16 LUT tables.
Any more common / useful ones ?
I think we have plenty of memory for 8bpp in HUB that uses LUT to make 256 color bitmap to 24-bit color. Could also do 16 bit color in HUB and not use LUT.
I'm not sure what's the best yet.
I think I just figured out how to use REP:
This increased my frame rate fro 40 to 75 Hz, a lot more that I expected.
I'm guessing that DJNZ now always take 4 clocks...
I thought Chip was cleaning up the REP syntax, to use a simple exit label form, which is edit-safe ?
See :
http://forums.parallax.com/discussion/162306/alternative-rep-syntax#latest
would suggest
Actually, I like it like this...
This post says it did change
http://forums.parallax.com/discussion/comment/1346391/#Comment_1346391
and this post covers a minor offset fix-up to make edit-safe
http://forums.parallax.com/discussion/comment/1346401/#Comment_1346401
Like what ? #1 ? Surely not ? - the #1 to repeat two lines simply reads plain wrong.
Nicer to not have to count lines, as discussed in the other thread.
Plus if/when 64b mnemonics appear, counting lines of code is going to be harder, making labels more natural.
There are also some nice tricks that can take advantage of our poor blue spatial perception. The gist of it is we lack high numbers of blue capable detectors in our eyes. It's something like 5:1 with 1 being the blue. This can be toyed with by taking a full color image, breaking it into red, green and blue channels, then perform various transformations on the blue channel. One of the more striking ones is to simply reduce the resolution of the blue by a large amount. Your perception of the image, when reassembled into a full color one will be nearly the same.
Since we have a lot of COGS, maybe some of these things will make sense, particularly for dynamically drawn, or procedural display use cases.
This is one area I plan on exploring a bit later with component video. One of the very nice things about it, compared to VGA, etc... well two things really:
But, higher frequency displays are more desirable just for the vertical resolution. RAM will get tight, but there again, component has some advantages. One of those is the monochrome signal and sync are carried on one single wire. The other two carry color difference signals. Running the monochrome part of the image at full resolution, and the color component at half that is cheap and easy compression with few downsides. A further reduction might involve something like the blue component perception mentioned above.
With the higher resolution LCD displays, a whole lot should be possible and look great at 8bpp.
@Rayman: Wow! That was a big boost in frame rate. Nice!
I may get an LCD panel or two later. TV Composite and Component come first for me though.
I did mention lower bit depths to Chip just a coupla days back. Even though we've got a lot more RAM on this one, people will still make great use out of 1, 2, 4bpp display options. (2, 4, 16 color)
His comment back was, "I need to get Transfer documented for you..."
So, there is a lot we don't know just yet. Good times coming up soon, as he catches up with us and documentation.
I've still got a lot of these 4.3" lcds left.
As for the #1 reading wrong... programmers count from 0 right? Right. Next.
Chip said it was changed here *
http://forums.parallax.com/discussion/comment/1346391/#Comment_1346391
hehe, nice try
* actually reading this line of Chip's more carefully
"The instruction count from D is still 0-based, but I changed the assembler so that by using @address, it figures the 0-based constant to go into D.
"
So I think both forms are supported, and I'd called 0-based that gives #1 for 2 lines (?!), deprecated/poorly maintainable & best avoided in source.
You just know somebody is going to put a label on a blank line too, and that form will break by taking the instruction after the label, just as easily as it will when somebody starts counting from 1.
If both are supported, great. No worries. You were a fan of user choice right?
I'll probably use the no label form and indent the block to be repeated, which is what I did on the "hot" chip, and it read very nicely, clean, etc... People will do what they do.
Nope, Chip said he was fixing that, so the label form is edit-safe.
It then reads just like any HLL or Assembler does.
I'm fine with arrays being indexed from 0, but REP is a Lines+COUNT opcode, and if you can find any editor that counts source lines from 0, please give a link.
Users have a choice to code opcodes as HEX too, but there is a reason they prefer to avoid doing that.
http://forums.parallax.com/discussion/comment/1346401/#Comment_1346401
The label is now an exit label, which makes the code flow very clear, and is edit/conditional/comment/opcode size safe.
- the Label gives natural block structure, same as an exit label in ASM or Repeat.. until in a HLL.
The latter example should be bad practice. It's as ambiguous as just a line count from 0 is. Which means the example you gave Chip actually requires the exact sort of parsing you wanted to avoid!
(which I do find humorous)
Secondly, there is P1 code out there that does operate with the assumption the instruction AFTER the label will be associated with the label. A bad assumption, because either one could technically be the one used. The first example above is clear. The latter one could end the rep with nop or add...
This stuff just isn't quite as clear, cut 'n dried as it is always presented.
The first example above should be required usage if the intent is to actually do the user any real good. Bonus points for a friendly indent, which actually clarifies both the first example, and the line count example, while not doing the ambiguous label example much good at all, due to the label - line link being unclear and subject to assembler behavior! The P1 assembler will take the line below, as will Pnut as of the last time I ran it a coupla days ago.
Now, I'm moving on from this, because it's about LCD displays on this thread...
A label always refers to the adress of the line it is on if it generates something occupying memory or the next line that generates something that takes up space. It can't refer to something that comes before it. That's just wrong!
As far as the LCD display, that's really cool that you are up and running! Nothing wrong with simple!
Please put me on the list for an adapter board and LCD. It looks like a fun addition to the 123 board.
http://forums.parallax.com/discussion/162306/alternative-rep-syntax
There is no confusion at all.
(Which others will find humorous)
Agreed, which is why this is edit safe, context tolerant, and correct (and will confuse no one used to HLL blocks)
Two lines are repeated, and the REP exits to CLKExit Label when done . RET is done only once.
Here are specs on LCD:
http://www.rayslogic.com/Propeller/Products/PSB/LCD_Datasheet.pdf
It's a fairly typical LCD, even though a few years old.
Newer ones might have capacitive touch.
Although, resistive versus capacitive can be a tough choice on 4.3".
One is to replicate what the SSD1928 does for qvga displays, namely provide Microsoft style 2D graphics acceleration.
Other way is what FTDI does with FT800, which is provide just in time pixels based on a list of displayed graphics items.
Yes, be interesting to see how they both pan out.
There may also be a third variant, where a picture-quality still image (or set of images) is stored and streamed to the display and more dynamic information overlaid - uses like process control come to mind, where a plant schematic is the background, and process information is updated in the graphic areas.
That's a nice little display. I'm tempted
The "just in time" pixels seems interesting. I'm not familiar with LCD driver methods at all. With all the COGS, that might make some sense. I suppose the list is items stored in memory as bitmaps, vectors?