I'm beginning to hear a lot of that (c;
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
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.
Don't let anyone fool you, all microcontrollers have their quirks and problems. IMO, the 8052 is the pits.
You won't regret it.
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
There's a pattern developing in this thread...
-- John English
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
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
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
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.
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.
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 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. ;-)
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.
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
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
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 !!
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....
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. ;-)
-- Keith
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.