I didn't even think about the RAM requirements for a CPLD - makes this 
especially difficult since the SSD1926 that needs to be replaced has 
256K onboard.  I've looked into some of the possible micros with onboard 
LCD, and they're usually lacking a large amount of internal RAM - the 
LPC2478 you mentioned is a nice part and would be a great fit 
(especially since it's not BGA) if it had a little more RAM.  Pulling 
4MHz from the PIC is a good idea I hadn't considered.

Thanks for the input,

Tony

Mike Harrison wrote:
> On Sat, 27 Feb 2010 17:35:15 -0600, you wrote:
>
>   
>> I know I've probably asked this question before here or elsewhere, but I 
>> need a cost effective alternative to the SSD1926 RGB LCD driver.  I'm 
>> using it between a PIC24 and a 472x280 resolution LCD that has a 24 bit 
>> RGB interface (8 bits per pixel), and the standard hsync, vsync, pixel 
>> clock control lines.  In addition to the horrible availability of this 
>> part and the high price ($7 is the best I've seen in about 1K 
>> quantities, and I'm only looking at using around 250 annually now), it 
>> requires that I have a 1.8V supply available, and about a 4MHz crystal.  
>>     
>
> You can probably get 4MHZ from a PIC24 compare output - 1.8v regs aren't exactly expensive (e.g.
> Microchip MCP1700) as long as you're not after the last drop of efficiency by using a switcher. 
>
>   
>> All this is detracting from my ability to manufacture something at a 
>> reasonable price.  Some time ago, it was suggested that I might be able 
>> to make my own driver using some kind of programmable logic device.  
>> Does anyone either know of a direct alternative to the Solomon Systech 
>> part, or where I might start in terms of CPLDs.  I have absolutely no 
>> experience with CPLDs, or FPGAs, but I'm curious about the subject and 
>> would be interested in doing something if I could get the core parts 
>> cheaper and learn something in the process - but only if it's not 
>> leading me down a dead end. 
>>     
>
> The  minimum hardware would be a CPLD and a SRAM - you could probably offload some of the work, like
> sync generation,  onto the PIC's timer/compare/PWM modules to reduce the size of CPLD required. For
> some reason there is a big price jump in CPLDs above around 72 macrocells, so anything you can do on
> the MCU will help.
>
> A CPLD+SRAM solution would help with availability but I doubt you'd save a lot on cost (although at
> low volumes the gap may be bigger) - much of the cost is the silicon area of the SRAM required,
> which you have whether it's integrated on the controller or seperate.
> Unfortunately, MCUs with integrated TFT-LCD controllers (e.g. ARM LPC247x) also come with a bunch or
> stuff you don't need, but still pay for, and even then often need external RAM.
>
> FPGA would be more expensive unless you could also utilise it for other parts of the system. 
>
> I did read recently about an MCU with enough onboard RAM to run its onboard tft controller with no
> external RAM - I think it was Renesas .
>
>
>   
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist