Some Arduino commands like EntradaPulsos1 = pulseIn(IO2_SERVO_IN_1, HIGH, 50000); doesn't work properly

[Escrich]

Dear all, I’m writing you because after latest actualizations, some Arduino commands started to work erratically, just coming to this example:
SignalOne = pulseIn(IO2_SERVO_IN_1, HIGH, 50000); //input pulsewidth 1# with 50 mS of timeout
With this sentence i read a servo control signal, and the result it’s something between 1000 and 2000 uSeconds, I’m using this kind of line since more than five years ago, and it’s really accurate, but actually, when you expect 1000, the reading shows around 700, when you expect 1500, (and you are sure you have it), you are getting around 1100, this is just for your information, i was tried connecting or disconnecting millis() and so.
Regards:
JMEC

[Escrich]

Tested deeply on Attiny85

[SpenceKonde]

This is fixed in github version, will be in next release.

The cause of the pulseIn issues was that:
Core was missing the precompiled assembly snippet used to fix dependence on compiler version (the newer compiler version is actually worse at optimizing the loop in question), but pulseIn() depends on the execution time of a very tight loop.
The assembly snippet, as it happens, didn't honor timeout value if no pulse was detected - it would expire in 11/16ths of the specified time. This was busted everywhere - though it is also fixed in ATTinyCore now.

[SpenceKonde]

(duplicate of #384) - still really confused by why three people reported it within the past 2 weeks, when it had been broken for quite a while without anyone noticing.

[Escrich]

Thanks a lot for your fast and valuable answer, I’ll wait to have the good working version, you are doing a very good job, and your job is helping me a lot on my projects, thanks for your time and your effort. Regards from Spain: Jose M. Escrich Enviado desde mi iPhone

…

El 24 feb 2020, a las 20:55, Spence Konde (aka Dr. Azzy) ***@***.***> escribió:  This is fixed in github version, will be in next release. The cause of the pulseIn issues was that: Core was missing the precompiled assembly snippet used to fix dependence on compiler version (the newer compiler version is actually worse at optimizing the loop in question), but pulseIn() depends on the execution time of a very tight loop. The assembly snippet, as it happens, didn't honor timeout value if no pulse was detected - it would expire in 11/16ths of the specified time. This was busted everywhere - though it is also fixed in ATTinyCore now. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.