(sorry for the grainy iPhone image…)

Here you can see the new scope, my old scope, and the project under development with some of the probes hooked up.  Here’s a shot of the scope in action, screenshot from it directly to a USB flash key:

This shot shows a lot of the features I that made me get this scope.  In this shot the screen is split into zoom mode, with 10us/div on top and 1us/div on bottom.  I can change the scale on the bottom and scroll it within the larger region at will, and it’s got all the data there at full resolution (2GS/s as shown).  The green trace is half of the RS-485 bus, while the pink trace is the math channel showing the differential result of that and its mate, after almost 100ft of lamp cord ;-)  D1 (cyan) and D0 (red) are the digital inputs hooked to the digital side of the bus controller.  S1 shows the RS-232 decode of that bus.  The really neat trick is that I’m actually triggering on the serial data, specifically 0×66.  You can see the orange triangle at the top of the two windows lining up with the end of the byte.  Since 0×66 happens to be the trigger byte for the end of the packet preamble in my design, what you see is preamble to the left and actual data to the right

I’ve even got the trigger output of this scope hooked up to a channel on my older TDS224, which allows the exact same waveform timings to be shown on the other scope at the same time ;-)

The scope also has a high-speed USB interface, which will allow me to set up, capture, and retrieve data from a Python script on my computer.  Since I have code already in place that will take a byte-stream in CSV format (so far from the Salaea Logic analyzer dump), it should be almost trivial for me to take the info from this scope and produce a human-readable packet dump.  The question is whether I can actually trigger and transfer data fast enough for every frame.  I suspect not, but that’s what the digital channels are good for: use a spare trace I/O on the board to signal a timeout or other bus condition, and go from there.

