Thursday, December 9, 2010

Still Chuggin' Along

Well, I've been off the project for a while. Sometimes life throws you a curve ball and in my case it was some unexpected health issues that I'm just now getting over. I'm slowly getting back on to the project and hope to crank out at least one more episode in December.

CodeProject Competition

I recently found out about the beginning hardware competition on The Code Project and decided that I'd take the starting work of the EmbeddedFun platform and enter an article on it. Head over to the site to learn more about the competition.

Saturday, November 6, 2010

Sometimes It Gets Ugly

Well it's been a while since I posted an update. I ran into a wall and figured it might be useful to somebody if I post about it instead of glossing it over. I started working on the next episode and was hooking up an SD card to the sensor platform. I had to face some realities. The code to work with the SD card was pushing the memory usage high enough as to limit some of the other features I have planned. Also, the PIC18F2455 is a 5V device and requires special circuitry to be able to interface with a 3.3v SD card. I decided it was time to look into another PIC for the project. I went to Microchip's site and really poured over the chip comparisons and decided that the PIC18F27J53 was just what we need.

Enter the PIC18F27J53

I chose this chip for several reasons. It has WAY more code space than the 2455 tipping the scales at 128KB. Ram sits at 3800 bytes. It gets even better. It is capable of full speed USB, runs at 2 to 3.6V and is a member of Microchip's XLP (extreme low power) family which makes it great for battery life. This thing can run for years in deep sleep mode on a couple of AA batteries. On top of that it has a built in real time clock and calendar. Needless to say I'm really excited about moving forward with this chip. I ordered a few and got them in the mail.

Things Go South

This is where things went south. I refactored the project to use the 27J53 and got everything compiling which was a snap since all we're doing so far is flashing an LED. I popped out the 2455 from the circuit and snapped the J53 onto the breadboard. What followed was several days of programming errors. I kept getting the error "Target Device ID (00000000) does not match expected Device ID". All of the help online seems to be for people who have the programming pins mismatched or actually are trying to program the wrong part. I didn't have either of those. Just as a sanity check I popped the 2455 back in and verified I could still program it. I searched and searched and tried everything I could thing of with no luck. Finally I found one forum entry on Microchip's site where somebody suggested that the wires connecting the Pickit 3 to the device should be less than 5 centimeters. I didn't give it much heed because the 2455 was programming fine. I was ready to ship the J53s back to the manufacturer because I thought I had a bad batch. Finally I had had enough. I ripped the entire breadboard apart and started from scratch. The only thing I changed was I repositioned the programmer header so that I could make the PGD and PGC wires about 1.5 centimeters each. Sure enough, it works now. Unbelievable.

The Good in the Bad

Another reason I wanted to share this hangup is because a bunch of good came out of it. When I was in the pit of electronic darkness I really dug in. I poured over the datasheet and errata to see if I had missed something. I learned a bunch of things about the J53 that I wouldn't have otherwise known if everything just worked and I'm sure that information will come in handy as the project progresses. There is always some good that comes out of seemingly terrible situations. Don't just throw your hands up and give up. That's for suckers that can't work through the tough problems.

Saturday, October 9, 2010

Focus on What Matters

What Matters?

So I've started getting things together for Episode 3 of the series in which I intent to get SD card functionality working. I quickly got sidetracked and thought it would be useful to mention it. This seems to happen a lot in projects. We let our minds get 3 or 4 steps ahead and we start thinking about details that don't matter now and may never matter but trying to plan for everything slows us down. This is a fine line to try to walk. If you don't plan ahead enough you can really hurt yourself in the long run or make things more difficult. If you plan too much you spend a disproportionate amount of time on ideas or details that may never matter. This has happened over the past couple of days. I started with what matters, getting SD card functionality added to the sensor platform. Then the details set in. SD needs 3.3V instead of the 5V I'm getting from the programmer not to mention the programmer can't source enough current required for SD communication. So I need a power supply. What kind of a power supply do I need? How will I know if the SD stuff is working. I need some sort of debug output. Should I hook up a temporary LCD to debug with? Maybe USB to output to the computer. I got bogged down fast in the details.

Stay Focused

So I decided I was getting too wrapped up in future details. What mattered was getting SD card functionality. I don't need to decide on the power circuitry right now. I just need enough power to get SD working. A USB port can source 100mA without adding communication protocol. That is pushing it so let's just use a wall wart to be safe. Most of us have a box of them lying around anyway and we can refine the power stuff more in the future if we want but the wall wart will get us the power we need right now. As far as confirming the SD stuff is working with an LCD screen, that is overkill. We need to confirm that the PIC can read and write to the SD card. Well, I think I have a simple enough way to do that with just the LED we've already added. Stay tuned for Episode 3 where I'll go through the whole process.

Tuesday, October 5, 2010

Pickit 3 OK...Bootloader Better

What's A Bootloader?

