A loooooong tmie ago (circa... 1992?) I had the same problem with an Hitachi embedded processor. Except our application was hard real-time (controlling the fuel injector of a Ford 150 that was modified to run on natural gas).
We ended-up splitting the division code over multiple loops of the core system so that it would not exceed the allotted time when the engine was running at maximum RPM. It meant that the value that required division would only update at something like 1/6th of the data acquisition speed of all other values, but hey, it worked.
Maybe I still have the source code on some floppy disk somewhere...
I did something similar for a high speed (10k rpm) stepper motor driver. We were emulating a legacy system and needed to do a 24 bit/16 bit divide, which took a long time. Even worse was that when the speeds increased, we had less time to do the computation. I came up with a trick: when the denominator changed to above a certain value, I knew the output's MSB would be zero, so I switched to a more efficient division routine that computed fewer bits. It was enough to get us smooth performance without running out of time.
I don't know why but the idea of working on an engine management system is incredibly appealing to me. How did you get into the field? I unfortunately have no background or formal training in embedded systems so I fear I have no real possibility of success in this dream
Get a job working in embedded systems. Preferably in the right industry.
Like any programming job, but without formal experience you'll need more (and interesting) informal experience, ie side projects.
Start with something simple, like an STM32Discovery board. Blink the LEDs. Respond to the button.
Get a logic analyzer, like a Saleae ($400 for the Logic8) or Digilent Digital Discovery ($200, worse software IMO) or something similar. Get a bench power supply. Get an oscilloscope (Rigol DS1054Z is cheap ($400 or so) and hackable. Don't get a PC-based one, get one with a UI similar to what you'll use in professional work.) Get a couple of cheap USB-UART adapters, maybe a BusPirate, an ST-Link, and a hand full of STM32BluePill boards.
Get an SPI flash memory dev board, and write code to read/write that external flash. Use the STM32's built-in SPI peripheral. Use the logic analyzer to decode the signals & for debugging.
Get an I2C sensor dev board, and write code to read the sensor value. Use the STM32's built-in I2C peripheral.
Get FreeRTOS running on your Discovery board. Make tasks for your sensor reads, LED control, maybe log data to the SPI chip. Show that it's all hard real-time.
From there, maybe add more inputs & outputs. Making a 3D printer or CNC router from scratch would be impressive. Or an RC car, or some sort of robot, or a drone. Maybe go to a more capable SoC, like a BeagleBone Black board or Raspberry Pi. The product I work on (an eletronic logging device for the trucking industry) was initially prototyped using a BeagleBone Black. (This post is my own opinion, and should not be taken as official statements of my employer.)
Or go to a less capable chip, like a PIC16F18345 ($12 dev boards) and see what you can do with <=1024 bytes of RAM.
Definitely learn to build your code without using the vendor IDE. It'll save you a lot of pain. Makefiles (or CMake, or whatever build system you prefer) + writing linker scripts +
pointing your preferred IDE (or editor) at that is a much better way.
Espressif's ESP32 and ESP8266, Nordics NRF52 parts, and some others have built-in networking (BlE, WiFi, Cell, etc). Those can be good for all sorts of projects.
There's some industry bias against Arduino, it's seen as overly abstract and not something "real" programmers use. If you get an Arduino, it can be a great starting place, but also get an ICSP (In Circuit Serial Programmer) and learn to use the ATMEGA328p chip without the Arduino bootloader+libraries. It's a fine chip and a fine platform, but not necessarily great for resume building.
Basically look on Adafruit and Sparkfun and the like, figure out what sorts of sensors & outputs look interesting, and start making things to use them. The product lines I mentioned happen to be popular among hobbyists, which means less chance of getting stuck without community help available.
We ended-up splitting the division code over multiple loops of the core system so that it would not exceed the allotted time when the engine was running at maximum RPM. It meant that the value that required division would only update at something like 1/6th of the data acquisition speed of all other values, but hey, it worked.
Maybe I still have the source code on some floppy disk somewhere...
Edit: I remembered wrong, it was a GMC truck: https://www.sae.org/publications/technical-papers/content/92...
Edit #2: found a picture of our truck: https://live.staticflickr.com/8487/8186513796_bd60fd3fd2_b.j...