Common Code Lookup

[lpcware]

Content originally posted in LPCWare by caprock on Fri Apr 27 14:43:10 MST 2012
All,
The Code Red/Eclipse help file shows a feature called [B]Common Code Lookup[/B] which seems to imply the ability to include specific code files into the build. So far, I have been unable to make this feature work, most likely problem is understanding just how to configure this feature.

A search for this feature on this forum and several others fails to find any detailed instructions.

Suppose that I have three projects that contain one or more of the same files, and are based on different target MPUs. Currently I am maintaining three source copies rather than one master source and two referencing this one.

Is there any detailed information available for this feature or a sample application?

Thanks

[lpcware]

Content originally posted in LPCWare by caprock on Thu May 10 08:26:50 MST 2012
Thank you for the reboot.

I am ashamed that I have spent so much time on an issue that should have been evident to anyone who has ever used a linker! :o

I had failed to evaluate the order of access, focusing only on the single fact that the low-level GPIO was serviced only by the CDL.

So you really can teach an old dog new tricks!

Thanks to all for your consideration.

[lpcware]

Content originally posted in LPCWare by atomicdog on Wed May 09 21:01:03 MST 2012

---

Quote:

[B][SIZE=3]The question is: When does the order of the Libraries (-l) have a significance?[/SIZE][/B]

---

I believe the 'dependent' library needs to go first on the command line. So if libFoo.a references symbols in libBar.a then LibFoo.a needs to be first.

[lpcware]

Content originally posted in LPCWare by caprock on Wed May 09 15:26:50 MST 2012
Ok, once again I am confused.

It appears that when linking 2 or more libraries, the order of the Libraries (-l) is important. Going back to the previous example based on [B]lpcUSBlib[/B] I created an executable project as Dummy with Dummy.c containing main().

[B][SIZE=3]The question is: When does the order of the Libraries (-l) have a significance?[/SIZE][/B]

The project is built as:
BSP - active: LPCXpressoBase_RevB

CDL - active: CMSISv2p00_LPC17xx
              LPC17xxLib


The project Dummy is referencing two Libraries: BSP and CDL. If I compile with BASIC=1, all linkages are resolved: BSP/LEDs_Init(), GPIO_SetValue() and GPIO_ClearValue(). In this case the order of the Libraries (-l) does not seem to matter.

/*
 * Dummy.c
 *
 *  Created on: May 8, 2012
 *      Author: Rick
 */

#defineBASIC1

#if BASIC
#include "lpc17xx_gpio.h"// use for direct gpio
void LEDs_Init(void);
#else
#include "MyDummy_Project.h"
#endif

uint32_t MyLeds;// 32b store test for lpc_types.h


int main(void) {
#if BASIC
LEDs_Init();
MyLeds = (1<<22);// try to use uint32_t

while (1) {
GPIO_SetValue(0,(1<<22));
GPIO_ClearValue(0,(1<<22));
}
#else
LED_INIT();
MyLeds = (1<<22);// try to use uint32_t

while (1) {
LED_BIT_ON();
LED_BIT_OFF();
}
#endif
}

But when the project is set to BASIC=0 several subtle changes seem required:
First is the inclusion of 'LPC17xx.h' vs 'LPC17xx_gpio.h', but more importantly, the [B]order[/B]of the Libraries (-l) seems relevant, with BSP then CDL. If the order is reversed (CDL,BSP), all of the GPIO_ referenced procedures in both BSP and Dummy are [B][I]undefined[/I][/B].

#ifndef DUMMY_PROJECT_H_
#define DUMMY_PROJECT_H_

/*
CHANGE LOG

 5/9/12RLDCreated for library testing
*/


/**
 *LPC17xx Cortex M3
 *
 *Includes basic support for the LPCXpresso board LED
 * - LPC17xx.h
 */
#ifdef__LPC17XX__
#include "LPC17xx.h"
#endif // lpc17xx


/**********************************************
Common - BSP definitions
 ********************************************/

void LEDs_SetAllLEDs(uint32_t LEDMask);
void LEDs_Init(void);
 #defineLEDMASK_XPRESSO0x01 // LEDS_LED1

 // Local LED macros
 #define LED_INIT()  LEDs_Init();
 #define LED_BIT_ON() LEDs_SetAllLEDs(LEDMASK_XPRESSO);
 #define LED_BIT_OFF() LEDs_SetAllLEDs(0);

