Saturday, November 26, 2011

Heroku + Node.js + MongoLab


I've taken a little break from the hardware side of things to mess with some software. Once I got started it was hard to stop. One of the things that I love about software is the instant feedback and ease of debugging. No connections to check or fleks of solder to worry about. Just write some code, compile when required, and run it. I never have to leave my seat which is great over the Thanksgiving break. Anyway, I wanted to post a quick how-to on setting up a mongo database on the Heroku platform. Heroku is where I'd like to run a server for WiFi enabled devices. Devices with internet access can send packets to the server that will be handled appropriately. I've really been trying to learn a ton about Node and MongoDB lately so those are the technologies I decided to mess around with.

Heroku

If you have never heard of or used Heroku then you haven't lived. It is a fully Git-integrated hosting solution. Like the heat and eat sausages at the supermarket, Heroku is pretty much commit and push and you are live on the internet. I can't say enough good things about how easy it is to deploy with Heroku and it can scale as fast as you can request additional resources from the command line. The other nice thing is that they offer a free tier for people to mess around with it. Anyway, enough marketing for Heroku. It's great and you should try it. They have some great tutorials on how to get going so I won't spend time on that here. See this page for a great walkthrough.

MongoLab

So it's no secret that there is this whole NoSQL movement going on and if you think it's just a fad then you need to take a closer look. A NoSQL-flavored database may be just what you need in certain scenarios. Sometimes the simplicity and easy setup of a document-based DB is just what you need. There are a lot of up and coming document-based DBs and I don't really have a great reason as to why I chose MongoDB other than I felt like it was easy to learn and has a lot of good documentation online. Since your Heroku app is completely contained within an Amazon EC2 instance you have to make use of various addons to get functionality. MongoLab is one of those addons that gives you access to a hosted mongo database. Again, the free tier is quite adequate for a new project.

Hooking It All Up

So all I wanted to do was get a Node.js app hosted that connected to a MongoDB database for the back end. What I ended up with was quite awesome and a breeze to use once set up. The steps I'm going to give are a little high level but if you have questions or want more detail just leave a comment or shoot me an email and I'll get back to you. I'll assume that you've set up your Heroku account and have the Heroku toolbelt installed at this point. You should also have installed Node and npm. There are great tutorials for doing those elsewhere.
  1. Create a new git repository
  2. $ git init
  3. Create a heroku app with the Cedar stack
  4. $ heroku create --stack cedar
  5. Add MongoLab AddOn
  6. $ heroku addons:add mongolab:starter
  7. Create server.js
  8. This is the meat of your Node.js application. I use the Connect library because it's simple to use and keeps the code clean. For the MongoDB interface I use the node-mongodb-native driver. The code for the server.js file can be found in a Gist I created.
  9. Create package.json
  10. This is how Heroku knows your app is a Node.js app.
    {
      "name": "mongolabtest",
      "version": "1.0.0",
      "description": "Sample app using Heroku, Node.js, and MongoLab",
      "engines":{
        "node": "0.6.x",
        "npm": "1.0.x"
      },
      "dependencies": {
        "connect": "1.8.x",
        "mongodb": "0.9.x"
      }
    }
  11. Create Procfile
  12. This is literally a file named "Procfile" in the root of your application directory. It is used by Heroku to know how to start your application in the EC2 instance. Our Procfile will tell Heroku to use a web dyno to run our node app. All that goes in this file as:
    web: node server.js
  13. Have NPM Install Dependencies
  14. NOTE: You may want to add "node_modules" to a .gitignore file to prevent all of the module code from being added to the git repo and being pushed to Heroku.
    $ npm install
  15. Commit Your Code
  16. Heroku is intimately tied to Git so to get your code to Heroku it has to be in the form of a git commit.
    $ git add .
    $ git commit -m "Initial Commit"
  17. Deploy It
  18. That's it. We're ready to send it to Heroku where they will work some special sauce goodness on it
    $ git push heroku master
  19. Marvel In Your Awesomeness
  20. Use the heroku open command to launch your app in a web browser. This simple app will parse a query string and add a document to the database with all of the arguments. It then returns the JSON of the object back to the browser.
    $ heroku open
  21. Check Out the MongoLab Admin Tools
  22. To verify your request generated an item in the database just log in to Heroku and access the MongoLab addon from your app area. You should see something like this:
    Clicking on the "requests" collection will show a list of the documents.

Conclusions

How much easier can it get? If you follow those instructions and use the code in the Gist it will take you less than 5 minutes. The example I generated isn't horribly useful but you can see that it's a decent starting point waiting for enhancement. If that interested you I recommend digging deeper into Node.js, MongoDB, Heroku, and all of the tooling surrounding these things. It really makes programming a lot of fun.

Friday, October 7, 2011

Microchip Stack Working!

