Shay

had seen mention of PIC microntrollers over the past few years. hadn't acquired practical setup/skills to program microcontrollers yet. just had a small portable computer hooked to my PC via RS-232, used it for basic I/O to a breadboard. had programmed an Atmel microcontroller a while back, but never did anything with it.

practical project opportunity occurred. I wanted to make a custom solution and figured it'd be a great time to use a PIC. I remembered reading about them having simple serial programming (In-Circuit Serial Programming). I scanned the web for info on them. found Microchip's website. determined what basic model I needed. found Digi-Key as supplier. 16LF628 was cheapest one with basic features and low power, at US $3.80 per unit. I ordered a couple to learn with.

armed with the downloaded PDF format manuals from Microchip, my I/O lines and a breadboard, I made a workable programmer. I had written an assembler and linker for another 8-bit microprocessor, and retargeted this. The PIC instruction set was very easy to incorporate, as it has a small number of instruction formats and all instructions are the same length (one thing I love about programming RISC machines, like the PowerPC platform).

my goal was to make the project with around US $10 investment in parts. I achieved this.

I didn't like the idea of doing a whole erase reprogram cycle for each edit-test cycle of development, so I put my mind to ways of reducing erasure of the program memory. At first I modified the program algorithm to use erase-program cycles on individual locations that needed to be changed, avoiding ones which stayed the same. This accomodated small tweaks to code, but didn't do well with large changes. A small improvement to this was avoiding the erase when bits were only being cleared in a location.

I envisioned a scheme which moved the start of the code through the program memory, finally filling it and requiring a bulk erase. The assembler I wrote allows breaking the code into many blocks per file. This allows the linker a much finer granularity for dealing with the code. I finally implemented this scheme, and it came out very nicely. The linker only relocates any new/changed blocks of code between edit-test cycles. So if you had a delay subroutine which didn't change, it would only be programmed into the device once. The only fixed locations in the device I use are the reset and interrupt vectors. These must be redirected when their destination code is moved (due to it being modified). I worked out a scheme for these which used a two-layer indirection and also avoided any erasure. This allows 64 total changes to each of the vectors between bulk erases. Basically the scheme starts out with a goto 0x7FF at the vector, and at 0x7FF a goto user_code. When user_code moves, the goto 0x7FF is changed to goto 0x7FE, which doesn't need an erase cycle. At 0x7FE a goto new_user_code is placed. This will start to leave holes in the high memory space. These are filled by erasing a goto to nop, then putting a goto after that. Once 16 total gotos are placed in high memory, the base goto 0x7F0 is erased into a nop, then a goto 0x7EF is placed after it, and the process begins again. At most, this double indirection scheme adds 14 cycles of overhead (2 goto + 10 nop).

So far I've made the original timer project, used the second PIC chip to make a programmer from scratch, and interfaced an IR receiver module to my PC to allow remote control of music track and volume. I think I'll be making more useful little gadgets in the future. I am thinking of little data-collection devices.