I may miss something in the code but I think there is an error in the sendBit and recvBit methods. Both disable interrupts at the beginning of the method but they re-enable interrupts only if there's an error during the transfer of the bit. I first thought that interrupts will be enabled later on but at least in the searchIDTree() method there's no re-activation. I don't know if this triggers some error later but I think this should be corrected anyway.
pylon:
What I'm still don't understand: In the emulated picture we see almost one byte in standard speed (I guess it's 0x3C too), but in the chip version we see only overdrive speed. Is that because you didn't scanned at the same part of the communication or does the real chip really not have any standard speed communication? Have recorded once the original reset command?
According to the DS2431 datasheet the chip supports standard speed but I'm having a tough time capturing the very start of communication (Logicport is still new to me). It does appear however that the real chip will stay in overdrive and stay that way while the emulated one seems to drop in and out...
pylon:
I may miss something in the code but I think there is an error in the sendBit and recvBit methods. Both disable interrupts at the beginning of the method but they re-enable interrupts only if there's an error during the transfer of the bit. I first thought that interrupts will be enabled later on but at least in the searchIDTree() method there's no re-activation. I don't know if this triggers some error later but I think this should be corrected anyway.
Hmm certainly sounds like something I'll have to take a look at. When the emulator is in overdrive I see all the same commands and signals as the real chip when its preparing for a read. That would leave the send functions being the culprit because there's only 1's being sent...
It does appear however that the real chip will stay in overdrive and stay that way while the emulated one seems to drop in and out...
My guess is that the emulation has an error and falls back to a reset state, it might even actually reset the device.
That would leave the send functions being the culprit because there's only 1's being sent...
Not really because sending 1s means for the slave doing nothing. The short pulses you see are from the master, the slave simply pulls the signal down if it wants to send a 0, but does nothing in the case it wants to send a 1.
I would start inserting commands into the library code that changes the state of some other pins depending in which state the code is. That way you can see that "debugging output" in the logic analyzer.