Home > On-Demand Archives > Theatre Talks >

Improve your Embedded IoT Hardware Today

Chris Gammell - Golioth - Watch Now - EOC 2023 - Duration: 40:07

Improve your Embedded IoT Hardware Today
Chris Gammell

We all want to build hardware that is bulletproof on the first rev. I can't promise you that, but I know how to add in hooks and capabilities that make troubleshooting, upgrading, and measuring deficiencies much easier. Your second rev will be leaps and bounds ahead of your first, and you can get to market faster.

This talk will showcase components, tools, and troubleshooting methods that enable better hardware, regardless of the parts you choose or the form factor you need to fit into. This talk will also feature some recently created hardware that focused on modularity and flexbility, as it was not targeted at a production environment; this could form the basis of a good “rev a” build of hardware and help engineers to focus on validating new product ideas before digging into more complex layouts and smaller form factors.

italicssurround text with
boldsurround text with
**two asterisks**
or just a bare URL
surround text with
strikethroughsurround text with
~~two tilde characters~~
prefix with

Score: 0 | 3 months ago | no reply

I echo Steve's comment below. Even getting the HW engineer's to preserve unconnected I/Os to test points was difficult. These are invaluable in synthesizing HW outputs to match internal FW states (e.g., interrupt handler entry and exit). LEDs are really useful in showing state and activity as well.

Score: 0 | 1 year ago | no reply

I enjoyed the talk. I'm retired now, but my company used to do several of these things. We had several processor boards, and a line of peripheral boards that used common interfaces. We'd try to sell customers on using our stock products to prototype what they wanted, with the option of getting a custom design once things were working if their production run would be big enough to justify it. It didn't always work; sometimes, they wanted the custom board from the start.

My big problem, as a firmware engineer, was getting the hardware engineer to put test points and accessible I/O on the board for my testing. He had the habit of designing optimized, cost-reduced hardware from the get-go. Unless there was a significant problem discovered, rev A was the final hardware.

Score: 1 | 1 year ago | no reply

Great Talk. You have given a bunch of things to go research more.

Score: 1 | 1 year ago | no reply

Thanks Chris, enjoyed your talk, love your podcast. Hope to see more of you in future conferences.