#endif /* DUMMY_PROJECT_H_ */

[lpcware]

Content originally posted in LPCWare by atomicdog on Tue May 08 00:24:10 MST 2012

---

Quote: caprock
...I do notice that the MCU property does not change with LPC11Uxx_LPCXpressoRevB, but I thought that perhaps the included CMSIS was overriding the property. Or are these LPC11u14, LPC11Uxx and the LPC17xx similar/compatible cores and so this common MPU as LPC1768 is the proper setting?

---

I forget about this...

---

Quote: caprock

Seems this may be the case, so a question here: where can I find a table of compatible core families?

---

You could compile for the LPC11 (cortex-m0) since the LPC17 (cortex-m3) supports all the M0 instructions plus some. But compiling for LPC1768 could screw up the LPC11 binary.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri May 04 02:55:14 MST 2012
I can't comment on what NXP have done with their nxpUSBlib as I haven't really looked at it.

However if you want to setup a library project that supports multiple MCUs/architectures this is fairly straightforward.

There are a few notes in the following FAQ...

http://support.code-red-tech.com/CodeRedWiki/StaticLibraryMCU

and you can see an example implementation in the CMSIS DSPLIB SRC project that you can find in the top level of the examples directory....

[FONT=Courier New][SIZE=2][I]<install_dir>[/I]\lpcxpresso\Examples\CMSIS_DSPLIB\CMSISv2p10_DSPLIB_SRC.zip[/SIZE][/FONT]

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by larryvc on Thu May 03 11:38:00 MST 2012

---

Quote: caprock

As an aside, I have a comment about the Code Red tools: [B]simply wonderful![/B] I have worked with many different tools in the AVR environment and those tools can't stand up to the offerings available to the LPCXpresso! :)

---

Careful caprock,  I  totally agree with you, but fear coderedsupport will get a swelled head with comments like "simply wonderful!".;)

By the way, this thread is one that I will be following very closely as I would like to be able to do the same.  Good luck.

[lpcware]

Content originally posted in LPCWare by caprock on Thu May 03 08:29:17 MST 2012
@researchinmotion: Thanks for the suggestion. At the moment I am totally confused as to how to create a library product that can be used for different classes of MPU's. At this  time, the intention is to target devices that I have and can test.

I'm trying to port an RTOS that has been successful in the AVR and Zilog EZ8 environments, and has been ported to theses LPC MUC's earlier. What I am trying to accomplish is a build where my library has only one source location, thus was looking at Common Source Lookup or some variation of alias linking. At this time the same source is spread to 3 different builds.

But I am confused about your comment re: the MCU selection. When using something like nxpUSBlib as an example, doesn't this accomplish this? I do notice that the MCU property does not change with LPC11Uxx_LPCXpressoRevB, but I thought that perhaps the included CMSIS was overriding the property. Or are these LPC11u14, LPC11Uxx and the LPC17xx similar/compatible cores and so this common MPU as LPC1768 is the proper setting?

Seems this may be the case, so a question here: where can I find a table of compatible core families?
:confused:

As an aside, I have a comment about the Code Red tools: [B]simply wonderful![/B] I have worked with many different tools in the AVR environment and those tools can't stand up to the offerings available to the LPCXpresso! :)

[lpcware]

Content originally posted in LPCWare by researchinnovation on Wed May 02 22:10:28 MST 2012
@Caprock....!!!
Hi..!!
For LPC11xx, why don't you change the location of workspace or create new workspace and let be the default setting as it is, and just change the MCU setting.

Hope this help.


Thanks & Regards.....!!!:)

[lpcware]

Content originally posted in LPCWare by caprock on Wed May 02 13:08:25 MST 2012
Tried the exclude properties - still makes all configurations.

But noticed something odd/different from the nxpUSBlib: the generated branch code for my second CDT/LPC11xx which also has the makefile, is grayed out for makefile, objects.mk, sources.mk.

Clearly the make is not correct. Building the LPC17xx is ok, but not the LPC11xx. And this is after the exclude was confirmed.

Deleted the project once again and re-built - this time used standard C project, Static library, and setting all build file properties for Exclude - this time all is ok.

