Introducing Agile into a hardware development process presents quite a few problems that just aren't found in a software-only scenario. Some of these are the nature of the beast, others are remnants of days gone by. Some require the retraining of team members. Others require a small change in definition. In all cases, there are ways around the problem.
To be clear, there are scenarios where hardware development can fit into Scrum sprints. Designing FPGA firmware is one scenario, but the development process for it is so close to software that it is an easy fit. Another scenario is combining Commercial-Off-The-Shelf (COTS) cards into a working device. Though some software groups consider this a form of hardware design, it is really just integration. The hardware development scenario I am talking about is anything that requires a custom PCB.
Redefine Working Hardware
On of the tried-and-true precepts of Agile development is that each "sprint", or "cycl... (read article)
OK... so the "dummies" part of the title is a little extreme. You really don't need to be a dummy to forget about the basics of one of the simplest of all circuits. The problem is that the concept is too simple. Often enough, an LED circuit is done badly, even though the very same engineer has done a bang-up job on an extremely complicated circuit on the very same board.
I've seen so many goofy LED circuits that have come from so many competent, experienced engineers that I thought it worthy of a little online advice. On this page, you will find some extremely simple designs, with a few caution flags thrown up around some of the more common mistakes.
Your First LED Circuit
Figure 1: A basic LED power indicator
Simple isn't it? It's just voltage applied to the LED, with a resistor to limit the current. No rocket science here. All of the calculations can be done using Ohm's law and a 4-function calculator. If you're go... (read article)
Did you ever run a resize algorithm against an image and wonder "how is that done"?. Do you have a piece of hardware or code that could benefit from a basic resizer? Do you lack the basic knowledge of resizing algorithms that is assumed by most of the "scholarly" papers about resizing? Does matrix math give you a headache? If you answered 'yes' to any of those questions, you are in the right place.
First of all, lets get a few things out of the way:
I tend to use the terms 'resize','rescale' and 'resample' interchangeably. Only one of these is truly correct. Which one is correct depends on who you are talking to at the time. IMHO, resampling is probably most correct because it is more descriptive of what is happening. However, I tend to switch around based on mood.
I'm not going to go into too much detail about the formulas except where necessary. I'll also stick with the extremely simple stuff (like how to calculate a scaled distance) and skip diff... (read article)
Is Agile hardware development a pipe dream or a reality? Well... that really depends on how you view Agile, and how closely you adhere to your chosen methodology. The key to the entire matter is how you interpret the Agile Manifesto. It's a short, masterfully written document that can apply to hardware development with the correct interpretation. It's an unusually short read, so lets take a quick look at it to determine what can translate to hardware development. Because hardware projects can vary dramatically based on application, we'll use a small video player as an example. We'll also use the most popular Agile methodology, SCRUM, to discuss Pros and Cons.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contr... (read article)
A short while ago, I published a post called Six Steps to a Successful Hardware Product. It was intended as a guide to rapid hardware development in a startup environment. However, I couldn't explain the steps without getting long-winded. If you are serious about hardware development, I suggest that you check it out when you have the time. For this post, I'll just hit some of the highlights.
The main thrust of the article is that hardware development need not take longer or cost significantly more than a comparable software product. With new development tools, creative supply chain management, and a little ingenuity, developing a hardware product can be as easy as developing a software product.
The basic steps are: Develop a Concept and Business Case Assemble a Core Team Evaluate Available Technologies Develop an "Alpha" Product Manufacture a "Beta" Product Release to Manufacturing
These steps should be completed in order, but should not follow a ... (read article)
I've often heard it said that successful hardware development is impossible in a startup environment. The usual complaints are "It's too expensive", "It takes too long", and "It's too difficult to manage". I can tell you from experience that none of this is true anymore. With the right team in place, there is no reason why hardware development should take any longer or cost any more than a comparable software project.
There was a time not long ago when hardware did suffer from all of these problems. However, recent advances in technology have helped to lessen, and often eliminate, many of these concerns. ECAD tools have added significant time-saving features like one-click generation of 3D board models, easy incorporation of FPGA code, and comprehensive device simulation. Advances in technology have also dramatically reduced the cost and delays of developing PCBs. Even chip manufacturers have contributed by lowering the power consumption and component count of designs.