Magnetometer V: Fixed-Point Math

This is another article in my series about developing a magnetometer-based digital compass. Last time, I talked about estimating code size, and what I might do to fit the application in the roughly 5.25K program space available on an Adafruit Trinket.

In this article, I replace the floating-point math with fixed-point, and make various space-saving improvements to the calibration and rotation code. Read on for more.

Medieval Manuscripts

MS20BXX-78vWe’re kickin’ it old-school on SGS today, with a lovely post on the British Library‘s Medieval Manuscripts Blog. The image to the right is from Royal MS 20 B XX. Click the image to see a larger version, or — far better — use the British Library MS Viewer to browse wonderful, high-res zoomable scans of the original.

Warning: All links above are more perilous Internet time-wasting rabbit-holes than Wikipedia and TVTropes combined.

Magnetometer IV: Code Size

Last time, I presented a working proof-of-concept of a digital compass based on a three-axis magnetometer. That version was running in userland on a Raspberry Pi running Raspbian, which is a whole lot more computer than the Atmel ATtiny85 I eventually want to target. It was also coded for clarity rather than for speed or size.

In this post, I’ll look at some quick-and-dirty ways to estimate program size for an AVR version (as well as some simple things we can do to save space). Read on for more.

Magnetometer III: Working Prototype


In previous posts, I talked about a method of transforming magnetometer readings to compass headings, then experimented with using those transformations on real (but static) data. In this post, I’ll present a working prototype of a vehicle compass using the methods I discussed earlier.
Read on for more details.

Magnetometer Reading to Compass Heading


I’m working on building a digital vehicle compass, using the Honeywell HMC5883L three-axis magnetometer as a sensor. Answering the question “Which compass direction am I facing?” from the raw sensor output data is somewhat more complicated that you might expect. This is especially true when using a microcontroller like the ATTiny85 with extremely limited memory. Read on for a discussion of the problems involved and my solutions.

I2C with ATTiny85 on Adafruit Trinket

SONY DSCThe Trinket microcontroller from Adafruit Industries is a tiny and inexpensive (US$8 for a single unit) way to control your electronics projects. One of the coolest things about it is that you can do I²C (and communicate to lots of inexpensive sensors and displays using only two pins) and still have plenty of room left over for your code in the ~5.5KB of flash on board.

Read on to see an example of how to do I²C communication on the Trinket (or anything with an Atmel ATTiny85)  while shaving every possible byte. Also included: driving the Adafruit Mini 8×8 LED Matrix with I2C Backpack.

BeagleBone Black PRU: Hello World

This article presents what is meant to be the simplest possible example of using the PRU (programmable realtime unit) on the BeagleBone Black single-board computer. The example program has no inputs and no outputs; it does nothing other than delay for a fixed duration then exit. Read on after the jump…

Дракон

d3aa59c54ad861119104cdd14f27f6a3Moscow-based artist Cuarto has created Darkhorn: a brilliant posable dragon figure with ball joints. See his blog post talking about it (in the original Russian) or the same page machine-translated to English. (The image to the right and all images after the break are from that site.)

As you can imagine, they’re not cheap and there’s (at the time of this writing) a long waiting list. Nonetheless, there is an English-language order page where you can join the queue.

More images after the break.