View Single Post
Old 04-28-2021, 01:14 PM   #22
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

@bobxyz: When you were talking about PinChangeINTerrupt I was thinking you were meaning about the https://github.com/NicoHood/PinChangeInterrupt library but from your snipplet I've understood that you are talking about a different thing and you want to use directly the registers.
I've not written yet any code that uses them but I read something about and I agree with you that could be the right method to get more interrupt enabled pins. (This is the link to the article I'm talking about: https://thewanderingengineer.com/201...ge-interrupts/)
In your snipplet I saw that you have used the function digitalRead() to read the status of a single pin, digitalRead() is not too much fast and if used to read the status of many pins inside the ISR its delay could became an minor issue. Do you have already searched for a faster way? It should be possibile to read the status of a pin reading the whole port as a byte and applying on it a bitmask instead of using digitalRead().


@142 guy: I don't understand what you mean with As an example, if injectorSignal goes HIGH just after you execute "int injectorSignal = digitalRead(INPUT_PIN_ECU_INJECTORS_SIGNAL); " you won't capture the state change until the next time you run through that part of the code loop.
Did you thinked that the function injectorsSignalChange() is called from the main loop as a polling?
No, both injectorsSignalChange() and tqSignalRise() are ISRs and not normal functions.
Since injectorsSignalChange() is an ISR is impossibile that the injectors signal falls down and rises up again in less than 5Ás (or a bit more), also when engine is at idle the pulse width of the injectors is near 2000Ás.
The slownes of the function digitalRead() is a limit in measuring very short pulses width with high precision but I don't think that is this my main problem to solve.
Infact I've better re-analyzed the Tq signal recordings I took two weeks ago with my oscilloscope and I found another issue.
I was thinking that the pulse of Tq and injectors were always in sync, in other words I was thinking that:
- at t0 injectors pulse signal falls down
- at t0 + approx 130Ás Tq pulse signal rises up
- at t0 + 130Ás + 20Ás...250Ás Tq pulse signal falls down
- at t0 + 2000Ás...8000Ás injectors pulse rises up
This is wrong because when the rpm and load increases the sync of the two signals change and there are situations when there is an overlapping.
For example the injectors signal could fall down when the Tq was yet high and according to my code the call to injectorsSignalChange() will be delayed until tqSignalRise() ends. I found also that also the sync of the Tq rise changes.
If I had more interrupt pins availabe I would never have calculated the rpms from the count of the Tq pulses instead of the rpm pulses and above all
written a busy wait inside an ISR. I did it to quickly test the performances of the optoisolator and believing that it could works, after all also the pulseIn() function do a similar thing to measure a pulse length.
This could drive to an error in the measure of the injectors pulse that could reach up to 250Ás and is not acceptable.
Pin Change Interrupts, as suggested by bobxyz, could help me to rewrite the code and to fix the problem, but I whould also to find the alternative to the digitalRead() function.


A bit off-topic: I also would like to add the the ignition advance measure, but I'm dreaming a totally different way from getting the crank signal from EZK. I believe that it could be possibile to detect the TDC by analyzing the AMM signal oscillations and I want to take more scope measures using AC coupling to better study it.
May be that it will drive me to dead-end road, but a few years ago I made a similar experiment using my oscilloscope and I was able to measure the ignition advance with a reasonable precision looking the current oscillations produced by the alternator that can show you when the piston reaches TDC and BDC (when there is the piston stroke the current produced is a bit more since the cranck shaft is accelerating, on the opposite, when the piston is compressing the crankshaft slow down a bit)
Also the air mass is not a continuosus flux but if you are able to zoom the signal just enough you can see that is alternating, in sync with the pistons that suck the air. One of the most difficult thing in doing this is that the amplitude of the signal changes not only with the load but also with the rpms as you have seen I'm a novice in designing electronic circuits.
apollokid is offline   Reply With Quote