Newbie: Which MCU/kit to Start?

Pretty much any one that you can get your hands on. Seriously though you have to decide at what scale you want to work, i.e. do you want an OS on top of your code or not and how fast do you need the thing to run. It sounds like you might be interested in the lower end chips like the Microchip PIC, Atmel AVR, Intel/Phillips/Dallas/etc 805x, TI MSP430, Motorola 68HC etc. I do recommend that you work with several differenct architectures as there are subtle but important differences between them.

Make sure you have an oscilloscope, they are invaluable for debugging. Other stuff like freq. counters, signal generators etc are ok, but you've got to have a scope or you will go insane. ;-)

Microchip PIC's are a good start IMHO. I can't specifically recommend a kit, because I use a cheap programmer that I put together from a kit (Picall) and experiment using solderless breadboards and generic circuit boards from Radio Shack for the more permanant projects. BTW, get an oscilloscope if you don't have on.

In a word, Read. ;-) No kidding, you're going to be doing allot of reading from now on. There are "charts" posted by the manufacturer cross referencing the capabilities of their line of microcontrollers. However, you will be able to accomplish pretty much any thing you need by using one or two processors from each manufacturer. The huge variety available is so that engineers can pick one that saves them a few cents per unit for large volume manufacturing.

Doable and you will have much fun in the process.

It sounds simple enough, but you will find that you may wish to concentrate on simply blinking an LED at first, but you will be able to build upon that to accomplish your desired task.

I highly recommend that you stick with assembly until you are very familiar with the processor you are currently using.

Cool, I don't know what chip comes on that board, but the 16F628 (supercedes 16F84) and 16F876 are very common. People are now jumping on board with some 18F252 and 18F452 types, but I haven't used them yet so I can't offer you any first hand info there. Go to

and get signed up for the piclist. There's a bunch of highly knowledgable (but also somewhat eccentric) list members. You will learn a great deal about embedded electrical engineering.

That's about it. Good luck and enjoy. ;-)

michael

Did you get an ICD2 with it? It would help with debugging. The Demo2 board is pretty good as it has a nice variety of I/O devices to fool with.

I'd go along with Anthony, but not with a PIC. They are quirky. I like the MSP430, tools are free, programmer is US$10 from Olimex, chips are cheap, it's 16 bit, but does 8 bit as well. Not as popular as the PIC, but more like most other micros, so moving from it to , s ay a motorola would be easy. It's biggest advantage over lower end PICs is that all parts have a built in debugger. I'd start with something like the the MSP430F1232, but if you are in the US or Canada Ti are running courses on their new 169 chip right now where for $50 you get an decent EVM, programming tools and a days training. well worth it.

Stay with assembler until you understand the Architecture, then go back to C if you are more comfortable with it.

Cheers

Al

DJ wrote:

Check:

Thanks for the suggestion. I'll experiment with MSP430's.

I was unable to find any info on the EVM/training offer. Can you point me to it?

-- DJ

Thanks, Michael. This is extremely useful.

Something about MCU development is very exciting. It's better than workstation software because you're interacting with the physical world instead of just cybersapce.

-- DJ

Hi DJ,

another nice one to start with would be the MCB900 from Keil ($59 with development package)

, featuring an 89LPC932 microncontroller. The benefit of going with a

51-based micro is that multiple vendors will sell similar devices (with PIC you are tied to one vendor). If you want to be more open for future applications you might want to look at ARM7 devices as well.

Cheers, Schwob

Anotehr alternative if

How true is this, really? My examination of '51 lines is that there are large family differences. Hardware tools intended for one family won't plug-n-play with another because of different programming algorithms and memory technologies. Most "interesting" peripherals are implemented differently amongst different families; the only common denominator is the peripheral set of the original biblical Intel parts.

It's not even uncommon for one vendor to have two different families in one catalog, because of acquisitions. So really there is still a considerable amount of porting effort required. It's not at all the same as a single vendor selling a line of micros with different peripheral sets. There is not even as much commonality across the '51s as you would expect to find in a single vendor's 8-bit line.

I would appreciate reponses on this issue... so correct me if I'm wrong.

I'd say you are both right.

The 80C51 market is very wide indeed, so let's consider some segments :

Generic DIP40/PLCC44/TQFP44 packages : Here you can expect to physically drop in a device from over a dozen vendors, with minimal-to-none startup style code changes. Most candidates now have the FX core PCA, so the common-denominator has moved.

High performance Analog: Here we have Analog Devices, then BurrBrown(TI) and another in Q4. All 3 vendors offer 24 bit ADCs with FLASH 80C52 (turbo) cores. The details and init-code of the ADCs will certainly differ, but all 3 know the others are out there, and that keeps the price/performance ratios honest.

If you go into the fringes, such as 11 pin or 14 pin 80C51's, then yes, they are physically single sourced.

One aspect of NON-C51 uC I have seen bite users over the years, is 'thin families' - where you get either one, (sometimes two) code sizes in a given package. Hit that ceiling, and you have big re-design/re-certify costs.

