Problems with example code supplied with LPCXpresso

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Jul 14 02:56:45 MST 2011
A lot of the new LPCXpresso users will start with the example code that is supplied with their board/IDE environment.

Code Red does a good job by including lots of examples with the LPCXpresso environment, but things can be even better ...
Code Red collects the examples and delivers them as is, most of the examples are written by NXP and delivered as is.

To start with: these are [B]examples[/B] to show how a certain peripheral or feature of the lpc1xxx can be used. So we can not expect the examples to handle all possible situations for a peripheral.
One thing that strikes me however is that there seems to be no standard in the type of examples that is delivered.
For the lpx11xx there is a "timedwakeup" example showing how to use, and wake up from, deep sleep mode - but that example is not available for the lpc13xx or the 17xx variants.

Strange ... especially when I look at the header of the main.c file with this example:

/****************************************************************************
 *   $Id:: [B][COLOR=Red]invokeisp_main.c[/COLOR][/B] 4816 2010-09-07 17:24:10Z nxp21346                        $
 *   Project: NXP LPC11xx timedwakeup example
 *
 *   Description:
 *     Code sample demonstrating entry into sleep and deep sleep
 *     power save modes.
 *
 ****************************************************************************
 * Software that is described herein is for illustrative purposes only
 * which provides customers with programming information regarding the
 * products. This software is supplied "AS IS" without any warranties.
 * NXP Semiconductors assumes no responsibility or liability for the
 * use of the software, conveys no license or title under any patent,
 * copyright, or mask work right to the product. NXP Semiconductors
 * reserves the right to make changes in the software without
 * notification. NXP Semiconductors also make no representation or
 * warranty that such application will be suitable for the specified
 * use without further testing or modification.
****************************************************************************/

//#undef DEBUG
//#define ENABLE_CLKOUT

// Uncomment below to flash an LED. The LED consumes current.
#define FLASH_LED

#define [COLOR=Red][B]LPCXPRESSO_LPC1343_BOARD[/B][/COLOR]

Whow ... there I see a clear mention of LPC1343 and yet I could not find this example in the lpc13xx examples delivered.
Also the filename, which should be generated by the change management system used, differs from the filename in the example tree.

Also, when I read the readme that comes with this example there is some strange text in there:

---

Quote:
To wake the part up, the watchdog oscillator is set to the slowest
speed (near 8 kHz) and [B][COLOR=Red]used to drive the main CPU clock in deep sleep
mode[/COLOR][/B]. This allows the lowest possible current consumption with on-chip
self-wakeup.

---

I started wondering how one would use the watchdog to drive the main clock in deep sleep mode - this is the exact opposite of what I expect a watchdog to do.:confused:
I guess they mean that the WD is used to recover from deep sleep mode

I do accept that I find some funny things like lpc1343 being mentioned in an lpc11xx example because that example is used for both parts but errors like the one in the readme drive me nuts ...

It would be a good idea if we could form a team of independent reviewers/code cleaners to get strange things like this fixed.
If Code Red/NXP threw in a couple of LPCXpresso boards and RedProbe+ devices we should be able to choose from a wide range of LPCXpresso users who are willing to fix these problems and provide a set of common examples that can be used for the different LPC variants (I would be one of them :D).

I think some of the goals of this team should be:

[LIST]
[*]collect/create/fix a set of simple examples that show basic features.
[*]use common defines for bit-fields being used (e.g. use LPC_SYSCON->CLKOUTCLKSEL = MAIN_CLOCK; instead of LPC_SYSCON->CLKOUTCLKSEL = 3; )
[*]provide comments and instructions with each example explaining the details of the feature being used.
[*]make sure that these examples are available for (at least) lpc1114, lpc1343 and lpc1769 (the 'old' LPCXpresso boards)
[/LIST]
Anyone interested to join? (please note that there are no incentives - yet ...)
Is Code Red willing to facilitate by (at least) including this set of examples with the LPCXpresso distribution?

Regards,

Rob

[lpcware]

Content originally posted in LPCWare by serge on Mon Jul 18 00:44:16 MST 2011
I think that even small typo's are a problem for newbies. I was looking at the revised LPC17xx.cmsis.driver.library (june 2011) and found under 'drivers', 'source' this LPC17xx_I2C.c file with this public function:

---

