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

[KerimF]

I used to write my codes (for CPUs then MCUs) in assembly language only. Lately, I ended up working with ATmega8.
For RMS current/voltage meters, I had to divide 32-bit register, with rounding, by a limited set of numbers, for example, from N=320 to 447.
I wrote a subroutine which executes this division in 132 cycles (+ 7 cycles for ACALL and RET).
Do you think it is not fast enough?
Thank you.
Kerim

Added:
You may like viewing post #36 for 8-bit divisors.

[brucehoult]

Only you can say what is fast enough for your application.

Since the ATmega8 has 8x8->16 single-cycle multiply, you can do a 32x32-> 64 multiply with 16 multiplies plus a similar number of 16 bit adds i.e. about 48 cycles.

If you only have 128 different numbers to divide by then you could store the multiply and shift constants in 640 bytes of flash (<8% of it).

If you are dividing by the same number many times in a row then you could calculate that divisor's multiply and shift factors just once, using about the same amount of time as a divide, and then reuse it. Then you don't need a table in flash.

[Kleinstein]

The normal RMS calculation does not need many deivisions, so I don't think the division would be that relevent. The more relevant part is more the square root and the multiplications during sampling.
So the division routine should already be fast enough if used right. It may be a bit more of an issue if used as part of the square root routine.
I somewhat doubt that the result would have 32 bit relevant bits - usually its's rarely more than 16 bits that are really relevant. In ASM one is free to use 24 bit numbers.

The 8x8 multiplication on the Mega8 is 2 cycles ( AFAIK the Xmega and chinese clone offer 1 cycle).

[Siwastaja]

Instead of micro-optimization of expensive operations, question your algorithm design - why does it use those expensive operations? I have implemented real power metering, RMS current calculation etc. countless of times and never used division. Why would you?

Such things boil down to pre-calculating a single multiplier which is a product of calibration factor, unit conversions, ADC ranges, number of averaged samples etc. baked into one number, and then shifting the result; for AVR, that would be shift by a multiple of 8 (i.e., usually division by 256 or 65536). Like, you need *1.234? Multiply by 80871 and shift by 16, and you get *1.2339935, or 0.00053% error.

Unless it's a very high resolution instrument, usually both intermediate and final results fit into 32 bits but sometimes you might want to use 64 bits either for intermediate result for high-resolution high-accuracy stuff, or for the accumulator which accumulates squared values, maybe for tens of thousands of samples, so that you simply cannot pre-shift before accumulation or the accuracy would suffer too much.

You should consider worst-case ranges in Excel/etc., often you find a decent compromise between accuracy (rounding error) and performance. For example, if your voltage reference is repeatable to 0.5%, why would a rounding error of 0.05% be a problem?

If you want to micro-optimize, the best opportunity I think is to come up with arbitrary n*8 bit routines and types (e.g., 24- and 40-bit operations). Also for workloads where a single periodical ISR does all the heavy lifting and performance of the rest is irrelevant, you may want to instruct the compiler to use registers for some static variables and prevent the same registers from being used elsewhere.

Or, just switch to 32-bit architecture like sane people do when they run out of computational performance of 8-bit AVRs. Remember, there 32 bits come "for free", and 64 bits is similar pain level to using a 16-bit variable on an AVR!

[KerimF]

Thank you, Siwastaja, Kleinstein and brucehoult, for your interesting practical ideas.

For instance, I have to use ATmega8 in my products to minimize their cost and let them be competitive in the local market.

In designing AC meters, I usually use the time-division topology.
The period of the main loop is fixed. It is the ADC reading time in the free running mode (13 ADC cycles).

When the ADC interrupt flag is set (the starting point of the main loop), a start common code is executed which ends by IJMP; a jump to the address in ZH:ZL which is incremented continuously and reset when the external interrupt flag is set (that signals the end of the main’s cycle).
After IJMP, one or more functions could be executed and end with an AJMP; to jump to the end common code before returning back at the start of the main loop.

