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

[Ian.M]

Not a bad PIC to learn on - its still a classic midrange core but is a lot more modern than a lot of the PICs that have been mentioned and has built-in silicon support for in-circuit debugging with any Microchip debugger.  Microchip used to bundle the high-end part from the same datasheet (PIC16F887) on a demo board with the PICkit 2 as the PICkit 2 Debug Express kit, which came with a reasonably good set of introductory assembler tutorials.  Apart from stuff being on different pins, it would largely be applicable to your PIC16F883.

PIC16F887 44-Pin Demo Board User's Guide (includes tutorials)

PICkit 2 Debug Express Lessons (PIC16F887)

[cvriv]

Ok... I got through all the replies. Thanks to everyone for all the information.

I am definitely using a PIC16F883 for the class and we are definitely programming it with Assembly. I find it extremely frustrating that there are more online tutorials/ projects than actual books available. I actually prefer to read and learn from real books, but i guess i dont have a choice.

I will check out the Googlium thing and see what thats about. I actual have a friend that took the class already and he texted me some ebooks that he used. I trust this guy because he's very smart. I just thought that maybe there was a book or books I could buy.

I actually wanted to take C++ before taking this class, but the professor was like no! He saod in this class we're doing Assembly. He said to take this class now because its only available once a year. So i was like..... Ok.

I saved the projects folder for this class before the end of this semester, so I know what all the projects are going to be. I can actually get started over the summer if i want. The proffessor is awesome because if any of us have any trouble doing it over the summer, he'll arrange to meet to help walk us through any problems we may have. He said we dont really need a book and that all we really need are the data sheets project whatever. Im assuming its all in this folder I have on my PC.

I dont know anything about assembly... I just find it to be weird that i im going to learn this with datasheets and tutorials etc. As said, im used to learning via a book.

[CJay]

There are plenty of PIC books out there, but there's such a *lot* of information out on the web that all you need is the datasheets and some good tutorials, the Gooligum Electronics ones are good.


Most of the learning I did from datasheets and experimenting though if you're determined to have a book then I'm sure I'll get shot down but I got on well with the Myke Predko books, there may well be better out there now.

https://www.amazon.co.uk/Programming-Customizing-PIC-Microcontroller-Electronics-x/dp/0071472878

They seem to have been abandoned now but the need for the web resources were minimal anyway and the books should come with CD

[NivagSwerdna]

This is the book I bought...

https://www.amazon.com/Embedded-Design-PIC18F452-John-Peatman/dp/0130462136/ref=asap_bc?ie=UTF8

but that was >15 years ago... I imagine there is a lot that hasn't changed if you are using 16F

(I would not recommend buying a new copy at >$130 !!)

[jpanhalt]

@cvriv

I suspect not many Assembly programmers actively use flow charts on a day to day basis.  Until the instruction set becomes second nature, a flow chart will allow you to break down the assignment into smaller manageable tasks.  It is also useful for getting the whole picture and reducing go to's (part of creating spaghetti).

