They are part of TI now. I think the NXP parts are much faster.
Leon
Yes, I did not mention the LM parts because the fastest chips are 80Mhz and the main chips are 50Mhz. I don’t see anything faster than that. Since these are all CM3 core, the MIPS/Mhz should be identical, so core speed is your deciding factor.
Personally I’ll be pleased to try something else other than the LM chips once I get a SWD debugger and can try the NXP offerings.
I’m pretty set on the LPC1756 for my project. I will probably flash it with the USB-Bootloader and then I will have all 4 UARTs available, very neat.
Have anyone tried the new JTAG-programmer from Olimex/IAR? It’s supposed to be able to debug everything supported by IAR in their codespy or whatever it’s called. I bit pricey at about 100 euros, but still a lot cheap than the “commercial” stuff.
monstrum:
I’m pretty set on the LPC1756 for my project. I will probably flash it with the USB-Bootloader and then I will have all 4 UARTs available, very neat.Have anyone tried the new JTAG-programmer from Olimex/IAR? It’s supposed to be able to debug everything supported by IAR in their codespy or whatever it’s called. I bit pricey at about 100 euros, but still a lot cheap than the “commercial” stuff.
In IAR, I have used the “flash breakpoints” so much for so long, free since I bought J-Link & IAR together - I would not like to lose that. Does this Olimex JTAG do so? I think flash breakpoints is sort of unique to Segger
Doesn’t say anything about flash breakpoints.
“ARM-JTAG-EW emulates on low level the IAR Systems’ J-LINK API so it works like normal J-LINK debugger, but add some unique features which are available only in the very high end and expensive debugger tools”
http://olimex.com/dev/arm-jtag-ew.html
I’m curious though. How does a “flash breakpoint” differ from a normal hardware breakpoint?[/quote]
Code in flash memory can’t be changed by the debugger to insert a software breakpoint, so it’s moved into RAM, a breakpoint is added, and the code is executed there. I don’t know how the Segger does it.
Leon
Hello Leon,
The Segger J-Link with flash breakpoint option is able to write breakpoints into the internal flash memory. Depending on the situation the flash breakpoints can also be simulated or emulated. Emulation is done by moving the code like you described, simulation directly manipulates registers to have the same effect as the underlying piece of code. Which measure is taken to set the breakpoint depends on several factors.
Best regards,
Dirk
Thanks. I thought it must do something clever like that.
Leon
I thought the debugger told the MCU to halt when it reached a specified address.
leon_heller:
Code in flash memory can’t be changed by the debugger to insert a software breakpoint, so it’s moved into RAM, a breakpoint is added, and the code is executed there. I don’t know how the Segger does it.Leon
I think Segger/J-Link does flash breakpoints as follows, not sure. When you run or continue execution on the ARM, the software automatically alters any flash sectors that have deleted or new breakpoints. It alters by storing some sort of trap instruction in the flash. That way, you can have any number of breakpoints, not need lots of RAM nor a different linker config when debugging. J-Link also allows one to single step - maybe that’s done in hardware.
I’ve been developing on several LPC2106 and 2129 boards for maybe 1-1/2 years like this, debugging and re-downloading willy-nilly without any flash failures. Probably thousands by now. I know that I might wear out the flash someday, but the boards are cheap enough compared to my salary.
Hardware breakpoints rely on the logic on the microprocessor. Like 4 or so breakpoints.
monstrum:
Unfortunately I think the 32 kB flash would be a little short. But the LPC17xx seems to be very good, in spite off the lack of current OpenOCD support. At least I will be able to flash the devices using FlashMagic and the UART, so migration will be quite swift in terms of hardware.
So, Why not NXP LPC1758? Or LPC1759 if ethernet isn’t important…
I will probably use LPC1758. Seems to be the best general purpose CM3-device on market right now, performance wise.
I agree. I've been a fan of Luminary Micro parts for years but am thinking of switching to the LPC17xx series because the low to medium end Luminary parts seem to have stagnated at 50MHz for quite some time now.monstrum:
I will probably use LPC1758. Seems to be the best general purpose CM3-device on market right now, performance wise.
SodaAnt:
I agree. I’ve been a fan of Luminary Micro parts for years but am thinking of switching to the LPC17xx series because the low to medium end Luminary parts seem to have stagnated at 50MHz for quite some time now.
Not to mention that luminary seems to have stopped releasing new parts since TI purchased them. The last batch of new parts is still showing as “Sampling to lead customers” and have been for over a year now it seems. The last batch of new parts before that came out and were made available in no time.
I hope luminary isn’t being killed off by their success. 
I’ve had my LPC1114 and LPC1313 chips sitting here for a while, just waiting for Rowley to release their SWD adapter. I noticed Crossworks 2.0.5 was released and lists FT2232 devices now support SWD and you can select SWD from the connection properties, but there’s no more details than that. I’ll be real interested in seeing what this adapter is about.
Hopefully its temporary M&A Paralysis.Not to mention that luminary seems to have stopped releasing new parts since TI purchased them. (
Too often, Big, Inc. acquires Entrepreneurship, Inc. which disappears into a black hole.
stevech:
Hopefully its temporary M&A Paralysis.Not to mention that luminary seems to have stopped releasing new parts since TI purchased them. (
Too often, Big, Inc. acquires Entrepreneurship, Inc. which disappears into a black hole.
I wonder if it’s something to do with fab switchover? Luminary was fabless, TI has its own fabs. Maybe they are changing things over to use TI’s fabs and it is just going slow??
Ok, OP here again. I am still quite set on the Cortex M3, and LPC1756 in particular. What it falls on now is debug-compatibility with tools that don’t cost an arm (no pun intended) and/or a leg.
Maybe OpenOCD will support it, but I’m not so convinced it will be any good (from my experience with the SAM7 + OpenOCD + Eclipse).
What I’m actually considering now is PIC32 or AVR32. I’ve used the 8-bit AVR’s a lot and I find WinAVR and AVR Studio quite nice.
I have no experience with PIC’s but I’ve heard that MPLAB is based on GCC so I’m sure it will do fine. Debugging should be possible with the 40-buck official programmer and that’s great.
I’m not looking for another PIC vs AVR battle here. But if I must decide between the two (32-bit) which one would be better for my purpose.
I do 10% digital filtering and a lot of matrix/vector multiplications. A DSP would appear to be the better choice, I know, but that’s not an option due to other reasons.
MPLAB is the IDE, the PIC32 compiler is based on gcc. Microchip has extensive free libraries for DSP and other functions like matrix operations, and several cheap evaluation boards. The low-cost PICkit 3 debugger/programmer supports the PIC32.
Microchip has really risen in my eyes since their introduction of PIC32. I wouldn’t really touch one of the 8-bit PIC’s.
What really make me lean over towards the PIC32 is that it seems I won’t have to struggle for a week getting a simple program to run (like with a certain ARM7 with linker and startup scripts and nightmares).
Does anyone have the current status on WinAVR and support for AVR32. Is it a painless experience to set it up, and what do I need to do debugging?