help. leaving pic for arm... but which arm????

[tipofthesowrd]

I was looking at the PE universal multilink, I would not call that a production programmer imo. but its good to know you dont need one for programming and in circuit debugging then

I have some mixed experiences with the PE multilink. It won't work on my new PC due to USB incompatibilities (PE can't or won't fix). One of the things I hate about Freescale's microcontrollers is that they rely on exotic debugging/programming hardware so you are screwed when it doesn't work for some reason.

Hmm, can't say I've tried the PEMicro stuff. Recently I've been hanging around the Freescale forums and some of the unofficial app notes from the Freescale people you'll see they're also using the mbed firmware on the freedom board as a general programmer/debugger in combination with the Kinetis SDK and Kinetis IDE. Might be they also got tired of it.

[funkathustra]

The PE Micro stuff is crap. They've largely been eclipsed by CMSIS-DAP and J-Link firmware on the FRDM boards.

Since we're on the subject of Freescale ARM chips, did anyone else notice how ridiculously cheap Freescale started selling the MK02 for?

A buck sixty-nine will buy you single quantities of a 100 MHz Cortex-M4F MCU with 64K of flash, infamous Freescale analog (twelve 16-bit ADC channels, two comparators with optional 6-bit DAC reference, 12-bit stand-alone DAC), 6 channels of 16-bit PWM, and decent connectivity for a 32-pin part (two UARTs, 1 SPI, 1 i2C).

And people wonder why I crack up when they tell me what they spend on those ridiculous AVR chips.

[tipofthesowrd]

A buck sixty-nine will buy you single quantities of a 100 MHz Cortex-M4F MCU with 64K of flash, infamous Freescale analog (twelve 16-bit ADC channels, two comparators with optional 6-bit DAC reference, 12-bit stand-alone DAC), 6 channels of 16-bit PWM, and decent connectivity for a 32-pin part (two UARTs, 1 SPI, 1 i2C).

Exactly the reason why I switched to Freescale ARM for some customer projects.
Though, fair bit of warning the official Freescale forums are a PITA to use.
For Freescale parts there is a huge amount of information on the http://mcuoneclipse.com/ website by Erich Styger

[jnz]

FWIW, while we're on the topic of programmer/debuggers... My JLink Ultra has been very very good.

Bit of a learning curve with Debug ITM (printf over the SWO wire) and Keil but that's really more an issue with Keil. Other than that, I think they have a cheap Jlink that I could recommend for sure.

[exapod]

I also reccomend the freescale MCUs. When i was starting i bought two freedom board ( one with a M0+ and one with an M4 ) and basically tried every peripheral and configuration available.
Now i don't want to start a war but in some application i find the pics easier to use and the best choice (maybe because i used them for a lot of time). The reference manual for one arm family is something like 800 pages so the learning curve will be a lot more steep than with pics where for the 8 bit family you configure 5-6 registers and you are good.
One big plus for me is that freescale has a free and supported IDE for their series of arm mcus with no code restriction and also sends free samples.

[sswift]

Avoiding teensy because the bootloader chip isn't open source is about like avoiding all those atmel chips because the JTAG ice 3 code isn't open source...  The teensy bootloader chip isn't required in a production design; there are plenty of other ways to get your code into the chip.

Not if you wish to allow your end users to be able to upgrade their firmware. 

With the Teensy if you don't have that chip, they'll need a programming device. With the Neutrino the end user only need a USB cable and the appropriate software to program it.

Even if Paul were giving away the firmware for those mini54tan chips, the chips would still add a couple bucks to your BOM.  And they're hard to find; I just did a quick search of Digikey and Mouser and neither carry them, and a search on Octopart and Oemstrade only shows one distributor with any significant stock.

[Yansi]

...and basically tried every peripheral and configuration available....

The Freescale MCUs must be therefore simple as bite... I'd like too see you doing this on some beefy STM32.   

[exapod]

...and basically tried every peripheral and configuration available....

The Freescale MCUs must be therefore simple as bite... I'd like too see you doing this on some beefy STM32.   