The program I used  was Lucid Chart (https://www.lucidchart.com/users/login).  It was free, but it has been awhile since I opened it, so that may have changed.

John

Edit:  I am not recommending "flowcode" and other programs that claim to convert a flowchart to actual code.

[Ian.M]

I think all the paper books out there for PIC assembler are badly out of date.  Certainly the principles haven't changed, but the tools and chips have.   The only reasons to get a paper book is if your first language isn't English and a good introduction in your native language is available, or if you can only learn effectively by marking up a paper book with lots of annotations and hilighter.   Even so, for the latter, you'd do better to print out the Gooligum tutorials single sided to allow lots of room for notes and have them spiral bound.  You'll be hard-put to find anything else that covers Midrange PIC assembler and is as up-to-date as the Gooligum tutorials.

Personally, if I were you and I was trying to make every dollar count,  I'd invest in the Gooligum tutorials, a breadboard, a PICkit 3 clone, 3x every PIC used in the Gooligum tutorials + 3x PIC16F883, and a selection of LEDs, switches, resistors etc.  If budget isn't an issue , I'd swap the clone PICkit 3 for a genuine one and swap the Gooligum tutorials for their Baseline and Mid-Range PIC Training Board, which includes the tutorials.   

[KL27x]

I dont know anything about assembly... I just find it to be weird that i im going to learn this with datasheets and tutorials etc.

That's the thing. If you read the instruction set in the datasheet, it describes what each instruction does. Once you wrap your head around the memory structure (also in the datasheet), binary and hex, and you understand the format of this data, this IS PIC assembly. You could almost start writing assembly by stringing together instructions. Your actual code will mainly consist of direct use of the native instruction set of the device.  But this is the easy part. (Other parts will be pseudo instructions, configuration, defining memory, and assembly directives, initializing EEPROM).

You might want to take a peek in the folder you got. Maybe he has provided some basic info to get you started. If you just want to get an A and move on, this (and the datasheet) might indeed be all you need. But if you want to learn to use PIC assembly in practice, Gooligum is untouchable. Head and shoulder and ankles above the rest, IMO. And as Ian suggested, to print it out, the tutorials ARE books. Very concise and organized books that should be easy to print out. As well, you should print out the entire datasheet of the 16F883 as well as the devices for the Gooligum tutorials, if you choose to try them. But I suggest you print out the datasheets in 2:1 book format and bind them. That is some labor involved, but it will be much handier. The datasheets will be a near constant reference, and a PDF doesn't cut it. You will have two or three fingers in it at times, flipping back and forth to put all the puzzle pieces together.

[StillTrying]

We're going to be using a PIC16F883 controller.

You can program and run it long before you get the uP, in the MPLAB SIM.

[KL27x]

Btw there is also an active forum over at the microchip website. Ian and ric are seemingly able to answer everything. I suspect one or the other wrote these tutorials.

[Ian.M]

No. David (Mr. 'Gooligum'), user meikled on the Microchip forum, isn't in any way connected with my self, other than by a number of public discussions on the Microchip forum, and to the best of my knowledge isn't connected to Ric (on Microchip forum, and also his own forum http://picforum.ric323.com/), either.

[lowtech]

PICmicro x14 Basic Training Modules. I know it's x14 but a lot of the basics are there.

http://techtrain.microchip.com/x14/

The following modules are available to help you familiarize yourself with the PICmicro MCU. Each module is an animated movie with audio.
PICmicro x14 Architecture
PICmicro x14 Instruction Set
Development Tools Overview
PICmicro x14 Device Configuration
PICmicro x14 Resets
PICmicro x14 Oscillator

Just received my pickit 3, still waiting on my Gooligum training board, which includes all tutorials. I hope to start next week.

[Ian.M]

x14, more commonly called the 14 bit core, is just what you need for 'classic' Midrange parts like the PIC16F883.  The core hasn't changed any however those videos are way out of date for the toolchain.  They refer to the original ICD debugger and mention the obsolete C17 compiler for the discontinued PIC17 range, which means they are probably circa late '90s and use the old 16 bit Windows MPLAB 5! 

[lowtech]

Good to know Ian. Since I'm new to this as well, which of these are worth watching? Evidently not the Development Tools Overview.

[Ian.M]

Personally, I don't like video tutorials^*  - I'd much rather have text, diagrams and images (and optionally short <2min video clips to show particular techniques and manual skills), so I'm less than keen on any of them.  However if you learn well from videos the first two + resets should be worth a look.  The remaining two, Device Configuration, and Oscillator are still valid but of course don't cover t newer device features like multiple config words or internal oscillators.

* When I learned the Midrange (14 bit core) on the PIC16C84, video wasn't really an option.  IIRC we'd just got ISDN at work, I believe I'd acquired a MPLAB CD at an exhibition, and I hammered the ISDN connection grabbing datasheets, FAQs and schematics and sourcecode for a Tait programmer.  I've still got the binder full of printed off datasheets . . .

[FrankBuss]

I dont know anything about assembly... I just find it to be weird that i im going to learn this with datasheets and tutorials etc. As said, im used to learning via a book.

I learn best with examples and writing programs myself. I think the PIC assembly language is not the best to start learning assembly, because the small instruction set makes it more difficult. I can program in PIC assembler, but it is still always twisting a little bit my brain when I have to program "skip next instruction when some bit is set", and then the next instruction is the actual branch, or the strange things I have to do to implement a simple lookup table (and be careful with page boundaries if you try this), which is one instruction with other assembler instruction sets, like 6502. Bank-switching was not a problem for me, because I just select the bank all the time before I access something when in doubt.

That said, you should install the MPLAB-X IDE. It is free and has an integrated simulator, which is very helpful, because you can single-step through your assembler program and see for each instruction how it changes registers, and you can even create a virtual "oscilloscope", where you can see the waveform of a GPIO pin which you control from your program, all without hardware. Then you can start with a tutorial program and see how this works. Then enhance the tutorial program and soon you know PIC assembly.

But of course, would be best if you try it on real hardware. Buy a PICKit3 programmer (there are cheap clones on eBay) and a few PIC16F883, and a solderless breadboard if you don't have already one, and things you want to do with it, like LEDs (with resistors in series), buttons and sensors. Then think of a simple project, for example a button press should be delayed and light an LED (as I did here), and try to program it yourself. This is the best way to get good at programming: not by reading books, but by programming. But to read an introduction book first, what assembly is at all and how a CPU works, might be helpful, if you don't know this already.

[rstofer]

I actually wanted to take C++ before taking this class, but the professor was like no! He saod in this class we're doing Assembly. He said to take this class now because its only available once a year. So i was like..... Ok.

If assembly language is as close as you can get to the hardware, C++ is about as far away.  You will be coming at computers from both ends.  Not a bad plan!

I started with Fortran IV and migrated down to 8080 assembly language.  I was a bit slow on the uptake but one thing I think I have learned:  It isn't about the language as almost any program can be expressed in almost any language, it's about the data and how it is manipulated.

I'm of the opinion that coding is just a matter of applying patterns.  There are specific ways that various operations are coded and I like to think of them as patterns.  A loop, indexing an array, basic math, subroutine calls and returns; each of these operations will eventually degenerate into a pattern.  There may be alternatives and you will probably select one based on your personal taste.  It is still a pattern.

When you get to 'banks', you will see where it is useful to have a written map of where you want to put various data items.  It is best if related items are in the same bank as this reduces bank switching.  I sometimes copy the memory map out of the datasheet and draw on it.

See page 6-10 here:
http://ww1.microchip.com/downloads/en/DeviceDoc/31006a.pdf

While I am on the subject, read that document and follow along.  Put it under your pillow at night if you think it will help.  Everything you need to know about paging and banking is in that document.  Notice the special area at addresses 70h..7fh.  Regardless of the bank selection, you always get the same data.  There is only one copy and it allows access to those 16 bytes without worrying about banking.

The map in the above document is generic and it doesn't apply to the 16F883 directly.  Instead see the actual map here (Page 24):

http://ww1.microchip.com/downloads/en/DeviceDoc/41291D.pdf

In addition to datasheets for various families of chips, Microchip has a small document describing all of the mid-range CPUs.  It is a mere 688 pages and there will be a test later:

http://ww1.microchip.com/downloads/en/devicedoc/33023a.pdf

Read question 4 on page 29-45 and when you think you understand it, I assure you, you do not!  This Read-Modify-Write thing catches a lot of programmers.  And then you will come up with the idea of shadow registers where you keep a copy of what has been sent to the port.  You modify the shadow register (just a byte of memory somewhere) and then send it to the port rather than reading the port and modifying individual bits.

You said you wanted a book!  Well, there it is...

[rstofer]

@cvriv

I suspect not many Assembly programmers actively use flow charts on a day to day basis.  Until the instruction set becomes second nature, a flow chart will allow you to break down the assignment into smaller manageable tasks.  It is also useful for getting the whole picture and reducing go to's (part of creating spaghetti).

The program I used  was Lucid Chart (https://www.lucidchart.com/users/login).  It was free, but it has been awhile since I opened it, so that may have changed.

John

Edit:  I am not recommending "flowcode" and other programs that claim to convert a flowchart to actual code.

I wonder if they even teach flowcharting to CS majors these days...

One thing I like to do is write a kind of high level pseudo code of what I plan to do.  I can have a lot of detail or a little depending on the complexity.  Regardless of the target language, the pseudo code is a map toward the end result.  Which kind of leads back to my comments above on 'patterns'.

In the old days of Fortran and batch computing, there were three blocks of code:  Input, Crunch, Output.  Every program did the same 3 things, the code was just the details.  Sometimes there was a loop around the 3 blocks.

I always started with the output I wanted and worked back toward the input I needed.  I know it is totally obvious these days but, at the time ('70-), it took a while to understand these things.  I wasn't the brightest bulb...

[jpanhalt]

I wonder if they even teach flowcharting to CS majors these days...

One thing I like to do is write a kind of high level pseudo code of what I plan to do.  I can have a lot of detail or a little depending on the complexity.  Regardless of the target language, the pseudo code is a map toward the end result.  Which kind of leads back to my comments above on 'patterns'.

What you describe as "pseudo code" sounds like a flow chart to me.   You have processes (rectangles) and decisions/branches (diamonds) and outputs (if you chose to use them).   Anyway, pseudo code, flow chart, recipe, or whatever you call it, will help avoid spaghetti code and is an aid to the beginner.  It was to me. 

I can't imagine a college-level course on "flow charting."   What did they do for the remaining 74 days after the first hour on day one?

John

[rstofer]

I wonder if they even teach flowcharting to CS majors these days...

One thing I like to do is write a kind of high level pseudo code of what I plan to do.  I can have a lot of detail or a little depending on the complexity.  Regardless of the target language, the pseudo code is a map toward the end result.  Which kind of leads back to my comments above on 'patterns'.

What you describe as "pseudo code" sounds like a flow chart to me.   You have processes (rectangles) and decisions/branches (diamonds) and outputs (if you chose to use them).   Anyway, pseudo code, flow chart, recipe, or whatever you call it, will help avoid spaghetti code and is an aid to the beginner.  It was to me. 

I can't imagine a college-level course on "flow charting."   What did they do for the remaining 74 days after the first hour on day one?

John

I don't know what they do today but I have IBM documentation from back in the '60s and it often contains flowcharts that were dozens of pages.  In fact, you can follow the assembly code directly from the flowchart, it was that detailed.  The stuff was all printed on a line printer so they must have had a very slick program for drawing it.  For that matter, their logic diagrams were also drawn on a line printer.

Again, back in the old days, I visited some business programmers in another department.  They wrote all their code in COBOL and the flowcharts they created were extensive.  Old school...

Flowcharting itself is pretty easy.  Program structure is the hard part.  In some ways business programming is much more complex than simple embedded programming as the decision trees can be quite complicated.  Think about sales taxes that vary within a state, county or city.  I'm not sure what a company's obligation is in terms of how far down they need to dig but I'm betting the problem is non-trivial.

My pseudo code turns out to look a lot like C without the proper syntax.

[ggchab]

I started with 16F84 et 16F877. Instructions set is not that difficult to learn but segmentation of memory (program and RAM) is a bit annoying. Something else that caused me many problems was the limited levels of the hardware stack. If you do too many nested calls, you might never come back to the instruction following the first call. Now, I am using PIC18F (18F25K22). There are easy solutions to most of the previous problems (far less need to switch between banks, 31 levels stack,...). I like programming them in assembly. This is not very time efficient but as a hobby, this is a lot of fun.
I also find very important to add a lot of comments. I document each blocks of code and, frequently, instructions themselves.
When I started programming PICs, there was a lot of Web sites to teach programming 16F84. For the others, I simply used the documentation of Microchip (printed copies). I find it well structured and easy to read.