Zilog are aware of that, when you see their eZ8 offerings.

- jg

Hi Lewin,

what you mention is right however,.... ;-) The much more expensive professional software tools (compiler / debugger) cover the 51-family range. The boards that cost somwhere between $50 and $200 are specific to each implementation, agreed, that's why there are different boards. Generic code running on a

51-device from Intel also runs on Atmel, Philips, Cygnal, Infineon, ST, Sharp, OKI .......... Hardware specific code such as initialization is specific for each device. The bigger your code grows, the more generic code you can reuse.

In a nutshell, there will always be some code changes when switching between different vendors but the reuse within one architecture is SO MUCH morethan switching between different architectures. Using PIC or AVR generates a huge dependency on one company and it is your call wehther you want to do this.

Cheers, Schwob

I understand your point, but I have three counter-arguments:

a) As the amount of "algorithm" code (vs "implementation" - hardware-specific code) grows, it makes progressively more and more sense to move from pure assembly to a HLL such as C. Given that compilers of comparable quality exist for all candidate microcontrollers, the effort of porting across cores can be considerably less than you make out.

b) To generalize broadly, when a vendor discontinues a proprietary component, they generally recommend a substitute and document a migration path to the larger component. Moreover, they usually have an official migration path from small code size micros to larger micros (including devices of different word width). With '51s, once you max out one manufacturer's family tree, you have to jump ship to a different manufacturer, with associated redesign effort and probably no hand-holding from the new vendor. So I argue that using a single broad-range family like PIC or AVR, you have *somewhat* more protection than just "part A out of stock, too bad - redo your design from scratch!"

c) Any "real product" (i.e. something not a hobby product - something with strict reliability criteria and delivery deadlines) is dependent on single vendors anyway, because of the need to lay out a new board, retest, etc. The only exception to this is if you use a totally generic '51 part available from several vendors. But this means using off-chip peripherals and a more complex, inefficient design. Using parts with interesting (=proprietary) on-chip peripherals ties you to a single vendor anyway. This was basically the point I made in my original posting. If you're doing anything really interesting with a '51, you probably have no drop-in replacement for your microcontroller.

By the way, I'm not being argumentative for argument's sake here :) I just finished a chapter of my book where I describe why I chose to use the AVR series, and I am preemptively defending that decision. If it turns out to be an indefensible position, I have a lot of work rewriting ahead of me.

That argument would hold a lot better if the languages called "C" by various vendors of "C compilers" weren't so incompatible with each other on a routine basis. Esp. with the smaller micro families, standardized C syntax and semantics often has to be bent double and tied into a knot to fit the platform, and that'll show through in all but the most carefully written C code. Just take all those 'far', 'code' 'interrupt' and whatsoever other keywords added to the language as an example, and you'll see what I mean. Clever coders will have kept all such platform-isms nicely protected behind some centrally managed preprocessor macros. But not all of them are that clever.

Now to put this straight, I do understand the need for and usefulness of these language additions quite fine. But still, it makes for lots of quite incompatible dialects of C, which can bite a port to a different CPU family almost as badly as it would had you written all the code in assembly in the first place.

This is tied in with tool and training costs. Having to redesign the hardware may be tough, but having to redesign both the hardware *and* the software is certainly going to be even tougher.

That would be a pretty suicidal attitude to be displayed by the new vendor, wouldn't it? They'ld effectively be telling you "no, we don't want whatever money we could make from doing business with people who used to spend their money elsewhere". It sure sounds like it would be a perfect example of suicide by stupid marketing, to me. I'm not saying that this never happens, but I'd be quite surprised if *all* contestants in the given market were to expose that level of silliness at the same time.

Unfortunately this protection only works against individual parts being discontinued by the maker. It won't help if the part maker itself is in danger of being discontinued, which is the *real* danger in single-source chips. You just might end up having to _pour_ funds into the part maker to avoid them going bancrupt. Either through unbearable part price rises, or by directly shunting money to the company in question.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

In article , Lewin A.R.W. Edwards writes

This is not the case.

In the 8 bit area the C is not that portable compared to 32 bit architectures. 8051 has HW BIT addressable memory.

Within the 8051 family the core code is fully portable, usually even when compiled. Which is more than can be said for PIC's.

The other thing is that there are not always comparable compilers for all architectures. There are a wide choice of 51 tools to suit most kinds of development.

Neither PIC or AVR are "broad range". Several 8051 vendors, Atmel, Philips and Infineon for example each have 8051 ranges that are larger than either PIC or AVR. More to the point there are often several popular designs that are implemented by more than one vendor.

If you need more power then there is the 251 (binary compatible) 16 bit version of the 8051 and the Philips XA.

If Part A is out of stock then part B will have the same core and same basic peripheral set. Maybe you might have to redo the module interfacing to a particular peripheral but a lot of the code will not even need to be recompiled.

