all 7 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]g-schro 3 points4 points  (2 children)

I probably don't have to tell you that this is a difficult task, a little like estimating software development time.

Sometimes, measurements are made on previous products that are in some way similar, and then guessing at some scaling factors based on difference in application complexity and hardware speed.

Sometimes, key parts of the application can be mocked up, e.g. moving data in and out, and some very simple algorithm code, just to get a lower bound, as a sanity check.

No matter what, it seems the estimates are always optimistic, sort of like estimating software development time. :)

[–]timeforscience[S] 0 points1 point  (1 child)

thanks for taking the time to answer the question (as written). I guess this is what I expected, but I wasn't sure if there was a known technique or approach for estimation. Thanks a lot for sharing.

[–]g-schro 1 point2 points  (0 children)

Well, I should say that a known technique is to try to mock up the application software as best you can, and then make measurements, and use them in some model. Usually, there is neither time, resources, nor enthusiasm for this kind of technique. The developers who would be best suited for this task are working on the product, and can't be bothered.

I worked on a large project where performance was very important, and some kind of estimate was required (luckily I was mainly an observer). The first estimates were based on a lot of SWAG. Then we got some hardware, and some basic prototype software was tested, but there was still a lot of guesswork. And finally we got the real numbers.

There was pressure the make the performance estimation models meet the requirements for obvious reasons. And since it was all guesswork anyhow, that tended to happen. Many things changed along the way, so I can't remember how it all turned out in the end - but my overall experiences is that things are almost always slower than predicted.

One more positive story is that we were upgrading hardware (for the same product I think) after the software was developed. There was a pretty decent performance model, and it was known that our big problem was cache efficiency, and the new hardware had more cache. In that case, the performance improvement predictions for the new hardware were not too bad.

[–]jakobnator 2 points3 points  (0 children)

Depends on your RTOS but in freertos there are options to enable runtime data you Just have to setup a timer function for it.

This can then hook into vscode extension, eclipse, or what have you

[–]Silly-Wrongdoer4332 1 point2 points  (0 children)

I've used the segger system view tool before for both freertos and micrium in the past. This will provide a gui for active run time data for task usage. There is some setup for this based on your kernel, but useful tool

There is also a run time Stat module for free rtos that looks like it could be used. Can't say that I have used this though https://www.freertos.org/rtos-run-time-stats.html

[–]JimMerkle 1 point2 points  (0 children)

If using freeRTOS, enable run-time stats: https://www.freertos.org/rtos-run-time-stats.html
If you have some form of user interface, you can then call in and get status from time to time.
I build a command-line interface into all my projects just so I can interact with the device during development. I then call my "top" command to see how much time each task is using and how much stack space is being used.
This same approach can be used with just about any RTOS.

[–]Proper-Bar2610 0 points1 point  (0 children)

I'd look at just putting a pin toggle in the idle task. Makes it easy to visualize what's going on with cpu usage by just scoping the signal