emwin speed

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

emwin speed

7,373 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Thu Feb 14 05:43:08 MST 2013
I have a speed problem with emWin. I have board with a 4.3 inch 24bit LCD and the LPC1857.The processor and the LCD are connected via 24 lines. I use MEMDEV so I need a lot of RAM. I divided Video-RAM to be used for LCD and emWin GuiConf.c. But performances are bad. Everything work very slow (picture moving, etc.). What can I do?
Labels (1)
0 Kudos
20 Replies

6,886 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Tue Feb 26 04:19:06 MST 2013
After testing I have some new results. If I lower processor clock to 36 MHz and set FCCO to 288MHz the program works with the emWin library in the flash and RO data in the external RAM. But when I set clock to 72MHz the same problem arise. 
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Thu Feb 21 03:39:13 MST 2013
We are using the same SDRAM as it is on the MCB1800 (48LC4M32B2). The connections are the same. The only difference is in 3 data pins (D8, D10, D11); we have them on P1_15, P1_18, P1_20; MCB1800 have them on P5_4, P5_6, P5_7.

On LCD side we use 24bit connections and MCB1800 uses only 16bit connections.

When the RO data is loaded in the external RAM? For ZI data I understand that is saved in a RAM on the run. How is it with the RO data. Is it loaded from a flash to a RAM when necessary or what?
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mc on Wed Feb 20 10:09:00 MST 2013
Hi Cusko,
Looks like your PCB has more parasitic capacitance than MCB1800. Which SDRAM are you using? Did you program EMC for this SDRAM? How different is your board than MCB1800 in terms of components and schematics?
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Wed Feb 20 03:54:02 MST 2013
I measured with an oscilloscope. I found only difference with the MCB1800 in the CLK0 signal. On our board the CLK0 signal doesn't go back to 0V when oscillating. I am attaching 2 pictures showing the difference. And I checked the processors revision (my board and MCB1800) and they are not the same. Any suggestions.
Thank you!
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Wed Feb 20 01:00:35 MST 2013
I will test it with oscilloscope. My project is already uploaded in this topic.
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by mc on Tue Feb 19 08:15:30 MST 2013
Hi Cusko,
Use Oscilloscope and probe the clock pin of SDRAM. It will help to determine speed. Also you can upload your project here.

Thanks,
NXP Support
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Tue Feb 19 01:59:18 MST 2013
I checked every pin and I didn't find the mistake. But I don't know how to slow down the EMC or how to use analyser. Any suggestions?

I found another thing that might help. If I program the device with the wrong settings and successfully
enter debug mode, the program start from address 0x10403E00 instead from startup_lpc18xx.s

0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Wouter on Mon Feb 18 07:51:12 MST 2013
That's very strange! There should be no problem running the library from internal Flash.

As the example works fine on the MCB1800, an issue with your board seems the most logical cause. Especially the external memory interface is suspicious, I see from your source code that you have another configuration then used on the MCB1800. Please verify all settings of your EMC for your board, and verify the memory signals using an analyzer. You can also try to slow down the EMC and check if running the library from internal Flash does work in that case.

Regards,
Wouter
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Mon Feb 18 04:06:22 MST 2013
Hi Wouter,
Thanks for help so far.
I modified your example. But the problem stays the same. In order for your example to work on my board (not MCB1800) I had to change RO data for the emWin library to an external ram, set an optimization to "Level 3" and check "Use MicroLIB". After those 3 steps the program works fine but slow.
Maybe the problem is in the GUI driver I use (GUIDRV_LIN_32)? I am attaching your modified example that works on my board.
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Wouter on Mon Feb 18 02:36:14 MST 2013
Hi Cusko,

Over here your attached project does not work and gives compilation and programming errors.

If I understand correctly, the example I send earlier is working (when disabling the optimize for time option). I assume the performance is much better also. Therefore I'd recommend to use that project as template and edit it to your needs.
If you're interested in why your own project is not working, please compare it to the working example.

If you have any other questions, please let us know!

Regards,
Wouter
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Fri Feb 15 06:58:07 MST 2013
Yes, my mistake. From your example you must remove flag "Optimize for time" in order to work.
On the Keil board this problem doesn't exist. I thought I test this but I didn't.

I am attaching my project that doesn't work with emWin on internal flash.
I explore my project in detail. I noticed that if I uncheck "Use MicroLIB" or set Optimization to any level except Level0, program won't work. Even if I have emWin lib in external RAM.
Attached project works.   
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Wouter on Fri Feb 15 05:03:36 MST 2013
The project you've attached is configured to run from external memory, not from the internal flash banks.

Please try attached project, it has an additional configuration to run from internal flash. I don't have any MCB1800 board with me currently, but it should work. If not, pease let me know and I'll test it on Monday.

Regards,
Wouter
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Fri Feb 15 04:46:41 MST 2013
I am using my own board but I get this from the KEIL examples for the MCB1800 board. It is the same problem on their board, so I attached a MCB1800 example. I supposed you have the uvision installed. If not I will prepare you a whole project.
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Wouter on Fri Feb 15 04:21:43 MST 2013
That's indeed strange!

Can you zip your project and attach it to this thread? And which board are you using?

Regards,
Wouter
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Fri Feb 15 04:13:27 MST 2013
I execute all other code from internal FlashA and FlashB.
I tried to leave emWin library to default but that doesn't work.

If I run some small example so that GuiConf don't need external memory and ZI data is in internal memory then emWin library can run from Internal flash. Strange behaviour.   
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Wouter on Fri Feb 15 04:00:08 MST 2013
Hi Cusko,

This last comment explains the bad performance; the RO region is where all constant data AND code is placed. You're executing the full emWin library from external RAM, where also you framebuffer and GUI buffer are located!

Once again, from which region is the other code executed? You should be able to execute the emWin library from the same region as all other code. If you execute from internal Flash, you should get great performance!

Regards,
Wouter
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Fri Feb 15 03:50:49 MST 2013
And I noticed another strange thing which might causing bad performance. If ZI data from GuiConf.c is in an external RAM, the ReadOnly (RO) data from GUI_CM3.lib must also be in the same external RAM. If is it not, the device won't work and cannot be programed again due to error "Could not stop Cortex_M Device". Why?  

So I for GuiConf.c ZI data I use external RAM1.
For GUI_CM3.lib RO data I use external RAM1.
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Cusko on Fri Feb 15 03:47:37 MST 2013
I execute zero initialized data from GuiConf.c in the external RAM because an internal RAM is too small. In the EA LPC1788 examples they did the same.

Can I use a SPIFI as a RAM???

Core running at 180Mhz. As for the EMC I am not sure because I copied code from the Keil.

0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Wouter on Fri Feb 15 03:44:57 MST 2013
Zero-initialized data from GUIConf.c should indeed be placed in external RAM. But my question was, from where do you execute your code? E.g. in keil, what memory space have you configured for ROM/IROM, which of the regions is set as default, and did you change the code/const location for any of the files, or do they use the default region?

Regards,
Wouter
0 Kudos

6,888 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Wouter on Fri Feb 15 00:53:00 MST 2013
Hi Cusko,

Most performance issues with the LPC1800/4300 are due to not optimal code placement. Execution from interal RAM is the fastest followed by internal Flash, then SPIFI memory. As you have an external RAM device for your framebuffer, the EMC is already very occupied.

So, for best performance, be sure to use either internal RAM, internal Flash or SPIFI and avoid external parallel memory for code execution.

Verify the core/EMC are running at maximum possible speed, and if your using SPIFI, ensure it uses 4 bit mode and verify the clock of the SPIFI.

Regards,
Wouter
0 Kudos