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
Design your own with exactly the features you need?
Leon
sparky0253:
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
And, it doesn't have the dreaded dual address space flash/RAM making compilers a PITA.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.
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.
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?
millwood:
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:
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
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.
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, :).
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, :).
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 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!
leon_heller:
Design your own with exactly the features you need?Leon
If everyone did that SparkFun would be out of business 
Embedded Artists have announced that their LPC1343 'LPCXpresso' board should be available next month: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?
Here’s a good place to keep your eye on:
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.
Sorry … forgot the link for the blog post:
cfb:
Embedded Artists have announced that their LPC1343 'LPCXpresso' board should be available next month: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?
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)!
I’d like to use the STM32 or the LPC1xxx over the Luminary Micro, but a 64K flash LM3s8xx series are < $4 on Newark for single quantities and the others are both significantly more expensive for 64k or 32k chips. The two things I don’t like about the LM chips is the lack of USB support except for on the much higher end more expensive chips (many that aren’t kept in stock) and I know I harp on this, but 8bit ports on a 32bit micro make absolutely no sense. I have no idea why they decided that, but dividing interfaces up among the 8pin ports is much more annoying than I thought it would be.
no insane bank switching nonsense
if bank switching can drive you insane, your problem is much bigger than bank switching.
ktownsend:
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)!
I wonder if you can use the SWD debugger with something like a STM32 and OpenOCD??
SWD hardware debuggers seem to be a bit thin on the ground at the moment.
gussy:
I wonder if you can use the SWD debugger with something like a STM32 and OpenOCD?? SWD hardware debuggers seem to be a bit thin on the ground at the moment.
Even if you could figure out how to use the LPC-Link outside Code Red/LPCXpresso (the SWD/JTAG debugger on the LPCXpresso boards), OpenOCD doesn’t support SWD (alas). I’m not sure what the current status is on that since I don’t use it myself, but I’m guessing it will take some time before we see low-cost 3rd party debuggers and open source software for SWD. As far as I know, only the Keil uLink (which is tied to uVision) and the Segger J-Link for ARM currently support it. I’d definately recommend the Segger device since it at least works with most IDEs (Keil, IAR, Crossworks and OpenOCD [in JTAG mode]). If you’re not doing commercial work, Segger offers a decent non-commercial price, but it’s still going to be more than an ARM-USB-TINY or ARM-USB-OCD.
It’s a shame, since I think this is going to be the main issue that slows uptake of the new Cortex cores with hobbyists, and I can’t imagine it being resolved in the immediate future (<6 months?). It’s definately above my pay grade to make an SWD debugger and the accompanying software/firmware, much as I"d like to be able to.
While the USB bootloader on the 1343 is nice, you’re really going to be stuck with LPCXpresso if you want something under $100 for debugging and stepping through the code line by line. I’m a big fan of Crossworks, but I’ll probably start publishing some examples in LPCXpresso simply because it’s the platform that makes the most sense for the moment, and the code is at least still GCC compatible.
It would be nice if just the JTAG portion of the LPC-Link worked with OpenOCD.
At $29.99 from Digikey that would make it by far the cheapest ARM hardware debugger around.