RULES: ACQUIRE FORK TO THE RIGHT OF YOU AS WELL AS FORK TO THE LEFT OF YOU. EAT PASTA. REMOVE AN ARTICLE OF CLOTHING. REPEAT.

RELATED: STRIP RUSSIAN ROULETTE. NO, NOT WITH A GUN.

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

xw@pewter:~$ whois apple.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

APPLE.COM.WWW.BEYONDWHOIS.COM
APPLE.COM.WAS.PWNED.BY.M1CROSOFT.COM
APPLE.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM
APPLE.COM.IS.OWN3D.BY.NAKEDJER.COM
APPLE.COM.IS.0WN3D.BY.GULLI.COM
APPLE.COM.BEYONDWHOIS.COM
APPLE.COM.AT.WWW.BEYONDWHOIS.COM
APPLE.COM

…

xw@pewter:~$ whois google.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

GOOGLE.COM.ZZZZZZZZZZZZZ.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM
GOOGLE.COM.ZZZZZZ.THE.BEST.WEBHOSTING.AT.WWW.FATUCH.COM
GOOGLE.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
GOOGLE.COM.ZOMBIED.AND.HACKED.BY.WWW.WEB-HACK.COM
GOOGLE.COM.ZNAET.PRODOMEN.COM
GOOGLE.COM.YUCEKIRBAC.COM
GOOGLE.COM.YUCEHOCA.COM
GOOGLE.COM.WORDT.DOOR.VEEL.WHTERS.GEBRUIKT.SERVERTJE.NET
GOOGLE.COM.VN
GOOGLE.COM.UY
GOOGLE.COM.UA
GOOGLE.COM.TW
GOOGLE.COM.TR
GOOGLE.COM.SUCKS.FIND.CRACKZ.WITH.SEARCH.GULLI.COM
GOOGLE.COM.SPROSIUYANDEKSA.RU
GOOGLE.COM.SERVES.PR0N.FOR.ALLIYAH.NET
GOOGLE.COM.SANATATEA-NOASTRA.COM
GOOGLE.COM.SA
GOOGLE.COM.PE
GOOGLE.COM.P2NK-AJA.COM
GOOGLE.COM.MX
GOOGLE.COM.LASERPIPE.COM
GOOGLE.COM.IS.SHIT.SQUAREBOARDS.COM
GOOGLE.COM.IS.NOT.HOSTED.BY.ACTIVEDOMAINDNS.NET
GOOGLE.COM.IS.HOSTED.ON.PROFITHOSTING.NET
GOOGLE.COM.IS.APPROVED.BY.NUMEA.COM
GOOGLE.COM.HICHINA.COM
GOOGLE.COM.HAS.LESS.FREE.PORN.IN.ITS.SEARCH.ENGINE.THAN.SECZY.COM
GOOGLE.COM.ESJUEGOS.NET
GOOGLE.COM.DO
GOOGLE.COM.CO
GOOGLE.COM.CN
GOOGLE.COM.BR
GOOGLE.COM.BEYONDWHOIS.COM
GOOGLE.COM.AU
GOOGLE.COM.AR
GOOGLE.COM.AFRICANBATS.ORG
GOOGLE.COM

…

xw@pewter:~$ whois microsoft.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

MICROSOFT.COM.ZZZZZZZZZZZZZZZZZZ.THE.BEST.WEBHOSTING.AT.WWW.FATUCH.COM
MICROSOFT.COM.ZZZZZZZZZZZZZZZZZZ.IM.ELITE.WANNABE.TOO.WWW.PLUS613.NET
MICROSOFT.COM.ZZZZZZZZZZZZZZZZZZ.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM
MICROSOFT.COM.ZZZZZZ.MORE.DETAILS.AT.WWW.BEYONDWHOIS.COM
MICROSOFT.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
MICROSOFT.COM.ZZZOMBIED.AND.HACKED.BY.WWW.WEB-HACK.COM
MICROSOFT.COM.ZZZ.IS.0WNED.AND.HAX0RED.BY.SUB7.NET
MICROSOFT.COM.WILL.BE.SLAPPED.IN.THE.FACE.BY.MY.BLUE.VEINED.SPANNER.NET
MICROSOFT.COM.WILL.BE.BEATEN.WITH.MY.SPANNER.NET
MICROSOFT.COM.WAREZ.AT.TOPLIST.GULLI.COM
MICROSOFT.COM.TOTALLY.SUCKS.S3U.NET
MICROSOFT.COM.SOFTWARE.IS.NOT.USED.AT.REG.RU
MICROSOFT.COM.SHOULD.GIVE.UP.BECAUSE.LINUXISGOD.COM
MICROSOFT.COM.RAWKZ.MUH.WERLD.MENTALFLOSS.CA
MICROSOFT.COM.OHMYGODITBURNS.COM
MICROSOFT.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM
MICROSOFT.COM.MATCHES.THIS.STRING.AT.KEYSIGNERS.COM
MICROSOFT.COM.LOVES.ME.KOSMAL.NET
MICROSOFT.COM.LIVES.AT.SHAUNEWING.COM
MICROSOFT.COM.IS.NOT.YEPPA.ORG
MICROSOFT.COM.IS.NOT.HOSTED.BY.ACTIVEDOMAINDNS.NET
MICROSOFT.COM.IS.IN.BED.WITH.CURTYV.COM
MICROSOFT.COM.IS.HOSTED.ON.PROFITHOSTING.NET
MICROSOFT.COM.IS.A.STEAMING.HEAP.OF.FUCKING-BULLSHIT.NET
MICROSOFT.COM.IS.A.MESS.TIMPORTER.CO.UK
MICROSOFT.COM.HAS.A.PRESENT.COMING.FROM.HUGHESMISSILES.COM
MICROSOFT.COM.FILLS.ME.WITH.BELLIGERENCE.NET
MICROSOFT.COM.CAN.GO.FUCK.ITSELF.AT.SECZY.COM
MICROSOFT.COM.ARE.GODDAMN.PIGFUCKERS.NET.NS-NOT-IN-SERVICE.COM
MICROSOFT.COM

…

Is somebody spamming our WHOIS records?

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.