Protocollo di comunicazione seriale μFR per dispositivi della serie μFR

Protocollo di comunicazione seriale μFR per dispositivi della serie μFR

I dispositivi della serie μFR possono stabilire una comunicazione tramite la porta COM virtuale di FTDI, quindi i dispositivi sono visti come hardware standard della porta COM.

Parametri di comunicazione #

Lettori con interfaccia seriale FTDI #

Lettori μFR Classic e μFR Advance con connessione USB:

Comunicazione seriale: 1 Mbps, 8-N-1, Controllo di flusso: Nessuno;

Il pin RTS viene utilizzato per reimpostare il dispositivo. Quando l'RTS è impostato, il dispositivo è in uno stato di ripristino. Quando l'RTS è chiaro, il dispositivo è in uno stato normale.

Lettori μFR BaseHD con firmware "μFR support" installato (es. lettori XR e μFR XRc):

Comunicazione seriale (utilizzando driver VCOM FTDI): 250 kbps, 8-N-1, Controllo di flusso: Nessuno;

Lettori senza interfaccia seriale FTDI #

RS485 (connessione senza convertitore USB/RS-485):

Il baud rate variabile può essere impostato tramite uno strumento software. Il baud rate corrente deve essere noto quando si modifica il baud rate. La velocità in baud predefinita è 250 kbps.

μFR Classic Nano RS232 e formato scheda RS232:

UART / TTL: 115200 bps, 8-N-1, Controllo del flusso: Nessuno.

115200 bps è il baud rate predefinito. Il baud rate variabile può essere impostato tramite lo strumento software.

Il PIN 4 sul connettore viene utilizzato per reimpostare il dispositivo. Se la tensione su questo pin è alta (3,3 V), il dispositivo è nello stato di ripristino. Se la tensione è bassa (0 V), il dispositivo è in uno stato di funzionamento normale.

Se il dispositivo è collegato al nostro convertitore da RS232 a TTL, il livello di tensione sul pin 4 controlla su RTS. Quando l'RTS è chiaro, il dispositivo è in uno stato di ripristino. Quando l'RTS è impostato, il dispositivo è in uno stato normale.

Durante l'aggiornamento del firmware, il pin RTS deve essere collegato al pin 4 del dispositivo.

La piedinatura per il modello UART / TTL è presentata di seguito:

Ai fini della comunicazione tra i dispositivi di lettura e il PC host, viene creato il protocollo proprietario di D-Logic chiamato "seriale μFR".

Tutte le comunicazioni vengono avviate dall'host (PC o altre piattaforme) a cui è collegato il dispositivo.

Il numero massimo di dati trasferiti da un singolo comando o ricevuti da una risposta del dispositivo, dalla versione firmware 3.9.44 è di 256 byte e prima è di 192 byte.

Generalmente, ci sono due tipi di pacchetti:

• CMD – comando inviato dall'host al dispositivo
• ANS – risposta inviata dal dispositivo all'host

CMD può essere un set corto o lungo. Il set breve CMD è sempre lungo 7 byte mentre il set lungo CMD – chiamato CMD_EXT può avere una lunghezza variabile.

Le risposte sono:

• ACK – Riconoscimento, tutto è OK, il dispositivo è in attesa del prossimo CMD o CMD EXT
• ERR – Si è verificato un errore, il byte di errore definisce ERR_TYPE
• RSP – Risposta dal dispositivo su CMD o CMD_EXT

Byte di costanti di comunicazione definiscono il tipo di pacchetto, che può essere visualizzato nei primi tre byte di ciascun pacchetto.

Il primo byte di ogni pacchetto è il byte HEADER. Il secondo byte è sempre CMD_CODE. Il terzo byte è il byte TRAILER.

Tabella1. Costanti di comunicazione

CHECKSUM #

Tutti i checksum in questo documento sono calcolati nello stesso modo: una riga di byte viene utilizzata per il calcolo del checksum, ogni byte è XOR-ed con quello successivo fino alla fine della riga. Il valore finale viene incrementato con 0x07.

Ad esempio, un pacchetto CMD ha 7 byte, dove il settimo byte è il checksum dei 6 byte precedenti:

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

Codici CMD #

Ogni comando ha il suo valore corrispondente – guarda PANORAMICA DEI COMANDI.

Codici di errore #

Se si verifica un errore, il dispositivo risponderà con il pacchetto ERR. Ogni errore ha il suo valore corrispondente che può essere trovato nella tabella in Appendice: CODICI DI ERRORE.

Pacchetto CMD #

Il pacchetto CMD può essere breve – 7 byte di lunghezza o EXT-ended con lunghezza variabile. Nel caso del pacchetto EXT CMD, il quarto byte del pacchetto CMD è maggiore di 0, contenente il valore intero – lunghezza del pacchetto CMD_EXT. Quando si emettono CMD_EXT, il pacchetto cmD principale lungo 7 byte va per primo. Se tutto come previsto, il dispositivo risponderà con il pacchetto ACK, in attesa del pacchetto CMD_EXT. In caso di errore, il dispositivo risponderà con il pacchetto ERR. CMD_EXT è costituito da vari parametri diversi, a seconda del tipo di comando, quindi CMD_EXT non ha una lunghezza e un ordine fissi di parametri.

Il pacchetto CMD ha la seguente struttura:

Il pacchetto CMD ha la seguente struttura:

• Byte 1: CMD_HEADER come definito in Table1.Costanti di comunicazione, 0x55
• Byte 2: CMD_CODE come definito in Table2. CMD_CODE valori
• Byte 3: CMD_TRAILER come definito in Table1.Costanti di comunicazione, 0xAA
• Byte 4: CMD_EXT_Length: Se 0 allora il "CMD EXT" non viene utilizzato); Il valore ELSE è la lunghezza dell'intero pacchetto CMD_EXT
• Byte 5: CMD_Par0: parametro di comando0, assume valori diversi a seconda del comando
• Byte 6: CMD_Par1: parametro di comando1, assume valori diversi a seconda del comando
• Byte 7: CHECKSUM – Checksum di byte da 1 a 6 come spiegato sopra

CMD_EXT pacchetto ha la seguente struttura:

CMD_EXT pacchetto ha la seguente struttura:

Parametri byte da 1 a N – parametri diversi, i valori dipendono dal tipo di comando

• CMD_EXT_CHECKSUM – Checksum di byte da 1 a N
• CMD_EXT_Length è il numero di tutti i byte, inclusi i CMD_EXT_CHECKSUM; ad esempio la lunghezza è N + 1

Tipi di pacchetti ANSWER #

Il dispositivo può rispondere con i seguenti tipi di pacchetti:

ACK – Pacchetto di riconoscimento

Se il comando e il pacchetto CMD sono configurati correttamente (struttura e checksum) e deve essere inviato un pacchetto CMD_EXT aggiuntivo, il dispositivo risponderà con un pacchetto ACK.

ERR – Pacchetto di errore

Se si è verificato un errore, il dispositivo risponderà con il pacchetto ERR. Alcuni comandi possono restituire il set di ERR_EXT.In tal caso, il pacchetto ERR_EXT viene immediatamente dopo il pacchetto ERR.

RSP – Pacchetto di risposta

Se viene inviato un pacchetto CMD o CMD_EXT correttamente configurato, il dispositivo risponderà con RSP o RSP_EXT pacchetto, che dipende dal comando emesso. Ad esempio, se CMD ha bisogno di una risposta abbastanza breve per il pacchetto RSP, non ci sarà alcun pacchetto RSP_EXT. Altrimenti, se CMD o CMD_EXT ha bisogno di una risposta con più byte, RSP_EXT arriverà immediatamente dopo il pacchetto RSP. Una situazione comune è quando si leggono i dati con il comando LinearRead, in cui il dispositivo risponderà con una riga di byte di dati della scheda.

ACK – Pacchetto di riconoscimento #

Il pacchetto ACK ha la seguente struttura:

Il pacchetto ACK ha la seguente struttura:

• Byte 1: ACK_HEADER come definito in Table1.Costanti di comunicazione, 0x55
• Byte 2: CMD_CODE come definito in Table2. CMD_CODE valori. Device ACKnowledges che il comando precedente è stato inviato correttamente
• Byte 3: ACK_HEADER come definito in Table1.Costanti di comunicazione, 0x55
• Byte 4: Byte 5, Byte 6: non utilizzato nel pacchetto ACK, i valori vengono 0x00
• Byte 7: CHECKSUM – Checksum di byte da 1 a 6 come spiegato sopra

ERR – pacchetto di errore #

Il pacchetto ERR ha la seguente struttura:

• Byte 1: ERR_HEADER come definito in Table1.Costanti di comunicazione, 0xEC
• Byte 2: ERR_CODE come definito in Table3. CODICI DI ERRORE.
• Byte 3: ERR_TRAILER come definito in Table1.Costanti di comunicazione, 0xCE
• Byte 4: se esiste ERR_EXT, questo byte contiene la lunghezza del pacchetto ERR_EXT (incluso ERR_EXT checksum)
• Byte 5: Possibili informazioni aggiuntive sull'errore possono essere definite in ERR_Val0
• Byte 6: Possibili informazioni aggiuntive sull'errore possono essere definite in ERR_Val1
• Byte 7: CHECKSUM – Checksum di byte da 1 a 6 come spiegato sopra

ERR_EXT e ha la seguente struttura:

• Byte 1: Primo byte di ERR_EXT
• …
• Byte N: N-ennesimo byte di ERR_EXT
• Byte N+1: ERR_EXT_CHECKSUM, checksum di byte da 1 a N, calcolato come spiegato in precedenza.

RSP – pacchetto di risposta #

Il pacchetto RSP ha la seguente struttura:

• Byte 1: RSP_HEADER come definito in Table1.Costanti di comunicazione, 0xED
• Byte 2: CMD_CODE come definito in Table2. CMD_CODE valori
• Byte 3: ERR_TRAILER come definito in Table1.Costanti di comunicazione, 0xDE
• Byte 4: se esiste RSP_EXT, questo byte contiene la lunghezza del pacchetto RSP_EXT (incluso RSP_EXT checksum)
• Byte 5: Possibili informazioni aggiuntive su RESPONSE possono essere definite in RSP_Val0
• Byte 6: Possibili informazioni aggiuntive su RESPONSE possono essere definite in RSP_Val1
• Byte 7: CHECKSUM – Checksum dei byte da 1 a 6 come spiegato sopra.

T

• Byte 1: Primo byte di RSP_EXT
• …
• Byte N: N-ennesimo byte di RSP_EXT
• Byte N+1: RSP_EXT_CHECKSUM, checksum di byte da 1 a N, calcolato come spiegato in precedenza.