At SDS, we specialize in development and consulting for embedded systems and Internet of Things (IoT) systems. We have worked with many clients on a wide range of projects over the years. We would like to share some of the most common questions (and their answers), so you can benefit from this knowledge as you consider projects revolving around IoT and embedded systems design and development.
Our first series of questions focus on IoT software systems and development. These questions and answers come from two of our team members—engineering manager Sam Fahenstock and software engineer Brandon Everett.
A: Yes! Agile is a mindset focused on customer feedback and value-focused delivery. By focusing on that mindset and combining different Agile practices, hardware projects can be just as agile as software projects.
A: The short answer is no, you should not automate all of your application testing unless the “users” of your application are automation systems. The apps we build often have people as their users in some fashion, so it only makes sense that our applications should be tested by people as well. Automated tests are extremely valuable and should be used to continuously test the application for continued correctness, but should not fully replace manual testing.
A: The goal in building an automated test suite should be the same as building any software application: code reusability and maintainability. For automated tests, this means abstracting your low-level code into reusable pieces called primitives and helpers, which allows your test cases to be simpler and more trustworthy.
A: Throw them away! Yes, that’s correct; get rid of them. The number 1 goal for an automated test is to be trustworthy. If, when a test fails, your delivery team isn’t sure if there is a problem with the test or a problem with the application, then the test isn’t providing you with any value. A good rule of thumb is to set a team timebox for tests that are “flaky.” If you can’t make the test trustworthy within that timebox, then that test should be thrown away. You need to find a different way to test that feature.
A: There is a tool called create-react-app that will bootstrap an entire frontend application for you with all the necessary configurations.
The remainder of the questions in our series dig deeper into embedded systems programming, prototyping, and development, courtesy of SDS electrical engineer, Ben Girt.
A: No. Commercial off-the-shelf (COTS) evaluation boards can often be combined to develop a working prototype.
A: One cost-effective approach to prototyping is to supplement your COTS boards with a custom printed-circuit board (PCB) for your sensor. Another approach is to use breadboards (a construction base) to evaluate your prototype before investing in a custom PCB.
A: PCB fabricators specializing in low-volume orders, such as Osh Park, are a great option for low-cost custom PCB boards. Creating a prototype design using thru-hole components is an easy way to simplify PCB assembly using a soldering iron without the need for surface-mount component assembly equipment.
A: Sometimes evaluation board pin definitions can be reconfigured with firmware changes, such as converting an SPI interface to I2C, for example. A GPIO expander, mux, or interface converter (such as one converting UART to USB), can be included in a design using COTS evaluation boards or added to a custom PCB daughtercard.
A: A COTS evaluation board will have limitations on the power it can supply to external components. The circuit schematic and PCB layout files can be analyzed to determine the maximum amount of power the evaluation board can safely deliver. If enough power is not available, a custom solution can be designed to supplement the power to your sensors from an alternate source.
