529fd4128c
* exti default * s * skip late events * there are more hellens now * oof * science * kick * kick * I do not understand how computers * science * science * no workflows to speed loop * use existing subtraction * extract function because I don't understand computers * well, let's just dump the stack nearby * is flipped condition still broken? * different behavior * what if we don't optimize * mass storage overflows * ok fine optimize a little bit * we are just unable to print 64b apparently * angry integers * track which wheel/value was last * signal instead of both * try a queue * Revert "no workflows to speed loop" This reverts commit 0637a7d7ab39a3fb2af1a01eef6123b7269559a4. * s * print new timestamp too * don't overrun the error buffer * try to see where the event came from * s * does it help if we abort while self stim is enabled? * do it in hwHandle * what if we disable the pins * include * run with the safeties off in the name of science * s * d * fix configs * s * s * remove duct tape * put the test back too.... Co-authored-by: Matthew Kennedy <makenne@microsoft.com> |
||
|---|---|---|
| .. | ||
| 48way | ||
| GDI4 | ||
| atlas | ||
| core8 | ||
| f407-discovery | ||
| f429-discovery | ||
| frankenso | ||
| hellen | ||
| kinetis | ||
| microrusefi | ||
| nucleo_f767 | ||
| nucleo_h743 | ||
| prometheus | ||
| proteus | ||
| skeleton | ||
| subaru_eg33 | ||
| tdg-pdm8 | ||
| STM32F407VET6_Black.bat | ||
| STM32F407VET6_Mini.bat | ||
| clean_env_variables.bat | ||
| clean_env_variables.sh | ||
| common_make.bat | ||
| common_make.sh | ||
| hellen_meta.h | ||
| mre_meta.h | ||
| proteus_meta.h | ||
| readme.md | ||
readme.md
Boards Directory
rusEFI supports quite a wide array of hardware - we support stm32f4 and we support stm32h7, we have kinetis and we support cypress MCUs. We support on-board a number of smart GPIO chips, overall we support quite a wide array of hardware. With all those options our goal is to provide nice user experience which means upfront investment by board designer.
For best user experience we have more than a dozen of different binaries which are all compiled from same firmware files with different configuration. This folder is all about that process.
See misc/jenkins/compile_other_versions/run.bat which is executed by build server.
See https://rusefi.com/build_server/
By definition, BOARD_NAME is a folder in firmware\config\boards
One BOARD_NAME could be producing a number of artifacts via compile_$BUNDLE_NAME.sh scripts
Work in progress: SHORT_BOARDNAME becomes BUNDLE_NAME
New board procedure once you have new folder in this boards directory
-
update gen_config.sh: add "board board" pair into 'for BOARD' iteration - this would produce new signature*.h file and new rusefi*.ini file
-
update build-firmware.yaml to get new firmware bundle on https://rusefi.com/build_server/
-
add connector pinout mapping yaml file see examples of yaml files in 'connectors' subfolders here.
See also https://github.com/rusefi/rusefi/wiki/Hardware
FAQ
Q: how do I change Primary UART pins via TS?
A: Primary UART, critical error LED pin and maybe a couple more of the most fundamental pins could NOT be chagned via TS. You would need another binary altogether - either another official binary or a custom binary.
Q: I need more info!
A: please remember about https://github.com/rusefi/rusefi/wiki/Hardware#q-this-is-all-very-cool-but-you-guys-do-not-have-a-plugplay-for-my-trabant-i-think-i-will-go-and-make-a-new-rusefi-board-just-for-my-trabant