Changes by last author:
Added:
|
This page is for developers, who want to improve, enhance and tune the firmware internals with using modeling techniques
---- Why? * see full operation without much soldering and risks * catch potential overflow places * the onboard JTAG, or stepbystep code execution is almost useless for firmware development. Try to put sane input vector into the WBO2 code and you will see why. Detailed logging (such as we used for WBO2) and histograms (see benchmark.c) are useful, but the input is still often harder to make by soldering than in the memory of a PC. ---- Modelling what? So we need a nice way (a prototyping space) to run * make input vector * operation * evaluation Eg. the * timing from last possible tooth (a proposed feature) seems a perfect target to layout in prototyping space. * staging injection: the condition is that "when the smaller injector set is near max %, the bigger (that can be equal in size) set joins with 1/2 of the fuel sent to each sets". Note this is better for staging than dual tables: dual tables is only ideal for asymetric intake or exhaust, not for staging or clompensating unequal flows between injectors. * I would not mind a somewhat faster eventqueue, with heap written in ASM; although step-by-step is quite OK for that. Note: we only need to model just the part we need at the moment, no need to make everything at once. ---- What are good properties to choose language? * object oriented * talk serial (eg.RS232) so it can talk to actually executing firmware * GUI functions for visualizations (plots in 2D, 3D) * syntax compatibility with firmware (not strictly needed; only C++ provides) ---- Languages candidates * JAVA (J2SDK1.4.2, suggested IDE: eclipse.org). Java3D available, and nice speed. (Marcell's choice). Disadvantage is that the very exact same syntax as firmware's cannot be used. But it might be possible to create or find a language (or tap into the GCC P-code ???) so we can generate both the firmware code and the simulation-evaluation code from same source. Note that this is not a strict requirement, manual syntax-porting a working code is only 10% compared to making the code work well. * C++ although it requires more work and attention than JAVA, no such brilliant tool as eclipse.org, there would be some advantages: with the operator overloading it could (maybe) be possible to compile the same code as in firmware: ** operator+ overloading is very convenient in our case. (think how 2 uint16_t can be added in JAVA; C++ syntax is closer to firmware code) ** preprocessor is used (although it can be used for JAVA too) ** C++ Speed is also excellent. ** compiler is harder to set up than JAVA (at least on broken OS-es) * PERL although object oriented style PERL would be suitable, I vote against it * octave (matlab) I'm concerned about it's better to use helpful libraries from a nice structured object oriented language than trying to add structure to a language like octave (although octave is quite impressive when it comes to matrix stuff) Imagine that uint8_t would be a variable that would implemented in higher bitcount (maybe floating point): it would watch overflow, make histogram statistics, etc... ---- Framework or library candidates * [Scalable Simulation Framework (SSF)] ---- JAVA - C++ combo is reasonable? C++ would run firmware operation, and JAVA would provide trigger and analysis. Now I think that it's better to do it all in JAVA, porting code that is well understood and works and tested in JAVA on a PC is relatively cheap to port to firmware, and there are advantages of an extra-clean (at many places re-done) structure (I envision too many ifdefs for when trying to compile the firmware in C++ ) OnlineCourse/Modeling/Scheduler ---- See also: |