Import dev files

This commit is contained in:
Josh Stewart 2020-01-06 12:47:50 +11:00 committed by GitHub
parent 5b841c3945
commit e21901f1a6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 226 additions and 0 deletions

97
dev/Code_overview.md Normal file
View File

@ -0,0 +1,97 @@
<h2>
Description of source files
</h2>
<h3>
speeduino.ino
</h3>
speeudino.ino is the main project file, including both the setup() and loop() functions that are common to all Arduino sketches. Additionally, it also includes the callback functions to turn the injectors and ignition pulses 'on' and 'off' As at April 2015, it also includes the crank sensor trigger function. This will change in the future when the modular wheel decoder is written
<h4>
Main loop
</h4>
The main loop runs continually, and has 2 primary functions, determining the engine requirements and setting the ignition/injection schedules according to these requirements.
A high level description of the functions performed in the main loop is below:
- Check whether there is a request in the serial buffer to be processed
- See whether the engine is turning by looking at the last time a crank tooth was seen
- Read values from all analog sensors (TPS, IAT, CLT, MAP, O2, Battery voltage). Not all sensors are read every loop as they do not change frequently enough to warrant this
- The following functions only occur if the engine has 'sync':
- Check whether the RPM is above or below the cranking threshold (Both fuel and ignition values are adjusted when the engine is cranking)
- Run all corrections functions (See corrections.ino section below). The outcome of this is a % that the pulsewidth will be adjusted by (100% = no adjustment, 110% = 10% more fuel, 90% = 10% less fuel)
- Lookup VE from the the main fuel table
- Convert VE into a pulsewidth value in uS
- Lookup the desired advance from the ignition table
- Calculate the current crank angle
- Calculate the crank angle that each injector should open at based on the current engine speed
- Calculate the dwell angle based on the desired dwell time and current engine speed
- Calculate the ignition start angle for each cylinder by subtracting the advance angle and the dwell angle from the TDC angle
- Set a 'schedule' for each injector by converting the above calculated start angles into a number of uS in the future (Eg if injector should start opening at 45\* ATDC and the crank angle is currently 10\*BTDC, how long will it take to travel those 55\*)
- Perform the same schedule setting for each ignition output
<h4>
Trigger
</h4>
This function is called whenever the crank sensor 'sees' a tooth. It performs the following functions whenever it is called:
- How long has it been since the last tooth was seen ('Tooth Gap')
- If this time was too short, consider it to be noise and filter it out
- Add the latest tooth gap time to the Tooth History array
- Check for a missing tooth
- Store the tooth gap time so that RPM can be calculated in the main loop
<h3>
comms.ino
</h3>
<h3>
corrections.ino
</h3>
<h3>
display.ino
</h3>
<h3>
math.h
</h3>
This file contains some utility functions that are all aimed at improving performance. A brief description of each is given below
- fastMap - A faster version of arduinos Map function. Not currently in use
- fastMap1023toX - An even faster version of the Map function, used specifically when the original values are in the range 0 to 1023. This is common because this range is what the arduino analog inputs are in.
- divu10 - A high performance divide by 10 function for unsigned ints (Eg x / 10)
- divs10 - A high performance divide by 10 function for signed ints (Eg -x / 10)
- divs100 - A high performance divide by 100 function for signed ints
<h3>
scheduler.ino
</h3>
<h3>
storage.ino
</h3>
The storage file deals with storing and loading the ECU configuration onto the arduino's EEPROM. This is broken into 2 parts:
- The load and save functions for the configuration pages
- The load and save functions for the sensor calibration values
For the layout of the EEPROM address space, see the commented table in storage.h
<h3>
table.ino
</h3>
<h3>
timers.ino
</h3>
<h3>
utils.ino
</h3>

98
dev/Style_code.md Normal file
View File

