Can the Propeller move graphics like this 8-bit chip when paired with a good LC
JRetSapDoog
Posts: 954
Update:· I've changed the title of this thread to focus more on LCD display controllers, wherein, here in this first post, this ILITEK controller connected to an 8-bit MPU can server as an example to get the ball rolling for various controllers we could·use with the Prop.· Perhaps we can create here a·list of potential display controllers with/without displays that we could use (or are using) with the Prop.
I came across a link on Crunchgear·today (which is also on Make), but the source post goes back a couple weeks.· A guy named Rossum over on Posterous has·a cool·post.· It apparently shows an 8-bit MPU with only 4KB of RAM (TRS-80 style) doing all sorts of "crazy" graphical things connected to a 2.8" LCD, things that would be definitely be impossible if it weren't for the fact that the LCD has an ILITEK ILI9325 LCD controller chip with 172,800 bytes of graphics RAM (GRAM).· I'm particularly interested in this LCD controller because it's the same one that my Propeller System Module (PSM) from Rayman uses, although·the PSM is·integrated with a TianMa display.··This ILITEK·controller supports a maximum of·18-bits per pixel·(2.25B/Px) at QVGA resolution,·which amounts·to 320x240x2.25 = 172,800 bytes.· The MPU in this demo is an Atmel 8-bit,·12Mhz Atmega644·chip with 64k Flash and 4k RAM.· Here's some links:·
This demo is·impressive to me.· Yes, an impressive·demo can be made that's not completely functional, but that little MPU·sure seems to be frantically hauling the bits around (from it's tiny RAM, Flash and an SD card to the ILI9325 display controller w/memory).· If it can do this, imagine what the Propeller could do.· Imagine what the Prop II could do!·
Post Edited (JRetSapDoog) : 11/9/2009 7:24:43 PM GMT
I came across a link on Crunchgear·today (which is also on Make), but the source post goes back a couple weeks.· A guy named Rossum over on Posterous has·a cool·post.· It apparently shows an 8-bit MPU with only 4KB of RAM (TRS-80 style) doing all sorts of "crazy" graphical things connected to a 2.8" LCD, things that would be definitely be impossible if it weren't for the fact that the LCD has an ILITEK ILI9325 LCD controller chip with 172,800 bytes of graphics RAM (GRAM).· I'm particularly interested in this LCD controller because it's the same one that my Propeller System Module (PSM) from Rayman uses, although·the PSM is·integrated with a TianMa display.··This ILITEK·controller supports a maximum of·18-bits per pixel·(2.25B/Px) at QVGA resolution,·which amounts·to 320x240x2.25 = 172,800 bytes.· The MPU in this demo is an Atmel 8-bit,·12Mhz Atmega644·chip with 64k Flash and 4k RAM.· Here's some links:·
Original Source Post w/Comments:· http://rossum.posterous.com/avr-homebrew-device-with-iphone-aspirations#comment
Rossum Source Code and so on:· https://sourceforge.net/projects/microtouch/
Larger Video as·provided by·Make:· http://blog.makezine.com/archive/2009/11/8-bit_touch-sensitive_handheld.html
Ray's Propeller System Module:· http://rayslogic.com/Propeller/Products/PSM/PSM.htm
ILITEK's ILI9325 Description:· http://www.ilitek.com/products-txt-e.asp?ck=17·(click Qui/Yes if prompted)
PDF for ILI9325 (111 pgs):· http://zaxxon.altervista.org/A320/ILI9325.pdf· (At a glance, I didn't see it on ILITEK's site)
Thai Easy Electric:· http://www.alibaba.com/product-free/104162003/2_8_262k_TFT_LCD_Touch.html· (same display, I think)
Rossum Source Code and so on:· https://sourceforge.net/projects/microtouch/
Larger Video as·provided by·Make:· http://blog.makezine.com/archive/2009/11/8-bit_touch-sensitive_handheld.html
Ray's Propeller System Module:· http://rayslogic.com/Propeller/Products/PSM/PSM.htm
ILITEK's ILI9325 Description:· http://www.ilitek.com/products-txt-e.asp?ck=17·(click Qui/Yes if prompted)
PDF for ILI9325 (111 pgs):· http://zaxxon.altervista.org/A320/ILI9325.pdf· (At a glance, I didn't see it on ILITEK's site)
Thai Easy Electric:· http://www.alibaba.com/product-free/104162003/2_8_262k_TFT_LCD_Touch.html· (same display, I think)
This demo is·impressive to me.· Yes, an impressive·demo can be made that's not completely functional, but that little MPU·sure seems to be frantically hauling the bits around (from it's tiny RAM, Flash and an SD card to the ILI9325 display controller w/memory).· If it can do this, imagine what the Propeller could do.· Imagine what the Prop II could do!·
Post Edited (JRetSapDoog) : 11/9/2009 7:24:43 PM GMT
Comments
Currently I am wirting a driver for a Crystalfontz display that uses a SPFD5408B controller. But on the first glance this controller is compatible with the ILI9325. I'll try out Raymans demo-code.
Well ... don't know yet how the 3d part is done, because it refreshes nearly the complete screen .. or maybe it's a trick and it only refreshs the changed pixels. Currently my driver uses 8 bit interface, so it needs 3 bytes transfer per pixel and is to slow to update the display at reasonable frame-rates. Maybe I have to switch to 16 bit mode. But for the first steps 8 bit was easier because you can simply read a BMP file and send it to the display. In 16 bit mode the BMP has to be preprocessed.
The slideshow part is easy, as those controllers allow to shift the display without shifting content in RAM. So, you only have to shift the whole picture 1 pixel and refresh the one line that appears on the other side of the screen. This is the next function I want to add to my driver.
In fact I want to have a IPod-like user interface for my propeller.
www.ett.co.th/product2009/LCD/ET-TFT240320TP-3.2.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
http://www.thaieasyelec.net/index.php/display-module/breakout-board/breakout-board-2-8-inch-qvga-tft-lcd-with-touch-screen/p_3.html
it uses an ILI9325 with 8 bit data, with 5 control lines. plus the touchscreen is an AD7843 SPI device, which needs a further 5 for the SPI including pen interrupt
its 262K colours ( as i recall)
its not particularly fast, but is fine .
it was $54
Mike
I would be interested in how he created the image-files. The color scheme in 64k mode is 5R/6G/5B. Is there a program that can convert BMP-files to this format or do I have to write a converter by myself?
Yes, on first glance, 8-bit demo seemed too good to be true, considering the puny amount of RAM available and the nature of the MPU. However, on considering it further, with the Prop, it would often be the case that we would dedicate a single cog to communicating with the display controller, and, at 4 cycles/instruction, that gets a down to 20 MHz, which is in the neighborhood of the MPU in this demo. And, although the MPU in this demo is only an 8-bit one, with the Propeller, we'd likely only use 8 bits (or maybe 16) to talk to the display. So, with one cog, we're down to similar performance. Of course the beauty is having 7 other cogs with which to do other things.
Regarding the scrolling, although I've read through the ILI9325 datasheet in the past, I didn't recall offhand whether it could move the pointer to display memory around (but, of course, why wouldn't it be able to since it's got the memory). Thanks for that comment, Mag, and good luck on implementing scrolling with your display. Maybe you can keep us posted.
Also, yes, if using a serial RGB interface, one would need to pump data to the display three times per pixel, consecutively, which would slow down performance. By the way, if using a 16-bit mode (5R-6G-5B, 64K colors), for the demo I'm wondering if it would take just one transfer per pixel, or two. I'm not familiar with that chip but was assuming it had an 8-bit data bus since they call it an 8-bit chip (I know I should check), so, if using the so-called 16-bit color mode, I would think that it would need to send out a byte twice per pixel, which is better than 3X/Px but not as good as 1X.
Anyway, with our "remaining space" (before we max out the database), I thought we could mention display-related things here (with or without display controllers). On the one hand, based on Rayman's work with his most recent display, it seems like having a display controller with memory is not even an essential requirement. If I understand correctly, he's already got one cog on the Prop pumping data fast enough to a memory-less display using a modified VGA driver. That's certainly fine for many applications and quite cool. Moreover, it's much easier and somewhat cheaper to find displays that don't have memory built in than those that do. So, that's certainly a good way to go for many or even most common situations to which the Propeller is applied.
However, a problem arises if one want to send hi-color graphics or photos to the display due to the Prop's limited memory (the Prop II could help a lot in that respect). Whatever is sent to the display must be constantly refreshed (although I was surprised to learn that Ray was able to drive his display at low refresh rates without flicker). On the other hand, even with a display controller with memory, there can be a problem if one wants to double-buffer graphics (unless the display memory is twice what one needs and can be partitioned). Also, for a display with memory, an important factor is whether one is using it in "video mode" wherein the display expects to be constantly written to in a synchronized way (to avoid tearing of animation, etc.), or whether one writes to the display more leasurely. At any rate, there's a case to be made for using displays with and without memory.
Here are video links:
COBY DP151 Hacks www.youtube.com/watch?v=JpyX3l569RU - Code is not line. Parallel bus.
SFE Nokia-knockoff www.youtube.com/watch?v=YalcMqkdHEU - Code is on forum. SPI bus.
We just have other goals / interests.
Other points:
- PSM LCD has GRAM, but has no touch screen.
- 4.3" LCD has touch screen, but no GRAM. Unfortunately we can not show pictures or a reasonable amount of colors.
- Propeller memory: only 32KB RAM (code + var.) vs. AVR: 64KB code + 4KB RAM (+ EEPROM???)
We have solved the problems of memory using alternative methods, such as ProDOS, etc.
Now needed (urgently), a Propeller with more memory (and pins [noparse]:)[/noparse]), but no news from Propeller II, presumably would be available last year or so.
Post Edited (JRetSapDoog) : 11/9/2009 9:25:59 PM GMT
http://forums.parallax.com/showthread.php?p=821309
You say that your interest "wanes." That's honest and interesting. I think that's a common problem. A project can become an ends unto itself without a clear mission afterwards. That's a big problem, but, at least for most of us here, a lot of learning can be had along the way, often appicable to other ideas. And then the cycle repeats, lol, for better or worse. Now, in your case (pun intended, considering that project box), perhaps what you need is the advent of the Prop II to re-inspire you, perhaps coupled to a bit bigger display (with or without GRAM). Surely that's the ticket! But, then again, after that,·you'd want it to have wheels or wings to keep your interest.
But there is a good point in this: sometimes a successful project needs to be sufficiently "standardized" so that many people can build on it (rather than just everyone going in a million directions), either that or it needs to have an upgrade path. In certain ways, I think the Hydra game machine addressed these areas. Perhaps in its case (warning, another poor pun coming), it could have been, or could be, even more successful if an injection-molded case had been crafted for it. Yes, an expensive prospect when one is unsure of the market demand. Hmm...maybe we could have some standardized plastic cases for Propeller stuff. Anyway, thanks again for your answer.
Post Edited (JRetSapDoog) : 11/9/2009 10:39:12 PM GMT
http://forums.parallax.com/showthread.php?p=847577· <-- quote below is from this link (bot. of pg. 1)
The "#2" display of the 4 he's evaluating has a Solomon Systech SSD1926 controller w/GRAM and some other weird stuff thrown in for fun.· Solomon Systech (out of Hong Kong) has quite a few interesting controllers.· Some are standalone ones and others are for integrating with a display (as they also drive the display's columns and rows).· Here's a quote from the second link above from·Bill about his #2 display:
As you can see, this controller has graphics primitives built in that could be used to offload some work from the Prop.· On the one hand, that's good, but, on the other hand, it perhaps raises the complexity (needing to know two chips) and makes the design dependent on a particular specialized chip.· At any rate, I think it's interesting and hope that he succeeds with the driver.· The folks that responded to his survey about which displays they'd be more interested in typically preferred the other displays for various reasons.· But this one has quite a bit of potential and could be used for many graphical things (BMP or perhaps even JPEG) that the other displays can't really do with just a Prop.· Anyway, as Bill suggests, at least in the beginning, the main thing would just be to take advantage of the GRAM.· Those other things might be kind of "esoteric" and more targeted at a digital photo frame, though there's nothing wrong with that.·
Post Edited (JRetSapDoog) : 11/9/2009 10:34:05 PM GMT
I have been too busy with PropellerBasic to work more on that little display, but I have big plans for it.
For a large class of applications it is more than good enough - at a significantly lower price point than my 5" VGA display. I love the fact that it has enough GRAM for displaying photo's!
For pin-limited applications, I still prefer NTSC displays, because with 3 pins you get some text and graphics; even from a bare dip chip, and with good NTSC displays, 40x30 text is possible.
This parallel display takes 12-14 pins, but it will be able to do very crisp text and graphics - up to 53 columns by 30 rows of text with my 6x8 font!
I can't wait to finish the driver and run my demo's on it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
using the 8 bit interface, does indeed require 3 xfers per pixel.
This results in taking about 1 second to clear the display, by writing a colour to every pixel.
The PIC I am using is an 8 bit device, so that also compounds the problem.
drawing lines and circles etc, requires algorthms such as Bresenhams, which is compute intensive.
Since the display is 320x240, of course it needs int16 variables, and for calculation such as temporary multiplication using Bresenham, int32
The poor old PIC is using intructions just to get to 16 and 32 length, unlike an ARM or the propeller.
However, for a typical HMI such as touchpanel display of 4 buttons, with displays such as temperature, pressure etc, it is no problem.
The PIC 8 bit device is not a good solution, but I started the design using a PIC18F4580 because of its CAN bus, and familiarity.
I had not planned to stick a colour graphic LCD on it, but had time on my hands, so had a go.
I do think that using a colour graphic screen with a propeller requires separate controller such as the ILI932x
Hope this helps
Mike
In the driver I wrote I copy pixels at a rate of 3MB/s from buffer to display. Maybe it can be increased when using counters for WR signal generation. The all in all read from file print to screen still takes a while because I use SPIN as glue between SD driver and display driver and the SD driver is an old one. I'll try another one soon.
In bresenham line algorithm your repetitive task is addition and subtraction only. Only for setup you have to divide by 2 which is fast as well.
In bresenham circle algorithm you also have to multiply by 2 in the loop ... which still is fast.
The advantage having a propeller is that one COG can do the communication with the display at max-speed, whereas the other one is preparing the pixels.
My opinion on displays:
The NTSC/PAL displays are wonderful for technical applications that don't need a graphical output at all or maybe a rough graphic is fine. With the right font text windows and nice text menus are possible.
640x480 with raw interface is fine for technical applications that need to output more text. In bigger applications graphics output impossible.
Any display without controller is a pain when you want real good graphical output, as the propeller does not have enough memory and/or IOs.
262k versus 64k colors: Difference is noticeable when you want to display pictures.
320x240x18 8bit mode - you need 10 to 13 pins depending on what functionality you need/support. CS can be tied to low in case you don't need the data bus for other devices. RD can be tied to high in case you don't need to read content of GRAM. RESet may be not needed if you make sure that the display gets a power on reset. RS (register select) and WR are needed anyway.
320x240x18 8bit mode 262k colors - as far as I can tell it's fine for a GUI with nice text and perfect icons, maybe background-image. Marking active selections in a menu shouldn't be a problem. General text output should be fine. BMPs can be directly loaded into GRAM. SD card is a 'must have' for that.
320x240x18 8bit mode 64k colors - transfer is faster, but you have to prepare the image that you use. BMPs can not be used directly. So, the development efford is bigger if you use a lot of icons.
320x240x18 16bit mode 64k - eats up more pins 16 data + 2 to 5 for control. Animated icons should be possible.
I want a real nice GUI, so I plan to go for another display with a 18 bit data-bus. My current one only allows 16 bit. The controller could do better, but the display manufacturer only attached a flex with 16 bit data-bus. I think in the end I'll have a 2 prop design, where one prop is for user interface only.
I totally agree that the PIC is slow in comparison.
The propeller unfortunately has neither the memory capability, or pins to do the job itself.
I dont want to get into a religion wars here, as usual its horses for courses.
The PIC18F4580 not only is successfully controlling the LCD system, but also the CAN bus,
16 Relay outputs, 8 digital inputs, 2 optocoupled I/O's, 4 12 bit DAC outputs, 8 12 bit analogue inputs, 3 serial ports, and a Dallas 1 wire bus.
as I said in my earlier post, a PIC is not good at the display task, but it does work.
My point in getting involved with this thread was to give my opinion that the graphics lcd should be handed off to a dedicated graphics controller.
Mike
below is the working circle drawing algorithm.
looks like there is multiplication going on to me.
I didnt write this, just modified this for my own purposes such as thickness of circle line
/////////////////////////////////////////////////////////////////////////
// Purpose: Draw a circle on a graphic LCD
// Inputs: (x,y) - the center of the circle
// radius - the radius of the circle
// fill - YES or NO
// color - int16
/////////////////////////////////////////////////////////////////////////
void glcd_circle(int16 x, int16 y, int16 radius, int1 fill, int16 color,int8 thickness)
{
signed int16 a, b, P;
a = 0;
b = radius;
P = 1 - radius;
do
{
if(fill)
{
glcd_line(x-a, y+b, x+a, y+b, color,1);
glcd_line(x-a, y-b, x+a, y-b, color,1);
glcd_line(x-b, y+a, x+b, y+a, color,1);
glcd_line(x-b, y-a, x+b, y-a, color,1);
}
else
{
glcd_pixel(a+x, b+y, color);
glcd_pixel(b+x, a+y, color);
glcd_pixel(x-a, b+y, color);
glcd_pixel(x-b, a+y, color);
glcd_pixel(b+x, y-a, color);
glcd_pixel(a+x, y-b, color);
glcd_pixel(x-a, y-b, color);
glcd_pixel(x-b, y-a, color);
}
if(P < 0)
P += 3 + 2 * a++;
else
P += 5 + 2 * (a++ - b--);
// } while(a <= b);
} while(a <= b);
} // end of function
just noticed you comment requesting clarification.
there is no video involved here, its not composite NTSC or PAL.
the 1 second ( probably 1.5 actually) screen clear illustrates the slowness of the PIC sending out glcd_pixel(x,y,colour) commands through an 8 bit interface, which is then multiplexed via 3 8bit latches (LHC245's).
it works, it aint fast, but it would be OK in my application.
moving pictures, it wont do !!!
small bitmaps it will, when i can get the C function to work
Mike
Do you mean this part? Well ... you should rewrite that. Multiply by 2 is the same as shift to the left one bit. And that's directly supported by the PICs-assembler instructions. I'm not sure if the C compiler is doing optimization at that point. I'd not rely on it and write a++<<1 and (a++ - b--)<<1 directly.
I don't like religions as well. Just wanted to point out that a >1second clear screen is not due to the display interface. It's because your PIC is busy with handling a lot of interrupts and doing other things.
If you want a display with high color, for the PIC and for the Propeller the only practical way to go is to use a display with controller and·for both it's still not a perfect solution. But·that's not a surprise, as we talk about microcontrollers - they are meant for doing·little things ;o)
@MagIO2:· Thanks for those comments, especially for stating, "CS can be tied to low in case you don't need the data bus for other devices. RD can be tied to high in case you don't need to read content of GRAM. RESet may be not needed if you make sure that the display gets a power on reset."· I've wondered about the first two.· I figured that'd be the case for the chip select (though wasn't completely sure), but I wasn't sure about RD (those timing sheets make me dizzy, lol).· Tying RD high would work for me.· I don't think reading the display memory would be much of an advantage for my purposes.· I suppose it might be needed if doing some kind of image processing, or one could hide some data there if not using the whole 320x240.· But those are exceptional situations.· Moreover, I recall that the reading process is slow (compared to writing), so the utility drops.· Regarding·that last item·about the reset line, I'm still a bit in the dark about the power-up sequence for a display, so I can't fully appreciate the meaning.· The datasheets for small LCD displays seem to have a lot of rules regarding the power-up sequence, rules which if ignored might potentially damage or lock-up the display.· At this point, I don't even know whether the main power to the display must be turned on by the MCU separately and subsequently to the MCU firing up or whether everything can be turned on in common.· But hopefully that and the other reset matters will become clearer as I learn more.· Thank you very much for providing such specific information about which lines are needed.· That information is very useful and addresses some things I'd wondered about.· One has to wonder about such things when they are carefully keeping track of how many precious pins they have left.
Of course after the reset you have a sequence to initialize the display, but as long as you make sure that no noise on the data-lines will set registers in the startup-time that the propeller needs, it should be fine. The reset itself should be low for 1 ms minimum. No max. defined. ( Of course you should verify these things in the specs of your controller, but I think all these controllers have very similar handling )
VGA 640x480 w/ 4 colors out of 256 color palette per scan line
SVGA 800x600 w/ 4 colors out of 256 color palette per scan line
XGA 1024x768 w/ 4 colors out of 256 color palette per scan line
XGA timing, 256x192 w/ 256 colors per pixel
coming soon:
320x240 w/ 256 colors per pixel (VGA timing)
400x300 w/ 256 colors per pixel (SVGA timing)
512x384 w/ 256 colors per pixel (XGA timing)
The 256 color per pixel limit is not great for photo's, but it is more than enough for great looking HMI screens.
I avoid the messy 40-60 pin flex cable connectors etc by sourcing a very nice 5.0" 640x480 TFT LCD with analog board providing VGA, NTSC and PAL input.
Works great
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Speaking of Crystalfontz, they also have a seemingly nice 3.5" display that uses Solomon Systech's SSD2119 controller.· Like the ILI9325, it also offers 320x240x18 = 172,800 bytes.· Hear are the links from Crystalfontz (full disclosure:· I'm the principal shareholder....NOT), including the datasheet.
3.5" LCD display:· ·http://www.crystalfontz.com/product/CFAF320240F-T.html
3.5" LCD w/TS:· http://www.crystalfontz.com/product/CFAF320240F-T-TS.html
SSD2119 Data:· http://www.crystalfontz.com/controllers/SSD2119.pdf
One reason I like this company is that they are up-front with their prices.· Haven't tried them yet, but comtemplating it.
Post Edited (JRetSapDoog) : 11/10/2009 5:55:42 PM GMT
Thanks for the info on crystalfontz - their prices have come down since the last time I checked them out!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
@bill:
Switch on any new commercial device - mobile phone, harddisk recorders, satellite receiver .... whatever - you'll hardly find one which does not use a pleasant looking user interface. That's what I want with little efford. I also use a 3,5" NTSC display for my COG-OS and it makes perfect sense to use such kind of displays in a more technical environment. But for the high color way I think that displays with controller are the easier way. ... And now that I saw the BMPs on my display you can't change my opinion anymore [noparse]:o[/noparse]) At least unless you come up with a 18bit or more solution.