Fastest AVR8 Code to Divide 32-bit Register with Rounding?

[Kleinstein]

There is no ablolute need to execute the final calculation between 2 ADC samples. One may have to rearage the code and maybe use interrupts to let the ADC sampling work in the background. This way there is way more time (e.g. 15 ms) for the calculations.

Getting a square root to work in 316 cycles is quite good.

For the division one could likely cut the time a bit by limiting the accuracy - one would hardly need a 24 bit accurate result. Even 16 bits are rare for AC measurements.

[Siwastaja]

Writing cycle-accurate asm and interleaving all code manually between timed events is possible, but extremely time-consuming, and a nightmare to maintain when you want any changes to it. Using a bit more modern CPU core from this millennium would give you not only cheaper parts with better availability, but things like priorized interrupts and enough clock speed to overcome interrupt latency, making firmware development a lot easier. For example, I have a real power + RMS current + power factor measurement (and much more) running on Cortex-M3 @ 64MHz so that ADC DMA finishing triggers one high-priority interrupt (@ 4kHz or so), which processes the samples, and once enough samples are processed after 3-second integration period, said interrupt triggers a lower-priority software interrupt, which has full 3 seconds to do anything it wishes, while the higher priority interrupts keep running in the background. And the rest of the CPU time can be used for doing anything you wish, e.g. UI, either in the main loop (which is still completely free), or other interrupts.

[KerimF]

There is no ablolute need to execute the final calculation between 2 ADC samples. One may have to rearage the code and maybe use interrupts to let the ADC sampling work in the background. This way there is way more time (e.g. 15 ms) for the calculations.

For the division one could likely cut the time a bit by limiting the accuracy - one would hardly need a 24 bit accurate result. Even 16 bits are rare for AC measurements.

I believe that programming is somehow an artistic work because there are many solutions for the same problem. Each of these solutions has its pros and cons and the programmer chooses the one that suits best his situation.
To discuss professionally a certain algorithm written in two different ways, for example, their codes need to be known so that one of them, if not both, could be updated (made better in some respects) if necessary.

[KerimF]

Writing cycle-accurate asm and interleaving all code manually between timed events is possible, but extremely time-consuming, and a nightmare to maintain when you want any changes to it. Using a bit more modern CPU core from this millennium would give you not only cheaper parts with better availability, but things like priorized interrupts and enough clock speed to overcome interrupt latency, making firmware development a lot easier. For example, I have a real power + RMS current + power factor measurement (and much more) running on Cortex-M3 @ 64MHz so that ADC DMA finishing triggers one high-priority interrupt (@ 4kHz or so), which processes the samples, and once enough samples are processed after 3-second integration period, said interrupt triggers a lower-priority software interrupt, which has full 3 seconds to do anything it wishes, while the higher priority interrupts keep running in the background. And the rest of the CPU time can be used for doing anything you wish, e.g. UI, either in the main loop (which is still completely free), or other interrupts.

I agree with you fully. I even add, if you don't, on your side, take advantage of the advanced CPUs and MCUs, as you described, you won't be professional in programming as you are now.
On my side and for many reasons (which are off topic here and I explained some of them earlier) I have to keep working with the old MCU, ATmega8 (actually ATmega8L or ATmega8A) to produce competitive products for the local consumers. But I also understand that, to most engineers around the world, my situation looks weird.

[Siwastaja]

Yeah. The risk is that if ATMega8 is all you have available, what happens when you lose that? It's not a hugely popular chip after all.

[Kleinstein]

Writing cycle-accurate asm and interleaving all code manually between timed events is possible, but extremely time-consuming, and a nightmare to maintain when you want any changes to it.

Yes cycle accurate code is a real pain, but possible in tricky situations. Especially more complex math is an isse as all branches need the same speed.  I have used for the high res ADC one AVR.

