SparkFun Forums

[sparky0253]

I am interested in using a NXP LPC1343 as they are really low cost and cheaper than a PIC. I need a dev board and the 2 I have found so far are from Hitex and IAR. Does anyone know of any others? My usual supplier for dev boards is Olimex but there is no LPC1343 availible (yet?). The IAR board and schematics look suspiciously like they came from Olimex (like most IAR boards). Does anybody have any other suggestions.

Thanks

[leon_heller]

Design your own with exactly the features you need?

Leon

[jsiei97]

My usual supplier for dev boards is Olimex but there is no LPC1343 availible (yet?).
Thanks

I'm curious, are not LPC1343 a Cortex-M3 based mcu.
Any reason not to use another Cortex-M3 mcu like the stm32,
that Olimex is using...?

They have a card called stm32_h103 that has the stm32

BR
Johan

[stevech]

The NXP (founded by Philips) LPC1343 is an ARM 32-bit Cortex-M3 Microcontroller with MPU, CPU clock up to 72MHz, 32kB on-chip Flash ROM with In-System Programming (ISP) and In-Application Programming (IAP), 8kB SRAM, USB 2.0 Full-speed Device Controller with On-chip PHY, Nested Vectored Interrupt Controller, AHB Matrix, APB, UART with full Modem Interface and RS485 Support, SSP, I2C, 10-bit ADC with 8 channels, High-current Output Driver (20mA) on One Pin, High-current Sink Drivers (20mA) on Two I2C Pins, Four Timers with capture/compare, Watchdog Timer, System Tick Timer, Power-On Reset, Power Management Unit, Crystal oscillator, 12MHz internal RC oscillator, PLL, JTAG and Serial Wire Debug/Trace Port with ETM, Up to 42 General purpose I/O pins.

And, it doesn't have the dreaded dual address space flash/RAM making compilers a PITA.

[sparky0253]

Reason for using the LPC1343 is the cost. We need a very very very low cost USB-SPI bridge and the LPC1343 comes in at sub $1. I don't think the STM offering can beat this on price.

[millwood]

And, it doesn't have the dreaded dual address space flash/RAM making compilers a PITA.

unless you are writing the compiler, why should you care about that?

[stevech]

And, it doesn't have the dreaded dual address space flash/RAM making compilers a PITA.

unless you are writing the compiler, why should you care about that?

I am an AVR fan. Having been through the PIC's small segment paging memory mess and graduated. I do offer this, in context of this thread...

Writing C code for AVR/PIC is a PITA where one puts strings and other constants in Flash so they don't use RAM at run-time. This leads to the need for two kinds of pointers, and two forms of many C library routines. Example, we all know:

Code: Select all

printf("The value of n is %d\n\r", n)

is used in all single-address processors. If used in a dual address Harvard processor, the quoted string constant is stored in both flash and copied to RAM during initialization prior to main(). There it sits, using up RAM for a constant that's also in flash.

So GCC's solution is

Code: Select all

printf_P(PSTR("The value of n is %d\n\r"), n)

where printf_P is a twin of printf, to access the string constant from flash
and
PSTR() is a macro that causes the string to live in flash and not be copied to RAM by the initialization.

And so on for many other library routines. And macros to declare numeric constants to be flash-only. This gets complicated and impossible, with GCC, for, say, an array of pointers to flash-resident strings. I don't think GCC can do such due to use of macros rather than in-built. Otherwise, GCC does a great job on the AVR and has been a boon to many students.

Commercial compilers for the AVR (and I suppose, PIC), add to the compiler in-built solutions for this that eliminate PSTR() and the like, and make the code more standard and portable.

The scheme in the ARM7, for example, is to have flash and RAM, in a single address space (von Neuman). The processor accesses flash differently than RAM, e.g., since flash is slower, NXP and others do a very wide single-read from flash and reconstitute it as instruction-width data. This keeps the pipe full. Being von Neuman, the ARMs can, for debugging, execute code out of RAM.