With enough free time everything is possible...

[zapta]

With the Teensy if you don't have that chip, they'll need a programming device. With the Neutrino the end user only need a USB cable and the appropriate software to program it.

And with the ARM PRO MINI you don't even need software to program it, even not the first time, just a file drag with the mouse.

[Sal Ammoniac]

IAR is very good, but (at least last time I looked) had a huge cost jump from the 32K free version to the first non-free version - about $3K I think

Let me put in a plug here for Rowley CrossWorks for ARM. If you're a hobbyist and using it non-commercially, there is a personal license available for $150.

I've been using it for around five years and it works with JLink, STLink-v2, LPC-Link2. It's fast and has no code space limitations.

[zapta]

Let me put in a plug here for Rowley CrossWorks for ARM. If you're a hobbyist and using it non-commercially, there is a personal license available for $150.

Dues it run on Mac OSX?

Also, can I develop  with it open source projects that others can compile with the free ARM tool chain?

(I am currently using lpcxpresso which is yes for the two points but wouldn't mind to switch.)

[jnz]

Yea, iirc, Rowley works in OSX.

I tried Rowley, and liked some of it, a lot. But it wasn't going to work for me. I pretty much had to spend lots of money somewhere either at Segger, Keil, IAR, other, and chose Keil. uV5 isn't terribly high end in terms of IDE, but it was well and hasn't crashed or done anything dumb yet.  I crashed Rowley twice in two days, but I don't really hold that against them.

Someone mentioned to me Rowley was great for Hobbiest that wants a full IDE and for some reason doesn't want mbed. And someone like a professional hardware guy who wants to confirm designs.

If I was the later or just worked mail with hardware I'd go with Rowley over Keil, but since I do more software, RTOS, production firmware etc, Keil was the better choice for me. I know one thing for sure, setting up a custom toolchain was NOT the right move and I'm glad we skipped that potential mess.

[BloodyCactus]

going to order a FRDM-K64F dev board from mouser and a couple of MK02FN64VLH10 chips and a segger jlink and see how I go at making my own little dev board with swd

[Brutte]

going to order a FRDM-K64F dev board..  and a segger jlink

FRDM already comes with a debugger. External targets are supported (SWD).
I would not start from making a custom LQFP board. These are not 4MHz PIC8s, you know.

[BloodyCactus]

going to order a FRDM-K64F dev board..  and a segger jlink

FRDM already comes with a debugger. External targets are supported (SWD).
I would not start from making a custom LQFP board. These are not 4MHz PIC8s, you know.

thats part of the learning processes. why wouldnt I make a custom lqfp board? in this regard its no different from a pic32. drop a 16-20mhz crystal and expose the pins to a header, make my own dev board. its what Ill be doing with it with my projects anyway when i make a board with it on.

[sswift]

And with the ARM PRO MINI you don't even need software to program it, even not the first time, just a file drag with the mouse.

So... it looks like a USB stick to the PC?  That's clever. 

I might have to borrow that. idea.  Not for the Neutrino; that's staying compatible with the Arduino toolchain and finding the bin files after you compile would be more of a pain than just hitting upload, but I plan to design other boards that I want the end user to be able to update the firmware of.  Right now I do that by having them drop files on an SD card.  But that's on boards using the Atmega, and I really wanted to make things simpler now that I have a USB port to play with. 

I was considering supporting USB sticks, but making the board itself appear as one so they can just drop the firmware update onto it would be even better. 

Well, actually... having both would be ideal in case you can't get the device near a PC to connect a USB cable.     

[tipofthesowrd]

Mbed works the same wat, as does the lpc1768 USB bootloader...

[zapta]

So... it looks like a USB stick to the PC?  That's clever. 

I might have to borrow that. idea.

Look for NXP MCU's that have USB ISP.  These MCUs come stock with bootloader that support both serial and USB bootloading. The bootloader is not part of the user's writeable flash so you cannot overwrite it. When you reset it in ISP mode, they mount themselves as a flash disk and have a single file called firmware.ben. You overwrite that file with the new firmware (the name of the new file doesn't matter)  and the flash get updated. This is done at USB speed and takes a fraction of a second. In the arm pro mini I added a 'or' function to allow entering the ISP mode with a single button click (see schematic below).  When I program it with lpcxpresso I added to the build a shell script that does the file copying so I build and download in a single operation. It's a very handy bootloader.

https://github.com/zapta/arm/blob/master/pro-mini/board/arm-pro-mini-schematic.pdf

[jnz]

So... it looks like a USB stick to the PC?  That's clever. 

I might have to borrow that. idea.

Look for NXP MCU's that have USB ISP.  These MCUs come stock with bootloader that support both serial and USB bootloading. The bootloader is not part of the user's writeable flash so you cannot overwrite it. When you reset it in ISP mode, they mount themselves as a flash disk and have a single file called firmware.ben. You overwrite that file with the new firmware (the name of the new file doesn't matter)  and the flash get updated. This is done at USB speed and takes a fraction of a second. In the arm pro mini I added a 'or' function to allow entering the ISP mode with a single button click (see schematic below).  When I program it with lpcxpresso I added to the build a shell script that does the file copying so I build and download in a single operation. It's a very handy bootloader.

https://github.com/zapta/arm/blob/master/pro-mini/board/arm-pro-mini-schematic.pdf

ST has some sort of bootloader mode as well. It's on the parts I have, just haven't looked into it yet.

I like the idea for prototyping, but I'm not 100% crazy about it from a security standpoint in production parts. I'm sure it's fine, it's just that my initial reaction is I Should Be Concerned About This. What is to prevent someone from resetting the module into that mode and writing their own firmware for your hardware?

[zapta]

I like the idea for prototyping, but I'm not 100% crazy about it from a security standpoint in production parts. I'm sure it's fine, it's just that my initial reaction is I Should Be Concerned About This. What is to prevent someone from resetting the module into that mode and writing their own firmware for your hardware?

These devices have several protection modes.  I never used them.

[Sal Ammoniac]

What is to prevent someone from resetting the module into that mode and writing their own firmware for your hardware?

Why do you care about this? If they've bought your hardware, why would you care if they wrote their own firmware for it?

[mikeselectricstuff]

What is to prevent someone from resetting the module into that mode and writing their own firmware for your hardware?

Why do you care about this? If they've bought your hardware, why would you care if they wrote their own firmware for it?

Support/warranty issues?

[nctnico]

What is to prevent someone from resetting the module into that mode and writing their own firmware for your hardware?

There are firmware protection mechanisms in the LPC series from NXP. Nothing complex or requiring proprietary hardware. Just make sure a 'magic number' is at a certain address and it will protect the firmware (see the user manual). AFAIK the NXP Cortex series have various levels varying from disabling read to disabling flash erase/program through the bootloader entirely.

[Sal Ammoniac]

What is to prevent someone from resetting the module into that mode and writing their own firmware for your hardware?

Why do you care about this? If they've bought your hardware, why would you care if they wrote their own firmware for it?

Support/warranty issues?

Simple--just disclaim the warranty if someone writes their own firmware, but don't go out of your way to make it difficult for someone to write their own.

Linksys doesn't seem to mind people loading non-factory firmware on WRT routers.

[Tandy]

I guess the firmware issue depends a lot on the price and function of your product. If someone destroys their $30 router they probably won't try and send it back. On the other hand if it was some $200 box they might take it back to the retailer and claim it has a fault. Retailers don't have rigorous checks on returns, you are lucky if they try turning it on to see if the claims of not working are true. I am kind of divided on the issue because on the one hand I think if you buy something it should be yours to do what you like with including mess with the firmware. On the other hand manufacturers are expected to provide a warranty, but that shouldn't include problems caused by people futzing about with the innards.

Personally I think a step such as having to desolder a link or something helps limit the number of clueless people downloading random firmware off the internet and bricking their product. It also means that there is a way to identify when someone has been tinkering with the innards.