Our ECU has a 32 bit 32MHz RISC processor and our MUT protocol runs at a decent baud rate (15625) which with 8 bits, 1 start, 1 stop should theoretically support about 781 items per second, whereas the standard logging protocol runs at about 1/4 of that.

I have been looking to see where the delays are because on a fast revving car logging many items, sometimes we would want more data points, and when we read and write maps in RAM we want it to be fast.

So I have done some tests.

By rewriting the comms routines so that the request received on the ECU serial port receive interrupt is replied to immediately in the same interrupt and running at 100000 baud (the fastest it would connect without errors) you can get about 750 items logged per second - still short of theoretical for the baud rate. The engine also doesn't start when doing so, I must be keeping it too busy.

So I have made a "superlog" setup which at sensible baud rates allows 375 items to be logged per second in batches of 15 which are cached to a RAM buffer 25 times a second. So we have concurrent logging of items and we gain performance because we aren't sending a request ID for every item, just one for the whole 15.

I have also put the addresses for the items to be logged in RAM. This means that we can alter the batch of 15 items that are being logged without reflashing the ECU.

I am also revisiting the idea of DMA transfers.

Having written the PC side app I already posted, I do want to get on and release realtime patches, but I want to get it right - running as fast as it can with reliability.

Tephra and I are also carefully sharing info so that patches will work together. He has some nice things in the pipeline.

Volunteers to help with complex ECU patches?

 

I'm pretty limited on free time these days, but what do you need from a volunteer?

 

The patches are quite complex, and whilst I am very happy to share asm code, it needs to have the variables changed to the correct locations for individual ECUs and then the code patched in a few different places in the ROM. It is too much for me to do. Tephra's previous patches obviously took a lot of work, but the realtime stuff is considerably more complex in the routines it slots into in the ECU.

Do I spend my time writing a how to to modify the ECU (which would be very time consuming because it is so complex) or do I just make 88590015 and leave it at that?

 

John,

Maybe set up a poll to see which are desired/required and find out where to turn your attentions.

Even leave it to tephra to do the modifications based on romid popularity to allow him to add to his suspension fund.

having said that I still haven't contributed to that, having not got the nlts working, but am happy enough with the other two to make my donation - I am ashamed of myself. sorry dave!

 

It wouldnt hurt to get it debugged in one ECU (x15, if you havent already done so) and then as time permits work on other versions.

And JC I definitely think some donations are in order. Live tuning on the stock ECU is pretty exciting

 

Big time!!!
post up your paypal addy and if people want the patches they can donate for your time,
that means everyone can have access to this brilliant mod and you get paid for your time,

 

If you can give me a few pointers, I can help port it to other ROMs. PM me if this is what you'd like to do.

 

Update: now logging at 680 items per sec (approx 4 x MUT) whilst retaining MUT and OBD compatibility and the engine runs well.

I think that will do. So now I will turn my attention back to the PC side app to get the batch logging of 15 items running well, and speed up the reading of the realtime maps. I will then work on a test version of 88590015 and a PC app to go with it.

Thanks mrfred. I think I should use Tephra 88590015 as the base for my mods, unless you want to supply one along these lines with any of your boost adjustments in? Once I have a test 88590015 I'll be sure to send it to you.

 

I didn't mean to give you one of my ROMs. I was thinking more along the lines of doing the grunt work of adapting to the other ROMs (presumably tephra's patched ROMs) using info that you might give me. Since you were asking for help, just trying to figure out what it is that I or anyone can do to help. Still not clear to me what kind of assistance you were thinking of.

 

I was thinking that if I got things started by giving you a modified 88590015 with a list of the changes made you would be able to test it and then help with patches for other ROMs? The depth of the changes will be quite tricky for you to follow from say my 88570008 to then expect you to transfer this easily to 88590015 I think.

I was thinking of putting fast logging, map switching, live map editing high octane fuel and timing (along with Tephra mods) in the first try.

 

So glad to see you guys doing this stuff so we can all enjoy our vehicles to the fullest. MAD PROPS.

Keep up the fantastic f'n work guys. Cheers.

 

ok, that's about what I was thinking. I can definitely imagine that it would be a challenge to adapt it to different ROMs. Since I'm more of a newb than you or tephra, I'm sure I'll need a few pointers to get started.

 

Hey John,

As long as we don't use the same address space and memory locations then our mods can co-exist. I have actually been planing to release v4 very soon, which adds a few tuning knobs to the current code as well as some other features.

Since 88590015 is the most popular do you want me to get that out the door so you can "patch over" it?

I will be interested to see how your map switching compares to mine hehehe

Cheers
D.

 

Maybe we should start dividing up memory space

 

LOL, I have nearly finished an 88590015 patch, just having a little issue with illegal branches. I am using ffff8100-ffff8500 and 49000-49200.