LPCOpen - what am I missing?

[lpcware]

Content originally posted in LPCWare by DodigI on Wed Nov 06 07:16:43 MST 2013
Dear community & NXP,
I'm trying to use LPCOpen 2 .0 but it seems I'm missing something.
Please be kind and answer a few questions.

I would like to use LPCOpen with a custom board built around a LPC1114 MCU.

1) I presume LPC11XX family is not supported? It's not listed here (i.e. no download link)
http://www.lpcware.com/content/nxpfile/lpcopen-platform
and when I change sys_config.h to #define CHIP_LPC110X I get an error that file named "cmsis_110x.h" is missing which cannot be found in the LPCOpen package. 

2) Is there any documentation on setting up the library? I have found the Keil getting started guide but it is, with all respect, useless. Why are things like sys_config.h not mentioned?

3) What is the purpose of a library built for boards like LPCXpresso and similar. I want to use the library with professional tools like Keil MDK on custom boards like 99% of other developers.

I'm looking forward to your helpful answer.

Best regards,
Developer

[lpcware]

Content originally posted in LPCWare by funkyguy4000 on Sun Dec 21 20:24:39 MST 2014
While this post is helpful, the process is still excruciatingly tedious. 

NXP people, are there any plans at all to help with this process?  I'm tempted to just abandon everything NXP and move back to freescale. 

[lpcware]

Content originally posted in LPCWare by Dill on Wed Oct 01 08:23:54 MST 2014
>  Replace files in config_11uxx directory with files from the attachment in the config_110x.

from  config_110x/cmsis110x.h: "Applies to LPC1102 and LPC1104 devices."

Can you confirm, that despite this comment cmsis110x.h is the correct header for LPC1114?

Also could you please help me in my confusion about the lpc11xx product family:

From the website: http://www.nxp.com/products/microcontrollers/cortex_m0_m0/lpc1100/

The LPC1100 series includes:
LPC1100: low power, low pincount
LPC11U00: USB device
LPC11C00: CAN
LPC11D00: segment LCD display
LPC11A00 : analog
LPC1100LV: dual supply voltage

is the LPC1100 subseries the series LPC1114 belongs to?

Thanks for your help.

[lpcware]

Content originally posted in LPCWare by wellsk on Tue Nov 19 12:24:59 MST 2013

---

Quote:
All LPCOPEN GPIO functions work with that particular macro, but IOCON function for LPC11C24 expects CHIP_IOCON_PIO_T type, i.e. IOCON_PIO0_7. Now I need to have two macros to control an LED?

I see that IOCON functions for i.e. LPC11U can work with LED 0,7, but LPC11C24 lib cannot!

---

The LPC11xx family consists of 6+ individual device families. The IOCON block on some of these are different than others.
The LPC11Cxx IOCON muxing is not aligned with GPIO port/pin numbers so the enumeration is needed here. A single abstracted interface could be made to work with it, but the cost would be a (relatively small) index lookup table required to map port/pin mapping to the non-aligned registers for some of the parts.

For example, the 11uxx is ordered like this:
Portt 0, pin 0 - offset 0x00
Portt 0, pin 1 - offset 0x04
Portt 0, pin 2 - offset 0x08
etc.

But the LPC11Cxx is ordered like this:
Portt 2, pin 6 - offset 0x00
Unused - offset 0x04
Portt 2, pin 0 - offset 0x08
Portt 0, pin 0 - offset 0x0C
etc.

---

Quote:
Please provide an explanation why is this so user unfriendly or propose a workaround. It all comes to that fast that if I change the IC simple IOCON functions change prototypes?!

---

You are probably referring to these functions for the 11cxx and the 11uxx, which take int account the different IOCON organization and is meant to be 'size sensitive code'.

For the 11Uxx:

void Chip_IOCON_PinMuxSet(LPC_IOCON_T *pIOCON, uint8_t port, uint8_t pin, uint32_t modefunc);

For the 11Cxx:

STATIC INLINE void Chip_IOCON_PinMuxSet(LPC_IOCON_T *pIOCON, CHIP_IOCON_PIO_T pin, uint32_t modefunc)