If the MCU crystal is 8 MHz and the ADC prescaler is 64, the ADC reading time is 832 cycles (64*13) and 104 us (1/8*832). In this case, The IJMP list (of RJMPs) should be longer than for one main's cycle (for simplicity, I usually make it 256 long for which the lowest frequency is about 38 Hz). In case of 50Hz, the number of samples is close to 192 (20ms/104us). Also, to simplify the sensor circuit, I pass just the half cycle (current or voltage). The worst case is when the signal peak at the ADC input equals the ADC reference when the reading is 1023 (10-bit ADC). By using Excel, the sum of the ADC readings of the half cycle could be found to be close to 52326448 (0x031E7030). And, in case I read, during this half cycle, both the voltage and current, this sum becomes 26163224 (0x018F3818) which, as we see, has to be saved in 4 bytes (a 32-bit register). Obviously, this number increases when the frequency decreases.

By the way, in this case, the divisor could be expected, speaking practically, to be any number between 174 (about 55 Hz) and 214 (about 45 Hz).

But on my 1st post, I assumed that the divisor could be between 320 and 447. Actually, this was for the case when the ADC prescaler is 128 (416 cycles, 52us). Also, it was for the highest frequency 60 Hz (1/320/52us) and the lowest one 43 Hz (1/447/52us). The AJMP's list (for IJMP) had to be doubled.

I mean; I made a mistyping on my 1st post because 132 cycles (+ 7 cycles for ACALL and RET) is for the case of ADC timing of 104us. I had to write 145 cycles instead, which are for the case of 52us.

Naturally, in both cases, the division is faster if rounding is not important; 99 and 103 cycles respectively.

[Kleinstein]

The RMS or power calculation has usually 2 parts: one is summing up things like ADC values or ADC values squared. This is done for each ADC sample (or possibly pairs if voltage and current are read for power). This part does not need a division, just sums and multiply.
The second part is done after a number of peroids, so hat most event 16 to 20 ms depending on the mains frequency. In most cases the mains frequency is reasonable fixed and known.
With using interrupts for the sampling and sum part the per block calculation is no longer time critical  as one usually has plenty of time, like 3/4 the CPU power for more than 10 ms. This part includes a division (maybe even a few of these) and for RMS voltage also a square root. This square root is typically way slower than a division. One way is to use an iterative method that includes a division and may need some 3 to 6 iterations after a crude inital start.

The mains frequency is usually relatively fixed and thus a factor for 1/N can be calculated upfront.


I would not consider using only half waves a good idea, as this gets sensitive to DC offsets and some electronic loads may not be symmetric. It is likely better to an offset and sample the whole waveform, even if this means loosing 1 bit for the sign. The exact DC offset can be corrected in the calculations, even to better than 1 LSB resolution. A nice point of the digital RMS part is that one can avoid DC offset errors and thus work resonably well even with small amplitudes.

[KerimF]

The mains frequency is usually relatively fixed and thus a factor for 1/N can be calculated upfront.

This reminds me when I was at Nantes (a city, West of France, by the Atlantic) for 2 months (about 50 years ago, summertime) as an undergraduate trainee at the offices of 'Electricite De France'. I visited a big hall, full of big panels, screens and equipment, in which many engineers were supervising and controlling the electrical power network of the Nantes' region. The French engineer who was in charge of my visit, asked me: "Don't you know what the main purpose is of all what you see here?"... He continued: "it is simply to keep the network frequency very close to 50 Hz" (I forgot what he told me about the acceptable tolerance which was very narrow).

But where I live (mainly after year 2012) and in case the mains power is on (lately we got it 6h/24h, at best), the frequency could be between 48 and 52 Hz typically. And the mains voltage could be as low as 150V (if not lower) and as high as 250V (if not much higher during a fault).
I mean most solutions I have to think of (to gain my daily bread and of my assistances), while designing products for the local consumers, may be seen somehow exaggerated to most engineers in the world.
Most of the time, I have to think out of the box. But I agree with Nikola Tesla when he said: "I do not think there is any thrill that can go through the human heart like that felt by the inventor as he sees some creation of the brain unfolding to success... Such emotions make a man forget food, sleep, friends, love, everything"

[brucehoult]

For instance, I have to use ATmega8 in my products to minimize their cost and let them be competitive in the local market.

If the equipment is already designed and made then fine, but  think you'll find that 32 bit microcontrollers are available for less money than the ATMega8. I guess there are probably certification issues though.

[T3sl4co1l]

So, native, internal, the crappy 10-bit ADC? Even with subtractive dithering, I don't see that having useful performance for measuring mains power.  It'll have a deadband of, what, several watts?  Tens of watts, if designed to read high crest factors.

Not only are 32-bit MCUs available, but those with 16-bit ADCs included as well.  Not that they have nearly so many ENOB, but the resolution at least is vastly improved, and there may be enough noise to get useful dithering.  The sample rates are also vastly improved.

Whether such are accessible in any particular part of the world, I don't know.

On the upside, the square of a 10-bit value is at most 20 bits, so accumulating 24 bits is very close to practical.  It would overflow sometimes (MAXVAL^2 * 16 samples), but that might either be detected and flagged (saturating arithmetic), or rescaled in a clever way (say, accumulate ~15 samples at a time, then decimate and shift).  Otherwise, 32-bit arithmetic isn't a deal-breaker, it's just 32-bit accumulation after all.  (Probably the decimation would cost about as many cycles overall?  It would actually cost more memory on account of having to keep both fast and slow accumulators around.)

The expected ENOB gain of ~300 samples accumulated is about 5, so a 16-bit result will certainly suffice after the root.  Basically taking the integral part of the sqrt, though because of nature of the signals, it may need a couple shifts (you can begin introducing your gain factors here, if you like).  Which can be done (or in part) before the sqrt, because there's a ton of headroom in the 32-bit accumulator.

And then subsequent manipulation of the 16-bit values is simple enough.

Tim

[Kleinstein]

Many 32 bit µCs come at least with a 12 Bit ADC, 16 bits is rare and more like a premium part. The usually higher sampling rate can help a little, but the actual noise of the ADC may be more limiting. The 10 Bit ADC in the AVRs is relatively low noise.
The calculations during accumulation are not that critical - no division there. For many applications one does not need a new result every mains cycle and can accumulate over more cycles (e.g. 0.5 seconds) and still get a reasonable reading rate. The eye / brain can not really use a much faster rate.

Due to the oversampling the resolution is actually not that bad, even with only 10 bits. No need for a dead band - it is mainly noise and averaging can work quite well. For a power or current measurement one may still have to switch ranges / gain to get a larger dynamic range. It still won't meet the standards for a commercial meter used for ther power bill.  If that level of accuracy is needed, there are special metering chips that include better (e.g. 16-24 bit) ADCs and do most of the math. Due to the large numbers they are surprisingly cheap.

[KerimF]

For instance, I have to use ATmega8 in my products to minimize their cost and let them be competitive in the local market.

If the equipment is already designed and made then fine, but  think you'll find that 32 bit microcontrollers are available for less money than the ATMega8. I guess there are probably certification issues though.