No doubt, if one is doing development for a volume product, none of this matters since the non-recurring-engineering cost is often of low importance, and code portability is not sorely needed.

[millwood]

Example, we all know:

so? how about a simple solution if you care that much about it: structure your code so that you don't declare vast quantities of strings in main().

is that so difficult to do that you have to abandon an entire platform / architecture or to worry about writing your compiler?

if that's the case, you have many far more pressing issues to worry about, .

[mpanetta]

Example, we all know:

so? how about a simple solution if you care that much about it: structure your code so that you don't declare vast quantities of strings in main().

is that so difficult to do that you have to abandon an entire platform / architecture or to worry about writing your compiler?

if that's the case, you have many far more pressing issues to worry about, .

You don't seem to understand. It does not matter *WHERE* in the code the strings are declared, they still have to go somewhere. Even if you declare them in a header somewhere they will still be copied to RAM unless you use the PSTR macro (I avoid PIC's like the plague, so I do not know how strings are default allocated on them).

As for abandoning an architecture, I highly doubt that is a reason for anyone to do it. I personally would abandon both PIC's and AVR's because the Cortex-M3's completely KILL them in terms of both performance AND power usage, and now, PRICE. THAT is the reason to abandon them.

I don't understand why people keep propping up the PIC processors when clearly they are the looser in all but the smallest of applications. There are other processors out there that are much better because:

• They are easier to program (no insane bank switching nonsense).
  
  They are faster (no ancient 4 clock per instruction architecture).
  
  They are lower power (ARM processors were designed from the start to be low power, Cortex-M3 doubly so, and they can do much more work in the same amount of time than a PIC or AVR, so by default are lower power because they can spend more time sleeping in a low power state).
  
  And sometimes the most important, CHEAPER!

I guess I just don't understand what I see as blind evangelism, and why people are doing it...

[gussy]

Design your own with exactly the features you need?

Leon

If everyone did that SparkFun would be out of business

[cfb]

I am interested in using a NXP LPC1343 as they are really low cost and cheaper than a PIC. I need a dev board and the 2 I have found so far are from Hitex and IAR. Does anyone know of any others?

Embedded Artists have announced that their LPC1343 'LPCXpresso' board should be available next month:

http://www.embeddedartists.com/products ... 43_xpr.php

[gussy]

Here's a good place to keep your eye on:

http://www.microbuilder.eu/Projects/LPC ... esign.aspx

[ktownsend]

gussy:

Hey ... you beat me to it. I'm currently working on a 1343 dev board ... I sent off for a few prototype PCBs this week and should get them back in around 10 days time. Once I can confirm that the design is sound, I'll publish a final schematic. I already have a working LPC1114 board (Cortex M0), but since it's pin compatible with the LPC1343 I'm not expecting any surprises.

Aside from the main project page:

http://www.microbuilder.eu/Projects/LPC ... esign.aspx

There's a recent blog post on this board. A feature that's totally flying under the radar is the built in USB bootloader. In addition to the normal UART based ISP, you can now get the 1343 to enumerate as a USB Mass Storage device and just drag and drop you're compiled binary to update the device. Easy as pie.

[ktownsend]

Sorry ... forgot the link for the blog post:

http://www.microbuilder.eu/Blog/09-12-1 ... esign.aspx

[ktownsend]

I am interested in using a NXP LPC1343 as they are really low cost and cheaper than a PIC. I need a dev board and the 2 I have found so far are from Hitex and IAR. Does anyone know of any others?

Embedded Artists have announced that their LPC1343 'LPCXpresso' board should be available next month:

http://www.embeddedartists.com/products ... 43_xpr.php

I've got one and their nice, certainly for the price. (I think you can buy them off Digikey now?). The best part is that they have an ARM9 SWD hardware debugger that you can cut off and use with any other board supported by the LPCXpresso IDE (a 128KB limited version of Code Red's Red Suite). I honestly think that brings the cost of entry for serious ARM development about as low as it's ever been (the debugger, board, plus the IDE)!