For the RMS / power case there is no need for cycle accurate code. Even if interleaving one only need a bound runtime. Interleaving alone is tricky enough  and I would not do that again (did it once with code with a software PLL that had lots of interrupts (~ every 25 cycle).

The RMS / power measurement is however a problem that does not need such measures - just simple interrupts are possible and there should even be enough reserve to allow for other interrupts (e.g. a display or UART).
The mega8 is not that bad. The ADC part of the AVRs has not changed a lot and other AVRs (e.g. mega88) could be used with little change.

[KerimF]

Yeah. The risk is that if ATMega8 is all you have available, what happens when you lose that? It's not a hugely popular chip after all.

I believe that the local retailers (and their main trader) will look for the next economical MCU (which is no more used by most engineers in the world)

This happened many years ago when AT892051 (which was the core of my various controllers, and I had a DOS assembler for it) ceased to be available locally at a low price and in quantities. It was replaced by ATmega8, and fortunately I was able downloading its AVR Studio 6.2 (whose AVR assembler is the last one I had the privilege to download).

In general, in one's life, when a door is closed, another is opened

[Siwastaja]

In general, in one's life, when a door is closed, another is opened

Yeah. It's highly likely the next thing is some cheap Cortex-M0 MCU, or a Chinese clone thereof. But maybe AVR is still relevant for the next 5-10 years.

[KerimF]

In general, in one's life, when a door is closed, another is opened

Yeah. It's highly likely the next thing is some cheap Cortex-M0 MCU, or a Chinese clone thereof. But maybe AVR is still relevant for the next 5-10 years.

I am 73 now. So, I wonder for how long my brain will keep obeying me to design more products

[Siwastaja]

I am 73 now. So, I wonder for how long my brain will keep obeying me to design more products

And you have some skills most young players do not have, but which still are relevant in some special cases. Understanding the mindset of (nearly) cycle-accurate code and use of assembler is less of a requirement today, but there are cases where it's still an absolute must-have.

[KerimF]

I am 73 now. So, I wonder for how long my brain will keep obeying me to design more products

... but there are cases where it's still an absolute must-have.

This applies perhaps for certain NASA projects

Actually, it wasn't my decision to write my codes in assembly.  I just had no alternatives though, in the past and for many years, I used to write various PC programs on DOS (after I bought the BorlandC 3.1 package), even for controlling industrial machines.
When the PC serial and parallel ports were replaced by USB ports, I noticed that I had no more right to download any C compiler that helps me transfer data via the USB port (even simple compilers and their libraries made for kids). So, first, I had to make an in-house protocol to transfer data (though at a very low speed, about 20 Kbit/s) via the in/out sockets of the PC audio card. Fortunately, I found later an open-source project to write and read SEEP memories (24Cxx) via USB which helped me transfer data, in and out of my laptop (13-year-old), in a better way.

[KerimF]

To complete somehow the topic here I attached 'Division, 32-bit register with rounding by 8-bit numbers.asm' as an example, written for ATmega8.

The next one will be for 16-bit divisors.

[KerimF]

I also attached, on post #1, 'Division with rounding, 32-bit register by 16-bit divisors.asm’, written for ATmega8.

[ledtester]

...
But, when the AC current meter has to drive a relay (or triac) to also work as a conventional mechanical breaker, measuring the RMS current in every cycle (preferably in its two halves) will allow a better response of the cutoff delay in function of current.
...

When comparing the RMS value against a threshold you don't have to perform the division or the sqrt. You could precompute N times the square of the threshold and compare the sum of squares against that value.

[KerimF]

...
But, when the AC current meter has to drive a relay (or triac) to also work as a conventional mechanical breaker, measuring the RMS current in every cycle (preferably in its two halves) will allow a better response of the cutoff delay in function of current.
...

When comparing the RMS value against a threshold you don't have to perform the division or the sqrt. You could precompute N times the square of the threshold and compare the sum of squares against that value.

Good remark, thank you.
This is indeed a fast solution if there is one current threshold to take care of.

For instance, I meant by a mechanical breaker the one which is activated when a certain temperature threshold is reached inside of it. In this case its cutoff delay is a function of the heating current (RMS). If this delay is made as a counter, with one top threshold, the 'rate' of increasing it towards this threshold (and decreasing it towards zero) is somehow proportional to the difference between the actual current and the breaker current threshold.

[Siwastaja]

This thermal threshold would still update more rarely than the current value is calculated, and even if you had to calculate it for every cycle, squaring and multiplication by any N is way faster than dividing by any N and taking a square root.

What you really need is to learn to decouple slow and fast operations and while that is possible, even optimal in hand-crafted cycle-accurate single-thread assembler, it is so tedious that one rarely has time to do it especially when your algorithm changes, you get new ideas etc. A little bit more modern microcontroller would simply allow you to run different priority level of interrupts to do different levels of parallelism, e.g. calculate a square root while new samples are being processed, and writing that or modifying something would be quick and trivial in C.

[Nominal Animal]

Just out of interest:

I just had no alternatives though, in the past and for many years, I used to write various PC programs on DOS (after I bought the BorlandC 3.1 package), even for controlling industrial machines.
When the PC serial and parallel ports were replaced by USB ports, I noticed that I had no more right to download any C compiler that helps me transfer data via the USB port (even simple compilers and their libraries made for kids).

Is there a reason you never switched to Linux?  As far as I know, there are no restrictions on providing free/open source software to Syria.

I have used Linux as my only machine for well over a decade now (right now typing this on a 5+-year old HP EliteBook 840 G4 laptop), and prefer it over other OSes exactly because I have full access to free compilers and tools for basically all programming languages to do exactly what I want (I write a lot of code), and even to adapt the operating system and applications to fit my needs and workflow.

Note, although Tux the Linux Penguin is my mascot, I'm not a Linux zealot, pushing Linux on everyone.  I am just genuinely interested in knowing why you never shifted to using Linux, while having needs that remind me of my own.

[KerimF]

This thermal threshold would still update more rarely than the current value is calculated, and even if you had to calculate it for every cycle, squaring and multiplication by any N is way faster than dividing by any N and taking a square root.

What you really need is to learn to decouple slow and fast operations and while that is possible, even optimal in hand-crafted cycle-accurate single-thread assembler, it is so tedious that one rarely has time to do it especially when your algorithm changes, you get new ideas etc. A little bit more modern microcontroller would simply allow you to run different priority level of interrupts to do different levels of parallelism, e.g. calculate a square root while new samples are being processed, and writing that or modifying something would be quick and trivial in C.

I agree with you.
But, since I don't have any more, since about a decade ago, the privilege, as most engineers have, to get, for free or paid, new tools and components (as MCUs), I have to work in my designs with what I have. So, I usually don’t feel the need to think of new solutions while the actual ones work fine, no matter if they are optimum or not. But I used to be ready to think 'out of the box' whenever I face a problem 'firmware or hardware' to solve.

[KerimF]

Just out of interest:

I just had no alternatives though, in the past and for many years, I used to write various PC programs on DOS (after I bought the BorlandC 3.1 package), even for controlling industrial machines.
When the PC serial and parallel ports were replaced by USB ports, I noticed that I had no more right to download any C compiler that helps me transfer data via the USB port (even simple compilers and their libraries made for kids).

Is there a reason you never switched to Linux?  As far as I know, there are no restrictions on providing free/open source software to Syria.

Thank you for your care.
Since about a decade ago, my small private business has been slowed down very fast because... and even after life in the city returned to normal, the slow down continued because... and I ended up using, since then, my old laptop (whose battery is almost dead and works just as a capacitor) which I bought in year 2010.
Fortunately, I can still feed two dogs and three cats