I think I would prefer if you went this route. It's probably a bit slower, but a bit safer in the long run. Honestly a good chunk of bugs occur with "optimistic" coding which assumes that everything is always going to work and when it doesn't.....

You should only need to do this when setting up to post the maps into the ECU? Or are you expecting to have to do this on a more regular basis?

 

There is writing maps to the ECU, and also setting up tables for logging. Neither should be terribly repetitive.

Each row of logging is called from a MUT request the way I have it. It does introduce a small delay, but it is fast enough. The convenience of going through MUT is nice as the connection stuff is well understood and reliable. If I used a MUT instruction to switch entirely to DMA transfers I'd need a load of stuff in the ECU code about how to handle disconnections/timeouts/engine off during logging etc.

For the knock color coding I think I will make a little table that is loaded from a color map after all, then I can just look up the RGB for each value of knock. I do think I'll need to store the maximum knock level in another table and use that to paint the ignition map colors for knock tracing.

I also wondered rather than multithreading, I might process the logging to file and display update (not every log of course) whilst I'm waiting for data to come back from the ECU. So I could send the request ID, do something else and only when that is finished check to see if the ECU has replied. I'd have at least a millisecond if the ECU is sending 64 bytes at 62500 baud.

 

After I found a bug where I was attempting to read a word variable as a long, I now have done a successful DMA write to the ECU. Ignition map now takes less than 0.5 sec to write, it can go quicker just that I write the bytes one at a time on the first test, and the FTDI chip has a 1ms delay on each operation (by design). If I get the 399 bytes into the FTDI write buffer first and send that it should only take 70ms including the 5ms wait I put after sending the E6 request ID.

Next phase is to make the DMA read/write operations configurable without reflashing the ECU. This will allow completely flexible logging and reading/writing at will of any address range in the entire memory space of the ECU, with the user option to do indirect or direct reads (ie you can point to any MUT table we want and read the addresses it points to, or we can just read a block of memory).

 

John - I would like to help you with this - but do not know how. I do not have the patched ROM that you are using - and I do not know how to patch mine. I am finished (temporarily) with the pocket pc FTDI logger - as a dashboard + logger seems to be workng fine so far.
So looking for some challenges

 

Thanks. I'm just in the middle of overhauling everything I'd done so far to convert it to DMA. What I am running right now is a hybrid between shoving information through MUT requests one at a time, and block reads/writes using DMA.

You can help right now by discussing what you think of the command set below that I've just come up with, as an idea to standardize high speed DMA logging and realtime mapping:

DMA logging via MUT (E0) 32 bytes should be good compromise between speed and amount of info - some could be 2 byte
DMA Write MUT table (E1) (this would write the addresses that would be logged - each ECU is different - addresses can be harvested from the original MUT table)
Select ROM maps (E2) (default at power up or after reflash as there is a check for valid map headers in RAM)
Select RAM maps [plus copy from ROM if RAM is empty] (E3)
DMA Read fuel map (E4)
DMA Write fuel map (E5)
DMA Read ignition map (E6)
DMA Write ignition map (E7)

The only thing the PC app then needs to know is the dimensions of the fuel and timing maps. So the emphasis would change from a PC app that peeks and pokes ECU memory to one that uses a cross-ECU standardized protocol for the new features. The ECU code would have the above E0-E7 instructions hard coded when it is patched.

Thoughts/questions?

 

Seems that everything is there - do you thing that there will not be a need for a standalone copy command ROM to RAM?

 

I think we would benefit from one actually.

It is whether to go command based or keep it peek/poke style. It is difficult to decide...

If we did peek/poke with then other maps could be made realtime just by messing about in Ecuflash rather than needing patching... we could even make the PC do the copying of ROM to RAM.

This way our commands could be:
E0 aa bb cc dd xx yy [d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 etc] = DMA read indirect
E1 aa bb cc dd xx yy [d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 etc] = DMA read direct
E2 aa bb cc dd xx yy [d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 etc] = DMA write direct

Where aa bb cc dd is the address in the ECU to start from and xx yy is the number of bytes and d0 d1 d2 etc is the data.

Indirect is the method we use when logging where it indirects to the data through a MUT table for logging.

Direct is just reading or writing blocks of data such as for realtime mapping.

Subarus use a very slow SSM protocol that is more like the peek/poke method.

Power FCs use a load of commands to do all their comms. It is much faster but does run at 57600 baud vs 4800 baud SSM.

 

The aa bb cc dd xx yy style seems to be more flexible - less ROM patching. Do you think these will be much slower than the hardcoded commands?
We can use these "addressed" commands just to write those cells that have been actually modified - and not write the whole table .

 

I always wondered about just writing the changes, and also about a checksum.

Originally it was taking 7 seconds to write the ignition map. Now it is a hundred times faster at 70ms so we can happily keep it writing the whole lot on command, and possibly put in a read so we can have a read-write-verify cycle.

We will not notice a performance difference either way - we are just trading code between the PC and the ECU - I'm getting to the point where I'm easy writing either. The instruction packet to peek or poke will be sent by DMA anyway - Ex, 5ms delay to allow the ECU to process the MUT request, 1ms for the packet of 6 bytes aa bb cc dd xx yy. 32 bytes of logging, approx 300 bytes for fuel map, 399-420 bytes for ignition map.

 

I see - so the speed should not be an issue when working with PC.

 

just a technical question - how long are the the RAM area values stored after the ignition is switched off? The ECU is continuously powered (even when everything is being switched off) - so until the battery is disconnected - the RAM values should remain - am I right?

 

RAM values remain unless the ECU is unplugged, battery disconnected, Ecuflash reads/writes the flash memory.

Some RAM areas containing ECU variables are wiped by the ECU, the unused areas we are using are not.

 

I would vote for the peek/poke method. This way if there was another table that we wanted to view/change real time it would be a simple software change and be a lot more flexible.

If you wanted to change boost then you need the size of the map(Row x Column), starting position in memory and the conversion and it could be generated on the fly.

It does have a potential to be dangerous but I think worth the risk.

 

I think you're right. Last night I wrote some asm to use three request IDs - one to log, one to read a block, one to write a block.

The command block is request ID followed by 6 bytes (read by DMA) - 4 for the address, 2 for the length. This then sets up a second DMA transfer of the required type to transfer the data.

Not tested it yet, but I should be able to get it working.

---

I also wondered again about how to do the map switching. Presently I use the ECU's own map switching variable, but only some tables use this (mainly the 3d ones, with the except of MIVEC). Other approaches would be to always read the address of the maps we're interested in from RAM, then we can change this pointer to go wherever we want it to. Potentially you could have dynamic loading/unloading of various maps in and out of RAM, but it would make the PC app more complex!

Tephra uses RAM variables to do his map switching rather than using the ECU's original method. Advantages of both.

Perhaps if I concentrate on the comms for read/write first and let the interested parties comment meantime what they want.

 

I have it working sending a request ID followed by the 6 byte command block I mentioned in the last post (4 bytes address, 2 bytes length).

So we can read and write any address and specify the length.

We can also read indirectly through logging table(s) which contains pointers to the addresses we want to log (like the "MUT table") at any address, and of course we can change the contents and lengths of these logging table(s) if we place them in RAM. So we could log one batch of data frequently, and then another batch less frequently.

I have an issue to resolve where the logging sometimes stops unexpectedly since I changed to this setup where I have two DMA operations one after the other. I need to work out why, whether that be an interrupt at the wrong time, data collision etc.