Only problem so far is that the thing’s got a decent-sized fan, which means both noise and heat ;-(

make has its place, no doubt, but small microcontroller projects not so much.  In my projects I like to just start coding, pulling in existing code where it makes sense.  Maintaining a makefile for that gets old really fast, and is massively overwrought compared to the requirements.

So, over the last couple years I’ve developed my own scripts to build AVR projects.  The latest variation has just received a major speedup, so I thought I’d share it along with some selected Bash tips.

#!/bin/sh -e

# Paths to various libraries
xmega=/home/omega/work/xmega
libpaths="/home/omega/work/iostack $xmega"

# Figure out what chip we're targetting
prog=`echo $1 | sed 's/\.c$//g'`;shift
core=$1;shift

# Set up the common commands
cc="avr-gcc -O6 -g -mmcu=${core} -I. -Wl,-u,vfprintf -lprintf_flt -lm -Wall -Werror -Wno-unused-variable $*"
for libpath in $libpaths;do
  cc="$cc -I$libpath"
done
#avrdude="avrdude -cavrisp2 -p${chip} -Pnet:localhost:$pipe"

# Remove and recreate the hidden bin directory
rm -rf .run-${prog}
mkdir .run-${prog}

# Remove the final binary and its srec
rm -f ${prog} ${prog}.srec

# Compile the main source (in background)
/bin/echo -en "${prog}."
$cc -o .run-${prog}/${prog}.o -c ${prog}.c -Wa,-almshd=.run-${prog}/${prog}.lst > .run-${prog}/${prog}.err 2>&1 &
objs=".run-${prog}/${prog}.o"

# Track down all the lib files that are in use
sources="${prog}"
srctocheck="${prog}"
while :;do
  # for all sources still to check, find all the headers they're dependent on
  headers=""
  for srcbase in $srctocheck;do
    hdrs=$(echo `$cc -MM ${srcbase}.c | sed -e 's@\\\\@@g' -e 's@^.*:@@g'`)
    headers="$headers $hdrs"
  done
  # break the list into lines, sort/uniq it, and collapse it again
  headers=$(echo `echo $headers | fmt -w1 | sort -u`)

  # for each header found, check to see if it exists as a C file
  newsrctocheck=""
  for srcbase in `echo $headers | sed 's/\.h//g'`;do
    if [ -e ${srcbase}.c ];then
      # if it isn't already in the sources list, add it
      if `echo $sources | grep -vq ${srcbase}`;then
        # start the compile
        src=`basename $srcbase`
        /bin/echo -en "."
        $cc -c ${srcbase}.c -o .run-${prog}/${src}.o -Wa,-almshd=.run-${prog}/${src}.lst > .run-${prog}/${src}.err &
        objs="$objs .run-${prog}/${src}.o"

        sources="$sources ${srcbase}"
        newsrctocheck="$newsrctocheck ${srcbase}"
      fi
    fi
  done

  if [ "x$newsrctocheck" = "x" ];then
    break
  fi
  srctocheck=$newsrctocheck
done

wait

echo

# check for any errors
haserrors=0
for srcbase in $sources;do
  if [ -s .run-${prog}/${srcbase}.err ];then
    haserrors=$((haserrors + 1))
    echo "ERRORS for $srcbase:"
    cat .run-${prog}/${srcbase}.err
  fi
done
if [ $haserrors -ne 0 ];then
  exit
fi

# Link it all together, strip, and generate SREC
$cc -o ${prog} $objs
avr-strip ${prog}
avr-objcopy --output-target=srec ${prog} ${prog}.srec

The script is run with the base name of the project (without the .c suffix) and the microcontroller to build for. Additional CFLAGS can be added to the commandline, like -D’s.  It will start compiling the main source file, and simultaneously recurse through all the referenced non-system headers looking for other source files in the same place (#includewill add xyz.c in that same directory to the source list).  The libraries listed at the top of the file ($libpaths) contain my various library files (many of which I should publish eventually).

Oh, I promised to share a tip or two about bash:

• If you have a bunch of strings intermixed with both spaces/tabs and newlines, do this: list=$(echo `generate list`)
• If that list has potential duplicates you want to get rid of, do this: list=$(echo `echo $list | fmt -w1 | sort -u`)

Anyway, I’m hoping this script is useful for someone ;-)

I’ve actually managed to cram all 24 debug windows onto the screen at the same time.  Time will tell if they’re actually too small…  So far I’ve got 4 stations and the port controller hooked up, though I need to see if I can get a single-port PDI5 controller built to isolate the port controller.  For some reason when I have too many stations attached to the same OctoPDI5 as the port, engaging the power-cut relay on the controller causes enough noise that the controller resets and turns everything back on again…

Imagine my surprise when UPS shows up with a 7″ x 8″ x 27″ box:

Inside this monstrous box there are 3 (!) large static bags, 7″ x28″ and 11″ x 18″.  One of them is covered in bubble-wrap, and all 3 of them are packed inside a large volume of loose paper.  Unpacking all 3 of these bags yields a full tray with 2 parts in it (the TQFP), a tube with 14 of the SOICs, and a second tube with 2 more of the SOICs (besides the large dessicant bag and moisture card in each):

Now, under absolutely no circumstances is this even remotely acceptable.  The SOIC parts should have been consolidated into a single tube, or at least they might have shortened the tube rather than cut additional plastic strips to fill the immense amount of empty space in them.  Even with 2 tubes they should have been packed in a single (smaller) bag.  The tray designed to hold 67 parts should have been chopped down significantly and packed in a smaller bag.  The entirety of this should have been in a radically smaller box, with less waste material.

In theory I saved $64.46 on the components by ordering them from Arrow rather than Digikey.  However, the shipping cost from Arrow was $14.99, reducing the cost savings to $49.47.  Saving $50 is a pretty good deal, but if the savings were any smaller, I would refuse to order anything from Arrow until they fix these absurd shipping practices.  The larger cost is in garbage, recycling, shipping volume and the resulting additional fuel cost for more trucks on the road with the additional traffic and noise.  You might say that this one package is a drop in the bucket, but unless I’m presented with evidence that Arrow only ships things like this to me (repeatedly, I might add), the impact is far larger than it might seem on the surface.

Responsible packing and shipping has been the watchword for years now, and Arrow needs to get a clue.

Luckily I have a Teensy++ sitting on my desk, which I haven’t had a chance to do much with yet besides play with the loader and core examples.  It’s nominally got all the stuff I need to pull this off, though before I actually connect it to anything I’ll need to alter it to run on 3.3V lest it blow out my port controller with 5V…

The software stack porting turns out to be quite trivial, because of the way I’ve set up all the code for the existing PDI5-related boards.  Basically I’ve built a rough object-oriented system for the various “streams” such as USARTs and the STK500V2 engine.  A little bit of hacking gave me both an “avrmega” standard USART module (though it’s hard-coded for USART1 so far; I’ll need to enhance it to run on “any” AVR mega, especially the one with more than one…) and a “USART” that uses PJRC’s usb_serial code.  A little more code gives me the “iosmux” mainloop that multiplexes the serial and stk500v2 streams through the upstream.  Some quick tweaks to my host-side software so it handles the /dev/ttyACM0 path instead of /dev/ttyUSB0, and I’ve got the basic ability to send a text substream out to hardware.

The next step will be porting the PDI physical layer to the “avrmega” type, and shuffling the pdi5 code around so it’s not hardcoded to the Xmega PHY.  Neither of those will be particularly difficult.  At that point I’ll be able to hook up a PDI5 cable (USB micro-B) to the Teensy and my port controller, and I’ll have a nifty single-port version of the OctoPDI5 (albeit without isolation in this form).

At some point in the future I hope to implement an ARM SWD interface in the same style as PDI5, using the same cable, connector, and pinout.  If all goes well I should be able to run this on a Teensy as well, which means I might have a particularly killer ARM programming interface at some point ;-)

