Agreed, the TI Launchpads are pretty good, as are the various NXP LPC boards. For both, the respective development tools are free.
(I have 20 years' experience in PICs, and have moved from PICs to ARM in the past six months or so. This was after Microchip launched their PIC32MZ which was promising if you read the marketing stuff from the launch a year ago, but the silicon was very late, and it under-delivered as the silicon still has tons of bugs. To add insult to injury, Microchip were forcing the developers to learn a brand new, and very buggy programming paradigm anyway to use the new chips (Harmony), so I took the decision that if I was going to have to learn something as fundamental as that, I might as well try something that was more mature.)
TI has a restriction on the hardware debugger you can use, it has to be either an XDS100 or a debugger integrated onto the dev board, and NXP simply have a 256KB code limit, both are $495 to unlock. So, you can do an awful lot with both without having to make a big investment.
I found that the biggest problem with ARM is knowing which one to choose, you need to spend a bit of time just investigating the different ARM levels. Unless you're already really into microcontrollers in a big way, I would seriously recommend go for the low end devices first. The complexity of the chips and peripherals at the upper end makes it really hard to get started much beyond running example code. As soon as you want to do anything serious, you need to start opening the startup, chip and board code for your own use, and learn the chip. The LPC43xx series, for example, are enormously complex, just the clocking scheme will take many hours to master. Some of the peripherals on the higher end LPC devices are truly complex, the good news being that peripherals like the State Configurable Timer and the Serial GPIO can replace CPLD functions, but boy are they a bitch to fathom out.
Between TI and NXP, the TI development environment feels more polished, both are based on Eclipse. Both have bolted on stuff to the base Eclipse environment, the NXP stuff feels a bit more flaky when debugging, but with TI's CCS you need to thoroughly understand the way the file link process works to get much beyond compiling and running the sample code.
Although the customisations of the Eclipse UI gets you started quickly on their dev boards, as soon as you want to do anything with your own hardware you need to unpeel the thick veneer they've added, and understand how it hangs together, so you can create a project from scratch. Once you've removed the lipstick, you get to really understand what's going on, but it is time consuming.
One final thing, although it seems to come with the turf these days, the dev environments are being continually updated, m maybe once every month or two. The frustrating thing is that sometimes this breaks things, I had this when updating from CCS 6.0.0 to 6.0.1, and it can take a while to figure out not least because of the makeup they've added that somewhat obfuscates what's going on under the hood.
Edit to add something about the documentation...
The documentation is a minefield, but that goes for every chip manufacturer these days. Firstly it's the sheer volume, both in PDF and in various online sources like wikis. Some of it, particularly the wikis, can be pretty low quality, leaving you with more questions than answers. NXP tend to have a smaller number of documents, but their documents are large and lack descriptive diagrams, favouring millions of tables instead. TI on the other hand have tons of documents, generally individually of good quality, but it leaves you scratching your head as to where to start. I also absolutely hate the naming conventions used for PDF documents these days, a series of seemingly random characters. Would it be so hard to add some kind of descriptive title within the filename too?!
Home
Help
Search
Login
Register
