Improvements (#99)
* add note about discovery boards, and linux * DFU link * fix link names, add link to home * extra lines * brackets * fix link * very shoddy dev tips * code quotes * added link * added link * newlines * newlines * more improvement
This commit is contained in:
David Holdeman
GitHub
parent
39dd46f309
commit
37477e8c3a
|
|
@ -0,0 +1,92 @@
|
|||
### Getting Data to and from Tunerstudio
|
||||
|
||||
Definition of configuration data structure:
|
||||
integration/rusefi_config.txt
|
||||
This file has more information in its comment header.
|
||||
|
||||
Definition of the Tunerstudio configuration interface, gauges, and indicators
|
||||
tunerstudio/rusefi.input
|
||||
|
||||
Contains the enum with values to be output to Tunerstudio.
|
||||
console/binary/tunerstudio_outputs.h
|
||||
|
||||
See the [documentation main page](https://rusefi.com/docs/html/#config) for more information and tips on how to use these files.
|
||||
|
||||
Q: Do new outputs need to be added at the end and their space taken out of mainUnusedEnd[]?
|
||||
A: Look at the diff. if the diff is not crazy you are doing it right. If the diff touches too much stuff you are doing it wrong.
|
||||
In practice I have found this to mean that they should be added to the end.
|
||||
Usually the tradition is not to move other existing fields for no reason. Starting an array at an odd offset is also unusual.
|
||||
Let's work around existing fields without shifting them please.
|
||||
There may be unused "padding" variables spread throughout that can be replaced with your new variables, particularly of the 'bit' type, as we do bit packing for better communication efficiency.
|
||||
|
||||
Check config/boards/kinetis/config/controllers/algo/engine_configuration_generated_structures.h after generating to ensure the total size is 20000
|
||||
|
||||
Tunerstudio output channels are handled completely manually, as opposed to settings where offsets are managed automatically by the gen_config scripts.
|
||||
Adding channels to tunerstudio_outputs.h induces offsets which are kept track of in comments next to each channel.
|
||||
In the OutputChannels section of rusefi.input, these values are 3rd token in the configuration string.
|
||||
|
||||
http://www.tunerstudio.com/index.php/manuals/63-changing-gauge-limits
|
||||
|
||||
in order to use CONFIG macro you need EXTERN_CONFIG and include engine_configuration.h
|
||||
|
||||
### GPIO
|
||||
|
||||
[efiSetPadMode()](https://rusefi.com/docs/html/io__pins_8cpp.html#a4bd76c1e23f3126d720239707dbcbaaf)
|
||||
[efiReadPin()](https://rusefi.com/docs/html/io__pins_8cpp.html#a6df3ebf4716cb8e2a42f45f6fa7e3afe)
|
||||
|
||||
efiSetPadMode calls brain_pin_markUsed
|
||||
If you call efiSetPadMode, you need to call brain_pin_markUnused if the config changes.
|
||||
There are several places this could be done, depending on the purpose of your code.
|
||||
applyNewHardwareSettings() in hw_layer/hardware.cpp
|
||||
incrementGlobalConfigurationVersion() in controllers/algo/engine_configuration.cpp
|
||||
unregisterPins() in controllers/system/efi_gpio.cpp
|
||||
|
||||
### General how-do-I-do-this
|
||||
|
||||
most stuff is initiated in engine_controller.cpp
|
||||
|
||||
There are useful enums in firmware/controllers/algo/rusefi_enums.h
|
||||
Acquaint yourself with them to avoid re-inventing them.
|
||||
|
||||
[Timers](https://rusefi.com/docs/html/#sec_timers)
|
||||
|
||||
efitick_t is cheaper than efitimems_t.
|
||||
getTimeNowNt() will get you the current time in units of efitick_t.
|
||||
MS2NT(...) will convert from milliseconds to efitick_t.
|
||||
|
||||
For logging, use [scheduleMsg()](https://rusefi.com/docs/html/loggingcentral_8h.html#a0da1724993b78c84530d681d254b59a2)
|
||||
sharedLogger is a generally available logger object, which is passed (by reference) to scheduleMsg.
|
||||
|
||||
### Discovery pinout with usable pins
|
||||
|
||||
https://docs.google.com/spreadsheets/d/1pnU3Migcc7JEezvpVt3TcVCbuE5dIXXwrYFGZI97GNM/edit#gid=0
|
||||
|
||||
### Debugging
|
||||
|
||||
http://www.openocd.org/doc/html/GDB-and-OpenOCD.html
|
||||
|
||||
Using openocd and gdb on STM32F407G-DISC1 requires modifying stm32f4discovery.cfg to source stmlink-v2-1.cfg
|
||||
|
||||
```
|
||||
openocd -f /usr/share/openocd/scripts/board/stm32f4discovery1.cfg
|
||||
arm-none-eabi-gdb rusefi.elf
|
||||
tar ext :3333
|
||||
mon reset halt
|
||||
<set breakpoints>
|
||||
load
|
||||
c
|
||||
```
|
||||
|
||||
### Errors
|
||||
|
||||
`cannot move location counter backwards (from 0000000020020018 to 0000000020020000)`
|
||||
This means that rusEFI is out of memory.
|
||||
Down at the end of engine_controller.cpp there's a dummy array that keeps track of how much free space we have. You can shrink that to give your code room to fit.
|
||||
|
||||
### Testing
|
||||
|
||||
All tests are run in one instance, but each test gets its own EngineTestHelper, which calls commonInitEngineController, so your objects need to gracefully handle being initiated multiple times.
|
||||
For CONFIG(...) to work in tests, you need a DECLARE_ENGINE_PTR; in the class declaration, then an INJECT_ENGINE_REFERENCE(&myObject), at some point during init.
|
||||
Time doesn't pass in tests. If you need time to pass, you have to do it manually.
|
||||
Example:
|
||||
`timeNowUs += MS2US(15);`
|
||||
|
|
@ -15,6 +15,8 @@ Testing coverage open tickets: https://github.com/rusefi/rusefi/labels/automated
|
|||
|
||||
All open tickets: https://github.com/rusefi/rusefi/issues
|
||||
|
||||
See [Try It](Try It) for how to work on rusEfi code with zero or minimal hardware.
|
||||
See [Try It](Try-It) for how to work on rusEfi code with zero or minimal hardware.
|
||||
|
||||
[Click here for a Q&A on source code.](http://rusefi.com/forum/viewtopic.php?f=5&t=10)
|
||||
|
||||
[Some random tips](Dev-Tips)
|
||||
|
|
|
|||
|
|
@ -7,4 +7,9 @@ DFU is Device Firmware Update mode - that's a way to update firmware via the sam
|
|||
*Manual DFU* mode is when you hold "Program" button while powering your rusEFI in order to switch it into DFU mode. This mode is
|
||||
used to program brand new stm32 chips which do not have a running version of rusEFI firmware.
|
||||
|
||||
[HOWTO DFU video](https://www.youtube.com/watch?v=VdvXYgv_acg)
|
||||
[HOWTO DFU video](https://www.youtube.com/watch?v=VdvXYgv_acg)
|
||||
|
||||
On a STM32F4 Discovery, entering DFU mode requires putting a jumper between the pins VDD and BOOT0, then powering or resetting the board.
|
||||
|
||||
If you're running Linux, the tool `dfu-util` works great for uploading DFUs.
|
||||
example: `dfu-util -a 0 -D rusefi.dfu`
|
||||
|
|
|
|||
|
|
@ -1,13 +1,16 @@
|
|||
|
||||
# How can I help rusEFI?
|
||||
|
||||
The weakest point of rusEFI is lack of samples and success stories. As of Aug 2020, we _really_ need vehicle threads on the forum. [HOWTO-contribute-success-stories](HOWTO-contribute-success-stories) We also do not have much user feedback in general - we do not know how many rusEFI units are used regularly and what are users looking for (we know about launch control).
|
||||
The weakest point of rusEFI is lack of samples and success stories. As of Aug 2020, we _really_ need vehicle threads on the forum.
|
||||
|
||||
Another weak point of rusEFI is documentation. If you've played with rusEfi for any time chances are you have help improve the documentation.
|
||||
[HOWTO-contribute-to-documentation](HOWTO-contribute-to-documentation)
|
||||
[HOWTO contribute success stories](HOWTO-contribute-success-stories)
|
||||
|
||||
We also do not have much user feedback in general - we do not know how many rusEFI units are used regularly and what are users looking for (we know about launch control).
|
||||
|
||||
Another weak point of rusEFI is documentation. If you've played with rusEfi for any time chances are you have help [improve the documentation.](HOWTO-contribute-to-documentation)
|
||||
|
||||
|
||||
We are also extremely short on software developers. [HOWTO-contribute-to-firmware](HOWTO-contribute-to-firmware)
|
||||
We are also extremely short on software developers. [HOWTO contribute to firmware](HOWTO-contribute-to-firmware)
|
||||
|
||||
|
||||
## Please do good and do not do bad
|
||||
|
|
@ -24,4 +27,4 @@ There are two ways to help financially:
|
|||
|
||||
One-time or monthly https://tinyurl.com/paypal-rusefi
|
||||
|
||||
One-time or monthly [rusEfi Patreon](https://www.patreon.com/rusefi)
|
||||
One-time or monthly [rusEfi Patreon](https://www.patreon.com/rusefi)
|
||||
|
|
|
|||
|
|
@ -31,6 +31,8 @@
|
|||
|
||||
* After you have programmed the chip, you should click '''Target --> Disconnect''' and hit the '''black button''' on the discovery board '''to reset''' the firmware. After you hit the reset button, you should expect all four LEDs to blink once and then you should see just the '''blue LED blinking'''. If all is good, proceed to the Dev Console below.
|
||||
|
||||
* Another way to upload firmware is using a [DFU file](HOWTO-DFU)
|
||||
|
||||
## rusEfi Console
|
||||
|
||||
[Console](Console)
|
||||
|
|
|
|||
2
Home.md
2
Home.md
|
|
@ -46,6 +46,8 @@ So you are thinking of doing an engine control project. You have stopped by the
|
|||
|
||||
[Get Tuning](Get-tuning-with-TunerStudio-and-your-rusEFI)
|
||||
|
||||
[Help Out](HOWTO-help-rusEFI)
|
||||
|
||||
## rusEFI in action!
|
||||
|
||||
[Engines running rusEFI](List-of-engines-running-rusEfi)
|
||||
|
|
|
|||
|
|
@ -11,4 +11,7 @@ rusEFI console in headless mode is known to work on Raspberry 3.
|
|||
Wifi password is in ``/etc/network/interfaces`` file
|
||||
```
|
||||
sudo dhclient wlan0
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
https://www.hackster.io/mexmarv/iot-raspberry-pi-wifi-headless-setup-6be0de
|
||||
|
|
|
|||
Loading…
Reference in New Issue