The problem is, there really is no such thing as “balance” in a straight ducted system like this.  If the heat is on at any point, the duct to upstairs has to be completely closed off in order to not boil me alive, since there’s plenty of existing heat-producing equipment on my desk.  If it switches to cooling mode, I have to open the duct lest the ambient temperature ooze through the roof and equally boil me alive.  To help this later situation the installation included a duct-assist fan for the upstairs registers, which has to be turned on in many cases to get enough cold air (which is heavy and doesn’t want to go upstairs) where it needs to be.

Unfortunately, the assumption that there would be enough air return “falling” down the stairs hasn’t turned out to be true, which means I’m likely going to have to look into adding return registers and figuring out how to route a duct alongside the supply to the basement.  That’ll mean disassembly of the supply duct because it was positioned in the middle of the available space….

All of this is of course a preamble to the real topic (as per the, um, topic line) of this post, which is my plans to turn this into a zoned system.  The actual meat is after the break….The heat-pump is located in the basement, with various supply ducts spidering off it to the rooms of the house.   Two come directly from the riser and go to the living room and dining/kitchen area.  A trunk goes to the other side of the house and splits to supply the bathroom and both bedrooms.  The upstairs is supplied by another duct that cuts through the framing just over the foundation, through the garage (where the assist fan is) and down the east knee-wall attic space.

At the point each of the per-room ducts splits off from the rest (either right at the riser or after the trunk split), there’s a rotary damper.  This is nothing more than a metal disc in the duct that swivels on a rod, controlled by a handle on the outside.  Rotate it through 90 degrees in order to close or open it to a variable degree.  Conventional “balancing” involves opening all dampers all the way, then progressively closing down the dampers that are getting too much air (warm or cold).  As long as the overall temperature outside stays in the same window in which it was balanced, this works well enough.  However, the point of the heat-pump is that it accommodates a wide range of outside temperatures, so the idea of balancing to a given point is, um, pointless.

My plan is to mount conventional hobby servos (e.g. the Futaba S3003, or smaller/cheaper ones if they’re strong enough) at each damper, coupled somehow to drive the damper handle.  I’ve done some experimentation with that, and so far haven’t implemented a viable system.  My next attempt is going to be constructing an extended servo armature of the same radius as the damper handle, and double-stick-taping it to the duct nearby.  A stiff wire will connect the two, and hopefully that’s sufficient (and simple).  Upstairs there are 3 registers that really ought to be individually controlled, which means I’ll need to figure out a method for mounting the servos inside the registers.  I’ve seen people do it before, and it doesn’t look particularly hard.

Controlling the servos is another matter though.  The PWM signal they run off of doesn’t actually take kindly to being run over a very long wire (I’ve tried), which means I need to locate the control electronics near each one.  Luckily the majority of them are all in the immediate vicinity of the fan coil in the basement.  Living room, kitchen, upstairs, and the assist fan’s rheostat are right there, and the bathroom+bedrooms trunk split is about 15ft away from there.

I recently put together a lighting controller for church (which I really should post about, even though it’s pretty simple) built around an ATmega48 and an SN75176-alike Rs-485 transceiver (since DMX-512 lighting control is a 485 bus).  I have plenty of those parts floating around from AnySeis(tm) development, and it’s really the only way to go for long-distance communications (it’s somewhere between 50- and 60-feet between the fan coil and my computer, along the ducting path).  My plan then is to build a multi-channel servo controller out of those same parts, and use a protocol either similar or identical to DMX-512 to drive them.

The main trick there is the fact that the ATmega48 doesn’t have enough hardware PWM ports.  That means I’ll need to figure out the best means of implementing a bunch of soft-PWM ports.  Depending on whether I can put together a solid interrupt-based DMX receive routine or not, I can either run PWM as the main() loop, or use a timer interrupt to drive it.  A simple approach for the latter would be to have a table in memory with each of the PWM step periods as a single byte, and just blindly blast them out on the port for each interrupt.  Setting the PWM period for each channel is just an exercise in setting the right bits throughout the table.

I haven’t thought much about the controller yet, but for now it’s going to take the form of a USB to “DMX” protocol bridge.  I could use my Enttec OpenDMX USB module, but it’s kindof wacky to deal with.  I’ll probably just hook a FT232RL module to an Xmega board and make a simple command protocol to set the DMX frame.

