@Matthew Kennedy @Andrey in your opinion whats the advantage between runing a 8bit mcu and a 32 bit mcu apart from having more timers can bus, etc? (serious question)
Matthew Kennedy 4:17 AM
You mean why is 32b better?
Rafael Matos 4:24 AM
Yes on your understanding why woukd you never use 8bit or why you wouldn't use it now
Matthew Kennedy 4:37 AM
That's a sort of complicated question that you could teach several full university courses about (some of which I've taken). There are some technical factors about how the CPU and peripherals actually work, then there are some economic factors that have pushed the world in the same direction.
Technical:
32b generally means that the native word size of the CPU core is 32 bits, which lets you do more math per cycle. For example the stm32 can add/subtract/multiply two 32bit numbers in a single cycle, but an AVR can only do 8 bits per cycle. If you want to add 32 bit numbers, it's possible, but requires issuing four instructions in sequence to complete the operation, requiring both more time and more program space.
In addition to the native word size being longer, addresses are also larger. An 8-bit cpu can only address 8 bits worth of memory, 256 bytes. With some trickery like the AVR does, you actually extend that to 16, but that only gets you 65k of address space. An stm32 has a full 32 bit memory bus, which gives you 4.2 gigabytes of address space. This has implications in that it allows more physical memory to be installed, in addition to more peripherals like timers/usb/serial/CAN.
Economic:
There has been more demand for more powerful processors everywhere (phones/desktop PC/servers/MCUs, literally everything), which means that chip MFGs have more incentive to develop and produce more advanced MCUs. This results in 32 bit processors getting diffused on smaller processes (each transistor is physically smaller), which means they can run a faster clock speed.
Since a faster 32b processor has more horsepower to play with, the development cost is reduced. You get a better "functionality per dev time" ratio when you have a bigger hammer to hit the problem with. For example MS/speeduino/etc use dedicated timers for each output - that's why they're limited on cylinder count on the AVRs, they ran out of timers. But since we had the performance available to not worry about that, we actually only use a single timer, and just emulate an infinite number of timers in software. Is it less efficient? Yep! Does it matter, since the CPU is so fast? Not really!
4:37
sorry for the wall of text lol
Gwendal Blot 4:40 AM
Is this on the wiki ?
Matthew Kennedy 4:40 AM
not yet :slightly_smiling_face:
:heavy_check_mark:
2
Gwendal Blot 4:41 AM
Should be imo, quite readable for semi specialists
Matthew Kennedy 4:44 AM
a quick perusal of mouser says that the fastest 8b MCU they carry is 100mhz, and fastest 32b is 400mhz
1 reply
Today at 9:49 AMView thread
Rafael Matos 4:49 AM
@Matthew Kennedy beautiful text, good info, as you said thats what we learn at uni, but in terms. Of engine management do you believe the advantage is only the timers and the fact it requires less cycles for the same calculations?
Matthew Kennedy 4:50 AM
the actual value for this project is that with a faster CPU, the ratio of tricks or cleverness required to functionality achieved is minimized
:heart:
1
Gwendal Blot 4:51 AM
Isn't it an automotive rating thing also ?
4:52
I.e. most commonly used 8 bit platform isn't regarded as the safest one that exists
Matthew Kennedy 4:52 AM
plenty of 32b stuff is automotive
4:53
tricore, spc5, etc
Rafael Matos 4:53 AM
S32
4:53
Mcp5
Matthew Kennedy 4:53 AM
kinetis
4:53
etc
4:53
they exist
Rafael Matos 4:53 AM
The future will probably be mcu+fpga
Matthew Kennedy 4:54 AM
you don't really need it for stuff like engine control
4:54
the versatile timers they have are plenty
4:54
and the whole industry seems to have settled on 60-2 as the "one true trigger pattern"
Gwendal Blot 4:54 AM
Multi core 32bits MCU ?
Matthew Kennedy 4:54 AM
yes
4:54
many of the ones we listed have multi core options
4:54
both lockstep and true multi core
Rafael Matos 4:55 AM
Yes most also have dedicated hardware for crank cam. Timing
Gwendal Blot 4:55 AM
That would be neat for interruption parallelization, with possibility of running a 60-2 or even more at 15k rpm
Matthew Kennedy 4:55 AM
we can do 60-2 at 15k (edited)
4:56
the point of the fancy timer hardware is that you don't need per-tooth interrupts
Rafael Matos 4:56 AM
Exaclty
4:56
Which the OEM manufacturers really prefer
Matthew Kennedy 4:56 AM
everybody prefers fewer interupts
Rafael Matos 4:57 AM
And also makes it easier to be plaved in several different cars
Matthew Kennedy 4:57 AM
I heard an anecdote that you could break in to the debugger (halting the CPU) with an engine running on the dyno, and it would continue running just fine
4:58
it wouldn't vary the ignition timing or fuel quantity, but it would continue running steady state
Rafael Matos 4:59 AM
The thing is, i understand 8 bit is enough to run an engine, and it works fine, everweek there is at least 9/10 8 bit ecus passing through my hands, but i dont like the fact that people try to make it look that has a lot if headroom and there is no advantage on 32b
4:59
Like the iphone 1 also makes calls and sends texts...
5:00
:face_with_rolling_eyes:
Matthew Kennedy 5:00 AM
But the iPhone 1 doesn't take photos like this
Image from iOS
Image from iOS
Rafael Matos 5:00 AM
Yep
Matthew Kennedy 5:02 AM
also geez I need to clean my keyboard
5:06
though to their point, even if an 8b ecu is fully packed with work to do, it can still work fine
5:06
there are many cases that it is 100% adequate, and you wouldn't get any gain from a faster cpu
Rafael Matos 5:06 AM
Of course
Matthew Kennedy 5:07 AM
my race car would make the exact same power with an ms2
Rafael Matos 5:07 AM
The problem is everytime there is a new idea to add something the mcu is a limiting factor and there is a lot of work that has to be done in order to work around it
Matthew Kennedy 5:07 AM
yep
Rafael Matos 5:08 AM
I get that, there is not many people that have seen and assembled so many DIY engine management systems as i did, i know what works and what doesn't work, i just don't like that people always try to find a way to justify things
Gwendal Blot 5:19 AM
Main advantage of a 32 bits ECU is you can brag about it at car meets when leaning on your engine
Simon - Orchardperformance 5:45 AM
I like to use the simple analogy of the flathead V8, sure a flat head V8 will run and drive, sure you can tune it up to decent power, but no matter what it is always going to be a flathead V8 and your not going to get the same $/hp or peak power or light weight from it.
Same deal for an 8 bit CPU
Dave B. 9:52 AM
If you look at the really successful automotive MCU platforms circa 201x, you'll see a few things:
9:52
-32 bit (way of the world)
9:53
-Dedicated coprocessors / programmable timer modules / fancy timers for handling time sensitive events
9:54
-Often a solid FPU, "DSP" or other set of instructions for doing lots of math fast
9:55
PPC/MPC/Power architecture, Tricore, SuperH, ARM variants. They all have very similar playbooks.
9:56
Unfortunately, most of the chip manufacturers will make you sign a fairly strict NDA before releasing details of their "TPU" time processing unit programing, from what I understand.
9:57
Processors like the XGATE that have been used successfully despite relatively modest specs (16 bit, low clock speed) tend to have very well developed secondary timing processors.
9:58
I look at the Honda ECUs on my bench that came in 1992 model year vehicles and would at least run an engine at 12,000 RPM with nothing more than a chip change. They have a 10Mhz 16/8 bit MCU with no floating point and an ASIC for handling timing tasks.
