There's any way to handle One protocol without delay?

[E_Blue]

I have a routine that handles 2 one wire devices by a separate pins.
The first one can read temperature devices and iButton IDs. The second one only read temperature devices.

The problem is that the One Wire protocol has some change in the data line that must be wait it until some change or timeout occur.

The whole reset signal took around 736mS.

I'm checking sensor number 1 every 1 second and sensor number 2 every 1 minute.

I'm disabling interrupts during those delays but I don't like that approach.
A delay_us(500) is a lot of time for a microcontroller that is handling USB, and 2 UARTs at 115.2Kbps

What can I do to let the interrupt keep running and don't loose One Wire data?
_________________
Electric Blue

[temtronic]

When I used the DS18B20 (? been awhile...) temperature sensors I had the external RTC module send an interrupt every second ( I called it the 'heartbeat' ).
So every second main() would call 'readdstempsensor()'. That function got the LAST data from the sensor,then told sensor to read and store (or whatever the command is called ). yeah it's been almost a decade and grey cells are aging....

The reality is temperature doesn't vary fast so reading the LAST value is OK.

main() ..
do nothing

on RTC interrupt..set flag..

main() now does
read old temp sensor 1 data
read old temp sensor 2 data
read old temp sensor 3 data
read old temp sensor 4 data
do control stuff
update LCD module
send data to PC in CSV format
....

Each sensor was on it's own I/O pin, parasite mode.

While it does make for a larger program( 1 driver per pin ), it was a quick and easy way to get around 'nasty' several devices on one pin.

I eventually worked out code to 'scan for new devices' then confirm they were there,got around the oops, wire open/shorted problem.

[gaugeguy]

You can poll interrupt flags during non-critical parts of the data stream or you can offload the one-wire timing to an I2C-to-1wire IC.

[E_Blue]

In my case I must to check if the sensor still there because they are optional, so the can be connected or not and even disconnected with the device running.

I have a routine that calls the ReadTemp() routine but that routine calls another routines like ResetOneWire1(),WriteOneWire1() and ReadOneWire1() and those routines has delays inside that are critical to read the 1-Wire devices properly.

@gaugeguy
I can't add a new IC to the PCB, the device is in production state and I think that my boss will not be happy with the idea to change the design.

I can stop UART1 because use the RTS but on UART2 I have a GPS module and doesn't have any RTS line.
_________________
Electric Blue

[gaugeguy]

You don't need interrupts blocked for 500us for the 1-wire timing. During the reset pulse 480us pulse is the minimum, so extra delays in this are OK. The critical time during the reset pulse is only about 70us.
When sending or reading data, the critical time is during the bit transfer, so again only about 80us. A delay between bits is OK. If you look at the timing diagram the delay between bits is 1us minimum and infinity maximum.
Having interrupts disabled for 80us will not result in any lost data at 115k.

[E_Blue]

I changed a the a code a bit. Would you check if there's some flaw?

The code for the second sensor is pretty the same but with another pin.

[gaugeguy]

I don't think you are understanding the reset pulse diagram.
The bus must be kept low a minimum of 480us (with no maximum)
Once the bus goes high, the slave will respond with a presence pulse starting somewhere from 15us to 60us. The presence pulse from the slave can last from 60us - 240us.
If you wait 70us after the reset pulse is released you can just test the line then.
If a device is present the line will be low. If no device is present the line will be high. There is no need to keep looping and looking for the moment it changes.

[E_Blue]

Ok. Thanks, I will make some changes to my code.
_________________
Electric Blue