LPC MicrocontrollersのトピックRe: LPCOpen V3.00 Feedback

LPCOpen V3.00 Feedback

lpcware — Wed, 15 Jun 2016 20:24:40 GMT

Content originally posted in LPCWare by EarlBryner on Fri Dec 19 11:23:00 MST 2014
Feedback on new V3.00 structure.
Please use the following guidelines to avoid topic fragmentation:
[list]
[*]If an existing subtopic exists, please use the 'Edit' button rather than 'Reply'. Reply will start a new box which does not get attached to the original sub-topic.
[*]When replying to subtopics it would be helpful to include your name to provide context on your perspective.
[/list]

Re: LPCOpen V3.00 Feedback

lpcware — Wed, 15 Jun 2016 20:24:40 GMT

Content originally posted in LPCWare by EarlBryner on Fri Dec 19 11:59:00 MST 2014
The new paths are indeed shorter, but can we shorten them further (i.e change the project dir lpcxpresso to lpx)?

Reply (Earl Bryner):
This is a touchy subject. The current paths were developed as a compromise between competing desires to shorten the folder names and lengthening them to be more descriptive. The current proposal is the resulting compromise between those interest.

Re: LPCOpen V3.00 Feedback

lpcware — Wed, 15 Jun 2016 20:24:41 GMT

Content originally posted in LPCWare by EarlBryner on Fri Dec 19 12:44:00 MST 2014
Can the example and project files be grouped together to aid in distribution?

Reply (Earl Bryner):
The current proposal (though this wasn't obvious in the sample provided) has separate folders for projects and source because the intention is that when a MCU family has multiple boards (virtually every MCU we have fits into this case), there will be a unique project directory for each board. For example in the provided sample if we were to include support for the original CSP board we would have included a prj_lpcxpresso_54102_csp directory which would have had iar, keil and lpcxpresso sub directories similar to the current prj_lpcxpresso_54102 directory. Additionally in order to support vertical markets it is very desirable to have a clear distinction between source code and project files since they are typically only interested in the source code (because they maintain their own project files).

Re: LPCOpen V3.00 Feedback

lpcware — Wed, 15 Jun 2016 20:24:42 GMT

Content originally posted in LPCWare by EarlBryner on Fri Dec 19 15:47:00 MST 2014
Many new users struggle with the requirement to build the library projects in order to link the examples. Could the projects be changed to refer to the library files directly?

Reply (Earl Bryner)
This is understandable however the problem with making every project reference the lib files (like chip and board) directly is a maintenance issue. If / when we need to add a new module to a library, we would then have to modify 30+ projects to include the new link which becomes a lot of extra work and introduces the possibility of missing one etc. To help mitigate this problem, the LPCXpresso projects automatically have a dependency built in which forces the library to be built prior to linking. I am not aware of a mechanism to enforce this in Keil or IAR. There may be other creative ways to solve this problem so we are open to other suggestions.

Re: LPCOpen V3.00 Feedback

lpcware — Wed, 15 Jun 2016 20:24:42 GMT

Content originally posted in LPCWare by EarlBryner on Fri Dec 19 15:57:09 MST 2014
Most examples share common code (such as startup files) which makes it difficult to customize for only a specific example. Can the examples be changed to have their own copy instead of sharing?

Reply (Earl Bryner)
Our experience (please correct me if I am wrong) has been that the desire to customize startup code is the exception rather than the rule. Sharing the startup code across examples allows us to easily correct bugs / add features across all the examples rather than having to replicate the fix N times for each example. In the rare case that an example needs a custom startup file, it should be relatively easy to copy the shared one to the local project source directory and reference it from the project.