I can only propose a different solution for you atm if you can live with the slightly larger code size.
A 'version' of the function with the same API can be created for the 11Cxx version, but it requires a lookup table something like this:

void Chip_IOCON_PinMuxSetCompatibleLPC_IOCON_T *pIOCON, uint8_t port, uint8_t pin, uint32_t modefunc)
{
    /* This list can get complex based on specific devices */
    const uint16_t portPinToEnumMap[] = {
        (uint16_t) IOCON_PIO0_0,
        (uint16_t) IOCON_PIO0_1,
        (uint16_t) IOCON_PIO0_2,
        (uint16_t) IOCON_PIO0_3,
        .... etx.....
    };

    /* Only works for ports with 12 pins per port */
    Chip_IOCON_PinMuxSet(LPC_IOCON_T *pIOCON, (xxx) portPinToEnumMap[port*12+pin], modefunc)_;
}

You can rename those functions so they API is the same between both families...

[lpcware]

Content originally posted in LPCWare by wellsk on Tue Nov 19 11:44:00 MST 2013
I'll try to answer these points - the files that you are missing are attached to this email.
You've probably figured this out already, but the approach I would probably use is at the bottom of  this post.

---

Quote:
1) I presume LPC11XX family is not supported? It's not listed here (i.e. no download link)
http://www.lpcware.com/content/nxpfile/lpcopen-platform
and when I change sys_config.h to #define CHIP_LPC110X I get an error that file named "cmsis_110x.h" is missing which cannot be found in the LPCOpen package.

---

All existing LPC11XX devices are supported in LPCOpen, but the releases are targeted for a specific product line - so the LPC11U14 release contains files specific to the LPC11U14 only. Because of that, the CMSIS file you need isn't available in that package. But come to think of it, it isn;t available publicly at all anywhere due to the way these packages are released.
The missing files you need have been attached in this post
You should be able to paste the 2 files into the existing releases 'config_11*' directory and it should allow you to move forward with the device you are using for Keil and IAR. For LPCXpresso, yuo will need to locate the files in the workspace and add them to the chip projects 'inc' directory. I think going forward we will just add all the files for Keil and IAR builds so they are available publicly.

---

Quote:
2) Is there any documentation on setting up the library? I have found the Keil getting started guide but it is, with all respect, useless. Why are things like sys_config.h not mentioned?

---

Not yet for v2.xx and the old v1.xx documentation is significantly different to not be useful. If you are going to use the examples released with LPCOpen, you need to build the chip library and board library and then the individual examples will build. You may need to tweak IOCON settings in the board library code and individual examples to make the examples work for your board. Maybe the sequence at the bottom of this post will help?

---

Quote:
3) What is the purpose of a library built for boards like LPCXpresso and similar. I want to use the library with professional tools like Keil MDK on custom boards like 99% of other developers.

---

You don't really need to use the board library. The chip library is standalone, but needs to know about several items that are 'board specific' - look in the chip.h for the things you need to define that are needed by the chip library at link time in the CHIP_11XX_DRIVER_OPTIONS section.

Concerning LPCXpresso/Keil/IAR, the projects to build the libraries are available for all of those toolchains. Individual releases are available in 'Keil/IAR' versions and a separate 'LPCXpresso' version. The LPCXpresso boards and LPCXpresso toolchains are different things and Keil/IAR toolchains support for LPCXpresso boards just fine.

I would use this approach based on the existing LPCOpen v2.xx release for the LPCXpresso LPC11U14 board.
1) Replace files in config_11uxx directory with files from the attachment in the config_110x. Build the library using the existing Kiel project (no path changes needed).

2) If you want to keep the board layer, you will probably need to at least review the code for clocking and IOCON setup and change it if necessary (ie, PLL setup is for an external crystal and IOCON pinmuxing is setup for LPCXpresso board). If you want to use the Board_* functions in your code, you will need to setup LED code, Button/joystick functions, and Board_Init(). This layer also provides the configuration and routing for DEBUGOUT (basically printf), DEBUGIN, and DEBUGSTR functions and the mapped UART if used.

