h1

Debugging

December 17, 2014

A podcast listener requested a show about debugging. I’m still working out just what he meant by that but between that and working on a Trinket, I find I have a few things to ponder aloud for you.

First, the Trinket is a small board with an ATTiny85 on it. It is a very low power, deeply embedded sort of processor. With all of 8k of code space and 512 bytes of RAM (and 512 bytes of EEPROM), this is a dinky little thing. Plus, with the on-board bootloader, there is only about 5000 bytes of code space. I feel like a kid again.

So why in the world would anyone use the Arduino interface with this? Well, it is what I have, it is what Adafruit had in their tutorial, and I’m too unmotivated to set up a GCC cross compiler (yet).

Usually when I use the Arduino compiler, it is with a proper Arduino board (or the MicroView which is a “proper Arduino board” for this discussion). Debugging is done via printf because there is a serial connection via USB after the bootloader has finished programming the board.

Under “Debugging Tools” on my resume, I have “DVM, oscilloscope, logic analyzer, JTAG, ICE, printf” so I’m fine with printf as a way to determine what is going on with my code. On the other hand, if I can have an on-chip stepping debugger, I much prefer that. But that isn’t an option with the Arduino compiler so I limp along. Nothing I do on an Arduino is all that complicated.

All that said, the ATTiny doesn’t have the serial debug interface. There is no on-chip debugger and no printf. That means debug is usually through GPIO lines and prayer.

There are tools that could help me. I think. But I’m trying to do it the way everyone else is. Or the way I think they are. I’m writing little pieces of code and running them. I’m blinking the little onboard LED once for good, three times for an error. It look a stupidly long time for me to figure out why my byte variable wasn’t getting to 256. It isn’t impossible to work like this but it is a lot harder.

So, yeah, maybe it is time to talk about debugging. We could start with Arduino (and mbed) and debug through printf. Then go into the tools available for that space. Then the SWD interface for the ARMs (i.e. Cortex-M0). What are ITMs and ETMs anyway? We could talk about timing errors due to debugging (both serial and on-chip). We could talk about the extras that are available on some IDEs (mmm… profiling and backtraces!). We could talk about GDB, how it is super powerful but opaque and a pain to the beginner. We could even talk a bit about data logging and error handling (other listeners have requested shows about these).  I wonder if we’d even get into unit tests since some systems I’ve developed for run on-target-hardware via debugger.

I feel a lot more secure and confident when I can see what my chip is doing. I don’t mind using printf but I’m better at getting things done with better tools. Most tools are cheap compared to my time.

So yeah, debugging…

h1

Another Day of Battery Life

December 16, 2014

To make a ring, I needed to minimize everything. Of course, if you’ve seen the picture, you already know I didn’t actually minimize much.

Still, batteries in wearables are a pain. For this wearable with my “you have to take it apart to charge it” methodology, well, longer battery life means this hack will exist longer. The more I take it apart, the more like it is that I’ll repurpose the parts to do something else. (I have this idea for a different ring…)

Minimizing power in Arduino is a topic that has been taken on by plenty of other people. And I happily reused their code and methods(Thank, you Nick Gammon!).

However, when planning a device, it is helpful to determine the size of battery you need. To that end, I made an Excel sheet (sorry, I default there) which I’ve put into a Google spreadsheet so you can see it with the math. The first sheet (words) describes the process in words. The second sheet (numbers) reflects the same information but with numbers. You fill in the orange boxes, it generates the green one.

The first step is to determine the different power states of the device. For Wordy, it is either on (display showing) or sleeping (Arduino asleep, accelerometer configured to wake and interrupt it).

 

My next step was to figure out how much time the system would spend in each of these states. My goal is for the ring to be on for about five seconds every five minutes. Sometimes it will be on more, as I play with it a lot. More often it will be sleeping, such as left on a table overnight. (Note: if you build a Wordy, I strongly recommend setting the ring so it will lose at Pong. Sometimes if you leave it on the X side with no Y tilt, the ring will play Pong by itself indefinitely.) Starting with the idea of five seconds per five minutes means I’ll probably be on the conservative side (unless it plays a Pong marathon without me).

Next, I measured how much current each state. I used my shiny new DVM-with-current-sensing (my old one didn’t have that (though it did have a more melodious beep in resistance mode)). You can use a resistor if you feel like doing it old school style.

(This pic is from my book. If you were unaware I wrote a book, well, yes, I did and it is full of jokes. And dinosaurs. But mostly embedded systems.)

Finally, I calculated how long the device would last given a 40mAh battery (the largest I was willing to use due to size constraints). The result turned out to be much greater than I expected.

