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.
