Remove delays

[dunkmann00]

This fixes #39.

I tested this code on an itsybitsy m4 express and everything worked as expected. It was even returning the firmware version on the first attempt.

[ladyada]

dont remove this?

[dunkmann00]

It seems that when you issue a command to the PN532 _wait_ready is called before it is ready to respond, which results in an OSError. I tried to check in CP what error was being triggered and it was a NACK. When I removed this line it ends up only taking a few milliseconds to send the ready status. But with this line, it got stuck sleeping for half a second. And if there is no _req pin setup, the only thing that self._wakeup does is sleep for half a second, which is overkill for here.

It is also worth noting that this problem didn't present itself on older versions of CP for me. I think some of the newer performance improvements are the reason this is surfacing. _wait_ready was never called fast enough after a command to cause the OSError to be thrown like it is now. Sooo that's kind of cool lol.

[tannewt]

It seems that when you issue a command to the PN532 _wait_ready is called before it is ready to respond, which results in an OSError. I tried to check in CP what error was being triggered and it was a NACK. When I removed this line it ends up only taking a few milliseconds to send the ready status. But with this line, it got stuck sleeping for half a second. And if there is no _req pin setup, the only thing that self._wakeup does is sleep for half a second, which is overkill for here.

Why not return early from _wakeup if _req isn't available? Seems like we do want the ability to sleep and wake the device.

It is also worth noting that this problem didn't present itself on older versions of CP for me. I think some of the newer performance improvements are the reason this is surfacing. _wait_ready was never called fast enough after a command to cause the OSError to be thrown like it is now. Sooo that's kind of cool lol.

🎉 Does the OSError vary depending on whether it's asleep or waking up?

[dunkmann00]

Why not return early from _wakeup if _req isn't available? Seems like we do want the ability to sleep and wake the device.

That seems like a good idea.

🎉 Does the OSError vary depending on whether it's asleep or waking up?

It doesn't seem to matter. I'm not 100% sure, but when running one of the simple examples each time you loop through it you always get the same OSError.

I've been looking through the PN532 manual, and while I definitely am not familiar with reading this kind of thing, so I could be wrong, but I think the issue doesn't have to do with waking up. At least not the problem I was seeing.

I think waking up happens in between I2C address Write and COMMAND frame. The OSError is being thrown when we try to read in between COMMAND frame and I2C address Read + Acknowledge frame. So wouldn't calling _wakeup be unnecessary?

[tannewt]

I don't know anything about the sensor itself. Does it power down automatically or can we track when the driver shuts it down?

[dunkmann00]

In the event that we do have _req connected I think we are supposed to call it first, before any command is sent.

Here is another excerpt from the manual:

And the relevant text that follows:

• The PN532 is in Power Down mode (T_PD1),
  The host controller wants to send a frame to the PN532, and so it asserts the H_REQ line. That makes the PN532 waking up (1) and it acknowledges with P70_IRQ pin (2),
• Then before sending the command frame (3), the host controller has 2 possibilities:
  • either the host controller waits for a defined delay (twup) which guarantees in that case that the PN532 will be waken up when the I2C frame will be sent,
  • or the host controller monitors the P70_IRQ pin to check when the PN532 is woken up (with a maximum timeout of twup). This option can optimize the overall waiting time if the PN532 was not asleep; there is no need to wait the maximum wakeup time (tready < twup).

[dunkmann00]

Closing this in favor of #41.