Many updates => consult display freez
Moderator: Matt
Many updates => consult display freez
ok, i select a part of a fuel map for example, while i have the sonsult panel open, and i hit the key "+" few times, i recive a message that the update que is full i hit the ok button and afther that the consult windows is does not receive any new data, i close it i open it again, same thing noconsult data available, i disconect from type 1 board (by hiting the consult button in the upper right corner of teh screen, i conect back to the type 1 board, and open teh consult window, and now data is updated and keep beeing updated in the consult window)
- Attachments
-
- consult window.jpg
- (29.58 KiB) Downloaded 2134 times
* Got CA18DET Love
There is currently an 'enhancement' CR open for this issue
What happens is that USB transfers data in packets. for fast upload it is best to transfer larger sized chunks. However some ECUs such as the early model Z31 only have 256 bytes of RAM in the HD6802.... Of which there is only 16 bytes free for NIStune to use for its consult buffering. So our data transfer rate is limited by this lower end ECU
Currently when more than 1 cell is selected, 16 x buffers (of 16 bytes) are uploaded for a single update
Hold a +/- key down and suddenly you are pushing 256 byte updates over the interface for each key press
Obviously i need to make this more efficient, similar to serial consult where I queue the memory addresses to be changed and then only ovewrite those cells which have not been uploaded yet, and only the update buffer groups that need to be updated
What happens is that holding the +/- on the USB version will fill up the current buffer queue and then it becomes too much for the comms interface to handle and it disconnects
For now do the changes gradually or one cell at a time. It is a known issue and probably needs about a day of design, code and testing to properly implement it to make it work better
What happens is that USB transfers data in packets. for fast upload it is best to transfer larger sized chunks. However some ECUs such as the early model Z31 only have 256 bytes of RAM in the HD6802.... Of which there is only 16 bytes free for NIStune to use for its consult buffering. So our data transfer rate is limited by this lower end ECU
Currently when more than 1 cell is selected, 16 x buffers (of 16 bytes) are uploaded for a single update
Hold a +/- key down and suddenly you are pushing 256 byte updates over the interface for each key press
Obviously i need to make this more efficient, similar to serial consult where I queue the memory addresses to be changed and then only ovewrite those cells which have not been uploaded yet, and only the update buffer groups that need to be updated
What happens is that holding the +/- on the USB version will fill up the current buffer queue and then it becomes too much for the comms interface to handle and it disconnects
For now do the changes gradually or one cell at a time. It is a known issue and probably needs about a day of design, code and testing to properly implement it to make it work better
i'm not taliking about, the upload beeing slow or the size of the que, the problem is that you hit + for example many times, without receiving the mesage that the que is full, in this case data is beeing sent to the ecu and during the data send the consult display is not updated but as soon as data transfer is finished the consult display start to receive updates again,
until now no problem - the problem is that afther you receive the message that the transfer que is full, the consult display will not receive updates anymore (you have to disconect and reconect from the consult in order to make the display receive updates again)
until now no problem - the problem is that afther you receive the message that the transfer que is full, the consult display will not receive updates anymore (you have to disconect and reconect from the consult in order to make the display receive updates again)
* Got CA18DET Love
Whilst updates are being performed, requests for streaming are halted until updates are complete (so the updates can be finished)
ie Updates are higher priority than streaming data
Optimising the queuing of information will speed up the updates, so you will get streaming back sooner
If the consult queue is full then it should continue to receive streaming. It is probably in an internal error state. I'll raise a CR for this and look into it
ie Updates are higher priority than streaming data
Optimising the queuing of information will speed up the updates, so you will get streaming back sooner
If the consult queue is full then it should continue to receive streaming. It is probably in an internal error state. I'll raise a CR for this and look into it