jcsbanks

After a few bugs, I have a first test of DMA (direct memory access) working.

When MUT request E5 is called, it dumps the first 64 request IDs (00-3F) to the OBD port very quickly indeed. So we can have much quicker datalogging than presently, with the possibility of two byte data. This will improve resolution in both the accuracy and time axes and will be good for very fast logging of fast revving engines. It also forms a basis for very fast reading and writing of blocks of memory for realtime mapping. I had hit a limit with trying to speed up the MUT logging/reading/writing because the ECU needed the time I wanted to run the engine. With DMA as the name suggests the engine is quite happy running whilst the ECU peripherals are busy doing our bidding!

The programming is quite complex though, but I think it will be worth it.

I have a little bug to hunt as to why it doesn't elegantly return control to MUT after our burst of data.

MR Turco

iTrader: (16)

Ok I am going to ask a stupid question, what is MUT? Is it just the Mitsu protocol? I can assume what it denotes but what is the formal definition. I have done some assembly programming but mostly java so i understand a lot of what you are talking about I am just still trying to figure out what everything actually means. /end noobness

jcsbanks

MUT is the name of the Mitsubishi tool, we tend to refer to MUT as meaning the protocol this uses. It is quite slow (but faster than OBD), and processor intensive if you speed it up.

EvoBroMA

Turco - for the people that aren't microprocessor guru's DMA is enabled using a special memory controller separate from the CPU. Basically he's using it to read/write large amounts memory without taxing the main CPU.

MR Turco

iTrader: (16)

^^ does that require addition HW like a daughterboard?

jcsbanks

No, just a reflash.

EvoBroMA

most modern microprocessor systems (if not all) have their own DMA controller on the same motherboard. I imagine the DMA controller is basically doing very little in our ECU. i'm glad jcs is putting it to good use.

highly concurrent timestamps, make for better power and acceleration calculations, and just plain better logging resolution. i dont think we need to write more than a few cells at a time when actually using real time tuning, but uploading several maps at once would be painfully slow trying to force it through the MUT protocol.

donour

iTrader: (6)

Very cool. Remind me which ROM id you're using?

d

jcsbanks

88570008 JDM IX GSR (UK FQ model).

burgers22

I guess you are using an extended version of the PC, Live Map logger. Is there much code to be inserted in the ECU rom and is the new code relatively easy to insert in diffrent ROMs?

MB

jcsbanks

Yes, because I can easily knock up a button to say send request E5 and then catch the echo and the 64 byte reply.

Lots of code strewn around, calls to interrupts etc, stoppping the DMA and serial registers being reset etc. I'm still trying to get around the problem of closing down the DMA process gracefully and returning control to MUT without either giving a run of garbage for a while or crashing the logging altogether. The problem is that the transmit and receive lines are tied together so both the PC and the ECU get echoes of all their own transmissions. I keep the ECU busy if I let it respond to the echoes of all that it sends in the usual way! However, if I disable receive interrupts or receive altogether, then restarting it after the DMA transfer is messy, even if I check for the last byte transmitted and then clear everything to receive normal MUT again. There may be a small point I'm missing. One option is to setup read and write DMA channels at the same time. The read channel will dispose of all the echoes without having to turn off the receive or receive interrupt on the serial port. It might then return more gracefully to MUT.

None of the DMA examples you find in the chip docs give attention to this little point of the echoes from the Tx and Rx lines being tied together in the hardware of OBD. I think it will be worth it from what I've seen though.

jcsbanks

I'm pretty sure I have found the problem which I'll document here for our future reference. There is a receive counter that keeps track of where in the standard MUT receive buffer we are. Normally when a request is received the receive counter is incremented. The MUT routines process the request, and when the reply is transmitted a flag is set that tells the ECU to discard the first byte it then receives (the echo). When the echo is discarded it also resets the receive counter in readiness for the next request. None of this is happening during my DMA transmit, so when we return to MUT afterwards the original request that triggered the 64 byte DMA reply is still in the buffer, and receive counter just grows, so it triggers a 64 byte reply again LOL. No wonder the log looks funny!