I currently have an EMX mounted on my own custom board. I am working on coding a user interface and have hit a significant issue. It seems the pixel clock is not running fast enough to give me a reasonable update rate (say 60Hz). I am using a 7 inch 800x480 display, so here’s what I figure the pixel clock should run at to get a 60Hz refresh rate:
800 * 400 = 320,000
320,000 * 60 = 19.2MHz
It doesn’t seem like that frequency should be any problem for the LPC2478. Just in case anyone is curious, I am using the FEMA Corp. PN: GM800480C-70-TTX2NLW-TP display.
The other issue I’ve run into and I think Skewworks also found this out is that WPF sucks for throughput. I’ve found that using WPF I can’t have more than a few objects on a canvas or panel before I begin seeing significant delays in touchscreen response. I’m assuming this means the Render methods that are called when I make a change are eating up too much process time. I think I’ve fixed this by going to all bitmaps but I wanted to see if anyone else ran into this.
Considering the PLL and consequently the CCLK that is the source for the pixel clock can be programed to be up to 550MHz I don’t see any problem with the requirement that the CCLK be divided by say 15, which would give a pixel clock of 36.67MHz. The typical clock frequency called out in the display datasheet is 33.2MHz.
Keep in mind the LPC2478 is advertised to handle up to 1024x768 at 24bpp and still maintain 60Hz, so my requirements should be pretty mild by those standards.
Maybe on an SRAM whith 32-bit bus and special optimization?! From our experiments, this sounds too good to be true! Maybe the LCD peripheral is capable of doing so but then the SDRAM bandwidth wouldn’t allow that.
800x480 can be done for sure as we have tested it already but with a clock divider of 5 (if I remember right)
Yeah I started with a clock divider of 5, and then turned it down to 3 which is better, but not good enough. I wish I had measured the actual pixel clock frequency, but does anyone know what the PLL output frequency is set to right now? I would think all it would take is to bump this up.
Gus, you said 800x480 has been tested, what was the refresh rate you guys achieved?
I’d really like to not have to go into RLP and write my own LCD driver if I can help it. Also, it seems that my control over the LCD controller would have to be somewhat limited in RLP since I couldn’t just willy-nilly change the system clock frequency without the rest of the system being affected.
What level of control does RLP offer in that regard?
Using RLP for internal-TFT-LCD driver is bad idea. The configuration gives you everything. I do not know what refresh rate but the divider is set to 5. The LCD peripheral is clocked at 72Mhz.
You can easily scope the clock pin to determine your LCD clock if you like
Using higher clocks (lower divider) may choke the system. The display works but then other peripherals may start to fail due to SDRAM being overloaded, like USB Host.
I am only using the EMX for the TFT display interface, touchscreen controller, and a relatively slow serial connection (9600 baud). So the LCD controller can eat up 80% of the processor utilization and it won’t be a problem for me. However I have found that reducing the pixel clock divider any lower than 3 causes the pixels to smear drastically, almost as if the data bits weren’t keeping up with the clock. I need to get a logic analyzer hooked up to investigate that any further.
I was hoping GHI would have some information as to why 5 was chosen over 3 or 8.
Also, what is your solution to the slowness of WPF?
First, you did not explain where 5 came from previously, go back and read your posts.
Second, I don’t need the attitude. I realize you deal with a lot of hobbyists and people that don’t always know what they’re doing, but that is no excuse. I am a paying customer designing your module into a product.
Third, a pixel clock divider value of 5 gives a clock frequency of 14.4MHz which makes sense if CCLK is set to 72MHz. The reason I wanted to understand why GHI chose 5 is because I don’t understand why you would choose a value that only gives a refresh rate of 38Hz, which can easily be seen by the human eye. I need to understand if it is realistic to expect that I can get the EMX to a point where it can handle a sustained refresh rate of 60Hz. Whether that is possible or not determines whether the EMX is designed into my product.
No attitude, it is a simple misunderstanding. I apologies if I sounded different. I went back and read what I posted and still do not understand why you misunderstood my answer! I am answering your questions within few minutes and on the weekend so I am really trying my best to help.
As you seen already, this forum is more relaxed place to chat about projects and to share knowledge between everyone interested in NETMF, professionals or hobbyists. Of course, feel free to call or email directly for support.
I do appreciate the quick response, as that has always been a great thing about GIH’s forums.
Maybe I’m not explaining what I need very well so let me start with what I currently understand. You told me GHI has tested the EMX with a 7 inch display and found that it worked well with a pixel clock divider of 5. In my testing, I have found that I can see the display raster scan updates at that speed. My questions is this, did GHI also see this, and if so is there a way to mitigate it?
@ Gus. I have several cobra’s with different displays.
If powered by the USB only there is noticeable flicker on all the displays.
If powered by a 5v 10W switched mode supply, directly onto the 5v rail then there is no flicker… I know this is probably not the case in this instance but its worth noting that the supply can make a subtle difference.
I am not using the FEZ display, but instead the FEMA Corp. display I mentioned in my initial post. Instead of using Hsync and Vsync it uses the DataEnable and PixelClock lines. However I don;t see how that would affect the module throughput.
I really just need an answer as to whether GHI has actually been able to get a 7 inch display to run at a refresh rate of 60Hz. If it isn’t possible then tell me so I can find another solution.
I work for a contract design firm where I have designed numerous medical devices with ARM7 microcontrollers. These devices often use large LCD displays and I have never run into this issue.
The point I’m making is that this micro is more than capable of the throughput required to maintain a 60Hz refresh rate on a 7 inch display. An example of a kit I’ve used in the past is: uEZGUI-2478-43WQS. Check it out on Mouser.
That kit had no problem maintaining 60Hz refresh. What I’m hearing from you Gus is that GHI is not interested in seriously pursuing this issue right now. You did say that you’re working on WPF, but that isn’t going to help if the low-level driver isn’t set up to handle the data.
If the EMX isn’t capable of this then why sell a display for it?