Microcontroller Hacking

Serial Communication with Microcontrollers

2012-10-02T17:58:00.000-07:00

With my temperature sensors working, the next step is to start getting data back to the PC/Mac/RPI (Raspberry PI). Right now, data can be sent back via to ways:

RS232 via a standard USB serial port (and the supporting max232 circuit)
RS232 over Bluetooth

I reached one of the milestones in programming where I really needed to see real time debugging information. The first step was to wire up a standard serial port and start dumping data to Putty (o'l standby). Interestingly enough, on one of my shopping sprees I ran across a $9 Bluetooth serial module and I could not be happier. I have scrapped my legacy MAX232 -> USB in favor of a Bluetooth module that accepts 3V-5V input (FYI, I think it outputs 3V signals). It could not have been simpler to plug in the module, run GND, 5V and a line from the PIC. A few minutes later, it is discovered on the PC and the serial port is added as COM6. Nice. Now that is one less cable between the PC and bread board.

The tricky part is that these devices default to 9600bps. In reality, this is a very reasonable number for most applications. However, I needed to drop it down to 4800bps due to the clock speed I am running. The trick to that is that the BTM can only be configured via the terminal when the BT link is not active. To do that requires connecting the BTM to the host via serial TTL.

Fortunatly, there is a lot of information out there on configuring this BTM. A quick google for, "Bluetooth and linvor" will turn up a wealth of resources for customizing the BTM.

Why the AVR is better than the PIC

2012-04-23T07:49:00.002-07:00

It has only been a few short weeks since I took the plunge back into microcontroller programming and already I have regrets. Back in earlier posts, I listed a few reasons that I am sticking with the PIC. Since then, I have solidified my position even more by purchasing a PICkit2, and installed the CCS and Microchip C compilers. Sadly, my frustration continues and it has absolutely NOTHING to do with the chips and everything to do with the development environment.

20 years ago, the devices were so small (RAM/ROM/Flash) and there were so few variants that developing in assembly was not too bad. With the variations of chips today, it would be foolish to write almost anything for these microcontrollers in assembly. If you are old enough, or hard core enough, you know that writing reusable and modular (library) code in assembly is akin to stabbing a pencil in your own eye (it hurts). A simple example would be to imagine upgrading code on a PIC that had a single W register to a PIC with 4 W registers. Sure you could just migrate the code, but all that optimization that could be leveraged is lost! Hence, we have C.

I will be the first to admit from a hardware size, what I have at hand is pretty nice. I have a handful of powerful and flexible PICs at my disposal. However, the compilers are really starting to wear me down.

The free compiler (from Hi-Tech) is almost worthless when the optimization expires
The available C compilers are between $150 and $500
Don't forget about maintenance
Due to copy write restraints, I cannot share with my readers how I customized the code to fit a particular situation
If the reader does not have the compiler, my source code is all but worthless
You help $timulate the economy by buying a new compiler for each chip family (16 vs 18 vs 24).

So, in short, here I sit trying to squeeze coding into a tiny device and all I can do is produce bloated code files. And let me assure you, there is a difference. My once simple temperature with RS232 will no longer fit onto the device. Previously, it was only filling up 70% of the code space.

Of course hindsight is 20/20. Right now, as I look over my shoulder I wish I would have dropped $50 on the AVR Dragon instead of the PICkit2 (mind you, the PICkit2 really is a fantastic setup). So, I implore you to not follow my path and shift (or start) with the AVR as soon as possible. And, I hate to say it. I don't think you (or I) will look back and think we made the wrong decision. Look at some of the benefits:

tried, true and free compiler with GCC
-O 3 (gcc's optimization flag)
The $ that would be spent on the compiler can go towards a logic analyzer, Oscope or a bench power supply
Ability to switch among device types w/o buying a new compiler for each
Ever growing list of user created libraries that you can freely copy, change, enhance, and share

1-wire
I2C
USB
Manchester encoding
RS232
Wireless modules
List is long and keeps growing

AVRfreaks as a resource (yes, they are a wee bit hostile towards PIC people)
Hobbyist and Magazine support is bar none
Let's not forget the quick and simple Arduino
I consider all the other items (price, features, pin count, availability) to be the same

Am I switching? Not right now. But be assured when I run out of my supply of PIC's, the inventory and tools will be refreshed with AVR's.

Am I wrong or am I missing something obvious? Post below and let me know.

Starting out with the DS18S20 Digital Thermometer

2012-04-22T18:38:00.001-07:00

When I first started this project, the DS18S20 thermometer started out as a real winner. Looking at some of its key features, how could it get much better?

Communicates over a simple 1-wire interface. No waste of I/O ports
Multi-drop and individual addressing allows more than one device to share the same I/O pin
Cheap (my weak spot)
±0.5°C resolution
Digital communications means the devices can sit at the end of a long bus run w/o loss of accuracy

Look at how simple this device is to hook up to the circuit.

All that is needed is a standard 4.7KOhm resistor. It only took about 5 minutes (thanks to the included libraries from the compiler) to start talking to the device. In about 30 minutes, I was able to put together a simple program that would continuously read the temperature and send the data over RS232 to my PC. The next step was to add a few sensors to the bus and see about addressing them individually. <crash> Turns out that my frugal nature of using a 15+ year old part bit me. Each device is addressed via a 48bit number. While keeping track of 1 or 2 of these nifty devices would not be a problem, any more than that and the C84 is out of RAM. In all fairness, just about any reasonable microcontroller is going to quickly run out of RAM keeping a track at 6 bytes per device. Secondly, I discovered that the firmware required to discover all the devices on the bus is not that small either. By the time I extended the code to enumerate the bus, I used up almost 100% of my 1K of my EEPROM. Fortunately, there are still an abundance of I/O pins on the device that have not been used. So, for my design I am going to limit the number of DS18S20's to 5 (RA0-RA4). If I really need to expand the number of temperature sensors, a simple solution of a MUX (151) and an analog switch (4066) would be where I would turn. Using pins RA0-RA3 tied to a 74HC151, and the mux's outputs tied to 2 74HC4066's RA5 can be used for all the DQ lines (perfect since it needs a pullup anyway). With that in place on the breadboard, the PIC can now easily address 8 thermometers w/o any complicated 1-wire coding.

The down side is that the project cost has just gone up by $2 as has the complexity of the board. If I were going at this greenfield, I would be much better served putting the extra $2 into the PIC device I was going to use. A $4 PIC would provide a few hundred bytes of RAM and about 8K of FLASH. With a device that size, the issue of the firmware size and 6 byte device address storage would be removed and and there would be no need for external components. Oh well, glad I keep a drawer full of shoe horns.

PICyStiX

2012-04-16T19:33:00.000-07:00

One of the first things I HATE about bread boarding is the setup nightmare. How many times must I wire up a power LED, reset circuit, ISCP, xtal, and it goes on and on. My first task is to design a PIC carrier similar to what this individual did. Thanks to China, we all now have inexpensive board manufacturing at our disposal and I am about to take full advantage of it. My only constraint is that I am cheap (really, ask my wife). Iteadstudio will make 10 5cm X 5cm PCB's for $10. Who can beat that! With a little mind optimization, I was able to design a PIC carrier card in 2.5cm X 5cm. Great! Now I can cut the PCB in half and get twice the number of PICyStiX.

It only took about 12 days to from order to mail man at my door step. I was like a kid at Christmas opening the heavily packing taped package from China. After I gnawed, sawed, ripped and cut the package opened, I ran to the garage, scored the board with a box knife, snapped a couple in half and started soldering. Boy was I excited to get going! 30 minutes later, I had 4 PICyStiX in hand and was off to my eagerly awaiting bread board. My only issue was that I was out of the correct size of momentary switches. Luckily, I had a handful that would fit, if ever so snugly.

<insert failing warp drive sound> Oh no! I forgot to pour the ground plane before I sent off the board. Back to the garage to start soldering in 7 jumper wires (it could have been worse).

Engines online! After an hour of tedious soldering, my four PICyStiX were ready to be retested. This time they worked.

I have since populated, fixed and tested 8 boards.

2 PIC16C84
2 PIC16F628
2 PIC16F54
2 PIC16F88

In the end, the worst thing I discovered is that the new PIC16F parts actually have three additional I/O pins (RA5,RA6, and RA7), that I did not run to the headers. On the better side of the coin, I have some very handy modules to use and a couple fantastic lessons learned.

I have already started on version 2.0 that will bring all 16 IO pins to headers (Vcc and Vss too). If you are interested in the schematic and gerber files, just post a note below.

Requirements

2012-04-15T22:03:00.001-07:00

Before I get too far down the road, I need to establish some high level specs.
The end product will:

measure incoming water temperature (EWT)
measure outgoing water temperature (OWT)
measure return air temperature
measure supply air temperature
measure supply humidity
measure outside temperature
log the data somewhere somehow
display the data on an LCD (of course)

It will be nice to have:

measure KWh usage for whole house
measure KWh usage for HVAC
pulse monitor for water meter (have one sitting in the closet)
keep track of seconds the burner in the water heater is running
RTC for data tagging

Devices:

DS18S20 temperature sensor (few in the drawer)
PIC16C84 (if we cannot smash the code in there, we will buy a bigger one)
HSU-07 humidity sensor
16x20 LCD (need a good cheap source)
Bluetooth serial module (these ain't the dark times with cables and stuff)
433MHz wireless modules (just in case)
74HC138 will slim down the 1-wire
Flame sensor - Cool!

Misc:

Google for data logging
DesignSpark for PCB creation (seriously, I tried Eagle and could not figure it out).

Going Geothermal

2012-04-15T17:48:00.000-07:00

In December of 2010, I finally made the decision to replace my aging HVAC and update it to a vertical closed loop geothermal system (Yes, it was expensive. But, it was the right thing today and I wish more people would made decisions based on the future and not the hear and now). While researching geothermal, I ran across individuals using Web Energy Logger to monitor their home ecosystems. For the longest time, I watched this house up in Plano and was been envious of not only the monstrous floor plan, but of the kick ass WEL monitoring system that is installed. This simple event rekindled my interest in the PIC microcontroller and dusting off my BSEE (paper only).

Back in the mid 90's, while I was working at a small engineering company in Austin, TX, I spent an entire summer designing small control modules with the legendary PIC16C54 and PIC16C71. Wow! Things sure have changed. Back then there were few alternatives (enjoyable) to PICs and they were quite the fan fair. Today, the playing field is a tight battle among Microchip PIC, Atmel AVR and the TI MSP430 series of microprocessors. With my rediscovered interest in microcontrollers (and being off the scene for so long, I figured I would dabble in each of them a bit). Rather than bother with that story, let's just say old habits die hard (you always retreat to what you know).

If you are interested (if not skip on), this basically sums up my decision to stick with the PIC.

I already know PIC assembly (but that ain't hard and I have no intention of using it)
Free C compilers are available for all of them
I don't use a Mac or Linux, so those are not driving factors
The prices are about the same
The MSP430 is too modern at 3.3V
I already had a PIC programmer and two PIC16C84s laying around (yea, I typed 'C')

In all honesty, if I were to start all over, I would have picked the AVR, just for the social popularity. But, here we are and here we go.