RomRaider

To add to all of this, it would be great to come up with a system that works for both 16bit and 32bit ecus. I had been talking to NSFW about realtime tuning and he had a good idea that I would like to expand on.


I think a "lookup table" similar to the SSM lookup should be put in place. Each realtime tunable table would have a specific index number (similar to ssm parameter index numbers). The lookup table would exist in ram and the first byte of the LUT would be the "individual index size" (amount of bytes per index, this would allow flexibility between 16bit and 32bit). Each index would have a byte that contains bitflags that are set/cleared to enable/disable the use of each realtime table, and then a couple bytes that point to the address at which its particular table exists in ram. Then the PC gui would determine where to place each table based on the available ram space and write the table locations to the lookup table indexes. The rom would take the table address from the lookup table based on its index (this table address would be the ram address) and then check its "index bitflag" which would determine if the RAM or ROM table is used. So realtime tuning "definitions" could be added to the ecudefs, they would simply need the lookup table start address, the available ram space for each rom, and the size of each table including x and y axis data. Then the PC software would take this definition file and use it to determine where to place tables in ram and where to write the address of each table in the lookup table. The indexes would be determined beforehand and would be the same between 32bit and 16bit, the same way SSM indexes are.

An example lookup table would look like this in a 16bit rom.




The bit flag byte could also contain a bit flag that determines if the system is "ready". The rom would never have to copy tables to ram, the PC software could do this and then set the "ready bit".


Then we would just have to agree on what "index number" each table would be, some may not be used in some roms but those indexes would still exist in the rom they just wouldn't be used.





What do you guys think about this system?

That sounds like a much neater solution, and avoiding the writing of the realtime tables into Ram each time would eliminate a lot of headache (never mind room for corruption). As you say, a table index would have to be agreed on and codified like the P logger parameters, I think it would be quite easy to get agreement on the key tables initially required like MAF and timing.

Great idea!

I like it. To integrate it with what I've been working on, it would only require writing a definition and canning the logic that enables RAM tables.

I think it can be done as simple as changing the ROM ID (or adding some other kind of identification string), and having a corresponding definition to that ID which contains the available tables, RAM addresses, and 'ready/enable' flag addresses.

time machine works, we are back 5+ years

viewtopic.php?f=3&t=901&hilit=realtime&start=60

I was actually planning on adding an index "id" to every <table> tag in the editor definition when I define an Editor database, like I did for the Logger database I created.

Hi Tiny - was the 16bit patch ever released? Looks like there's a lot of good information that could prevent having to reinvent the wheel in there.

I also think this should be moved to its own thread with a "32 bit realtime tuning" heading.

never got released because there was no supporting gui application. 95% of the code for the 16bit ecu is in that thread. Coding for the ecu is the "easy" part, building a foolproof gui app isnt

What would be the best way to go about the PC software end of things?

Independent C++/C# app or integrated with RomRaider?