PIC in common use
16{C/F}5x coding issues
Some of the instruction limitations are just 'annoyances' (such as the fact that a subroutine CALL destination is limited to the first 256 bytes of each memory page), which can be 'worked around' (eg by using 'indirect Call' tables - at the cost of at least 2 extra instruction cycles per 'Call').
Others - such as the fact that there is no 'increment Accumulator' (aka W "register") and the 'Inc/Dec register skip on Zero' instructions does not set the Z flag - enforce fundamental restrictions on your coding approach (whilst waiting to 'trip you up' should you forget which instructions effect the Status bits (and which do not)).
If you do ANY assembler coding, I suggest you do it with a print-out of 'Table 9-2: Instruction Set Summary' from the PIC16F5X pdf manual in front of you !
Alternatively, do what I did = just write your own 'macros' with easier to remember mnemonic instruction names
Microchip MPLAB IDE
If you think a web page CMS ('Content Management Systems') are a real pain, you should try Microchip's IDE ('Integrated Development Environment').
Written for DOS users, it can be a real pain. HOWEVER it has one VITAL advantage - it offers full MACRO support, which allows you to write your own Macro 'library' and thus 'replace' Microchip's total confusing and non-intuitive 'instruction names' with your own !
'Blink that LED'
Most PIC programs are written to 'blink a LED' when they start running in order to provide some 'instant feedback' to the user (and show that the code is, in fact, 'working').
However most PIC projects quickly find a use for every i/o pin, so you will soon run out and start looking to 'double up' the function of some pins
The 'serial output' pin is the most obvious one to 'double up' as the 'blinking LED' drive - with the advantage that (if you run the 'bit banging' code slow enough) it's even possible to send visual messages :-)
LED drive
When driving multiple LED's you need to watch out for the PIC current limits - you may have 20mA 'per pin' however you are limited to 50mA 'per PORT' and 100mA for the whole device.
If you only need to use one or two cheap 15-20mA LED's that's fine - but if your design calls for half a dozen or more, should stick to high efficiency 3-5mA LED's When choosing current limiting resistors, remember the PIC16F5x will only be running at 3v3 if it's being clocked at 10MHz or less. Above this (up to 20MHz) and you have to use a 5v supply - or even higher, if you are overclocking.
Pulse drive
You can 'pulse drive' a LED with higher 'instantaneous' currents so long as the 'average' is within both the LED and PIC power limits
But watch out for 'power-on' pin state and consider what might happen if your code crashes :-) One trick I use is to pulse drive the lED via a small capacitor and (current limiting) resistor - if the i/o pin 'sticks' the LED stops 'blinking'
A LED driven with double the current for half the time appears a lot brighter to the human eye than one driven with the normal current all the time
Bi-colour LED's
These come in 2 types = 3 wire and 2 wire (two 'back to back' LED's). You can drive the 2 wire type using a single i/o pin = but usually only so long as your PIC supply is 5v (or more).
The trick is to wire the i/o pin to one end of the LED and the other end to a pair of resistors forming a 'divider', with R1 from 5v power to LED, R2 from LED to Gnd. R1 and 2 are calculated from the bi-colour LED If (mA) and Vf ratings and the PIC i/o pin voltages (typical values are 100-133 ohms, with the least bright (and thus highest current) colour on the R1 = 'Pull Lo' side of the i/o pin) With the i/o pin tri-state, the LED is off. With the i/o pin 'Lo', current flows from R1 via the LED and into the i/o pin. With the i/o pin 'Hi', current flows from the i/o pin via the LED and to Gnd via R2 If you are using battery back-up, be aware that current will constantly flow from power to Gnd via R1+R2 = so wire R1/2 to the 'main power' and NOT the PIC/battery supply :-)
At power on, PIC i/o's are 'tri-state', so as soon as one LED lights up you know your software is 'working'
Serial comms
If you want to communicate with a PC, you don't need an expensive PIC with USB capability (and no room for anything else)
Instead you can program the PIC to 'bit bang' a serial data stream and pick that up at the PC using a Serial to USB dongle
Serial is a lot easier than using the Parallel (Printer) Port, especially as so few modern PC's actually have either a Serial or Parallel Port (and whilst Parallel to USB dongles do exist they are rather 'specialist' (i.e. both temperamental and expensive)
More to the point, the industry standard 'I2C' serial comms protocol is directly supported by many peripheral chips such as RAM / EEPROM (storage) and analogue processing chips (amplifiers, DAC's etc) which are likely to find their way into your projects.