So we've got our platform in a state where we can load new firmware onto it with our programmer. That's great but what if we need to update the platform after we've built some units and sent them off to end users? I guess we could give them all a Pickit and instructions on how to use it. FAIL. We need a better way than that. We need a bootloader. What's a bootloader? Simple, a bootloader allows our microcontroller to be reprogrammed WITHOUT our Pickit.

Basic Operation

When we use the Pickit, or any other programmer for that matter, ones and zeroes are sent on the programming pins after the microcontroller is put into a special programming mode. The microcontroller writes that data into program memory. Most of the PIC microcontrollers nowadays have a “self-write” capability which means that they are capable of writing to their own program memory space during normal operation without going into a special programming mode. We have to be careful though because if we put new programming instructions in the wrong addresses the microcontroller will exhibit unpredictable behavior or stop working altogether until we reprogram it with our Pickit.

When the unit is powered up we can have a small piece of code that checks some type of flag(button pressed, entry in EEPROM memory) to determine whether to run the application code or run the bootloader code. The bootloader code has some mechanism for getting the new firmware instructions into the application code program memory, overwriting the old application code in the process.

Bootloader Spec

I've thought a lot about the best way to implement a bootloader for the EmbeddedFun Sensor Platform. Taking into consideration ease of use and functionality I think the best option is to use an SD card. We can put new firmware on the SD card and the next time they reset the device it can check for new firmware and load it into program memory as well. How we get the firmware onto the SD card is also up to us.

The platform could implement the Mass Storage USB class so we could copy firmware to it like any other external drive or maybe we could get it there wirelessly. The SD card provides other benefits as well. It gives us a ton of storage that the platform can use for things like storing sensor data, settings and other things. Episodes 3 and 4 will cover implementing the bootloader for our sensor platform. Topics covered will include:
  • Reading/Writing to flash program memory on the PIC
  • Communicating with an SD/uSD card

Thursday, September 30, 2010

EmbeddedFun Series - Episode 2 Available

I've posted Episode 2 on and updated the Github repository. Head over and check it out. I'm also going to add each of the latest episodes to the Quick Link list in the right panel. As always I welcome any feedback you may have. In Episode 2 I build the very base hardware platform and get it setup to be programmed in MPLAB with the Pickit 3. It's a very clean, bare-bones breadboard that is ready for us to expand on. Stay tuned to see what's next.

Monday, September 27, 2010

The EmbeddedFun Sensor Platform Is Born

Baby Steps

Ok, I'm purposefully taking baby steps on this project for a couple of reasons. First, I don't want to assume to much about what people may know so I'm trying to cover the basics. The second reason is because I've learned, from experience, that when you try to hack something together too fast by just reproducing other people's schematics or dropping in their code that you quickly loose the ability to navigate your own code and schematic because you don't really understand it. So, in keeping with that philosophy, we're going to start our platform in it's most basic form and build from there.

Hardware Hello World

So the hardware-world equivalent of “Hello-World” is the blinking LED. Get your microcontroller to flash an LED when powered on. There are some important differences though. In the software world this normally just takes a few lines of code. Build it and see it on the screen. Not very difficult or exciting and it doesn't prove a whole lot. In the hardware world the blinking LED program depends on several things; proper powering of the board, proper connection of the microcontroller and any necessary supporting circuitry, proper transfer of the hex file to the microcontroller, etc. One thing you have to get used to when working with hardware is that there is no Intellisense or compiler errors to help you hook up wires correctly. The blinking LED helps us verify several things are working properly before we write too much code.

First Hardware Specs

As I mentioned in an earlier post, I'm intentionally not defining a long list of requirements for the project. We're just going to wing it as we go and develop the spec as needed. Our first spec is going to be that the platform have an LED that can be used for providing visual status indicators to the user. We'll implement the basic blinking LED program using that LED to confirm that our initial setup works properly. It sounds simple and boring and, granted, it is a little, but it will help us accomplish several things:
  • That we are able to program the platform with a hex file
  • That our microcontroller is connected properly and running our code
  • Gives us a very basic platform to build on. The sky's the limit from here

This is what I'll be covering in Episode 2 of the series.

Saturday, September 25, 2010

EmbeddedFun Series - Episode 1

Be Gentle
So this is the first time I've done a screencast so be gentle. I'm sure I'll get better at it as we move along. This first episode covers setting up the environment for us to start working. I install the MPLAB IDE along with the C compiler. If you already have an environment set up then I would recommend skipping this episode as it would be quite boring and doesn't contain any other information. I recommend you view it in full screen mode so that you can see the text. If you can't see it below this is a direct link to it.

Get Ready To Git
Next up we will finally be getting into creating the project and defining some more of the finer details. The GitHub repository has been virtually empty up until now but in the next episode we will start getting some code written. I'll cover getting the hardware set up so that we can start adding functionality.

