Posts Tagged ‘DMX-512’

h1

DIY HVAC zoning

2011/06/17

Last December (just in time for the “perfect storm” of energy credits…) we had a new heat-pump installed to replace the old gas furnace.  Additional work was done to run ducts to my office upstairs.  The plan was to make the upstairs actually workable during the summer, rather than having the window unit chill the office overnight, then lose the battle at 2 or 3pm and effectively end my productive work day.  So far the system has worked nicely, though the actual compressor has been a persistent noise problem (which Carrier is slowly working on).

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…. Read the rest of this entry ?

Advertisements
h1

Misc updates

2010/06/07

I’ve kindof neglected my blog for the past week, so I thought I’d post an update of what I’m up to.  Mostly I’ve been fighting with rebuilding the debugging console for my primary contract, updating it to support Bluetooth.  More on that in a bit, first the other various things I’ve done:

  • I’ve managed to get DMA working for DMX-512 transmission, after a bunch of bizarre fighting with both the DMA engine and GCC.  They conspired to blow about 3 hours of headbanging, compared to the roughly 15 minutes it took me to get the baseline write,wait,write,wait style working.  The next step will be to enhance it to use a timer and interrupts, so it can happen entirely in the background.  That should reduce the overhead of continuously sending a full DMX universe to about 0.025% of a 32MHZ chip!
  • Some more thinking about how to drive a large number of LEDs with BAM without using too many chip resources.  At this point I’ve got a theoretical configuration that drives 64 channels at 12 bit resolution at nearly 8KHz refresh (bits and refresh can be traded off) while using one timer, one DMA, and around 1KB of RAM.  All this should use 0.005% – 0.0075% of a 32MHz CPU….
  • Some quick tests with the QFP version of the Xmega-A4 board confirms that I can hook the anode of an LED to 3.7V and switch the cathode connected directly to the MCU.  Combined with a resistor for the red element, that means direct drive of RGB LEDS, as intended.  That makes the 64-chan RGB driver that much more viable, once I finish hotwiring my AVR-PDI screwup (I assume the data line could be shared between all the chips…)

As for my debugging console, it’s a Python beast designed to handle the overlap in serial port usage between debugging and bootloading.  The Arduino app does something a lot like this, but not nearly as slick.  The goal of the application is to provide full terminals for each of the devices hooked up to my system,  but allow AVRdude to reset and reprogram them as quickly and easily as possible.  In its original incarnation, terminals would be created for each expected device statically, and only if they were actually attached via USB would they be active.

In addition to providing the terminals, each instance created a socket for AVRdude to communicate with while programming the device.  These sockets answer and simply act as conduits (just like a serial port) to the device.  When the socket is connected, the console resets the device into the bootloader (either by command or by bit-banging the reset line on the FT232), then hands over control to the programming socket.  Once the socket closes, control switches back over to the terminal, and you see the boot screen from the program that was just uploaded.

The new version is designed to respond to devices as they connect, rather than constantly checking for particular units.  In addition, it must support both the rev2 boards which are FT232-based, and the newer rev3 boards, which use a Bluetooth serial module.  The biggest pain so far has been trying to coerce the Bluetooth stack to do my bidding.  It seems very fragile as far as connecting devices and various protocols (such as serial), so I’m having to be very rigorous with my error checking and whatnot.

A feature of my Bluetooth adapter boards is that not only are the serial debug lines attached, but two more are wired from the AVR-PDI interface (which includes RESET#) to GPIOs on the module.  I haven’t gotten the GPIOs to work fully yet, but the hope is that I’ll actually be able to implement an STK500 stack in the programming console that allows the installation of a bootloader on a bare chip.  This would be a handy place for my “logic helper” stack as well.

Anyway, back to the grind, currently toasting up another board stack so I have two complete copies of the rev3 hardware and can get back to bus testing.

h1

DMX-512 transmission successful

2010/06/02

Some fairly quick software work and I’ve got a baseline for DMX transmission from the Xmega DMX board ;-)

The code after the break is quick and dirty, and hogs the whole chip, but it works!  The next step is to convert it so that it uses DMA, then enhance it to use timers and events so that the MBB/Make/MAB sequence and transmission is as lightweight as possible.  The trick is to balance peripheral usage vs. interrupt overhead.  Given the slop built into the DMX protocol, I can set the interrupts to lowest priority safely enough, and probably get the overall CPU time required to transmit a continuous DMX universe down to something like 0.05% of a 32MHz chip.

The next challenge is DMX reception, which can be done with interrupts, but can also potentially be done with timer capture channels.  I’ll have to start with the dumbed-down version first of course…

 Read the rest of this entry ?
h1

Dual DMX board populated

2010/06/02

I just finished putting the remaining parts on the dual DMX Xmega prototype board, and it comes up at least as far as getting the programmer to talk to the chip.  The next step is to bootstrap it up and get some rudimentary DMX transmission code going, and hack one of my DMX cables so I can connect it to the two terminal strips, one each for input and output.  I’ll probably just make a basic all-channel fader test, and hook up both the 1200W dimmer pack from church and my 8-fixture LED kit (24 each red, green, blue, and white per fixture, total 60W for all; I really should post further details on that old kit and how it relates to my newer projects…).

h1

DMX-512 module in development

2010/05/04

In response to a question on answers.hackaday (this one) about an open-source DMX-512 platform, I figured I’d post something about what I’ve got under development as part of a larger project.  The long-term goal is to develop a wall-mounted control panel (e.g. in the standard light-switch box) for lighting scenes.  A number of these would be installed at key places in our church sanctuary, allowing the DMX-controlled lights to be operated without having to trudge upstairs and find the light board.

The module in question would be the brains of such a beast, having a microcontroller and the necessary DMX interfacing.  An ATXmega would form the core, given that it’s the most versatile MCU I’ve used so far.  DMX interfacing uses a pair of MAX13430’s, which are dual-voltage transceivers allowing me to run the DMX ports at the proper 5V yet interface cleanly to the ATXmega running at 3.3V.  A soft-USB port is present for configuration, though that depends on either porting or rewriting the AVR-USB stack to run at 32MHz, or just running the whole module at say 20MHz (the max current speed for AVR-USB).

The module takes the physical form of a 40-pin 600mil DIP, for which sockets are easily available anywhere and everywhere.  All the pins not used by the DMX interfaces are brought out on pins for use by whatever you want to drop this thing into.  DMX and power connections are made via screw terminals, which could be routed to standard 5-pin DMX connectors on whatever chassis you have.

This module is still under development, as in I was modifying and cleaning up the PCB just a few minutes ago.  The DIP power pins are yet to be routed, and there’s more cleanup to be done.  However, I’m waiting to turn the actual boards until I get my baseline Xmega adapters populated and can start developing some of the software so I know I’m not smoking something.  I expect to turn these boards in 2-3mo, and shortly make them available for purchase.