Sci.Electronics.Basics

on Electronics-Related.com


	Sign in


	username: password: Remember Me Not a member?

Search Sci.Electronics.Basics

Sci.Electronics.Basics -> Which uController to learn?

There are 124 messages in this thread.
You are currently looking at messages 40 to 60.

Author: Eeyore
Date: 03:24 16-03-07

Anthony Fremont wrote:

> Eeyore wrote:
> > Anthony Fremont wrote:
> >> Eeyore wrote:
> >>> Anthony Fremont wrote:
> >>
> >>>> Multisourced, that's another misrepresentation. For the most
part,
> >>>> chips from different vendors are just similar archetectures, not
> >>>> "compatible" chips insofar as actually being able to
drop one in
> >>>> place of another. Not to mention how vastly incompatible the code
> >>>> internals are for anything but the most basic peripherals.
> >>>>
> >>>> But that's just my opinion. ;-)
> >>>
> >>> Eh ?
> >>>
> >>> The various 8051 clones from various manufacturers are completely
> >>> compatible in every respect. That's one of the joys of the part.
> >>> Such changes as have been made are backwardly compatible even with
> >>> no code change too.
> >>
> >> Things must have changed then. Only the barest parts would be
> >> compatible. As soon as you start adding extra peripherals (and these
> >> _are_ the chips that get used in production, not the 8051 true
> >> clones)
> >
> > I don't know about that. Some of the extra functions seem to be
> > implemented both by Philips and Atmel for example. Sure you can use
> > an 89C51 with flash memory in place of an 87C51 to take the simpler
> > example.
> >
> >
> >> things change allot.
> >> So it's true that you could probably get away with dropping an Atmel
> >> 89c52 in place of a vintage 8052, it likely wouldn't work the other
> >> way around since the Atmel part has "extensions". As soon as
people
> >> utilize the extensions, compatibility disappears. no?
> >
> > Manufacturers seem to have been careful about allocating the new
> > SFRs. I've never come across an example where a 'new' SFR didn't
> > default to 'plain vanilla' operation if left untouched.
>
> That's true, but wasn't really my point. I'm saying that people use these
> "special features" and then they narrow (or eliminate) their source
options.
> Where parts from different vendors do have similar extensions, they don't
> usually implement the SFRs the same way. It's been a while since I looked
> around, maybe vendors are getting on the same page now (why do I really
> doubt that though ;-).

Well.... yes if you do use those very specific features you will be stuck with a
single source but you're still no worse off than you would be with a PIC.

Graham

Author: John E.
Date: 04:19 16-03-07

> I'm prejudiced against the PIC because bank switching is Evil.

I'm beginning to hear a lot of that (c;

> As a hobbyist: 6502, 6800/02/09, Z80; as a pro, 68HC11, Z80, 80186 ;-)

I think I should clarify that my desire isn't to go in the direction of
microprocessors, but in the direction of microcontrollers. I distinguish
those that have data and memory bus pins from those that are self-sufficient,
memorywise. The latter may have I/O such as analog inputs and/or outputs, but
not necessarily; they may interface with outboard converters.

Thanks,
--
John English

Author: Anthony Fremont
Date: 06:03 16-03-07

John E. wrote:
>> I'm prejudiced against the PIC because bank switching is Evil.
>
> I'm beginning to hear a lot of that (c;

Since you're starting, the 18F PICs may be more in line with what you want.
Not even any bank switching till you're ready for it. Plus Microchip has a
decent C compiler for them (I never used it, but that's what I keep hearing)
that has something like a 90 day trial. After the trial, uninstall and
reinstall.
www.picbook.com is a good treatise on the 18F PICs.

Don't let anyone fool you, all microcontrollers have their quirks and
problems. IMO, the 8052 is the pits.

>
>> As a hobbyist: 6502, 6800/02/09, Z80; as a pro, 68HC11, Z80, 80186
>> ;-)
>
> I think I should clarify that my desire isn't to go in the direction
> of microprocessors, but in the direction of microcontrollers. I
> distinguish those that have data and memory bus pins from those that
> are self-sufficient, memorywise. The latter may have I/O such as
> analog inputs and/or outputs, but not necessarily; they may interface
> with outboard converters.

You won't regret it.

Author: Tim Wescott
Date: 11:15 16-03-07

John E. wrote:
> 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

Author: John E.
Date: 13:18 16-03-07

> 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 English

Author: John E.
Date: 13:28 16-03-07

> 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?)
--
John English

Author: Tim Wescott
Date: 14:08 16-03-07

John E. wrote:

>>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?)

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

Author: John E.
Date: 14:50 16-03-07

> 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:
--
John English

Author: Anthony Fremont
Date: 15:19 16-03-07

John E. wrote:
>> 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...

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.

Author: TT_Man
Date: 15:20 16-03-07

"John E." <incognito@yahoo.com> wrote in message
news:0001HW.C220350A0041BFCBF01826C8@news.sf.sbcglobal.net...
>> 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:
> --
> John English
>
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.

Author: TT_Man
Date: 15:22 16-03-07

> 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

Author: Anthony Fremont
Date: 15:26 16-03-07

Tim Wescott wrote:
> John E. wrote:
>
>>> 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?)
>
> 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. ;-)

Author: Anthony Fremont
Date: 15:34 16-03-07

TT_Man wrote:
>> 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

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.

Author: Homer J Simpson
Date: 16:00 16-03-07

"Anthony Fremont" <spam-not@nowhere.com> wrote in message
news:12vlsaujevici3d@news.supernews.com...

> 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.

Author: John E.
Date: 16:57 16-03-07

> 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.
--
John English

Author: bungalow_steve@yahoo.com
Date: 18:21 16-03-07

On Mar 15, 4:52 pm, John E. <incogn...@yahoo.com> wrote:
> 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,
> --
> John English

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

Author: bungalow_steve@yahoo.com
Date: 18:37 16-03-07

Author: John Barrett
Date: 18:52 16-03-07

<bungalow_steve@yahoo.com> wrote in message
news:1174083664.366440.223730@d57g2000hsg.googlegroups.com...
> On Mar 15, 4:52 pm, John E. <incogn...@yahoo.com> wrote:
>> 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,
>> --
>> John English
>
> 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 !!

Author: Eeyore
Date: 18:56 16-03-07

"bungalow_steve@yahoo.com" wrote:

> 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

Author: bungalow_steve@yahoo.com
Date: 01:48 17-03-07

On Mar 16, 2:52 pm, "John Barrett" <ke5c...@verizon.net> wrote:
> <bungalow_st...@yahoo.com> wrote in message
>
> news:1174083664.366440.223730@d57g2000hsg.googlegroups.com...
>
>
>
> > On Mar 15, 4:52 pm, John E. <incogn...@yahoo.com> wrote:
> >> 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,
> >> --
> >> John English
>
> > 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 !!- 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....

1 2 3 4 5 6 7

Contact | Electronic Portal

Sci.Electronics.Basics by Keywords

ADC
Antenna
CAD
Coil
Generator
IDE
LCD
Modulator
MOSFET
NiMH
Opamp
Oscilloscope
PID
RS232
Telephone
Transformers
TTL
USB

Sci.Electronics.Basics By Author