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).
So it looks like the Prop won't have enough memory to display AND calculate, measure all of the sensors, and control a DAC output. I might have to run a dedicated Display Prop that takes care of that.
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.)
If one could choose, I hope the prop can do this dance, but otherwise it would be nice with some options. The lcd is 100%, it's now only a pure ram problem.
I'm asking as well since I have no clue yet, but I guess as long as the end result allows for a graphics area that doesn't need double-buffering and that can be really small. (also perhaps in one bit color).
The rest of the screen is text and a few custom tiles.
To use the entire screen and plot the gui w. graphics needs more memory tough.
I don't need fast updates in the graphics in my application, as long as the click irq from the lcd doesn't delay so it gets missed.
But does this exist?:
* a graphics chip that could handle compact serial commands (not serial transfer of bitmaps) and then act as a graphics adapter and generate the bitmap & control the lcd? (could be done on a prop 2?)
A command like syntax, like svg, or damn it in worst case something html like, which is more or less end screen resolution independent, it's just a meta language, the choosen chip that follows the syntax chip will convert it to bitmap to vga, hdmi, lcd, e-mail / web-upload .png or print it or whatever.
All chips that can send serial data could use it, if the application allows us to have a "uncertain/unknown/depends on what" refresh screen time, it might be possible, might even exist already, perhaps the same chip that controls the Oled screens could work with lcd screens or, well, I'm a new to this, hope for some hints if anyone out there is designing that kind of output from a propeller.
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.
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.
Just spent 2 hours trying to compress the 6-bit image data so that three bytes held 4 pixels. But, it's ending in disaster because the assembly driver is just not fast enough to decompress the data... [noparse]:([/noparse]
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...
Rayman said...
Ariba: I would love to see the 480x272 version! Can different rows have different colors?
The colors are now settable for every 32x32 pixel tile, like in the VGA original driver.
But I can make a version with 1 color per row (=272 words for the colors).
It would also be possible to change it only every n rows, i.e 8 rows for text lines. Just say what you need [noparse];)[/noparse]
Per tile coloring is perfect... Does it have to be full screen? I can see cases where you only need 1-bit graphics in a less than a fullscreen window...
You can change some constants for pixel width and height, to get a lesser size, but the window is then always top left placed.
It would be possible to add a left and top margin, but the current driver hasn't that implemented.
It is really only a bitmap driver, and you can't use the remaining part outside the window for anything other.
The tiles are only for defining the colors.
Double buffering with 2 buffers in RAM is certainly possible. It has a sync indicator to know when to switch the buffers.
I don't know if SD as double buffer will be fast enough...
There are 1 bit per pixel drivers in HiRes- and LowRes versions (480x272 and 240x136 pixels).
The color is definable per 32x32 pixel tile.
HiRes is usefull when you will draw a lot on the screen, but needs 16 kByte memory.
LowRes is mainly for application which has not much RAM free for the screen, LowRes needs only 4.2 kByte.
Then there is also a 2 bit per pixel driver with 240x136 pixels. Every pixel can have 1 of 4 colors. Individual 4 colors
are definable per 48x32 pixel tiles. This gives 5 x 5 tiles, which is a good size for touch buttons. The first line of tiles
is only 10 pixels in height, this can be used for a Titlebar with its own colors.
A demo code is included in the ZIP, which works for all drivers. You just need to change the driver in the OBJ section.
The demo shows the color tiles, and draws pixels and lines. I've tried to make a photo, but my camera is not good
enough, to show details sharp, so perhaps somebody else can make a screenshot.
Andy
Edit: Updated also the comments and description to the right version.
Here's a new screenshot and latest (final?) version of the fullscreen 6-bit driver.
It's at 11 Hz refresh, which gives a noticeable flicker to the eye, but looks great on camera!
I tried your 6 bit driver, but my SD card is to slow (a 512MB older card). I get only the half buffer filled for every
16 lines.
I tried to slow down your video driver, but as you say before, the pixel clock seems not to work under 4 MHz.
So I decided to reprogram a 6 bit Fullscreen driver starting from my Bitmap drivers. And it was not very hard.
I have attached the result in the ZIP. It contains only the changed files (demo-code and driver) the other objects
are in your PSB_6bitDemo Archive.
This driver allows to adjust the Pixelclock in 0.3 MHz steps (5/16 MHz). And I also found that it's the best when the
Sync Signal for buffer filling comes after a 1/4 of the buffer is outputed by the driver.
I have the feeling that the flickering is lower, but I can't really say, because I see only the half picture and some
changing lines with your driver.
It's very easy to change the driver to 480x136, and I also have tried a 240x272 version which is not so bad, perhaps
for a movie player with higher frame rate.
Great!· More the merrier...
I'm surprised your SD would be slower, mines a very old 256 MB card...· Maybe it's fragged...
Anyway, you could have also used this parameter to slow down the refresh rate in my driver:
Comments
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
Ariba: That's a·clean looking·setup! Is that your own custom Prop board?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
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
I'll start taking orders again in the next couple days...
Breakout boards will stay $30 (If I were saavy I'd reduce it to $29.99 [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
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.)
I'm asking as well since I have no clue yet, but I guess as long as the end result allows for a graphics area that doesn't need double-buffering and that can be really small. (also perhaps in one bit color).
The rest of the screen is text and a few custom tiles.
To use the entire screen and plot the gui w. graphics needs more memory tough.
I don't need fast updates in the graphics in my application, as long as the click irq from the lcd doesn't delay so it gets missed.
But does this exist?:
* a graphics chip that could handle compact serial commands (not serial transfer of bitmaps) and then act as a graphics adapter and generate the bitmap & control the lcd? (could be done on a prop 2?)
A command like syntax, like svg, or damn it in worst case something html like, which is more or less end screen resolution independent, it's just a meta language, the choosen chip that follows the syntax chip will convert it to bitmap to vga, hdmi, lcd, e-mail / web-upload .png or print it or whatever.
All chips that can send serial data could use it, if the application allows us to have a "uncertain/unknown/depends on what" refresh screen time, it might be possible, might even exist already, perhaps the same chip that controls the Oled screens could work with lcd screens or, well, I'm a new to this, hope for some hints if anyone out there is designing that kind of output from a propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
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.
Andy
Now I see that has a counter and DAC.
Thanks Ariba.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
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
Since I am trying to learn Propeller Assembly, I am excited to compare the changes that were made from the original driver!
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
The colors are now settable for every 32x32 pixel tile, like in the VGA original driver.
But I can make a version with 1 color per row (=272 words for the colors).
It would also be possible to change it only every n rows, i.e 8 rows for text lines. Just say what you need [noparse];)[/noparse]
Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
It would be possible to add a left and top margin, but the current driver hasn't that implemented.
It is really only a bitmap driver, and you can't use the remaining part outside the window for anything other.
The tiles are only for defining the colors.
I wonder if there's a way to use the SD card or EEPROM as the second buffer for a 480x272 mode...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
I don't know if SD as double buffer will be fast enough...
It's the best I release the code now....
There are 1 bit per pixel drivers in HiRes- and LowRes versions (480x272 and 240x136 pixels).
The color is definable per 32x32 pixel tile.
HiRes is usefull when you will draw a lot on the screen, but needs 16 kByte memory.
LowRes is mainly for application which has not much RAM free for the screen, LowRes needs only 4.2 kByte.
Then there is also a 2 bit per pixel driver with 240x136 pixels. Every pixel can have 1 of 4 colors. Individual 4 colors
are definable per 48x32 pixel tiles. This gives 5 x 5 tiles, which is a good size for touch buttons. The first line of tiles
is only 10 pixels in height, this can be used for a Titlebar with its own colors.
A demo code is included in the ZIP, which works for all drivers. You just need to change the driver in the OBJ section.
The demo shows the color tiles, and draws pixels and lines. I've tried to make a photo, but my camera is not good
enough, to show details sharp, so perhaps somebody else can make a screenshot.
Andy
Edit: Updated also the comments and description to the right version.
Post Edited (Ariba) : 12/7/2009 6:53:39 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Post Edited (Rayman) : 12/8/2009 1:07:38 AM GMT
It's at 11 Hz refresh, which gives a noticeable flicker to the eye, but looks great on camera!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
1.· Resize to 480x272
2.··Image-->Mode-->Indexed Color
and then choose the settings as shown in this photo.
Save as .png and then use that with the 6Bit dat generating app, I posted earlier...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
I tried your 6 bit driver, but my SD card is to slow (a 512MB older card). I get only the half buffer filled for every
16 lines.
I tried to slow down your video driver, but as you say before, the pixel clock seems not to work under 4 MHz.
So I decided to reprogram a 6 bit Fullscreen driver starting from my Bitmap drivers. And it was not very hard.
I have attached the result in the ZIP. It contains only the changed files (demo-code and driver) the other objects
are in your PSB_6bitDemo Archive.
This driver allows to adjust the Pixelclock in 0.3 MHz steps (5/16 MHz). And I also found that it's the best when the
Sync Signal for buffer filling comes after a 1/4 of the buffer is outputed by the driver.
I have the feeling that the flickering is lower, but I can't really say, because I see only the half picture and some
changing lines with your driver.
It's very easy to change the driver to 480x136, and I also have tried a 240x272 version which is not so bad, perhaps
for a movie player with higher frame rate.
I hope this will be usful for you
Andy
I'm surprised your SD would be slower, mines a very old 256 MB card...· Maybe it's fragged...
Anyway, you could have also used this parameter to slow down the refresh rate in my driver:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm