How do I go about picking an architecture ? My first thoughts suggested Cortex M3 but the more I look into it the less sure I am.
Obviously I don't to go to the trouble of learning a new technology only to find that I've made a bad processor choice (ie nearly end of line). I've spent many hours looking at many websites and have yet to find any high-level stuff on choosing my first ARM device.
If there's one thing wrong with ARM its the almost infinite number of devices
I'm an embedded developer wanting to undertake my first ARM project, so I'm completely new to the ARM architecture. I want a low power device with serial, USB and some ADC channels.
The interesting thing with "the code is generally of higher quality than a novice programmer can generate" is of course that a company that has any form of IT and business strategy should not use novice programmers to develop their products.
And licenses and availability of library sources are normally irrelevant for a student who just has to hand in a solution to an exercise. As long as the teacher allows the use of the library, the student will be home-free.
Dear Ashley: My previous employer was literally braking all records in terms of incompetence, unprofessional attitude and general ignorance. They happen to have a big name AND an ISO 9001 and more. At the same time, these people are making things that can (and do, annually) kill people all over the world...! (no, they don't build weapons)
"the code is generally of higher quality than a novice programmer can generate"
I have no idea how much experience you have of such things, but my experience is somewhat different.
Quite often, examples from chip suppliers should barely be described as examples.
For instance ...
I spent over a year on a project with Dallas code for an 80C400 and used their TCP stack.
After numerous problems taht they could not fix, they finally agreed to let me have a copy of the source code (after signing the obligatory NDAs).
My verdict on their code was not positive. Actually, it was so bad that I had to recommend an immediate stop on the products that included the code.
If I had access to that code at the start, our product may well have been considerably more reliable.
One product we had used some quite expensive commercial libraries.
The implementation of strncmp() was actually a memcmp(), i.e. if the two input strings were identical, and shorter than the max length to compare, the very expensive commercial library considered it ok to continue comparing the strings after the terminating zero, for a very unexpected and random result...
There is one situation where a chip-unique manufacturer library makes sense, and where it may represent a significant amount of development time. That is if you buy a special processor with special additional hardware.
If you need a software modem, it can make sense to buy a special processor with DSP acceleration, and use it with manufacturer-supplied soft-modem code. Your business decision is to get an almost turn-key hw+sw modem that you complement with your own - as much as possibly generic - main logic. Such a concept could save enough money (compared to using separate modem + duplex chips), that you after one year of delivery has saved enough on component costs that you can afford to buy a full years consumption of processors to put on the shelf as buffer in case the processor gets unexpectedly dropped and you need to redesign with a different processor.
If you do buy a chip with hardware acceleration for MP3 decoding, then you have normally already payed the sw license for using the corresponding MP3 decoder library. And you would expect that playing MP3-encoded voice prompts should be so trivial that you can't really get hurt by late bugs in the library.
But these examples are special cases where you directly when you selected the processor made an explicit choice locking your product to a specific sw+hw bundle. You normally don't take such decisions without having a backup plan. You may look at two different sw-modem solutions. Select to design with one solution after having made sure that there are at least one other solution good enough and possible to switch to within a reasonable time frame. And you make the business decision taking into account the amount of chips you may have to keep in a buffer to keep you going during the redesign. And you upfront estimate the redesign cost, the extra cost of warranties for two different designs and the extra certifications needed in case the backup design has to be implemented.
But a big problem with manufacturer-supplied libraries is that manufacturers do not have the best developers in their staff. It can often be (hopefully) good hw engineers that will have to double as sw engineers. And sometimes, it is one or more application engineers.
"My verdict on their code was not positive. "
there are always bad OEM libraries, as there will always be bad programmers, or bad people.
But such facts don't mean all OEM libraries are bad, or all programmers are bad, or all people are bad.
if you don't believe me, take a look at Luminary's Stellaris and let me know if you think you can do better consistently.
almost 10 years ago I was working for a startup company on a VOIP phone. we used a commercial TCP/IP stack which was riddled with a huge number of bugs. We could only help the manufacturer by actually having the source code and a lot of willingness to debug and dig up their trash...
I don't know why, but whenever someone mentions problems with a TCP/IP stack, I start to think about InterNiche. 10 years should be about the right time frame too ;)