As usual it's been a while since I've posted. I have, however, made quite a bit of progress on the WiFi implementation. As of this posting I have the MRF24WB0MA connected to and communicating with the PIC in a simple setup that supports ICMP (ping requests), Telnet, and making simple GET requests to a website. That's really all of the supported functionality I'll need for my project. How did I get here?

Plugging in the Code

The first thing I did was try to get the Microchip stack compiling in a project. To isolate any issues that may be caused by my bootloader I decided to create a fresh project for it. I refactored the code a bit since Microchip ships a bunch of examples for their different sample boards. Most of it was removing button and LED code. I also trimmed out a bunch of the UART code. I have to hand it to Microchip for building code that is very cross-chip, cross-compiler friendly but it really makes the code messy. For instance I'm using a PIC18 chip but have to wade through all of the PIC32 and PIC16 and PIC24 code to find which chunks are actually going to be compiled. It's one big ifdef nightmare. Anyway, after about 3 hours of messing with it and reducing the default buffer sizes (my PIC doesn't have enough RAM for the defaults) I was able to compile the code in the project. Here's a look at the memory usage.

Breakout Board

Once the code was compiling it was time to actually try this board out. To do so I needed to create a breakout board because while some people may be able to meticulously solder to the tiny pads on the MRF24WB0MA I just don't have the patience. Besides, creating your own home-etched boards is like a rite of passage. I whipped up a simple breakout board in Eagle. The hardest part about that was remembering how to export the layout so I could print it multiple times in a document editor. I'll try to put a post up on that in the next little while. I use the PCB Fab in a Box system to etch my boards at home and I highly recommend it. It's very low cost, easy, and produces amazing results. Once you get the hang of it you can crank out very good prototype boards in about 30 minutes. Here is what it looks like when it's been transferred to the copper and ready to etch.



With the contact etch method it only takes about 2 to 3 minutes with a sponge and some ferric chloride from the local Radio Shack and you've got yourself a nice board. Drill the pad holes with a Dremel, do a little soldering and you end up with this.



With the breakout board done I soldered the MRF24WB0MA on along with a couple of male headers. I used some super handy connectors from Sparkfun to get everything wired up to my breadboard and connected to the PIC.

The Hard Part

Next was the hard part. As with virtually all projects this thing didn't work the first time I flipped the power switch. I ran in to several problems. First, I didn't read the MRF24WB0MA datasheet close enough to realize that one of the JTAG pins always requires a connection. I had to do some of that meticulous soldering I was trying to avoid to remedy that (notice the read lead wire going to one of the pins in the pictures). Second, I had incorrectly entered my SSID in the source code. Third, and most annoying, there was a tiny fleck of solder creating a short on the MRF24WB0MA. Once I removed that the module started trying to connect. Still it failed. I finally found that, by default, the code for the MRF24WB0MA tries to connect to your router on channels 1, 6, and 11. Mine was set to auto-select the channel and was using channel 2. Switched that to 1 and boom, I started getting an IP address.



I still couldn't do a simple GET request however. It would start to transfer data and just freeze up. After quite a bit of troubleshooting I found that I had not set up my buffers correctly in TCPIPConfig.h. I highly recommend using Microchip's utility to handle that for you. Once that was done I was pinging, telnetting, and GETing away.

Next Up

Now that I have the Wifi unit in a working state I need to polish up the hardware and the firmware code. I want to get the Wifi code into a module so it is easy to plug in to any project. Microchip does a pretty good job but with some smart defaults and a few other tweaks I think I can make it a bit more friendly for the average hobbyist. Here's what the whole thing looks like at this point. Kind of a mess but it works!

Saturday, August 20, 2011

The WiFi Trek Begins

I started looking into implementing WiFi in the platform with the Microchip resources and thought that it might be useful to chronicle what I did. This serves the dual purpose of showing others how I go about figuring something out that I've never done before and the resulting blog post can serve as somewhat of a reference note that I can refer back to. So the goal is to send some data over WiFi with the platform. I've never done that before so here's how I'm going about it.

Hardware or Firmware First

I need to create a breakout board for the wifi module but before I do that I want to see how difficult it will be to integrate the Microchip stack into my firmware. If it turns out to be a huge pain then maybe I'll reconsider modules.

Get the Stack

Can't get the stack by itself. You have to download the entire 184MB of the Microchip Application Library and then, on install, you can decide only to install the tcp stack which appears to be a simple file extraction from the massive exe. Oh well, Microchip's business is creating chips not customer friendly software. While that was downloading I decided to give the MRF24WB0MA datasheet a read. More on that in a minute. Once I was done with that the download was finished so I started the download of the library documentation which is another 45MB. Why isn't that in the massive application library exe I just downloaded? Nevermind. While that was downloading I installed Eagle on my Ubuntu machine because I'll need that when I want to create a breakout board.

Datasheet Notes

A few things of interest in the datasheet. Page 11 has the footprint I'll need to create a breakout board in Eagle. Page 13 has an example application schematic that I'll mimic pretty closely in connecting it to the 27J53. Hibernate state can significantly extend battery life but isn't useful for intervals less than 30 seconds. The slave SPI interface implements the [CPOL=0;CPHA=0] and [CPOL=1; CPHA=1] modes (0 and 3) of operation. That is, data is clocked in on the first rising edge of the clock after Chip Select (CS) is asserted. This will be important when setting up the SPI driver in the wifi module. The SPI clock frequency can be up to 25MHz which is fine since currently the platform is running at 16MHz.

WiFi Is Up Next

So the PICBoot project takes care of the bootloader portion of the project and includes an SD card module which we can plug in to our main app if we need it. Next up is adding WiFi functionality.


Microchip MRF24WB0MA

I'm going to try to implement the WiFi portion of the project with the MRF24WB0MA from Microchip. They have a free networking stack that hopefully will plug in nicely to the module pattern I'm trying to follow. The price is pretty good compared to other offerings out there and the performance is comparable according to the datasheet. I'm just getting in to the implementation and hope to have a few posts on it. Specifically I need to get the code plugged in and I'll also need to create a custom PCB for the module to make it breadboard compatible. I really need to get around to fixing the speed issue in PICBoot. Reading 1 byte at a time in the hex file is really causing it to dog in performance. I think if I read like 512 or even 256 bytes at a time the performance would be significantly better.

Friday, August 19, 2011

PICBoot Alpha

Format Change

So, I've decided not to continue from the last posts like I said. I spend a lot of time trying to prepare educational posts to get something ready for the public eye that I could be spending on writing code and just laying it out as it is and getting feedback. In other words, I want to spend less time polishing my posts and more time writing code and putting out quick updates.

PICBoot Bootloader

As the last few posts suggest I started working on a bootloader. Well, the preliminary version of that bootloader is now available on github. It currently runs on the PIC18F27J53 but there is no reason that it couldn't be modified to work on other 18F chips. Once programmed onto the chip it will read a hex file from the SD card at startup and program the device. It's in it's early stages but it does work. I'll continue to enhance it as I have time but really the point was to get something up so I could start working on the platform and have a field programmable way of updating the firmware.

Wednesday, July 6, 2011

Anatomy of a HEX File


Before we can write a bootloader that reprograms our PIC for us we need to understand what a C18 compiled .hex file looks like. To do this I'm just using the MPLABX environment I set up on my Ubuntu dev machine. If we're going to look at a hex file then we need to get a hex file first. Let's keep it very simple. I created a new standalone project in MPLABX called HEXplorer. I added a single file named main.c with the following contents:
void main(void)
{
return 0;
}

That's as simple as I know how to make it. It compiled fine and created a hex file that looks like this:

Twenty-three lines of instructions for a four line program? This highlights a good point. C compilers are very nice utilities to allow you to write firmware code in a high level language but you do pay a price for it. Another interesting thing to noticed when you build this simple program is the RAM usage. After a clean build it showed 268 bytes or 7% of total RAM being used. Where is all that RAM going? Good question. If you look at section 3.3 (START-UP CODE) of the C18 User Guide you'll read that the default startup behavior that C18 creates involves initializing stack pointers. Those stack pointers point to a stack that is, by default, 256 bytes in size. You can control that size with a custom linker file. More on that in a later post. In section 3.4 of the User Guide you see that the compiler-managed resources account for a minimum of 12 bytes. 256 + 12 accounts for our 268 bytes.

HEX Demystified

"I don't even see the code. All I see is blonde, brunette, redhead. Hey uh, you want a drink?"

So if you look at the Intel HEX (http://en.wikipedia.org/wiki/Intel_HEX) page on Wikipedia ( I recommend you read it before going any further) you'll see that there are multiple formats for HEX files so the first thing we need to do is figure out what format we're looking at. That's easy, we just go to the Project Properties in MPLABX and select the MPLINK item on the left and see on the right that the HEX file format is INHX32.


Alright, so what do we know about that format? Well the MPLINK documentation can tell us. This is what it says.

1.7.5.3 INTEL HEX 32 FORMAT
The extended 32-bit address hex format is similar to the hex 8 format, except that the extended linear address record is also output to establish the upper 16 bits of the data address. This is mainly used for 16-bit core devices since their addressable program memory exceeds 64 kbytes. Each data record begins with a 9-character prefix and ends with a 2-character
checksum. Each record has the following format:
:BBAAAATTHHHH....HHHCC
where:
BB A two digit hexadecimal byte count representing the number of data bytes that will appear on the line.
AAAA A four digit hexadecimal address representing the starting address of the data record.
TT A two digit record type:
00 – Data record
01 – End of File record
02 – Segment Address record
04 – Linear Address record
HH A two digit hexadecimal data byte, presented in low byte/high byte combinations.
CC A two digit hexadecimal checksum that is the two's complement of the sum of all preceding bytes in the record.


So let's look at the first line in our compiled file:
:020000040000FA

Broken into it's parts we have
: - Indicates the start of the line
02 - Tells us that there are 0x02 or 2 bytes in the data segment
0000 - Will always be 0000 for record type 04.
04 - The record type is the Linear Address record. The data bytes represent the upper 16 bits of a 32 bit address.
0000 - The two data bytes. This makes sense because are program is small and will be under the 64KB (0xFFFF) range so the upper 16 bits of the address should be all zeroes.
FA - The checksum for the line. We're going to ignore this for now.

Well, that's not horribly interesting since that is how all of our PIC18 programs are likely to start. So let's look at one more.
:0600000063EF00F01200A6

This one is more interesting.

: - Start of the line
06 - Data segment will contain 6 bytes of data.
0000 - The starting address of the data in the data segment
00 - The record type is a Data Record
63EF00F01200 - The actual data. We'll disect that in a second.
A6 - The checksum.

Ok, so this time we're actually getting into the data that should be programmed onto our device at the reset vector (address 0x000). An important thing to remember here is how the data is organized. We read it from left to right but the bytes are swapped in each single-word instruction. Back in the MPLINK documentation it describes the data as "A two digit hexadecimal data byte, presented in low byte/high byte combinations." That means that "63EF"is really "EF63" if we want to break it out into binary and figure out the opcode which we obviously want to do right? This is confusing at first and seems completely insane and backward but it will help us later because when we want to program the PIC we program it LSB first then MSB so we'll program the device exactly how the data is in the hex file. It just needs to be swapped when we humans are looking at it.

Dissecting the Data

So lets look at the first two bytes of data.
EF63. Broken into binary we have

1110 1111 0110 0011

We take that information to the PIC18F27J53 datasheet, section 29.1, Table 29-2 which is the standard instruction set table. We just go down the instruction column until we find a match. Remember, some of the instructions have variable bits that will represent data for the instruction to use. That happens to be the case for our instruction which is the GOTO instruction. It has the format:

1110 1111 kkkk kkkk

The k's represent the address to go to. That address is the rest of the bits in our instruction word, “0110 0011” or 0xC6 when translated to hex format. If you want some practice try to figure out what the rest of the instructions are from our data segment. So, in review, the first instruction at the reset vector is going to be GOTO 0xC6.

I don't expect you to take my word for it. Let's have MPLABX confirm this. After building the simple HEXplorer program we can go to Window->PIC Memory Views->Memory View 2. This will display the PIC Program Memory in a tab in the bottom view area and you can see what the program memory should contain after programming the PIC with the HEXplorer hex file.


Well, you're welcome to go through the rest of the hex file and try to decode all of the instructions but I think we've got a solid enough understanding of the hex file format to continue working on our bootloader. The next piece of our problem is to "Understand how to write to the PIC's program memory space." That will be up next.

Bootloader Beginnings

Before I even begin defining the sensor firmware I want to create a solid, easy to use bootloader. I referenced it in an earlier post and still like the idea of using an SD card. It's platform independent and requires no host machine or software. The drawback will be power consumption. I'm designing the platform to be battery powered and while SD cards aren't huge power hogs they're not exactly power sippers either in terms of embedded systems. Before we even get to the SD part though we need to make it so our PIC can read hex data and program itself. Many of the PICs including the one I'm using for the project are self programmable, meaning you don't need an external programmer to reprogram it. I've done this before using the Microchip bootloader as a base and customized it a bit but I never really loved how it was written and layed out. I'm going for simplicity. So how do we solve this problem if we've never done it before? We do what any good programmer would do with a complicated software problem; break it into small, manageable pieces. So here are the pieces I've come up with to create a bootloader.
  1. Understand the anatomy of a hex file. If we're going to read a hex file and reprogram a PIC then we'd better understand what a hex file looks like.
  2. Understand how to write to the PIC's program memory space.
  3. Implement flash memory routines for the bootloader in C
  4. Implement programming routines to program the PIC from hex data.

The Spec

So what is the specification we are tackling here. I think it's good to define what "done" is so here's what I've got:

As a user I want to be able to update the firmware on the platform with an SD card containing the updated firmware.

It's not too specific but that's ok. In my next post we'll start breaking down the pieces to our problem and see where we get.

Saturday, June 25, 2011

MPLAB 8 on Ubuntu 11.04

Ubuntu Development Dream Lives On

I wasn't about to give up on my dreams of having a non-Windows development box to do my hardware tinkering on. So I decided to give Wine a try. Turns out it works like a champ and my bootloader project is simulating just as I expect. In case anyway else is interested here are the steps to get it up and running.

Install Wine

The first step is to install Wine. That is quite simple as it can be done through the Ubuntu Software Center. Just do a search for "wine" and install the "Wine Microsoft Windows Compatibility Layer."

Download and Prepare Files

Next up is to download MPLAB 8 and the Standard-Eval version of C18. Once you have downloaded them they need to be set as executable so that Wine can run them properly. You'll need to extract the zip file contents for MPLAB first. After that, change directories to the folder containing mplabc18-v3_38-windows-eval-installer.exe and run:

sudo chmod 777 mplabc18-v3_38-windows-eval-installer.exe

Next, change directories again into MPLAB_IDE_8_73 and run:

sudo chmod 777 *.*

Install C18

  1. Right-click on the C18 exe and select Open with Wine Windows Program Loader

  2. Accept the defaults through the install

Install MPLAB 8

Right-click setup.exe and Open with Wine Windows Program Loader. I chose the Custom setup and accepted everything that was checked by default. I accepted all other defaults during the install. If you selected the Hi-Tech compiler as part of the custom install it will launch a separate installer. I accepted all of the defaults during Hi-Tech C Compiler install except I checked the box to add the compiler path to the environment variable.

Test it Out

  1. Go to Applications->Wine->Programs->Microchip->MPLAB IDE v8.73->MPLAB IDE

  2. Open the project from the Project menu

  3. Viola! Works like a champ.
I haven't tried to program with the Pickit3 yet but I'm not too worried because I still have MPLABX installed so if I can't do it in MPLAB 8 I can just pop over to MPLABX and use it to actually program my device. It's not my ideal setup but it will work for now and allows me to remain Windows free. If you have questions or comments please feel free to pass them along.

Bit by the Beta

Back on the Sensor Project

So, I haven't talked about the sensor project for a while which was the whole reason I started this blog. Well, I'm ready to get back into it. First, I've decided not to continue with the screencasts although I would consider doing them again if a demand arises. For now they just consume a lot of time that I could be spending on designing, implementing, and documenting the platform. I want to share as much as I can about the design and implementation process so that others can learn and help me to learn. If you see something that you don't agree with or have a better idea, by all means, let me know. The more collaboration the better.

The Beta Strikes Again

I've been preparing several blog posts about the implementation of the bootloader for the platform which I'll be posting shortly in the future but felt like I should post this first. I was happily cruising along on my new Linux dev box and feeling pretty good about things. Cranking out some C code and got to that first debug moment. I created a simple test in code to see if my flash memory routines were working correctly and it turns out they weren't......or were they? I spent hours and hours trying to debug my code and try different things. Have you ever had one of those moments when you swear you are right and the machine is wrong but then talk some sense into yourself because "the computer only does what I tell it to do"? I reached that point. Finally, I was convinced that I was doing everything right and the thought hit me; "MPLABX is still beta software. Maybe I've found a problem." I pulled my code over to my trusty Windows machine and created a project in MPLAB 8 and built. I compared the hex file to the MPLABX version and they were identical. At least the compilers agreed. The problem appears to be in the Simulator. My test works as expected in MPLAB 8 but has erratic Simulator behavior in MPLABX.

Now What?

I was really excited to do all of my development work on Ubuntu with MPLABX. MPLABX is quite an improvement and has a TON of features I've always wanted in MPLAB. The fact that the compiled hex files are the same between the platforms tells me that if I program a PIC from my dev machine it will work fine but how will I know things work? I like to do as much simulation as possible before I start programming chips because once you get into the hardware the bugs are a lot harder to track down. The fact is, I need the Simulator to work reliably so that makes MPLABX on Ubuntu a no-go for me right now. Perhaps I'll look into MPLAB 8 under Wine. I'm not ready to let my Ubuntu dev box dreams go down the drain.

Saturday, May 21, 2011

Installing MPLABX on Ubuntu 11.04

As promised these are the instructions for installing MPLABX on Ubuntu Linux. Nothing is really too tricky just a few gotchas along the way that hopefully these instructions will help you avoid. These instructions were performed on a fresh install of Ubuntu 11.04 but they should work on previous versions of Ubuntu and even other Linux distros. If you know of differences or tips for other environments please send them in and I'll post them here. NOTE: These instructions pertain to a 32-bit installation of Ubuntu.

Get the Files

Before we do anything we'll need the files from Microchip. Go to http://ww1.microchip.com/downloads/mplab/X_Beta/index.html and accept the license agreement and you'll be taken to the download page.
  1. Select the platform of Linux
  2. Select the items you want to download and install. I chose:
    • MPLAB IDE X
    • MPLAB C18 Lite Compiler for PIC18 MCUs
    • HI-TECH C Lite Compiler for PIC18 MCUs
    • HI-TECH C Lite Compiler for PIC10/12/18 MCUs
  3. Click Download Now and it will start 4 separate downloads.

Install Java

MPLAB X requires Java to be installed in order to run. To install Java in my Ubuntu environment I ran the following commands from a terminal window. You can find the full instructions at http://www.multimediaboom.com/how-to-install-java-in-ubuntu-11-04-natty-narwhal-ppa/

sudo add-apt-repository ppa:ferramroberto/java


sudo apt-get update


sudo apt-get install sun-java6-jre sun-java6-plugin sun-java6-fonts

With java installed we can begin installing pieces of MPLAB. I decided to install the compilers first but don't know if that's required.

Open a terminal window and browse to the folder where you downloaded the MPLAB files. Before you can run any of the installers you will need to verify that they have execute permissions. Execute the following commands in the terminal window:

chmod 755 mplabc18.bin


chmod 755 mplabx-ide-beta60-linux-32-bit-installer.bin


chmod 755 picc-18-pro-linux.run


chmod 755 picc-pro-linux.run


Install the Compilers

C18

Enter the following command:

sudo ./mplabc18.bin


An installer will launch. Follow the prompts through. Nothing special here.

HI-TECH for PIC18

sudo ./picc-18-pro-linux.run


This is a more traditional linux install script and will have you read the license agreement in the terminal window. Hit enter to scroll down through that and accept it at the end.

After the license agreement it will ask you where you want to install the compiler and suggests a path of /usr/hitech/picc-18/pro/9.63PL3. I didn't feel like I needed the pro layer in there so I just used /usr/hitech/picc-18/9.63PL3. It will then prompt you to enter the serial number, "demo", or "lite". Type "lite" and hit Enter. The install will finish.

HI-TECH for other PICs

sudo ./picc-pro-linux.run

This install is practically identical to the one for PIC18 devices. The only thing different is the install path. I used /usr/hitech/picc/9.80a. You're free to use whatever you want. Now that the compilers are installed we're ready to install MPLABX.

Installing MPLABX

From the terminal window run:

sudo ./mplabx-ide-beta60-linux-32-bit-installer.bin


An installer will launch. I accepted all of the defaults and let it install. When it's done you will get a message saying you will need to reboot your system for the changes to take affect. In reading the Microchip forums this was suggested because certain USB programmers may not work until you do so. However, I was able to do:

sudo restart udev


and have MPLABX correctly recognize my Pickit 3. You may or may not need a reboot.

With MPLABX installed we need to make it aware of the HI-TECH compilers. For some reason it recognizes C18 right out of the box but not the HI-TECH ones.
  1. Launch MPLABX
  2. Go to Tools->Options
  3. On the Build Tools tab click Add under the Toolchain box.
  4. Browse to the path of the compilers and MPLABX should detect them. I was not able to get it to recognize the PICC-18 compiler. If anyone has any luck with that let me know.
Once that is finished we are ready to test things out. I was fortunate because I have two projects out on github that I could pull down and use for testing. One will test that the C18 compiler is working correctly and the other will test the HI-TECH compiler for non-PIC18 devices.

If you don't have git installed I suggest you do that now. I won't cover the instructions for that here because there is no lack of documentation for it online. Just google "install git on Ubuntu."

Compile EmbeddedFun

The EmbeddedFun project uses the C18 compiler so we can use it to test whether everything is set up properly. Pull that project down from github into a directory of your choosing.

git clone git@github.com:<username>/EmbeddedFun.git

I've already updated the project to follow the new MPLABX layout of files. There are no longer .mcp files with MPLABX and builds are done with makefiles.
  1. Launch MPLABX.
  2. Go to File->Open Project
  3. Browse to the firmware folder of the EmbeddedFun project and select the make object and click Open Project
  4. Test your installation by performing a "Clean and Build" action.

Compile FMBomb

The EmbeddedFun project uses the C18 compiler so we've tested the installation of that but we haven't tested the installation of the HI-TECH compiler. Well, we're in luck because that's what the FMBomb project uses so let's pull that project down.

git clone git@github.com:<username>/FMBomb.git

Open the FMBomb project in MPLABX.

One thing I had to change in the Project Properties to make the HITECH compiler work was to remove the PRO option. To do so select your project in MPLABX and go to File->Project Properties. Expand the Conf: [default] section and the HI-TECH PICC section and select Compiler. Select Operation from the dropdown and change the Operation Mode to "Lite".

Now try to build the project. Everything should be working and you should be all set to create your own projects.

Saturday, May 14, 2011

MPLAB X with Ubuntu

Well, first of all I'm back....I think. I haven't posted in a while because I've been busy on some side projects for pay which, understandably, take precedence over this fun stuff. Gotta put that food on the table. Anyway, I've been dying to get back on this project and have had tons of ideas swimming around in my head. I'm hoping to spend a lot more time working on this now that most of my side projects have just about wrapped up.

On the Ubuntu Kick

So about 6 months ago I gave linux another twirl. I've tried it several times over the last decade and have had fun but never felt is was practical to switch from Windows. Well, Ubuntu 10 changed my mind. I created an Ubuntu image in a virtual machine to work on a Rails website and was instantly hooked. If you haven't tried Linux in a few years it's worth taking another look. I've since switched my family PC over to Ubuntu and, believe it or not, it was fairly smooth with the wife and kids. I've been thinking about making the complete switch on my development machines but haven't been able to take the plunge yet.

New Dev Machine

Why am I telling you all of this? Currently I do all of my hardware development and chip programming from a 2002 Toshiba Satellite Laptop running XP. Seeing how my new "thing" is linux and I'm just getting back into the sensor project I wanted to see if I could set up a complete hardware dev machine with Ubuntu. Enter MPLAB X which has downloads for Linux distros so you don't even need to use Wine. After a few hours of googling and fiddling with Ubuntu 11.04 I've successfully pulled down the EmbeddedFun project from github, compiled it, and programmed a chip with the Pickit3 all from a 7 year old P4 630MB RAM frankenstein PC running Ubuntu. Perhaps mostly for my own documentation purposes I'm going to do a post with the steps in the next few days. Windows is great but seriously, we're not doing anything Windows-specific here so why pay for an extra copy of Windows when you can set up a pretty sweet hardware dev machine with Linux.

Wednesday, March 23, 2011

FMBomb Does Voice Now

So one of the requested enhancements to the FMBomb was to be able to transmit your voice. Well, ask no more. I've updated the schematic with the electret microphone breakout board from Sparkfun..




This little board is a great example of how easy it can be to bolt on functionality to an embedded project. No firmware changes were needed and the whole upgrade, including soldering a breakaway header to the breakout board, took me about 20 minutes. I immediately tuned all of the radios in the house to my preset transmission frequency and began speaking to the family from my basement lair. The transmission range is pretty good with just a simple 30 inch hookup wire antenna. Anyway, the schematic has been updated on github and I'll probably post an update to the Codeproject article in the next week or so. Keep the comments and requests coming. Who knows what we'll do next.

Sunday, March 20, 2011

Go Ahead, Reinvent The Wheel

A friend of mine is always telling me that I'm someone who loves to "reinvent the wheel." The other day I was browsing through the almost 900 page spec of the Intel processor instruction set. My mind started racing. How cool would it be to hook up an Intel processor to a microcontroller and have it execute some instructions? I'm not planning on trying that FYI but the thought was there. Then I started reading more about processors and the North and South bridges on a motherboard and how to write a bootloader and starter OS for a PC. My friend would say "Why on Earth would you write a PC bootloader or OS? Here you go reinventing the wheel."

Why "Reinvent the Wheel"

So why do I "reinvent the wheel" sometimes? One word, education. I know I'm not going to create the next Linux or Windows or the next great whatever it is I'm reinventing. That's not the point. The point is to learn something new. The thing I love the most about my educational background is that I can explain, with fairly decent detail, how a computer works down to the physics of the billions of transistors. It's not magic fairies to me like it is for a large percentage of people. But this isn't just limited to computers. Whenever you dig into the "guts" of how something works I guarantee you will learn something new. It can give you ideas for projects you are working on. It will give you a deeper understanding of the technology.

Black Box? More Like a Coffin

The people who rely on the black box encapsulation are fine until that black box fails on them. Then what? They turn to the person that knows what's going on inside that black box. Be that person. That desire for learning, that insatiable need to know how things tick; you can't outsource that. So to all you wheel reinventers out there I say "Go ahead, reinvent that wheel and all the other wheels you can find."

Thanks for the Votes

Finally, I'd like to thank all those who voted for my FMBomb Codeproject article. I won first place in the Beginner's Hardware Competition. Thanks for the support.

Tuesday, February 22, 2011

Do What You Love

Giveaway Cancelled

So first things first. I only got one entry for the Netduino giveaway so unfortunately I had to cancel it. A simultaneous thanks and apology to Steve for submitting the lone entry. I'm just not getting enough traffic to generate enough interest at this time but don't worry we'll definitely run a giveaway again in the future when the time is right.

Follow Your Passion

That brings me to my next point which is not really directly related to hardware or software. Do what you love. If you can do that every day things will work out for you. For me that's writing software and fiddling with hardware. I get to do one or the other pretty much every day. If you're not doing what you love every day find a way. Watch less TV or play less XBox. You'll get better at whatever it is and you'll enjoy it more.

What Next?

So it may appear that I've forgotten about the sensor platform but I haven't really. I've been pretty busy at work and doing some work on the side. Unfortunately the platform takes 3rd place. I haven't forgotten about it and intend to continue working on it. I also intend to post more often and mix in more simple projects here and there. Whatever comes to mind and whatever I love.

Thursday, January 20, 2011

Netduino Giveaway Announcement


As promised, this post provides the details to enter to win a free Netduino board. I said it would be a very small giveaway and I meant it. Unfortunately blogging hasn't brought me the riches of the world so I'm only giving away 2 Netduinos at this time but hey, two is better than none right?

Why Netduino?

You may be asking "Why a Netduino? Don't you use PICs?" Well, yes, I'm a PIC user myself but I also realize that PICs, while pretty easy to get setup, are no match for the ease of the Netduino and my purpose is to help a budding hobbyist get right into it. Besides, who cares what it is? It's free right?

How to Enter

To enter to win one of the Netduinos you have to meet the following criteria.
  • Have a strong desire to get into or continue learning about embedded systems.
  • Be at least 18 years of age or have guardian permission to enter.
  • Be a registered follower of this blog. (see the column to the right)
  • Send an email to netduinogiveaway@hardlysoftware.com explaining to me why you are interested in winning a Netduino and what you would do with it if you won.
  • Be willing to send me an update of what you make with you're new Netduino if you win

Now most of these bullet points are based on the honor system so please.....be honest.

Winner Selection

I'll be accepting entries from now until February 18th. I will choose the two entries that I feel have given me the most compelling reasons for why they want/need a Netduino board. My goal is to get these two free boards to owners that I think will get the most out of them. So submit your entries. Tell your friends. Tell them to tell their friends. Tell anyone you think may be interested in a brand new Netduino. If you don't like these rules then just don't enter. You've got until midnight (Mountain Standard Time) on February 18th to get your entries in.

The Fine Print

To make this a worthwhile endeavor I need to receive at least 20 submissions to select two winners. If I receive less than 20 entries the giveaway will be cancelled. Tell your friends and anyone you think might be interested so we don't have to worry about this one. In your email submission you must provide some contact information and a shipping address that can be verified. I just need a way to get in touch with you (email is fine) and if you win I'll obviously need to know where to ship your new Netduino. Except as required by US law enforcement I WILL NOT share this information with ANYONE. If your submission has been successfully received and meets all of the above-defined criteria you will receive a confirmation email within 24 hours notifying you that your entry has been accepted. Winners will have their Netduino board shipped within 2 weeks of the giveaway ending. If you have any questions just shoot me an email at netduinogiveaway@hardlysoftware.com. I've never done anything like this before so bare with me. As always, feel free to leave a comment if you so desire.

Wednesday, January 19, 2011

Vote for the Next Step

Just wanted to take a minute to thank everyone that has taken a look at the FMBomb article on Codeproject. If you just linked over from there, welcome. I appreciate the nice comments and votes. You never know what kind of reaction you'll get when posting an article for everyone to see.

What Should We Do Now?

So in the article I mentioned that I wouldn't be opposed to doing a follow-up article if there was an interest. So, if you're interested in more let me know. Leave a comment to this post with your idea for what I should do next. It doesn't necessarily have to be an extension of FMBomb. It could be something completely new. Some possibilities are:
  • Add a display to show transmission info for FMBomb
  • Add a way to change the transmission frequency other than hard-coding it
  • Add a microphone preamp so you could broadcast your voice
  • Do an article about the sensor platform
  • Something different all together. All ideas are welcome

I'll take the feedback and look at what to do next so don't be shy, leave a comment.

Embedded Fun Giveaway

I'm passionate about embedded hardware. I love learning about it and I love sharing what I can to help others learn. As such I wanted to do a very small giveaway to help some budding hobbyists on their way. I'll post the details in the next day or so. Stay tuned.

Saturday, January 15, 2011

Codeproject Article Posted

The FMBomb article was posted today. You can find it at
http://www.codeproject.com/KB/system/fmbomb.aspx. Feel free to leave comments there or here and if you like it give it a vote.

Friday, January 14, 2011

FMBomb Article Submitted

I sent my article to the Codeproject staff today for submission in the Beginners Hardware Article Competition. I'll post the link here when it's published on their site. It covers the creation of a simple FM transmitter using the PIC16F688 and the NS73M FM transmitter module available from Sparkfun. It's a simple project that I think is very approachable for beginners.

Like What You See?

If you like what you see in the article or here on the blog please leave a comment. I have a real passion for sharing the joys of working with hardware. I welcome any and all questions and comments or even suggestions on topics I could cover. If I get enough feedback on the FMBomb article I might post a follow-up article in which I go over expanding the capability of the project.

Saturday, January 8, 2011

Change of Plans - A Quick Sidetrack

SD Functionality Up and Running

First of all, I have the SD card communication up and running using the Petit FatFS library. It really is a slick little library. Up next is to take that functionality and create an SD bootloader. I'll document all of this and get the code up as soon as it's ready and hopefully find time to do a screencast. Stay tuned.

CodeProject Competition

This is where the change of plan comes in. So I was going to enter the beginnings of the sensor platform as an article for the hardware competition but I just couldn't make it concise enough and "beginner" enough so I decided to switch gears and use some hardware I built about a year ago involving FM transmission. I hope to get that posted in the next week or so and then it's back to the sensor platform. I'll post a link here when it's up.