Getting started with PICs. Looking to learn ASM

[rwgast_lowlevellogicdesin]

Ive been playing with micro controllers for a little over a year now and I have been programming in C for over 10. I have yet to use a PIC though! The other day I got a vellman kit at radio shack on sale for 15 bucks that programs PICs. I've been using the PICPgm program with the kit and it seems that I can program mostly any PIC 18 series and under, even though the PICPgm software has the ability to program the 24 and 33 series. If I eventually decide to stick with PIC's I will purchase a pickit.

Anyways I know very little assembly for the x86 and that is about it. I would really like to start learning ASM on a simpler architecture like a micro controller. The PIC seems like a great place to start. There is a ton of hand holding tutorial material out there about PIC assembly, while the most other micros have a huge lack of this kind of material for newbs.

What im wondering is if I start learning ASM on PIC 16F chips how does that translate to 18F and 24F chips (I know the pic33 are MIPs, so that's a whole different ball game)?? Does each new pick series keep backwards compatibility with the last, while adding new instructions?

Also if I am say writing code for a pic16f28a, yet reading a tutorial focused on another 16F series chip will I be fine for the most part, assuming the two chips have the same peripherals, the only thing in the code that should change would be pin numbers?

[mariush]

PIC16, 18, 24  etc are all MIPS architecture... the datasheets for each PIC chip are very detailed and explain all assembly instructions... there's also application notes on microchip's site and tips&tricks pdf files.

Since you're a beginner, I'd suggest you start with writing C for the microcontroller (you have the free XC compiler and MPLABX) and once you have programs running on the microcontroller you can look at the generated assembly code.
PIC16 is a tiny bit harder to write assembly for compared to pic18 but not by much. PIC32 is more optimized for C programming.

To be honest, I'm not even sure why you'd want to code assembly... you'd only have to write asm if you really have to write the smallest size code or very tight loops and things like this. These days, unless you're doing it as a hobby or curiosity, it's not worth the time to do the programming in assembly... if you happen to write some program that takes more resources than your microcontroller, you can pay 5-15 cents extra for a larger microcontroller... there's a huge variety of microcontroller models out there.

[nuhamind2]

If you want a more pleasant ASM experience, try AVR8

[johnboxall]

Beginner PIC ASM and C tutorials - http://www.gooligum.com.au/tutorials.html

[dannyf]

"I have been programming in C for over 10."

Then why start now with assembly?

"What im wondering is if I start learning ASM on PIC 16F chips how does that translate to 18F"

They are reasonably similar.

"(I know the pic33 are MIPs"

PIC32s are MIPS; dsPIC33 are Microchip's.

"Does each new pick series keep backwards compatibility with the last, while adding new instructions?"

Reasonably good backward compatability 18F and below. Not much for 24F or 32. However, 24F have great peripheral compatibility - which is really what you need to know if you program it in a high level language like C.

"Also if I am say writing code for a pic16f28a, yet reading a tutorial focused on another 16F series chip will I be fine for the most part, assuming the two chips have the same peripherals, the only thing in the code that should change would be pin numbers?"

But that assumption is wrong.

My suggestion would be to start with C, given your background and (likely) interest to move to 24F or 32F chips.

"PIC16, 18, 24  etc are all MIPS architecture... "

Really?

[nctnico]

No, only PIC32 is MIPS. If you want backwards compatibility then go for ARM. The ASM is the same for the 50 cent microcontrollers and the multi-core GHz mobile phone CPUs.

[dannyf]

"The ASM is the same for the 50 cent microcontrollers and the multi-core GHz mobile phone CPUs."

It depends on the particular instructions used.

For those chips, programming in assembly is futile, unless you just want to blink an led, or you have access to (nearly) unlimited resources.

[AlfBaz]

Well, there's learning asm and then there's learning an architecture.
Asm is asm and learning it is about carrying out certain programming constructs within the instruction set limitations. Sure there are different mnemonics and side effects for instructions from processor to processor but that's essentially architecture semantics

Just pick a processor and go for it, however, if you want to make use of your new found skills you may as well choose a small 8 bit processor with limitations that hinder good compiler output. For well endowed processors you will hard pressed to better the asm generated by a half decent compiler

[westfw]

I would really like to start learning ASM on a simpler architecture like a micro controller.

Note that a "simple architecture" does not make for "simpler ASM programming."
I would rate a basic x86 as much easier to program in ASM than a PIC16.

PIC18 is an improved version of the PIC16 chips, with similar (painful) "architecture."  The PIC16 chips differ in the number of bits reserved in the instruction words for addresses.  There are chips with 12, 14, and 16bit instruction words, and they have different "page sizes" and such.  A 12bit PIC16 will have weird limitations ("you can only do a computed jump or CALL to the first 256 words of the program address space.")  And different call stack depths.  (On the bright side, the Microchip datasheets are much better at explaining the Architecture than most modern CPU datasheets.)

You can learn a lot about computer architecture by comparing a PIC with an X86...

PIC24, PIC30, and PC33 are similar to each other, but quite different than the 8bit PICs (nicer!).  (These are 16bit chips.)

PIC32 is different again (MIPS, as someone said.)  MIPS was one of the flagship RISC architectures, but has fallen way behind ARM.

"[ARM] ASM is the same for the 50 cent microcontrollers and the multi-core GHz mobile phone CPUs."

Actually, it's not.  A CM0-architecture (50-cent) chip is programmed in a relatively small subset of "thumb2" instructions, while the BIG ARM chips use the full 32bit non-thumb instructions.  They're pretty substantially different.

[AlfBaz]

I would rate a basic x86 as much easier to program in ASM than a PIC16.

With all due respect, there are only 35 instructions for a pic16, and aside from branch type stuff all single cycle.
Whilst paged memory access (aka banksel) and the split instruction memory and data memory are a bit of a head ache it's not quite as convoluted as the multitude of addressing methods on an x86

[WarSim]

ASM is not harder or easier on any architecture.  This is not a uC debate, the thread author is asking for reference suggestions.

Any one programming C for ten years should know the process for programming quite well.  The only way the author has no experience with architecture interaction is if his entire C experience is sandbox coding (only used pre made libraries). After 10 years I assume this is not the case.  Try it out you may be surprised how easy it is.  Leverage your structure development experience gained from your C experience.

If I am wrong on this point them I highly suggest you start with one of the sandboxed nemonic training languages.  Only to start with don't get in a training language like all the career BASIC programers. 

ASM is just another language that has closer association to the target architecture model.  The exact same process applies, nothing new.  Only thing that changes is the instruction set available.  Same as any other transition to a different language. 

Because ASM is very close to the architecture reference material is supplied by the manufacturer.  This goes for all processors of any type.  If you find the resources supplied by the manufactures is not enough for you.  Let's us know where the problem persists and additional resources can be suggested.

[nctnico]

"[ARM] ASM is the same for the 50 cent microcontrollers and the multi-core GHz mobile phone CPUs."

Actually, it's not.  A CM0-architecture (50-cent) chip is programmed in a relatively small subset of "thumb2" instructions, while the BIG ARM chips use the full 32bit non-thumb instructions.  They're pretty substantially different.

The newer Cortex processors all use thumb. The 'bigger ones' are backwards compatible with the 'old' ARM instructions.

[fcb]

PIC16, 18, 24  etc are all MIPS architecture... the datasheets for each PIC chip are very detailed and explain all assembly instructions... there's also application notes on microchip's site and tips&tricks pdf files.

Wrong. PIC10/12/14/16/17/18/24/30/33 series are modified harvard architecture. PIC32 is MIPS4K architecture.

Since you're a beginner, I'd suggest you start with writing C for the microcontroller (you have the free XC compiler and MPLABX) and once you have programs running on the microcontroller you can look at the generated assembly code.
PIC16 is a tiny bit harder to write assembly for compared to pic18 but not by much. PIC32 is more optimized for C programming.

Start with 18F series, skip 10/12/16 series unless you are designing something that needs very small packages (SOT23-6) and/or low pincount or is very cost sensitive.  There is no need to get annoyed with the paged memory unless you need to.
I keep gobs of PIC18F1220's (18pin DIL) about in-case I need something quick and dirty (same goes with the dsPIC33FJ128GP202 in 28pin DIL).

To be honest, I'm not even sure why you'd want to code assembly... you'd only have to write asm if you really have to write the smallest size code or very tight loops and things like this. These days, unless you're doing it as a hobby or curiosity, it's not worth the time to do the programming in assembly... if you happen to write some program that takes more resources than your microcontroller, you can pay 5-15 cents extra for a larger microcontroller... there's a huge variety of microcontroller models out there.

ASM has it's place (I still write everything in PIC ASM and have done for 20+ years) - have a go! You have nothing to lose and it will probably improve your code.

[dannyf]

What tool is best depends on the application: for every nail, there is a hammer,

However, if you are looking to maximize return to your investment (in terms of time spent learning a tool), I would say that C is the better alternative generally. The issue with assembly is that you can be easily replaced by a compiler (again, most of the time -> that means in some applications, you cannot be replaced by a compiler).

As the ARM market has shown, people give very little consideration to the core and instead, the peripherals are the differentiating factor, and where you will be spending most of your time.

So if you are starting, particularly with 10-yrs of C behind you, C is a good starting point.

[WarSim]

ASM is not harder or easier on any architecture.

Yes, it really, really is. AVR assembler is a lot easier to get started with. Actually 68000 assembler is nice too. 8 bit PIC and x86 are not pleasant, and ARM bogs you down with a complex architecture.

The 16 bit PIC24 series is probably the best place to start if you must use PICs. Otherwise, I'd have to recommend AVR instead.

I have been programming since 83 and I know there was/is no difference.
I am confused and concerned about your comment.  It's like saying a blue hammer is easier to use than a green hammer.  Alas it is your opinion, and I disagree with it.

Putting aside the fanboys.  The most important factor is selecting the architecture that best fits your goals. As mentioned before chip count is going down.  Instead of adding external function use a single chip that gets closest to your goal.  Therefore it is critical that you do not blindly favour any chip. 

If you want to learn how to utilize a uC it does not matter which one you start with.  Except Arduino which is a hobbyist gimmick, and teaches nothing useful outside the Arduino world.  I understand it's purpose, but hobbyist need low investment options not the "speak and spell" versions of a computer. 

CISC, RISC, Harvard, MIPS ....... are just the tools available pick one a get learning. But of you start with a processor instead, start with a development board.  No need to de-snag interfaces when you are learning to de-bug code. 

[AlfBaz]

The most important factor is selecting the architecture that best fits your goals.

It would appear the goal here is to learn asm, in which case you would be doing the OP a disservice by suggesting he start learning on a complex architecture for which material learnt would be useless because they have abundant resources for which a compiler can cater and undoubtedly do a better job.

[westfw]

ASM is not harder or easier on any architecture.

I think we're going to have to agree to disagree on that one.  I much prefer a multiple-register, orthogonal instruction set with a flat address space (like a PDP11, 68000, or MSP430) and rich addressing modes, than an Accumulator-based with banked code and memory spaces were some traditional primitives are handled by "peripheral registers" (like a PIC, 1802, or 8051.)

There are also architectures where ASM is widely used enough that the assembler itself is well written, and there are "standards" (and support Macros) for various useful things (subroutine linkage, bitfields, structures, etc.)  And others where ASM is just something you write the startup code for a HLL...

[JTR]

ASM is not harder or easier on any architecture.

I think we're going to have to agree to disagree on that one. 

Likewise! Now I'm going to get out of here now before this thread becomes like the C Vs ASM thread...

[WarSim]

ASM is not harder or easier on any architecture.

I much prefer a multiple-register, orthogonal instruction set with a flat address space (like a PDP11, 68000, or MSP430) and rich addressing modes, than an Accumulator-based with banked code and memory spaces were some traditional primitives are handled by "peripheral registers" (like a PIC, 1802, or 8051.)

Yes exactly my it is your preference.  Preference is a huge factor when any task is seen as easier or harder.  My whole goal is not to have anyone persuaded the op into any architecture.  Everyone learns differently, we are not programmed automatons.

Because it have trained and mentored hundreds even thousands of people in programming and electronics I know for a fact people are different.  The key is help them find the eureka moment not push them into a program based on your individual experience.

I have seen many people stumble with what is considered "easier" and excel at what is "hard".  The very sad part is they were pressed into the notion that they had to start with the "easy", and could not succeed with the hard.

I have also seen people not be pressed into the easy first and start with the "hard".  They do very well quickly.  Once they know their first architecture the second is much easier.

The new ASM programer should read about the basics of various architectures and find one that looks like a good idea to them.  That architecture will be the best to start with, not the one that you or I say is the best.  This is not formal training, allow that flexibility to be to the ops advantage.

[WarSim]

ASM is not harder or easier on any architecture.

I think we're going to have to agree to disagree on that one. 

Likewise! Now I'm going to get out of here now before this thread becomes like the C Vs ASM thread...

It is not a fight I out X or Y.  This is about allowing the op to make the best choice for themselves.
If the thread was about what the contributors liked about an architecture and why it made since to them, I would not have responded.  With only abstract opinion the op has no information to decide what is best for them.

[westfw]

The new ASM programer should read about the basics of various architectures

Now THERE is something I can agree on.

When you learn an assembly language, you're learning TWO things.  One is the syntax of the particular assembler you are using - how to define variables, constants, labels, and the dozen to hundreds of mnemonics for the instructions that that particular machine implements.  The other is the architecture of the processor involved, in intimate and mind-numbing detail; how it works, internally, at a "logical" hardware level.  Some of those architectures are elegant pieces of design, others are magnificent exercises in cost reduction, speed improvement, and hardware simplification.

In a way, the whole RISC founding principle might be summarized as "Stop designing architectures for assembly language programmers, and start designing them for compiler writers (and BTW, that will make the hardware simpler and faster.)"

You'll usually learn a lot more when you study your SECOND assembly language.  But you can certainly do a better job learning the right things on the first.

[dannyf]

With assembly, your learning is (highly) limited to that particular platform. Moving to a different platform, you have to re-learn.

So, it pays to be selective upfront on which chips are you likely to use in the future and then learn on that chip. But for beginners, they lack the knowledge to know that so this becomes a chicken-and-egg problem.

If you are a hobbyist, it doesn't matter which chip you learn on.

If you want to code for a living, it doesn't pay to learn assembly: the most value-add you can as a professional programmer are two things: algorithm and peripherals. writing assembly is mostly a non/low-value add job as it can be done by a compiler.

In my view, two types of people code in assembly: those who are resource poor and those who are resource rich. Everybody else (=99% of us) code in some kind of high level language.

[WarSim]

With assembly, your learning is (highly) limited to that particular platform. Moving to a different platform, you have to re-learn.

So, it pays to be selective upfront on which chips are you likely to use in the future and then learn on that chip. But for beginners, they lack the knowledge to know that so this becomes a chicken-and-egg problem.

If you are a hobbyist, it doesn't matter which chip you learn on.

If you want to code for a living, it doesn't pay to learn assembly: the most value-add you can as a professional programmer are two things: algorithm and peripherals. writing assembly is mostly a non/low-value add job as it can be done by a compiler.

In my view, two types of people code in assembly: those who are resource poor and those who are resource rich. Everybody else (=99% of us) code in some kind of high level language.

Unfortunately you have not been successful in transporting your knowledge.  Don't limit others.

The chip you are likely to use in the future haven't been created yet.  Careers last 30 - 35 years.

The claim that ASM is a waist of time is your opinion and BS.  Your 99% figure is based on your desires not to be alone.  These days because your opinion is not unique, I would accept 80%.  That is why people with a complete skill package will never we wanting for a job.  Everyone has the choose of competing for the cookie cutter jobs or take any job they want.

[senso]

Someone as to program in assembly, or in a near future there will be no one to teach the compilers on how to generate good code from C/C++/anything worse than C++.

[dannyf]

Start with 18F series,

My two biggest complaints about those low-end pic chips (18f and lower) are 1) their lack of a vectored interrupt controller; and 2) too many different chips / peripheral sets (this one can be a plus). A non-vectored IC makes modular coding difficult; and too many chips / peripheral sets make porting difficult - you typically start development on a larger chip and once the code finalizes you figure out the target chip to use. But if the peripherals are so different, you end up pretty much rewriting the code.

