Modifications

Non. Le PN532 est conçu pour être utilisé avec des tags [http://en.wikipedia.org/wiki/ISO/IEC_14443 ISO14443], le tag Mifare Classic étant probablement le type de tag (d'usage général) le plus couramment utilisé. Pour plus d'informations sur les tags supportés, référez vous à la documentation [http://www.libnfc.org/documentation/hardware/tags/iso14443 http://www.libnfc.org/documentation/hardware/tags/iso14443] ou recherchez des informations sur la famille des tags MiFare répondant à la norme ISO1443A.

Non. Le PN532 est conçu pour être utilisé avec des tags [http://en.wikipedia.org/wiki/ISO/IEC_14443 ISO14443], le tag Mifare Classic étant probablement le type de tag (d'usage général) le plus couramment utilisé. Pour plus d'informations sur les tags supportés, référez vous à la documentation [http://www.libnfc.org/documentation/hardware/tags/iso14443 http://www.libnfc.org/documentation/hardware/tags/iso14443] ou recherchez des informations sur la famille des tags MiFare répondant à la norme ISO1443A.

== Can I set a delay calling readPassiveTargetID()? ==

== Puis-je fixer le délais pour appeler readPassiveTargetID()? ==

{{traduction}}

{{traduction}}

Note: This question only applies to the [https://github.com/adafruit/Adafruit_NFCShield_I2C I2C Library]. The [https://github.com/adafruit/Adafruit-PN532 SPI library] doesn't handle the timing the same way.

Note: cette question ne concerne que la [https://github.com/adafruit/Adafruit_NFCShield_I2C bibliothèque NFC Shield en I2C]. La [https://github.com/adafruit/Adafruit-PN532 bibliothèque SPI] ne gère pas le temps de la même façon.

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.

readPassiveTargetID() attend intentionnellement un certain temps (délais bloquant) jusqu'à ce qu'une carte entre dans le champs magnétique du lecteur. La raison de ce délai bloquant est d'assurer un flux commande/réponse" correctement traité. Une fois que le champs magnétique est activé et qu'une requête de lecture est envoyée via {{fname|readPassiveTargetID}}, vous pouvez continuer a envoyer de nouvelle commande sur le PN532, mais au moment où la carte entre dans le champ, le PN532 enverra la réponse à la requête de lecture initiale, même s'il est au milieu d'autres réponses ou activités. Pour éviter d'avoir à déboguer ce fonctionnement relativement complexe au niveau logiciel, un délais bloquant à été mis en oeuvre pour garder le "modèle commande/réponse" aussi clair que possible.

As a workaround to this blocking-delay limitation, '''setPassiveActivationRetries(maxRetries)''' was added to the latest NFC libraries to allow you to set a specific timeout after read requests.

As a workaround to this blocking-delay limitation, '''setPassiveActivationRetries(maxRetries)''' was added to the latest NFC libraries to allow you to set a specific timeout after read requests.