Part I of this article discussed the MQ game itself and a bit about the wand IR transmission and protocol. Today covers how the actual wand decoding is done in PIC assembly. This project uses PIC12F508, a little tiny member of the 8-bit PIC family. It’s adequate for our simple tasks, but doesn’t offer a lot in the way of code memory (768 bytes) or RAM (25 bytes). It’s easy to eat up both RAM and code memory using the careful and sometimes inefficient path of C compilation, so we’re going all the way down to asm today – PIC assembly. Assembly language is a very low level language, meaning that each statement you write does something very simple and also that each statement translates directly into one logical instruction the device will execute. You’re writing machine instructions essentially, and the compiler is just search and replacing them with the hex opcodes that will be programmed into code memory. Cool! Assembly certainly has it’s pluses and minuses, but is highly revered here.
Let’s start with the downside of assembly: It’s WAY low level, with absolutely no abstraction. Without good documentation, it can take some time to see the big picture – or what exactly each piece of code is doing. Simple things take many instructions, and complex things can take thousands of instructions. That’s a major turnoff for the grab and go crowd, and definitely limits what types of things you can write in asm – you sure won’t be writing a Linux kernel in asm, but for the parts that you actually want to run fast on a specific machine, yeah, it’s worth it. Which shows us the upside: There is absolutely no other way to get tighter or faster code than assembly, which can be extremely important in a high-performance number crunching routine, and sometimes essential in a little code-limited micro.
Funny story – a previous project had a simple routine that needed to fit in 0×100 (256) bytes. We first wrote it in C, which compiled to some obscene size using MPLAB C. Fail. Compiled to way over the required size using the HITECH C compiler, and about 1.5x with SDCC. Rewritten in assembly, it compiled to it’s verbatim 0X56 (86) bytes. Win.
So if you’re not an assembly guy, at least consider it for your next project. Maybe by walking you through a few simple tasks, you’ll see that it’s not that daunting and the learning curve is actually quite shallow for RISC devices like the PIC or AVR. One thing’s for sure: It allows you (forces you?) to obtain a good understanding of the physical implementation of the device you’re working with, which then allows you to operate on a very efficient level. But hey, if you need abstraction you need abstraction – high level languages abound.