Now, that can be a huge advantage if you are pinching every penny and trying to reduce hardware cost for your project.

The higher-end chips (PIC24 for example) don't have those issues.

There is no need to get annoyed with the paged memory unless you need to.

If you code in a high level language, that's transparent to you.

[WarSim]

you typically start development on a larger chip and once the code finalizes you figure out the target chip to use. But if the peripherals are so different, you end up pretty much rewriting the code.

There is no need to get annoyed with the paged memory unless you need to.

If you code in a high level language, that's transparent to you.

Who exactly is "you"?    BTW I don't do this.  I perform a program survey process I just select the correct chip and use it.  I find programming twice in efficient.

Or you can use the paged memory to your advantage.  Think outside the box, and you can do things that many others say is not possible.

[nctnico]

With assembly, your learning is (highly) limited to that particular platform. Moving to a different platform, you have to re-learn.

Not really. Architectures may differ but once you know how to read an instruction set specification (usually 2 to 4 pages) you can write assembly for any architecture. Every architecture has load, add, substract, and conditional jump/call instructions and those are what you need to write a program.

[dannyf]

Every architecture has load, add, substract, and conditional jump/call instructions and those are what you need to write a program.

Those instructions differ from chip to chip and you need more than that to write a program.

My point is that you hear people picking chips for cost, life cycle management, sourcing, availability, etc. far more than "architecture". When was the last time that you saw a piece of code that has to run on a particular architecture? (ie it is so unique to that architecture that it cannot be ported to a different architecture).

