Page 1 of 1
Q&A on source code
Posted: Wed Sep 25, 2013 12:58 pm
by AndreyB
I guess one of the most fundamental ideas of this project is to have a very readable code. Click
here for info on how to compile the code.
Source code reference
About console output
ChibiOS/RT role
Working with time
What about the injectors already!?
Working with Timers
Doxygen Reference
TunerStudio integration
Unit tests
Persistent Configuration
https://rusefi.com/docs/html/
General folder structure
config/system: ChibiOS configuration
config: rusEFI configuration
console, console_util: files relayed to serial protocol PC communication
controllers: the main logic lives here, that should be the most interesting folder!
hw_layer: helper files related to lower level work with hardware: ADC, software PWM, inputs, outputs...
util: some general utility files
Everything begins in
main() method of
main.c where hardware layer and engine controller are initialized.
Sensors, including shaft position sensors, are initialized in
initHardware- the most interesting part of which is
initInputCapture where we setup an IRQ callback. Actual engine control located inside the
controllers folder:
onShaftSignal is the method where all the magic happens.
onShaftSignal is invoked as part of the position sensors IRQ handling and it controls the engine by scheduling outputs using
OutputSignal infrastructure.
Re: general Q&A on source code
Posted: Thu Oct 24, 2013 11:10 pm
by AndreyB
About console output
rusEfi has a plain text based human readable console accessible either over serial-over-usb or via the USART unit, usually via a USB TTL module. Click
here for an overview of the build-in commands.
Currently there are two approaches for serial console text output: the simpler one which sends out data directly, and the buffered one which puts data into an intermediate buffer which would be processed later by a dedicated thread.
The plaint "print()" approach is good if you are part of the main method, for instance while you are initializing everything: this case you do not have to worry about performance and you do not have to worry about concurrent access to the console hardware from multiple threads. See
print.c
The buffered approach implemented in
datalogging.c is more complex: you have to allocate a buffer for each thread/each module, you have to initialize the buffer and then you have to explicitly "commit" the message into the output buffer. All this fuzz allows you to safely output messages in a concurrent manner and be able to output messages from the IRQ handlers without any performance concurs.
Ticket #5: looks like print.c could be thrown away and replaced by ChibiOS os/various/chprintf.c. Looks like print.c is more or less a copy paste of some version of chprintf.c anyway. Be sure to make sure float type works with this printf - I recall there were some issues at some point, something about stack alignment.
Ticket #4: this could be improved - these two logging approaches should be more unified. I guess buffered console should be implemented as ChibiOS buffered stream - BaseSequentialStream, so that c
Re: general Q&A on source code
Posted: Thu Oct 24, 2013 11:38 pm
by AndreyB
ChibiOS/RT role
On the one hand,
ChibiOS/RT helps a lot. On the other hand, rusEFI could have theoretically happened without ChibiOS/RT - there is no fundamental dependency on this or any rtos. Still, I strongly believe that rusEFI is much better with ChibiOS than without it.
Roles of ChibiOS:
- nicer peripheral API. Just compare SPI interface
http://chibios.sourceforge.net/html/spi_8c.html we are using with SPI implementation we were supposed to implement manually
https://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/firmware/chibios/os/hal/platforms/STM32/SPIv1/spi_lld.c have we chosen to work with the hardware directly
- threads and chThdSleep() are nice to have. Buffered output implementation would have been much more complicated without threads
- serial-over-USB implementation
- chprintf implementation
- much higher chance of porting to some other platform when we outgrow stm32f4 in 2018
As you see, there is no fundamental ChibiOS dependency. We can still work with the hardware absolutely directly and ChibiOS would not even notice. It's just that I do not see much need in working with the hardware directly. ChibiOS is not perfect, but it is really good
One of the few scenarios in which we would need to go around ChibiOS and work with hardware directly would be software PWM - more info on that in
http://www.rusefi.com/forum/viewtopic.php?f=5&t=2 This is just a plan now - for the purposes of Phase0 chThdSleep based scheduling is good enough.
Re: general Q&A on source code
Posted: Thu Oct 24, 2013 11:55 pm
by AndreyB
Working with time
Current version of ChibiOS/RT is tick-based. Our
chconf.h specified
#define CH_FREQUENCY 100000 so we have 100 system ticks, systicks every millisecond.
chTimeNow()
Returns the number of system ticks since the board initialization.
overflowDiff
It is worth mentioning that at 100K ticks per second, a four-byte integer would overflow in a matter of hours. In order to address this in a unified manner, we should use this macros while calculation the time gap between two points in time. TODO: write actual implementation of this macros
currentTimeMillis()
Returns the number of milliseconds since the board initialization. TODO: rename for more consistent naming?
chTimeNowSeconds()
Returns the number of seconds since the board initialization.
chThdSleepMilliseconds()
Delays the invoking thread for the specified number of milliseconds.
TICKS_IN_MS
Number of system ticks in one milliseconds, CH_FREQUENCY / 1000.
onEveny10Milliseconds
This method of
engine_controller.c is invoked 100 times per second, some small tasks like status LEDs are handled there.
Examples:
systime_t now = chTimeNow();
int wasNotRunningRecently = overflowDiff(now, timeAtNotRunning) < 60 * CH_FREQUENCY;
This code sets
wasNotRunningRecently to true if
timeAtNotRunning was less than a minute ago.
Re: general Q&A on source code
Posted: Fri Oct 25, 2013 2:15 am
by AndreyB
What about the injectors already!?
Updated: Feb 2015
Positions sensors generate input capture interrupts. Right within the handler we go through all the
ShaftPositionListener listeners, including the one defined in
main_trigger_callback.cpp, Within this listener, we do some quick math on when the output pin should be turned on and for how long, and invoke
scheduleOutput(OutputSignal *signal, int delay, int dwell) method.
Current implementation of scheduleOutput consists of one thread per each of the OutputSignal. First a timer is alarmed for the duration of the 'delay' and then the thread of the particular OutputSignal is awakened so that it can turn the pin hot, sleep for the dwell time and turn it off.
Currently scheduleTask callbacks are handled by a single hardware 1MHz timer and a linked list of all pending tasks. Each time a new task is inserted, we locate the pending task which would be executed first and re-set the 1MHz timer callback for that time.
Re: general Q&A on source code
Posted: Sun Oct 27, 2013 4:32 pm
by AndreyB
Working with timers
In order to get a timer, first you need to declare a variable of type 'VirtualTimer':
VirtualTimer myTimer;
Each alarm call back is set individually - so, if you want a periodic timer you should re-set the timer withing every callback.
In order to setup alarm you should
chVTSetAny(&myTimer, _10_MILLISECONDS, &callBackMethodName, 0);
where _10_MILLISECONDS is the time till the alarm and 0 is the optional callback parameter.
chVTSetAny is a helper method which simplifies ChibiOS API a little bit.
More on timers in ChibiOS:
http://www.chibios.org/dokuwiki/doku.php?id=chibios:kb:timing
Re: Q&A on source code
Posted: Thu Dec 19, 2013 9:38 pm
by AndreyB
Doxygen reference
We have an online reference.
It is still less then perfect, but we are doing what we can. Feel free to ask questions or, even better, email us patches with more doxygen comments for the source code
Re: Q&A on source code
Posted: Thu Jan 30, 2014 3:23 am
by AndreyB
TunerStudio integration
Tuner studio configuration layer consists of
rusefi.ini which is needed to create a project which would run based on
engine_configuration.h which defines the configuration and
tunerstudio_configuration.h which controls the gauges.
see also:
tachometer_ts
Re: Q&A on source code
Posted: Sat Mar 15, 2014 10:59 pm
by AndreyB
Q: Looks like there are some changes to ChibiOS source code?
A: Yes, there are a couple of changes. These are all to improve debugging - __FILE__ & __LINE__ is added into chDbgPanic macros, current thread name added into stack overflow panic message. You can compile rusEfi with unchanged ChibiOS source codes if you un-define EFI_CUSTOM_PANIC_METHOD macros
When I get some free time, I should really figure out how to get this __FILE__ & __LINE__ into the main ChibiOS branch. I think there was something about this in 3.0
Re: Q&A on source code
Posted: Sat Mar 15, 2014 11:06 pm
by AndreyB
Q: Is there a way to print debug messages from interrupt handlers?
A: Sure there is! Since rusEfi is just a bunch of interrupt handlers, obviously we need a way to print debug messages from any context. This is implemented in
datalogging.c
* The idea is that each interrupt handler would have it's own logging buffer. You can add
* stuff into this buffer without any locking since it's you own buffer, and once you get
* the whole message you invoke the scheduleLogging() method which appends your local content
* into the global logging buffer, from which it is later dispatched to the console by our
* main console thread.
Re: Q&A on source code
Posted: Sat Apr 26, 2014 1:05 am
by AndreyB
Q: Is there any way to do firmware development without (yet) buying the actual hardware? Some sort of ECU simulator?
A: I really suggest you get just the stm32f4disovery board - it's just $15. The firmware has a build-in trigger signal simulator, so with one or two jumper wires you would be able to convince the firmware that there is some like in your crank sensor and the whole thing would be alive. Out dev console has a build-in logic analyzer so you would see both the simulated signal and outputs right away.
Technically there is another way: you can compile most of the firmware code into a win32 executable - see rusefi_simulator.exe @
http://rusefi.com/build_server/ - and you would be able to connect to it with the same dev console. This is a less preferable way because that's only 80% of the code and some minor kinds could be different between arm and win32, so that only works to a certain extent,
Re: Q&A on source code
Posted: Wed May 14, 2014 12:41 am
by UnaClocker
russian wrote:Q: Is there any way to do firmware development without (yet) buying the actual hardware? Some sort of ECU simulator?
A: I really suggest you get just the stm32f4disovery board - it's just $15.
Q: I see Frankenstein has a USB serial adapter on it. Will I be able to communicate with the ECU without that particular port?
Q: Where can I find instructions on flashing the firmware onto the discovery board?
Re: Q&A on source code
Posted: Wed May 14, 2014 1:14 am
by AndreyB
UnaClocker wrote:Q: I see Frankenstein has a USB serial adapter on it. Will I be able to communicate with the ECU without that particular port?
http://rusefi.com/forum/viewtopic.php?f=4&t=359&p=4189#p4189
UnaClocker wrote:
Q: Where can I find instructions on flashing the firmware onto the discovery board?
http://rusefi.com/wiki/index.php?title=Manual:Software:User/en &
http://rusefi.com/forum/viewtopic.php?f=5&t=283
Re: Q&A on source code
Posted: Thu May 22, 2014 2:17 pm
by AndreyB
Q: memory block CCM? Address 0x10000000? What is this about?
A: stm32f407 has 192Kb of RAM. Funny thing is that the 192Kb consists of two pieces
Code: Select all
flash : org = 0x08000000, len = 1M
ram : org = 0x20000000, len = 128k
ccmram : org = 0x10000000, len = 64k
The main 'ram' block starts at 0x20000000 and it's 128k. There is also the secondary 'CCM' block which is 64k.
There are some limitations on the secondary CCM block like for instance DMA does not work with CCM
Since we currently have a lot of debugging data structures like wave_chart, analog_chart and performance histograms, we do not fit into the 128K thus we are sometimes using the CCM block.
Re: Q&A on source code
Posted: Sat May 24, 2014 12:32 pm
by puff
datasheet stm32f4xx:
The 64-Kbyte CCM (core coupled memory) data RAM is not part of the bus matrix (see
Figure 1: System architecture). It can be accessed only through the CPU.
doesn't this mean it can't be flashed and has nothing to do with the firmware?
Re: Q&A on source code
Posted: Sun May 25, 2014 2:29 am
by AndreyB
All I know is that yes, it is weird. From the firmware stand-point, there is no data initialization for CCM fields - I believe the whole range is zero by default. Indeed you cannot flash into it.
Q&A on source code
Posted: Wed Sep 24, 2014 4:59 pm
by jengeltx
"Description Resource Path Location Type
no return statement in function returning non-void [-Wreturn-type] main.c /ARMCM4-STM32F407-DISCOVERY line 164 C/C++ Problem"
This is the only warning (no errors) I get from compiling RusEFI using Chibi's Eclipse. I _think_ it's because GCC assumes it is going to return to an Operating System, but I'm not really a programmer and would like to be sure. The source I started with is version: r4438
No, I haven't tried to run the code yet. If it's not a problem, is there some way to be rid of it?
TIA,
Jeff Engel
Arlington, TX
Re: Q&A on source code
Posted: Wed Sep 24, 2014 5:37 pm
by AndreyB
We can use different compilers to compile rusEfi - different versions of GCC and also other compilers like IAR. Each warning is different, I am doing what I can to avoid them but a warning is just a warning - until these are not errors we are probably fine.
By the way, the build server logs are online - one can see the latest compilation output @
http://crapcan-am.com:8080/job/rusEfi/lastBuild/console
Now another issue: there is no main.c file in rusEfi
rusEfi has main.
cpp and it's only 27 lines long. That together with
ARMCM4-STM32F407-DISCOVERY make me wonder if you have compiled something else
I've just added links to the "pre-compiled binaries" thread into both "how to compile the code" threads - for the majority of people the pre-compiled binaries would be the best option.
Re: Q&A on source code
Posted: Mon Jun 01, 2015 11:20 pm
by AndreyB
Persistent Configuration
rusEfi stores all persistent parameters in an instance of persistent_config_s structure. The definition of this structure, alongside Tuner Studio data fields mapping and dev console fields mapping, is generated by
gen_config.bat according to
rusefi_config.txt structure definition.
In order to add/change what is persisted and how, one should read & understand the comment on top of
rusefi_config.txt and then invoke
gen_config.bat
In order to make at least some changed of the structure compatible with the older version, this structure currently has some unused fields - by default, one would simply re-purpose some of the unused fields. (Those are called
unusedsomething)
In case of incompatible changed of the persistent configuration, FLASH_DATA_VERSION should be incremented and TS_FILE_VERSION/fileVersion should be updated.
Default values should be defined in
setDefaultConfiguration() method
Re: Q&A on source code
Posted: Sat Jan 09, 2016 3:29 am
by AndreyB
Time for a new diagram
Re: Q&A on source code
Posted: Tue May 23, 2017 2:33 pm
by megatroneye
Is any C/C++ standard followed as a convention? POSIX, C++11...?
And about style - anything else not listed here
http://rusefi.com/wiki/index.php?title=Development:Code_Style ?
Re: Q&A on source code
Posted: Tue May 23, 2017 3:19 pm
by AndreyB
Added mentioning of -std=c++11 to
http://rusefi.com/wiki/index.php?title=Development:Code_Style
I am not a real C/C++ developer so this part is pretty vague.
Re: Q&A on source code
Posted: Tue May 23, 2017 3:28 pm
by megatroneye
Thansk! Don't worry, I am just asking because I am becoming accustomed with the project. By the way, I am trying to write down things I think might be missing or worth mentioning for newbies like me. I will be sending them to you from time to time, if you want to.
Re: Q&A on source code
Posted: Tue May 23, 2017 3:30 pm
by AndreyB
megatroneye wrote:By the way, I am trying to write down things I think might be missing or worth mentioning for newbies like me. I will be sending them to you from time to time, if you want to.
Appreciate your interest in the project and yes, keep the notes coming!
Re: Q&A on source code
Posted: Mon Jan 28, 2019 3:34 am
by sparky
I downloaded the code and have started to take a look around. I notice some of it does not match the first post description above (that was written back in 2013). Most notably the current code is C++ versus C. I also notice that some of the key methods/classes described in the first post dont exist either.
So I am guessing there was a re-write at some point? I just want to make sure I am looking at the right code. I dont needs a guide, as it helps me learn the codebase better if I dig through it myself.
thanks
Re: Q&A on source code
Posted: Mon Jan 28, 2019 4:21 am
by AndreyB
sparky wrote: ↑Mon Jan 28, 2019 3:34 am
So I am guessing there was a re-write at some point?
Nope, it's just 5 years of refactoring
Could be easier to chat using
https://rusefi.com/forum/viewtopic.php?f=13&t=1198