Yeah, the breakout board is covering up the access to the Prop Platform's Prop pins 16..31... I think I'm using 16..23 for HSync, VSync, and colors (just like with the VGA driver)...
Just got the final (hopefully) PSB prototypes yesterday...· Need to see if they work...· Still thinking of trying to squeeze in a DS1307 RTC and backup battery somewhere...
BTW:· I'm about to order the breakout boards...· Trying to be clever and save money by combining two different versions of the board with the mono breakout board...
Breakout board just tested successfully with Protoboard.
Was pretty sure it would, but had to make absolutely sure [noparse]:)[/noparse]
Actually, I did have a heck of a time figuring out that I had the counter in a mode that was by default messing with Pin#0, which I'm using for VSync here...· Just have to set the counter to use a pin that's not in use...
Important things to know to see if will work with other screens:
60 pin
0.5mm pitch
On mine actual use does not mater but label may be wrong for different display:
pin 14-DOF
pin 18-25 Blue
pin 26-33 green
pin 34-41 red
pin 42-HSYNC
pin 43-VSYNC
pin 44-PCLK
pin 45-DE
On both boards pins must match use
pin 1,2-Back Light- or GND
pin 3,4-Back Light+
pin 6-touch X+
pin 7-touch Y+
pin 8-touch X-
pin 9-touch Y-
pin 46-NC
pin 47,48-VDD
all others GND
*Note I thought you found potentially compatible screen not connector.
Here's a look at the hand soldered Protoboard variant of the Breakout board.·
You can probably do a cleaner looking wiring job.· Also, I may not have picked the best place to put it, depending on your needs.
This is the version I'll be selling myself...
I'll be sending an email soon to everybody on the waiting list, offering up to 6 displays per box.· (But, if you get a breakout board, then 5 is the limit, so that I can squeeze it all in the box.· Also, I've got connectors now for $1 too.
Probably have to limit breakout boards to 1 per person at first, until I get some made...
Ok, got the first batch of breakout boards ready to ship!· All are individually tested for functionality by yours truly [noparse]:)[/noparse]··
(Boards on the left are the ones I'm selling, those on the right·are special for the Prop Platform board and I'm sending them to Gadget Gangster.··Prop Platform boards·have Backlight and Display On pins hardwired together·so it can simply plug into that board without worrying about pin conflicts with the Tx/Rx pins...)
Going to send out some invoices now to the first few people on the waiting list...
That Propeller Platform really does make things like this plug and play...· It doesn't get any easier...
Anyway, looks like 6-bit full-screen photos are going to be possible by reading directly from the SD card!· This is a work in progress, but check out this image:
Now, I've got to get back to shipping stuff or people are going to start to get mad with me [noparse]:)[/noparse]
How many total pins will be needed to do full 24bit color? I'm guessing 24 for RGB and 3 or 4 control lines. Just wondering if a single Prop could drive the full color display and 4 pins for an SD card interface. I'm looking to create a smart serial driven display that could use bitmaps from an SD card. I guess I could cut the color level down to 16 bit from 24 bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
24 colour pins + 9 control pins.
scl,sda can be shared with eeprom
bl,don can be combined together and forced to 1 rail.
pi can be left disconected
so that is 32 pins minimum for 24 bit colour so it can be done with a prop alone if you want to try.
What about a 12 bit interface? I'm not sure I even know what I'm talking about, but with 24bit you are basically driving each color to 256 different levels, so wouldn't 12 bit bring down the pin count and let you drive the color to 128 different colors? I'm only looking at this from the point of bringing in a BMP from an SD card and dumping it on the display. The BMP's could even just be 16Bit. Instead of trying to have the Prop keep a copy of the graphics memory, it simply just copies pre made images and fonts from the SD card. I know this would not be fast,, but for many applications that want fancy colors and images it would be ok. You still could address the display on a pixel by pixel to draw simple shapes in any of the 12bit color, just rely on the SD card for the high color content.
16 Bit mode make make more sense because you would have less math to do when decoding the BMP. You would simply just copy the bytes to the output ports.
Sorry, I had a lapse in math memory. 12bit color would give 4096 colors. I think the 16bit mode would be best if pulling from an SD card.
Ray,
In your driver, do the Hsync & VSync have to be pulsed at a specific rate. Or can they simply be pulsed at any rate to allow the slower SD card to write the bytes at the speed they come off the SD card at? That's the only way my approach would work. The prop would not have enough memory to drive the display much higher than your 6bit mode otherwise. I'm trying to leverage the mass storage of the SD Card.
People have been asking for the 6-bit photo code...· Unfortunately, it's not in very good shape yet.
It shows a fullscreen 6-bit photo directly from a file on the SD card.· Currently, it just barely works· and is unstable in x and y and has very low refresh rate...
But, here's a first look at it anyway.· Also, here's the Windows App I use to create the data files for the SD card.
Also, here's another screen shot.· Note that the camera photo looks much·better than it does in real life.· Also, I've done some Photoshop error diffusion magic to optimize the result...
Ran into a problem with 6-bit mode, seems VGA driver is too fast to read HUB ram the way I want, even will PLL turned all the way down to 500kHz...
But, I'm looking at it closer now and I think if I just shift all the VSCL constants to the left a bit or two or three, I can slow the driver down enough to make this part work...
Still need to see if I can make it slow enough for the SD part...
If all goes well, we'll be able to mix 6-bit from SD image tiles with regular ROM font tiles. This way we don't have to have full screen images...
Also, if this all works out then full-screen 6-bit video should also be possible (albeit with a very low frame rate)...
I got some of Ray's LCD's today shipped to Sweden. I was mighty surprised about how easy this went (except for my reversed order for all the VGA pins at first ), and not to mention the power of the back-light, wow! In Sweden I've barely got a cheese-sandwich for $5, really happy with the screens, they look brand new as well. The three demos was a real time saver as well, thx man, hope you get something for all your effort to make this happen Ray, this Propeller community thing really makes one remember what was so fun with the Amiga etc.
Would it be possible to have a graphics driver that uses all of the 480x272 pixels?
You can do Graphics full screen, but only not double buffered... For example, the drawing area in the "PSB Paint!" program could probably be extended to full screen...
How would one go about that? I changed the constants for the x_tiles and y_tiles to match the LCD. In doing that, I had to change the amount that the x and y tiles were multiplied in the GraphicsBytes declaration from 32 to 16, due to memory constraints. I also declared a constant memory location for the bitmap and display bases. As well, I changed the offsets to zero to get the graphics area into the corner of the screen. See below.
CON 'Constants for Graphics Demo
[b] x_tiles = 30 [/b] 'width of graphics area
[b] y_tiles = 17 [/b] 'height of graphics area
GraphicsBytes=x_tiles*y_tiles*[b]16[/b]
_stack = ( GraphicsBytes + 100) >> 2 'accomodate display memory and stack
paramcount = 14
bitmap_base = [b]$3000[/b]'$5000 'these are the same because not double buffering...
display_base = [b]$3000[/b]'$5000
lines = 5
thickness = 2
GraphicsXOffset=[b]0[/b]
GraphicsYOffset=[b]0[/b]
Problem is, I get a screen that accepts "painting" input until about column 19, then it displays random characters. See photo attached.
Obviously, I am not familiar with video displays, my exposure to displays is limited to character and graphic LCDs, and any help would be appreciated.
Hmm, I noticed that the random characters are part of the ROM that starts after $8000. So I replaced the constant memory location with the previous declaration of $8000-GraphicsBytes. However, I do not think there is enough memory to display this, since I still get part of the ROM characters on the right side of the screen.
kerryw: Yes, I'll be selling PSB very soon. I actually have 50 "like new" lcds in reserve for that one...
tdeyle: I don't see anything obviously wrong with what you've done. Problem·is probably a few lines down in the code where you have to point each of the graphics tiles to a spot in memory... Make sure you make the x and y changes there too...
Oops, I see I was wrong about going to fullscreen... Turns out the drawing area is already much bigger than that of "Graphics Demo", when I recalled them being the same...
Graphics Demo is 16x12 tiles double buffered
Paint is 22x13 tiles single buffered.
So, it looks like we'd have to make a monochrome version of Graphics to get fullscreen [noparse]:([/noparse]
Rayman said...
Ariba: That's a clean looking setup! Is that your own custom Prop board?
Yes it's my universal Propeller test board. It has 7 equal connectors with 4 I/O pins, GND and 3.3V. The connectors are
compatible to the Digilent PMOD modules (and also to the first 6 pins on each side on a Propeller Protoboard).
I have made a lot of modules, some are in the attached photo: SD card, another LCD, Capacitive Buttons, VGA/TV/PS2 module which uses 3 of the connectors, Audio out ...
Program interface is a PropPlug clone with additional 5V from USB brought to the Test board.
EEPROM and Voltage regulators are under the DIP Propeller.
Really nice work! Do you have any RTC and something in the 433MHz range of tranceiver "bricks" yet?
With all these break-out components, and the great obex, finally it's possible to within a few hours/days of work step right into the application's end users perspective of the wanted propeller system. I remember programming 8 bit for the MC68HC11 w. 256 bytes ram 512 bytes Eeprom or something in that size, one entire project had one goal, like "I now have a program that decodes a 4x3 keypad" and it outputs the debounced-pressed key to a 2x16 char lcd, wow!! no more resources though..
Well,
The VGA/LCD driver is great
The graphics driver is great.
Breakout boards and other puzzle bricks are just great.
"Everything is great."
So the only "problem" now, is to create a "mixed mode of everything"
* Text
* Custom graphics tiles (symbols)
* Touch clickable buttons (text or tiles?)
* On screen keyboard
* Overview lists (text) (windows listbox w up down arrow)
* Sliders / progressbar
* Probably a smaller grahics area, to monitor time/value samples.
* Enough system resources left to handle SD, servo etc.
I have tried many tv drivers, some vga drivers and now the lcd driver, seems like the mix between text & graphics melded into something that could act as the foundation to a presentation layer would be something for the skilled programmer, a GUI layer so to say? To give a layer ontop of the lcd/touch layer that gives you screen areas, realtime graph, something similar to click events etc.. Anyone has any tips?
Saw another member asking about the vga tiles etc:
Check out Rayman's propeller software page!, 1 bit, and 2 bit "image-to-propeller-vga-tiles" windows based single .exe programs - great stuff).
In "PSB Paint Demo" is a line that says:
lcd_backlight:=3 '1=bright, 16=medium, 32=dark
But I see no change nor code PWM.
Is that implemented?
I tried with the object PWM v2.0 (Author: Beau Schwabe), and it worked.
Here some results (My tool of measurement is not accurate.):
PWM = 1:1 490 mA
PWM = 1:4 385 mA
PWM = 1:6 220 mA (Good choice.)
PWM = 1:8 170 mA (Audible Noise, low frequency)
PWM = 1:16 90 mA
PWM = 1:32 40 mA
PWM = 1:64 30 mA
PWM = 1:128 20 mA (And still visible, audible high frequency sound.)
This function is implemented. But it can only work, if you use a LT3593 (or something compatible) to generate the LED voltage.
The brightness control is not done with PWM, but this chips have internal 32 step LED current control, which you can set by toggeling the BL pin.
It describes a 2 bit VGA graphics driver that uses the 512x384 object. I attached it below.
I tried to convert it to the 4.3" LCD by replacing the timings and pixel information in the CON section, but it does not work.
I read in the post that it doubles the horizontal and vertical pixels from 512x384 resolution to 1024x768, and if the monitor you are using does not handle this res, then it will not work. So I halved the pixel information to see if the driver would work.
No dice.
So I was wondering if it was possible to adapt it, since it was essentially a monochrome graphics driver and should be within the limits of the Prop's memory.
I have adapted this driver to the 4.3" LCD last night [noparse]:)[/noparse]
I made 3 versions:
480 x 272 1-bit pixels, uses 16 kByte of memory
240 x 136 1-bit pixels, uses only 4 kByte
240 x 136 2-bit pixels, uses 8 kByte memory
Every pixel of the 240x136 modes spans 4 TFT pixels so it fills the whole screen.
I find the 4 color 240 x 136 the most useful.
I need to polish the code a little bit and make a demo.spin, so I will release the drivers maybe tomorrow.
No, this driver is very easy to understand, and requires only a few changes. Mainly the pixel clock output and DataEnable.
The nice thing is that the display is not so timing sensitive as VGA Monitors, it works with Vertical and horizontal frequencies in a wide range.
I have attached an early version of the 240x136x1 driver with the VGA Demo and graphics-driver you posted.
This Bitmap driver version has the fewest changes, so it's the best to compare with the original. But the last rows do not work.
The newer drivers, which I will post later allows to pass the Pin settings to the driver, so no constants in the driver must be changed.
The driver has a little test code incorporated, so you can first try the TDS__.spin file alone. Then try it with the demo.spin.
Ariba said...
I have adapted this driver to the 4.3" LCD last night [noparse]:)[/noparse]
I made 3 versions:
480 x 272 1-bit pixels, uses 16 kByte of memory
240 x 136 1-bit pixels, uses only 4 kByte
240 x 136 2-bit pixels, uses 8 kByte memory
Ariba:· I would love to see the 480x272 version!· Can different rows have different colors?
I spent hours yesterday doing everything I could think of to increase the framerate of the 6-bit fullscreen driver, but can't get much past 11 fps.
It's not too bad, considering, but the flicker is still noticeable...
Think I'll wrap that up and try a new version with the graphics limited to a 320x240 area. That should let me up the rate.
Think I need about 20 fps to reduce the flicker to acceptable levels...
I originally though I had no flicker with much lower fps, but I was duped by a bug in the Parallax VGA code that doesn't do the pixel clock correctly when it's below 4_000_000...
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
BTW:· I'm about to order the breakout boards...· Trying to be clever and save money by combining two different versions of the board with the mono breakout board...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Was pretty sure it would, but had to make absolutely sure [noparse]:)[/noparse]
Actually, I did have a heck of a time figuring out that I had the counter in a mode that was by default messing with Pin#0, which I'm using for VSync here...· Just have to set the counter to use a pin that's not in use...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
60 pin
0.5mm pitch
On mine actual use does not mater but label may be wrong for different display:
pin 14-DOF
pin 18-25 Blue
pin 26-33 green
pin 34-41 red
pin 42-HSYNC
pin 43-VSYNC
pin 44-PCLK
pin 45-DE
On both boards pins must match use
pin 1,2-Back Light- or GND
pin 3,4-Back Light+
pin 6-touch X+
pin 7-touch Y+
pin 8-touch X-
pin 9-touch Y-
pin 46-NC
pin 47,48-VDD
all others GND
*Note I thought you found potentially compatible screen not connector.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
The lcd driver has been updated so that the pins are fully abstracted and defined in the CON section...
The Paint app is tweaked so it should work with all displays...
Graphics demo has slightly better color match to the original...
Also:· Got an email that my breakout board PCBs have shipped, which is strange because it was supposed to take 1 more week....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
This is·the no-brainer way to go...· Just plug the display into the board and plug the board into the Prop Platform...
I think I'll send this type to Gadget Gangster to sell for me...· I'll sell the other type myself for a while.
Looking like MSRP will be $30 for either type...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
You can probably do a cleaner looking wiring job.· Also, I may not have picked the best place to put it, depending on your needs.
This is the version I'll be selling myself...
I'll be sending an email soon to everybody on the waiting list, offering up to 6 displays per box.· (But, if you get a breakout board, then 5 is the limit, so that I can squeeze it all in the box.· Also, I've got connectors now for $1 too.
Probably have to limit breakout boards to 1 per person at first, until I get some made...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
I'm waiting for the solder to heat up to room temperature...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
(Boards on the left are the ones I'm selling, those on the right·are special for the Prop Platform board and I'm sending them to Gadget Gangster.··Prop Platform boards·have Backlight and Display On pins hardwired together·so it can simply plug into that board without worrying about pin conflicts with the Tx/Rx pins...)
Going to send out some invoices now to the first few people on the waiting list...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Anyway, looks like 6-bit full-screen photos are going to be possible by reading directly from the SD card!· This is a work in progress, but check out this image:
Now, I've got to get back to shipping stuff or people are going to start to get mad with me [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
How many total pins will be needed to do full 24bit color? I'm guessing 24 for RGB and 3 or 4 control lines. Just wondering if a single Prop could drive the full color display and 4 pins for an SD card interface. I'm looking to create a smart serial driven display that could use bitmaps from an SD card. I guess I could cut the color level down to 16 bit from 24 bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
24 colour pins + 9 control pins.
scl,sda can be shared with eeprom
bl,don can be combined together and forced to 1 rail.
pi can be left disconected
so that is 32 pins minimum for 24 bit colour so it can be done with a prop alone if you want to try.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
If you really want to go the higher resolution route...
I think 16 or 18 bits would be pretty straightforward, using 3 cogs, one for each color...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
What about a 12 bit interface? I'm not sure I even know what I'm talking about, but with 24bit you are basically driving each color to 256 different levels, so wouldn't 12 bit bring down the pin count and let you drive the color to 128 different colors? I'm only looking at this from the point of bringing in a BMP from an SD card and dumping it on the display. The BMP's could even just be 16Bit. Instead of trying to have the Prop keep a copy of the graphics memory, it simply just copies pre made images and fonts from the SD card. I know this would not be fast,, but for many applications that want fancy colors and images it would be ok. You still could address the display on a pixel by pixel to draw simple shapes in any of the 12bit color, just rely on the SD card for the high color content.
16 Bit mode make make more sense because you would have less math to do when decoding the BMP. You would simply just copy the bytes to the output ports.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
12bit gives you 16 levels each n^2
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
Sorry, I had a lapse in math memory. 12bit color would give 4096 colors. I think the 16bit mode would be best if pulling from an SD card.
Ray,
In your driver, do the Hsync & VSync have to be pulsed at a specific rate. Or can they simply be pulsed at any rate to allow the slower SD card to write the bytes at the speed they come off the SD card at? That's the only way my approach would work. The prop would not have enough memory to drive the display much higher than your 6bit mode otherwise. I'm trying to leverage the mass storage of the SD Card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
It shows a fullscreen 6-bit photo directly from a file on the SD card.· Currently, it just barely works· and is unstable in x and y and has very low refresh rate...
But, here's a first look at it anyway.· Also, here's the Windows App I use to create the data files for the SD card.
Also, here's another screen shot.· Note that the camera photo looks much·better than it does in real life.· Also, I've done some Photoshop error diffusion magic to optimize the result...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
But, I'm looking at it closer now and I think if I just shift all the VSCL constants to the left a bit or two or three, I can slow the driver down enough to make this part work...
Still need to see if I can make it slow enough for the SD part...
If all goes well, we'll be able to mix 6-bit from SD image tiles with regular ROM font tiles. This way we don't have to have full screen images...
Also, if this all works out then full-screen 6-bit video should also be possible (albeit with a very low frame rate)...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
But, I've played some other games and gotten the framerate up to maybe 6 or so, very close to passable...
Here's the latest version (the lcars screen is isn't too bad, but the flicker is still very noticeable in Jean Luc...).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
/M.E.S.H
How would one go about that? I changed the constants for the x_tiles and y_tiles to match the LCD. In doing that, I had to change the amount that the x and y tiles were multiplied in the GraphicsBytes declaration from 32 to 16, due to memory constraints. I also declared a constant memory location for the bitmap and display bases. As well, I changed the offsets to zero to get the graphics area into the corner of the screen. See below.
Problem is, I get a screen that accepts "painting" input until about column 19, then it displays random characters. See photo attached.
Obviously, I am not familiar with video displays, my exposure to displays is limited to character and graphic LCDs, and any help would be appreciated.
Post Edited (tdeyle) : 12/3/2009 8:28:28 PM GMT
tdeyle: I don't see anything obviously wrong with what you've done. Problem·is probably a few lines down in the code where you have to point each of the graphics tiles to a spot in memory... Make sure you make the x and y changes there too...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Graphics Demo is 16x12 tiles double buffered
Paint is 22x13 tiles single buffered.
So, it looks like we'd have to make a monochrome version of Graphics to get fullscreen [noparse]:([/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Just change these lines like this and get 23x15:
Might be able to get a bit more if you remove those embedded 2-bit graphics...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
I have also received my Displays today (shipped to Switzerland).
After an hour of soldering, it worked on the first try
Here is a photo.
Thanks Rayman for giving away such a nice display for so little money.
Andy
Yes it's my universal Propeller test board. It has 7 equal connectors with 4 I/O pins, GND and 3.3V. The connectors are
compatible to the Digilent PMOD modules (and also to the first 6 pins on each side on a Propeller Protoboard).
I have made a lot of modules, some are in the attached photo: SD card, another LCD, Capacitive Buttons, VGA/TV/PS2 module which uses 3 of the connectors, Audio out ...
Program interface is a PropPlug clone with additional 5V from USB brought to the Test board.
EEPROM and Voltage regulators are under the DIP Propeller.
I call it the Propeller Puzzle.
Andy
With all these break-out components, and the great obex, finally it's possible to within a few hours/days of work step right into the application's end users perspective of the wanted propeller system. I remember programming 8 bit for the MC68HC11 w. 256 bytes ram 512 bytes Eeprom or something in that size, one entire project had one goal, like "I now have a program that decodes a 4x3 keypad" and it outputs the debounced-pressed key to a 2x16 char lcd, wow!! no more resources though..
Well,
The VGA/LCD driver is great
The graphics driver is great.
Breakout boards and other puzzle bricks are just great.
"Everything is great."
So the only "problem" now, is to create a "mixed mode of everything"
* Text
* Custom graphics tiles (symbols)
* Touch clickable buttons (text or tiles?)
* On screen keyboard
* Overview lists (text) (windows listbox w up down arrow)
* Sliders / progressbar
* Probably a smaller grahics area, to monitor time/value samples.
* Enough system resources left to handle SD, servo etc.
I have tried many tv drivers, some vga drivers and now the lcd driver, seems like the mix between text & graphics melded into something that could act as the foundation to a presentation layer would be something for the skilled programmer, a GUI layer so to say? To give a layer ontop of the lcd/touch layer that gives you screen areas, realtime graph, something similar to click events etc.. Anyone has any tips?
Saw another member asking about the vga tiles etc:
Check out Rayman's propeller software page!, 1 bit, and 2 bit "image-to-propeller-vga-tiles" windows based single .exe programs - great stuff).
http://www.rayslogic.com/propeller/Programming/Programming.htm
/Magnus
Now I see that has a counter and DAC.
Thanks Ariba.
It describes a 2 bit VGA graphics driver that uses the 512x384 object. I attached it below.
I tried to convert it to the 4.3" LCD by replacing the timings and pixel information in the CON section, but it does not work.
I read in the post that it doubles the horizontal and vertical pixels from 512x384 resolution to 1024x768, and if the monitor you are using does not handle this res, then it will not work. So I halved the pixel information to see if the driver would work.
No dice.
So I was wondering if it was possible to adapt it, since it was essentially a monochrome graphics driver and should be within the limits of the Prop's memory.
I made 3 versions:
480 x 272 1-bit pixels, uses 16 kByte of memory
240 x 136 1-bit pixels, uses only 4 kByte
240 x 136 2-bit pixels, uses 8 kByte memory
Every pixel of the 240x136 modes spans 4 TFT pixels so it fills the whole screen.
I find the 4 color 240 x 136 the most useful.
I need to polish the code a little bit and make a demo.spin, so I will release the drivers maybe tomorrow.
Andy
The nice thing is that the display is not so timing sensitive as VGA Monitors, it works with Vertical and horizontal frequencies in a wide range.
I have attached an early version of the 240x136x1 driver with the VGA Demo and graphics-driver you posted.
This Bitmap driver version has the fewest changes, so it's the best to compare with the original. But the last rows do not work.
The newer drivers, which I will post later allows to pass the Pin settings to the driver, so no constants in the driver must be changed.
The driver has a little test code incorporated, so you can first try the TDS__.spin file alone. Then try it with the demo.spin.
Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
It's not too bad, considering, but the flicker is still noticeable...
Think I'll wrap that up and try a new version with the graphics limited to a 320x240 area. That should let me up the rate.
Think I need about 20 fps to reduce the flicker to acceptable levels...
I originally though I had no flicker with much lower fps, but I was duped by a bug in the Parallax VGA code that doesn't do the pixel clock correctly when it's below 4_000_000...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm