Services

Thu, Apr 12, 2018

There’s five main servies that I offer: Project Planning, Hardware and Software Prototyping, Hardware Design, Firmware Development, and Software Development. Below you’ll find some thoughts on each.

Project Planning

Have an idea for a technology product or service that you want to build? Let’s sit down and nail down:

• Business Requirements: What exactly are we trying to build? Who are we trying to help with the product, and are they willing to pay us?

• Technical Requirements: Is it a purely software product? Is there hardware? How much existing technology can we leverage vs. how much new technology? Are there new algorithms to build? Are there physical constraints?

• Work Breakdown and Estimation: The painful questions… how much is it going to cost, and how long is it going to take?

Hardware and Software Prototyping

I’m a huge fan of books like The Lean Startup. For many software projects, prototyping is pretty straightforward and obvious: build the highest value features first, and iterate as you go. Do the simplest thing that could possibly work, and get it in front of users quickly. Call it Kanban (a constant value flow), call it SCRUM (iterations focused on the highest value tasks), call it whatever you want. Let’s get the minimum viable product out in front of users as soon as possible.

For hardware it’s trickier, because you’ve got real physical manufacturing going on. My general approach to hardware prototyping progresses along a pretty standard path:

• Get dev boards for the main/hardest pieces of the design
• Bodge them together and get the simplest firmware possible running on the system
• Verify that the chosen hardware can actually do what you want it to do, and iterate on parts/code until you have a reasonable demo of functionality
• Once we’ve got a proof-of-concept, do a relatively quick board layout. This means that we’ll have all the parts on a single board instead of this mess of wires and development boards. It’ll take a couple of weeks for this to be manufactured, so it’s better to get this done sooner than later.
• While we’re waiting for the first revision of the board to come back, continue iterating on the firmware. The first proof-of-concept was to prove out the hardware design; now we’re back into the “software iteration” cycle where we’re building out the most valuable features.

I’ve also got a decent collection of development boards stocked here, and if we need a part that I haven’t used before… Digikey has overnight shipping.

Hardware Design

I’m happy doing all of the aspects of hardware design, and am also fine working with existing teams to do any of these parts:

• Conceptual/Block Diagrams/Signal Flows: I like to put extra effort in at this stage, to make sure we’ve really understood the problem we’re trying to solve and nailing down how the hardware will support the software. Errors at this stage are very costly.

• Schematic design: I’m happy designing analog, discrete digital, microcontroller-based, and FPGA-based designs. If you’re going for exotic RF stuff, I might not (yet) be the person for you, although I’ve got plans to prototype out a couple of ideas soon.

• Schematic capture: I’ve got licenses for Altium CircuitStudio and Autodesk Eagle, and I’m quite proficient at taking designs and turning them into CAD. I’m pretty picky about things like Net names and correctly marking every pin as an input/output/power pin.

• Circuit board layout: I’m also reasonably proficient at doing board layouts. I’m very detail-oriented with the layouts, and spent a lot of time doing pre-manufacturing validation. For a cheap board, messing up the first revision doesn’t cost a lot of money, but it really messes up the schedule. I’d rather spend a couple of extra days before manufacturing than have to inject an extra month into our schedule if a board comes back bad.

• Mechanical design: This is a relatively new skill that I’ve been picking up. In the past, mating circuit boards to mechanical pieces was always a bit painful and error-prone. A few months back, I started doing Autodesk’s Digital Manufacturing series of courses on Coursera and have gotten significantly better at this. CircuitStudio can export 3D models of the designed circuit boards, and those can be imported into Autodesk Fusion 360. Very cool!

• Testing: In school, colleagues would sometimes hesitate to show me their solutions to problems, because they were worried that I’d find the flaws. I take designs and try to come up with as many failure modes as possible, and figure out how to address them. I’m not quite at the level of the IBM Black Team, but we’ll probably find defects together.

Firmware Development

It’s weird for a 34-year-old to say he has 23 years of experience with C, but I really did get my first C compiler when I was 11 years old. That machine was about as powerful as a modern ARM Cortex M0.

There’s a couple of unique perspectives that I bring to firmware development:

• Firmware is software and needs to be treated like a software development project. Code is cleanly divided into layers to make it both maintainable and portable. Most of the higher-level functionality can be unit tested by swapping out the Hardware Abstraction Layer (HAL) with a test harness. Code is evaluated for complexity, and overly-complex code must be simplified into testable submodules.

• I have a deep appreciation for state machines and self-contained modules, and a strong aversion to global variables and spaghetti code. Clean, maintainable, reusable code is the name of the game, and I write it so that adding the features next time is no harder than adding features this time.

• When I can, I prefer to use free/open-source tools; this doesn’t mean that the firmware is open source, just that we don’t have to pay wild license fees in order to write software for a $2 microcontroller. These tools also lend themselves very well to automation; instead of having an elaborate build process, most of the time you just type make and 20 seconds later you have a new firmware build, ready to flash to your board by typing make flash.

• I’m happy working on whatever scale of embedded system. A tiny microcontroller with 512 bytes of RAM? No problem. A Cortex M3 with a floating point unit to crunch complex math problems? Great! A full-blown Linux system? I’ve written Linux kernel drivers more than once…

• Most of my experience is with the AVR and ARM Cortex lines of processors, with a little bit of MSP430 sprinkled in. However, if it’s got a C compiler, I’m pretty comfortable grabbing the datasheet, figuring out how to talk to the peripherals, and getting going.

Software Development

To start, I’ll say what I’m not: I’m probably not the person you want to hire to develop your next web or mobile app. I could do it, and if it’s part of a larger project, we can talk about that (e.g. a wearable that needs to talk to a mobile device, or an IoT device that needs to present long-term data trends to the user), but if the web or mobile app is the core of the product, you can find people who are better at that than I am.

Here’s the types of problems that would be a great fit:

• You have tough data processing problems to solve. I can probably help you significantly improve your data processing rate while also saving money on infrastructure costs. I can help you design and build a distributed data processing system if necessary, but I can also help you eliminate the need for one.

• You have a complex algorithmic problem to solve. As examples, I’ve worked on audio processing algorithms, image processing/computer vision algorithms, orbital dynamics and satellite position prediction, large statistics problems, etc. Engineering school taught me a pile of math and statistics, and Computer Science taught me how to build software systems; together, you end up with high-speed, maintainable solutions.

• You have a web application or other existing system that is struggling to scale. Congratulations! You have more users than you thought you’d have! I can sit down with you or your team, help them understand where their bottlenecks are, and help them come up with solutions to the problems they’re having.

• You want to discuss system security and understand your current security posture and plan out ways to improve it, if necessary.

• You want to discuss the feasibility of a system before committing significant time and effort towards building it. We can discuss what you’re trying to accomplish, potentially build out some rapid prototypes, and evaluate estimated build-out costs and staffing needs.