It would be interesting if that fixes the problem.
As of now I don't think anyone knows why there is a different behaviour between different esp32 builds.
The changes don't make sense to me in the context of one build working and the next one not but if it works, that'd be great :D

Edit: Ah I see that complete module will be new to esp32 as your 2nd PR removes the esp32 specific onewire library. That makes more sense to me, hopefully it'll work reliable.

The changes don't make sense to me in the context of one build working and the next one not.

That might be true when looking at it from one perspective. But if in between ESP32 switched from unicore to dual-core mode, that could well change some subtle details on its runtime behavior.

Also, Espressif Systems are still working on mitigating silicon bugs on their rev.1 and rev.2 revisions through compiler workarounds. Some bad cache coherency issues have been fixed lately, which also can contribute to different timing behavior. All that will also depend on which compiler/toolchain has been used for creating the builds.

In that light, depending on how solid the timing of mp_hal_delay_us_fast actually is, that adjustment could well help - or not at all ;].

your 2nd PR removes the esp32 specific onewire library

As far as I could see, esponewire.c hasn't been used at all within the ESP32 port and might have slipped in when copying files over from the ESP8266 port. So, its removal through #5289 was really just for cosmetic purposes.

Thanks for the patch.

Did you have a problem with reading onewire sensors on the esp32, and then after applying this patch it worked?

I'm really not sure this would fix anything because for these two delays they only require a minimum delay to work. So they could in principle be much longer delays and it should still work correctly.

The main use of mp_hal _delay_us_fast() is for when interrupts are disabled and it needs accurate timing, which is why this fast function was not used for the two delays here.

Did you have a problem with reading onewire sensors on the esp32, and then after applying this patch it worked?

Not quite, I just though I might have spotted something which missed to be adjusted accordingly with respect to the timing problems @kevinkk525 outlined above.

Unfortunately, we are stuck on Pycom MicroPython right now and our real problem is pycom/pycom-micropython-sigfox#356.

So, feel free to close this right away, sorry for the noise and keep up the spirit!

Not quite, I just though I might have spotted something which missed to be adjusted accordingly with respect to the timing problems

Ok, in that case I'll close this issue. If testing shows that this change fixes things then it can be reopened.