Which uController to learn?

[Tim Wescott]

PIC is king, I'm sure. But I'd like to hear from those who are using all
brands. Whichever you use, what do you like about it? What don't you like
about others? Suggestions re. learning?

I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
BASIC; COBOL if forced to admit it), so no stranger to programming, per se.

After you've selected your second or third new microprocessor and made
it work you'll realize that time spent learning the quirks of a new
processor is less than time spent working around the deficiencies of an
old one.

For each new application I look at what the application demands, which
usually boils down to processor speed, peripherals, the available pin
drive power, and the capabilities of the on-board EEPROM and flash.
Then if one of the micros that I'm already familiar with works I use it
-- otherwise I select a new one.

I will mention that for most microprocessors the verb is "use", but for
PIC it's "suck it up and use" -- Microchip does a sterling job with
peripherals, pin drive and features, but gawd I hate their architecture.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[John E.]

I will mention that for most microprocessors the verb is "use", but for

PIC it's "suck it up and use" -- Microchip does a sterling job with
peripherals, pin drive and features, but gawd I hate their architecture.

There's a pattern developing in this thread...

 

[John E.]

I will mention that for most microprocessors the verb is "use", but for

PIC it's "suck it up and use" -- Microchip does a sterling job with
peripherals, pin drive and features, but gawd I hate their architecture.

Which just *begs* the question: whose architecture do you consider to be the
antithesis of the PIC's? (ie, less obtuse, resulting in your being more
productive?)

 

[Tim Wescott]

Which just *begs* the question: whose architecture do you consider to be the
antithesis of the PIC's? (ie, less obtuse, resulting in your being more
productive?)

Almost anything but an 8051?

Actually, just about anything that has a stack-oriented architecture, or
a register-oriented architecture with an orthogonal instruction set and
decent indexing. If I can, with confidence, slam a bunch of parameters
onto the stack or into some registers and call a function without worry,
then I'm happy.

The PIC (and the 8051, and some others) are so poor at stack usage and
pointer manipulation that unless one wants severely inefficient code one
pretty much has to define all the program data as a bunch of globals.
If you try to make your life more efficient by programming in C, you'll
find that the C compilers for the PIC and 8051 give you a choice between
something that isn't quite C, or C code that's _really_, _really_
inefficient. If you want to write assembly using C calling conventions
-- well, find another processor, because you can't.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[John E.]

Actually, just about anything that has a stack-oriented architecture, or

a register-oriented architecture with an orthogonal instruction set and
decent indexing.

Being a beginner in all this, I have no experience / reference to be able to
put product names to these capabilities. Would you "name names" please? I'll
create a diversion to take all the flames while you do that... (c:

 

[Anthony Fremont]

There's a pattern developing in this thread...

Yes there certainly is. You've discovered the pic haters, welcome to my
world. ;-) Once you learn to use several different archetectures, you'll
see that they all suck in one way or another. 8052's are dumb in how they
deal with internal/external storage and also their "output" vs "input"
methods suck too because they don't have true directional i/o pins. AVRs,
TI MSP430 and the rest all have their problems too whether it be an
inabillity to supply drive current to a part or some other deficiency. They
all have trade-offs. What you're seeing here is an unfair attack on PICs
that seems to be made mostly by people that have hardly (if ever) used one,
Tim excluded. As you said, PIC is king and it is for a reason, they work.

 

[TT_Man]

