Which uController to learn?

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.

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

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

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

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.

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

The differences are minor. And if you code properly, its very easy to adjust any relocated SRF's that affect program execution. Ditto for the Interrupt vectors, which for the "Standard" interrupts like T0, T1, etc... are usually at the expected addresses anyway.

Now, clock cycle / instruction cycle time is another story. I think the original 8051 would execute 1 instruction every 12 clocks. (?) Newer ones can do it in 2. (in other words, a 6x improvement).

If yours happens to default to the faster "speed", then it may not be a drop-in replacement.

-even if its 100% code compatible.

-mpm

In article , mpm wrote: [...]

The ones from Cygnal do it in one. Basically they are 50MPIS 8051s with analog stuff on board.

Yes, I always wrote a module for each UC that had the names of all SRFs for that model. This module was then included in the MAKE based on version. Never, EVER, use absolute addresses for SRFs.

Sure, I hard-coded these at each location, whether they were used or not. The main source module would have a stub to each ISR.

Yes, as I recently found out (duh!) the original 8051 has a bit- serial ALU. BTW, MUL and DIV are 24 clocks per instruction.

How would do you do an 8 x 8 multiply with 24 clocks and a serial ALU? Seems to me you'd need at least 64 clocks.

Anyway, MUL and DIV take 4 machine cycles (24 states, 48 oscillator clocks in the original 8x51). Still not 64 unless you're using both clock edges. There is at least one 8-bit micro that is serial internally- the ST-6 (it's a feature they say, lower noise)-- but I am not convinced that the 8051 is. Any cites?

Best regards, Spehro Pefhany

I don't have the microarchitecture of the original 8051, but you don't need a clock for each bit. The diagonals should be enough.

I thought it was six clocks per machine cycle and two (most) or four (MUL/DIV) cycles per instruction. It's been a long time since I used one though so may be misremembering the convoluted details.

It was brought up in AFC in the past week or so. I'll see if I can find the reference.

68000 series has pretty symmetric instruction set (orthoganol).

ie Moving from register to memory and vice versa is symmetric there are minimal exceptions. There are microntroller variants of processors that use 68000 instruction set.

Having a lot of registers is a bonus, 16 to 32 is ideal for the vast bulk on microcontroller apps, can get away with 4 or even 2 if you are keen.

Basically, for a beginner, you'd want an instruction set that works 'both ways' with registers, memory and IO ports, you dont want one with lots of lumpy exceptions or stack size restrictions or memory address or io restrictions - because if you are doing assembler you dont want to worry about that many until you are proficient, which usually happens fairly soon once you get stuck into it...