Connect with us

Which uController to learn?

Discussion in 'Electronic Components' started by John E., Mar 15, 2007.

Scroll to continue with content
  1. Tim Wescott

    Tim Wescott Guest

    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
     
  2. John E.

    John E. Guest

    I will mention that for most microprocessors the verb is "use", but for
    There's a pattern developing in this thread...
     
  3. John E.

    John E. Guest

    I will mention that for most microprocessors the verb is "use", but for
    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?)
     
  4. Tim Wescott

    Tim Wescott Guest

    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
     
  5. John E.

    John E. Guest

    Actually, just about anything that has a stack-oriented architecture, or
    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:
     
  6. 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.
     
  7. TT_Man

    TT_Man Guest

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

    TT_Man Guest

    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
     
  9. I heard that. That is truly the ugliest archetecture.

    But but but an 8052 has a stack and an available stack pointer. Don't you
    like it?
    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. ;-)
     
  10. 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.
     
  11. 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.
     
  12. John E.

    John E. Guest

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

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

    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
     
  15. John Barrett

    John Barrett Guest

    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 !!
     
  16. Eeyore

    Eeyore Guest

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

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

    krw Guest

    That's true of more than just UCs. ;-)
    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.
    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.
    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. ;-)
     
  19. Yes, all computers suck in one way or another. The same applies to all
    operating systems. Some more than others. ;-)
    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. ;-)
    That's my point. On allot of micros, you just set some kind of direction
    flag and voila, no ambiguity.

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

    mpm Guest

    ....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
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-