[nctnico]

Edit:

Every architecture has load, add, substract, and conditional jump/call instructions and those are what you need to write a program.

Those instructions differ from chip to chip and you need more than that to write a program.

Since when is 1+1 not 2? Add works the same on every CPU. On an overflow the carry is set, when the result is 0 the zero flag is set.

When was the last time that you saw a piece of code that has to run on a particular architecture? (ie it is so unique to that architecture that it cannot be ported to a different architecture).

A couple of years ago I had to rewrite a lot of C code so it could run properly (fast enough / small size) on an 8 bit PIC because 8 bit PICs really don't like pointers.

[nctnico]

IMHO an Arduino-ish environment is a good start. My embedded software usually consists of seperate modules with an init and a run function called from main. I had quite a few interns work on microcontroller projects. I let them start with a basic piece of software which offers a command line on a serial port module and a timer module to blink a led. For the majority this environment offered an excellent starting point to get a project going.

[WarSim]

Funny how you like to take my comments out of context, for example:

Taking a comment about ease of learning different architectures and repeating it as if it is about denying there is a difference in architectures.
Taking a comment about Arduino purposely reducing the burden of Architecture knowledge from the beginner programer to mean their chip are beneath me.

If you need too twist what I have written to make your argument work so be it.  You are not arguing with me, only what you think I said.