Being a beginner in all this, I have no experience / reference to be able
to
put product names to these capabilities. Would you "name names" please?
I'll
create a diversion to take all the flames while you do that... (c:

I thought 51's had a decent stack and register structure. I've used them
since 1976... (Intel 8731?) I found the instruction set entirely logical and
usable with an easy learning curve.
The OP is a beginner and needs something simple to get going with. The 51
does what it says on the tin. The Dallas 450 version ,you can get up and
running in an afternoon with a couple of support chips.

 

[TT_Man]

As you said, PIC is king and it is for a reason, they work.Only if you can get to grips with the appalling op code set..... OK if you
can program in C , I suppose.I can't/won't

 

[Anthony Fremont]

Almost anything but an 8051?

I heard that. That is truly the ugliest archetecture.

Actually, just about anything that has a stack-oriented architecture,
or a register-oriented architecture with an orthogonal instruction
set and decent indexing. If I can, with confidence, slam a bunch of
parameters onto the stack or into some registers and call a function
without worry, then I'm happy.

But but but an 8052 has a stack and an available stack pointer. Don't you
like it?

The PIC (and the 8051, and some others) are so poor at stack usage and
pointer manipulation that unless one wants severely inefficient code
one pretty much has to define all the program data as a bunch of
globals. If you try to make your life more efficient by programming
in C, you'll find that the C compilers for the PIC and 8051 give you
a choice between something that isn't quite C, or C code that's
_really_, _really_ inefficient. If you want to write assembly using
C calling conventions -- well, find another processor, because you
can't.

The Keil compiler generates nice dense code on the 8052, but it costs a
fortune too. At the other end of the spectrum you have SDCC, ha ha ha. I'd
rather have a sharp stick in the eye. ;-)

Have you looked at the 18F pics? They added some things that make it much
more friendly to C compilers. Tripple data pointers (FSRs), auto
increment/decrement, bigger stack, W is a real SFR, LAT registers to
eliminate RMW issues for people too lazy to use a shadow register, etc.
Nice chip, I'll have to try one sometime. ;-)

 

[Anthony Fremont]

Only if you can get to grips with the appalling op code set..... OK
if you can program in C , I suppose.I can't/won't

I only do assembler on the PIC too. What's wrong with the op-code set?
It's RISC, it has 35 instructions, it's not supposed to be luxurious. It's
supposed to be functional and fast....it succeeds. ;-) Just for background
reference, I came from being a mainframe assembler programmer on a processor
with a 10 bit op-code.

I know it's tedious sometimes, but when you only have one working register
it's going to be that way no matter what.

 

[Homer J Simpson]

I only do assembler on the PIC too. What's wrong with the op-code set?
It's RISC, it has 35 instructions, it's not supposed to be luxurious.
It's supposed to be functional and fast....it succeeds. ;-) Just for
background reference, I came from being a mainframe assembler programmer
on a processor with a 10 bit op-code.

I know it's tedious sometimes, but when you only have one working register
it's going to be that way no matter what.

I don't think C is a great choice for small processors like the PIC. I
wonder if a version of Tiny Pascal might not work better.

 

[John E.]

What you're seeing here is an unfair attack on PICs

Let me ask that we not take an attack on a particular microcontroller as an
attack on one's person. Or one's child. (c: There are preferences, always
will be whether we're talking about cars, chips, or... well, tortilla chips.

Tell me what you like and don't, and why. I'm all ears.

 

[[email protected]]

PIC is king, I'm sure. But I'd like to hear from those who are using all
brands. Whichever you use, what do you like about it? What don't you like
about others? Suggestions re. learning?

I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
BASIC; COBOL if forced to admit it), so no stranger to programming, per se.

Thanks,

32 bit ARM's are nice, you can get them in small 4x5 mm packages up to
huge floating point versions with 256K of RAM, the small ones are a
few bucks. They work very well with high level languages and the
assembly is easy, you spend more time doing stuff rather then
fighting with the limitations of smaller PIC's, AVR's and 8051's (bank
switching, multi word math, accessing 16 bit hardware with double
reads that have to be done in a certain order, etc,etc,etc all that
weird goofy stuff goes away).

About C, you have to realize that the majority of example code out
there is in C, I hate the language myself, but I use it because it is
so easy to pick up someone's elses C code and start working with that.
I bought an ARM development kit recently and was up and running in a
few hours (blinking LEDS, reading A/D's, and sending the data to the
PC via the UART), cause they had C examples of everything, converting
the A/D inputs, UART utilities, start up files etc.

You have to remember the actual number of C features actually needed
in a small embedded processor is very little... learn a couple while/
for loops, if statement, how to set/clear a bit and how to call a
routine and what else is there? not much

 

[[email protected]]

PIC is king, I'm sure. But I'd like to hear from those who are using all
brands. Whichever you use, what do you like about it? What don't you like
about others? Suggestions re. learning?