Quote:
/*********************************************************************//**
* @brief General Master Interrupt handler for I2C peripheral
* @param[in] I2Cx I2C peripheral selected, should be:
* - LPC_I2C
* - LPC_I2C1
* - LPC_I2C2
* @return None

---

Where all other functions in this library state as parameter LPC_I2C[COLOR=red]0[/COLOR] they mention here LPC_I2C :eek: (which is a typo).

Maybe there are other typos like these. I didn't read the complete .c file nor did i test it.

For newbies this can be very frustrating, doing things like told in the header and comming up with an error.

It would be nice if someone could reread the samples before posting them :p

[lpcware]

Content originally posted in LPCWare by StephenHawkings on Sat Jul 16 05:01:29 MST 2011
From my point of view, it's important to get a readable code. And in fact,

"SSP0IMSC_RECEIVE_OVERRUN_INTERRUPT_ENABLED" is for me more readable than "RORIM".

Or another example:

//8 bits, no Parity, 1 Stop bit
LPC_UART->LCR = 0x83;                                                 compared with

//Define UART 8 Bits, No Parity, 2 Stop Bits
LPC_UART->LCR |= U0LCR_8BIT_CHARACTER_SELECT | U0LCR_2_STOP_BITS;

Which one is more readable; also for professionals?

My includes are written for the aspect, that someone does not write code every day, and doesn't want to read always the UM. So my includes contain the register descriptions as in the UM. To keep the UM always beside, is not necessary then. And if it's very rarely necessary to look up something in the UM, the search engine in PDF reader will find "U0LCR" quickly.

3 engineers, 4 different ideas. :-)

Best regards!
SH

[lpcware]

Content originally posted in LPCWare by ktownsend on Fri Jul 15 17:05:49 MST 2011
Rob:

I agree that CMSIS is more appropriate for most people ... the library I wrote catered to my own preferences and habits (good or bad), and I started writing it before many examples or even the chips themselves were widely available.  Were I to start today, I'd definately start with CMSIS as a base simply for consistency sake.

I simply pointed to the header files if someone is looking for all of the bits to be defined in one file for CMSIS or some other use since I spent many days copying and pasting from the UM and ARM documentation to fill all those values in, and thought it might save someone else some dreadfully dull work.

As you mentionned, the real problem with any sort of collaborative effort is that most engineers have very strongly held beliefs on just about everything, and it's easy to argue about little details of more intellectual worth than any practical value. :)

If you're interested in contributing the I2C changes you made for example, why not setup a project on google code (SVN) for example, and people can make changes accordingly to some of the other examples.  I'd be happy to rework a number of drivers I've written or some changes I've made to examples like power management, etc.

Kevin

[lpcware]

Content originally posted in LPCWare by Rob65 on Fri Jul 15 02:06:26 MST 2011
Kevin,

---

Quote: KTownsend
and made my own header files

---

What's wrong with:

LPC_SSP0->DR = cmd;

With your own defines this would be:

*SSP_SSP0DR = cmd;

The good thing about the CMSIS defines is that it's all there. Defined and checked by NXP.

For the bit defines I used the same names as the ones in the UM.
So not "SSP0IMSC_RECEIVE_OVERRUN_INTERRUPT_ENABLED" but just RORIM. I think #defines should be short enough to keep code readable. Long lines or register initializations that take up many lines are still not readable.

I prefer:

    LPC_SC->PLL0CON = PLLE0;                        /* Enable PLL   */
    LPC_SC->PLL0FEED = PLLFEED1;
    LPC_SC->PLL0FEED = PLLFEED2;

    while(!(LPC_SC->PLL0STAT & PLOCK0));            /* Locked ?     */

instead of:

    LPC_SC->PLL0CON = SYSCON_PLL0_CONTROL_ENABLE;
    LPC_SC->PLL0FEED = SYSCON_PLL_FEED_1;
    LPC_SC->PLL0FEED = SYSCON_PLL_FEED_2;

    while(!(LPC_SC->PLL0STAT & SYSCON_PLL0_STAT_LOCKED));

For two reasons. First, the defines are the same as in the User Manual - and I need to check the user manual anyway to find out how to program the block. Second, the short comments tell me much more than the longer #defines.

So you see, we have 3 software engineers with 3 different ways of doing things

For the examples, I started this thread to discuss the creation of a consistent set of examples for the lpc11/13/17 series, I definitely prefer to use the CMSIS and defines with the exact names as the ones in the user manual.
Also, when defining bit masks I recommend (1<<3) instead of 0x08. The first one shows me in one view that I am setting bit 3, for the second one I have to count (what bit is set in 0x200000 ???? bit 26).

Regards,

Rob

- No, it is bit 25 :eek:

[lpcware]

Content originally posted in LPCWare by ktownsend on Thu Jul 14 11:58:33 MST 2011
SH:

I don't know how useful this is to you, but I also like have all of the individual bits defined with text rather than magic numbers and made my own header files for the LPC134x and LPC111x because of this:

https://github.com/microbuilder/LPC1343CodeBase/blob/master/lpc134x.h
http://code.google.com/p/lpc1114codebase/source/browse/trunk/lpc111x.h

Sorry that one is Github and the other is google code ... I've been moving over to Github but haven't update the 1114 library yet.

Kevin

[lpcware]