I have seen a project to move from two different 8051's to a third combining the first two programs. A lot of the code on the new system is the same code, literally, from the first two projects. the conversion was very rapid as all the team new the architecture and the tools.

However with the PIC you need a completely new tool chain when moving from one member of the family to another.

With AVR if they discontinue a part all your tools become redundant and you need new ones the new architecture. If you can get a full set of decent tools.

Not so: Many 8051 are pin compatible and several vendors offer replacement parts and not just for the basic 8051/2 There are even Philips LPC parts that can pin replace PIC's :-)

This is true.. however the speed of redesign when swapping one 8051 type for another in a CAD package is not difficult. Especially as many of the pins will be the same and the peripherals (A/D, CAN, Serial, USB, etc) will have the same external characteristics. They use standard packages as well. Then most of the code will be the same.

I spend a lot of my time with 8051 users who have no problem swapping between 8051 types and vendors.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Hallo Hans-Bernhard,

Point taken, but I still think that it is likely easier to port C than assembly language, in general. (I discount utterly bizarre language variants like Rabbit's "C"; the more I learn, the less I like).

This is all the "implementation" stuff, though, not "algorithm". I would expect to have to change this sort of code in moving amongst processors.

I would call it quite standard :( FAEs have been culled all over the place; engineering support is in general significantly worse now than it was three years ago, and it wasn't great back then. Maybe if you're a big customer, they'll send a better grade of monkey, but certainly not to small customers.

In any case, the level of support you can expect from "vendor B" can't usually be expected to reach the bitfields-in-registers type of level you'd normally get from a vendor guiding you through upgrades within their own product line.

Browsing my favorite manufacturers, I don't find many pre-written app notes for "porting from vendor X to our chips". And that's not really surprising, because those porting guides work backwards, too... Also, what makes more sense - to put your engineering staff to work studying competitors' chips and writing porting guides in the hope of generating customer churn, or concentrating on supporting existing customers in new applications?

That's true. But it's kind of a side issue, since it's a given that we cannot truly second-source drop-in replacements for the parts in question. This whole discussion doesn't apply to jellybean parts.

(Oh - Also, I am not significantly worried that Atmel is about to go out of business :)).

In article , Lewin A.R.W. Edwards writes

It is easier to port C than ASm but of course there are over 500 8051 types that use the same assembly language :)

The algorithm might also be specific. Using fast data or slow data storage.

You are talking to the wrong FAE's then :-)

No? I have found vendors will go to great lengths to help you move to their parts. Of course within the 8051 family they have the advantage that most of the tools will be the same so conversion does not even mean porting code just re selecting the target part..

They tend not to be needed in the 51 family between vendors.

The do this because it is so easy to swap 8051 vendor if you get poor service.

Not so. there are many "drop in" parts in the 51 world. Others only require minor changes to the HW and SW.

Of course not. The have a major line in 8051's :-) A line that they are expanding and a line of 251..... so if you have to ask yourself if Atmel are pushing 8051/251 where does that leave AVR?

They also have ARM and I recall reading somewhere "ARM is the 32-bit

8051" I will have to look out the reference and see who wrote that* :-)

Regards Chris

*Page 19 Para 3 :-)

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

From the UK, I have been told several times by FAEs that a major problem for the distributors is that designs get done in one country, but that manufacturing is done in another. The result is that one distributor puts in the support effort but does not get any recognition for it.

This seems to mean that the quality (and price) of the software supplied with a silicon vendor's EVBs is a critical part of the design-in process. I'm quite happy to part with $99 for an MSP430 EVB, but $5000+ for the Atmel AT91RM9200 EVB is too much of a risk. Does anyone have any experience with the Cogent board?

Stephen

-- Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time

133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: - free VFX Forth downloads

Porting a single "algorithm" I would agree, but porting a whole application accumulates the effort. Personally, I have not seen much cross-core porting actually done in embedded systems. Where cores have been changed, it is normally done at a product-cycle-step.

AVR's are not actually that broad, plus most of the first generation are now tagged 'not for new designs', or pruned. In any given package, there are not many code-options - plenty of cases where a ceiling was hit, and a re-design was needed. Sure, SW porting to the physically larger sibling was relatively easy, but the HW impact was significant.

A chapter comparing the 'code knees' of AVR, C51 and eZ8 cores would be interesting. Code Knee is where a particular opcode limit kicks in, and slower, bulkier code is needed for Data access above that limit.

Thus eZ8 and 8051 have direct memory opcodes (reach 256 Bytes), and DJNZ opcodes. Register frame pointers exist on both 8051 (2 bits) and z8 (8 bits)

- good for fast interrupt context switching. 80C51 features atomic boolean opcodes, and a large 128 byte SFR space. Index registers on AVR are 16 bit, so more opcodes can access > 256 bytes, but they do have to be (re)loaded. ( ..etc.. you get the general idea :)

-jg

When is your book ready Lewin, sounds like a nice present to some friends in competing companies :-)

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB

Are You trying to make a case for buying an IAR compiler for Your next project?

Yes, please send me some ;-)

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB