Coding guidelines documentation
This commit is contained in:
@@ -21,9 +21,10 @@ As mentioned previously, all core engine control is handled on the Cortex M7, th
|
||||
|
||||
### Input Signals
|
||||
The engine provides two key input signals:
|
||||
- Crank pulse
|
||||
- Cam pulse
|
||||
- Crank pulse, triggered every 180 deg
|
||||
- Cam pulse, triggered every 720 deg and slightly dephased
|
||||
These are both registered using a hardware interrupt using `TIM2` as a low jitter time source.
|
||||
These signals can have missing pulses or extra triggers which need to be accounted for.
|
||||
|
||||
### Time Base
|
||||
`TIM2` is the main timebase used to control the engine, it provides 4 channels that are used as follows:
|
||||
|
||||
20
docs/CODING.md
Normal file
20
docs/CODING.md
Normal file
@@ -0,0 +1,20 @@
|
||||
# NeoECU Firmware Coding Guidelines
|
||||
|
||||
## Naming Conventions
|
||||
Functions : camelCase
|
||||
Variables : python_case
|
||||
Constants : UPPER_CASE
|
||||
Macros : UPPER_CASE
|
||||
Types : python_case_t
|
||||
|
||||
## Performance Standard
|
||||
Don't use heap at all if possible avoid mallocs at all cost.
|
||||
Don't make heavy computation in ISR delegate everything to a task that you'll wake.
|
||||
Don't copy big chunks of memory, use pointers if you need to read a buffer, even if simply passing the buffer as a parameter compiles it will have huge overhead.
|
||||
|
||||
## Readability Standard
|
||||
Avoid more than one layer of pointer indirection if possible.
|
||||
Don't use void* they are unclear and make mistakes more likely.
|
||||
Avoid magic numbers and indexes, use macros and constants to define them clearly.
|
||||
Define all macros in macros.h and all global variables and constants in glocal_state.h.
|
||||
Use one c file per feature, avoid big monoliths that become hard to jump around.
|
||||
Reference in New Issue
Block a user