The last assembler I had the privilege to download and run is of the AVR Studio 6.2. Since many years I have no more the privilege (due to world's regulations that most engineers in the world are not aware of) to download advanced tools as compilers (for PC or else), assemblers, simulators, CAD of any sort... etc. And the big companies/corporations have to also close their doors (with apology) when I contact their sites to obey these rules.

So, I am fortunate for still having a C compiler for DOS (of the BorlandC 3.1 package, I bought 40 years ago), DOS assembler for the C51 MCU family, the assembler of the AVR studio 6.2 and very old versions of Kicad, LTspice and Excel.

But I also have no reason to complain because this is life since always... a free horse doesn't expect having any of the privileges of those who live in farms. This is why I said I am fortunate even for the little I have. Anyway, I am an old man who, sooner or later, will leave the world and its regulations for good  

[T3sl4co1l]

Not that assemblers need to be very up-to-date, but you may wish to investigate GNU assembler syntax.  GCC processes asm in *.S files seamlessly with C files in a project, and symbols are available globally (if so specified) and linkable.  You do need to make sure of the ABI (size and order of parameters, what registers they will be placed in) to interface with C, this isn't handled for you (at least, I don't think so?).

Advanced (inline) asm syntax may also be of interest.  Most things, GCC doesn't generate very optimal AVR instructions, but by writing the instructions yourself, you can still let it choose which registers to allocate for the statements.  This is handy when you have short functions that should be inlined without the expense of shuffling registers around.

I recall the main quirk with AVR Studio was, you do an ASM project, and, that's the entire freaking project, no C, no libraries (well, maybe asm ones, but not libc).  No interfacing, at least, I don't recall there was an easy way to mix them.  Probably because it used their assembler, which is different from GCC (which is what AVR Studio uses).  So, you may find it worthwhile adjusting for the GAS syntax and keywords/directives, and mixing them.

Tim

[Kleinstein]

There are ways to mix ASM and C code with GCC and thus also works for the AVRs. There are 2 ways to do it: for small ASM parts there is inline ASM. For larger ASM there is the option to use the assember to create an object file like the compiler does for C code. The code can than be included in a C (or other supported languish) with an header filer to define the interface. So the ASM part would provide some functions than can than be used with compiled code. AFAIR the assembling is done via GCC, not the Atmel provided AVR assember and the project is a C type project.

It is quite some time I tried this, actually for calculating RMS reading. While the ASM code was quite a bit faster, the C code did turn out to be still well fast enough even with the µC running on a relatively slow clock. For many parts GCC is quite good in the optimization, but not so much when mixing different variable types.

[T3sl4co1l]

I already forget what I last used advanced asm for, but my first mixed project is here,
https://github.com/T3sl4co1l/Reverb

I created these by taking asm dumps of the pure-C functions, then optimizing them by hand.  This method is interesting as it's somewhat self-documenting, in terms of the ASM being also implemented in (perhaps) more readable C.

The difference of course being, as the functions evolve separately after conversion, you can end up with the same kind of discrepancy as between stale comments and code.  Also, and perhaps less important (but depending on how severe the optimizations are), the exact semantics may change; which may include optimizations that cannot be expressed in C at all, but which are still suitable for the overall purpose.

