_0x87mode_read:packetCount
this is the number of packets with a length of 44 that must be read, if you make it equal to zero then the maximum size of 79 messages will be read

read worked --> branch stockDMAdev
_0x87mode_write, where is the payload?

 

<duplicate post>

 

If you send a write:
packetCnt = 0x00
direction = 0x05
addr4B = 0x0001C000

The ECU responds with 0x100 (256) packets covering 0x0001C000-0x0001EBFF.

I updated the asm to change the response packet for read (0x05): 05<currentByteCnt1B>05 ... 0D
The original read (0x01) still responds with a single response: 050001 ... 0D

For a write request the payload is in the request packet:

 

no, ecu replies with one message in which all 0x51 packets are added

there is a nuance, I modified 90550001 rom (there is all the code with an offset of 0x1000), but this is hardly the reason, well, reading it takes me a couple of three seconds for all maps

 

write dont worked

 

There is only one start of message set at the beginning of a read. Many packets get coalesced into a single message by the OP2. The built-in DMA logging works the same way.

I fixed a bug with writes in the asm where it would send multiple acks. A test write and read to 0xFFFF9C00 works for me.



I didn't add the acknowledgement packet for writes. That's how the existing code works.

 

Well, yes, I didn’t notice the responsiveness.
now the recording is working
my client is now fully functional according to your way of reading the record

a little boring:
you do not correctly imagine reading and writing by means of op20, you do not need it continuously poll, op20 does it for you.
For example:
The ECU sends a packet of bytes, op20 receives it and writes it to the internal memory, when you call PassThruReadMsgs you read this packet from the memory of op20 into the memory of your application, and in op20 this data block will be considered destroyed for simplicity.
Further:
Let's say the ECU sends several packets and 20 bytes one by one, for op20 it will be one message and will be buffered one by one and when PassThruReadMsgs is called it will be read as one message.
Now the sweetest thing: PassThruReadMsgs receives a pointer to memory in your application into which it will copy data from op20, moreover, the structure of this buffer is an ARRAY OF STRUCTURES PASSTHRU_MSG.

PASSTHRU_MSG date [desired number of messages that can be read at a time]


Therefore, if ECU sends you many packets and does not pause P3_MIN between them, you will read them all at once in one message.
That's it, you don't need a timer.

 

response on write packet is over 900ms..
you fix it, but it would not be bad to remove this packet altogether, or at least shorten it
it still takes about 90ms to read at 62,500

 

you can check 80700010? On 0x8214 many diff with 88590015 and 90550001 (88590015 is the same as 90550001)

 

I tried to remove the ACK for writes but a second write doesn't work. Will look into it when I have more time.

Is 80700010 an automatic? Looks like the same function in 88590015:0x9026 is 80700010:0x805C. There are different stack locations, state bits used, and the compiler moved other things around. The changes will have to be ported by someone who can test it.

 

i can test it, 80700010 very popular rom, I'm not very good at revers rom

​​​​​​​
it's just an important point, proofreading this answer takes a significant amount of time (90ms) and makes it difficult for group editing of rom

 

many more branches than 90550001 or 88590015

 

for each request of the form 0x8x, there is a response 0x0x,
and in the case of subfunctions, the answer should be of the form
0x0x 0x0y where x is the function number and y is the subfunction number
(in the case of direct read / write) in this case responses can be easily parsed and sent
to the appropriate handlers

 

The CAS interrrupt gets called every 1.25ms. The main loop has a delay which only allows it to execute at most every 10ms (8x CAS interrupts). The command decoder, handler for 100 hz logging, and reads/writes are in the main loop. And it looks like there is also a minimum required 20ms delay between the end of one command and the start of the next. Normally this protected by the client waiting for the response, but since the response is removed I can see there being 20ms + (2 to 3 mainloop iterations to decodeCmd/performWrite, cleanup) * 10ms = ~50ms of necessary delay. As long as the read and write is handled in the mainloop a single command won't get much faster. It may be possible to add a EOW (End of Write) bit in the write packet so the state machine stays live but data would need to be double buffered and it gets complicated. You would still need to add pauses to slow it down to every 10-20ms. There are other solutions:

(1) Add new read/write commands that setup DMAC so raw data can be transferred to/from an address after the initial command is sent. The write will generate a response and only after receiving the response the client can start sending data.

This should get close to the full 62500 data rate for large data (minus serial overheads). Small reads/writes will still be slow since 1 command can only be done every ~90-100 ms. But when sending lots of data in one command it will be at a high rate.

(2) Custom decoder in the serial data ready interrupt which sets up DMAC for these new read/write commands.

This should have low latency and high data rate. Not sure if it can even be made to work, though. Something has to keep the mainloop DMA state machine from triggering. The way this works for OBD/MUT transfers is the 5baud init causes it to get disabled. When the ECU boots up it sets up the receive buffer DMA for 0x33 bytes which is why commands can be sent @ 62500 baud with no setup work. Would require changes to not setup the DMA right away. This seems too complicated.

(3) DMAC complete interrupt to decode new commands and setup DMAC for data or hand off other commands to existing main loop state machine.

Right now the main loop polls on idle DMA transfer counts. The interrupt is not used. This would also have low latency and high rate like (2). This seems like the best approach since the DMAC completion interrupt can immediately manage the RCV/SND fifos and state before the serial interrupt or mainloop do their work.

I'll have to think about it more as there are problems with all 3 approaches. Not sure if or when something can be coded and tested. It's not a simple thing to change.

 

This is how it works livemap jcsbanks https://www.evolutionm.net/forums/ec...ap-source.html

word_FFFF7D14 -FFFF7D20 ?