This does not have to be the order of events: you might start with the idea of how long you want the device to last and choose the battery accordingly. Or you may have a fixed battery and a predetermined life and need to determine how much time you can spend in each state. Happily, the math works in all the different ways.

Note that this value I got was greatly in excess of my self-imposed goal (which was a puny two hours). It is also greatly in excess of what I said in the build instructions (which was 48 hours). My wear-time was even greater than the estimated value: I charged on Tuesday afternoon and it died on Saturday night.

Though, I’m pretty sure I can do better than these power numbers.

When I measured the MicroView without the accelerometer, the on-state power fluctuated between 10mA and 14mA, depending on how much of the screen was lit. (All current measurements were taken around 3.7V.) If I modify numbers on the spreadsheet, the on-state power of 10mA to 14mA, it changes from 3.5 days to 3.1 days. I switched it back to 12mA as reasonable middle ground.

The accelerometer doesn’t add much to this on-state value. On the other hand, for the sleep-state power, it is a very different situation. The MicroView alone took 0.14mA. The MicroView and accelerometer together take 0.31mA. If I change the sleep-state power from 0.31mA to 0.14mA, the amount of battery life expected changes from 3.2 days to 4.9 days.

The accelerometer datasheet says the accelerometer’s current consumption is 6uA to 165uA. Looking at the numbers above (0.31mA-0.14mA = 0.17mA ~= 165uA), it is clear I should be able to reduce the sleep-state power by reading over the accelerometer datasheet again. (There is also an application note about wake/sleep features.)

Skimming through the app note, I don’t care too much about the precision of the data (though I might in Pong mode but that is an active mode so it is ok to use more power there). It would be no problem to turn the system from 14-bit mode to 8-bit mode.

Sleep mode is limited to 50Hz sampling but that is what I’m sampling at anyway. Why am I still seeing the max current?

Ahh, according to the oversampling chart, I may see 165uA due to high resolution sampling. I can go to 24uA with normal sampling or 14uA with low power. However, I want some filtering either through oversampling or via the low noise setting. The combination of low noise + low power is back to 24uA.

Making only one change (from high resolution to normal sampling) should be enough to increase my battery life from 3.3 days to 4.6 days. That’s exciting. Excuse me, I need to go see if that’ll work and what else I need to change.

[Note: this was crossposted from Wordy’s Hackaday page project log.]

h1

Hackaday: Wordy

December 9, 2014

I wanted to make build instructions for Wordy but since it uses both SparkFun and Adafruit parts, I couldn’t decide where. Though I did say I was going to put my next project up on Hackaday. I did that. There is a link to the code there as well as build instructions. Anyone here want to check it out for me? Maybe suggest what I forgot?

Wordy Ring

One thing already on my list is a project log of different ring making methods I tried. I’m going to do another pass with Sculpey, taking pics as I go. I also need a final picture of it all together, I plan to take that when I wear it out tonight.

h1

Call for Proposals

December 4, 2014

The embedded systems conference (finally renamed the “Embedded Systems Conference”, yay!) and O’Reilly’s Solid conference have opened their call for proposals (Solid’s and ESC’s). After telling everyone that I’m tired of giving conference presentations, tired of attending conferences without talks that I want to see, that presentations take way too much time to prepare, presenting leads to no goodness for me, I have nothing to talk about, and I have way more fun (and reach more people) on the podcast, I’ve put in three proposals.

Faker to Maker in 30 Minutes

The Maker revolution is obviously here.

What does that mean for those of us who aren’t Makers? We worked hard for these engineering degrees and now sometimes feel daunted (even intimidated?) by the free sharing, open source, do anything, tinker in their obviously copious spare time hackers.

Wait, weren’t hackers the bad guys? (Sometimes, semantics change.)

Will there still be a space for careful, professional engineering? (Hint: yes.)

Most importantly, how can we join forces to get the best of both worlds?

Low Power Strategies for Wearables (and Everything Else)

Sleep early and often. Reduce your clock speed. Turn off your IOs and unneeded subsystems.

Excellent tactical advice only goes so far, this talk will help you understand how to architect software to reduce power usage. Focusing on ST’s Cortex-M0 and Atmel’s ATMega328, Elecia White will describe how to start from a clean slate to get great results and how to utilize some of these techniques on to existing code bases.

Intro to Inertial Sensors: From Taps to Gestures to Location

What is the difference between an accelerometer, a gyroscope, and a magnetometer? What would you use each for? If you aren’t sure, let me explain.

The entertaining host of the Embedded.fm podcast, Elecia White will explain the differences and each sensor’s best uses, on their own and in combination. She will detail the most common ways to put them together and help you determine which are the best choices for your products.

The talk will discuss how to replace buttons with accelerometers, how that leads to gesture recognition, and why integrating to get location is a more difficult problem that it sounds. While you might not be able to implement a Kalman filter by the end of the talk, you will know why it matters.