@ -0,0 +1,98 @@
File Structure
==============
Items must be arranged in the following sequence:
Header comment
1. included files
2. defines
3. local struct typedefs
4. local prototypes
5. global vars
6. main function (if present)
7. local functions
In a C header (.h) file items must be arranged in the following sequence:
1. Header comment
2. ifndef guard
3. included files
4. defines
5. struct typedefs
6. prototypes
7. (extern) global vars
Names
=====
All names should be meaningful and follow existing usage patterns if present.
Conventions
-----------
| Item | Standard | Example |
|---------------------------------------------|--------------------------------------------------------------|---------------------------|
| Functions | camelCase, lowercase first letter, no spaces or _ | readSensor(); |
| Variables | sensorValue = 0; |
| Anonymous variables (eg some loop counters) | Single lowercase letter (Preferred order or use: x, y, z, i) | x++; |
| Constants | UPPER_CASE, words joined with _ | 1. define TWO_SQUARED 4 |
Layout
======
- Use spaces for indents, not tabs
- Indent 2 spaces per level
- Always use { }, even for single statement blocks
- Describe block structures using indentation, do not rely on { } alone
- For multiple line blocks, brackets should always have their own line:
` void readSensors()`
` {`
`    analogRead(sensor1);`
`    analogRead(sensor2);`
` }  `
- Single line blocks (if/else statements etc) should be on the same line and must includes braces
- When used on a single line, there should be a trailing space after the { and a preceding space before the }
` if(fanEnabled) { digitalWrite(fanPin, HIGH); }`
Declarations
============
- Declare variables at the top of the function
- In a block of related definitions vertically align the names, types, and initialisations
- Initialise variables close to where they are first used.
Functions
=========
- Put the return type on same line as function name
- Functions should be kept as short, and broken into sub-functions as required
- Each function should have a single clearly defined purpose, this purpose should be reflected in its name.
Executable Statements
=====================
- One per line, not i=0; j=0;
- Multiple operations are permitted per line where appropriate. Eg: i = j = 0;
- True / False if statements should not use a comparison to 0 or 1. Eg:
- Good: if(isEnabled)
- Bad: if(isEnabled == 1)
don't use comma operator
Function definitions
====================
- Use inline static for all non-interface functions
- Use prototypes for all functions (even those returning int)
- Don't turn parameter type checking off in prototypes with (), use (void) instead
- Give sensible variable names in prototypes
Comments
========
- Blocks comments should be used for any single comment longer than one line
- Single comments are preferred at the end of a line rather than on their own line beforehand

31
dev/Trademarks.md Normal file
View File

@ -0,0 +1,31 @@
<languages/> <translate>
Overview
========
Whilst the Speeduino project is completely open source in terms of hardware, software etc both the name ('Speeduino') and logo are trademarked in the USA and Australia (And potentially others). The use of either (or both) the name or logo is limited to the specific methods outlined on this page.
I encourage the adaptation of the designs and code that are included in this project, but in order to protect it from exploitation and potentially quality concerns, these restrictions on the project identity will be enforced.
Speeduino name
--------------
No unofficial boards (Eg PCBs), complete products or accessories may use the name 'Speeduino' on it's own, or combined with something like a version number, in a way that could potentially imply that it is in any way sanctioned by the project. The 'Speeduino' name maybe used, however, if it is combined with wording that indicates that the product is related to Speeduino. Permitted examples of this are:
- 'Speeduino compatible'
- 'Made for Speeduino'
- 'Powered by Speeduino'
If you wish to use other, similar wording, but are unclear whether it is allowed, please contact me for clarification.
Speeduino logo
--------------
Similar to the 'Speeduino' name itself, the logo may not be used on it's own. However, additional wording may be added to make clear that the product in question (hardware/software/documentation/artwork etc) is not an official prt of the project. As with the naming, the following examples are permitted:
- 'Speeduino Community'
- 'Speeduino compatible'
- 'Made for Speeduino'
- 'Powered by Speeduino'
</translate>