feature discussion for Antusprom

User avatar
Jayme
Posts: 2585
Joined: Sun Mar 01, 2009 8:59 am
Location: North Coast, NSW

feature discussion for Antusprom

Post by Jayme »

Hi, I figured this would be best placed here, not cluttering up the other thread about antusprom.
I know tunerpro 5 is coming so it may not be worth the time, but I had an idea that may save a bunch of time.
when testing and changing timings etc, everytime antusprom is restarted it takes 80 or so seconds to download the bin from the ecu. what about having a funtion where upon exit, antusprom saves its current ecu memory contents to a file,then when antusprom is started, it calculates the checksum of the locally saved file, compares that against the checksum address of the ecu memory and if it is the same, just launch and use the files contents instead of reading the whole bin from the ecu.

is this a dumb idea or something worth looking at?
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: feature discussion for Antusprom

Post by antus »

Sounds good to me. It wouldnt be hard to implement either. It would go hand in hand with some kind of interface, that way it could have a checkbox for save last state or similar, and a shutdown button that makes it save and exit, and a reload button so for a fresh session it starts up immediately and you click "reload-bin" or something like that.

I can upload the work in progress version with the gui as far as I got, perhaps someone at your work fluent in VC could take a look and glue a control in somehow... Ive added a form, and been breaking out the delco code in to a library so it can be used for other tools. At the moment most the debug info is in functions that end up the library portion, but im not sure how to print back to a textbox on the main form for monitoring whats going on, similar to what you have in VL400s flashtool.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Jayme
Posts: 2585
Joined: Sun Mar 01, 2009 8:59 am
Location: North Coast, NSW

Re: feature discussion for Antusprom

Post by Jayme »

that would be great, I actually have a friend looking into it now, seeing how we can convert the console app into a form and the possiblility of changing variables at runtime though the form (only to avoid having to redownload the bin everytime I want to adjust something) but with the save option it would be no trouble to stop the thread, change the value and resart the thread without the 80 second delay. your current work in progress would help, bit of a head start :D

his first comment about the app was " I can see why its in C++". hes currently working on how to call the form variables from the main class
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: feature discussion for Antusprom

Post by antus »

Well, its actually in straight C, not C++. Never got my head around C++ objects, plain C that you can read from top to bottom seems to work easier in my head and be simpler than all these c++ constructors and destructors and things!

I'll up my work in progress tree shortly.

I think it might be useful to have different timing presets too, since what I had worked best for the FTDI usb->serials but is obviously sub-optimal for hardware serial ports.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: feature discussion for Antusprom

Post by antus »

OK, try this one:

http://ant.is-a-geek.org/antusprom/antu ... opment.zip

It isnt building. Check delcolib.cpp, the definition of readEcuMemory which contains a RichTextBox ^ definition that isnt valid. Im trying to make it possible to call the function from the gui form and pass the richtext box for it to log to (instead of calling printf and outputting to stdout).

Once how to do that is understood I'll be able to do the whole thing and it should be usable pretty quickly from that point.

Good luck :)
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Jayme
Posts: 2585
Joined: Sun Mar 01, 2009 8:59 am
Location: North Coast, NSW

Re: feature discussion for Antusprom

Post by Jayme »

ok, the reason for the inital build error with richtextbox is you need to add "using namespace System::Windows::Forms;" to delcolib.cpp as well. hes just showing me now how to pass a string to the textbox and do the stirng converisons (apparently something like logBox->Text += "sdmjfsdjf"; ) will keep you posted and send the code once its wokring.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: feature discussion for Antusprom

Post by antus »

I had no hope of figuring that out. Cheers!
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
VL400
Posts: 4991
Joined: Sun Mar 01, 2009 2:54 pm
cars: VL Calais and Toyota Landcruiser. Plus some toys :)
Location: Perth, WA
Contact:

Re: feature discussion for Antusprom

Post by VL400 »

I cant help on the VC side of things, my flashtool is all VB. My brain likes assembly and the way it flows, VB seems to fit well too!

The checksum idea is a good one, and would work with factory code however for real-time editing I have fiddled with how the checksum works in the OSE code releases. It no longer includes the calibration data (the tunable bits), just the main code base. That way you dont have to use AA in the program ID and you still get a checksum for safety.

I do have an idea that would speed the process up. In the $12 OSE release there is only 7KB out of 32KB that is calibration the rest is ALDL config, running code and blank space. Can you just pass the calibration to TunerPro?? Or does it need the entire 32kb?? Or once the calibration data is finished just send blocks of blank data at the normal transfer rate (not having to wait for the ECM to respond anymore) to TP to pad the rest out??
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: feature discussion for Antusprom

Post by antus »

just the calibration would do it, but it adds complexity. you need to know what your doing to get the right data and know that if you read the bin in to tunerpro and hit save you wont get a working file (although you wouldnt anyway on any bins with that GM last byte bug). I guess it could be worth it. Maybe could let antusprom parse the XDF file and figure out the highest and lowest calibration data locations, or even more specifically it could load just the bytes defined in the xdf. It'll be good if mangus's ALDL interface is more tolerant to slow reads and writes, then there would be no need to buffer the whole file in the first place, tunerpro could just pace itself to the ECU.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Jayme
Posts: 2585
Joined: Sun Mar 01, 2009 8:59 am
Location: North Coast, NSW

Re: feature discussion for Antusprom

Post by Jayme »

ive tried my best to understand and repeat what my work mate said to me about it. he mainly uses c#, his C is a little rusty. so anyway, to print stuff to a the richtextbox, you need to create a stringbuilder:
StringBuilder^ sb = gcnew StringBuilder();

then in replacement of your printf, you go:
//printf ("Reading 0x%04X\n", address);
sb->AppendFormat("Reading {0:X4}\n", address);
I hope I got the format correct, im not sure yet.

what that does is create a string, each time you call sb->AppendFormat, it adds to the string. every time you want to actually update the textbox you go:
logBox->Text += sb->ToString();

ive attached the delcolib.cpp, it builds now but cant do much obviously coz there is no way to call the functions yet. I havent finished doing all the stringbuilders, I just commented the rest of the printf's out to make sure it would run. im still not 100% sure that code suits our purpose, but its a start, so I figured theres not much point finishing them till its tested. oh yeah, I also changed the invalid ID reference to 0x04 just to get it to build.

im basically a glorified copy/paste function, doing what i was told by the guy who knows what hes talking about. so let me know if ive confused you :P
Attachments
delcolib.cpp
(6.55 KiB) Downloaded 448 times
Post Reply