Nearly everywhere you look nowadays, you can find sneaky undercover computers. We know they’re in our phones and smartwatches, sure, but what about your electric kettle, washing machine, or car? Devices are getting smarter all the time thanks to embedded software – code written for microcontrollers that are embedded in devices rather than for a personal computer or phone.
At Treetown Tech, we work on products ranging from large delivery trucks to wearable medical devices, developing bespoke electronics and the software that runs them.
In the latest installment of our Prototyping Toolbox Series, we’re thrilled to give you an inside look at how, exactly, we develop embedded software.
Phase 1: Ideation
Like everything at Treetown Tech, the process starts with a conversation and collaboration with our clients. We want to learn what problem is trying to be solved; we have a series of questions and use cases we work through to help identify and define requirements to best understand how an embedded solution can fit into the product development lifecycle.
Maybe a client wants us to create a product from scratch. Or they may have some parts (like a board or chip) pre-selected and want us to build a device around those parts. Sometimes clients come to us with an existing product in need of changes. Or there may not be a product at all; some undertakings are strictly exploratory.
In the consulting phase, all the chips get laid on the table (pun intended!), so we’re on the same page with our clients.
Phase 2: Development
The development phase starts with architecture, not the kind that designs a house, but similar in that we need to figure out the strategy of how all the big pieces go together and why. Sometimes this work involves co-developing the hardware the software runs on, and other times just the software to run existing hardware. This stage uses many tools but rarely starts with jumping in and writing code. We’ll start thinking wholistically about the complete solution on things like how we get inputs from the outside world, what other systems we need to communicate with, do we have any power constraints such as making a battery last as long as possible. The tools we use in the architecture stage vary by project, but they typically involve state machine diagram creation, design documents, and technology selection.
After the architecture, we dive into development. Though we love thinking outside the box, it’s not all fun and games—lately, development has largely depended on the availability of parts. However, we intentionally design our code to be modular or portable, meaning it can be transferred easily to another processor or project. That means if a certain chip becomes unavailable, we can change the software to work on one that is. This is typically achieved via a hardware abstraction layer of software that separates the main application code from the nitty-gritty of how a specific microcontroller works.
Most embedded software is developed for very specialized hardware, and, commonly, the hardware is being developed simultaneously as the software. In this case, we like to use development PCBs with the same microcontroller as the future hardware. While the development board won’t have all the same features and functions as the bespoke hardware, it does give us a good jumping-off point to start developing and learning. This can be especially helpful if the software development can inform the hardware development, as it is a lot more cost-effective to start testing on a development board than a custom PCB.
While we work through implementation, we regularly check back and ensure that the outcome will match the original requirements that were developed. We do this by breaking down the work into blocks of functionality; this also allows us to leverage different team members based on their individual strengths to provide the best possible outcome for our clients.
Throughout development, testing the software and ensuring it’s functioning properly is critical. We set up manual and automated testing to learn more about how the system works, which involves a lot of cooperation from our electrical and mechanical engineer colleagues.
We can even run tests without a product being fully assembled using circuit boards with probe points. This test is aptly named the “bed of nails,” because that’s exactly what it looks like!
Phase 3: Deployment
Once a product is developed, it can be deployed. So, we’re off to factory assembly, which includes provisioning serial numbers and end-of-line testing.
Different methods of “field programming” then keep software products up to date once they are deployed. Depending on factors like cost, security, and connectivity, clients might choose internet-based updates or physically send in technicians with update tools. Some projects can even require the setup and maintenance of internet infrastructure to facilitate telemetry or logging behavior.
Although these operations occur in the last phase, decisions about deployment and field programming updates merit early consideration and planning.
Creating complex and capable electronics
We pride ourselves on the ambitious variety of projects we work on at Treetown Tech. Sure, we like to have fun creating simple doodads (like a Pomodoro desk pet), but we really light up when challenged to develop complex projects for our clients.
Ready to consult on your next project? Reach out to us today!