[WarSim]

IMHO an Arduino-ish environment is a good start. My embedded software usually consists of seperate modules with an init and a run function called from main. I had quite a few interns work on microcontroller projects. I let them start with a basic piece of software which offers a command line on a serial port module and a timer module to blink a led. For the majority this environment offered an excellent starting point to get a project going.

Yes it is a good start for someone new to programming and uC.  But I would not say someone that has done just Arduino programming has gain enough knowledge and skill to be considered a knowledgeable embedded programer.

If the op was much newer to programming the Arduino learning step would have more value.  The Arduino producers are purposely reducing the required architecture knowledge to help the new programers.  What learning value comes from a hidden architecture.  You only gain significant architecture knowledge when you break out of the Arduino box and do something new not covered by a library.

I have never seen an Arduino in a consumer product.  I would be very surprised if I ever did.  Arduino is about enabling people to use micro controllers.  For this purpose they made decisions that make them the lesser option for a finished consumer product.  For the same reasons they are a good choice for beginner programers to make a hobby project. 

Before anyone says Arduino's are their manufacturer equivalents.  Yes they are.  Only very few could not be cracked back to their originals purpose.

[nctnico]

IMHO an Arduino-ish environment is a good start. My embedded software usually consists of seperate modules with an init and a run function called from main. I had quite a few interns work on microcontroller projects. I let them start with a basic piece of software which offers a command line on a serial port module and a timer module to blink a led. For the majority this environment offered an excellent starting point to get a project going.

Yes it is a good start for someone new to programming and uC.  But I would not say someone that has done just Arduino programming has gain enough knowledge and skill to be considered a knowledgeable embedded programer.

If the op was much newer to programming the Arduino learning step would have more value.  The Arduino producers are purposely reducing the required architecture knowledge to help the new programers.  What learning value comes from a hidden architecture.  You only gain significant architecture knowledge when you break out of the Arduino box and do something new not covered by a library.

Actually less is better. If you need to spend a lot of time putting all kinds of small parts together a project needs a long time to complete. If you can pull large bricks from a library then you get results much faster. You can do all the math by yourself but you'd agree with me using a calculator is much faster. And there is no reason to spin your own board based on Arduino hardware and use the same software. Maybe you've never seen an Arduino board in a product but I'm sure there are products out there which started as an Arduino project and still use the same software.

[WarSim]

IMHO an Arduino-ish environment is a good start. My embedded software usually consists of seperate modules with an init and a run function called from main. I had quite a few interns work on microcontroller projects. I let them start with a basic piece of software which offers a command line on a serial port module and a timer module to blink a led. For the majority this environment offered an excellent starting point to get a project going.

Yes it is a good start for someone new to programming and uC.  But I would not say someone that has done just Arduino programming has gain enough knowledge and skill to be considered a knowledgeable embedded programer.

