What takes most of your time/effort in micro controller based development?

Thread Starter

ahmaza

Joined Jul 10, 2021
8
Estimating time required for a project is not proportional all time to the requirement complexity, some relatively simple projects can take more time than expected.

So where most of time and effort is spent in the development? and how to accurately estimate and optimize development time ?

The thread is not specific to certain micro-controller vendor or tools.
 

BobTPH

Joined Jun 5, 2013
4,051
For me, it would be software development.

But that is okay, because that is what I am best am and like the most.

Bob
 

djsfantasi

Joined Apr 11, 2010
7,925
Design 20%
Coding 5%
Testing 50%
Finalizing* 12.5%
Testing# 12.5%

* “Finalizing” includes removing test code, optimizing blocks where test code modified the structure
# “Testing” repeats test to validate optimization modifications.
 

dcbingaman

Joined Jun 30, 2021
498
I have written two books one on using FPGA's and another on Microcontrollers. 75% of my time is spent writing the book, cleaning it up and getting it ready to publish, the other 25% of the time is spent creating the schematics, wiring up the circuit and coding. For the 25% schematics and circuit wire up probably 1/2 that time and coding 1/2 that time. Working on a third book now. Another good portion of time is getting the code/schematics and documentation organized and available on github for readers of my books.
 

djsfantasi

Joined Apr 11, 2010
7,925
Well, let's take the last project you worked on as an example what makes debugging takes most of the effort?
In my experience, debugging (testing) takes the most time because of several reasons. Here are a couple.

First, debugging tests a lot more code than you wrote. Every possible path through your code must be tested. For example, if your code contains ONE logical condition (one if statement), the number of tests you need automatically doubles. With multiple conditions, the number of tests increases exponentially.

Second, if you find and fix one error, you pretty much have to start over again. Because that fix may have broken something else.

This may be illustrated by the programmer song…

“99 bugs in the code
99 bugs in the code
Fix one of the bugs in the code
127 bugs in the code!”
 
Last edited:

Thread Starter

ahmaza

Joined Jul 10, 2021
8
In my experience, debugging (testing) takes the most time because of several reasons. Here are a couple.
That's cool!!! you put a total of 75% of debug related tasks and 25% coding. that makes me feel good. this is reasonable of course for me also especially if we are talking about debugging embedded firmware

But i think going through different passes of the code can be automated in a way or other. and also you ususally don't have to go through every branch one by one. Don't you think so
 
Last edited:

Thread Starter

ahmaza

Joined Jul 10, 2021
8
Design 20%
Coding 5%
Testing 50%
Finalizing* 12.5%
Testing# 12.5%

* “Finalizing” includes removing test code, optimizing blocks where test code modified the structure
# “Testing” repeats test to validate optimization modifications.
I like the way you sorted out the development process. So how do you think the DEBUG process can be optimized in time and effort for embedded system.
let's think about the most annoying part you think it's during the firmware DEBUG process
 

eetech00

Joined Jun 8, 2013
2,653
Business perspective mostly as project timing is crucial to retain your customers
In project management, then there will be more time planning than anything else. Developers need targets and targets have to be planned before they can be developed and expensed. I know that seems counter intuitive since beta testing is part of development and it can be long. But that has to be planned and expensed as well.

At least that's been my experience..
 

MrSalts

Joined Apr 2, 2020
733
Most of the time is the designers deciding what makes a product look desirable and the product manages deciding what features it should have based in cost, functionality and fitting into the design (form) the designers want. Then cycling back once the first electromechanical design is complete to negotiate form vs functionality (designers don't understand why we can't fit a suitcase-sized component into a thumbnail-sized enclosure).

Other projects that are difficult to predict are new technical challenges. As in, trying to make a distance sensor, motion sensor or accelerometer from extremely low cost/non-traditional components. In the 90s, I consulted for a company that designed and contracted out manufacturing toys for dollar stores. Great experience to push the limits of design concepts and manufacturing cost optimization.
 
Last edited:

djsfantasi

Joined Apr 11, 2010
7,925
That's cool!!! you put a total of 75% of debug related tasks and 25% coding. that makes me feel good. this is reasonable of course for me also especially if we are talking about debugging embedded firmware

But i think going through different passes of the code can be automated in a way or other. and also you ususally don't have to go through every branch one by one. Don't you think so
No, because even a “little” change can cause more problems than it fixes. The corollary is “There are no little changes.”
 

djsfantasi

Joined Apr 11, 2010
7,925
I like the way you sorted out the development process. So how do you think the DEBUG process can be optimized in time and effort for embedded system.
let's think about the most annoying part you think it's during the firmware DEBUG process
The DEBUG process cannot be “optimized”. It is hard, boring work.

BTW, I’ve been a professional software developer for 50 years.
 

dendad

Joined Feb 20, 2016
3,939
It is pretty hard to design a device to be idiot proof.
Some idiots can be pretty creative in ways to break things.
And it can be difficult and take ages to test for all these said ways.
Some ways our industrial control devices have been damaged or destroyed is quite a case in point.
Like, bypassing fuses and then connecting the power reversed, or 240VAC in stead of 24VDC......
So, do what point do you design to. Do you want to prevent damage when 240VAC is applied to a 24VDC device?
 

KeithWalker

Joined Jul 10, 2017
2,046
I was a very successful professional project engineer for Hewlett Packard for many years designing automatic test systems. For any project I have ever done, by far the most time consuming task was research. That included a large number of things that I knew that I didn't know.
I had to make absolutely sure that both the customer and I understood what the customer wanted to achieve by studying his job specification. Sometimes, if he didn't have experience with projects, I had to help him write the specification. That step included studying and understanding the customer's product. I had to find the right test equipment needed to make the required measurements. I had to research how long each of the tests would take, keeping in mind the accuracy required. For some unknowns, I had to do a feasibility study. I had to understand any data interfaces in the product and the test system. For other unknowns I had to consult with specialists to get a written estimate of their time and cost. I had to do a risk analysis to take care of things that I didn't know that I didn't know. I had to decide which was the most suitable language to write the test program in and estimate how long it would take to write and test the code. All of these things were necessary to write a comprehensive quote for the customer.
All of these tasks were pure research and usually took longer to complete than actually implementing the the solution.
Now that I am retired, I design and build fun gadgets using microcontrollers. I find that I still spend most of my time in acquiring what ever knowledge is necessary to make my gadgets do what I want them to do.
 
Last edited:
Top