However, there’s an aspect not discussed yet: temperature sensing.  I have a batch of 10 1-wire sensors that I need to figure out how to place in the various rooms in the house.  The location of each will determine how effective the system is (too close to vent means early response, in a dead-air zone means too late, near the outer walls means an offset to outside temperature, near windows means drafts, etc.) and I also don’t want these wires and little black sensors to be particularly visible….

The last part of this is something I think I just came up with a solution for.  The problem is this: the heat-pump is controlled by a thermostat located in the living room.  The only temperature it cares about (except for the outdoor sensor it uses for anticipation) is its internal sensor.  That means that if I get into a situation where the rest of the house is too warm and I really need cooling, I don’t actually get it unless the living room is too warm.  Getting the living room warm enough in any kind of expedient manner is not really feasible.

In a normal system, I could simply replace the thermostat with relays and drive the compressor, reversing, and fan terminals myself (with appropriate sanity checks for dead time and such).  However, my system is a “communicating” Infinity setup, which means there’s a 4-wire bus running from the stat to the fan coil, then out to the compressor.  The bus contains 24VAC power for the stat, and what I assume at this point is a proprietary RS-485-based bus (manual says “A” and “B”, which are the standard names for a 485 bus).  Because the thermostat is the master on the bus, there’s really no way I can force the system to do anything at all, unless I’m prepared to completely reverse-engineer and fully replicate the existing thermostat…

However, I discovered two terminals underneath the stat that give me hope.  The manual says they’re for a “remote sensor” to be used in the case where the stat is in a position that’s not representative of the rest of the building.  You can attach an external sensor and locate it somewhere else in the house.  It even shows how to connect multiple sensors in order to average the readings: 2×2 series/parallel arrangement.  This strongly implies that the sensor is nothing but a bare thermistor, as a such an arrangement will actually perform passive averaging of a rough sort.

So, my though is to connect up a digital potentiometer to those terminals, under the control of my system.  By adjusting the resistance of the digipot, I can “fake” different temperatures to the thermostat.  If I set the stat with a particular fixed temperature goal, I can then control whether the system heats or cools by whether the temperature I’m faking is above or below the scheduled setpoint.  Because my system is variable-speed and dual-stage, I should be able to hint the system as to how much heating or cooling I want by how far off the setpoint I tell it.

Since the weather here is finally starting to show signs of actually being mid spring (even though it’s going to officially be summer in only 4 days), this project is getting to be a pretty high priority.  I’m tired of running downstairs to mess with the dampers several times a day….

I’ll post more on each piece as I get there.  First will be the remote DMX-ish servo control and attempting to mount the two servos I have on the upstairs damper and assist fan rheostat.

Then a couple minutes ago (1:25pm Friday) through my headphones I hear somebody shouting outside, competing with the lawn equipment grinding away nearby.  Headphones come off, and it sounds like my name…. Huh?  Then I recognize the local Fedex driver’s voice and run downstairs, apparently I missed the doorbell (gotta find a solution for that).

He hands me a Digikey box, and I’m thinking “was there another order before this I forgot about???”.  He points to the “Monday” on the box and says he’s just “getting a jump on things”.  Out comes the leatherman, and out come the parts I ordered 22 hours and 25 minutes ago…..  These early deliveries are becoming a common event with this driver, and I’m definitely not complaining <g>

Making it even more amazing, one of the parts I ordered was a replacement for some parts Digikey mis-picked for the big assembly order.  I got a call from them around 5pm yesterday and he said he’d try to make sure the confusion with the parts was dealt with before the order shipped out.  I only got the shipment notification from them at 10:51 this morning.

I’m taking the old codebase and rebuilding it module-by-module so I can clean things up as I go, and make the main loop more configurable for various experiments.  After getting the serial port (which is running over the same cable, to my programming board) up and running, I moved on to the FD77T (which is an CDCE949 + crystal).  Now I’m starting to build in all the other subsystems necessary to get the thing actually talking to other units…

The only error was actually caused by Digikey, where somehow they managed to stick a cut tape of some random SOT23-5 part inside a bag marked for SC70-6 parts…  I’ll have to figure that one out with them and mount those parts myself.  Luckily those are on the controller boards, of which there are only 3.

I have to assemble the 3rd board of each stack myself, because I ran them on the DorkbotPDX group order.  That’s because they’re simple by design, so I can run variations more frequently (and cheaper) as I work on fine-tuning that part of the product.  That and the debug board (which I have to solder a cable to) bracket the above boards, making the whole thing quite colorful ;-)

Part of my design is careful re-usability of parts.  The interface boards I’ve designed for upgradability are also snapped onto the controller, so if I come up with a better version I can replace the controller’s interface just as easily as all the others.

The next step of course is to bootstrap them, which is always a very nerve-wracking procedure…  It begs the question though: if the boards are red and purple, what color of smoke should come out if something goes wrong???