Content originally posted in LPCWare by StephenHawkings on Thu Jul 14 11:17:05 MST 2011
In fact, I think there is possible a lot of improving. Especially, I'm tired about the bit-field problem, so I made include-files for peripherals etc. I made it out of the original datasheet.

So I spend the enclosed ZIP file for this community:

LPC111x_ADC.h
LPC111x_CAN.h
LPC111x_Counter_Timer_16Bit.h (checked)
LPC111x_Counter_Timer_32Bit.h
LPC111x_FLASH.h
LPC111x_GPIO.h (Direction of bitfields need check)
LPC111x_I2C.h
LPC111x_SPI.h
LPC111x_SystemControlBlock.h
LPC111x_SysTick.h (checked)
LPC111x_UART.h (checked)
LPC111x_Watchdog.h

These files are for a first start; some are first time checked shall be checked second time, other I never used myself, need to be checked for first use.
Best regards!
SH

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Jul 14 11:04:39 MST 2011

---

Quote: KTownsend
I think the 8kHz is a reference to the slowest speed for the WDT oscillator (/* Freq. = 0.5MHz, div = 64: WDT_OSC = 7.8125kHz */) ... for the lowest possible power consumption.

---

and I thought it was 32.768 kHz / 4 :eek:

---

Quote:

Thankfully, once you get it working on the 1114 it's just copy and paste for the 1343 (which is probably why they didn't provide a 134x example as well, although many people only using the 1343 might not think to look at the very similar 111x examples as well).

---

There is another thread asking if there is a list of peripherals that are the same in different LPCs and which are different ...
Since we don't know for sure we have to read both UMs to see what we can copy and what we need to change.
Clocking and IO config is different so if the example is not working on the other part is that because I made a mistake with clocking or IO config or is there a difference I failed to notice.

---

Quote:
Making a repository on something like GITHUB is a possibility but someone needs to manage it. :(
...
...
What's your thought on starting with a library on GITHUB for some of the more popular parts?

---

If your question is about a library of examples then yes - that might be a good idea. Although something like subversion or cvs would be even better since then we can submit directly from within LPCXpresso (I use a subversion server for this myself).

But GITHUB has a very nice online view of the archive with a nice look&feel so it might not even be a bad idea to do this.

Regards,

Rob

[lpcware]

Content originally posted in LPCWare by ktownsend on Thu Jul 14 09:05:27 MST 2011
I think the 8kHz is a reference to the slowest speed for the WDT oscillator (/* Freq. = 0.5MHz, div = 64: WDT_OSC = 7.8125kHz */) ... for the lowest possible power consumption.

The example might be a bit hard to wrap your head around, but when I wrote code to do this myself (before the example was published or anything useful was in the UM) I had to fill in a lot of blanks myself. This example still would have made my life easier so better late than never even if it still takes a bit of time in the datasheet/UM to understand. I think it took me almost a week to really get everything working properly on my own. Thankfully, once you get it working on the 1114 it's just copy and paste for the 1343 (which is probably why they didn't provide a 134x example as well, although many people only using the 1343 might not think to look at the very similar 111x examples as well).

I agree some of the example code could be improved, but obviously it's hard to see how to manage that since you'll need some soft of official gatekeeper to control what gets included and what doesn't, and I don't know if NXP wants to pay someone to manage that(?). Making a repository on something like GITHUB is a possibility but someone needs to manage it. :(

The examples for the different chip families definately vary a lot. While I'm not going to complain too loudly since any example is better than just a UM ... but some of the recent library code I've seen for newer parts has been pretty good. But again ... I'm also just glad to see NXP/CodeRed providing things in GCC as well rather than the just the traditional Keil. It's easy to port between them, but it's better than things were in the LPC2000 days.

What's your thought on starting with a library on GITHUB for some of the more popular parts?

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Jul 14 07:13:27 MST 2011

---

Quote: KTownsend
For the WDT comment I think they mean to wake up from the timerhttp://https://github.com/microbuilder/LPC1343CodeBase/blob/master/core/pmu/pmu.c#L219

---

Indeed - the remark in the readme confused me but that is the only way to use the WDT. But now try to understand what they mean with the 8 kHz oscillator speed. Then try to discover what the code actually is doing.
It is a big mess of programming timer, WDT, timer, some BOD bits are mixed in on the go ... hard to follow what the real goal of the example is.

Rob

[lpcware]

Content originally posted in LPCWare by ktownsend on Thu Jul 14 04:46:04 MST 2011
For the WDT comment I think they mean to wake up from the timer, you first switch to the WDT oscillator for the timer clock for the lowest possible power in deep sleep.

I wrote this before an example existed so I may have got some things wrong, but this is the same approach I took here:

https://github.com/microbuilder/LPC1343CodeBase/blob/master/core/pmu/pmu.c#L219