SPFD5408B display driver (320x240x18)
Yeah ... got my Crystalfontz display today ...
2,4", 320x240x18bit, supports SPI mode, 8 bit mode, 9 bit mode, 16 bit mode, 18 bit mode interface ... and even a raw interface mode, including touchscreen
It has a spfd5408b as controller. Is someone out there who has a driver for that? Or in development?
If not .. fine .. then this will be my first contribution to the ObEx ... in some weeks .. maybe earlier, maybe later ;o)
Post Edited (MagIO2) : 11/26/2009 7:52:03 PM GMT
2,4", 320x240x18bit, supports SPI mode, 8 bit mode, 9 bit mode, 16 bit mode, 18 bit mode interface ... and even a raw interface mode, including touchscreen
It has a spfd5408b as controller. Is someone out there who has a driver for that? Or in development?
If not .. fine .. then this will be my first contribution to the ObEx ... in some weeks .. maybe earlier, maybe later ;o)
Post Edited (MagIO2) : 11/26/2009 7:52:03 PM GMT
Comments
interested.
Well ... first of all I should correct my initial post. What I read when I wrote that was the datasheet of the controller. Unfortunately not all features of the controller are supported by the crystalfontz display. No SPI, no 9 bit interface, no 18 bit interface, no raw interface.
I did not find a proper driver ... even if I found rayman's propeller system board. I guess it would be easy to convert that code, but after a first glance into the code I was not sure wheather he connected his display the same way. The rev instruction made me feel that you have to take care with the wiring, if you want to use that driver.
So I started to write my own.
To implement the low level stuff to send commands and data and a whole pixel was pretty easy. But the initialization of the display using this code did not work [noparse]:o[/noparse]( In the end it turned out to be a problem caused by the german distributor. They offer the display already soldered to a breakout board which converts the flex to a 2.54mm pin connector. Soldering was bad.
Now I started to code some things for the 8bit interface, 18bit color mode.
First addon command in the driver was the clearscreen. It needs 60ms to clear the screen, wich makes a refresh rate of 17 frames per second or a data transfer rate of nearly 4MB/sec. Good enough for further testing ... later on I'll make it faster.
Setting single pixels makes not much sense in SPIN, as it needs seconds to fill a screen.
Now I wanted to see pictures on the display. Here the 8 bit interface is really cool. Simply read a 24 bit bmp-file and send it to the display. That's it ... no conversion. Bottleneck is the SD card. I used version 1.7 of the FSRW driver to access the SD card as the latest 2.4 version was not running, but I wanted to see pictures ;o) IMMEDIATELY!
622ms is the time it needs to read a full 320x240 picture and send it to the display. I played a bit with start the next read while the LCD driver was sending data to the display, but that did not change very much.
In the end I used 2 tricks to make it faster: 1. Don't use the FAT stuff, but continuously read the sektors and 2. send the stuff directly to the display without a HUB-RAM buffer in between. (I put some code into the SD driver which takes over the I/O lines from LCD driver, writes the data and passes back the I/O lines to the LCD driver)
With that a full image can be loaded in 412ms. Next step is : MAKE FSRW24 run.
I guess the load-time can be half of the current load-time by that.
I did additional tests with 16 bit color. Wrote a little Java program that reads the BMP file and saves it in the right format. That way the same copy routine can be used as in the 8 bit interface mode with the difference that now 2 bytes are 1 pixel instead of 3. In non optimized version the transfer needed 415ms and it went down to 217ms after using the no FAT direct tansfer code.
That's pretty cool, but the difference to 18 bit colors is noticeable and for fotos I'd never use it.
Additionally to that I did some tests with the build in propeller font, which is to big. Then I created some characters of an own font which will use 2bit per pixel. I think a 3 color font would be nice in a graphical environment, as you can use outlines. Maybe I'll use 3 bits in the end for choosing a color out of a palette.
I ported Chips line drawing algorithm which also uses the color palette.
And I did some tests with icons. 4 bit per pixel and one icon with a size of 32x32 fits into one sector.
Post Edited (MagIO2) : 11/26/2009 7:42:48 PM GMT
I can't wait to see some pics...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Pic 1 shows a BMP that's been loaded with the old method -> >600ms
Pic 2 and 3 should·show the difference between 16 bit color and 18 bit color
Pic 4 shows the main menu of my home automation project. With a faster FSRW the icon bar could even slide in softly. The clock is running. Will see that on the vid.
Before someone asks: This is NOT my wife ;o)
Post Edited (MagIO2) : 11/26/2009 8:45:08 PM GMT
I am now itching even more to get time to play with the 3.5" SD1226 based displays I have.
Any problems soldering the tab connector your display uses?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Post Edited (JRetSapDoog) : 11/27/2009 12:28:21 AM GMT
Some additions:
Very nice is the possibility to define a window. So, if you have a smaller picture - say 100x100 pixels - you'd simply set the window where you want this picture to appear and write it to the display - no need to adjust the adress-counter after a row.
Maybe worth to mention:
There is no real 64k color mode for the display itself. Content in GRAM is always 18 bit. So, you can't switch to 64k and use some not used memory. On the other hand you could load a pic in 2 steps. First put the 16 bit version in place - which is faster - then correct the pixels which would look better when using the missing 2 bits.
I think I should have given a conclusion of my experiences.
Writing data in 8 bit mode would be possible at a speed that allows ~40 frames per second - from display point of view. So, the display itself is pretty useful. Currently I plan to use SD card only, which is the bottleneck then. Loading a picture in 100ms is still noticable, but if you have a application that only loads a background initially, that's fine. Text updates should be possible very fast, if you have a one-color text area. As then you don't need to load picture data then.
A nice option would be to have a huge RAM where you can store all the pictures. Maybe with a direct transfer from RAM to Display - it's a data bus. In burst mode you could deliver the whole picture. Drawback is that on boot you have to copy all pictures from SD to RAM. Maybe later ;o)
As you can see in raymans video, the usual graphics stuff is also possible. With some modifications you could possibly get use of the additional color depth.
What I miss in my display is the 9 bit mode. This would be a perfect match with the propeller. With movs you can set 9 pins of the data bus in one instruction without overwriting the control signals. In 9 bit mode you'd only need 2 transfers per pixel instead of 3. Of course BMP's can no longer be used, but writing a converter is not a problem.
18 bit mode only makes sense if you have fast access to the picture-data or maybe when you compute the picture. Refresh rate would then be 3 times faster as in 8 bit 256k mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
But you·can·call me micro.
Want to·experiment with the SX or just put together a cool project?
SX Spinning light display·
Want cheap wholesale electronic parts?
Transistor parts wholesale
http://www.crystalfontz.com/product/CFAF240320K-T-TS.html
I bought that for testing those kind of displays and to see if it's practical to load data from SD to the display. Now that I know it works I'd buy the bigger one, which is a bit more expensive:
http://www.crystalfontz.com/product/CFAF320240F-T-TS.html
But when I got that right Bill is also selling such kind of displays?! Or did you only order a couple for testing?
They are based on the SSD1926 which should be quite similar, and need between 12-14 pins (parallel mode, I am not sure SPI mode is brought out)
After seeing your results, I am itching to try it, so I may resume work on the driver for it next week.
I am afraid they are a bit more expensive than the Crystalfontz display:
$55USD+s/h without touch panel ($2 more than Crystalfontz, and without touch panel - but easy to hook up to due to 0.1" header mount)
$65USD+s/h with touch panel
based on the last quote from the distributor.
If I could get a large enough order together I should be able to do better as it would reduce the shipping cost from Asia to me, and also the wire transfer fee would be split over more units - and I'd probably be able to get better prices from the distributor.
http://forums.parallax.com/showthread.php?p=847577
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
In case you are keen on trying this, I could provide a snapshot of my current demo.
There's a vid available on www.aching-diodes.net/propeller/mov19.mpg (~70MB). I don't know which video players can play that. VLC can - that's the one I use - and each player that plays DVDs should be able to as well. Dunno how to put that in youtube so that it runs in the browser, maybe someone else want's to do that?
Later that day I'll explain a bit what you see in the vid.
Post Edited (MagIO2) : 11/30/2009 2:38:02 PM GMT
First you see my breadboard setup with my latest SD card prototyping PCB - where fast FSRW 2.4 still does not work [noparse]:o[/noparse](
After pressing Strg + F10 the current display test software starts. First thing it's doing is initializing the display, clear the screen (that's when it turns black).
The time it shows then was the time needed to scan the whole directory and write the filenames of BMP-files to virtual Memory. (198,7ms)
Then comes a test where I read an empty section (filled with $A5) from the virtual Memory and write it directly to the display memory (484,1ms).
Actually the last two tests have been developed at the end of this test-program, but I did not want to have that tests in the loop.
The next test was one of the first. It's calling low level clearscreen 30 times and needs 1782,9 ms. (That's nearly 4MBytes/sec or 17 frames/sec).
Then comes a test of setting single pixels the usage of the buildin propeller font written in SPIN. I think this big font is not very useful for this display, so I did not rewrite it in PASM yet.
Next step is scrolling down the content while clearing the section that comes in from above. In my latest tests I also load a picture instead of clearing and scrolling up works as well .... well it works best when you have the picture saved in a upside down version, because you don't need seek then.
The lines are created by Chips line-drawing code from graphics driver.
Then there is a loop showing all BMP's found on the SD card. For the video I limited that to 3 BMP's, I have around 30 on the card because I can't get enough to see this display work ;o)
622,4ms is the time for normal load via FSRW and then move it to the display.
Then I tried the window mode of the display. You set the window and the display automatically increments the memory pointer so that it stays inside the window. So, if you have the BMP same size of the window, you simply have to move the whole file to the display.
Next is a bit slow, as I fill the whole display via SPIN and the set-pixel. It's purpose was to test the difference in 16 bit versus 18 bit color.
The girl loaded next is stored on SD as 16 bit version, plus it uses a modified FSRW. Here I do a direct output to the display instead of loading the data into a buffer. (275,2ms)
The following low color pictures were loaded old-style using a buffer and need 318ms.
In all low color pictures you see the missing 2 bits. Of course thes could be done better by dithering, but to be honest .. I don't like that.
After the last pic (the psssst-girl again) I did a test with an own font. 8x8 is a bit to small, but I plan to support at least 4 colors out of a color table - maybe more.
The squares which fade from blue to black actually are a test of drawing icons that use 16 colors out of a color table. Having icons like this means that one icon directly fitts into one sector: 32 pixels * 32 pixels * 4 bit / 8 bit = 512. And it's pretty fast.
Last picture is again a full color version, but this time with direct transfer from SD to display.
Next is a menu where an empty background image is loaded first. Then the menu-bars are loaded afterwards and that's what the 150ms measurement was about.
"Seet Home Com" was used to test what a animation looks like if the images are continuously reloaded. I think with a faster FSRW and not redrawing the spaces between the icons it would be fast enough. Or maybe with indexed colors ...
Last part shows how to update the small status icons (well the battery icon update is nearly invisible in the video) and how a clock would look like.
Hope you liked it.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
thank you very much for your help. I tried this version and it still does not work for me. It runs at half the speed. But at full speed I still get results close to 55 AA but only close to ;o) I tried it with 3 different SD cards, with different capacitors, with different crystals (as usually I use a 10MHz crystal) ... nothing helps.
Maybe it's the brand? All SD cards are from SanDisk ... I'll give it another try with another brand next time.
Maybe it's the breadboard? I'll run the old FSRW until I switch to a PCB ... maybe I'll create my own board or purchase one of the available boards.
What pins are you using? I wonder if it has to do with the path length for the pins which depends on the cog in use (see the "Cog and I/O Pin Relationship" section, pg 29 of the prop datasheet). I've used pins 12-15 and 24-27.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
I use pins 16-19.
The SPI reading code uses the Logic A & B mode, with A being the clock line and B being the DO line from the card. The clock line is only high for 1 clock cycle, and the logic mode of the counter uses both A and B delayed by 1 clock. What I'm not sure about is when the sampling actually occurs relative to the pulse's edge. And the card needs to see the clock pulse and respond within that time, which is guaranteed by the SD spec for operation of the prop up to 100MHz. I know any delay due to simply the length of the wires is not an issue because of my 9" test case. However, I don't know exactly how the _active_ propagation of the I/O from the specific cog to the specific pin delays the signal (though the data sheet mentions 1.5ns, which should be fine). More importantly, it apparently changes the capacitance of the pin, and I don't know how that affects the data signal coming back from the SD card.
(Do you have pull-up resistors? And if so what values?)
Pins 16-19 are as far away as you can get from cog 0. I would be interested in seeing how it behaved if the SPI code was in cog 7. Perhaps initialize the SD cog last, or even add in a few cognew's to a function with an infinite loop.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
I replaced the cognew by a coginit( 7 ...) and guess .... now it works. That makes me wonder at how they get all this GHz circuits to run reliably.
Thanks a lot lonesock.
Now let's see what the new driver can do for my display ;o)
I would like to get this LCD working: http://www.xtune.se/product_info.php?cPath=21_35&products_id=111
"In case you are keen on trying this, I could provide a snapshot of my current demo."
Yes please.
Have to redo all my virtual memory stuff and the direct write to display including the takeover of the control signals from SPFD driver....
The code you find in there is not cleaned up! I'd suggest to take the code as a not running example and just copy and paste things to an own program.
Base are the *_test.spin files. With mayor changes I tend to keep what was running before. In my setup, D and E versions were the latest - don't know if versions before would still run. D was using the old FSRW and E was for testing the 2.5 FSRW. Please note that in E all parts that used the CMD_COPY can not work.
The driver is in SPFD5408driverC.spin. I think that this should work with many different LCD controllers. It's a good idea to check all the values initData section. This is what your display expects in the initialization phase.
initSeq has to be explained a bit:
In the initialization of my display there are 2 wait-times defined after sending several register values. That's why I have the initSeq. The first value is the number of registers to set, the second defining how long to wait. The second value is simply used to divide clkfreq, which means lower value means longer waittime.
If waittime is 0, that's the last number of registers to be set and Init will return afterwards without waiting.
PS: Before I forget ... don't spend to much time in analysing the driver. It will be completely re-written during the next week.
Post Edited (MagIO2) : 12/11/2009 8:52:19 PM GMT
Now i will sit up all night trying to get my lcd up and running.
Thanks again.