The world of Open Source software is built on collaboration. In one corner of the world, someone can fix a bug in a piece of software, and push it up to the gits. In another part of the world, someone else can put that fix into the next release, and soon everyone has newer, better software. The Internet, or the ability to rapidly transmit text and binary files, has made this all possible.
Hardware is another story. There’s a financial barrier to entry. Not only do you need a meter and a good iron, you’re probably going to need oscilloscopes, logic analyzers, and a bunch of other expensive tools. You’ll need to buy your BOM. If you’re using a PIC, it might be a good idea to buy the good compiler. Hardware is hard and expensive, and all those software devs who complain don’t know what they’re talking about. Collaborating on hardware is much more difficult than pushing some code up to the cloud.
For this week’s Hack Chat, we’re going to be talking about collaborating on hardware projects. This is a deep dive on how to make collaboration with physical objects work, and this week we’re going to be learning from some of the best.
Our guests for this week’s Hack Chat are Pete Dokter and Toni Klopfenstein of SparkFun Electronics. Pete is formerly the Director of Engineering at SparkFun and now the Brand Ambassador for SparkFun Electronics. He hosts the According to Pete video series expounding on various engineering principles and seriously needs a silverburst Les Paul and a Sunn Model T. Toni is currently the product development manager at SparkFun. She’s served on the Open Source Hardware Association Board and participates in the Open Hardware Summit yearly. In her free time, she spends fifty weeks out of the year finding dust in her art and electronics projects.
During this chat, we’re going to be discussing what makes a collaborative hardware project, how to make distributed development work for your team, and the limits of what you can do with several hardware engineers separated by thousands of miles. This is a hard problem, much harder than a distributed team of software engineers, and a fantastic discussion for all.
Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. This Hack Chat is going down Friday, February 9th at noon, Pacific time. Time Zones got you down? Here’s a handy countdown timer!
Click that speech bubble to the left, and you’ll be taken directly to the Hack Chat group on Hackaday.io.
You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.
boo paying for compilers, boo
At the masters conference a Microchip rep said it best:
“If you have to use one of our paid compiler options, your code is a mess or you’re flying too close to the sun.”
..the last part being in reference to selecting a part with the smallest code space to shave a penny.
Like most of their customers, I use 8 bit PICs with assembly when I need a cheap reliable part that I know I can find stock of in ten years with supported software environments. If it’s too complex for that or they need it now at any cost, I move up to 32bit ARM and C.
+1
Collaborating at what level? HDL? Actual gates? The brainstorming level?
A viable process would be great, but the existing problems with software collaboration haven’t been worked out yet, maybe that should be worked out first? Some of my projects get huge, and it’s so easy to overlook things, or simply not have some vital knowledge that would be very helpful! Good luck to everyone working on this, I hope it (eventually) works out!
For several years, have seen an increasing number of software people that wanna do hardware, mostly because I get stuck with the technical interviews. The only CS-educated candidate we ever considered was a person that did avionics in the military prior to their degree (they accepted offer from another, very large, company). The better candidates tend to be EE-educated. Not to say all CS people have no business doing basic circuit design, just that their learning curve and professional experience does not count much towards the industrial embedded control systems.
You wanna hardware if you only have code experience and education? Work at a large company where it can be easier to weasel your way into an engineering lab. Gotta know both at mid-sized and small companies. You wanna just code after some years of hardware and ‘only’ an EE education? Just do it…