thanks steveo, yeah i try to make it easier for the guys jumping into it
I'd rather just link the write ups rather than post it elsewhere as i update it frequently so having it in multiple places would make it difficult to keep it all up to date and accurate
decipha @ EFIDynoTuning
i've started writing my datastream layout discovery engine. it's getting there in theory i just have to work some design issues out...
the idea is we have a memory topology definition of the entire t-side and e-side, with variables defaulting to RAW. i think i'll build my own definition format, it'll be pretty simple. the memory definition itself will be 'load once on startup' and not be runtime configurable.
i'm still a bit torn on how i want to do the calculations. i think a math engine like tunerpro has would introduce too much overhead. i might force people to use a set of hard-coded defined formulas, and if a new formula is required, you can ask.
there will be a concept of 'view levels' built right into the memory map, so we can default the ui to 'view essentials' instead of 'view everything', you wont see the 'raw' stuff unless you ask for it. view levels will be useable in graphing and stuff too so you can graph any raw memory address you want.
it'll do a discovery of the t-side on initial connect (and e-side if available) grabbing the entire datastream configuration, then build a datastream_topology which is basically just a list of pointers to definitions of memory addresses in that particular message. the raw datastream configuration will be stored in the log file.
each loaded datalog will have its own independant datastream topology (but share a memory layout definition). this increases log loading overhead slightly but not really runtime overhead.
you will be able to choose any combination of messages and vary their polling frequency a bit. having multiple selectable datastreams is a bit tricky for the dashboard and analyzer and all that, it'll just require me to rethink a bit of stuff.
consider when you have a message without RPM in it, and that one is polled often. when there's no RPM data, do you just display the last known RPM? or do you display zero? what if zero is a potentially normal state for that data, that means you're displaying false data. do you just grey the control out and make it blank? what if RPM is only polled every 30 seconds? does it just flash the rpm then turn grey again?... definitely this is the part that requires the most thought, it'll probably take more work than the discovery engine itself.
i'll need a new datalog format, so the next version probably won't load old logs.
4.4 release: http://fbodytech.com/eehack-4-4-release/
after some testing and trial runs i've decided datastream config discovery isn't the best option for eehack at this time. its' just too much work for almost no real gain.
im going to stick with fairly statically defined data but start allowing multiple messages, and continue along with my original 'passive patching' instead. there will be two datastream definitions, patched and not patched.
i think message zero is sacred and should kinda be left alone as to not break compatibility with any other logs. my accelerated logging message works well and should be left alone too.
i really want that eside message. just one message with all cool parameters we can find.
the next version of eehack will just have a goal of reading, log, and play back all t-side bytes on the 'extended' tab.
im thinking i don't really want or need an external configuration file for the datastream right now, and i'll just build it internally.
all available bytes, undefined or not, will be accessible as raw data for research; but people will have to approach me to add new definitions with names or equations (or recompile themselves).
this does discourage people from modifying datastream config themselves but i think if we just use eehack's passive patching to have a stock datastream and an optimal modified one we'll be better off.
any objections?
To me it only makes sense to use an external definition file that can be updated independently of the program code.
of course i see that being useful for a parser designed to deal with more than one ECM, but i'm having trouble finding a real-world use case for it for this particular program.
Posting Permissions
Reply With Quote
Bookmarks