Total Noob tutorial

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lams_007 on Thu Feb 21 21:15:20 MST 2013
I am actually totally new to ARM architecture I know how to use some 8-bit microcontrollers (AVR, PIC and MSP430), but I have been looking for a little tutorial, or something where I can have that little push I always need to start with one new architecture, I have read the datasheet and really don’t understand registers, I have seen examples but they don´t help me a lot I am looking for basically a total noob tutorial someone know where I can find

lpcware · ‎06-15-2016

Content originally posted in LPCWare by markr on Tue Oct 22 07:54:17 MST 2013

Quote: cpldcpu
I added it to system_LPC8xx.c in the codebase, along with the clock calculations. I don't think it is set anywhere in the official libraries.

#if __SYSTEM_CLOCK <= 30000000
  LPC_FLASHCTRL->FLASHCFG=0;                /* Set flash waitstates to zero if core clock is <=30 Mhz. Default is 1 waitstate */
#endif

I did the same thing. I have my own system_LPC8xx.c (and header file) and I merged your code into mine.

Quote:

The NXP support told me that the wait states are supposed to be set by the energy management ROM routines. Now the real joke is that there is a recent erratum that recommends accessing the ROM only wait flash waitstates>0. This seems to be a bit contradictive.

Are the ROM routines documented anywhere? I know several people have reverse engineered the ISP routines. I have the "LPCOpen Doc" but it appears to be 5000+ html, javascript and code examples with no structure. The LPCOpen start_Here.html just leads to the website, even though it also loads 5000 files locally.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by fjrg76 on Wed Jul 29 23:19:50 MST 2015
Just sit and think as a newbie would do when facing the LPC812/Cortex-M0+/32Bits architecture for the first time and then you'll figure out what NXP can do in order to make the transition less painful.

Even for someone like me that not only has experienced in this architectures, but that also loves your LPCs micros, everytime I start a new project this experience becomes quickly a pain in the back.

Have you noticed that the official library for the LPC1227 is not only incomplete but also has bugs? Not to mention that such a library is obsolete compared with the ones related to, say, LPC11E67, or LPC800, or LPC1500, and so on? BTW, no one is taking care of it, I mean, for the time being, the LPC1227 library is death, sadly to tell :((

Let's go to the point: As a LPC812 new user I just want to send the letter 'A' through tUART0 at 9600,8,N,1. Forget for now fancy things like the ring buffer. Have you tried that? It takes hours! I hate Arduino, but in this platform it tooks seconds to start sending the letter 'A' through its serial port.

At hardware level, LPC800 family rocks and beats any 8/16 bits platform. But a firmware/driver/examples level, there are so much room for improvements.

Greetings! ;-)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cpldcpu on Tue Oct 22 08:44:22 MST 2013

Quote:

Are the ROM routines documented anywhere? I know several people have reverse engineered the ISP routines. I have the "LPCOpen Doc" but it appears to be 5000+ html, javascript and code examples with no structure. The LPCOpen start_Here.html just leads to the website, even though it also loads 5000 files locally.

The Power-API is documented in the user manual. The code itself is not available though, at least i was not able to find it.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cpldcpu on Mon Oct 21 23:48:29 MST 2013

Quote:
Is the wait state set _anywhere_ in the libraries? I haven't found it.

I added it to system_LPC8xx.c in the codebase, along with the clock calculations. I don't think it is set anywhere in the official libraries.

#if __SYSTEM_CLOCK <= 30000000
  LPC_FLASHCTRL->FLASHCFG=0;                /* Set flash waitstates to zero if core clock is <=30 Mhz. Default is 1 waitstate */
#endif

This file is part of the official start up code and usually should not be altered. So this approach is debatable, but it comes with the least overhead...

The NXP support told me that the wait states are supposed to be set by the energy management ROM routines. Now the real joke is that there is a recent erratum that recommends accessing the ROM only wait flash waitstates>0. This seems to be a bit contradictive.

Quote:

With the right examples and library the LPC81x should kill the little 8 and 16 MCUs in the market today. But it's hampered by bad libraries and poor examples.

I agree, the LPC800 looks really nice one on paper. But a lot of bugs, rough edges, poor documentation and delays made it less attractive than it could be. Also, some really powerful competitors in the same package size are emerging (XMC1x00, STM32F03, STM32F05 in TSSOP20) with a more complete set of periphery. For example ADC was only planned in the next iteration of the LPC800 while some of the competing devices offer it now at a very similar price point. The same goes for DMA and a more advanced set of timers.

I really like the SCT, but for many applications (such as your WS2812 driver) DMA could actually be a more powerful alternative. Of course a combination of DMA, SPI and SCT would be the best approach to a zero overhead WS2812 driver...

Edit: Of course DMA will never replace a state engine, but it can be more powerful in waveform generation applications.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by markr on Mon Oct 21 16:07:50 MST 2013
I guess we're thread hijaking here. If a moderator can move these comments to a thread like "library issues", that would be nice.... :-)

Quote: markr
>If the idea is to write portable code, it would be much better to define the clock rate (or bit fields) in a project specific header file, and then pass them to the clock setting routine

Quote: cpldcpu
I did this in a pull request I submitted to microbuilders LPC810 sample code. However, it involved changing CMSIS slightly, which is of course not the way things should be done.

I'd like to add one further gripe: The flash wait state configuration is never addressed in any of the examples. The default configuration with 2 cycle access almost halves the core speed and is not really desirable from a power point of view.

Is the wait state set _anywhere_ in the libraries? I haven't found it.

I actually pulled your code and tried to merge it with LPChobbyist's code that used the SCT to drive a WS2812 LED string. That was my initial goal of the LPC810-min board: a serial to WS2812 driver. The pure bit banging solution didn't leave enough bandwidth to implement a serial command parser, and using the SPI bus a single bit waveshaper worked, but was ugly. (I could have done that with an MSP430 if I wanted a kludge.)

But I never got the merged code working. I had developed my own spreadsheet that gave the same data for the SCT, but the output was always 2x what it should have been. I suspect buried someplace inside the libraries was a clock setting that expected 12MHz and was getting 24MHz.

Now that I can set clocks with reasonable confidence, I'll go back and play with the WS2812 driver and see if I can get it to work.

I've reached the point where I use the system headers for the register structure names and am writing my own libraries and functions from scratch.

Case in point: I used the GPIOSetbit function to set/clear an IO pin to create a pulse in MRT_IRQHandler. The two function calls were back-to-back and did not include the IRQ clearing or incrementing mrt_counter (which is not documented in the function comments!). The pulse time was 1.46 uSec or 35 instructions at 24MHz! On a single clock per I/O processor this is crazy. I turned of the wait states (Thank-you cpldcpu!), re-coded it as a macro and it uses 3 clocks, a 90% decrease in overhead.

With the right examples and library the LPC81x should kill the little 8 and 16 MCUs in the market today. But it's hampered by bad libraries and poor examples.

I haven't tried the clock & pll spreadsheet with Open Office, but it doesn't work with Office2003 or Google docs. It requires at least office 2007. So far the only tool I've found that works as advertised is the Switch Matrix Tool.

-markr

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cpldcpu on Sat Oct 19 11:27:32 MST 2013
Maybe a practical example about the issue of going from AVR to LPC810:

I am currently trying to use a nRF24L01+ module on the LPC812 SPI port. There are zillions of libraries for the AVR and Arduino. So, great, I could just port one of the libraries. So the only new part I need is SPI, right?

Turns out that there are lots of HW registers to configure SPI, much more complicated than on AVR. But wait, I should use the firmware library for I/O anyhow. So I imported the LPC800 driver lib into the project, which works nicely in LPCXpresso.

So but where is the documentation? None? Does not matter, I'll just look at the source.

The first function to call is obviously SPI_Init.

/*****************************************************************************
** Function name:SPI_Init
**
** Descriptions:SPI port initialization routine
**
** parameters:None
** Returned value:None
** 
*****************************************************************************/
void SPI_Init( LPC_SPI_TypeDef *SPIx, uint32_t div, uint32_t cfg, uint32_t dly )

Interesting. First of all there is some undocumented structure to define a local context. Do I need to create one myself? No parameters need to be passed?? Really? What are div, cfg, dly?

Ok, maybe I am not approaching this from the right angle. But these are just some of the problems...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Pacman on Sat Oct 19 04:55:37 MST 2013
Mark, I agree with you on all these issues. (Paul, I think these things are important).

As for me, I also thought about this CPU-clock.
What I did, was that I spent some time writing macros (and #IFs) for the 1768, which calculated/generated the bit values required. That allows me to change the CPU clock on the command-line (at compile-time).

I later wrote a routine to set the clock rate.

More pins on the LPC8xx ... Haven't thought about it, but having a couple of ADCs would probably be something many people would benefit from. I do not use ADCs myself, though.
On the other hand... I might make a product that used such an ADC if the 8xx series had it.
... And six 8-bit resistor DACs, where four of those are on the same port (eg. P1[31..0]). :)

-But if you really need many I/O-ports, then NXP makes a low cost I/O-expander called PCA9557D.
It's I2C, 400kHz.
Other companies make some that support higher speeds. I do not know if NXP makes fast I/O-expanders too, but the above mentioned one could probably be a good companion for the 812 if you need more I/O ports.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cpldcpu on Sat Oct 19 00:26:49 MST 2013
>If the idea is to write portable code, it would be much better to define the clock rate (or bit fields) in a project specific header file, and then pass them to the clock setting routine

I did this in a pull request I submitted to microbuilders LPC810 sample code. However, it involved changing CMSIS slightly, which is of course not the way things shuold be done.

I'd like to add one further gripe: The flash wait state configuration is never addressed in any of the examples. The default configuration with 2 cycle access almost halves the core speed and is not really desireable from a power point of view.

>I like the LPC81x series. I'd love to see an LPC82x or LPC83x with more IO pins.

I recall seeing some older slides where further members of the LPC800 family were anticipated in 2013. I did not see any announcement so far. There are a couple of alternatives from other manufacturers in this space now, some at lower prices points and with more functionality (ADC, DMA). Will be interesting how NXP is going to react to this.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by markr on Fri Oct 18 15:56:26 MST 2013
Number one would be to clean up the example code and libraries, make them more LPC81x efficient, then document, document, document it!

I'm a 20 year veteran of using micro controllers from the 8048 to TI MSP430s, but this is my first ARM. I thought choosing the LPC810 (on the mini-board) would be easy because it was a small device. But it's definitely an ARM and ARM is very different and has a different view of the code writing. It's taken me while to understand.

I finally realized that part of my "not understanding" was because of errors and omissions in the example code and libraries. I feel that a lot of what I "didn't understand" was because the library code was written for Cortex-M3s or larger cores and changed only enough to make it run on the M0+. As cpldcpu pointed there is a low of inefficiency in the clock libraries.

Example code issues:
Sample code that lists what a function does, but doesn't mention that it modifies global variables (the MRT IRQ handler) or
that a function depends on the system clock running at a specific clock rate that is not specified (delayMS) [And what is a "milo second"?]

The blink sample code says it's running at 24MHz and puts the clock out on a pin, but the pin is toggling at 12MHz and all the time delays (as measured on a scope) are 2x what they should be. Furthermore, the CLKOUT_Setup function has CLKOUTDIV hard coded with a value of 1.

These types of issues are common throughout the example code and libraries: An example will list an operating clock, but the compiled code does not produce the desired result.

As I see it, the problem is the PLL and clock parameters are defined in a global library header file that is used for all projects rather than in a project specific location that is then passed to the global libraries.

The clock & pll spreadsheet can be used to determine the various PLL & clock mux values. There is a library call to determine what the clock actually is, but the clock rate itself is never declared in a single, easily identified location. The only way to determine the clock rate is to run the code, or reverse engineer the clock rate by hand from the bit fields.

If the idea is to write portable code, it would be much better to define the clock rate (or bit fields) in a project specific header file, and then pass them to the clock setting routine.

Finally the LPC compiler and tools are very Xpresso board-centric. If you're not using an Xpresso board, you're on your own. I started with the LPC810-mini board and I could build projects created by others that produced a hex file for Flash Magic, but I had to copy their build settings to produce a hex file with the example code that was provided for by NXP specifically for the LPC810 Mini board. A radio button to enable the creation of a HEX file would have saved a lot of time and frustration.

I like the LPC81x series. I'd love to see an LPC82x or LPC83x with more IO pins. It could really upset the embedded market. But the tools and libraries need work.

-markr

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Pacman on Fri Oct 18 06:15:11 MST 2013
@Bingo: Try calling El-Supply and ask them if they can get it; they sometimes order components from Farnell and RS. Farnell has the LPC812 (1.27mm pitch) as I wrote in another thread.

If you need to find dealers in Denmark, just go to elektronik.gpio.dk; I've listed all the dealers I could possibly find in DK, plus some in Sweden, Norway, UK, Germany and other countries.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Bingo600 on Wed Oct 16 22:33:47 MST 2013

Quote: nakedible
For me, the biggest hurdle was getting the toolchain set up, as I have not worked with microcontrollers before.

I downloaded LPCXpresso from LPCWare. All I found there was a page that said "NXP Verified: Yes" on a non-secure page and a link to a binary in Amazon S3 (for Linux). I downloaded the binary, and the first thing it does is ask me for root permission. This is obviously unacceptable, so LPCXpresso was a no go.

Luckily just by having a standard "arm-none-eabi-gcc" toolchain, adapting some of the cr_startup_lpc8xx.c stuff and a linker script, I was able to finally get a working binary. Lpc21isp worked right out of the box, too, and was very helpful.

That might be a bit "parnoid" , but maybe NXP can add a MD5 sum to the download packages/page.

See http://www.lpcware.com/content/forum/lpc812-max-original-sample-codewhere-it#comment-1132574
For another example with the "launchpad" toolchain

I just saw this one...
http://hackaday.com/2013/10/15/breadboarding-with-a-arm-microcontroller/

That's a neat hack (The use of the debugger wo. using the xpresso TC)
I'll have to try that ....

I wonder if the 812-Max can be used as a dongle , else i do have a few of the old Xpresso-LPC1768 boards , and might "dissect one" ...

/Bingo

lpcware · ‎06-15-2016

Content originally posted in LPCWare by nakedible on Wed Oct 16 21:28:48 MST 2013
For me, the biggest hurdle was getting the toolchain set up, as I have not worked with microcontrollers before.

I downloaded LPCXpresso from LPCWare. All I found there was a page that said "NXP Verified: Yes" on a non-secure page and a link to a binary in Amazon S3 (for Linux). I downloaded the binary, and the first thing it does is ask me for root permission. This is obviously unacceptable, so LPCXpresso was a no go.

Luckily just by having a standard "arm-none-eabi-gcc" toolchain, adapting some of the cr_startup_lpc8xx.c stuff and a linker script, I was able to finally get a working binary. Lpc21isp worked right out of the box, too, and was very helpful.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Bingo600 on Wed Oct 16 10:18:28 MST 2013

Quote: cpldcpu
I am using a <2$ USB to serial converter from ebay to power the device with 3.3V and run the bootloader. That works quite well.

I think the main hurdle is to actually get devices. The LPC810 mini kit was a nice idea, but I'd rather have ordered a couple of extra LPC810 at my favourite electronics supplier.
Even if the LPC810 becomes available at some point: All of the current distributors charge more than 20$ for shipping. In my opinion it is important to get the devices to more accessible suppliers.

Here i agree 100% ....

There is no way to get at few NXP MCU's for a hobbyist ...
I have tried :-(

Why couldn't NXP or Embedded Artists or ??? have a shop on *Bay EU , where one could buy some low quantities NXP Arm MCU's , with a decent shipping price.

Please make it EU located , as the US residents apparently doesnt have to pay VAT for a few MCU's ... As we EU'ians do.
The VAT isn't even the worst ... Thats the "VAT handling Fee" witch is 20€ here in DK.

I was searching for LPC1114-28Dip for 4 month before i found someone that could/would deliver for a decent price.

/Bingo

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cpldcpu on Fri Oct 11 05:30:59 MST 2013
I am using a <2$ USB to serial converter from ebay to power the device with 3.3V and run the bootloader. That works quite well.

I think the main hurdle is to actually get devices. The LPC810 mini kit was a nice idea, but I'd rather have ordered a couple of extra LPC810 at my favourite electronics supplier.
Even if the LPC810 becomes available at some point: All of the current distributors charge more than 20$ for shipping. In my opinion it is important to get the devices to more accessible suppliers.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by starblue on Wed Oct 09 01:36:35 MST 2013
I think for starting it is easier to run on the internal oscillator, and to use the boot loader for programming.
Also the boot loader is a good safety net, it is almost impossible to brick an LPC controller.
If you don't have a serial interface you should get one.

I like 3.3V FTDI breakout boards for that: http://www.watterott.com/en/FTDI-Breakout-Reloaded-V11
Except for RTS they have all the signals needed for ISP on a 0.1" connector and can provide power.
Instead for using RTS you can set the pin for entering ISP to high or low manually.
(I added a connector for RTS so that entering the boot loader is automatic, but soldering a wire to the 0.5mm pitch FTDI chip is not so easy.)

I use lpc21isp for programming (thanks capiman!).
If it doesn't recognize your chip you may need to download the newest version, especially for the LPC8xx controllers.

The breakout board linked above is for Arduino, with a standard Arduino connector as far as I understand.
It would be nice if a similar standard connector existed for LPC controllers (e.g. on the LPCExpresso boards),
but with RTS replaced by CTS, so that newbies could just plugin a suitable serial breakout board.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Pacman on Tue Oct 08 13:40:18 MST 2013
Paul, this is one of the reasons I like NXP so much - apart from making great products. :)

Oh, I forgot to mention above, that I'm actually using a PowerMac (eg. PPC based, not intel based) to program the LPCs via JTAG.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by NXP_Paul on Tue Oct 08 09:19:00 MST 2013
Pacman
We very much appreciate your feedback and the time you took to write up your comments. I'll make sure that these suggestions get elevated to the appropriate people.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Pacman on Tue Oct 08 08:02:20 MST 2013

Quote: NXP_Paul
I would be interested to get feedback on what NXP should do to help new users get familiar with the LPC812.

To me, that is definitely a tough question to answer. (That might be a good sign).

Unfortunately, I'm no longer totally new to NXP or the LPC, but for inspiration, I'll try pretending coming just from some 8-bit microcontroller.
I'll pretend to be an almost extreme-newbie in this case, because sometimes things "just won't work", and it's good to have some detailed guidance on each step.

Usually people have a Windows-based PC, which calls for a serial bootloader (that's a very good idea, indeed!) and the ARM-tools (click-one-button-to-install software).
-But for me, things are different. =P

First thing is that I do not have a Windows-based PC, so I will have to go with open-source tools.

I will need to know how to build my own tools, as they're not available for my platform (no need to make a step-by-step guide, but you could point to the Yagarto and Linaro toolchains, which is are known to be good and working). (as for myself, I had to build my own, as the two mentioned toolchains would not build on my system).

OK. After that I need a JTAG adapter to be able to program the chip, as I don't have a serial interface on my computer (yes that's right, argh!).
Fortunately I have USB, but my ISP-adapter from the previous microcontroller I worked with will not work, as it's using SPI- or some other interface.
As a newbie, I would probably prefer a low-cost general-purpose JTAG adapter, which is not too difficult to get working with the open-source tools (OpenOCD in this case).
(Some of those sold on eBay won't work with LPC, so I won't buy those. Personally I have Olimex's Tiny-H and JTAG-lock-pick Tiny 2).

Next thing is to get example code and libraries (from sw.lpcware.com and git.lpcware.com) - how to download and clone.

Now a difficult one: How do I get the libraries and examples built with gcc (I recall having trouble with this).

OK, I got all the "free stuff". Now I ordered my chip, but it hasn't arrived yet, but I'd like to wire up a breadboard.
What components are necessary and why ?

...1 electrolytic capacitor, 1 x 100nF, 2 x 18pF, 1 x 12MHz crystal; connect the chip to 3V3, a male 20 pin-header/-IDC connector with 7-8 (10K) pull-up/-down resistors and you're good to go.
(where do I find the correct way of connecting the pull-up/-down resistors for JTAG, and how do I verify that the JTAG is wired up correctly)

Let's assume the chip has arrived and the breadboard is ready.

Now I need to initialize the chip, to get my long-awaited blinking LED - oh, I need to also connect a resistor in series with the LED; I could use 100 ohm in order to be blinded, but using a 1K has been my favorite for a long time.

I need to understand that I need to turn on the hardware power-switch to be able to get the hardware online. Eg. clock-power. This is essential and if starting with an ARM7TDMI-based microcontroller, this is really something that I must understand even before I place the chip on an adapter-PCB.

But again, it's essential that I know that I need to turn on the clock-power and why; it'll save me a lot of headache in the future.

I do not know if there are anymore things that could be "showstoppers" for a newbie. The most difficult of them has to do with getting open-source tools working.
Being able to get quickly through these problems would definitely be a huge help. The hardware problems are much easier: Smoke and smell means your wiring is incorrect. ;)

(I've gotten the LPC1768 working well, but am still having problems with flashing the 43xx - you probably wouldn't believe it, after all the help and config files I received from people in the 43xx category).

But if you ask me, the NXP support is doing quite a good job, especially when comparing to some of your competitors. ;)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Bingo600 on Wed Oct 02 12:47:33 MST 2013
I was lucky enough to get one of the LPC-812 Max boards for 1€ (Thanx NXP)

I have posted how to make the famous Blinky here , but using plain arm-gcc.
http://www.eevblog.com/forum/microcontrollers/lpc-812-max-arm-gcc-blinky/

I'm Linux based , and prefer plain arm-gcc, i switched from CodeSourcery arm-none-eabi-gcc to the one from launchpad, when Mentor bought CS.

You can get the latest arm-gcc for Linux,Mac or Windows here
https://launchpad.net/gcc-arm-embedded

/Bingo

lpcware · ‎06-15-2016

Content originally posted in LPCWare by NXP_Paul on Mon Sep 30 11:19:45 MST 2013
I would be interested to get feedback on what NXP should do to help new users get familiar with the LPC812.