Get more out of your Rev A hardware

IoT projects and products fail at a spectacularly high rate; not in the field, but by never making it out of the lab. One of the myriad reasons is time to market. When you have a fixed amount of time to make an idea work and deliver that product to the marketplace, you don’t get a lot of retries. That’s why I gave this talk about how to get the most out of your “Rev A” (first revision of) hardware. It was delivered as one of the free talks from the Embedded Online Conference (EOC) in 2023. You can view this and many other highly specialized talks on the EOC site. Registration is required for viewing the other free talks and there is a nominal fee to join the site and view the talks from this year and last year.

Balancing Act

Why not “move fast and break things”? Why bother caring about Rev A? Despite reduced costs around hardware thanks to quick turn manufacturing services domestic and abroad, it’s possible to get hardware fast…but there is still a delay between a Rev A and Rev B board. What’s more, the decisions you make in your early hardware prototypes can carry with you throughout the life of a product, and it makes sense to shoot for a best-case scenario when planning and executing your first spin of a prototype. This talk covered three areas of the prototype process.

Before Rev A

The “before” is all about planning, especially across different teams. Hardware designers for IoT products need to make sure they communicate properly with their firmware and cloud teams, in order to maintain good expectations. A written plan about what you’re hoping to get out of the Rev A prototype and how to maximize the testing of that prototype will ensure you don’t waste or duplicate efforts later. Design reviews are a crucial component to allow different teams to voice their needs before manufacturing.

During Rev A

Once your prototype is planned, designed, and manufactured, you need to execute on your testing plan. Your testing methods will help you to understand when a prototype has met or missed goals set during planning. This part of the talk also reviews some testing tools that can help teams get more data from their prototype device.

After Rev A

Once you have thoroughly tested your Rev A prototype, a post-mortem of what went wrong (and right) is crucial. It will ensure you improve your process (for future Rev A prototypes) and also capture all of the needed changes for a Rev B prototype.

Case Study

Golioth does not build and sell finished hardware products.  But we do regularly create “Rev A” hardware when we create different Reference Designs. These are built to help accelerate teams looking to build an end product but wouldn’t mind benefiting from someone else showing how to build the first spin of a design. Our Reference Designs are built on top of a prototyping platform we created that attempts to balance flexibility, a quasi-finished look, and a relatively compact design. None of these categories are super optimized, as that is left up to the user hoping to build a finished product.

We’re always looking for new Reference Designs to build to help accelerate engineers’ Rev A prototypes. If you have any requests or need help building out your prototype, let us know on our forum or drop us a note.

Conference Talk Slides

 

 

 

Chris Gammell
Chris Gammell
Chris is the Head of Developer Relations and Hardware at Golioth. Focusing on hardware and developer relations at that software company means that he is trying to be in the shoes of a hardware or firmware developer using Golioth every day. He does that by building hardware and reference designs that Golioth customers can use to bootstrap their own designs.

Post Comments

No comments yet! Start the discussion at forum.golioth.io

More from this author

Related posts

spot_img

Latest posts

The Miserable State of Modems and Mobile Network Operators

This is a story of the complexities of cellular connectivity, the perils of closed ecosystems, and how to debug what you cannot see.

Useful Zephyr Shells for IoT Development

The Zephyr shell subsystem will help you directly interact with and troubleshoot your IoT hardware. This post details our most commonly used commands, as well as a listing of all Zephyr shell modules that we could extract from a recent project.

Guide to Securely Store Credentials on an nRF91 Modem

The Nordic nRF91 modems include secure storage for TLS credentials. This may be used to authenticate with Golioth. The assets are stored separately from the firmware, and once written, they cannot be read back from the device. This guide shows the process of storing and using credentials.

Want to stay up to date with the latest news?

Subscribe to our newsletter and get updates every 2 weeks. Follow the latest blogs and industry trends.