- Fri Oct 04, 2024 1:38 pm
#69753
Perhaps you should not have replied at all.
PSIG wrote: ↑Thu Oct 03, 2024 8:11 pm Perhaps I should postpone conversation until I know the basis for contention here, but I will respond in good faith and out of curiosity, and so any others that might read this know the perspective of my question in order to follow.
It would seem you need more processing speed, and so a more powerful processor would be in order, using current code in your application. So, I assume you should pursue that other processor.
That said, I am curious why the 16MHz Mega2560 is insufficient to process a 257Hz crank speed (16500 rpm). Only a curiosity, not that it can or can't but why, and where the "bottleneck" in processing is located. Thus my question. I understand you simulated and it apparently failed, and as a programmer you would have the ability to examine where the process was slowed excessively. However, I am not a programmer, and am again assuming.
If my assumption was correct, perhaps you would or could identify the bottleneck, and could (as one option) pursue a streamlined version for high-rpm applications. Perhaps the bottleneck was extra functions and frills not needed on a 'simple' application, that could be deleted or disabled for the code to run sufficiently quick?
My interest in this is high, as my position has always been for Speeduino to focus strictly on operating the engine, and very well when it does. No "toy Arduino", but an ECM that has no equivalent rivals in quality of function. It's not an Arduino, but a legit processor that happens to also be used by some Arduinos. Arduino was simply a convenient path to developing the concept. This means that non-critical functions would not be added that could slow or reduce quality of control. What I call 'bells & whistles" or "glitter & bling". Stuff that — if desired — should be modular, such as a BCM, TCM, or GPIO, etc, avoiding bugs, excessive merges, updates, complexities and speed, ensuring solid, reliable and optimal function for the engine operation.
I had this exact conversation years ago at lunch (and later at a pub ) with Bruce and Al (the 'fathers' of Megasquirt). Amazing guys, looking for the direction to develop their young product. It's a story for another time, but helps answer why ECMs on the market are structured like they are, with how the mold could be broken, and was a big piece of what formed my position today.
To @noisymime's credit, Speeduino has most of this functional foundation, such as interpolating tables that avoid the need (and do a better job) than the old-style zillion-cell tables. Should it have AC control? NO. Add that as a module that talks to Speeduino, else it slows and complicates the required engine control. Plus, the AC ECU or BCM can do a better and more focused job of its tasks, allowing changes, options and mods without messing with the Speeduino ECM. Win-win.
This is only my opinion position, in-support of optimal high-performance engine operation with the ability to "do anything", that also enables success for Speeduino, users, and commercial opportunities. So I hope you see my perspective, that knowing why the Mega2560 is insufficient for your application can bring focus to making Speeduino a better, highly-respected and desired control option. Everyone's inexpensive first option (most of all mine ) in engine control.
Some old guy who started programming at 8yo in 1966