Some background...

[NorthWet]

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,

 

Cheers!!!

[Scott in Bellingham]

Im ready and support this, when you come up with a stand alone system that will make a stok EJ moter run I want to be part of it and sell them at my store

[tractor pole]

Quality results can only come form quality input.

 

I couldn't agree more, I think that this could be a lower cost/simpler approach to stand alone engine management for those that do not want/need all the extra options and added expense of currently available systems.

 

I try not to pass judgement on this forum but the anonymity that the internet generally provides I can see how some might be skeptical.

 

It certainly sounds like your background and past experience will definitely help you through the design and implementation process.

Good luck and I am excited to see what you come up with.

 

Ben

[NorthWet]

Whatever might result from this will be determined by the community's technical help.  If there is one thing that I know, it is that there are things that I don't know.  There are better ways of doing things then I would think up on my own.  There is expertise spread throughout.  I know that left on my own, that I will make some wrong decisions: it is just the nature of the process.  People need to be willing to question, to call "bull****"... sometimes they are right.  I am used to this.

 

Cheers!

[NorthWet]

...I try not to pass judgement on this forum but the anonymity that the internet generally provides I can see how some might be skeptical....

Everybody has a right to be skeptical.  Skeptics are far more useful than wide-eyed zealots.  Only a very few members have ever met me, and only a couple have spent much time with me... and that was mostly just talking cars.  Add a couple years of my undiagnosed migraines making me appear flaky (really messed with my memory, with hilarity ensuing ) and you get a lot more reason to sit back with some popcorn and watch the train-wreck.

 

When it comes to programming I have a huge ego, and that is both a gift and a curse.  I have to let the ego out to do great things, but I also have to keep it reigned in to keep from alienating those with whom I am working (who also tended to have big egos).

 

Question everything, assume nothing.  I have no feelings to hurt.