New to Embedded Programming - Curious About EMS Software Architecture

Official FreeEMS vanilla firmware development, the heart and soul of the system!
Post Reply
ThatRotaxCar
TO92 - Vaguely active
Posts: 3
Joined: Tue Jan 11, 2022 1:13 am

New to Embedded Programming - Curious About EMS Software Architecture

Post by ThatRotaxCar »

Hey guys! Gonna dive right into it - sorry for the essay I'm about to write, and apologies if I have questions that are "googleable" or considered common knowledge. I'm still pretty new to embedded programming but I'm doing a huge amount of reading in my spare time! Hopefully this is an appropriate spot to post this.

About Me/Background
For context, I'm a software developer (mostly C# and .net) and I want to write my own EMS for an NA 1985 Mazda rx7. I'm quite familiar with this car and have rebuilt most of its systems a couple times. I'm also interested in adding hybrid elements to the car, like a motor-generator to gather energy from exhaust gases and/or a motor-generator to power the car in parallel with the rotary engine (if you're familiar with current F1 cars - mgu-h and mgu-k).

I've been researching engine management software architecture for the last few months, but am finding that most software is proprietary. I did buy a bunch of great technical papers from the SAE site, and I've been looking at the ms3-source git repo - and now I've stumbled on this forum! I'm hoping I can keep learning and get to a point where I can give back.

Initial goals:
- runs the stock NA 13b rotary engine (how hard can it be?)
- can enable logging to view sensor data in the cloud (this part is a bit easier for me - I made a prototype app that can display data in real time)
- being a dev by trade, I hate spaghetti and want to make the ems as reusable and abstracted as possible

Future goals/nice-to-haves:
- basic functions programmable (engine timing, air-fuel ratio maps)
- hybrid functionality
- support for a turbocharger, because I may want one in the not-so-distant future

Questions
- Do we just rely on the crankshaft positioning sensor to properly time the spark/fuel injection, or is a timer used?
- Are interrupts used to control the coils/injectors/rest of the car, or are there multiple threads (or modules) that each monitor/control a part of the car?
- Are there standardized control algorithms for the software to use, or is that something that each EMS developer would have had to discover for themselves (for example when calculating engine load)?

Thanks if you made it this far - I'm still so unclear on a lot of these concepts that I'm not really sure how to turn them into questions! I guess my main uncertainty is how the software is laid out (simple, right?) so I'm hoping that it'll make more sense as I look at the source code.

- Roland
User avatar
Fred
Moderator
Posts: 15414
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: New to Embedded Programming - Curious About EMS Software Architecture

Post by Fred »

Wrong section, but it can stay for now :-) I'll move it later when you're ready.

13b - how hard can it be? Not very. Just need more than average IO for a "four cylinder" because factory staged injection.

Answers:
Yes/no/maybe - you'll be able to answer this yourself when you start writing some code and getting some data and trying to use it to do some good :-)
Yes/no/maybe - you can use any method software or hardware or FPGA that gives you the required real time nature and precision/accuracy.
Yes/no/maybe - Speed Density is pretty standard but by itself it's not enough - you need to establish a data flow and amendments to the base line and make it all make sense in the right units etc - I'd err on the side of saying "each designer does this" as the basics that are "given" are not enough.

Reality of timers: Most MCUs don't have 100 of them, so you have to economise on that somehow.

How the software is laid out:

Embedded typically has a main loop, there is no OS that can be idle - it's chewing up instructions as fast as it can so just start it on the next job as soon as it's done with the last. Interrupts in embedded world typically do exactly as their name says and STOP the main loop code, run their tiny bit, then resume the main loop code. So you have to think about all this stuff in precise detail to get a usable safe system that won't send your rotors into a low earth orbit and shatter your apex seals the first time you try it out :-D

PS, compulsory users' rides thread on your 13b miata - sounds like a fun car :-)
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply