Protocole de communication série μFR pour les appareils de la série μFR

Protocole de communication série μFR pour les appareils de la série μFR

Les périphériques de la série μFR peuvent établir une communication sur le port COM virtuel de FTDI, de sorte que les périphériques sont considérés comme du matériel de port COM standard.

Paramètres de communication #

Lecteurs avec interface série FTDI #

Lecteurs μFR Classic et μFR Advance avec connexion USB :

Communication série: 1 Mbps, 8-N-1, Contrôle de flux: Aucun;

La broche RTS est utilisée pour réinitialiser l’appareil. Lorsque le RTS est défini, l’appareil est dans un état de réinitialisation. Lorsque le RTS est clair, l’appareil est dans un état normal.

Lecteurs μFR BaseHD avec firmware « μFR support » installé (ex. lecteurs XR et μFR XRc) :

Communication série (à l’aide du pilote VCOM FTDI): 250 kbps, 8-N-1, Contrôle de flux: Aucun;

Lecteurs sans interface série FTDI #

RS485 (connexion sans convertisseur USB/RS-485) :

Le débit en bauds variable peut être défini via un outil logiciel. Le débit en bauds actuel doit être connu lors de la modification du débit en bauds. Le débit en bauds par défaut est de 250 kbps.

μFR Classic Nano RS232 et taille de carte RS232:

UART / TTL: 115200 bps, 8-N-1, Contrôle de débit: Aucun.

115200 bps est le débit en bauds par défaut. Le débit en bauds variable peut être défini via l’outil logiciel.

Le code PIN 4 du connecteur est utilisé pour réinitialiser l’appareil. Si la tension sur cette broche est élevée (3,3 V), l’appareil est dans l’état de réinitialisation. Si la tension est faible (0 V), l’appareil est dans un état de fonctionnement normal.

Si l’appareil est connecté à notre convertisseur RS232 vers TTL, le niveau de tension sur la broche 4 contrôle sur RTS. Lorsque le RTS est clair, l’appareil est dans un état de réinitialisation. Lorsque le RTS est défini, le périphérique est dans un état normal.

Lors de la mise à jour du firmware, la broche RTS doit être connectée à la broche 4 de l’appareil.

Le brochage pour le modèle UART / TTL est présenté ci-dessous:

À des fins de communication entre les lecteurs et le PC hôte, le protocole propriétaire de D-Logic appelé « série μFR » est créé.

Toutes les communications sont initiées par l’hôte (PC ou autres plates-formes) auquel l’appareil est connecté.

Le nombre maximal de données transférées par une seule commande ou reçues par une réponse d’un périphérique, à partir de la version 3.9.44 du firmware est de 256 octets, et avant est de 192 octets.

Généralement, il existe deux types de paquets :

• CMD – commande envoyée par l’hôte à l’appareil
• ANS – réponse envoyée de l’appareil à l’hôte

CMD peut être un ensemble court ou long. L’ensemble court CMD est toujours long de 7 octets tandis que le jeu long CMD – appelé CMD_EXT peut avoir une longueur variable.

Les réponses sont les suivantes :

• ACK – Accusé de réception, tout va bien, l’appareil attend le prochain CMD ou CMD EXT
• ERR – Une erreur s’est produite, l’octet d’erreur définit ERR_TYPE
• RSP – Réponse de l’appareil sur CMD ou CMD_EXT

Les constantes de communication octets définissent le type de paquet, qui peut être vu dans les trois premiers octets de chaque paquet.

Le premier octet de chaque paquet est l’octet HEADER. Le deuxième octet est toujours CMD_CODE. Le troisième octet est l’octet TRAILER.

Tableau 1. Constantes de communication

SOMME DE CONTRÔLE #

Toutes les sommes de contrôle de ce document sont calculées de la même manière : une ligne d’octets est utilisée pour le calcul de la somme de contrôle, chaque octet est XOR-ed avec le suivant jusqu’à la fin de la ligne. La valeur finale est incrémentée avec 0x07.

Par exemple, un paquet CMD a 7 octets, où le 7ème octet est la somme de contrôle des 6 octets précédents :

CHECKSUM = (Byte1 XOR Byte2 XOR Byte3 XOR Byte4 XOR Byte5 XOR Byte6) + 0x07

Codes CMD #

Chaque commande a sa valeur correspondante – regardez COMMANDS OVERVIEW.

Codes d’erreur #

Si une erreur se produit, le périphérique répondra avec le paquet ERR. Chaque erreur a sa valeur correspondante qui se trouve dans le tableau de l’annexe : CODES D’ERREUR.

Paquet CMD #

Le paquet CMD peut être court – 7 octets de long ou ext-terminé avec une longueur variable. Dans le cas d’un paquet EXT CMD, le quatrième octet du paquet CMD est supérieur à 0, contenant une valeur entière – longueur de CMD_EXT paquet. Lors de l’émission de CMD_EXT, le paquet principal CMD long de 7 octets passe toujours en premier. Si tout est prévu, l’appareil répondra avec le paquet ACK, en attendant le paquet CMD_EXT. En cas d’erreur, l’appareil répondra avec le paquet ERR. CMD_EXT se compose de différents paramètres, en fonction du type de commande, de sorte CMD_EXT n’a pas de longueur et d’ordre de paramètres fixes.

Le paquet CMD a la structure suivante :

Le paquet CMD a la structure suivante :

