Getting started with PICs. Looking to learn ASM

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