I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
BASIC; COBOL if forced to admit it), so no stranger to programming, per se.

Thanks,

32 bit ARM's are nice, you can get them in small 4x5 mm packages up to
huge floating point versions with 256K of RAM, the small ones are a
few bucks. They work very well with high level languages and the
assembly is easy, you spend more time doing stuff rather then
fighting with the limitations of smaller PIC's, AVR's and 8051's (bank
switching, multi word math, accessing 16 bit hardware with double
reads that have to be done in a certain order, etc,etc,etc all that
weird goofy stuff goes away).

About C, you have to realize that the majority of example code out
there is in C, I hate the language myself, but I use it because it is
so easy to pick up someone's elses C code and start working with that.
I bought an ARM development kit recently and was up and running in a
few hours (blinking LEDS, reading A/D's, and sending the data to the
PC via the UART), cause they had C examples of everything, converting
the A/D inputs, UART utilities, start up files etc.

You have to remember the actual number of C features actually needed
in a small embedded processor is very little... learn a couple while/
for loops, if statement, how to set/clear a bit and how to call a
routine and what else is there? not much

 

[John Barrett]

32 bit ARM's are nice, you can get them in small 4x5 mm packages up to
huge floating point versions with 256K of RAM, the small ones are a
few bucks. They work very well with high level languages and the
assembly is easy, you spend more time doing stuff rather then
fighting with the limitations of smaller PIC's, AVR's and 8051's (bank
switching, multi word math, accessing 16 bit hardware with double
reads that have to be done in a certain order, etc,etc,etc all that
weird goofy stuff goes away).

About C, you have to realize that the majority of example code out
there is in C, I hate the language myself, but I use it because it is
so easy to pick up someone's elses C code and start working with that.
I bought an ARM development kit recently and was up and running in a
few hours (blinking LEDS, reading A/D's, and sending the data to the
PC via the UART), cause they had C examples of everything, converting
the A/D inputs, UART utilities, start up files etc.

You have to remember the actual number of C features actually needed
in a small embedded processor is very little... learn a couple while/
for loops, if statement, how to set/clear a bit and how to call a
routine and what else is there? not much

OK -- I'm a late entry on this one -- but WinAVR makes everything similarly
transparent for the 8 bit Atmel chips, and there is plenty of code out there
written in C for the AVRs, including math libs and such (used one to do a
software PID for servo motors -- worked well !!) -- best of all for me --
the compiler is free And like the ARM, you can ramp up to 32 bit chips
with on-chip DSP and may other specialty features

I personally dont care WHICH chip I use as long as I have good development
tools I started on the 8047/8051/Z8 MANY moons ago, and I've done plenty
of PIC and AVR -- I prefer the AVR chips because the development tools and
community support I got were better than what I ran into for the PIC when I
was getting started. (and the only FREE dev tools I could find for the the
PIC were BASIC, which I put aside a coupla hundred years ago !!)

They are all good chips -- make sure you got good dev tools !!

 

[Eeyore]

32 bit ARM's are nice, you can get them in small 4x5 mm packages up to
huge floating point versions with 256K of RAM, the small ones are a
few bucks. They work very well with high level languages and the
assembly is easy, you spend more time doing stuff rather then
fighting with the limitations of smaller PIC's, AVR's and 8051's (bank
switching, multi word math, accessing 16 bit hardware with double
reads that have to be done in a certain order, etc,etc,etc all that
weird goofy stuff goes away).

PL/M51 handles all that goofy stuff for me.

I've only once ever come across a situation with an 8051 where I'd have liked a
long word btw and I use even words quite rarely.

Graham

 

[[email protected]]

OK -- I'm a late entry on this one -- but WinAVR makes everything similarly
transparent for the 8 bit Atmel chips, and there is plenty of code out there
written in C for the AVRs, including math libs and such (used one to do a
software PID for servo motors -- worked well !!) -- best of all for me --
the compiler is free And like the ARM, you can ramp up to 32 bit chips
with on-chip DSP and may other specialty features

