not shure this is a bug but maybe it can be improved:
i noticed that when data is sent to the board while the engine is running, there can be felt a little bump (rev drops ~30rpm and come back)
because my "play" time was limited last night, i canot say for shure if it does this no mather what table/constant you change or it is because i changed the cels/constants that the ecu readed at that time,
at idle this is hardly noticeable, but i do not know what will happen if beeing on dyno at 6000rpm i'll want to make a little change, the hardly noticeable bump wil lstay the same or the "bump" will incrase as the rev incrase.. ?
i'll do some more test today and try to change data while it is at 2000rpm, 3000rpm.... and i'll report back
engine can feel the updates
Moderator: Matt
engine can feel the updates
* Got CA18DET Love
The NIStune firmware is injected at the start of the interrupt handler. This way we have a common place to inject our code with many different ECUs and know that the ECU will always execute from this path
I tried finding a commonly executed path outside the interrupt handler, but the earlier Nissan ECU code has no central loop (unlike later ECUs) which will gurantee execution each cycle
The aim with interrupt handlers is to get in, do minimal processing and get straight back out
However if you perform a mass of communications operations it will slow down interrupt handler processing and has some minor effect on operation of the ECU. I am aware of this, because I can hear it on the bench with the injectors clicking
When the CR for USB minimal updates is implemented the changes will be a lot smoother and minimal processing in the interrupt handler will have an improved effect on engine operation
When data is being streamed there is only one byte update each interrupt which is why you dont notice this having an effect on the engine. We used to stream all registers on one interrupt cycle (higher speed updates) but this affected operation on some ECUs such as Z31
I've done code timing measurements inside the interrupt handler to minimise NIStune impact on the ECU software when a CAS pulse is detected and the injecton/spark is calculated and triggered
I tried finding a commonly executed path outside the interrupt handler, but the earlier Nissan ECU code has no central loop (unlike later ECUs) which will gurantee execution each cycle
The aim with interrupt handlers is to get in, do minimal processing and get straight back out
However if you perform a mass of communications operations it will slow down interrupt handler processing and has some minor effect on operation of the ECU. I am aware of this, because I can hear it on the bench with the injectors clicking
When the CR for USB minimal updates is implemented the changes will be a lot smoother and minimal processing in the interrupt handler will have an improved effect on engine operation
When data is being streamed there is only one byte update each interrupt which is why you dont notice this having an effect on the engine. We used to stream all registers on one interrupt cycle (higher speed updates) but this affected operation on some ECUs such as Z31
I've done code timing measurements inside the interrupt handler to minimise NIStune impact on the ECU software when a CAS pulse is detected and the injecton/spark is calculated and triggered
The NIStune firmware is injected at the start of the interrupt handler. This way we have a common place to inject our code with many different ECUs and know that the ECU will always execute from this path
I tried finding a commonly executed path outside the interrupt handler, but the earlier Nissan ECU code has no central loop (unlike later ECUs) which will gurantee execution each cycle
The aim with interrupt handlers is to get in, do minimal processing and get straight back out
However if you perform a mass of communications operations it will slow down interrupt handler processing and has some minor effect on operation of the ECU. I am aware of this, because I can hear it on the bench with the injectors clicking
When the CR for USB minimal updates is implemented the changes will be a lot smoother and minimal processing in the interrupt handler will have an improved effect on engine operation
When data is being streamed there is only one byte update each interrupt which is why you dont notice this having an effect on the engine. We used to stream all registers on one interrupt cycle (higher speed updates) but this affected operation on some ECUs such as Z31
I've done code timing measurements inside the interrupt handler to minimise NIStune impact on the ECU software when a CAS pulse is detected and the injecton/spark is calculated and triggered
I tried finding a commonly executed path outside the interrupt handler, but the earlier Nissan ECU code has no central loop (unlike later ECUs) which will gurantee execution each cycle
The aim with interrupt handlers is to get in, do minimal processing and get straight back out
However if you perform a mass of communications operations it will slow down interrupt handler processing and has some minor effect on operation of the ECU. I am aware of this, because I can hear it on the bench with the injectors clicking
When the CR for USB minimal updates is implemented the changes will be a lot smoother and minimal processing in the interrupt handler will have an improved effect on engine operation
When data is being streamed there is only one byte update each interrupt which is why you dont notice this having an effect on the engine. We used to stream all registers on one interrupt cycle (higher speed updates) but this affected operation on some ECUs such as Z31
I've done code timing measurements inside the interrupt handler to minimise NIStune impact on the ECU software when a CAS pulse is detected and the injecton/spark is calculated and triggered
The NIStune firmware is injected at the start of the interrupt handler. This way we have a common place to inject our code with many different ECUs and know that the ECU will always execute from this path
I tried finding a commonly executed path outside the interrupt handler, but the earlier Nissan ECU code has no central loop (unlike later ECUs) which will gurantee execution each cycle
The aim with interrupt handlers is to get in, do minimal processing and get straight back out
However if you perform a mass of communications operations it will slow down interrupt handler processing and has some minor effect on operation of the ECU. I am aware of this, because I can hear it on the bench with the injectors clicking
When the CR for USB minimal updates is implemented the changes will be a lot smoother and minimal processing in the interrupt handler will have an improved effect on engine operation
When data is being streamed there is only one byte update each interrupt which is why you dont notice this having an effect on the engine. We used to stream all registers on one interrupt cycle (higher speed updates) but this affected operation on some ECUs such as Z31
I've done code timing measurements inside the interrupt handler to minimise NIStune impact on the ECU software when a CAS pulse is detected and the injecton/spark is calculated and triggered
I tried finding a commonly executed path outside the interrupt handler, but the earlier Nissan ECU code has no central loop (unlike later ECUs) which will gurantee execution each cycle
The aim with interrupt handlers is to get in, do minimal processing and get straight back out
However if you perform a mass of communications operations it will slow down interrupt handler processing and has some minor effect on operation of the ECU. I am aware of this, because I can hear it on the bench with the injectors clicking
When the CR for USB minimal updates is implemented the changes will be a lot smoother and minimal processing in the interrupt handler will have an improved effect on engine operation
When data is being streamed there is only one byte update each interrupt which is why you dont notice this having an effect on the engine. We used to stream all registers on one interrupt cycle (higher speed updates) but this affected operation on some ECUs such as Z31
I've done code timing measurements inside the interrupt handler to minimise NIStune impact on the ECU software when a CAS pulse is detected and the injecton/spark is calculated and triggered