I'm going to save this off, then delete and retry with Red Suite Project.
This fails on the build with several java exception errors when adding the path includes for selected builds and one of the builds was mixed.

Did a File/Restart and builds were ok.
Still unsure of the rules & procedures & order but closer.

Thanks for the assistance!

[lpcware]

Content originally posted in LPCWare by atomicdog on Tue May 01 23:56:46 MST 2012
What about the [All configurations] configuration setting? Does it have stuff in it that should only be specific to one config?

You can go to the properties of (right click) folders and files to go to settings for that file/folder and exclude it from that specific build configuration.

[lpcware]

Content originally posted in LPCWare by caprock on Tue May 01 17:35:04 MST 2012
atomicdog, I studied the nxpUSBlib project and have attempted to produce my own project Red Suite C Project for the CDT branch as a starter.

1) Starting with a clean workspace I created the CDT project branch, as Red Suite C Project, Static Library and no CMSIS, inc or src; Configuration: LPC17xx, and set the Resource:

Resource Filters
FilterExclude all
AppliesFiles
All children

Name matches *.s

2) Set Build Steps for prebuild & post build strings as in the nxpUSBlib

3) Set the include (-I) for the two paths

Build the first configuration OK

But when I do the same steps to add another configuration as LPC11xx, this targeted build also tries the LPC17xx and errors occur as [B]No such file or directory[/B]. 

When I examine the makefile, I can see that sources from [B]Both[/B] are active. Obviously, some step is not correct.

I studied the C/C++ Indexer but seems to be Ok.

Perhaps the CDT label itself is not a project, but a Virtual Folder? Well I can't seem to create it from File/New.

Can someone please steer me to a template or procedure to create the correct project settings (as per nxpUSBlib/CDT) ?

Thanks for all the help.

[lpcware]

Content originally posted in LPCWare by caprock on Sun Apr 29 11:59:47 MST 2012
Excellent idea - I will.

[lpcware]

Content originally posted in LPCWare by atomicdog on Sun Apr 29 11:52:45 MST 2012
Checking out the nxpUSBlib should give you some good ideas.
The library project allows targeting multiple MPU's and different dev boards.

[lpcware]

Content originally posted in LPCWare by caprock on Sun Apr 29 10:30:31 MST 2012
atomicdog & CodeRedSupport for the ideas, but perhaps the files are created incorrectly to begin with.

Yes, the correct terminology is [B]Common Source Lookup[/B], not Common Code Lookup.


I have created V4 Static Libraries, but to date, are specific to an MPU class; 11xx,13xx,17xx. Also tried to create the linked resource but can't seem to link, or compile with an external 'main' file.

The bottom line is that I believe the CodeRed/Eclipse platform is capable of the following variations, but I can't seem to simplify the process.


What I am trying to accomplish is:
Y = Target MPU class (LPC11xx, LPC13xx, LPC17xx)

sourceLib + targetMpu_1Yxx ==> libFoo_1Yxx.a

In this case, the sourceLib is common to all builds, so results in three different libraries.


Then I want to combine the libFoo_1Yxx to create executable demonstration files that can be targeted to several different development boards; ie: LPCXpresso (3), RDB1768, MBED.

demoSource + targetSrc + targetMpu_1Yxx + devBoard + libFoo_1Yxx.a ==> demo_1Yxx.axf

Where targetSrc are 0 or more supporting source/inc for this specific MPU

This currently expands to five different executables.

With this requirement, what is the best approach to create/build? :confused:

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Sat Apr 28 01:52:12 MST 2012
I do not know of anything called Common Code Lookup. Perhaps you are getting it confused with Common Source Lookup, which a feature of the debugger to help it locate source files while you are debugging.

To share sources, you have these options.
1. As atomicdog mentions, you can create a Library project. However, this is really 'object file and header file' sharing. You share header files and object files built from your source code
2. Use Linked folders. Using Linked Folders, you can create a directory that is actually a link to a folder in another project, or even a folder elsewhere in your file system. For more information, in the help system, search for "Linked Resources"

[lpcware]

Content originally posted in LPCWare by atomicdog on Fri Apr 27 17:44:14 MST 2012
From your description I think creating a library project is the best solution. In the library project you can then setup build configurations for the different MPU's.