LPCXpresso IDEのトピックRe: LPCXpresso Limitations

LPCXpresso Limitations

lpcware — Thu, 16 Jun 2016 00:39:25 GMT

Content originally posted in LPCWare by railtech on Thu Jan 05 02:30:11 MST 2012
Hi,
I am new in LPCXpresso.
I have few questions about the limitation of this IDE. I know that its debug limit is 128 KB.
Questions:
1. Is it capable to build code size greater than 128 KB?
2. Does it support programming or debugging of LPC1768 (Flash 512 KB) but code size less than 128KB?

Thanks
:):):):)

Re: LPCXpresso Limitations

lpcware — Thu, 16 Jun 2016 00:39:26 GMT

Content originally posted in LPCWare by OXO on Thu Jan 05 02:36:02 MST 2012
1. If you pay for the unlimited version, yes

2. yes!

Re: LPCXpresso Limitations

lpcware — Thu, 16 Jun 2016 00:39:27 GMT

Content originally posted in LPCWare by Ex-Zero on Thu Jan 05 02:45:27 MST 2012
1. Yes :eek: It's a 128k limit for debugging / downloading. The compiler isn't limited :), so you can compile a hex file and use FlashMagic to program.

2. Yes :)

Re: LPCXpresso Limitations

lpcware — Thu, 16 Jun 2016 00:39:28 GMT

Content originally posted in LPCWare by railtech on Thu Jan 05 21:20:48 MST 2012
Thnx for rply
I need one more help please.
How can I change Clock Configuration(Main PLL, USB PLL, CLKSRCSEL etc.) through a user interface like uVision by clicking on Configuration Wizard of "System_LPC17xx.c" file. It'll be very helpfull if possible.:cool::cool::cool::cool:

Re: LPCXpresso Limitations

lpcware — Thu, 16 Jun 2016 00:39:28 GMT

Content originally posted in LPCWare by vasanth on Sat Jan 07 10:50:00 MST 2012
My release builds in lpcxpresso have never crossed 15kb flash till date...:(. I've used FatFs file system, IEEE 802.15.4 stack, Graphics library for TFT touchscreen LCD and several other features in my application.

128kb debug limit is quite a lot even in professional programming (atleast for the programmer within me...). Infact i consider it as a completely free full version IDE for students and non-professionals.:)

Quote:
How can I change Clock Configuration(Main PLL, USB PLL, CLKSRCSEL etc.) through a user interface like uVision by clicking on Configuration Wizard of "System_LPC17xx.c" file.

I'm afraid there is no such thing in LPCXpresso. Perhaps we could ask code red and NxP to add that feature in future versions.
I have some other wish list too...like...adding C++ support in lpcxpresso with limited debug support...such as 128kb...which will be very restrictive....;) :D

Best Regards
Vasanth

Re: LPCXpresso Limitations

lpcware — Thu, 16 Jun 2016 00:39:29 GMT

Content originally posted in LPCWare by Rob65 on Sat Jan 07 16:53:30 MST 2012

Quote: vasanth

Quote:
How can I change Clock Configuration(Main PLL, USB PLL, CLKSRCSEL etc.) through a user interface like uVision by clicking on Configuration Wizard of "System_LPC17xx.c" file.

This is not something I would do in compile time (or even before).
I like to do this at run time: let my system run at a low clock frequency and only increase the clock when it is needed. As an example: my system runs at 4 MHz (lpc1754, internal RC oscillator) and I only switch to the crystal when I need the accuracy for USB and I only switch to higher frequencies when I need the speed for audio compression or high speed SD access.

I wrote a small driver that you can use to program the PLL and clock selection fairly easy. Have a look at the clocking.c file and the clocking.h file in the drivers section of my Platform1754 code.

The interface is simple.
LPC_UseOscillator(LPC_MAIN_OSC) will switch the CPU clock to the main crystal oscillator and LPC_SetPLL0(50000000) sets the PLL to 50 MHz.
If you need USB, just call LPC_EnablePLL1() and LPC_DisablePLL1() to disable it again.

I have included PLL settings for both the internal RC oscillator and the crystal oscillator (with a 12 MHZ crystal) for 10 - 100 MHz in 10 MHz steps.

I am still working on the C++ support. It works but the code size is just too big. C++ is used in a number of embedded systems, the Embedded C++ variant needs only smaller C++ base libraries but I don't have a proper GCC-ARM port for this (yet). C++ compilation/debugging works in LPCXpresso (this is all default ARMGCC functionality) but you will not be able to just generate a C++ project using the project wizard.

If you need C++ support I strongly suggest to buy a Code Red license. This gives you the wizard to create an LPCXpresso C++ project and 90 days of support with it.

Regards,[INDENT]Rob
[/INDENT]

Re: LPCXpresso Limitations

lpcware — Thu, 16 Jun 2016 00:39:30 GMT

Content originally posted in LPCWare by vasanth on Wed Jan 11 07:41:21 MST 2012

Quote:
This is not something I would do in compile time (or even before).
I like to do this at run time: let my system run at a low clock frequency and only increase the clock when it is needed.

That is a good way to optimize power consumption.

But what is the time taken for a changeover? Because we know there is PLL locking. If the changeover takes significant time between conversions, what is the optimum way to use this feature?

By the way, LPC1114/302 and LPC1313/01 has a feature called power profile API's built-in ROM exactly for this purpose.:)

Re: LPCXpresso Limitations

lpcware — Thu, 16 Jun 2016 00:39:30 GMT

Content originally posted in LPCWare by Rob65 on Wed Jan 11 13:31:09 MST 2012

Quote: vasanth
But what is the time taken for a changeover? Because we know there is PLL locking. If the changeover takes significant time between conversions, what is the optimum way to use this feature?

I have not really thought about this yet.
The LPC17xx user manual tells me this about PLL locking:

Quote:
The PLOCK0 bit in the PLL0STAT register reflects the lock status of PLL0. When PLL0 is
enabled, or parameters are changed, PLL0 requires some time to establish lock under the
new conditions. PLOCK0 can be monitored to determine when PLL0 may be connected
for use. The value of PLOCK0 may not be stable when the PLL reference frequency
(FREF, the frequency of REFCLK, which is equal to the PLL input frequency divided by the
pre-divider value) is less than 100 kHz or greater than 20 MHz. In these cases, the PLL
may be assumed to be stable after a start-up time has passed. This time is 500 μs when
FREF is greater than 400 kHz and 200 / FREF seconds when FREF is less than 400 kHz

Here FREF is the reference frequency, PLL clock in / N. in my driver FREF is always greater than 400 kHz so I guess that means locking the PLL takes (less than) 500 μs.
That's a real guess though ... I have just scanned across some pages to see what I could find regarding the PLL lock timing.

The quickest way to switch clocks is to just reprogram the CPU clock divider (the one after the PLL). That gives the faster response when needing a higher frequency.
Still - both ways of increasing/reducing the clock mean that you have to reprogram all timing dependent things (e.g. uart baudrate, SPI/I2C clock, Systick) and that also takes some extra time.

Finding an optimum way to use this feature is a good question.
I don't know (yet) :eek:

Most users will just determine different use cases in the application and adjust the clock to fit the needs for these cases.

Just as an example:

[LIST]
[*]* user interface handling only:
Slow clock, just fast enough to keep the user interface respond quick enough
[*]* Logging data to SD card:
Keep the clock high enough to prevent filling up the buffers (only possible when the speed of the data to log is known).
[*]* Attaching to USB to read the SD card and program parameters:
fast is good. The device is now powered over USB so no need to save batteries.
[/LIST]

Rob