I'm really excited to get feedback on this project so please feel free to leave your comments here on the blog or shoot me an email. I'll be working hard to get Episode 2 done but it will probably be several days. Until then, feel free to read some of the C compiler documentation or the PIC18F2455 datasheet to become more familiar with the brain of our platform.

Thursday, September 23, 2010

Get Set Up To Hack

Laying the Foundation
So the tempo of this blog will seem a little slow to some. That's what happens when the author has a full-time job that doesn't involve hacking all day. Ohhhhhh, how I would love that. Try to hang with me and I promise I will crank out the content as fast as I can. The last couple of days I've laid the groundwork to really get things going on this project. I set up a GitHub repository that will house all of the source code and schematics, etc for the project so anyone can access them. Right now it's just an empty project because we haven't done anything yet. That will change soon enough. If you want to fork it you can head over to the EmbeddedFun Project. I've also been acquiring some necessary tools for the project which I'll cover below.

Basic Tools and Supplies
So I'm trying my best to keep the price tag on the project down but unlike software where all you need is a compiler, hardware is a bit more involved. I'm not going to try to create a full parts and supplies list up front because it would take forever to think of everything. What I will do is list everything I use as I use it so we can try to keep a running list of sorts. Suffice it to say you'll want to have some of the standard things lying around like a multimeter, soldering iron, resistors, capacitors, wire, etc.

Hardware Environment
For this project I've chosen the PIC family of microcontrollers. I know Arduino is hot right now and much easier to set up but I'm not looking to stack shields together. If we screw something up (miswire, spilled Mt. Dew on board, 1 year old thinks it's a snack) I'd rather replace a $4 microcontoller and some wires than have to buy another arduino shield. Besides, I want to build this thing from the ground up. So one thing you'll definitely need is a programmer.

I recently purchased the Pickit 3 from Microchip. It was around $50 and is capable of programming any uController from Microchip. You're welcome to use whatever you want but I went this route because the price was right and it integrates into the IDE I'll be using; MPLAB.

When Does the Fun Start
By now you're definitely thinking "GET ON WITH IT. I want to make something shocking myself in the process." I hear you but we have to get things set up first.  It will make life much easier as we get into the project. So let's just get through the boring stuff so we can move on. As an aid to these posts I plan to make heavy use of screencasts so people can follow along. So, tomorrow I plan to post the first video which will walk through setting up the environment. Until then this is the basic setup:

Wednesday, September 22, 2010

Step 1 - Define the Project

So my goal in this blog is to share the entire process of creating something.  The hardware I'm setting out to build is nothing new and spectacular although maybe we could add some cool things that have never been done before.  I'm NOT a genius and will make some crazy decisions and mistakes.  That's the beauty of this format.  I want to share it all.  The good, the bad, and the ugly in the hopes that it may be useful to some other fledgling hacker out there.  I will assume a certain amount of subject matter knowledge but not a ton.  I want this to be accessible to a wide audience.  If something is confusing or you want more info, leave a comment.  I'll do my best to respond. 

Disclaimer 2
I am NOT here to help you with your senior project/homework or debug your personal projects so please don't ask.  I will just ignore you.  Alright, with that out of the way, let's get on with it.

The Project
So some people might argue that spending hours/days/weeks on planning up front is a good thing.  I won't disagree but this isn't a major corporation and we're not going to do it that way.  We're hackers so the more time we spend planning the less time we spend actually doing the fun stuff.  Besides, in my experience, a lot of the planning flies out the door once you get into the nitty, gritty details of the project and you realize things work better on paper than on the workbench.  So, the definition of my project is thus:

Build an awesome sensor platform that is extremely easy and intuitive to use that can log data to a website and be administered remotely.

Alright, that's it.  That's our spec.  Now let's build it.  Stay-tuned.

Sunday, September 19, 2010

Let's Get This Party Started

My name is Kevin Sidwar and in 2009 I started my company HardlySoftware with the intent to create a remote monitoring solution for things like datacenters, hotels, property management, etc. I have a passion for quality products that are easy to use and have great support. I set out to build my solution. I didn't like the widely accepted model of charging outrageous prices for simple sensors. Most companies brag that they don't charge a monthly fee which means they have to charge you $250 for $30 worth of electronics. I figure a modest monthly fee for active monitoring and alerts is well worth it IF the sensors can be reasonably priced. For me the value add is in the monitoring and gathering of data. I started working on the website and figured I would save some time by contracting out the hardware part so I could focus on the software. After sinking several thousand dollars of my own money into the hardware creation I got my first batch of sensors. I quickly realized that I just wasn't going to be able to provide the customer experience I had envisioned. So back to the drawing board. I've decided to just build it myself. Because I don't feel like the sensor is the major value-add of a monitoring solution I want to open source my version of the hardware. I intend to learn a lot in the process and hope my journey can help other budding hackers. I plan to cover the entire process in a fair amount of detail so please feel free to leave feedback and let me know what you think.