OG, my angle is to provide the general framework for accomplishing a task, then break the framework into steps, then further to the requirements of each step, in order for them to all come together to reach the goals of the task. A large portion of tuning theory comes into play before the engine is started the first time, and it's very easy to lose critical steps in a sea of information. Rather, I feel we must assume the user knows what it basically takes to run an engine, and we are only showing them how to have Speeduino do that instead of a carburetor or different ECM, in clear but increasingly detailed steps.
In the case of the Wiki, the "configuration" section contains the specific system info and how to instruct the ECM to control it, while the "tuning" section is which specifics to use, when, and why. The balance of writing everything you'd ever need to know, against some assumption that certain basic knowledge is existing or obtainable by the user must be made, with the added assumption that a user at the level of creating a custom engine management system from scratch already has at least the basics of that in-hand or nearby.
An analogy would be a recipe book, where we can't reasonably take time and chapters to explain what a mixing bowl is or what eggs are, or that heat may be required to cook, with too little or too much under-cooking or burning the food; and therefore must assume the reader already has basic knowledge of cooking as a prerequisite — or will obtain it.
In the case of "first engine start", an outline might involve four basic steps to reach that point, perhaps consisting of:
- determining requirements of inputs and outputs (IO), quantities and coordination,
- instructing the ECM to deliver those requirements,
- verification those instructions are occurring how and when they should,
- first engine start and continued running.
Moving-on to breaking those down further in the next section, such as defining the first step as required sensor inputs for this specific project (trigger signals, temperatures, etc.), outputs (injectors, coil drivers, etc.), followed by quantities (hypothetical pulses, VE, dwell, etc.) and coordination (squirts-per-cycle, ignition timing, firing order, etc.). The second step to refer to Configurations and Settings
to instruct Speeduino through TunerStudio how to accept input and then output the requirements determined in the first step. The third step to verify the ECM is actually doing what it's supposed to in harmony with the vehicle, including valid RPM, injector operation, fuel pump operation, reasonable fuel rail pressure, spark plugs sparking and in correct order, timing of the sparks matches the settings, etc. And the fourth step of starting, observing engine responses, determining errors and making corrections.
Finally, the last section is telling users how to actually accomplish those steps, some of which is already accomplished. How Speeduino uses VE. How to use the VE Table Generator to rough-in the VE table, or manually create a VE table if you don't have that tool. Fortunately, much of step two is covered (or should be), such as how to set the dwell determined in step one, or trigger function, or calibrate sensors and provide correction tables, or set priming pulses, WUE or ASE. How to effectively test for proper hardware operation before starting, in order to avoid excessive wasted time and frustration, or even damage. And lastly what cautions and steps to take on first-start, what will likely need adjustment from the step-one hypothetical to the new step-four reality, along with how to do that and in logical order for success using TS, logs, MLV, and other tools effectively. Note the 'first engine start' is only the last of these sections, but requires stepping through the first three to get there. See, that was simple!
Viable alternative structures, methods, and suggestions should be open to discussion and implementation.