If the op was much newer to programming the Arduino learning step would have more value.  The Arduino producers are purposely reducing the required architecture knowledge to help the new programers.  What learning value comes from a hidden architecture.  You only gain significant architecture knowledge when you break out of the Arduino box and do something new not covered by a library.

Actually less is better. If you need to spend a lot of time putting all kinds of small parts together a project needs a long time to complete. If you can pull large bricks from a library then you get results much faster. You can do all the math by yourself but you'd agree with me using a calculator is much faster. And there is no reason to spin your own board based on Arduino hardware and use the same software. Maybe you've never seen an Arduino board in a product but I'm sure there are products out there which started as an Arduino project and still use the same software.

A project can start in any form (project).  My comment was on finished form (product).  The process of napkin to widget dose not make the napkin the widget.

If that is your chosen method I would never dispute what makes sense to you.  Like I said before it is all about what makes sense to the programer.  In the case of business, what makes sense to the development team.  I can see the advantage of using an Arduino for making mock ups/demos for a development team.  All I can say is I haven't, I use pictures, charts and text.

I personally just pick a chip with all the require capabilities and use the same chip start to finish.  In contrast, I do know many that do not have success with their resource audits and need to change chips mid development. 

I rarely use third party libraries, they need to be everything to everyone.  I prefer to use minimal hardware so I am looking for ns to shave and libraries are on the target list.  Instead I have made my own collection of slimmer libraries.  So yes I do use libraries of a fashion. 

[westfw]

Every architecture has load, add, substract, and conditional jump/call instructions

Not true.  The architecture I've written the most assembly for did most of its decision making via "skip" instructions.  It also had half-a-dozen or so subroutine linkage instructions, none of which were named "call."  (In fact, the PIC16f architecture, which is what we started out talking about, is also SKIP-based.)
ARM lacks what most people think of as a "call" instruction, as did the 1802 (in a totally different way.)  Conditional call instructions seem to be pretty rare (briefly existing on 8080 and z80?) (well, and on some ARMs, in their unusual way.)
As for add/subtract, architectures different on where the operands can be.  Some can add/subtract only to the "accumulator."  Others can add/subtract only registers.  Still others want one argument in a register and one in memory.  And on the length of operands.

[WarSim]

Every architecture has load, add, substract, and conditional jump/call instructions

Not true.  The architecture I've written the most assembly for did most of its decision making via "skip" instructions.  It also had half-a-dozen or so subroutine linkage instructions, none of which were named "call."  (In fact, the PIC16f architecture, which is what we started out talking about, is also SKIP-based.)
ARM lacks what most people think of as a "call" instruction, as did the 1802 (in a totally different way.)  Conditional call instructions seem to be pretty rare (briefly existing on 8080 and z80?) (well, and on some ARMs, in their unusual way.)
As for add/subtract, architectures different on where the operands can be.  Some can add/subtract only to the "accumulator."  Others can add/subtract only registers.  Still others want one argument in a register and one in memory.  And on the length of operands.

Only indication you disagree is the words "Not true."
How about load/fetch, add/inc, sub/dec, skip/jump/call/brn/brk instructions. 
Or maybe it was not clear that the writer was referring the command groups. 
Or some other reason I haven't figured out why pointing out that the capabilities or syntax differences of specific commands prove that the writer is wrong in saying that every architecture can.

