Pic microcontoller programming in assembly...

[cvriv]

Im taking a class this fall on programming pic microcontrollers with assembly and theres no book for this class, which kind of blows my mind.

I need a book. I want a real book in hand to learn from. A freind of mine recommended some ebooks what what about a good hardcopy book on the subject? Any recommendations? Also, should i get a book on just assembly language as well? I dont know enough about assembly. I googled the topic and ive seen many specific books involving assembly.

What do you recommend?

[mariush]

See this : http://ww1.microchip.com/downloads/en/DeviceDoc/33014K.pdf

And this : http://www.covingtoninnovations.com/noppp/picassem2004.pdf

There's a lot of stuff here as well (but not necessarily asm related) : http://www.microchip.com/doclisting/TechDoc.aspx?type=ReferenceManuals

[Howardlong]

Check which device(s) are going to be used in the course. Although there is often similarity between peripherals across the PIC range, there are some fundamental differences between the cores, and even in the same family there are differences (PIC16 classic vs PIC16 enhanced core for example).

It's difficult to put this delicately, and you may well already know this, but not much coding is done in bare assembly language anymore. Having said that, having a working knowledge of assembly language is an extremely worthwhile skill to have when optimising code even if you never write any. While I look at and trace through generated code pretty much every day, it's only about once a year I find I actually have to roll my sleeves up and write a substantial block of assembly language for a given pinch point. Most of the time you can fix performance problems by choosing the right algorithm.

[KL27x]

"Pic googlium tutorials"

[orin]

Check which device(s) are going to be used in the course. Although there is often similarity between peripherals across the PIC range, there are some fundamental differences between the cores, and even in the same family there are differences (PIC16 classic vs PIC16 enhanced core for example).

Agreed - find out what kind of PIC.

For the original PIC16s, there is(was) the series starting with "Easy PIC'n" then "PIC'n up the PACE" - plenty on abebooks.com - you're not too likely to find it new.  I have a copy around somewhere, but I'd bet one of the abebooks sellers could sell and ship one cheaper than I could ship mine.

[jpanhalt]

1) There were books by Microchip (1990's) but they were quickly outdated.   Today, you rely on tutorials (as mentioned), datasheets, and instruction summaries for the device family.   The latter include  descriptions of the instructions and often have more examples.

2) There is a book: "The Art of Assembly" by Randall Hyde (available at Amazon and other places).

3) Microchip also has a series of application notes titled: Tip 'n Tricks.

4) For a list of routines with a little discussion go to Piclist.com  (http://www.piclist.com/techref/piclist/index.htm ) It is somewhat dated now.

5) You will also learn that there are Assembler directives and "pseudo" instructions.  Those will be somewhat dependent on which Assembler (aka compiler) you use.

John

[Flenser]

+1 vote for "Pic googlium tutorials"

The first in the series are free to download. I found them very useful when I first started PIC assembly.

[NivagSwerdna]

Check which device(s) are going to be used in the course.

+1
Some PICs only have around 30 instructions.  You actually need to know at least the opcodes and then the assembler directives, however that's not really the interesting bit... what you are looking to do is use the different hardware aspects of the chip to do something useful.... e.g. timers, usart, etc, it would really helpful to know the device.
You can always program in C and look at the disassembly.... or always program in C 

[KL27x]

Reading a disassembled c code is more fun than... ill finish that when i think of something.

The 30 or so instructions are only the tip of the iceberg. Even once you get past the configuration.

If you doodle around on single page with no guidance, the wheels can fall off the wagon when your code grows past one page. And bad habits can sabotage you in the future.

Then there are assembler directives... what make assembly maintainable and adaptable when the code gets complex. And you can't learn this from the datasheet or an assembly book.

This is why Gooligum (spelling?) does very succinctly what no general book can.... provided you are using Microchip's IDE, in particular. Knowing how to use the IDE tools is almost more important than learning the assembly. Assembly is pretty close to useless without the help of the IDE.

"Learning assembly" is just a vaguery with no practical application. Just a box to tick to say you have read a book or passed a class. "Learning PIC assembly" is a practical and specific thing for which Gooligum is top dog, IMO.

[rstofer]

The problem for the code wienie with PICs has little to do with the instruction set, it's the banking and paging that are a PITA to keep track of.

If you look at the output of a C compiler, you will see about half of the instructions being related to these 2 issues.  Of all the chips to start with, the PIC is the worst.  The upside is the instruction set is small, the downside is the architecture is ugly.

I used CC5X with good success:

http://www.bknd.com/cc5x/

[KL27x]

it's the banking and paging that are a PITA to keep track of.

This is true when you first start. When some small experience, this is second nature. You do not need to keep track of it, because you learn how to write it so it always works, without having to "keep track of it." You will skip some of these redundant instructions, locally, but maintain the "form" when making any jump. One of the more annoying things about assembly, to me, is the pure vertical length of the code. You spend a lot of time just navigating it and copypasting it into multiple windows just to work on it.

I agree page and bank management is a tall initial hurdle, and it is specific to PIC architecture. This is just one of many, many reasons a PIC specific book or tutorial is suggested.