• Octet 1 : CMD_HEADER tel que défini dans le tableau 1.Constantes de communication, 0x55
• Octet 2 : CMD_CODE tel que défini dans le tableau 2. CMD_CODE valeurs
• Octet 3 : CMD_TRAILER tel que défini dans le tableau 1.Constantes de communication, 0xAA
• Octet 4: CMD_EXT_Length: Si 0 alors le « CMD EXT » n’est pas utilisé); La valeur ELSE est la longueur de l’ensemble du paquet CMD_EXT
• Octet 5: CMD_Par0: paramètre de commande0, prend des valeurs différentes en fonction de la commande
• Octet 6 : CMD_Par1 : paramètre de commande1, prend des valeurs différentes en fonction de la commande
• Octet 7 : SOMME DE CONTRÔLE – Somme de contrôle des octets 1 à 6 comme expliqué ci-dessus

CMD_EXT paquet a la structure suivante :

CMD_EXT paquet a la structure suivante :

Octets de paramètre 1 à N – différents paramètres, les valeurs dépendent du type de commande

• CMD_EXT_CHECKSUM – Somme de contrôle des octets 1 à N
• CMD_EXT_Length est le nombre de tous les octets, y compris CMD_EXT_CHECKSUM ; Par exemple, la longueur est N+1

Types de paquets ANSWER #

L’appareil peut répondre avec les types de paquets suivants :

ACK – Paquet d’accusé de réception

Si la commande et le paquet CMD sont correctement configurés (structure et somme de contrôle) et qu’un paquet CMD_EXT supplémentaire doit être envoyé, le périphérique répondra avec un paquet ACK.

ERR – Paquet d’erreur

Si une erreur se produit, le périphérique répondra avec le paquet ERR. Certaines commandes peuvent renvoyer le jeu de ERR_EXT.Dans ce cas, le paquet ERR_EXT vient immédiatement après le paquet ERR.

RSP – Paquet de réponse

Si un CMD correctement configuré ou CMD_EXT paquet est envoyé, le périphérique répondra avec RSP ou RSP_EXT paquet, ce qui dépend de la commande émise. Par exemple, si CMD a besoin d’une réponse suffisamment courte pour le paquet RSP, il n’y aura pas de RSP_EXT paquet. Sinon, si CMD ou CMD_EXT a besoin d’une réponse avec plus d’octets, RSP_EXT viendra immédiatement après le paquet RSP. Une situation courante est lors de la lecture de données avec la commande LinearRead, où le périphérique répondra avec une ligne d’octets de données de carte.

ACK – Paquet d’accusé de réception #

Le paquet ACK a la structure suivante :

Le paquet ACK a la structure suivante :

• Octet 1 : ACK_HEADER tel que défini dans le tableau 1.Constantes de communication, 0x55
• Octet 2 : CMD_CODE tel que défini dans le tableau 2. CMD_CODE valeurs. Device ACKnowledges que la commande précédente est correctement envoyée
• Octet 3 : ACK_HEADER tel que défini dans le tableau 1.Constantes de communication, 0x55
• Octet 4 : Octet 5, Octet 6 : Non utilisé dans le paquet ACK, les valeurs sont 0x00
• Octet 7 : SOMME DE CONTRÔLE – Somme de contrôle des octets 1 à 6 comme expliqué ci-dessus

ERR – paquet d’erreur #

Le paquet ERR a la structure suivante :

• Octet 1 : ERR_HEADER tel que défini dans le tableau 1.Constantes de communication, 0xEC
• Octet 2 : ERR_CODE tel que défini dans le tableau 3. CODES D’ERREUR.
• Octet 3 : ERR_TRAILER tel que défini dans le tableau 1.Constantes de communication, 0xCE
• Octet 4 : s’ERR_EXT existe, cet octet contient la longueur du paquet ERR_EXT (y compris ERR_EXT somme de contrôle)
• Octet 5 : Les informations supplémentaires possibles sur l’erreur peuvent être définies dans ERR_Val0
• Octet 6 : Les informations supplémentaires possibles sur l’erreur peuvent être définies dans ERR_Val1
• Octet 7 : SOMME DE CONTRÔLE – Somme de contrôle des octets 1 à 6 comme expliqué ci-dessus

ERR_EXT et a la structure suivante:

• Octet 1 : Premier octet de ERR_EXT
• …
• Octet N : N-nième octet de ERR_EXT
• Octet N+1 : ERR_EXT_CHECKSUM, somme de contrôle des octets 1 à N, calculée comme expliqué précédemment.

RSP – paquet de réponse #

Le paquet RSP a la structure suivante :

• Octet 1 : RSP_HEADER tel que défini dans le tableau 1.Constantes de communication, 0xED
• Octet 2 : CMD_CODE tel que défini dans le tableau 2. CMD_CODE valeurs
• Octet 3 : ERR_TRAILER tel que défini dans le tableau 1.Constantes de communication, 0xDE
• Octet 4 : si RSP_EXT existe, cet octet contient la longueur du paquet RSP_EXT (y compris RSP_EXT somme de contrôle)
• Octet 5 : Les informations supplémentaires possibles sur RESPONSE peuvent être définies dans RSP_Val0
• Octet 6 : Les informations supplémentaires possibles sur RESPONSE peuvent être définies dans RSP_Val1
• Octet 7 : SOMME DE CONTRÔLE – Somme de contrôle des octets 1 à 6, comme expliqué ci-dessus.

t

• Octet 1 : Premier octet de RSP_EXT
• …
• Octet N : N-nième octet de RSP_EXT
• Octet N+1 : RSP_EXT_CHECKSUM, somme de contrôle des octets 1 à N, calculée comme expliqué précédemment.