And without OpAmp, like in Unicorn? MCU+FET and nothing else?

That’s weird. In my view, programmers are also PCB and schematic developers. These tasks can’t be addressed separately. And there are enough people to write programs.

I don’t think so. Problem is the technical feasibility of these ideas and they can be anything – this doesn’t affect the implementation of the current regulator. There are will still be the same approaches and requirements, no matter what we use for UI. Even type of driver doesn’t matter much. Linear, Impulse, with external stabiliser or software, for 50mA or 50A…

It is, for now, but I’m thinking to move to a pre-calculated tabular version. That’s faster, more flexible and convenient and takes similar amount of memory.

I now have a resolution of 160 steps, and it is enough. 160 steps is not so much for a tabular version with a depth of 16 bits (a total of 320 bytes per profile). This also does not affect the thermal control, because it takes effect after the UI with all its transformations. It modifies the Iref, that was set by UI before it arrives at the input of the current regulator. This is a system mechanism, isolated from the UI. And it does not cause any problems, so the UI can be implemented as you like …

Clones of fairly simple interfaces, which I can write in a few hours myself? Could a completed engine be so flexible and versatile to allow you to implement at least some non-standard functionality as quickly?

What I need right now:

  1. Do you have a stack of returns a step back implemented in FSM (I’m still struggling to do this with so many branches, and I haven’t gone beyond one step)?
  2. And what about predictions of further actions of the user in order to execute commands even before completion of their activation by user? With an analysis of the commands themselves, to make exceptions like “if you now need to preload the turbo, but it will be followed by the moonlight - it’s better not to preload the turbo, because a prediction error is more harmful than a good forecast”. It used to be easy to do, but now the interface has become amorphous and this mechanism should automatically change its behavior according to the situation. And without it, the interface is laggy.
  3. How does it work with context, transmitted between commands to each other (transmit brightness to a beacon, for example)? To manually drag through the variables?
  4. How easy is it to implement a configurable UI like Unicorn? Will it facilitate this task?

I’m not familiar with FSM. If it has necessary functionality for implementation of all that, than it’s interesting indeed.

It may help. If you reserve at least 16 first registers (R0-R15) for assembler inserts, the problem can be considered solved. It remains only to figure out how to explain to GCC which cells in RAM to use to communicate with assembler interrupt handlers.

And I have a 4-channel buck on ATtiny24 (located on one side of the 17mm board), and there all 4 channels work in CTC mode (250kHz, 32 steps) without any issues. Since unused Comparator C is only available on timer 1, the timer 0 is reset by interrupt of the timer 1. And thanks to ability of the assembler to strictly plan clock cycles - everything works as it should. In addition, 32 cycles are enough for the DSM of all 4 channels and there is still time left for the background loop.

And another example:
I once developed an ultrasonic positioning system for industrial machines in rooms (where GPS does not work, and its accuracy is worse, than millimetre, anyway). There the slightest jitter of the transmitter led to noticeable errors in measuring the distance to it, and again the assembler came in handy. With it, the main influence became the air flows in the room …

There are fewer latency requirements thanks to hardware synchronization of OCRXX timers over timer overflow events. But this does not cancel the requirements for code execution speed. DSM must have time to calculate everything before the end of the PWM period. And this is, well, a dozen or two clock cycles for several channels. There is no time even to save the context onto the stack…

That we’ve been translating for more than a week this time >_<…
[From translator] And this one as well. That’s on me. Sorry, I’m kinda busy and lazy. Bad mix, I know.

What do you think if I write in Russian and you will try to deal with google translate? ))