[dannyf]

A couple of years ago I had to rewrite a lot of C code so it could run properly (fast enough / small size) on an 8 bit PIC because 8 bit PICs really don't like pointers.

Pointers have been used on 8-bit chips, including the PICs, for as long as they are used.

Anyway, back to the question:

When was the last time that you saw a piece of code that has to run on a particular architecture? (ie it is so unique to that architecture that it cannot be ported to a different architecture).

[WarSim]

Every architecture has load, add, substract, and conditional jump/call instructions

Not true.  The architecture I've written the most assembly for did most of its decision making via "skip" instructions.  It also had half-a-dozen or so subroutine linkage instructions, none of which were named "call."  (In fact, the PIC16f architecture, which is what we started out talking about, is also SKIP-based.)
ARM lacks what most people think of as a "call" instruction, as did the 1802 (in a totally different way.)  Conditional call instructions seem to be pretty rare (briefly existing on 8080 and z80?) (well, and on some ARMs, in their unusual way.)
As for add/subtract, architectures different on where the operands can be.  Some can add/subtract only to the "accumulator."  Others can add/subtract only registers.  Still others want one argument in a register and one in memory.  And on the length of operands.

Only indication you disagree is the words "Not true."
How about load/fetch, add/inc, sub/dec, skip/jump/call/brn/brk instructions. 
Or maybe it was not clear that the writer was referring the command groups. 
Or some other reason I haven't figured out why pointing out that the capabilities or syntax differences of specific commands prove that the writer is wrong in saying that every architecture can.

Ok I think I figured out the reason. 
You are having issue with the "works exactly the same" as meaning literally everything is syntacticly the same.  When I read it as every architecture adds two numbers together the same way, ergo you always get the same result. 
I also see that your primarily issue is that reprogramming for a different architecture is required, and this is what limits you to a particular architecture.  I did not read a single claim that all ASM I completely transportable, because it isn't. 
For some this task is a non-issue.  Once the resource survey is done and the design is done typing in the code in the required syntax in respect to the chip abilities is trivial. 
The programming process has changed or some neither is wrong and both have advantages.  Apparently before your time, multiple debug cycles where very time consuming and expensive, now they are cheep.  For example when I made my adaptive AI in 92 it took over 8hr on a bleeding edge computer to compile, now the same code would take 30min on a normal desktop.  Now programers have the options of faster compiles and can afford many more debug cycles, and the process that was done before has become optional.

[westfw]

Interesting questions:

1) Assume that a modern "Assembly Language" class should actually teach several actual chips, to adequately demonstrate both the similarities and differences of common architectures.
Which chips/architectures should be used?  Do you include x86 and ARM because of their popularity, or omit them because they are so rarely programmed in assembler?  Do you include an ancient classic architecture like the PDP11 because of its influence on things that came after, or exclude anything too old.  Do you include PIC8 because of its popularity, or omit because of its oddities?  (I'd say... PIC8, 8051, MSP430, and ARM.  Except I think four is too many.)

2)What programming exercises or projects do you attempt?  Duplication of HLL constructs to give insight into how compilers work?  ISRs and peripheral handling because that's where ASM still survives?  Primitives, or complete projects?  Live hardware or simulators of the core CPU?  (The assembler class I took in college taught IBM360 assembler on the mainframe, and PDP11 on a simulator.  The latter was particularly unsatisfying!)

3) Do you focus on how things work, or how to get things done?  Tools and techniques, or mostly code?
Emphasize performance, or "correct style" ?  Special features, or aspects in common?

[JohnnyGringo]

ASM is not harder or easier on any architecture.

I think we're going to have to agree to disagree on that one.  I much prefer a multiple-register, orthogonal instruction set with a flat address space (like a PDP11, 68000, or MSP430) and rich addressing modes, than an Accumulator-based with banked code and memory spaces were some traditional primitives are handled by "peripheral registers" (like a PIC, 1802, or 8051.)

There are also architectures where ASM is widely used enough that the assembler itself is well written, and there are "standards" (and support Macros) for various useful things (subroutine linkage, bitfields, structures, etc.)  And others where ASM is just something you write the startup code for a HLL...

