lpc 812 Max - arm-gcc blinky

[bingo600]

If anyone else got a 1$ LPC812 Max board.

http://www.embeddedartists.com/products/lpcxpresso/lpc812_max.php

And want to do a blinky with arm-gcc , i just completed one with help from the below repos.

https://github.com/sebseb7/lpc8xx

1: Get the base repos

git clone https://github.com/sebseb7/lpc8xx

2: Extract the attached sources into the newly cloned lpc8xx dir.

3: make

4: insert the lpc812 MAX Board into an USB slot on the pc (it'll open a new file-explorer window , like an usb-disk)
, pull the blinky.bin onto the "disk"

5: Press the Reset Key on the board , and your program is running.

I use linux , and arm-gcc from here https://launchpad.net/gcc-arm-embedded

/Bingo

[nctnico]

Are these devices already for sale? AFAIK these are the smallest ARM controllers available. IIRC there is supposed to be an 8 pin DIP version.

[dannyf]

One suggestion:

Code: [Select]

LPC_GPIO_PORT->SET0 = 1<<LED3;    // LED output high (Off)
LPC_GPIO_PORT->CLR0 = 1<<LED3;    // LED1 output low (On)

It would be a lot easier to write either a macro or a function that sets / clears pins on a variable (in your case), or a port base (which can be either pointer or a struct).

Something like this would work, for example:

Code: [Select]

#define PIN_SET(port, pins) port->SET0 = (pins) //set pins
#define PIN_CLR(port, pins) port->CLR0 = (pins) //clear pins

In your code, you can do this:

Code: [Select]

#define LED_PORT  LPC_GPIO_PORT (or whatever the struct pointer is)
#define LED1  (1<<7) //led1 on port.7
#define LED2 (1<<1) //led2 on port.1

...
  //set pins
  PIN_SET(LED_PORT, LED1 | LED2); //set led1 + led2
  PIN_CLR(LED_PORT, LED2); //clear led2

When you port the code to a different chip, all you need to do is to include the right files that implement the PIN_SET() or PIN_CLR() macros / functions.

The same can be done for setting input / output modes, etc.

[bingo600]

One suggestion:
...
...
...

When you port the code to a different chip, all you need to do is to include the right files that implement the PIN_SET() or PIN_CLR() macros / functions.

The same can be done for setting input / output modes, etc.

Thanx for the thoughts.

This is not my repos , but it's quite nice if you want to use plain arm-gcc.
The blinky was a quick hack of the already existing blinky (for the repos board).

It's a cute feature on the MAX-board , that you can pull the "bin" on the "drive" , and it will then be programmed to the lpc812 target.

So not much thought went into this code , other than i missed the "active low leds" and did not understand why it wouldn't show red. 

/Bingo

[dannyf]

that you can pull the "bin" on the "drive" , and it will then be programmed to the lpc812 target.

That's not unique: the LPC1768 from years ago does that too - youjust need to route out the D+/D- pins.

[bingo600]

EA has released the source for theit demo  (mbed code)
http://www.embeddedartists.com/sites/default/files/support/xpr/LPC812_max/LPC812MAXdemoTest_revPA1.zip

I just "tried" to port it to CMSIS , it is an ugly hack and the formatting is terrible.
I have no idea if i got the I2C right , but it responds to the button.

Edit: I just threw the source through indent , so the formatting is a bit nicer.

/Bingo

[Harvs]

Are these devices already for sale? AFAIK these are the smallest ARM controllers available. IIRC there is supposed to be an 8 pin DIP version.

Looks like the boards are out there.  The 8-pin DIPs (LPC810) are currently 0 stock everywhere, but farnell has a date of 24 Nov for them being in stock.

The strange thing is you can buy them in a kit from adafruit and they're in stock. http://www.adafruit.com/products/1336

[nctnico]

I'm pretty sure companies like Adafruit get a batch of samples while they are still warm 

[dannyf]

The 8-pin DIPs (LPC810)

I never understood purposes of such devices.

[nctnico]

Me neither. Maybe its just to annoy Microchip. I've seen designs with 12 8 pin PIC microcontrollers...

[bingo600]

The 8-pin DIPs (LPC810)

I never understood purposes of such devices.

I'm just a hobbyist , so i like DIP's.

I find it quite usefull, allthough i must admit that the DIP prob. isn't going to be the all time high seller.
My guess is that NXP had the "DIP mold" , and they're targeting "EDU Classes & Breadboards" that get familiar with the chip, and later the (now finished) EE's uses NXP in their designs.

For the 800 series i like 3 things :

1: It can "single cycle" toggle a gpio pin , meaning 30Mhz IO speed and 32bit bit operations.
     Combined with the 8 bit pattern match engine , and advanced bitmask regs. This can be a "logic chip" substitute.

2: It has a "real" 32bit timer (SCT) , everyone should have one  (I always loved NXP for their timers)
     I'll use it for a "jitterfree" 10Mhz down divider (Thunderbolt) ie. 1PPS,50Hz etc.

3: Arm-GCC has float & double (ie. AVR only has float) , makes some PID or DDS dividerwords easier to calc.
    Easier as in you don't have to do the calc with integer math.

That said ... I do like the DIP-28.Pin 1114 even better , but do admit that DIP's aren't going to be the top source of NXP's income.

Edit: I'll still use AVR's for things that doesn't require any of the above "skills" , you don't need a cannon to shoot a bird.

/Bingo

[dannyf]

1: It can "single cycle" toggle a gpio pin

Pretty much everyone has them, sometimes even in the 8-bit world.

2: It has a "real" 32bit timer (SCT)

Are there fake 32bit timers?

3: Arm-GCC has float & double (ie. AVR only has float) , makes some PID or DDS dividerwords easier to calc.

The frequency-to-tuning word conversion can be easily done in integer, with faster speed and better accuracy. The same with PID.

[Christe4nM]

2: It has a "real" 32bit timer (SCT)

Are there fake 32bit timers?

Nah, it just counts real numbers 

There are of course counters that are specified as 32-bits, yet under the hood are actually 8- or 16-bit counters cleverly used. I guess they can be called "unreal" or something 

[bingo600]

1: It can "single cycle" toggle a gpio pin

Pretty much everyone has them, sometimes even in the 8-bit world.

@30Mhz ?

2: It has a "real" 32bit timer (SCT)

Are there fake 32bit timers?

Yupp cascaded 16bits

3: Arm-GCC has float & double (ie. AVR only has float) , makes some PID or DDS dividerwords easier to calc.

The frequency-to-tuning word conversion can be easily done in integer, with faster speed and better accuracy. The same with PID.

Why did i know you would say that .....

/Bingo

[dannyf]

@30Mhz ?

That's a different question from whether you can toggle a pin on a single cycle.

Yupp cascaded 16bits

So?

Why did i know you would say that .....

Because I said it.

[bingo600]

@30Mhz ?

That's a different question from whether you can toggle a pin on a single cycle.

Yupp cascaded 16bits

So?

Why did i know you would say that .....

Because I said it.

Thank you for posting so well thought answers ...
I'm looking forward to the next one.

/Bingo

[senso]

1: It can "single cycle" toggle a gpio pin

Pretty much everyone has them, sometimes even in the 8-bit world.

@30Mhz ?

2: It has a "real" 32bit timer (SCT)

Are there fake 32bit timers?

Yupp cascaded 16bits

3: Arm-GCC has float & double (ie. AVR only has float) , makes some PID or DDS dividerwords easier to calc.

The frequency-to-tuning word conversion can be easily done in integer, with faster speed and better accuracy. The same with PID.

Why did i know you would say that .....

/Bingo

Atxmega at 32Mhz can do a single cycle toggle, and its 8 bits core..

[markr]

One suggestion:

Code: [Select]

LPC_GPIO_PORT->SET0 = 1<<LED3;    // LED output high (Off)
LPC_GPIO_PORT->CLR0 = 1<<LED3;    // LED1 output low (On)
It would be a lot easier to write either a macro or a function that sets / clears pins on a variable (in your case), or a port base (which can be either pointer or a struct).
Something like this would work, for example:

Code: [Select]

#define PIN_SET(port, pins) port->SET0 = (pins) //set pins
#define PIN_CLR(port, pins) port->CLR0 = (pins) //clear pins
In your code, you can do this:

Code: [Select]

#define LED_PORT  LPC_GPIO_PORT (or whatever the struct pointer is)
#define LED1  (1<<7) //led1 on port.7
#define LED2 (1<<1) //led2 on port.1
...
  //set pins
  PIN_SET(LED_PORT, LED1 | LED2); //set led1 + led2
  PIN_CLR(LED_PORT, LED2); //clear led2


I agree with using #defines to simplify code readability and portability. NXP's solution is to use a subroutine (!) to set and clear bits in ports. The routine is a cycle pig, taking 17 cycles and who knows how much memory and stack space. Accessing the port directly took only 2 instructions and 3 clock cycles to toggle the I/O pin (and yes 30MHz cycles!)

Unfortunately ARM structures are defined as blocks with ports sprinkled inside those blocks. LPC_GPIO_PORT is a structure pointing to the bank of all GPIO registers. The '0' in SET0/CLR0 selects the actual port/address. The LPC81x only has 1 GPIO port, but if it had more (such as the LPC11xx) port3 would be set with LPC_GPIO_PORT->SET3 and portability of the #define breaks.

I have not figured out how to get a #define replacement that sets the port number correctly. I've resorted to creating a library of #defines that allow access to all of the ports I'm interested in and then creating a 2nd layer that creates more human friendly naming, based on the use of that port.

This goes against the "ARM" way of things, where the vendor supplies a defined structure that has the same names across all ARM products from all vendors.

Ultimately one needs to decide whether the goal is ARM portable code or typical embedded processor portable code.

-markr

[nctnico]

I never liked the vendor libraries. I have a strong suspicion they have been put together by interns. I usually define pins like this:

Code: [Select]

#define PIN_LED_ERR2 (1<<15)

#define SET_LED_ERR1() FIO0CLR=PIN_LED_ERR1
#define CLR_LED_ERR1() FIO0SET=PIN_LED_ERR1

Where FIO0CLR is defined in <mcu type>.n as:

Code: [Select]

#define FIO0CLR        (*(volatile unsigned long *)(FIO_BASE_ADDR + 0x1C))
The other ports follow a similar scheme. When I need to port code to a different platform the changes are simple.

[westfw]

Accessing the port directly took only 2 instructions and 3 clock cycles to toggle the I/O pin

Really?  Isn't it usually 3 instructions on these RISC architectures?
Load address of peripheral block. (sometimes this takes two instructions.)
Load bit constant.
Store bit to offset[pb].

I've been really unimpressed with a lot of the vendor libraries I've looked at. :-(

[dannyf]

I have not figured out how to get a #define replacement that sets the port number correctly.

Use the glue stick, "##" operator.