I recently started a thread on providing microcontroller-based electronic modules. In it, concern was expressed that I might not understand the scope and complexity of such an undertaking, and/or that I was shying away from wading in to electronic design. Perfectly understandable, especially considering my communication skills. (Even poor skills can be called skills. )
So, without (much) apology, my "CV":
I have been working on cars and motorcycles since around 1972, and on other things mechanical since 5 years previous. I fix things; I make things work. It doesn't matter much what it is. In 1973, I got interested in computer programming, and, shortly after that, in electronics. I got a job in mainframe computers in 1979, taught myself several computer languages (including several assembler languages, micro and IBM mainframe). I got hired as a Programmer (IBM BAL) in 1987, and worked as a Programmer until around 2004. During this time, I also took college courses in Electronics Technology, missing out on my Certificate by one class. (The instructor left the program.)
Most of my programming experience has been "on the metal", in machine-readable code. I understand how processors work, why they work. In Assembler/machine-code, the hardware does exactly what you tell it to do, which can be unfortunate when running in a Privileged/Supervisor state (which most of my later coding was in).
With some brush-up, I can build a processor from discrete transistors. I can build a processor out of discrete logic chips. I can build a processor out of bit-slice logic. I can design and etch my own (simple) circuit boards. I can build a computer out of uProcessors. But why would anyone want to if someone else has already produced an adequate board? Why would someone want to make a commodity part from scratch? In a modular approach to hardware, it makes sense to use parts that are already readily available, and for much less than I could make them. (I don't bother doing long-division anymore, either. )
My college major was in mathematics. I also have enjoyed studying the physical sciences. I THINK in terms of math and physics. In these narrow areas, I am likely genius. (Along with that goes a bit of an ego...) I am socially inept. I currently teach children with autism, and am good at my job because I can understand them. I tend to use words in their truest sense rather than their current social context; misunderstandings arise.
I have said that there is no need for a Floating-Point-Unit (FPU) for math intensive routines in my proposed gadgets. The honest truth is that there is seldom any need to use floating-point math in non-scientific and non-statistical software. Hobbyist "high-level" languages make unnecessary use of FP (really "scientific notation") to make things simpler for the novice coder; this is one reason why a lot of modern programs are such resource hogs. Enterprise-quality compilers avoid FP like the plague that it is.
Why modular software and hardware? As complexity grows, this is the only way to manage that growth. There is a need for small, discrete modules of code/electronics, each one with a well-defined, limited purpose. Maintenance and future enhancements depend on the ability to understand the current functioning. Otherwise, things get real ugly.
So, it is within my capability to design and build everything involved in an ECU, but I believe that is counterproductive. There are several existing processor boards from which to choose. It would also seem to be silly to design and build the control hardware when there are several highly integrated, highly capable and very cheap digital/analog interface ICs on the market. My time would seem better spent integrating the parts rather than reinventing them.
I also know that perspective from others is needed in any non-trivial undertaking. I have a different perspective than most, so am that much more in need of differing views. Quality results can only come form quality input.
I could do it many ways, but simpler makes more sense. For those of you who read this far,