http://learn.adafruit.com/getting-started-with-the-lpc810/
Introduction
The LPC810 is a new microcontroller from NXP, a super fast little controller has only 8 pins but packs a lot of punch with a high speed processor and 32 bit instructions. This learning guide will show you everything you need to know to get started with the ARM Cortex M0+ based LPC810 microcontroller. It will cover:
Setting up a cross-compiling toolchain for ARM
Creating and compiling your first blinky program
Programming the LPC810 using free and open source tools
Blinky!Created by Kevin Townsend
http://learn.adafruit.com/getting-started-with-the-lpc810/blinky
Now that we have our project imported, we can get start creating our own projects.
By default, the LPC810_CodeBase you downloaded is setup to run a blinky example on pin 0.2, and it spits out 'Hello, LPC810!' on the default UART pins, which we can see in the 'while(1)' super-loop in main.c, shown below:
while(1)
{
#if !defined(USE_SWD)
/* Turn LED Off by setting the GPIO pin high */
LPC_GPIO_PORT->SET0 = 1 << LED_LOCATION;
mrtDelay(500);
/* Turn LED On by setting the GPIO pin low */
LPC_GPIO_PORT->CLR0 = 1 << LED_LOCATION;
mrtDelay(500);
#else
/* Just insert a 1 second delay */
mrtDelay(1000);
#endif
/* Send some text (printf is redirected to UART0) */
printf("Hello, LPC810!\n");
}
"LPC_GPIO_PORT->CLR0 = 1 << LED_LOCATION" will clear whatever pin is at the 'LED_LOCATION' bit on GPIO bank 0.
'LPC_GPIO_PORT->SET0' does the opposite.
This is how you turn the LED on or off, but for those changes to be visible, we need to insert a delay between state changes, which is accomplished with the mrtDelay(500) lines, which causes a 500ms delay.
Blinky is following by our printf() statement, and by default all printf output is redirect to UART0 on the LPC810.
USB to TTL Serial Cable - Debug / Console Cable for Raspberry Pi
http://www.adafruit.com/products/954
The cable is easiest way ever to connect to your microcontroller/Raspberry Pi/WiFi router serial console port.
Inside the big USB plug is a USB<->Serial conversion chip and at the end of the 36" cable are four wire - red power, black ground, white RX into USB port, and green TX out of the USB port. The power pin provides the 5V @ 500mA direct from the USB port and the RX/TX pins are 3.3V level for interfacing with the most common 3.3V logic level chipsets.
Because of the separated pin plugs, this cable is ideal for powering and connecting up to the debug/login console on the Raspberry Pi or BeagleBone Black. Connect the pins as shown to power the Pi or BBB and establish the RX/TX link. Then install the Windows XP/Vista/7 or MacOS X PL2303HX.A drivers on your computer and connect with a terminal program at 115200 baud. Windows 8 is not supported.
Also handy for hacking WiFi routers to install alternate OS's, or nearly any other TTL port. This is easier to use than an FTDI cable in many cases because the wires are separated .
This cable is not good for Arduino re-programming such as a Boarduino, MENTA, Monochron, etc. because it does not have the DTR/RTS wire necessary for initiating the bootloader reboot sequence. For that we suggest an FTDI cable or FTDI friend.
OK ... But why the LPC810 at Adafruit? Created by Kevin Townsend
http://learn.adafruit.com/getting-started-with-the-lpc810/ok-dot-dot-dot-but-why-the-lpc810-at-adafruit
I'll be honest ... I just thought this was an incredibly interesting chip. I've been using NXP's LPC series of MCUs since, oh, forever ... but this particular chip in DIP8 really jumped out at me since it's so different than what people usually think of when they hear 'ARM'.
The DIP8 LPC810 is still somewhat of a challenge to use precisely because it's so small (by ARM standards, anyway): 4KB flash and 1KB SRAM. That doesn't go far, and in reality you only have about 3KB flash to play with once you add in your startup code and get everything setup.
But that's actually part of what I found so fun about this chip! It's a genuine challenge but a fun one to do something creative and interesting with so much performance in such a small space!
'Small is Beautiful' Warning: Shameless, unadulterated, highly-personal rant!
Really ... small is where it's at if you care about writing clean, efficient code and really learning how to do something properly and understanding what you're doing!
I always start my new projects with the smallest chip I can, rather than the biggest one available.
Why?
Because it forces me to keep size in mind, to try to write better, more efficient code, and to get the most out of the limited resources I have.
Why do I always start with ARM chips with 32KB flash and 8-12KB SRAM when I could get something with 512KB flash and 100KB+ SRAM for not much more?
Because if I started with those big chips I'd write even sloppier code that took more space than I needed, and I'd be stuck with bigger and more expensive chips and even worse code forever!
One of the biggest difficulties in deeply embedded systems is keeping things lean, without compromising on stability and reliability. That means error checking, data validation, etc., which takes space and time to implement, but you need to keep space in check, so it's an endless series of trade offs, decisions and optimisations.
Deeply embedded development has a lot more in common with mechanical watch-making than it does with traditional SW development: you're always trying to fit an impossible seeming number of gears and components into a ridiculously small package, and everything has to fit in in just the right manner to work at all. To throw some oil on the fire, it also needs to hold up to all manner of abuse and mistreatment that will get thrown at it, and keep smiling back at you day after day!
Something embedded SW engineers understand better than almost anyone else -- except maybe those crazy mechanical watch makers -- is the huge satisfaction in writing clean, concise, efficient code that solves real problems in concrete, elegant, reliable ways. Writing bloated code is easy ... writing elegant code and creating tiny solutions for big ambitions is harder, but also infinitely more satisfying!
Why the LPC810 with it's tiny package, and limited resources? Because it's a fun challenge and a really interesting way to learn ARM!
I really wanted to get this chip in people's hand just to see what people can do with 4KB flash and 1KB SRAM, and a reasonably limited set of peripherals. It's the kind of fun challenge that I enjoy working on, and I'm sure I'm not alone in that!
uv4 code size limit is only 32K!Saturday, 6 July 2013
http://fongeye.blogspot.hk/2013/07/uv4-code-size-limit-is-only-32k.html
hen I tried the debug thing. I found a big problem.
The evaluation mode code size limit is only 32K!
I guess 32K is very small, not that useful. Perhaps I should consider forgetting uv4 and start looking for other free tools more generous than uv4.
How disappointing!
I call it a day.
Posted by TL Fong at 22:10
.END
No comments:
Post a Comment