Before we begin my friend, with some obvious definitions, let’s start from the other approach.
Developing embed is like climbing a high mountain without trails. You see the summit that is your goal and you have to climb it with your partner, the hardware. Together you must make the way upwards. In well organized teams both partners help each other not because there is some obligation but because the cooperation gives more than hostility. On the way upwards, to obtain a perfect product, hardware is the one that’s slightly less flexible. It’s hardly modified and makes basis for software. Remember, that without hardware, peripherals software cannot communicate with the outside world. Before starting, a predicted way to the top is pointed out as well as some stop points. For climbers that would be camps, for products that would be milestones. There is much more in common with hiking and developing products. There are unexpected problems like avalanches or hardware faults. Sometimes our estimated way is insufficient or unable to obtain, so there must be found a new one. I’d like to take you, my friend, on this journey with me. I will show you all my tracks and tricks on the way to obtain a perfect product. Ready? If yes, let’s start!
First, we must make some research where to go. Usually there is a meeting handled with a client where a main goal is discussed.
So how to get to a camp?
After that meeting, there should be carried another one, but now the team involved in developing that product should also be present. It’s an internal meeting with a hardware engineer and at least one embedded software developer. Usually a mobile software developer is also there. On this meeting, the way to the top is discussed. Where to start and how. This is where engineering part begins. We take a map and plan our way. We point the most risky parts of development. Also, we set some milestones usually connected with functionalities and test steps. First stop will be our base and it’s usually the first prototype.
Usually, creating the first electronic version of a product takes few weeks. So does it mean that embedded developers have nothing to do? Wrong! There are evaluation boards with microprocessors. If you have the right one you can start building your software. That boards have connectors to which peripherals can be connected just like in the finished device, so you can start writing your code. It’s like trekking to the first base. You get out from a plane or a bus and then you see...your mountain! So you see your mountain but it’s an inaccessible region. You must take your backpack and ramble to a place where you’ve started your journey. This is the moment when you can learn your microcontroller. Every manufacturer has its own product and support policy. Especially in a low level, so if it’s a new processor, the work must be done from the beginning.
You have already written some code. Maybe you have set some peripheral drivers and the main loop outline when the first prototype arrives. It’s like setting a camp. You know, you have found the valley at the map and you seek for a good place but there is no such thing around? I known that from the embedded point of view. Useful things are patient and oscilloscope. Remember not to give up and check if a microcontroller do what we desire. Nothing can be left for later because there may be lack of water or because peripheral cannot work in the way we want it to work. This part must be done in the coordination with a hardware designer. If any hardware faults are spotted, they must be replaced in the second iteration.
We reached first base, what’s next?
Attack the summit? No, not yet. Now it’s a moment to explore the slope. Making progresses, testing abilities, writing drivers and the main program. We have all the components and starting from now, we have to make it work perfectly. Functionalities are being laboriously added. It’s like rigging and making camps on our way upward. No one can make this way fast, every step and every rig must be added carefully. If you want the program to work efficiently, it must be well organized. Similar situation is with the trail that must be set reasonably. In other way, it would be dangerous or the program will hang. Continuous tests are extremely useful.
Then you write software tests that continuously check if software has any bugs. They may be prepared by the main product developer but also they should be examine by a software engineer outside the project. They should start from the first day of developing.
The test shows lack of bugs and our software is ready..
Is it the end of our journey? No, it’s not! Now is the moment for testers that will use your device and tell you if there’s something to change or which parts are not intuitive. If a tester is not technical, the result will be better.
It's the moment of a summit attack! You are almost there! You’re tired, but you still strive for success. You go back to find that one line that make your code not optimized. It’s the longest part and it can be parallel to clearing stones. When it’s finished, the first release ends. It’s like achieving the goal, standing at the summit. Your work is finished. You made it.
After all you have done, you have to come down from the summit. How to do it? Usually in the easiest way. For developer, it means providing support after releasing the product: fixing bugs or adding new features. Nevertheless it’s a different story. Maybe next time I will bring it up. Here the research and development ends. Thanks for walking this way with me!
Goodbye my dear friend!