MPLAB X IDE – Header Files

22 February, 2014 (17:22) | PIC | By: Joshua

As I have been struggling to figure out MPLAB X IDE, I was trying to find the source file for my header file, xc.h to find the names of pins and configuration registers. Yet every time I clicked on the file itself, it wasn’t giving me anything. I finally found the issue is that xc.h is simply an intermediary file, which your program points at, and then depending on the model PIC you’re using, points you to the actual header file for that PIC. Once I read that, I realized that this is not new, it had just been awhile since I had thought about it. It was then very easy to find the actual header file for my PIC.

For a more in-depth tutorial, I found this helpful site.:

MPLAB X IDE – Updated Config Setting Procedure

18 February, 2014 (17:19) | PIC | By: Joshua

It has been awhile since I’ve worked on any PIC projects and I had my first experience with MPLAB X IDE just recently. Right off, I was getting errors for my CONFIG statement and I couldn’t figure out why. It turns out, MPLAB X IDE didn’t like my hand jamming and wanted something with a little more finesse.

The new MPLAB X IDE has a nifty little interface where you tell it what settings you want, and it generates the code for you. You then take that code and copy and paste it into your file. This is not new, but I like the way it does it. The generated code is very organized and well commented so that you know exactly what is going on.

A great in-depth tutorial on this is found here:

Soldering Amorphous Solar Cells and Conductive Epoxy

14 August, 2013 (20:19) | Projects | By: Joshua

In a word, don’t. Or, better said, you can’t. Or perhaps more accurately, I can’t do it well and everything I’ve read and done seems to agree that it’s not a good idea.

Amorphous solar cells are the cheapest, least efficient solar cells on the market. You’ll find them in cheap products that don’t have a high need of extreme efficiency or space utilization. As they’re mostly in cheap products, the systems they’re placed in are prone to failure, which makes them very available for any hack work that you want to do.

If you do get your hands on one of these and want to do a project, don’t waste your time, money, and sanity on trying to solder onto the backplane. Get some conductive epoxy or conductive tape and simply glue/tape your wires in place. It’s non-ideal and doesn’t have the solid physical or electrical connection that a good solder will, but it’s a lot better than the frustrating process and unbelievably weak solder points that you’ll get soldering. You also should have realistic expectations of the resistance of the epoxy. I’m certain not all epoxies are created equal, but I’m measuring in the tens to hundreds of ohms across a few millimeters of epoxy (Radioshack Conductive Wire Glue). My recommendation: Put the connections together and make sure they’re actually touching, with the epoxy enclosing and sealing them, but not separating them.

Boot Alarm – Part 3: The Setup and Finale

10 August, 2013 (01:41) | Projects | By: Joshua

So, sadly, life caught up to all of us here at and there has been a … considerable… gap in our posts. However, this project actually did go forward and was completed successfully, even though the second “improved” version was not successful, which was followed quickly by a combination of apathy and distraction and the Boot Alarm has moved from reality into legend.

Anyway! That being said, I decided to go with a Microchip microcontroller based infrastructure (the PIC 16LF877A) which used a Sparkfun Nordic Wireless transceiver (, a vibration sensor, an eight ohm speaker, two LEDs, and a mini-USB port to charge the Li-ion battery.

It ended up being rather gimmicky as there was a switch on the bottom of the boot that you flipped to turn the Boot Alarm on and off. Theoretically, if you knew anything about the Boot, all you have to do is flip that switch and the whole thing is rendered useless. That was changed to a keyswitch in the second, though failed, version. Once the Boot Alarm was on, I could hit the keyfob to arm the Boot, providing the satisfying chirping sound. When the Boot was armed, the two LEDs (oh, so cleverly inserted into the eyelets of the Boot) would flash slowly. If the Boot was moved or shaken more than just slightly, the speaker would start to wail (I basically just wrote a tiny script that increased the oscillation on two pins until a certain point wherein they would drop back to a lower frequency and work their way up – it was a pretty obnoxious sound) and the LEDs would flash quickly. The only way to turn it off was the aforementioned power switch or the keyfob.

I’m attaching the work so you can peruse it, please don’t judge – learn instead. Also, some pictures of the end result are shown on my account at: Boot Alarm Prototype Success

These are from version 1. The second version I cleaned up some power regulator issues and also tried to integrate the wireless on my own board but screwed up the antenna traces. It was a pretty board… just not functional. Let that be a lesson.

The schematic: Boot1Schematic
The layout: Boot1Layout.pdf

Here’s the C code, it still contains a large portion of the code that I used to communicate with my computer for debugging purposes:

/* C Code for the Boot Alarm version 1.0
* Designed with a PIC16F877A @ 4MHz with a Nordic NRF24L01+ transceiver
* Communicating with a Sparkfun Keyfob that also utilizes the NRF24L01+ transceiver

#include "wait.h"
#include "uart.h"
#include "spi.h"
__CONFIG(0x2F49); /* Oscillator - XT, WTD - OFF, PUT - OFF, BODEN - ON, LVP - DISABLE */

void siren(void);
void arm(void);
void disarm(void);

/* Pins for the SPI comm with Nordic */
#define CSN RD2
#define SCK RC3
#define MISO RC4
#define MOSI RC5
#define CE RD3
#define IRQ RB4 // Active-low

#define VIBRATE RB0 // Pin for vibration sensor.

#define BREAK transmit(10); transmit(13) // Hard return in PuTTY
#define WAIT wait_us(1)

/* The keyfob sends a different code for when a different button is pushed. These are the definitions saying which button does what. */
#define ARM1 0x1D // The top button will arm the boot. (Where the key ring does NOT go is the top)
#define DISARM1 0x1E // The buttom button will disarm the boot.
#define ALARM1 0x0F // The center button will start the alarm.
#define ARMCHIRP1 0x17 // The left button will give the arm chirp without arming.
#define DISARMCHIRP1 0x1B // The right button will give the disarm chirp without arming.

unsigned int y, status, data1, data2, count, debounce;

void main() {
int x;
TRISB = 0;
TRISB0 = 1; // Make input for vibration sensor
TRISB4 = 1; // Make input for IRQ
TRISD7 = 0; // Make output for buzzer
TRISD6 = 0; // Make output for LED
TRISD5 = 0; // Make output for Status LED
//RBPU = 0; // Turn on the weak pull-ups on PORTB
SPIsetup(); // SPI Setup
CE = 0; // Keeps transmitter from looking for a signal. Must toggle to use chip.
CSN = 1;

/* UART Setup */
/* Let things settle */
for (x = 0; x < = 100; x++)
/* This is the entire sequence to setup as a receiver. Needs to be cleaned and streamlined.
* (Register being written to, Command sent to register)
transmitSPI2(0x20,0X39); // Enable RX IRQ, CRC Enabled, be a receiver
transmitSPI2(0x21,0X00); // Disable auto-acknowledge
transmitSPI2(0x31,0X04); // Disable auto-acknowledge
transmitSPI2(0x26,0x07); // Change the data rate to 1MBit
transmitSPI2(0x20,0X3B); // Power up
CE = 1;

/* Enable interrupts */
RBIF = 0; // Clear interrupt flag
INTF = 0;
TMR1IF = 0;
TMR1IE = 1; // Set to interrupt on the overflow of Timer1.
INTEDG = 0; // Set it to interrupt on a falling edge
PEIE = 1; // To enable peripheral interrupts, needed for TMR1
RBIE = 1; // To enable local interrupt on change for PORTB4:7.
GIE = 1; // To enable global interrupt.
RD6 = 0;
debounce = 0;
count = 0;
status = 0xAA;

while(1) {
while(status == 0xAA) {
while(status == 0xBB) {
RD6 = 1;
for (y = 1; y <= 1500; y++)
RD6 = 0;
for (y = 1; y <= 3500; y++)
while(status == 0xEE)

void interrupt isr(void) {
if (RBIF) {
CE = 0;
CSN = 0;
data1 = transmitSPI(0x61); // Read the received
data2 = transmitSPI(0xFF);
data1 = transmitSPI(0xFF);
data1 = transmitSPI(0xFF);
CSN = 1;
switch (data2) {
case ARMCHIRP1: arm(); break;
case DISARMCHIRP1: disarm(); break;
case ALARM1: siren(); break;
case ARM1: arm(); status = 0xBB; INTE = 1; TMR1ON = 1; break;
case DISARM1: disarm(); status = 0xAA; INTE = 0; TMR1ON = 0; debounce = 0; break;
default: break;
CSN = 0;
data1 = transmitSPI(0x27); // Reset the IRQ
data1 = transmitSPI(0x78);
CSN = 1;
CE = 1;
RBIF = 0;
else if (TMR1IF) {
RD5 = 1 ^ RD5;
if (INTE == 0 && status == 0xBB)
INTE = 1;
else {
if (debounce >= 2 && count == 0) {
else if (debounce >= 2 && count == 1) {
count = 0;
TMR1IF = 0;
else if (INTF){
if (debounce >= 7) {
status = 0xEE;
TMR1ON = 0;
INTE = 0;
INTF = 0;

void siren(void) {
int a;
RD6 = 1 ^ RD6; // Toggle the LED on and off when this function cycles.
for (a = 1; a < = 250; a++) {
RD7 = 1;
RD7 = 0;

void arm(void) {
RD6 = 1;
for (y = 1; y <= 1000; y++) {
RD7 = 1;
RD7 = 0;
RD6 = 0;
for (y = 1; y <= 1000; y++) {
RD7 = 1;
RD7 = 0;
RD6 = 1;
for (y = 0; y <= 400; y++) {
RD7 = 1;
RD7 = 0;
RD6 = 0;

void disarm(void) {
RD6 = 1;
for (y = 1; y <= 1500; y++) {
RD7 = 1;
RD7 = 0;
RD6 = 0;
for (y = 1; y <= 1500; y++) {
RD7 = 1;
RD7 = 0;
RD6 = 1;
for (y = 0; y <= 250; y++) {
RD7 = 1;
RD7 = 0;
RD6 = 0;

Boot Alarm – Part 2: Brainstorming

2 March, 2010 (01:13) | Projects | By: Joshua

Brainstorming for a project has always been difficult for me.  There’s the saying, “If all you have is a hammer, everything looks like a nail.” I always try and solve a problem with the tools I already have, not wanting to spread out and learn different techniques. Or I’ll get focused on one particular technology I want to learn so I’ll try to use it to solve a problem and miss an obviously and drastically superior solution. I have to think, this project isn’t entirely about me. Obviously, we don’t want to go too far the other direction, but… I think you see my dilemma.

Using the situation discussed in my last post, and discussing more specifically the requirements of the “customer” (Mike), I broke the project down into different parts.

Power Source
Theft Detection
Mike Detection
Theft Notification

These topics tend to overlap and mix or aren’t needed, depending on the approach we decide to use.

Power Source:
AA or AAA’s
Coin cell
Li-ion / Li-pol

The real question was: Rechargeable versus replaceable. Replaceable would be easiest to design but would require fairly easy access to the batteries, whereas we’re hoping that the great majority of the alarm is hidden inside the boot and inaccessible to potential wrongdoers. Because of this, and that I happened to have a couple on hand, we decided to go with a Li-pol.

Theft Detection:
Vibration sensor to detect motion.
Accelerometer to detect motion.
Some form of alarm when Mike and the boot get too far apart, not based on vibration.
GPS with a set (or setable) area that will send a notification if that area is left.
Theremin circuit on the handle.

I immediately nixed the GPS idea due to cost, size, accuracy, difficulty of design, and reception indoors. This will be mostly used indoors and if it makes it outdoors, we’ll probably have lost our possibility of recovering the boot. The Theremin circuit was enticing due to its retro electrical style but, depending on the sensitivity, would either make noise when people are just around it or allow people to carry the boot by the soles. Also, with the proximity alarm, I struggled thinking of a way that I could set a distance accurately and not have a false positive. False positives would actually be worse than false negatives, if we tick off the higher-ups. And since accelerometers are more complicated and sometimes more expensive than normal vibration sensors while achieving the same goal, we ended up deciding on the vibration sensor. This may change if the vibration sensor is too sensitive.

GPS/GSM locator to broadcast its location to make it easier to find, in case the boot is successfully stolen.
GPS/WiFi so we wouldn’t have to pay for data packets on the cell
Some form of hot/cold locator.

We decided to not have a locator, mostly for the sake of simplicity.

Mike Detection:
RFID for Mike Detection, wireless for communication.
Wireless for both, low power for detection, high power for communication.
Car key fob style arm/disarm
Semi-secret switch on the boot to override alert.
Fingerprint scanner
Other biometric scanner
Keypad with unique passcode

This was a big issue for me and was difficult for me to decide. After discussion with some of the other junior guys, we decided on the car key fob style arm/disarm. After coming to grips with the limits of passive RFID, I decided that wasn’t the way to go. Then, as a selling point, Brian (a LTjg) explained it somewhat like this, “You can waltz in the room, put the boot on the table, hit the key fob and have the boot make the ‘Buh-bweep!’ sound. That’ll get their attention.” Up until he mentioned that, I was imagining this to be a surreptitious alarm, not to let the people know it was there until the first time it went off. But, he’s got a point. That is pretty stinking cool. As an added bonus, someone mentioned putting LEDs into the bottom two eyelets of the boot and having them flash like a cars headlights. Genius, I say. Pure genius.

Theft Notification:
Key fob in Mike’s pocket to warn him, either through vibration or an
audible alert.
Have an audible alarm on the boot that goes off when someone steals it.
Have a cell unit that calls his phone to tell him when it’s been stolen.

If we’re using the car alarm style, we’ll need a car alarm sound to go off when the boot is triggered. Thus, we decided on the audible alarm / lights flashing method.

Reviewing this brainstorming session and gaining a sense of what this project entails, I think I’m most concerned with the sound. I’ve never made sound before and my Googling has yielded mixed results. And my attempts to create sound by simply varying the frequency of a square wave sent out to a speaker made pitch accurate, yet completely unusable sounds.

Also, in order to use what’s on hand, I’m pretty sure I’m going to be using a PIC16F877A.

Let me know what you think! Leave your thoughts and comments below.

Boot Alarm – Part 1: Introduction

10 February, 2010 (06:35) | Projects | By: Joshua

Here’s a video introduction. I’m not used to being on camera, so be gentle.

"The Boot"
As you’ve read in the “About” page (I know that’s the first thing you did when you got to the page), I just recently joined the US Navy.  As with other navies in the world, we have our share of odd customs and the Seabees are no exception. If you are the junior Ensign in a Seabee command, you become “The Boot Ensign” or just “The Boot”. The Boot has the illustrious job of doing all the odd jobs that nobody else wants to do, being subject to ridicule, and carrying around a black boot filled with concrete to all command social functions. I am not the boot Ensign. I’m actually the senior Ensign, called “The Bull Ensign” and technically it is my responsibility to make sure all the other Ensigns in the command are squared away and doing what they’re supposed to. I say technically because in reality, there’s only two Ensigns, Mike and me, and since we entered and graduated OCS together, I’m only considered senior because my last name starts “Bi” and his starts with “Bo”. It took us awhile to come to that conclusion.

"The Boot" sole

"The Boot" Top
One of the joys of being The Boot Ensign is that other people are actively trying to steal the boot. The rule is that the boot can be stolen whenever the boot is left unattended, but force is not permitted. If the boot is stolen, whoever stole it is only limited by their imagination in what terrible and/or embarrassing tasks must be done in order to earn the boot back.

It is my goal to create some sort of Boot Alarm so that people cannot steal the boot without us knowing it. I want something simple and easy to use, small, hard to circumvent, and cheap. In the process of designing and building this, I will keep you posted with everything I learn, and hope you’ll leave tips and feedback when you see a better way to do things. At this point, I’m still not sure where we’re going to head with this. I’m trying to keep an open mind to make sure I don’t reject better ideas out of hand.

I hope this turns out to be a learning experience for all of us and look forward to the challenges that will be presented in creating the best Boot Alarm in the world. Being the only Boot Alarm in the world, I most certainly hope it merits that title.

Getting started with Assembly for PIC microcontrollers

18 September, 2009 (03:34) | PIC, Tutorials | By: Lucian

Hi everybody. This is my first post of a series related to assembly programming for PIC Microcontrollers. In this first tutorial I will show you how to set-up the compilers and IDEs that you will use for building code in assembly.

We will start with installing the tools for Linux based operating systems. I am using Ubuntu operating system which is free for download. For writing assembly code I am using Piklab, also a free program. To install this on Ubuntu you have to open the terminal and type the following command :

sudo apt-get install piklab

You will be prompted for you root password. Type it in to install the software. After installation, to launch the program you open the terminal and type “piklab”.

This is the Piklab main window. You are also going to need “gputils” for compiling the source code into hex files. To install gputils you type the following command into the terminal :

sudo apt-get install gputils

So now we have the software needed to write programs in assembly and compile them. We have to do one more thing. Open Piklab and select from the menu “Settings” -> “Configure Piklab” -> “Standalone file” -> “Toolchain” -> “GPUtils”. Now we have configured Piklab to use gputils as assembly tools for files that are not included in any projects. We are going to use this method for the first few codes.

If you are using Windows OS, Microchip is offering for free the MPLAB IDE that can be downloaded from their website. It is very easy to install and setup. You just follow the steps after running the setup.exe file.

Thanks for reading. I will soon post the first assembly lesson. If you have any questions just leave a message.

ID Location Space on a PIC

18 August, 2009 (03:53) | PIC, Tutorials | By: Joshua

There is a special location set aside on PIC microcontrollers called the ID location that is used for either storing checksum or identification purposes of the PIC.  It has four location spaces, but only the 7 least significant spaces are used.  The different applications of this space is limited only by your imagination.  For my applications, this area has been most useful in holding the version number of the software on a PIC.  As I improve my projects and the firmware on them, I lose track of which board contains which version. Of course, you can use it for whatever purpose you need.

Using this space is straightforward.  Simply use the following code, putting whatever numbers in there you’d like.


If you have any further questions, feel free to e-mail me or post a comment.