I compensate for my engineering mistakes with bigger engineering mistakes. -Me

Every new board needs an “LED blink” program. It’s basically a Hello, world! for embedded engineers. Thing is, I put two seven-segment LED arrays on Corntroller, my brushless motor controller, so my LED blink program got a little bit fan-çay:

The displays were the first things I wanted to program anyways (USB is next). Among other things, you can display hexadecimal digits on them, which is pretty straightforward from a code perspective:

static struct SevenSegmentDisplay {
public:
	SevenSegmentDisplay(GPIO_TypeDef *gpio, uint8_t offset) :
			gpio(gpio), offset(offset) {
	}

	void showHex(uint8_t x) {
		palClearPort(gpio, 0xF7 << offset);
		palSetPort(gpio, charLUT[x % 16] << offset);
	}

	void setDP(bool dp) {
		palWritePad(gpio, offset + 3, dp);
	}

protected:
	GPIO_TypeDef * const gpio;
	const uint8_t offset;

	static const uint8_t charLUT[16];
} red(GPIOD, 8), green(GPIOE, 0);

const uint8_t SevenSegmentDisplay::charLUT[16] = {
		0x77, 0x14, 0xB3, 0xB6,
		0xD4, 0xE6, 0xE7, 0x34,
		0xF7, 0xF6, 0xF5, 0xC7,
		0x63, 0x97, 0xE3, 0xE1
};

Making that lookup table was the hardest part. Most code is written for “abcdefg” bit order, but my LEDs were bit-swizzled since I rearranged my lines to have a cleaner layout. This just meant I needed different bit patterns:

// - GFABPCDE
// 0 01110111
// 1 00010100
// 2 10110011
// 3 10110110
// 4 11010100
// 5 11100110
// 6 11100111
// 7 00110100
// 8 11110111
// 9 11110110
// A 11110101
// b 11000111
// C 01100011
// d 10010111
// E 11100011
// F 11100001

For a clean layout, it’s totally worth it.

Tasssel: the extra ‘s’ is for “scattering”

Work continues on Corntroller, my vaguely retarded version of Shane’s sweet brushless motor controller.

I got my Digi-Key order last week and started assembling the board at the Graphics/Visualization/Usability (GVU) Prototyping Lab, the sister lab to the Georgia Tech Invention Studio¹, and home to my favorite hot-air reflow station on campus for prototyping.

Now the thing about reflow soldering is that it perfectly captures the sights, sounds, and smells of hell.

What else but hell would make you sit in place, hunched over for hours, as electric fire brings tears to your eyes and solder paste brimstone pierces your nostrils? Bright incandescent lighting, smoldering soldering irons, and in the case of the GVU reflow station, a 50-decibel electric pump all magnify the feeling of burning alive in invidious flames of divine wrath.

But the GVU version of surface mount hell is actually pretty legit. The aforementioned electric pump is hooked up to a precision solenoid valve gas dispenser (controlled by a foot pedal), which in turn feeds pressurized air into a hand-held tube of leaded solder paste. Hit the foot pedal, and a small and carefully controlled bit of gray goop flows out.

The setup basically lets you do manual pick and place assembly. Less efficient for small and medium runs than solder paste stenciling, but way less setup time and a lot more fun². It’s perfect for prototyping a new board.

Now I ended up shooting video instead of taking too many pictures, so bear with my video screenshots here.

To make life easier, I assemble components under a 10×/30× stereo microscope with tweezers in one hand, solder paste dispenser in the other, and foot on the foot pedal.

At 10× you can see the particles in the solder paste.

After assembly, I preheat the board over a Zephyrtronics… board preheater.

I’m not even making this up. This thing emulates the flat “warm-up” period of the reflow temperature profile you’d use in a full reflow oven. In addition, it has a genius “cool” mode during which it draws air down (instead of blowing hot air up), using ambient air to cool the board (“ramp-down”). No more blowing on the board until your face is red and your tongue is covered with flakes of solder.

It even comes with a sweet PCB jig to hold your board at just the right height above the pre-heater.

After that, you pretty much just apply heat like a normal person.

You may notice that in addition to unpopulated inertial sensors, there are also two funny-looking solder bridges.

You have ze Germans to blame for that. Had I the European-styled schematic symbols für a common-mode choke ge-used, which had I the wrong orientation for the part ge-using. I think.

In other words, I managed to short my input power leads across a pair of inductors.

Not that that surprises me in the least; I’ve managed to build almost every circuit I’ve ever designed to have a short from power to ground. Heck, this is the probably the highest impedance short I’ve gotten on a first-try board in the past two years.

Actually, maybe the footprint I was using for my Würth-Elektronik common-mode choke just had a mistake in pin assignments. But I like to chalk it up to cultural differences, since it’s 34% more hilarious that way.

At any rate, I ended up skipping the choke completely using solder bridges; I get less noise immunity, but hey, nobody’s perfect and I’m not sure if it would’ve even helped at all.

At this point, it was time to try out the logic power supply. With fingers crossed, I hook up the bench power supply to the V+ and V- power pads and hit the switch.

Nothing.

Turns out when soldering leads to the V- pad while “e-testing” the board, I had broken one of the traces from the pad.

Oops.

I haven’t made a soldering boo-boo this bad in years, but whatever. I briefly considered running a little green wire over the trace³, but then realized that I tented over all my vias with soldermask⁴ and couldn’t airwire even if I wanted to.

Instead I just ripped up the soldermask with an X-acto knife under 30× magnification and then solder bridged the shorn copper. Like a boss.

Now I was getting a sweet 3.304V out of my LT3970 circuit from an input of 4V all the way up to 31V, which was as high as the power supply could go. Not really sure why this mattered, since I’ll always be putting 5V into the board, but whatever.

But why the heck am I posting about such minor minutiae as fixing a broken trace when I should be plopping down code like a pro? Well, because performing board bringup⁵ on an STM32-based board like this is an (necessary) act of distilled masochism, and I avoid it like a plague even when I’m already working on the board to begin with. I mean, hell, the software you use with the popular GCC/GDB ARM toolchain is called OpenOCD.