I personally dont care WHICH chip I use as long as I have good development
tools I started on the 8047/8051/Z8 MANY moons ago, and I've done plenty
of PIC and AVR -- I prefer the AVR chips because the development tools and
community support I got were better than what I ran into for the PIC when I
was getting started. (and the only FREE dev tools I could find for the the
PIC were BASIC, which I put aside a coupla hundred years ago !!)

They are all good chips -- make sure you got good dev tools !!- Hide quoted text -

- Show quoted text -

There really is no upgrade path for the AVR, the AVR 32 is only the
same in name only, it's nothing like a 32 bit version of the AVR8, and
currently there is only one device in that family.

the AVR series hasen't increased in performance in years (speed, a/d
resolution, DMA, fifo buffers, divide instructions etc). Microchip has
been very good in this respect, even though I don't use any of their
PICS. I ended up using the Atmel SAM7's and Analog devices ARM chips,
although AVR's are still superior in battery power devices.

All the development tools are excellent now, in my opinion, but I'm
pretty easy to please....

 

[krw]

Yes there certainly is. You've discovered the pic haters, welcome to my
world. ;-) Once you learn to use several different archetectures, you'll
see that they all suck in one way or another.

That's true of more than just UCs. ;-)

8052's are dumb in how they deal with internal/external storage

Each memory type has its reason. I've found 8051s (variants) quite
powerful because of the memory types and the wide variety of
peripherals that have been integrated into them.

and also their "output" vs "input"
methods suck too because they don't have true directional i/o pins.

Again, they're not all "true" bidirectional pins because they're used
for multiple purposes. They're not difficult to make into true I/O
pins though. With any flexibility you have to trade off some
complexity.

AVRs,
TI MSP430 and the rest all have their problems too whether it be an
inabillity to supply drive current to a part or some other deficiency. They
all have trade-offs. What you're seeing here is an unfair attack on PICs
that seems to be made mostly by people that have hardly (if ever) used one,
Tim excluded. As you said, PIC is king and it is for a reason, they work.

I've never used a PIC, though would like to do a job with one.
Picking (NPI) up a new processor isn't a big deal once you've seen a
few. ;-)

 

[Anthony Fremont]

That's true of more than just UCs. ;-)

Yes, all computers suck in one way or another. The same applies to all
operating systems. Some more than others. ;-)

Each memory type has its reason. I've found 8051s (variants) quite
powerful because of the memory types and the wide variety of
peripherals that have been integrated into them.

PICs pretty much have all the same peripherals that I've seen in them. I
just don't like the whole MOV MOVX thing. People whine about bank switching
on PICs, but the 8052 has some of the same thing. It's not that I hate
them, I just don't love them. I don't really love PICs either, but I can
live with them for now.

Before anyone gets the wrong idea, I'm not a one tool fits all kind person.
All micros have their place, some have more than others. ;-)

Again, they're not all "true" bidirectional pins because they're used
for multiple purposes. They're not difficult to make into true I/O
pins though. With any flexibility you have to trade off some
complexity.

That's my point. On allot of micros, you just set some kind of direction
flag and voila, no ambiguity.

I've never used a PIC, though would like to do a job with one.
Picking (NPI) up a new processor isn't a big deal once you've seen a
few. ;-)

You should try them sometime, they're not as bad as people let on. They
shine in abusive environments and will deliver the current to external
devices (usually 20 to 25mA sink or source on most common parts). Hard to
kill for the most part and

I've played with a few different micros, but there are still plenty left
that I haven't. I do want to play with some of those tiny 32 bit ARMs that
have lots of memory and speed.

 

[mpm]

....Insert multiple "negative 8051" comments here..."

Look, if you're going to program in Assembler, the 8051 (and it's
many, many cousins) are fine.
All this talk about architectures and C-coding probably won't mean
that much to a beginner.

Except perhaps the drive levels discussions.
Here, generically, I think there is something worth discussing.
Ideally, you'd like 20mA sink on every pin. Some 8051's with Quasi-
bidirectional ports can handle that. But I've seen some that can
barely manage 4mA, or less..

8051's are very well supported having been around for decades.
And they're not going away anytime soon.
I don't think you can go "wrong" here.

-mpm