new $EE tuning thing!

[Performance SS]

Steveo - Sent some beer$ your way. Thanks again!

[steveo]

Steveo - Sent some beer$ your way. Thanks again!

i got that, really appreciate it!

let me know if you need any tech support or whatever

[steveo]

i reflowed the board that was having trouble in the oven, and resoldered both ecms with some extra care and attention. now both are functioning, so eehack has dual test benches.

now we're cooking with fire. i can try all the crazy stuff i wanted to with the flash write routine.

[steveo]

WARNING!

4.2 beta 4 has a serious bug with flash write and manual transmissons, it's possible to leave your ECM in a working state but it won't flash anymore. i've pulled that beta. new one will be out today.

[steveo]

new beta, please help me test it to death, i think this is ready for regular use

http://fbodytech.com/eehack-2/beta/

edit: set the 'cpu throttle' slider about halfway on the settings page before you flash, though, just in case.

[fbody_Brian]

i reflowed the board that was having trouble in the oven, and resoldered both ecms with some extra care and attention. now both are functioning, so eehack has dual test benches.

now we're cooking with fire. i can try all the crazy stuff i wanted to with the flash write routine.

Good to hear it!

[steveo]

played around quite a bit with the flash write routine. next release will be great.

first off i managed to get my 'sleep timer' (which is what generates the necessary delays in between events) to be a bit more stable. i tested it on a really crappy windows xp machine loaded full of garbage software, which tended to fail quite often, and adjusted a few delay timers until it started working correctly. this may help stabilize things as flashing does tend to get 'buggy' on some older machines. we don't want that. one problem with the sleep timer, is that's where i process the UI events. i actually have to wrap these ui events in their own timer so we know how long they take and can incorporate it into the following serial delays, which is a bit of a pain in the ass. yes, eehack is a monolithic one thread program. this is a poor design decision i made to make development a bit faster and easier to debug, and i stand by it.

i also increased the priority of eehack's singular thread during flashing... that seems to help too; although it's still a good idea not to run a bunch of background garbage when you're flashing, it might prevent the odd hiccup from bricking your ecm.

now for performance; serial transaction overhead is a big, big deal in flash writing to this ecm.

theoretically this chip can be flashed in several seconds, but transmitting so much data over a slow serial link is a major bottleneck.

so, armed with an ecm that wont permanently die if i screw up, i played around with write request sizes.... i've been writing 128 byte blocks per request as this is both the tech tool and tunercat's default, i assumed there must be a reason for it in the code or whatever.

turns out...NOPE!! i think those programs simply use it for convenience as the total write size is divisible by 128, so they can make a simple loop. so lazy.

as you might realize, 173 bytes is the maximum total request size, since 0xFF-0x52(the calculation for the message length byte. since there's there are 12 bytes of write overhead per chunk, so theoretically maximum should be 160, but for some reason, it becomes randomly unstable at that chunk size, perhaps it's a timing thing, but 158 bytes seems to be a magic number. writes of 158 bytes always succeed. assuming the entire bin is being written (which it rarely is) that's over 1KB of overhead saved from the larger write size, plus the extra delays necessary between operations.

this new parameter gets us near 5000bps of raw flash write throughput, considering a half duplex 8192 baud link, that's pretty damn good!

of course less writes mean less opportunity for a failed flash, too.

another thing i changed is the checksum verification -- i took it right out. it never worked correctly anyways, then i realized, it's redundant to even verify it.

when the ECM's main program is 'restarted' (necessary to exit the development upload mode thing and go back to normal anyways), the ECM's main program verifies the checksum on its own! we were getting it twice. so now what it does is make sure the ECM is alive after a flash by sending mode 8 and mode 1 requests (if it's not alive, it throws an error), then polls it for error codes. if there's a checksum/PROM error code, it tells you about it.

i added some more stuff too, such as a write speed display, and it now displays the progress of the 'erase' operation, which is quite a long operation... that always bugged me as it was kinda scary to watch during development since sometimes it looked like it was frozen..

edit: brian, i would like your help testing it with linux; i did remove that special linux post-delay as i think it might not be necessary now...

[steveo]

Benchmark time for flash write on a windows 7 quad core machine

LT1EDIT: 4:09
TunerCat winflash: 3:18
madtuner MTFlash: 3:22
eehack: 2:22

eehack erase and re-flash of e-side only (with just a few timing or VE table changes): 53 seconds

[fbody_Brian]

edit: brian, i would like your help testing it with linux; i did remove that special linux post-delay as i think it might not be necessary now...

Definitely not a problem!

Benchmark time for flash write on a windows 7 quad core machine

LT1EDIT: 4:09
TunerCat winflash: 3:18
madtuner MTFlash: 3:22
eehack: 2:22

eehack erase and re-flash of e-side only (with just a few timing or VE table changes): 53 seconds

That's about what I got the last time I timed it, averaged about 50 seconds just e-side on my old hp laptop.