rusefi-1/firmware
David Holdeman 664ed149f4
Workflow to write the date, once a day (#1504)
* Add date workflow

* add files

* use VCS_DATE in engine controller

* initial values

* switched to using one file

* moved to controllers

* Add comment and fix cron entry

* add pragma once

* Add more comments
2020-06-17 12:59:57 -04:00
..
ChibiOS@1a2c5967dc Update chibios (#1364) 2020-04-25 16:32:32 -04:00
ChibiOS-Contrib@8f7c2d187b Revert "Fresh generated - auto" 2020-04-18 19:11:47 -04:00
bootloader binary logging (#1443) 2020-05-17 15:56:37 -04:00
config un-hiding full pinout 2020-06-17 12:54:56 -04:00
console REO progress - binary logs 2020-06-14 15:43:54 -04:00
controllers Workflow to write the date, once a day (#1504) 2020-06-17 12:59:57 -04:00
development connecting time units 2020-05-26 01:08:21 -04:00
docs
ext
ext_algo
hw_layer BMW E90 Kombi (#1494) 2020-06-14 16:59:43 -04:00
iar_egt better file name 2020-05-25 13:02:05 -04:00
init better file name 2020-05-25 13:02:05 -04:00
integration TS project: hide all invalid entries #1505 2020-06-17 12:53:37 -04:00
tunerstudio un-hiding full pinout 2020-06-17 12:54:56 -04:00
util reducing constant dupliation 2020-05-31 13:40:48 -04:00
.cproject
.gitattributes is this the problem? 2020-06-16 14:19:40 -04:00
.gitignore XML export progress 2020-05-20 01:24:26 -04:00
.project
Doxyfile
DoxygenLayout.xml
Makefile Makefile clean-up 2020-05-25 13:42:55 -04:00
build-notes.txt
clean.bat
clean_build.bat
clean_compile_two_versions.bat
compile.bat
compile_and_program.bat
cov_config.bat
cov_run.bat
coverity.yml
dump.bat
dump_iar.bat
dump_release.bat
egt2can.cpp
exception.txt
flash.bat
flash_dfu.bat
flash_dfu.sh
flash_erase407.bat
flash_erase767.bat
flash_openocd407.bat
flash_openocd767.bat
flash_reboot_dfu.bat command line switch to DFU 2020-05-08 21:11:11 -04:00
flash_release.bat
gen_config.bat Now we are back to original behavior, great step forward :) 2020-06-16 14:28:46 -04:00
gen_config.conf Fix #1492 redux (#1496) 2020-06-16 12:50:22 -04:00
gen_config.sh progress 2020-06-16 12:56:01 -04:00
gen_config_board.bat converted gen_config_board.bat (#1498) 2020-06-16 15:48:09 -04:00
gen_config_board.sh fixing stuff by reducing the gap between Windows and Linux scripts 2020-06-16 14:12:27 -04:00
gen_enum_to_string.bat progress 2020-05-20 09:16:26 -04:00
gen_enum_to_string.sh
gen_firing_order.bat
gen_fsio_example.bat
gen_live_documentation.bat Remove old thermistor implementation (#1458) 2020-05-28 17:51:33 -04:00
gen_ptrace_enums.bat
gen_system_fsio.bat
gen_trigger_images.bat :) 2020-05-14 20:53:47 -04:00
generate_docs.bat
generate_memory_usage_report.bat
global.h nope, unit tests did not just fix themselves 2020-06-17 08:42:37 -04:00
globalaccess.h
kill_for_coverity.c
license.txt
main.cpp
main_hardfault.c
make4.bat
os_access.h code style 2020-04-01 21:32:21 -04:00
readme.md
reboot_ecu.bat
run_hw_test.bat
rusefi.cpp a few unneeded properties 2020-06-13 22:46:10 -04:00
rusefi.h
rusefi.mk
rusefi_rules.mk
svnversion.h poke 2020-06-11 21:17:53 -04:00
update_version.bat

readme.md

Doxygen

Q&A on source code

See also ../unit_tests

This directory contains the source code for the RusEFI firmware.

The ideal is that typical end users should be able to use pre-built firmware. They should not need to modify or even rebuild from the source code for basic use, but building from the source code provides the opportunity for optimization, supporting unexpected engine configurations, and specialized enhancements.

TL;DR

make PROJECT_BOARD=microrusefi PROJECT_CPU=ARCH_STM32F4

Environment

Rebuilding from source code requires this firmware, a modern C/C++ compiler for embedded ARM systems, and a platform that supports 'make' based builds.

While many compilers have the potential to work, we suggest using the official ARM version of GCC available at launchpad.net.

Linux and MacOS systems should have the software development tools, primarily 'make', pre-installed or readily installed. MS-Windows requires selecting and installing a Unix-compatible system environment.

Note that the developers are volunteers, with varied motivations. These motivations often include using leading-edge language and build system concepts, requiring recent versions of tools. Should you encounter build problems, review the latest version of this document.

Expected Future Changes

The firmware build is moving toward a system that separates board features from processor features. This will require specifying both the board type and specific processor.

The existing system evolved based on the original RusEFI boards. Those used 'STM32 Discovery' development boards plugged into base boards that held the ECU-specific chips. That approach resulted in hard-coded assumption about pin assignments, and associations of hardware with a specific processor variant. That legacy is slowly being cleaned up, but is still evident in some settings and limitations.