Posts Tagged ‘tech’

Older Entries »
h1

I love engineering pads

January 4, 2016

After having spilled coffee on one pad and actually finished the two others that generally live on my desk, I went to the pile of office supply paper and dug out an engineering notepad. I found this:

Making Embedded Systems Info Sheet

This is clearly a sketch for an information sheet from the podcast two years ago. So much has changed about the show (even its title) that this is a pretty funny little view into the beginnings of the show.

Of course, I wasn’t digging for an engineering pad purely for nostalgia. I wanted to sketch something out. And since I kept re-doing it until it almost looks good, I figure I should share it.

I wanted to know how the itty-bitty quadcopter’s motors worked. This is for the Cheerson CX-10, a quadcopter that is just a bit bigger than a quarter.

 

Posted in Uncategorized | Tagged , , , | 1 Comment »

h1

Throwing Boards Over Walls

August 23, 2015

In response to comments made on Embedded.fm episode 114 (Wild While Loops), an electrical engineering listener emailed us:

We all know that ‘throw it over the wall’ sucks as a business pattern. But it’s sometimes really hard not to; I’ve recently been under pressure to order those new boards already. Or I’ve flat-out overlooked something. Or I misunderstood how much testing the last guy had done. Or whatever. It’s hard.

We know we shouldn’t just throw and run, but it’s hard. Do you have any thoughts on how to persuade my boss that stronger reviews, and getting the embedded software people in on them, are a good idea?

I recognize that “throwing over the wall” between hardware and software is somewhat inevitable, especially as HW and SW sometimes have different schedules. The difficulty comes in when there is also animosity: the EE says the problem is software, the SW says it is hardware; no one works on it because it is clearly not their bug (or works on it resentfully). I remember those days and am very glad I grew out of it.

But how to persuade your boss more reviews (and possibly earlier reviews) are worthwhile? If your boss is a promoted engineer, data might help. How many issues were found and by whom? (That person could be part of the reviews.) How many hours do the SW folks say were lost to HW difficulties (that includes schematics they didn’t understand)? How much will a board respin cost if a problem isn’t identified until a quarter of the way through the software schedule? (Even better: how much did the last respin cost in terms of money and time lost?)

You might also pitch better reviews as cross training: should you win the lottery and go on a bender, a cross trained embedded software person might be able to babysit your work for a couple weeks until you sober up or another EE is hired. (We used to say “get hit by a bus” until my EE actually did; now I try for more positive scenarios.)

I am quite thankful that HP believed in cross training. I know the EEs didn’t get a lot from my review of their schematics (“Can you rename this net because I don’t understand your vernacular?”) but I sure did. It made me more effective in my firmware job because I knew what their plan was. It allowed me to debug with an oscilloscope by myself because I understood the schematic before I had to use it (before I was deep into “there is a problem!!!” mindset). Plus, I could ask for the test points I needed instead of cursing the lack of available signals.

And, of course, it is hard. Not only is the work hard, the boards and code are personal expressions of our brains making criticism difficult to accept gracefully. And engineers often neglect to turn on their niceness modules. And schedules are brutal. There is no time for reviews and it is hard to expose ourselves to the angst.

But you do the best you can and try to do work you are proud of, sometimes fighting the right battles, other times tilting at windmills because part of you knows it is important even when others can’t see it.

Hey, look, a rousing speech to close on.

Posted in Uncategorized | Tagged , , , | Comments Off on Throwing Boards Over Walls

h1

Women-in-tech activities

July 17, 2015

I go to the occasional women-in-tech things. I’ve been to Grace Hopper, once as attendee, once as a speaker/manager bringing her team. I read Systers for years but don’t currently, it is just too much sometimes.

Actually, that sums up my feelings about women-in-tech events pretty well: it is just too much sometimes.  And yet.

I like to attend women-in-tech things because it is nice to see women happy as engineers. Too many times, I hear the horror stories. But there are many people, many women, untouched (or only slightly touched) by the trolls, stalkers, and jerks of the internet. I like to be reminded that it isn’t always awful.

And I go because I get a little lonely in my job sometimes. I like to connect with people who might be in the same boat, maybe offer some advice to those more junior in their career, maybe receive some advice from those more senior.

I also go to find podcast guests. I’m not shy in trying to get a gender balanced podcast despite the lack of gender balance in embedded systems. That means I have to search a little more, work a little harder to get women guests. So I go to women-in-tech meetups hoping to find people.

Though, I’m fairly terrible (stressed) in crowds and I find that seems to be getting worse as I get older. I can pretend to be an extrovert for about 4.5 minutes (8 with alcohol). Then I get jittery and want to throw up. Reeeeallllly Jekyll and Hyde-y.

I went to an event this week. It was ok. There was no alcohol. And the demos (from the hosting company) were done by men (though they were nice, it just seemed like a missed opportunity to highlight some women’s achievements). At least the talks were done by interesting, engaging women… though they were a little long. As someone there for the networking (4.5 minutes of it anyway), I don’t want detailed technical presentations.

It got me thinking about what I’d want to do if I was putting on a women-in-tech event. So let me write these ideas down, maybe it will plant a seed for later.

1. There shall be alcohol. All networking events should have beer and wine.

2. Food will be primarily vegan. Because, crap, I’m tired of not being sure what is safe for my socially-nervous and vegetarian stomach to eat. Maybe steak strips or meatballs too, but everything else will be vegan. Sometimes at these things all I want is a little peanut butter and jelly sandwich. And there will be dessert but it will served later (halfway through), not set out with the food. Dessert doesn’t have to be all vegan.

3. There will be seating but not quite enough of it.

4. For a 3 hour event, there will be four to six 5-minute talks, three at T+30min hour, three at T+65min. The goal of the talks is to create discussion and getting people to talk to each other, not to give speakers platforms. The talks act as ice breakers, the speakers will know that.

5. Badges will have first names only. There will be small stickers for different interests. If it is hosted by a company, they will have small stickers so it is easy to pick out people who work there.

6. There will be different themes in different parts of the room. They will be clearly marked: “I’d love to meet you” (seating and food), “We’d love for you to join our conversation” (seating), “We’re happy in our conversation, give us a minute” (tables but no seating). People won’t have to declare themselves, just stand in the right place. Ok, this one is sort of dumb. Maybe scratch it out and put in a networking/mixer game thingy.

7. It will be a women in tech focused event but open to anyone who wants to support getting more women interested and retained in engineering, math, technology, and science. You do not have to identify as female to come.

8. There will be a few people who are asked specifically to act as hosts, who spend the evening meeting people then introducing them to each other.

9. We will make some horrible mistake against feminism (giving out lipstick, having men do demos, handing out hot pink rape whistles) so that everyone can be aghast at something.

Oh no! We’ve reach the cynicism level. Don’t go deeper, it gets very dark in there.

I’ve been to great meetups, both gendered and not specific. One GirlGeekDinner was fantastic, another one I was lost at. The OSHPark Bring a Hack Maker Fair after party is pretty amazing: Laen gets people there and mingling with each other. Some of that is because they are fascinating people and because we’re told to bring something which creates an icebreaker. But there is something else too.

I don’t know what that something else is. I suppose if I did, I’d bottle it and make millions.

Anyway, there are many women-in-tech things and something always goes oddly but I’m not ready to give up on them yet. Though I’m not ready to throw my own either.

 

Posted in Uncategorized | Tagged , , | Comments Off on Women-in-tech activities

h1

I’ve got an IMU in my pocket and it wants out

December 23, 2014

I have this idea for another ring…

I ordered an Adafruit 9-DOF IMU board for a client who went on holiday vacation before signing the contract so now I’ve got this board burning a hole in my pocket. Given how much I spent at their site, Adafruit sent along a free Trinket board. At the same time, I was starting slides for a presentation entitled “Introduction to Inertial” and working out scheduling details to have ThingM’s Tod Kurt on our Embedded podcast. Combine all these things and what do you get?

One thing you don’t get is something that will easily fit on a ring. Still, if it could, what would I want it to do? Maybe I’ll even get boards made…

The idea stemmed from a magnetometer first. I’ve read about anklets with several cell-phone motors and a magnetometer that subtly teaches you which way is north. I’d love a little ring that glowed white when I was facing north, red when west, and green for east. It would be dark for south. It would be a neat little beacon.

Never mind that the almost-always-on LED will drain a battery fairly quickly so ring mounted will need to be easily rechargeable. Never mind that I’ll need an accelerometer to tilt compensate the magnetometer (oh! must add why to the presentation!). Of course, adding an accel does give me a way to turn it off and on.

Well, if I’m to make the ring, I need to write the code. Hardware is not my forte but if I get it working well, I can probably get help laying out an ATtiny and a magnetometer/accelerometer chip. Though, as long as I’ve got a whole IMU to play with, I might as well use it all.

I spent a few days stripping the Adafruit sensor code of anything I considered unnecessary (floating point? gone! functions that make the sensors interface generic? gone!) so it would fit on the ATtiny in the Trinket (5000 bytes of code space! whee!). And then I wised up and realized I was going to spend all my time making atan2 tables, I should do the prototype on a regular Arduino.

It is funny how 32k feels HUGE and the ATmega is blazingly fast compared to the ATtiny. I stopped rewriting the Adafruit code and started writing the code I wanted. This was a good decision as it gives me more time to play (and since that’s what this is for me, making it seem like work was a good way to get frustrated and move on to another, more fun project).

I think the accelerometer mode should be the simplest. It should glow red if gravity is felt in the X direction (positive or negative), green if Y, blue if Z. This would let me talk about how accelerometers are used as gravity sensors the majority of the time. While free fall detection and actual acceleration are interesting, mostly we want our devices to know which way is down. (Since I’ll use double taps to move between accel, gyro, mag, and off modes, discussing gestures will be natural.)

For the gyro mode, the LED will light proportionally to how fast the rate sensors see movement. This will go nicely with my notes about how rate sensors are only useful when things are moving.

The mag mode will be the North Star implementation I described before.

I started out wanting a ring on a Trinket. Now I want a multi feature demo tool in a box.

(Note: I cross posted this project log from a new Hackaday project. I’ll be putting build details over there as I get it working. I’ll probably post here when I write less technical stuff.)

Posted in Uncategorized | Tagged , , , | Comments Off on I’ve got an IMU in my pocket and it wants out

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…

Posted in Uncategorized | Tagged , , | Comments Off on Debugging

Older Entries »