In the meantime, I have made some progress towards MAP averaging within a specific angle window - hopefully this value would be much better than just a single MAP reading at a random point of time.
I have implemented tiny oscilloscope feature for the dev console, here are the first screen shots - these pictures show a full camshaft revolution worth of MAP data on idle. Even with noise you can see four spikes for four intake phases:
Perhaps worth mention, this is an opensource mixed scope software. http://dangerousprototypes.com/2011/07/10/sump-logic-analyzer-with-2-scope-channels/ it's handy as it also can decode SPI streams and such in side by side with the analog signals. Perhaps you can make your serial stream match the SUMP data packets such the decoding features of SUMP can be used.
@ has implemented some code to blink out OBD-II codes with the MIL light
Over the weekend I have made some progress on getting the main trigger/fuel/spark logic closer to 'how it should be' then to 'it's one huge hack but it works'
Also some improvements to the dev console - it now shows the time & relative angle at the mouse cursor position, it's now much easier to see what's going on and when is stuff happening.
I've added a new command for fuel testing on a bench - I am not totally happy with the timing precision of the current implementation, but this is a good enough first version.
r1017 - totally innocent change if you ask me - has broken Makefile compilation - everything does compile but the firmware just would not run.
Lovely. Upgrading to the current gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-24) did not help. Changing -O2 to -O1 did help... You cannot trust anyone.
puff wrote:could you explain what it is and how to use it?
Not much - we can read data from Neo-6M GPS modules, but we have not yet implemented any features which would use this data. It's an open question how exactly we would use it, I just think that it's cool to have it and it could be useful. First feature will be logging GPS speed together with all the information we are currently logging.
Needless to say this would require a fresh version of the devconsole.
Unfortunately this does not go smooth - sending command to the simulator is unstable, I have reported an issue to ChibiOS. I suspect something is wrong with their win32 port
Things are looking up for the simulator - Chibi has found the issue https://sourceforge.net/p/chibios/bugs/468/ - we will have reliable communication with windows version of the firmware. Also I have learned that linux version of the simulator would be also possible
C++ is real now - I've just got some C++ code mixed into our C code, and it works! I am not planning to do anything crazy, just want objects instead of structures and methods to make the code more readable.
Still need to merge this prototype into the primary development branch, that's probably tomorrow.
I understand that those that make it to C# / mono often like C# /mono for a variety of reasons, mostly it takes care of lots of work the developer typically needs to keep track of. Is C# /mono physically an option for this project? If so would it be worth while to consider for this project?
kb1gtt wrote:Is C# /mono physically an option for this project?
No, at this point C# and Java are out of the question - both these languages have the concept of dynamic memory allocation and Garbage_collection and this would kill precise timing
I know this might looks weird - why the heck would I need a simulator? That's for my piece of mind: a piece of special software is firing this simulator every time I commit code into SVN, and if simulator reactions have changed unexpectedly I am getting an email alert. This way I can fix bugs right when they appear and not three weeks later.
The simulator proves to be really useful - made some good progress with the firmware today, using simulator as a quick way to test the changes without the hassle of flashing/connecting the real controller.
Another cool feature of the soft simulator is that a developer doesn't need anything more than a PC to developer the firmware. It's a very cool option.
Fixed two ignition bugs in the last 24 hours - one while playing with the real car, another while playing with the simulator.
Making progress on output events scheduling - getting closer to eliminating manual injection/ignition configuration coding.
Now with some engines running we know rusEfi is kind of functional. Now I want to focus on improving output scheduling precision and performance, so that we can actually rev these engines safely.