When functions are kept in sync, one can also swap them out and do immediate inline testing for size and performance.  A good plan to keep optimizations honest.  (Not that it's hard to find substantial improvements in DSP code on avr-gcc, but for other applications and platforms, it can be much less straightforward, and measurements can be valuable.)

Tim

[Siwastaja]

Despite all you said about varying conditions, you still don't need division in power metering. There is no 1/x function to calculate, anywhere. Just modify the multiplier instead, and keep division constant (as a shift).

And ATMega8 is not cheap. For example at Digikey, cheapest ATMega8 is 1.26USD @ qty 1000. Compare to cheapest STM32F030 at 0.82USD @ qty 1000 and it has significantly better ADC, too. (12-bit instead of 10-bit and while analog performance still isn't that great, 1MSPS enables quite decent oversampling.)

[KerimF]

I already forget what I last used advanced asm for, but my first mixed project is here,
https://github.com/T3sl4co1l/Reverb

Tim

I am afraid that it is too late for me, after more than 40 years of writing in assembly, to write codes in C for my controllers.
The main benefit, to me in the least, of the assembly language is that I don't need to rely/depend on most other's works; definitions, variable types, function' declarations, names of structures and classes... etc. So being somehow isolated from the various programming services which are usually offered to almost all engineers, didn't affect too much my design works. And the reason that writing in assembly worked always for me is that I work independently (being the boss of my private small business since graduation). But the high languages (as C and the like) are essential (cannot be avoided) when working in or for a group of designers, besides the possibility to let their codes be multiplatform in most cases.

[KerimF]

Despite all you said about varying conditions, you still don't need division in power metering. There is no 1/x function to calculate, anywhere. Just modify the multiplier instead, and keep division constant (as a shift).

You are right.
Although the routine is about division, its code, I am referring to, uses, as you pointed out, one multiplication for the integer result and another one for rounding it.

And ATMega8 is not cheap. For example at Digikey, cheapest ATMega8 is 1.26USD @ qty 1000. Compare to cheapest STM32F030 at 0.82USD @ qty 1000 and it has significantly better ADC, too. (12-bit instead of 10-bit and while analog performance still isn't that great, 1MSPS enables quite decent oversampling.)

Thank you for the info.

It seems that the ARM family ICs as of STM32F030 is not available around me.
Its package is surely of the SMD type which usually needs automated assembling processes (which were possible before years 2011, not anymore) for clean reliable boards.   
And... I doubt I will have the chance to get its assembler/debugger program

[DavidAlfa]

It's not about if it's fast enough, does the application really need it to be faster?
Otherwise optimizing something that doesn't need so is just a waste of time.
I.e.your power meter makes 100 reads per second, and the avr has enough power to make 2000 of these "inefficient" operations.
Then just go with it.

Writing in assembly makes no sense except for very specific routines, extremely tight timings and such,  we're not in the 512-byte eeprom MCUs era anymore, C is the way to go.

But I like optimizing things too. It's just that very often I realize it was just, why??
Search "Division by Invariant Multiplication", it's a technique to divide integers with multiplications, not sure if applicable to avr  but multiplications are normally much less expensive.

[Siwastaja]

It seems that the ARM family ICs as of STM32F030 is not available around me.
Its package is surely of the SMD type which usually needs automated assembling processes (which were possible before years 2011, not anymore) for clean reliable boards.   
And... I doubt I will have the chance to get its assembler/debugger program

While I understand your hesitation to solder BGA or LGA packages, if I remember correctly STM32F030 is available in TSSOP20 which is relatively easy to hand-solder and visually inspect the joints for reliability.

Of course you can program it in assembler. GNU assembler is available, and so is gdb. Can't get more universal than that, no manufacturer specific anything. What's best, every Cortex-M0 is the same, so you are not locked in STM32, but can use any other MCU manufacturer, including the cheap Chinese ones. Of course learning to write programs in yet another instruction set architecture is always some learning curve, but this is the price you pay for using assembler.

Even if possible and easy, it makes absolutely no sense to program in assembler, though. Even if you use C, you don't have to use anyone's else libraries, frameworks or even definitions if you don't want to.

[KerimF]

It's not about if it's fast enough, does the application really need it to be faster?
Otherwise optimizing something that doesn't need so is just a waste of time.
I.e.your power meter makes 100 reads per second, and the avr has enough power to make 2000 of these "inefficient" operations.
Then just go with it.

Sorry, I couldn't get you well.
As I explained earlier on post #4, my meters read about 192 or 384 samples in one mains cycle (20 ms typically). So, I just asked my brain to help me find a way to make the division of 32-bit register with rounding somehow fast (132 and 147 cycles respectively) to simplify my code whose main loop is usually based on a time-division topology.

Writing in assembly makes no sense except for very specific routines, extremely tight timings and such,  we're not in the 512-byte eeprom MCUs era anymore, C is the way to go.

You are right.
As I explained earlier, to almost all programmers in the world, writing codes in C is somehow a must for many reasons. In my case, things are different.
 

But I like optimizing things too. It's just that very often I realize it was just, why??
Search "Division by Invariant Multiplication", it's a technique to divide integers with multiplications, not sure if applicable to avr  but multiplications are normally much less expensive.

This is what I did to let my routine be fast. But I also added to it another multiplication to round the result.

Anyway, in order to complete the topic, I will likely prepare and upload the routine, I made, for two ranges of divisor, 160 to 223 (8-bit divisor) and 320 to 447 (16-bit divisor).

[Kleinstein]

Is it really needed to calculate the power for every mains cycle ? Things get less time critical when the calculations are done for longer intervalls. For a RMS caclulation the slow part is usually the root, not the divide by the number of samples.

[DavidAlfa]

Even a slow 8MHz AVR will have 80.000 clocks every 10ms, how many times can it execute that ~150 cycle division?  Like 500?
That's my point.

[KerimF]

While I understand your hesitation to solder BGA or LGA packages, if I remember correctly STM32F030 is available in TSSOP20 which is relatively easy to hand-solder and visually inspect the joints for reliability.

Of course you can program it in assembler. GNU assembler is available, and so is gdb. Can't get more universal than that, no manufacturer specific anything. What's best, every Cortex-M0 is the same, so you are not locked in STM32, but can use any other MCU manufacturer, including the cheap Chinese ones. Of course learning to write programs in yet another instruction set architecture is always some learning curve, but this is the price you pay for using assembler.

Even if possible and easy, it makes absolutely no sense to program in assembler, though. Even if you use C, you don't have to use anyone's else libraries, frameworks or even definitions if you don't want to.

Assuming its assembler and debugger could be reached (despite the world regulations applied on the internet), one thing remains to consider on my side... its availability Meanwhile, my friend 'ATmega8' helps me build various simple and complex controllers.
For instance, soon after year 2012, I had only the small AT89C2051 (PDIP, 2K flash, 15 I/O, no ADC) to build the controller of power square wave inverters. It helped me includes the following functions:
[1] Soft start to avoid the transformer inrush current.
[2] Measure the battery voltage to regulate the output RMS voltage (by varying the duty cycle when Vbat > 12V or 24V), also to regulate the maximum charging voltage.
[3] Sense the mains voltage to activate a SPDT relay (to shift from inverter to charger).
[4] Sense the maximum charging current (its limit is set by a trimmer).
[5] Regulate the charging current (not to exceed its maximum limit) by 3 triacs (isolated by two optocouplers, one for varying the phase and the other for selecting the proper triac) 
[6] Output a serial bit stream (based on in-house protocol) to drive, when necessary, the controller of an external 7-seg display to show its voltage reading.
[7] Sense the MOSFET overload (also set by a trimmer) to shut off the inverter after about 850ms.
[8] 3 LEDs to show its state.

So, it was a big jump for me in making controllers when ATmega8 (PDIP, 4K words, up to 23 I/O, with 6 ADC) became available at a relatively low price, and I was able to download its AVR Studio 6.2.

[KerimF]

Is it really needed to calculate the power for every mains cycle ? Things get less time critical when the calculations are done for longer intervalls. For a RMS caclulation the slow part is usually the root, not the divide by the number of samples.

In general, you are right.
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.
Such meters became important in my city when its citizens, since about a decade ago, have to get their AC power from local AC generators (since the mains power of the city is off most of the day). The owners of these generators sell their electricity per Ampere.

Added:
You are right. The SQRT routine is the slow part. For example, the 32-bit square root routine, I have, needs up to 309+7 cycles.
   

[KerimF]

Even a slow 8MHz AVR will have 80.000 clocks every 10ms, how many times can it execute that ~150 cycle division?  Like 500?
That's my point.

I am sorry for not being clearer.
Any function in the code has to be executed while the ADC reads a sample in the free running mode (13 ADC cycles). If the ADC prescaler is 64, the ADC timing is 832 cycles (13*64). During this time there are also two common codes to be executed, before jumping to that function and after it.

[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