This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
tutorials:products:rfidnfc:faqs.html [2012/07/23 18:13] ktownsend [Can I set a delay calling readPassiveTargetID() ?] |
tutorials:products:rfidnfc:faqs.html [2012/12/30 20:55] ladyada |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Frequently Asked Questions ====== | + | ====== Moved! ====== |
- | Blah blah blah | + | This tutorial has moved to [[http://learn.adafruit.com/adafruit-pn532-rfid-nfc|http://learn.adafruit.com/adafruit-pn532-rfid-nfc]] |
- | + | ||
- | ===== Can I set a delay calling readPassiveTargetID() ? ===== | + | |
- | + | ||
- | readPassiveTargetID() intentionally waits around in a blocking delay until a card enters the magnetic field. The reason for this blocking delay is to ensure a well-understood command/response flow. Once the magnetic field is activated and a read request is sent via readPassiveTargetID, you can keep sending new commands to the PN532, but the moment a card or tag enters the field, the PN532 will send a response to the initial read request, even if it's in the middle of some other response or activity. To avoid having to debug this in SW, a blocking delay was implemented to keep the command/response pattern as clear as possible. | + | |
- | + | ||
- | As a workaround to this blocking-delay limitation, an optional programmable delay was recently added to the NFC libraries to allow you to set a specific timeout after read requests. By default, the PN532 will wait forever for a card to enter the field, but specifying an optional 8-bit timeout delay will cause the read request to be aborted after the specified delay, and you can safely send new commands without worrying about mixing up response frames. | + | |
- | + | ||
- | Example Code: | + | |
- | + | ||
- | ToDo | + |