SDK examples should use and respect Config Tools!

[danielholala]

Hi,

I'm using MCUXpresso 11.6.1 and SDK 12.2 to develop firmware for LPC5528.

MCUXpresso IDE includes "Config Tools", a suite of evaluation and configuration tools is intended to facilitate configuration and use of NXP microcontrollers.

I understand that using the Config Tools is the suggested way to configure pins, clocks and peripherals of NXP MCUs.

Therefore I wonder why many of the SDK examples do not use Config Tools?

For example, the example project "lpadc_interrupt" uses Clocks Tool to configure the main clock only.

However, the USART clock is configured manually without it (relevant code is in main()  instead of clock_config.c).

Still worse, the ADC (which is the gist of this example) is configured manually and not through Peripheral Tools. Peripheral tools is completely disabled in this project. If you enable it, it has not idea that ADC0 is used and how it is configured in the example.

This is a particularly bad decision as 

a) the ADC of this MCU is a beast and has a pile of different configuration options,

b) Peripheral Tools does a nice job visualizing and configuring these options.

I suggest that SDK examples make good use of the Config Tools in the future.

Cheers
Daniel

[danielholala]

Nag,

just getting started with LPC5536-EVK, I figured that even with SDK2.14, the examples still do not employ Config Tools when IMHO they should.

For example, the lpadc_interrupt example:

https://github.com/nxp-mcuxpresso/mcux-sdk-examples/tree/main/lpcxpresso55s36/driver_examples/lpadc/...

does not configure the ADC using Peripherals Tools. 🤷‍

[fjrg76]

NXP has never been distinguished for its consistency. When you look at APIs from ST for whichever microcontroller you want from any year, you can see a pattern and consistency, no matter whether it's a Cortex M0 or M7; NXP is another tale.

For example, the NXP's APIs for the LPC812 and LPC824 uC were obviously written by different programmers doing each one what they thought it was correct in their respective time. I mean, LPC824 and LPC812 belong to the same family, however the API's are different; even worst, LPC824's API is a reduced and incomplete one in regards to LPC812.

You can name any API from NXP and you'll find that its only consistency is its inconsistency

NXP don't get angry at me, sadly I'm your fan.

[danielholala]

I appreciate your comment, @fjrg76 !

I did not know that the API of ST devices is more consistent. That being said, NXP mcus have better features (e.g., SCTimer) in my opinion. Also, I prefer the NXP community over ST community.  ;-]

Daniel

[danielholala]

@jackking ,

I agree. Further, if more SDK examples supported Config Tools, bugs would be spotted internally by NXP prior to a release. See for example this bug about incomplete ADC configuration via Peripherals Tool.

Thanks for commenting.
Daniel

[jackking]

I agree.  But to give some (unhelpful) context, the SDK and examples were provided before the Config Tools supported most of the peripheral configuration capabilities.  It started out as a tool that could only be used to configure the pins if I remember correctly (at least for IMXRT).

Ideally, the SDK examples should be maintained to keep up with the current capabilities, but I assume they were written before the tools and generically to support multiple IDEs.

Since I started using the SDK before the Config Tools did much, I had to learn the hard way to configure them by looking at the examples and the source code.  It took me awhile, but it allowed me to skip the Config Tools completely and configure them purely in my own source code.  I found that even with the Config Tools, there were certain things that happened "magically", only to find they were handled elsewhere in the source code (and in some cases override the Config Tool based settings).