So I plug my board into my Olimex ARM-USB-TINY-H and then pray to Tony Stark to guide my board to a successful JTAG interrogation.

C:\Users\Xo>"C:\Program Files (x86)\OpenOCD-0.4.0\bin\openocd.exe" -f interface\olimex-arm-usb-tiny-h.cfg -f target\stm32.cfg
Open On-Chip Debugger 0.5.0-dev-00753-g422e9f9-dirty (2011-02-14-13:06)
Licensed under GNU GPL v2
For bug reports, read

http://openocd.berlios.de/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : device: 6 "2232H"
Info : deviceID: 364511274
Info : SerialNumber: OLTQ5QMÖA
Info : Description: Olimex OpenOCD JTAG ARM-USB-TINY-H A
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06430041 (mfg: 0x020, part: 0x6430, ver: 0x0)
Warn : JTAG tap: stm32.bs       UNEXPECTED: 0x06430041 (mfg: 0x020, part: 0x6430, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 1 of 5: 0x06412041 (mfg: 0x020, part: 0x6412, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 2 of 5: 0x06410041 (mfg: 0x020, part: 0x6410, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 3 of 5: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Error: JTAG tap: stm32.bs  expected 4 of 5: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 5 of 5: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints

“hardware has 6 breakpoints, 4 watchpoints” is actually what I expect to see, making this by far my most successful board bringup to date. But wait, what are those errors? Why isn’t my device (0x06430041) being recognized? Let’s take a look at the stm32.cfg script:

    # See STM Document RM0008
    # Section 29.6.2
    # Low density devices, Rev A
    set _BSTAPID1 0x06412041
    # Medium density devices, Rev A
    set _BSTAPID2 0x06410041
    # Medium density devices, Rev B and Rev Z
    set _BSTAPID3 0x16410041
    # High density devices, Rev A
    set _BSTAPID4 0x06414041
    # Connectivity line devices, Rev A and Rev Z
    set _BSTAPID5 0x06418041

Oops, my STM32F103VG XL-density microcontroller isn’t in there. The comments mention Section 29.6.2 of RM0008, the STM32F1x Family Reference Manual. In section 31.6.2 (dotdotdot) of the newest version of RM0008⁶, we see that 0x06430041 is Revision A of XL-density devices.

So I need a more recent version of OpenOCD that has the newer STM32 devices. Crap.

See, I use the default vanilla FTDI drivers for my Olimex, presumably so I can use the Virtual COM Port driver for the broken-out UART the ARM-USB-TINY-H doesn’t have. Yeah, I’m dumb. But OpenOCD doesn’t support those drivers out of the box; licensing issues prevent binary distributors like Freddie Chopin from making available binaries compatible with regular FTDI drivers. Instead most people use libftdi and libusb-win32 for hardware interfacing on Windows.

So I gotta build OpenOCD myself to make it work? God damn it; what is this, Linux?

Let’s just say $ ./configure --prefix=/cygdrive/c/Users/Xo/Desktop/ocd-build/out --enable-maintainer-mode --disable-werror --disable-shared --enable-ft2232_ftd2xx --with-ftd2xx-win32-zipdir=/cygdrive/c/Users/Xo/Desktop/ocd-build/ftd2xx CC="gcc -mno-cygwin"⁷

With my new OpenOCD 0.6.0-dev build, I got a fully successful JTAG scan, and the OpenOCD GDB server is now open for business:

C:\Users\Xo>openocd -c "gdb_port 2222" -c "telnet_port 4444" -f "C:/Progra~2/OpenOCD/interface/olimex-arm-usb-tiny-h.cfg" -f "C:/Progra~2/OpenOCD/target/stm32f1x.cfg"
Open On-Chip Debugger 0.6.0-dev (2011-10-19-22:04)
Licensed under GNU GPL v2
For bug reports, read

http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : device: 6 "2232H"
Info : deviceID: 364511274
Info : SerialNumber: OLTQ5QMÖA
Info : Description: Olimex OpenOCD JTAG ARM-USB-TINY-H A
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06430041 (mfg: 0x020, part: 0x6430, ver: 0x0)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints

lol @ C:/Progra~2. Because this thing f—ing breaks if I don’t.

1. At least in sweet, sweet funding
2. No, not really
3. I hear in some Asian electrical engineering tria- circles, using more than 三 (3) little green wires is a shame to the engineer’s family and results in decapita- ritual de-accreditation
4. Yeah. On a first-version prototype. Balls, suckas.
5. “Performing board bringup” sounds way cooler than “bringing up”
6. As of 2011/10/19
7. Yeah, that really is for my benefit only. How did you guess?

So in typical son-of-an-accountant behavior, instead of building my own scooter, I decided to go the manic whacky sneaky route and build something to sell to the scooter builders. So now I’m announcing the corniest, trolliest brushless motor controller of them all: Corntroller.

Corntroller is a result of me completely ripping off Shane Colton and Dan Strother to build an extremely feature-bloated brushless motor controller. All of the following will be devoted to driving just a single motor:

• Modular corn-inspired design, stacking a logic board (called Tassel) onto a power board (called HexHusk)
• 10V–45V operation with two switching regulators for logic power (LT3991-5, LT3970-3.3)
• At least 40A of current capacity through IXYS GWM160-0055X1 3-phase MOSFET power modules
• Way too much processing power from a 100-pin STM32F103VG, one of the top parts in the STM32 F1 series of ARM Cortex M3 microcontrollers
• Full voltage and current sensing on everything (motor phases and power bus), so I can implement vector control or sensorlessness
• Compact three-phase N-channel FET driving through dedicated gate driver IC (A4935)
• Motor hall sensor inputs to microcontroller capture timer
• microSD card slot interfaced through SDIO (not MMC over SPI) for datalogging
• Full speed USB interface… just because
• Two 7-segment LED displays… also just because
• Full 9-degrees-of-measure IMU (accelerometer, gyroscope, magnetometer) with the some of the best dumb¹ MEMS sensors (BMA180, IMU3000, HMC5883L) available… just $@#%ing because

I’m only half-joking about that last one; I designed Tassel, the logic board on Corntroller, as a replacement for my (yet to be written up) Maizure Cortex M3/MEMS sensors board. Maizure has served as my general dev board, and its successor is so full featured and has such overspec’d components because of that. But, I can choose to not populate components for unused features. So when Tassel is used as a part of Corntroller, it will not have its 3-axis MEMS sensor footprints populated².

By the way, I started naming my projects after corn. Just—you guessed it—because.

Tassel was laid out with only surface mount components (preferring 0603³ chip resistors and capacitors), all on the top side. Layout was actually fairly straightforward, since a lot of the work required just routing directly from STM32 pins to headers (which I could reassign anyways).

The hard part was figuring out which peripherals I could route out of the STM32. The original plan was to use a 48-pin device; this grew to 64-pin and then 100-pin as I realized that all the “good” peripherals I wanted in the STM32 were actually sharing the same pins.

For example, USART1 and TIM1 (with its useful three-phase complemented PWM with software deadtime insertion) shared the same pins. I had to spend a solid week assigning pins to their functionalities, restarting all over each time I had to up the pin count and move to a bigger device. Through all of this I also had to make sure to fan everything out properly so wires route cleanly from µC pin to headers and devices.

That’s really how I ended up with 7-segment displays; switching to 100 pins meant I had a lot of I/O pins left over that I didn’t want to go to waste. With the decimal point, each Kingbright 0.2″ display fills up 8 pins: perfect for half a GPIO port, and thus nice to control in software.

Plus, 7-segment displays and resistor arrays are way easier to solder than individual 0805 LEDs and 0603 resistors.

So I ended up with a long list of nets to route well before even starting a schematic in EAGLE (see appendix)!

Since Maizure had a bit of problems with noise and stability, I made Tassel a four-layer design. This means extra layers of copper on which to route signals, but more importantly to serve as ground planes for surface signals. This isn’t necessarily needed, but it certainly lends me extra noise immunity I figure I’d want on such a densely routed board.

A four-layer design meant I had way fewer choices in PCB fabrication: I went with Dorkbot Portland’s group PCB order, but also considered 4PCB’s/Advanced Circuits’s $66 each service and BatchPCB’s 4-layer group order. For me, DorkbotPDX just turned out to be the best bang for the buck.

Why do I just have photos of unpopulated boards? Because (a) they’re pretty and (b) I sent these out before I finished designing the power stage, in an attempt to pipeline the prototyping process. I wanted to send these out, complete HexHusk, order parts for both from Digi-Key, and have the components before Tassel’s boards arrived. That didn’t happen… the Digi-Key order is just now in the mail. Guess I failed at pipelining.

Design files for everything and a HexHusk post are coming. I promise.

Appendix
Partial pin assignments:

Outputs
=======
# Q1
15 PC0 V_P
16 PC1 V_A
17 PC2 V_B
18 PC3 V_C
23 PA0 I_A
24 PA1 I_B
25 PA2 I_P

# Q2
26 PA3 AN_0
29 PA4 SPI1_NSS
30 PA5 SPI1_SCK
31 PA6 SPI1_MISO
32 PA7 SPI1_MOSI
- V+
- V-

- 3.3V
39 PE8 PWM1~ # remap
40 PE9 PWM1 # remap
41 PE10 PWM2~ # remap
42 PE11 PWM2 # remap
43 PE12 PWM3~ # remap
44 PE13 PWM3 # remap

# Q3
68 PA9 USART1_TX
69 PA10 USART1_RX
# Q4
86 PD5 H1 # 5V
87 PD6 H2 # 5V
88 PD7 H3 # 5V
92 PB6 I2C1_SCL
93 PB7 I2C1_SDA

JTAG
====
- 3.3V
PB4 JTRST
PA15 JTDI
PA13 JTMS
PA14 JTCK
PB3 JTDO
NRST RESET
- V-

USB
===
PA11 USB_D-
PA12 USB_D+
- V+
- V-

SDIO
====
PC8 SDIO_D0
PC9 SDIO_D1
PC10 SDIO_D2
PC11 SDIO_D3
PC12 SDIO_CK
PD2 SDIO_CMD

MEMS
====
PB10 I2C2_SCL
PB11 I2C2_SDA
PB12 SPI2_NSS
PB13 SPI2_SCK
PB14 SPI2_MISO
PB15 SPI2_MOSI

1. Read: non-intelligent, where “intelligent” is a technical term
2. Or maybe it will… what electric vehicle could use an IMU?
3. That’s 6 mils by 3 mils or 0.006″×0.003″

But what resistors do you buy for your resistor bridge? You want resistance values of some multiple of 1.7 to 3.3, but resistors come in preferred values, which are mathemagicatically spaced out resistance scales.

None of the “nice” E24 values that are multiples of 170 or 330 really work (330 exists, but not 170; there’s a 510 but no 990; and 680 but no 1320).

There’s gotta be some kind of ideal combination of preferred-value resistors that give me either the perfect 5V to 3.3V divider, or at least minimizes the error. Well, I wasn’t about to do all 24² combinations of upper/lower resistors by hand and for some reason Google couldn’t find it for me, so I wrote a script C++0x program to uh… do it for me¹.

So what are the results for each EIA resistor value series?

E12 best: r1 = 180, r2 = 330 (-5.556%)
E24 best: r1 = 470, r2 = 910 (-0.258%)
E48 best: r1 = 825, r2 = 1600 (-0.092%)
E96 best: r1 = 491, r2 = 953 (-0.012%)
E192 best: r1 = 102, r2 = 198 (+0.000%)

Those error percentages are for voltage drop over the top half of the resistor divider, not for the resulting voltages. For example, the 180 & 330 combo would have an error of . Not bad for parts you can get at RadioShack.

It turns E192 does have a perfect combo, but it’s not like E192-series resistors are available from Digi-Key. However, you can get E96 resistors to build a divider with only -0.0042% error, which will have so much error due to the bimodal distribution of binned resistor values that the time you’ve spent on making it “correct” would be completely wasted.

Damn.

Appendix: ‘Dat code

/*
 * 2011 Xo Wang
 * I hereby release this into the public domain, something about merchantability, blah blah. If you use it, it'd be nice to let me know.
 *
 * You'd be an idiot to use this; it does many things very wrong for the sake of expedient solution-getting.
 */

#include <algorithm> // <3 lower_bound, <3 set_union
#include <iostream>
#include <limits>
#include <string>
#include <vector>

#include <cstdlib>

static double error(const double r1, const double r2) {
	return (r2 * 1.7) / (r1 * 3.3) - 1.0;
}

static void process_series(const std::string &name, const std::vector<int> series) {
	using namespace std;

	int min_error_r1 = 0;
	int min_error_r2 = 0;
	double min_error = numeric_limits<double>::max();
	for_each(series.begin(), series.end(), [&](const int r1) {
		// find nearest resistance
		const double r2_wanted = r1 * (3.3 / 1.7);
		// r_wanted is too large, so scale it down by ten when searching
		const bool r2_wanted_10x = r2_wanted > series.back();
		const auto r2_higher_iter = lower_bound(series.begin(), series.end(), r2_wanted_10x ? r2_wanted * 0.1 : r2_wanted);

		// nearest two resistance values
		const int r2_higher = r2_wanted_10x ? *r2_higher_iter * 10 : *r2_higher_iter;
		const int r2_lower = [=]() -> int {
			if (r2_higher == series[0] * 10) {
				return series.back();
			}
			return r2_wanted_10x ? *(r2_higher_iter - 1) * 10 : *(r2_higher_iter - 1);
		}();

		if (fabs(min_error) > fabs(error(r1, r2_lower))) {
			min_error = error(r1, r2_lower);
			min_error_r1 = r1;
			min_error_r2 = r2_lower;
		}

		if (fabs(min_error) > fabs(error(r1, r2_higher))) {
			min_error = error(r1, r2_higher);
			min_error_r1 = r1;
			min_error_r2 = r2_higher;
		}

		//cout << "  r1 = " << r1 << ", r2 = { " <<
		//		r2_lower << " (" << error(r1, r2_lower) * 100 << "%), " <<
		//		r2_higher << " (+" << error(r1, r2_higher) * 100 << "%) }\n";
	});

	cout << name << " best: r1 = " << min_error_r1 << ", r2 = " << min_error_r2 <<
			" (" << (min_error > 0 ? "+" : "") << min_error * 100 << "%)\n";
}

static std::vector<int> merge_series(const std::vector<int> &s1, const std::vector<int> &s2) {
	using namespace std;
	vector<int> out_series(s1.size() + s2.size());
	auto last = set_union(s1.begin(), s1.end(), s2.begin(), s2.end(), out_series.begin());
	out_series.resize(distance(out_series.begin(), last));
	return out_series;
}

int main() {
	using namespace std;

	const vector<int> E12 = { 100, 120, 150, 180, 220, 270, 330, 390, 470, 560, 680, 820 };
	const vector<int> E24 = { 100, 110, 120, 130, 150, 160, 180, 200, 220, 240, 270, 300, 330, 360, 390, 430, 470,
			510, 560, 620, 680, 750, 820, 910 };
	const vector<int> E48 = { 100, 105, 110, 115, 121, 127, 133, 140, 147, 154, 162, 169, 178, 187, 196, 205, 215,
			226, 237, 249, 261, 274, 287, 301, 316, 332, 348, 365, 383, 402, 422, 442, 464, 487, 511, 536, 562, 590,
			619, 649, 681, 715, 750, 787, 825, 866, 909, 953 };
	const vector<int> E96 = { 100, 102, 105, 107, 110, 113, 115, 118, 121, 124, 127, 130, 133, 137, 140, 143, 147,
			150, 154, 158, 162, 165, 169, 174, 178, 182, 187, 191, 196, 200, 205, 210, 215, 221, 226, 232, 237, 243,
			249, 255, 261, 267, 274, 280, 287, 294, 301, 309, 316, 324, 332, 340, 348, 357, 365, 374, 383, 392, 402,
			412, 422, 432, 442, 453, 464, 475, 487, 491, 511, 523, 536, 549, 562, 576, 590, 604, 619, 634, 649, 665,
			681, 698, 715, 732, 750, 768, 787, 806, 825, 845, 866, 887, 909, 931, 959, 976 };
	const vector<int> E192 = { 100, 101, 102, 104, 105, 106, 107, 109, 110, 111, 113, 114, 115, 117, 118, 120, 121,
			123, 124, 126, 127, 129, 130, 132, 133, 135, 137, 138, 140, 142, 143, 145, 147, 149, 150, 152, 154, 156,
			158, 160, 162, 164, 165, 167, 169, 172, 174, 176, 178, 180, 182, 184, 187, 189, 191, 193, 196, 198, 200,
			203, 205, 208, 210, 213, 215, 218, 221, 223, 226, 229, 232, 234, 237, 240, 243, 246, 249, 252, 255, 258,
			261, 264, 267, 271, 274, 277, 280, 284, 287, 291, 294, 298, 301, 305, 309, 312, 316, 320, 324, 328, 332,
			336, 340, 344, 348, 352, 357, 361, 365, 370, 374, 379, 383, 388, 392, 397, 402, 407, 412, 417, 422, 427,
			432, 437, 442, 448, 453, 459, 464, 470, 475, 481, 487, 493, 499, 505, 511, 517, 523, 530, 536, 542, 549,
			556, 562, 569, 576, 583, 590, 597, 604, 612, 619, 626, 634, 642, 649, 657, 665, 673, 681, 690, 698, 706,
			715, 723, 732, 741, 750, 759, 768, 777, 787, 796, 806, 816, 825, 835, 845, 856, 866, 876, 887, 898, 909,
			920, 931, 942, 953, 965, 976, 988 };

	cout.setf(ios::fixed, ios::floatfield);
	cout.precision(3);
	process_series("E12", E12);
	vector<int> series = merge_series(E12, E24);
	process_series("E24", series);
	series = merge_series(series, E48);
	process_series("E48", series);
	series = merge_series(series, E96);
	process_series("E96", series);
	series = merge_series(series, E192);
	process_series("E192", series);

	return EXIT_SUCCESS;
}

1. Actually, the code runs in O(N * log N) time rather than O(N²) time: given some high-side resistance, I run a binary search on which low-side resistor value gives the best divider. I loop over all high-side resistances.

No, seriously, I’m not dead.

Here’s what the next prototype looks like. Note the compact size, the modern Bauhaus “function over form” styling, and lack of a hand controller: all control is done by simply leaning.

The final product may look even better!

If you’re completely unsure about prices, here are some related products:

Also check out another styling option from Jamo:

So I’m pretty sure I haven’t blogged about quaternions yet, so here goes: god damn quaternions.

Also, no blood for Euler. I’m no hippie, but we need to reduce our dependence on Euler angles and move on to a more modern, sustainable representation of orientation with no singularities. I’m not willing to send off young American men and women to die just for the sake of your decadent way of determining attitude.

Here’s a sneak preview of what I’m doing these days (besides everything else):

It’s a really simple simulation framework for nonlinear recursive estimation filters for attitude determination. Like “dynamically-compiled rasterizing software renderer,” this doesn’t actually mean anything, but I’m still looking for a good acronym. If I throw in “orientation,” I get enough letters for “NOFEAR,” but “nonlinear orientation filter estimation attitude recursive” makes no sense.

By the way, the screenshot above looks crappy because I made it look crappy; I wanted to post a second screenshot later and claim that I made mad improvements to the visualizer. It actually looked pretty decent prior to the lo-fi’ing:

Yeah, so I just failed at lying for fun and profit. Oh well. Though I really do need a better model for orientation visualization than the Ohio waterspout¹…

I’ve got a big pset due in 8 hours and an exam in 6 hours, so I guess I better stop write-crastinating.

God damn quaternions. ♥

1. Credit to my friend TH for the name

Transmitten

would be a great name if my setup involved some sort of sensory glove and I hadn’t brutalized the German language, but it doesn’t and I have…

The transmitter

I could explain the design, but I think this video is more helpful (though not very helpful):

HÄRDBÖRD: Interesting Bits

I think it’s fairly obvious what I was trying to do here, though poor camerawork coughjamisoncough kind of obscured how moving the joystick on the Nunchuk controlled Jamison’s three-pound battlebot, Cake. Wirelessly. Anyways, a series of dysconscious design decisions led to the following desired specs:

• Wireless control of the BÖRDs
• Wii Nunchuk as the human interface
• Some sort of reliable 2.4GHz link (radio hardware with a protocol stack built in)

Everything else fell into place right after that. I grabbed two pairs of the lowest-end Xbee radio transceivers as well as the cheapest USB adapters and breakout boards I could find for them. “O Captain,” you cry, “that’ll be from Sparkfun, right?”

Yeah no, Sparkfun is for tools, man. They were so much better when they were underground. </hípster>

Surprisingly enough, Parallax has Xbees at the same price as Digi-Key/Mouser, $3 breakout adapter boards¹, and a $20 USB breakout². And you thought they’re those overpriced backwards BASIC Stamp kids who supposedly got superseded by the Arduino clusterfugue³.

The rest of the article is about the technical hacks I used in software to reduce complexity, part count, cost, etc. Boring stuff.

Nunchuk

First off, it’s “nunchuk.” Not “nunchuck,” which is what you do in a convent.

Secondly, these things are an awesome addition to any project requiring an analog joystick, two buttons, and a three axis gyro, mounted in an overly ergonomic housing with Apple aesthetics and Nintendo unbreakability. Take care not to drop them though—you might break the floor. Nunchuks can be accessed through a simple I²C interface, exposed physically through six spring contacts in the connector for which simple adapters are available.

Keep in mind that the Nunchuks have gold-plated spring contacts and there is a tin finish on those adapters. This causes some sort of galvanic reaction and you get a lot of streaky black residue on both after a few months of use. Ew.

Now, I haven’t written straight C for a while now, so I wondered what sort of twisted interface code I’d come up with to grab data off of these things. Oddly enough I didn’t screw up the external interface that badly:

typedef struct {
	uint8 joyX;
	uint8 joyY;
	uint16 accelX;
	uint16 accelY;
	uint16 accelZ;
	uint8 buttonZ;
	uint8 buttonC;
} NunchukData_t;

void nunchukInit(void);
int nunchukReadData(void);
NunchukData_t nunchukGetData(void);
void nunchukPrintData(void);

Yeah, so if you were to use my code, you’d see a C struct for the data output and four self-explanatory functions. Clean and simple.

However, my implementation in the source file (attached) is way shakier, involving GCC attributes, bitfields, and anonymous union-nested anonymous structs. But hey, that’s how I roll when I want to decode binary data. First I define this… thing:

typedef struct __attribute__((__packed__)) {
	union {
		struct {
			uint8 joyX;
			uint8 joyY;
			uint8 accelX_HI;
			uint8 accelY_HI;
			uint8 accelZ_HI;
			uint8 buttonZ   : 1;
			uint8 buttonC   : 1;
			uint8 accelX_LO : 2;
			uint8 accelY_LO : 2;
			uint8 accelZ_LO : 2;
		};

		uint8 buffer[6];
	};
} NunchukRegisters_t;

What is that supposed to achieve? Well, it’s basically a 6-byte long C struct which corresponds to the bit patterns read off of the Nunchuk. Based on reading materials, I know that the data is encoded/ciphered by the byte, and all the decoded data is swizzled together to save bandwidth.

Thus, I have a union between the aforementioned struct and a size 6 byte array so I can fill up and decode the struct in a per-byte fashion, just by looping over the unioned array. The __attribute__((__packed__)) is just an futile, unnecessary hint to my compiler to make sure it doesn’t pad out my struct with extraneous bytes.

How do I use this struct? Now this is the beautiful part:

int nunchukReadData(void) {
	NunchukRegisters_t nunchukRegs; // allocate space
	readNI2C1(NUNCHUK_ADDR, nunchukRegs.buffer, 6); // read from nunchuk

	int i;
	for(i = 0; i < 6 ; i++) { // decode by byte
		nunchukRegs.buffer[i] = nunchukByteDecode(nunchukRegs.buffer[i]);
	}
	// assemble raw data
	nunchukData.joyX = nunchukRegs.joyX;
	nunchukData.joyY = nunchukRegs.joyY;
	nunchukData.accelX = (nunchukRegs.accelX_HI << 2) | nunchukRegs.accelX_LO;
	nunchukData.accelY = (nunchukRegs.accelY_HI << 2) | nunchukRegs.accelY_LO;
	nunchukData.accelZ = (nunchukRegs.accelZ_HI << 2) | nunchukRegs.accelZ_LO;
	nunchukData.buttonZ = !nunchukRegs.buttonZ;
	nunchukData.buttonC = !nunchukRegs.buttonC;

	DELAY_US(50); // comm delay so nunchuk doesn't complain
	nunchukRequestData(); // signal nunchuk to read sensors again
	return 1;
}

Notice how the unioning lets me fill up the registers without janky casting, and the bitfields in the nested anonymous prevents me from having to shift or mask off bits in order to decode the Nunchuk registers into my output data struct. For comparative delta, this is how the “reference implementation” looks on the Arduino:

// from http://todbot.com/arduino/sketches/WiichuckDemo/nunchuck_funcs.h
int joy_x_axis = nunchuck_buf[0];
int joy_y_axis = nunchuck_buf[1];
int accel_x_axis = nunchuck_buf[2]; // * 2 * 2;
int accel_y_axis = nunchuck_buf[3]; // * 2 * 2;
int accel_z_axis = nunchuck_buf[4]; // * 2 * 2;

int z_button = 0;
int c_button = 0;

// byte nunchuck_buf[5] contains bits for z and c buttons
// it also contains the least significant bits for the accelerometer data
// so we have to check each bit of byte outbuf[5]
if((nunchuck_buf[5] >> 0) & 1)
	z_button = 1;
if((nunchuck_buf[5] >> 1) & 1)
	c_button = 1;

if((nunchuck_buf[5] >> 2) & 1)
	accel_x_axis += 2;
if((nunchuck_buf[5] >> 3) & 1)
	accel_x_axis += 1;

if((nunchuck_buf[5] >> 4) & 1)
	accel_y_axis += 2;
if((nunchuck_buf[5] >> 5) & 1)
	accel_y_axis += 1;

if((nunchuck_buf[5] >> 6) & 1)
	accel_z_axis += 2;
if((nunchuck_buf[5] >> 7) & 1)
	accel_z_axis += 1;

Yeah… I’d rather have nested anonymous structs than line after line of nasty bit twiddling. Let’s ignore the fact that the above example is a snippet of application code, while my decoding was library code, making it instantly superior from a software engineering standpoint. That is, the programmer who uses my code can pick up and run with an interface which is decoupled from how bits are swizzled by the Nunchuk. But, the coder above would have to reference a couple of websites to write her own decoding routines before printf‘ing the data, for example.

Non-volatile storage

If there’s one thing I’m unhappy about with my choice of microcontroller, it’s that it doesn’t have built-in data EEPROM. EEPROM is flash memory, which is non-volatile—its contents are retained even when powered off. Most decent PICs have, in addition to RAM and program memory flash (where all your code is stored), a piece of data EEPROM acting as a memory-mapped peripheral which you can use as if it were an external EEPROM chip over SPI or I²C. The dsPIC33 family does not have this⁴.

But I still want my non-volatile storage, so I can store Nunchuk calibration data in the transmitter. How? We write it to the program flash. To make a long story short, this is a fairly complicated procedure which was achieved by using Microchip’s Data EEPROM Emulation library, which turns unused program flash space into software-addressable EEPROM blocks. It even spreads writes over different blocks of allocated program flash in order to reduce wear on the EEPROM cells.

Trouble was, this library had some fairly odd software engineering practices, like putting way too much internals in a public header. It also used a separate unit of assembly language routines so the library could use specific instructions for flash reads and writes, when they could have been done in inline assembly, or even better, compiler built-in functions. It’s not like your assembly is more portable when you put it in a separate file, Microchip. :\

My modifications and simplifications to the library are attached to this post.

The protocol

RC control is essentially packeted data; each piece of data you send is a full state of what motors/LEDs should be doing what, with no dependence on past or future data. Xbees provide you with a bidirectional stream (yes, I know it’s packets underneath) rather than a packet interface like Nordic radios. For those who grok teh nets, it’s more TCP and less UDP.

So, I hacked up a protocol that took advantage of both: use escape characters and base64 encoding to represent binary packets, and human-readable ASCII which is ignored by the receiver.

First I define a data structure. Starting to see a pattern?

typedef struct {
	union {
		struct {
			uint16 speed;
			uint8 reversed;
			uint8 brake;
		};
		uint8 buffer[4];
	};
} FluffyData_t;

FluffyData_t⁵ is the information the receiver cares about: speed, direction, and whether to brake. This is put through a base64 encode⁶, and surrounded with non-base64 escape characters, ^ and $, into a 10-byte ASCII string.

Now, everything outside of those escape chars can be easily parsed out on the receiving end. So, now we have easily-decoded binary data represented as ASCII so it doesn’t screw with our terminals, and we can stick “comments” into the stream so we can peek in and read debug output.

For example, this is what actually goes through my Xbees:

(Accel) x: 664, y: 450, z: 612 (Joystick) x: 148, y: 196 (Button) z: 1, c: 0
(fluffy) speed: 46260, reversed: 0, brake: 0
^tLQAAA==$
(Accel) x: 664, y: 450, z: 614 (Joystick) x: 148, y: 197 (Button) z: 1, c: 0
(fluffy) speed: 47031, reversed: 0, brake: 0
^t7cAAA==$

That’s right, most of it is human readable. Only a tiny fraction of it is for the machine. This is called taking advantage of the bandwidth.

On the receiver end, it’s trivial to listen for a ^ character, start decoding base64 into another FluffyData_t struct, and then stop decoding upon receiving a $ character. Of course I am oversimplifying data integrity issues here, which are remedied in my design with a few simple checks and CRC16 checksums.

Code listings

• nunchuk.c
• nunchuk.h
• DEE Emulation 16-bit.c
• DEE Emulation 16-bit.h

Note that I use the excellent Reese/Jones/Bruce library for PIC24 & dsPIC33 as my hardware interface library, which is referenced in the nunchuk.c code for I²C routines.

1. With pin headers, Montresor! Sparkfun sells only headers at the same cost.
2. Really a USB to serial adapter + LDO regulator with an Xbee footprint.
3. OK, they are. But still. SUPPLIES!
4. Though dsPIC30 does, for some reason.
5. HÄRDBÖRD used to be called Fluffy, in case you’re wondering about the name.
6. Note the byte array union again, which is great for doing binary transforms like b64 encoding.

Introducing HÄRDBÖRD, the new reason for my keyboard layout

Today, I want to turn your attention to HÄRDBÖRD¹, this wireless, all-aluminum electric longboard/deathtrap project I got myself involved in. My roommate Jamison and I are the principal designers (engineers? build slaves?) on a pair of these for fun and… leverage against The Man? The idea here is to get some learning done, but we do end up with ridiculously cool looking, possibly overpowered boards to ride around campus on:

Take that, campus shuttle!

I’m mostly in charge of the electronics, which are pretty simple compared to the all the other stuff. Most of it was done in about a week². The plan is to use a Wii Nunchuk to wirelessly control the motor controllers. Why a Nunchuk? Why wireless? These transcendental questions of painful gravity are endless, but I can not answer them.

Jamison has done much of the mechanical design and machining, though I’ve been able to contribute a bit in the shop by learning the trade (i.e. the OMAX waterjet cutter in the Invention Studio at Georgia Tech). The boards are almost all waterjet-cut 6061 aluminum, with custom trucks, wheel hangers, deck—the whole shebang. We’ve run into a few snags where the wheel hangers don’t center with as much force as we’d like (in fact, not enough to be rideable); I have an elegant solution involving one spring and a cam, but it’s unmachineable and apparently patented or licensed by Original.   

Power runs from huge 4000mAh 6S1P pack lithium-polymer batteries (22.2V nominal, 25.2V max). They’re really not that big, but I haven’t built large bots for a long while so their size still surprises me. This juice runs to a pair of Turnigy brushless motors mounted within 4-inch 30A durometer polymer-core wheels, though what goes in between the motors and the batteries is still up for debate with the bean counters—no motor control solution for the pair of the boards costs less than $300.

For more information on “getting the boards to move,” see Jamo’s posts on Härdbörd.

Meanwhile, we’re thinking of using a pair of Maxon DEC 50/5 (PDF) sensored brushless control modules. Now I’d personally prefer to build my own brushless controllers, but we really want to see this on the road. These take in a few digital signals and a 0–5V analog signal for speed. Unfortunately, everything electronic I covet and hold dear (including my low-MIPS microcontroller of choice, the Microchip dsPIC33FJ128GP802) use 3.3V, and I hate analog like that flat watered-down Sprite you get from really stingy restaurants in NYC’s Chinatown. No sir, no op-amps in my design; I’d rather drink diet.

An aside on my choice of µC

The nice thing about the dsPIC33FJ128GP802 is that it’s chock-full of every sort of peripheral, as described in its 386-page datasheet. If you don’t have a software solution, it has a hardware solution. If you don’t have a hardware solution, it has a hardware solution. If you already have a solution, IT HAS A HARDWARE SOLUTION.

In my computer architecture class, the professor was talking about the DEC VAX having a POLYD instruction to evaluate polynomials and everyone laughed at the ridiculously complex ISA co-designed by two Stuy alums. Then I realized, “dang, the dsPIC has a polynomial evaluator for CRC calculations!” Hardware bloat is not fastest in Intel’s newest SIMD floating point SSE6.8d extension, but in these little 8- and 16-bit buggers by means of the memory-mapped peripheral.

I mean seriously, in addition to the usual timers, ADCs, I²C, SPI, U(S)ARTs, CAN, and other junk, it’s got freaking DMA and multi-priority interrupt system for all of those. Then they decide that wasn’t enough and crammed an extra ALU and barrel shifter in there with 40-bit accumulators and called it a DSP engine. But wait, there’s more! There’s more space on the die! Let’s shove a comparator and a real-time clock in there! Now they had more hardware than they had pins, so what do they do? STICK MUXES AND TRISTATE DRIVERS EVERYWHERE. Yeah, that’s right, almost every peripheral on this thing can be mapped to any pin. This thing even solves your PCB layout issues because you can reconfigure your pinout in software.

Oh yeah, this thing also doesn’t need a crystal to run at its full 40MIPS, has a free official GCC compiler, and comes in 28-pin breadboadable through hole (as free samples!). Life doesn’t get more perfect.

The receiver

Aside aside, I wanted to output  0–5V analog from my dsPIC33F. Well, first thing I see is that it’s got this DAC peripheral. Everything is fine and dandy unti—AUGH IT OUTPUTS A DIFFERENTIAL SIGNAL. In other words, not only is it not 0–5V, it’s not even 0–3.3V. It’s some janky 0.8–2.8V (-ish. Don’t quote me.) swing for audio use. Darn, now I have to ghetto-hack a DAC from the PWM hardware.

Fortunately, this is extremely straightforward. The Output Compare module, as the “PWM” module is called in the dsPIC33F/PIC24H lines, is one of the most pleasant hardware peripherals I’ve ever used, on any computer, ever. Put it like this: it’s easier than the software way. You set up a timer with some prescaler values against system clock, as well as a period match register for when it should reset the timer counter to 0. That’s right: not only can you set the frequency of the timer tick, but also the period by which it resets. Awsm.

static inline void configTimer2(void) {
	T2CON = T2_OFF | T2_IDLE_CON | T2_GATE_OFF | T2_32BIT_MODE_OFF | T2_SOURCE_INT | T2_PS_1_1;
	PR2 = usToU16Ticks(PWM_PERIOD, getTimerPrescale(T2CONbits)) - 1;
	TMR2 = 0; //clear timer2 value
	_T2IF = 0;
	_T2IP = 1;
	_T2IE = 1; //enable the Timer2 interrupt
}

Anyways, next you just set up the output compare module to use that timer.

static inline void configOutputCompare1(void) {
	T2CONbits.TON = 0; //disable Timer when configuring Output compare
	CONFIG_RB14_AS_DIG_OUTPUT();
	CONFIG_OC1_TO_RP(14); //map OC1 to RP14/RB14
	//assumes TIMER2 initialized before OC1 so PRE bits are set
	OC1RS = 0; //initially off
	//turn on the compare toggle mode using Timer2
	OC1CON = OC_TIMER2_SRC | //Timer2 source
			OC_PWM_FAULT_PIN_DISABLE; //PWM, no fault detection
}

The way this work is basically described by this timing diagram:

When the timer counter is less than register OC1RS, the OC1 pin (reconfigured by software as described above, to RP14) is output high. Otherwise, it’s output low. The period of rollover is defined by the timer’s period register PR2. In other words, the duty cycle (and thus average voltage) is exactly³ OC1RS/PR2.

Aside: you know why this would be useless on your ATMEGATRON9000KFLASH4BYTERAM AVRDUINO CAPPUCCINO2001 device? It’s 8-bit. All of these registers would be 8-bit, and you’d either have crappy 8-bit timers that can’t do straightforward PWM like this or some janky concatenated 2×8-bit monster with terrible latency and 40 pages in errata. End aside.

OK, so now we know how the PWM works. But how do we get 5V output? Surely we’ll need an op amp to up our range to fiv—CATSLAP. We don’t like your kind here.

Yeah, so there’s a dsPIC peripheral solution here. The digital pins on the dsPIC have an open-drain operation mode⁴. A pin in open-drain output mode is hard pull to low (drain) when its port register bit is 0, and tristated (high-impedance, Z, floating) when its bit is 1. This means you can hook up 5V pull-up resistor to it, and get 5V output from a 3.3V device.

Now all I need to do is feed that 5V signal to a RC filter tuned to attenuate the PWM frequency, and I’ll have a clean 5V DAC output. I feel like freaking 诸葛亮 right here.

The test

I’m working on all of this in the Invention Studio because I want an oscilloscope for this. Now the Invention Studio is an Mechanical Engineering shop, so the o-scope is a bit dinky, but hey, it’s digital, there are working probes around, and it works… for the most part.

"Try a USB flash drive which has a smaller memory size." OK, what?

Anyways, I don’t have real o-scope captures, so bear with my cellphone camera photos of the various test cases. So here’s the circuit under test:

The transmitter and receiver ghettoed up to a power supply and scope

Now let’s get some data:

This is the PWM output from the dsPIC, without open-drain

Being able to adjust the duty cycle of the waveform with a joystick is some hot stuff, especially if you fiddle with the trigger settings a bit. Now let’s hook up a 100KOhm×0.1µF RC filter on that. This has a cutoff frequency of about 16Hz, at which point half the signal is attenuated. Higher frequency signals are attenuated at 20dB per decade, so the 3.28kHz PWM frequency is attenuated by at least 40dB. Good enough for me to play Etch-A-Sketch on the scope with my Nunchuk:

With RC filter and slooow sweep scope samples

And just for the hell of it, I measured the ripple of the analog:

About 30mV. Not bad. Taking this measurement was a real pain: I had to keep my joystick finger steady while zooming/panning on a tiny sliver of the vertical scale, throw in measurements, and praying that a little twitch won’t throw the waveform off the triggering level.

So, that concludes this really boring part of “reducing part count of everything to just a dsPIC.” Next time, I’ll show how I did this with the transmitter side.

1. Credit goes to Charles for this awesome name. Note that the Umlauts are metal umlauts, not actual German.
2. Much of that time was spent coding with my shirt off while Rammstein blasted from my workstation.
3. Actually, there’s a fencepost error here I’m glossing over, but which is covered by my code snippet.
4. Well, all of the I/O pins on the equivalent PIC24H do, but you’re not supposed to use the dsPIC analog pins in open-drain since they’re not 5V tolerant. Yes, it does work, but this puts your app outside of spec.

Hi again,

It’s Xo once again, the ever-adoring fan of the academic advisement office at the Department of Electrical and Computer Engineering. I’d just like to update you on my summer as it has been so far since I received your fantastic insight into the only pedagogical path appropriate to me at this point in my life.

So far, I have taken the path of the wastrel. These past months have seen me experiment with various illegal substances and participate in violent (though hardly consequential, in my humble opinion) street crime, all while I gamble away my personal assets.

In anticipation of my next year of valuable instruction, especially in the humanities (oh them!), I’ve taken on cutting my body as an extracurricular. I find that it is an extremely intense form of expression. Cutting enthusiasts have advised me that I am a “natural” and that I should enter the pros—perhaps eventually compete in the World Championships.

I have shrugged off warnings from friends and family about my declining state of health and squalorous living conditions. I see no reason in their concern. After all, they’re the ones who suggested that I should have a say in the choice of coursework at university and that I should be free to pursue my education at a level comfortable for me. Ha! They were demonstrated to be wrong by your highly logical and considerate counseling; who are they to now dissuade me from a path that will lead to assured ruin among the outcasts of society?

Yours,
Xo Wang

Alright, so I haven’t actually been doing of the above mentioned, but instead trying to hold a job. The Office of Professional Development, or rather the whole of Georgia Tech, has been exceptionally unhelpful towards that end.

Though they are often lauded for their great co-op & internship programs, GT basically withholds opportunities from freshmen. Their website isn’t open to anyone below a certain number of credit-hours and the staff are just unhelpful. What, are you afraid your students might catch up to those at better schools? God forbid any of us should get a head start on this professional development thing.

I started a bit at a hedge fund, decided finance was not for me, and switched into a rewarding internship at Barnes & Noble, thanks in great part to a wonderful friend and mentor. Developing applications is pretty nice.

As an aside, I highly recommend the sandwiches from Financier Patisserie and burgers from Jimbo’s, if you’re ever around that corner in Midtown East. They’re good stuff.