PIC18F4550 Controlling PSP LCD screen

hello everyone,

For a while now I have been designing an 5.1 Surround Sound Amplifier for my computer. I have started making prototypes for the amplifier section and I am now going to move onto building the controlling circuitry controlling volume etc. After looking at the Sparkfun website I looked through the colour LCD's. I saw the PSP LCD and thought it was the perfect screen to use along with the touch panel. However after looking through the data-sheet I had a few questions.

1. are ALL the inputs eg hsync, display, colour 2.5v tolerant only or can I use 5v
2. can anybody direct me to a 5V to 28V step-up converter for the backlight
3. If I use a PIC18F4550 running at 48mhz (12MIPS) would i have enough time between each pixel to read 3 bytes in I2C memory to give colour information
4. Is this the best approach to controlling the LCD cheaply

If I wouldn't have enough time between each pixel to read the colour information between clock interrupts on RB0 is it possible to use a non-pic hardware clock divider to reduce the interrupts by half or use a pic counter to go high on every 41,525 and 480 clock.

If anyone has experience interfacing PSP screens and is willing to help me through my learning of how to use then please PM me your email or something

Thanks, Dave

I own that LCD but have not used it. I have made a boost converter. Its somewhere. Search through my topics. Also the Datasheet should have info on pin tolerances ill double check.

Please buy it from ebay its about $30 and sparkfun is $70 heh buy 2

I think VCC + 0.3v is the max and VCC is 2.5v so about 2.8v is max on input pins...

Here is a nice image i made for you to see and i understand your confusion.


Its funny because if its a 2.5v supply why have a max of 4.5v ? then it would allow for 4.8v Inputs.... confusing...

This LCD is one of my main reasons im going back to ARM. I need speed. The pin switching speed i dont care its the processing speed that matters now heh.

Sorry for the many post but i was bored and remade this:

Hey Atomsoft, I'm running 18F4550 @ 48MHz and pumping data to a 160x128 16bit display. But I'm unable to get more than ~6fps without any other processing. What do you think the reason is? Slow IO switching?
( https://www.electro-tech-online.com/threads/interfacing-an-oled-to-pic18f4550.111621/ )

Btw Dave, I also believe that you gonna need much more faster core than a 48MHz for such a display.

Thank you for your feedback. It has been very helpful

Would you suggest using a voltage divider on all the 28 pins or suggest another means. I may find a suitable DSPIC that can run at a faster speed and at 3.3 volts or is it still too high if I run the 2.5V logic at 3.3V

However i do have trouble when it comes too the actual code writing. I have gone on Gooligum Electronics before and found their tutorials very useful. however I have trouble understanding assembly. Should I try learning C as I have heard its much easier but it lacks the same timing abilities that you can have in assembly. However does anyone know an C tutorials that are very good and actually talk about the C language as the Gooligum C tutorial expects you to already know the C syntax. I normally use a high level language which is the basic compiler on PIC Simulator IDE. However it is impossible to use this program with the DSPIC series.

Looking at the boost power supply schematic it looks good but it has a high component count. I guess its what you need to get the output 6x as much as the input. however I suppose they are mostly off the shelf components

I'm not sure but because the forward voltage is 28v and the forward current is 18ma should I use a 56 ohm resistor in series with the back light.

Thanks again, Dave

You have focused on the power requirements of the display, but not the interface.. although most TFT's have a somewhat basic interface it usually requires some custom logic (usually in FPGA's, or CPLD's) or even a dedicated LCD controller (PIC32, epson IC's) to keep the display refreshed from ram. Even if you are only displaying a few lines of text, the display is 'dumb', and does not remember information, so you would need to constantly draw a screen 25-50 times per second. With 3 bytes per pixel, and its reolsution, thats a lot of data to pump through, even if most of the data is the same.

It can be done with single logic chips, albeit with LOTS of them. But its far easier to buy a dedicated LCD controller for the purpose of driving it. Of course you would still ahve to provide information to the display (and 'draw' fonts) but this is something your PIC can handle - it just doesn't have the peripherals, or speed of logic to do it all by itself. I believe a guy used two AVR's in tandem to controll a smaller TFT panel, but I can't find the link.

Sure $7 may sound like a lot for just one chip, but it wont' require much in the way of support circuitry, and has a nice 8080/6080 parallel interface similar to the old SED1335 series.

+1 on the controller chip idea. I think even for the PIC32, they recommend a controller chip for a display above a certain pixel count, or matrix size. Microchip uses a Solomon chip for their larger demo display units. They supposedly have a PIC24 now that can handle the graphical display functions. I would be suspicious though, of them trying to try and lock you in to their full C compiler???

Microchip tend to be quite good for providing 'demo code' that will run on the evaluation version of their C compilers (which I use, because I'm poor). Alternatively you could just get the source code for the demo and use AVR GCC, with minimal changes (forget about using the USB stack though). As you're using C, its not much different from using a PIC. I won't get started on the 'PIC vs AVR' since I use both, and the main reasoning behind which one to use is based on the (free) compilers available.

I didn't check the PIC LCD board, but does it by any chances use a SSD1906? I love that chip, Neeeded one, bought another 3 as backup Its handy for all the controllerless displays I have, STN, CSTN, and coolest of all, TFT. The in built functions like rotation, font drawing, multi layered screens can make it quite straight-foward to build a professional looking screen interface.

To be sure, I have not run one of these controller chips, or tft screens. Investigated using the PSP as a display and was intrigued. Finding a used PSP for a decent price was a real challenge (I wanted the display in a case), so put it on the back burner. Would be a really cool interface though, perhaps sometime down the road.

Looks like the Solomon chip Microchip uses with their demo display is the SSD1926.

The reason why I mentioned the full C compiler angle, was problems encountered trying to run 2.4ghz MRF24J40MA rf modules, with an 18F device. Most all of the demos simply would not work due to extended memory and optimization requirements, only supplied by the "pay for" full C compiler. This may not be a problem with the 24F, 32F versions? I think there is a stripped down version of a star network (that has been posted) which could work with the demo compiler, requires a revisit.

What i had in mind was using a DSPIC or similar at 40MIPS to control the display and do an 8 or 16 bit wide bus to another PIC which does some MP3 decoding, touch panel decoding and the all round coding for the user interface. Is this feasible to do on my own or not.

I do not understand how the LCD controller chips can directly control the PSP screen or is there alot of coding involved?

The other thing is that I would like high quality graphics, almost like a PSP screen itself and so I was thinking about having BMP pictures stored on an SD card which a PIC can read and send to the controller. I do not just want text fonts and lines.

Thanks again, Dave