Which uController to learn?

Just looked at their web site. Top of the line is only EUR1800 (how the heck do I make a Euro symbol...?), US$2376. Not bad. FInally a DSO the average guy can afford. Keep us informed...

Many thanks, Don. Much good first-timer info there. A "rich" resource.

Not to mention the 64, 68, 80 and 100-pin ones.

There are several flavo[r]s to PIC assembly.

That thing is not 'a microcontroller'.

As to the original question.. it really depends on the application and the peripherals you might need. If you need Ethernet and/or USB on board, that's one thing (you'll almost certainly want something with a decent C compiler and available protocol stack), if you just want to diddle some bits fast, or do a relatively slow PID control that's another. If you need 10, 12, or 24 bits of ADC, multiple PWMs, quadrature input, direct display drive, etc. etc. that may play a great role. The choice of core is only one consideration among many.

Best regards, Spehro Pefhany

Be wary of certitude. PIC's bizarre fscked architecture is abhorred by right-thinking engineers (of course, there are no absolutes, but this is quite close to one).

If you have experience as you have enumerated, you will have little difficulty learning almost any architecture; the choice of which is "useful" depends on the "use" to which you intend to apply this knowledge.

Bought the DS1102C (100MHz/2-channel) for US$999. So far so good, I like it. :-)

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

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.

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.

Graham

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

In the early days, though I'm sure that has changed, the stack depth was way too short for any reasonable level of subroutine coding, this also affected the design of systems which needed multiple (flexiblely) prioritised interrupt sources...

Since I had been using the 8051 and atmel variants which had far deeper stacks and ease of changing returns and flexible control of interrupt response I had never any need to revisit the PIC.

Oh and the code/data memoru separation I found to be irritating on odd occasions,

From what I recall the 68000 series was the closest to a orthogonal instruction set making for great compiler efficiencies, with the later generaton of PICS there were, iirc, still many instruction exceptions which didnt allow compilers to be as efficient could have been good for assembler writers but you really dont want to stay in assembler as generally projects get more complex and we do want to have a social life dont we ?

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

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,

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.

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

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.

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:

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.