If you don't want to use the board layer, but want to skip pinmuxing, you can use the 'chip specific' setup to setup the PLL based on the internal oscillator by calling Chip_SystemInit(). This avoids doing anything board specific.

3) In the examples, if you retained the board layer/library, the Board_* functions should work without any changes in the example code, so blinky will blink something, etc. If you removed the board layer, you will need to remove the Board_* functions from the examples and replace '#include "board.h" with '#include "chip.h". Some of the examples (ie, ethernet, sdmmc, audio, etc. really require a board layer).

4) In your example project (if creating a new one), add the startup code specific to your toolchain, optionally the sysinit.c file, and the example code. If you have removed the board layer,  you may need to make some changes. The Startup code always calls SystemInit() prior to your application. SystemInit() is in sysinit.c which in turn calls Board_SystemInit() in the board library or Chip_SystemInit() in the chip library.based on the NO_BOARD_LIB definition. Define NO_BOARD_LIB to call Chip_SystemInit() and undefine it to call Board_SystemInit() - or just comment out the call to SystemInit() in the startup code and it will directly call your application and you can call Chip_SystemInit() as the first thing in your application....

4) For the example, you should do the minimum....

int main(void)
{
    /* If you removed sysinit.c and removed the startup code call to SystemInit(), call either Chip_SystemInit() or Board_SystemInit() here. Or do nothing and live with the default system clocks and setup on startup */
    ;

    /* Call SystemCoreClockUpdate() to update the SystemCoreClock variable */
    SystemCoreClockUpdate();

    /* Call Board_Init() if using the board library */
    Board_Init();

    /* Your application can start here.... */
    FillHotTubWithWater();

   /* ... */

    return 1;
}

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Mon Nov 18 12:53:02 MST 2013

---

Quote: DodigI
Dear community & NXP,
3) ... I want to use the library with professional tools like Keil MDK on custom boards like 99% of other developers.
Developer

---

If you haven't got any answer, yet, your assumption of point 3) may be wrong, especially the number 99  :p

I can't speak for NXP nor can I speak for the community. I don't use LPCOpen.
However, from my own activities (LPC2106, LPC213x, LPC17xx, LPC111x, LPC800) I know how difficult it can be to create a portable interface - especially for the GPIOs. LPC1100 has a quite different concept of accessing GPIOs compared to LPC800 or LPC2000.
LPC800 and LPC2000 are very different, too. So I guess that macro doubling is (finally) the result of such differences.

I seem to be an old-fashioned developer. Instead of having an library do an abstraction of the microcontroller for me I read the manuals, try to figure out the differences of the uCs and then I try to take advantage of the differences. For example, I do like the USART of LPC800 much more than the other UARTs because NXP finally kicked that '550 standard UART' (BS) with its highly non-intuitive initialization and interrupt handling.

I make heavy use of library code, but that code is rather hardware-independend - portable by definition.

tldr;

If you need to unleash full potential of your microcontroller, you have to do the critical stuff on your own.

[lpcware]

Content originally posted in LPCWare by DodigI on Wed Nov 13 03:08:29 MST 2013
Any support from NXP would be more than welcomed.

Best regards.

[lpcware]

Content originally posted in LPCWare by DodigI on Thu Nov 07 07:36:20 MST 2013
And one more question, lets say I want to work with an LED connected to P0.7, I would have this macro
#define LED 0,7 somewhere in target.h file.

I want to be able to use that single macro to configure IOCON, set direction and finally change pin value.

All LPCOPEN GPIO functions work with that particular macro, but IOCON function for LPC11C24 expects CHIP_IOCON_PIO_T type, i.e. IOCON_PIO0_7. Now I need to have two macros to control an LED?

I see that IOCON functions for i.e. LPC11U can work with LED 0,7, but LPC11C24 lib cannot! 

Please provide an explanation why is this so user unfriendly or propose a workaround. It all comes to that fast that if I change the IC simple IOCON functions change prototypes?!

Thank you!