***

What do you think? One fluffy and two technical. I had a third technical one but it seemed like an awful lot of prep work:

How to Choose a Micro for Your Application

Price, performance, and power war for supremacy. We all want the cheapest, lowest-power processor for our application. But at the beginning of development, we may not know how much performance we truly need. Choosing the wrong processor may lead to a complete redesign, a time to market disaster. How to estimate which family of processors is the best for your application?

Unaffiliated with any chip or compiler vendors, Elecia White is an experienced embedded systems consultant and host of the Embedded.fm podcast. She will explain her methodology, using examples across consumer applications.

The talk will tackle such estimation issues as where to start if you need to run WiFi—that often means running an Ethernet (TCP/IP) stack which means you probably need an RTOS. If you need an RTOS, you probably don’t want an 8-bit ATMega (not that it isn’t possible, just that it isn’t likely to be timely). Start with a Cortex-M3 range and look for the next set of requirements. Power might push you down to a cramped Cortex-M0 or heavy processing might sends you up to the Cortex-M4 (or a dual processor DSP/C-M0 option).

There are tradeoffs everywhere; this road map will help you choose a path.

***

That one also seems like one hundred thousand ways to be wrong since someone will always disagree. I can offer my opinion but I’m sure to frustrate some developer with a crush on PICs. (Because PICs are my least favorite processor. I don’t know why you’d choose a PIC over an ATTiny or an MSP430. Ok, I said it. AVR Freaks unite!)

Anyway, the proposals have been submitted on the idea that I should want to speak, that I should do my part for women-in-tech (bleah), and that I want more listeners for the podcast (which I should remember to mention this time, not like the last presentation I gave, urk).

The proposal deadlines are Jan 9th and 12th so get yours in. I’m only going to the conferences if there is someone I want to see speak. Go propose something amusing and informative, please.

 

 

h1

Giant rings are IN, right?

December 3, 2014

I finished up the working modes of my ring, so rev1 of the software is done. Here’s what it does:

On TAP: shows a vocabulary word. On tap or double tap, shows definition.

On DOUBLE TAP: starts Pong game, paddle position set by tilt of accelerometer.

On UPSIDE DOWN SHAKE: says to consider a question, waits for upside down shake (or punch) to give a response.

On PUNCH: puts up a punch word and a couple rectangles for emphasis.

As long as the wires are secure, this all works pretty well. I still need to format some of the Magic 8 ball style responses. And I could go through the vocabulary words to make shorter (better) definitions. I can probably pick up about 50 words too (yay!). I may continue to get rid of nonsensical floating point stuff so I can put more definitions in. Oh, and I should check the power usage, I didn’t minimize the accelerometer’s draw.

However, those tweaks can all wait as I need to make it wearable again. The button version was wearable but the ring blanks from that are a little too small for the accelerometer+battery stack up.

microView with accelerometer and battery

From another angle

MicroView, accelerometer and battery

 

On the back of the MicroView is a dab of funtac (that stretchy sticky stuff you might have used to hang posters in your dorm room), a modified Adafruit 5V tolerant MMA8451 board (ahem, they didn’t need all that space for logos and mounting holes). Tiny wires are soldered to the board, then hot glued. On the other side, they are soldered to the MicroView.

On top of the accelerometer is a SparkFun 40mAh LiPo battery with its connector snipped. It is held on to the accelerometer with funtac (sometimes I build things entirely from funtac). I needed the battery on the outside so I can remove it for charging. The

This all stacks up higher than I wanted and doesn’t leave much space for attaching the ring to the device. With the button+battery version of the ring, I pressed the MicroView pins into the ring blank and press fit it all together. That doesn’t work so well now, especially as the poorly pressed fit doesn’t hold the power on.

Add connectors

 

I snipped some jumper wire so I could build a connector on the inside of the ring blank. This was just a trial run. It worked out ok but I think I want to do something a little different for the real ones, maybe destroy 8 wires to get 16 connectors. Having attachments only on the pins of interest has some downsides (especially if I don’t line them up properly). More connector ends also lets me add some needed rigidity. Even these few fix the press fit problem. The female connectors are all too bulky though I may look around some more.

Ring on

 

It doesn’t look too bad. Though I think the new black version are going to be better (still waiting for those to dry).

photo 4

Well, let’s see it on!

OnThe 5s timeout on the screen makes it impossible to get an in-focus shot by myself.  Ahh well, you get the idea. This angle is probably the nicest. From the side where you can see the stackup, not so nice. (Realistically, it wouldn’t be hard to cover this.)

head on

But I can’t leave it on that shot, one more, a little prettier.

Sideview