But the ouput of a C compiler is going to have at least 2x as many of these instructions as manmade assembly will need. Possibly 3 or 4x as many, on average. In specific case, the sky's the limit, really. This is one reason why C compilers are not always efficient for 8 bit PIC.

[DimitriP]

What do you recommend?

If it's not a required class, find another.  Especially if you didn't PIC it( coulnd't help the pun)  yourself but  was suggested by an advisor.
If it turns out you are taking it ,find other students that have taken the same class and find out what was going on .
At least you'll walk in with your eyes open.

[jpanhalt]

The problem for the code wienie with PICs has little to do with the instruction set, it's the banking and paging that are a PITA to keep track of.

If you look at the output of a C compiler, you will see about half of the instructions being related to these 2 issues.  Of all the chips to start with, the PIC is the worst.  The upside is the instruction set is small, the downside is the architecture is ugly.

I used CC5X with good success:

http://www.bknd.com/cc5x/

Even with the PIC24 series?   NB: The OP didn't say what PIC was being used.

More to the point, for starters, e.g., a 12F509,  I doubt paging or banking will be much of a problem for flashing an LED.   As the code gets more complex and with newer PIC's, banking becomes quite simple with the MOVLB instruction.  Paging still needs to be addressed, but one advantage the Assembly programmer has is a knowledge of the structure of the code, so paging a can be minimized/optimized.

I suspect the purpose of the OP's class is to learn the basics.  Then progress to a high-level language.

John

[KL27x]

I highly doubt there's a college course teaching assembly on anything other than an 8 bit PIC. Assembly is pretty close to unmanageable on 24F. Even on an 18F, assembly becomes many times less efficient than on 16F.

There's no need to guess. It's 8 bit. Teaching assembly by starting with 24F PIC would be a total failure. There's no teacher good enough to do that. Anyone proficient in assembly for 24F will have to be beyond a genius to translate and convey that into English, or any other human language.

[jpanhalt]

@KL27X

While I agree in context (i.e., the target device is probably a 12-bit or 14-bit core device), I do not think using Assembly on a 24F chip requires a genius.  The instructions are similar, if grouped properly, and the operands offer more opportunities.  That is my Winter project, maybe I will change my mind, but I won't know until 2018.

Right now, I am stalled at the 8-bit enhanced instruction set, as it does what  I need to do.

John

[KL27x]

To learn it, yeah, maybe. But to teach it to a class of uninitiated? We don't have the words for that. If someone told me they could do that in a semester or two, I would not believe it until I saw it. Even if his students are cream of the crop. And it would still be sadistic to not start with 14 bit core.

Even the enhanced instruction set is nothing compared to 24F where you have 20 working registers. Most of the enhanced instruction set can be essentially duplicated by the basic instruction set within the subroutines. Many of the enhanced instructions I had already "created" by the time I first saw it. Some of the enhanced instructions amount to little more than "hey, look. We saved you 1 register of user memory." There is no need for probably more than half of the enhanced instructions. They were probably tacked on when there were bits left over from increasing the core size. Enhanced instruction set is cake and if anything makes assembly easier. 24F is another language, altogether. Anyone that thinks page and bank management is difficult, assembly on 24F is exponentially more cumbersome with threads to track and loose ends that can wreck your day, IMO. Basically, for all the reasons that people think actually programming in assembly is obsolete, these reasons are increased for 24F. You have more memory, more speed, and coding in assembly is more complicated. I have never seen a hobbyist project done in assembly on a 24F. The instruction set is more powerful, but the user manual is more suited to machine/compiler than for human... compared to 8 bit.

[shteii01]

My uC class used Intel 8051.  8 bit uC.  We did a few small projects in assembly and then the rest of the class was in C.

Assuming OP doing something similar.  And judging by all the students from India.  I assume that OP will be using PIC16F877A, it is 8 bit.  There is what?  About 40 years of development using this pic?  20 years of it documented on the internetz.  'nough said.

[Brumby]

I agree that programming in assembler for any serious applications is not really practical these days - unless you are stepping into some rare air where speed of execution is absolutely critical.

Learning assembler programming does, however, bring you down to the machine level, so that you have an appreciation of data structures and what is actually being executed.  IMO this can be very useful when programming in higher level languages when you encounter a situation which is not straightforward.

I would encourage such a course, as long as its objective was not to send you out as a commercial assembler programmer.

[Zero999]

+1 vote for "Pic googlium tutorials"

The first in the series are free to download. I found them very useful when I first started PIC assembly.

If you're strapped for cash, you can also find older versions of the course, when the whole thing could be freely downloaded, if you know where to look. Otherwise buy the whole series. It's very good and easy to follow.

On a side note: should a beginner start with assembly these days? I can see how it's useful to know, even though it isn't something that one will use a lot nowadays but perhaps it's not the best place to start?

[CJay]

I think there's a foundation to be learned with assembler programming but as much as I like PIC chip they're a PITA to program if/when you need to take page registers into account, they're not *difficult* to use but they're more awkward than they could be.

I can program assembler and have on 16F and 18F but C makes them so much more friendly to use.

[fcb]

I still program in PIC assembly - rarely use C, but I do a fair bit of DSP stuff (dsPIC33) - and a lot of realtime stuff with PWM, ADC's, timers etc..

Love the ICD3 and it's realtime debugging. I would say that assembler is slower to program than C, but easier to debug - but I spend alot of time designing the structure of the firmware before I write a line of code (be it assembler or C).

Personally I would say spend a few days learning and playing with the PIC16F54 building a few simple projects before progressing onto the devices with peripherals.

[Howardlong]

For inspiration on what can be achieved in PIC assembly language, Voja Antonic is your man.

http://www.voja.rs/PROJECTS/npr.htm

[rstofer]

PIC assembly code can be quite nice to look at given a little extra effort in things like formatting.  After a couple of years messing around with it, I thought I had a pretty good handle on it.  What you don't want is a pile of spaghetti code wandering all over the pages.

It is worth knowing something about assembly language because it comes up from time to time.  For example, the startup code for the ARM7TDMI is written in assembly with a fair number of globals/externals.  Later versions of the ARM have done away with this requirement but you still run across it from time to time.

Then there is old school like the 8080 and Z80 where a lot of the code was written in assembly language.  Lots of it!  So, when I wanted to bring up the CP/M operating system on an FPGA version of the Z80, I was right at home.

If I knew I had a class coming up, I would be all over gooligum.  That $70 base kit and tutorial package would already be in the mail.  Nothing like getting ahead of the curve.

I tend to like the AVRs but I'll concede, the instruction set can be overwhelming.  The good news is that the architecture supports C and I write darn little assembly code for the AVRs.  The ARM instruction set is similarly overwhelming.

For comments on the productivity of programmers:

https://en.wikipedia.org/wiki/The_Mythical_Man-Month

If a programmer can only write about 100 lines of debugged code per day, they had better be using a high level language.

[KL27x]

PIC assembly code can be quite nice to look at given a little extra effort in things like formatting.

I have written a lot of long code in assembly. 5 or 6 code pages... which is roughly on the order of 100 pages if printed out. I'm not suggesting anyone do that, but I have learned a thing or two about managing assembly.

As far as the code format, one thing I have evolved it to double indent the bulk of the code. Single indent on lcall's/pagesel and bank changes. No indent on jumps/returns.

The code history .txt is the most important doc of the bunch. I document what I'm going to do with "o's", there, and check of the boxes as I complete them, changing them to "x's". Of course always backup often, and use revision numbers between iiterations.

When revising or adding new code, I copypaste all the pertinent parts of the code into a scratchpad window (or two). Do the revisions there. I can scroll through the main code to look at the original code which I am modifying.... so that I will never double fix a logic error. And I can scroll the main code and have my scratchpad window side by side with any other pertinent code. And then copy this back in at the end.

When trying something that makes more than a minor change, which might break the code and make it worse, I will use assembly directives to try the new code. With the change of a constant, I can remove parts of the original code and replace them with the experimental code, and back again.

indented labels are one of the most important tools. No matter where you put them, you can get them to show up in the MPAB warnings. So whatever part you are working on, you can find, quickly. The IDE has tool to jump to labels... but it will only show the labels in the one file... not across all of them. And anyhow, you may have hundreds of label in a large code. (It also has a bookmark tool, which IMO is very cumbersome, and split screen tool which sounds great, but in practice it doesn't seem to work the way it needs to in order to be useful.)

And never.... never use macros. At first, you will think they are the best thing ever. Then you will busily convert a ton of code into macros. Then when you find out they conceal location of errors, you will pull your hair out.

The coolest thing about assembly is you have complete control over the device. I suppose if you completely understand functions of your specific C compiler (for which you would need to understand assembly even beyond the ability to write it), you would at least know exactly what your C code is doing. But building it yourself, your code works exactly how you need it to for specific task.

Take example of woodworking. I can buy a fancy general purpose jig that will do what I need it to.... along with perhaps many other variations of this task which might be useful in the future. This is C. Or sometimes for a specific project I can build a simple jig that does what I need, better (going back to the microcontroller, we're talking in terms of speed, code space, memory, execution speed, and/or repeatability of execution timing). Chances of it being useful in the future are perhaps slim. But I can build it differently for different tasks. This is assembly. You learn how to build your own tools, if you want, starting with stones and files and a microscope. So starting out with a full shop of Veritas planes and commercial cabinet saw and router table et al is going to allow you to make more cabinets and chairs, faster and easier. Having access to stones and files, you will be able to make and modify tools for building cabinets. Eventually, you will have enough tools to build basic furniture, and some of them will be unique. And you will have a different understanding.

My woodworking and approach to coding is similar. If I want a nice cabinet, I will buy it. If I need just some of the functions of a cabinet, and it has to fit in a specific odd space, in my particular house, I might build it. If I were the last carpenter on earth, I could eventually build something remotely resembling and functioning like a nice, cookie-cutter commercial cabinet.

[cvriv]

Wow so many replies! Sorry for the late reply. I have to read through this well.

We're going to be using a PIC16F883 controller.

I'll reply again in a bit....