Lots of code, such as device drivers is still all Assembly based.  My personal favorite was the DECsystem 2060 (36 bits!).  When you get tired of assembly, try some micro-coding. (Which is what assembly gets compiled to). Then you are really programming on the silicon.

[westfw]

My personal favorite was the DECsystem 2060 (36 bits!).

Yes; that was the system I was referring to as using skips instead of conditional jumps.  A lovely machine.
("All a hacker needs is a tight PUSHJ, a loose set of UUOs, and a warm place to shift.")

[micro-coding] is what assembly gets compiled to

Note exactly.  Microcode more-or-less interprets machine (assembly) code.  A lot of modern CPUs are no longer microcoded; RISC instructions are sort of what you get if you make microcode small and regular enough for mortals to understand, or regular instructions so simple that they don't need to be microcoded.

cisco did a lot of microcoded processors, starting with the MCI back in about 1989.  They pretty much had to be abandoned, because 1) it was too hard to find people who could write microcode, and 2) the bitslice chips got left behind, speedwise, as integrated processor clock rates kept going up.  I don't recall ever writing any microcode that actually worked, but I had a try once at modifying the 3MB Ethernet card to provide continuous carrier for use over a microwave link...

The 2060 microcode source is online, BTW...

[rwgast_lowlevellogicdesin]

Well thank you guys for breaking down PICS for me a little bit better. I guess I should give a few more details on my skills and goals.For the last year I've gotten in to micro controllers through the Parallax Propeller and Arduino. I've also taught myself how to use plain old AVR AtMegas and STM32 Discovery boards.

I have been programming in C for ten years, but it has all been on the PC obviously using the Standard Library, up until the last year. Originally I got into hardware because I wanted to understand more about how computers work. I have done a little bit of ASM on the PC but not enough to claim I know assembly. I want to learn Assembly language for two reasons, first and foremost to grasp low level details of hardware on a deeper level. Secondly the Parallax Propeller is a really cool chip, but in order to get the most out of it you need to program in machine language. Its built in interpreted language spin is much slower, and C has just started evolving on the platform, not only that but C on the Propeller does not generate the most compact code.

The Propeller is a unique architecture, it is 32 bit and runs 8 cores round robin that communicate through shared ram. The problem with learning on the Prop itself is there is no beginner friendly ASM documentation. I understand ASM is all about the architecture, but it is also about changing the way you think and breaking everything in to small instructions that just move memory around.

I've heard the AVR is actually a bad platform to learn on because it has so many extra instructions that are specifically implemented to make the C compiler faster. I do have a 68k mac laptop and TI-89 calculator around if the 68k. I also have a book about programming the PIC16f684, and this is why I was leaning towards learning pic first. Then there's always the Raspberry PI and its myriad of online tutorials. As I said Im looking to get my feet on the ground and learn more about CPU architecture, Using ASM in a practical manner can wait until I have a strong foundation and feel comfortable just reading a data sheet of a chip to learn how to program on a new architecture.

[westfw]

Well, you've got the 16f684 book; go for it...

I've heard the AVR is actually a bad platform to learn on because it has so many extra instructions that are specifically implemented to make the C compiler faster.

That's nonsense.
Especially compared to something like a 68000, x86, or even a PDP11.
You can think of an AVR has having REMOVED some elegant orthogonality from those older architectures, so as to leave only enough for a compiler to be happy with, to make room for addressing extra registers.
I have my opinions AVR marketing claims, but there's nothing inherently wrong with its assembly language.

One thing to watch out for, learning assembler on microcontrollers, is that there tend to be a somewhat unbalanced number of bit-manipulation and test instructions and kludges; all very nice to dealing with pins and peripherals, but not necessarily common (or standardized) on/for other architectures.

[westfw]

BTW, it might be especially educational to examine the changes Microchip made when designing the PIC18 chips, to make them "more C friendly."

[WarSim]

If you want something very different try PIC10F220 6pins and the smallest workspace in active production chip I have found.

Seems you already have the book may as well use it. 

[dannyf]

I've heard the AVR is actually a bad platform to learn on because it has so many extra instructions that are specifically implemented to make the C compiler faster.

It is true that it is "optimized" for C but not sure if that makes it a bad platform to learn.

I think how  you move forward is heavily dependent on what you are trying to do. For most parts, the core (or architecture) makes practically zero difference.