Embedded development – what is this?
If, when creating a new device, there are smart elements in the circuits that are capable of calculating and processing commands, they need embedded systems to work. You don’t have to look far for examples of embedded systems – these are smart elements, small coprocessors or microcontrollers designed for complex devices. You can find them in routers, electronic watches, or smart coffee machines. They perform a preprogrammed task that is not complex enough to create a separate device, but necessary for the device to work. Therefore, when a smart node appears in the design and creation of a device circuit, it needs to be trained and programmed to perform a specific task.
How does this happen?
We generate concepts, select the iron part
The prototype of the device is already in the drawings, its main provisions and functionality are thought out. The only thing left to do is to determine how it will process information, what exactly to interact with and by what algorithm.
The development process begins by generating concepts applicable to the work equipment, fitting them to the existing project budget, and calculating the basic interactions between the device and its environment. Should the microcircuit transfer data to the cloud service? Will it be required to launch applications other than the standard ones? Do you intend to interact with external operating systems via the web interface? All these questions will help determine what hardware will be used and how it will affect the budget.
Table with approximate indicators of various embedded systems
The next stage of embedded development for electronic devices begins when the development team draws up a document with hardware specifications, its features and selects a platform for software implementation. This can be an Arduino, Raspberry Pi, microprocessor, coprocessor, or other programmable element with logic circuits. The choice depends on the task at hand.
For example, a coffee maker that brews one type of coffee can also work with a microcontroller on board, which implements commands according to the principle of logic gates – the button is pressed, the water is warmed up, the coffee is poured.
But for a smarter coffee maker that can make latte macchiato or cappuccino, you need a more sophisticated mechanism, like an Arduino. In such conditions, it is necessary to accurately determine the functionality of the device in order to start from it when choosing the technical part of the project.
* Examples are given for illustrative clarity, embedded development concerns not only household utensils, but also complex infrastructure of servers, mainframes. All of the above will be true for the development of programs for microprocessors.
Cutting off non-viable concepts
At this stage of firmware development, there is a cut-off of those concepts that, for a number of reasons, cannot be implemented: there is not enough budget, drivers are not supported, the development of additional drivers will take too much time, etc. The most viable Spartan is selected, who will carry the entire project on his shoulders. And the very check of the concepts for viability is carried out empirically “will take off or not take off”, when, based on previous experience, one can say about the potential functionality and pitfalls of the device.
The fittest concept must survive
An alternative to this option is testing by the “blind run” method, when the iron part is chosen based on goals other than the optimal implementation of the product itself. The lack of the method is dire, without the lack of preliminary research, there is a high risk of running into a pothole in the development, which can sink the project. Electronics and software development go hand in hand, side by side. The thing is that to implement design tasks, you may need to create a separate node or element. Usually, work goes with already existing and ready-made parts, however, in an individual case, a decision can be made to create fundamentally new systems.
And there was a word, and a word was a Code
When the objectives and constraints of an embedded development project are clear, like the sky in summer, the lengthy process of coding for microprocessors begins. The first concepts become strings of logical operators, variables and modules. Of course, if it is supported by the device.
For example, a PC’s processor runs on microcodes that are part of its architecture, and it executes the given code. However, it has limitations on the types of commands that the operating system cannot run.
The first prototypes are needed to prove the work of the concepts themselves, after which the testing stage begins.
When the final one was selected from all the concepts, they begin to translate it into reality. Firmware development goes block by block, line by line, after which each concept prototype is tested on the selected hardware.
The first prototypes have only one task to do – to prove that the concept is working.
This is where those pitfalls emerge that, due to circumstances, could not be taken into account. Testing of prototypes is carried out by the method “Will it run if we change here or not?”, Thanks to which it turns out to identify the main weaknesses of the existing code.
By the way, we have material about hardware development: you can read it here.
Each prototype is launched in an environment that is as close to real life as possible, but not on the device itself. If the device operates on microcodes, a test bench is assembled, where they are checked for operability.
When the device supports operation in one of the programming languages, the code is checked on the workstation in debug mode. This allows you to detect subtle weaknesses and bugs in hundreds of lines of code before launching into production.
We create a case, solder it, implement it into the infrastructure
In parallel with programming and software development, the work of designers and engineers is in full swing. A built-in device needs an iron part, sometimes a case. This is done when there are existing concepts on hand, the tasks of the device are known. After successful development of concepts, testing and development of drivers, the stage of assembly begins. At this stage, the developed firmware is ported to the hardware and ready to go.
But not really. Each embedded device must interact in a pre-existing environment, which requires further implementation and integration. These are accompanying stages, individual for each project. They can be finished in two days, or they can take months. In any case, further observation is needed. You cannot foresee everything, but a lot can be avoided.