Update 20 Giu 2022: All parts together and translated into English
https://hackaday.io/project/185787-hid-bluetooth-phone-qr-barcode-reader
Ecco un altro dei miei piccoli progetti da weekend (in questo caso, più di un weekend). Si tratta di un lettore di codici a barre (e QR) che si collega alla porta USB del PC e viene visto dal sistema come un dispositivo HID, specificatamente una tastiera.
Grazie a questa caratteristica, è possibile collegarlo a qualsiasi computer / tablet e può essere usato da qualsiasi applicazione (spreadsheet, per esempio). Ho effettuato il test su WinXP, Win7, Win10 (Windows) e Ubuntu, Debian (Linux) e anche su un tablet Android provvisto di cavetto OTG e il risultato è sempre stato lo stesso: funziona e non ha bisogno di drivers.
Giusto per capire di cosa si tratta, diamo un’occhiata al circuito montato su schede da prototipi. Questa è la vista dall’alto
e questa quella dal basso (i fili da cavo piatto, separati, sono i migliori per questi lavori)
Se qualcuno sta già cambiando pagina perché pensa che sia un po’ complicato costruire un prototipo così, lo invito ad aver pazienza… ho trovato on-line dei circuiti che sono compatibili con questa applicazione e il prossimo step sarà di adattare il firmware a questi economici moduli di larga diffusione, evitando se possibile l’uso del saldatore. Ecco anche lo schema:
Per la versione più leggibile, in pdf, cliccare qui.
Il circuito si basa sul microcontrollore ATmega88. Si potrebbe realizzare anche con altri modelli della stessa famiglia, ma avendo solo questo nel mio piccolo laboratorio mobile, la scelta è stata obbligata. Per sviluppare il firmware ho usato una VM con WinXP (che uso normalmente per i tanti progetti con microcontrollori da 8 bit) e su questa ho installato WinAvr, che è un pacchetto contenente il compilatore C e diversi altri strumenti utili. WinAvr non ha un proprio IDE, dato che è possibile controllare qualsiasi cosa da riga di comando e usare il notepad++ (compreso nel pacchetto) per l’editing dei files sorgenti, ma io sono abituato ad usare un IDE e quindi ho scaricato e installato AvrStudio, lo strumento ufficiale di Atmel (ora Microchip). La mia versione preferita per WinXP è 4.19 che è l’ultima prima di implementazioni che purtroppo richiedono di appesantire il S.O. per poter funzionare.
A questo punto, con gli strumenti software a disposizione, sono andato a vedere un vecchio sito, che conosco da anni, dove esiste una libreria in grado di creare una periferica USB a bassa velocità, utilizzando solo un interrupt sul micro e un po’ di firmware. Questa libreria ha cambiato nome molte volte ed è stata continuamente migliorata e perfezionata ed è usata in moltissimi dispositivi legati agli Atmel AVR, tra i quali i famosi programmatori USBASP. Il link alla pagina principale è questo: https://www.obdev.at/products/vusb/index.html
Io uso DuckDuckGo per le mie ricerche su internet; se inserite le parole chiave: avr virtual usb, verrete indirizzati lì. Troverete anche diversi progetti di esempio, forniti di codice sorgente e in molti casi anche di schemi e disegno del PCB. Un bel sito, molto ben documentato.
Ho scorso la lista dei vari progetti e alla fine ne ho scaricati due. Miscelandoli e facendo qualche modifica, ho infine ottenuto ciò che desideravo. Ecco i links alle rispettive pagine:
a) 1-Key_keyboard di Flip van der Berg http://blog.flipwork.nl/?x=entry:entry081009-142605
b) Terminal Keyboard di Neil Stockbridge http://hobby-electrons.sourceforge.net/projects/terminal-keyboard/
Dato che i controllori usati in entrambi i progetti erano diversi dal mio, ho modificato i nomi di alcuni registri (porta seriale) e ho quindi compilato con successo. L’IDE AvrStudio ha anche una parte a destra dove è disponibile un elenco dei registri interni e dei singoli bits all’interno di tali registri, per cui è abbastanza facile rinominare quelli che purtroppo cambiano nome da un modello all’altro, anche se molto simili. Oltre a miscelare i due programmi citati e alla modifica dei registri, ho anche fatto una piccola aggiunta: il programma Terminal Keyboard (anche un altro dello stesso autore) ha un metodo di immissione semplice, cioè si invia il byte 0xFF seguito dal codice del tasto (per esempio, per mandare una A si invia 0xFF 0x04, che è lo “scancode” del tasto a). Io ho aggiunto uno 0xFE. Cioè… se voglio trasmettere un carattere maiuscolo, invio 0xFF 0x04 (e ottengo A), se no invio 0xFE 0x04 (e ottengo a). Questo perché in un caso inserisco il modificatore di “left shift pressed” e nell’altro, no. Subito dopo aver inviato il codice di tasto premuto, invio automaticamente quello di tasto rilasciato e tutto è a posto. Dato che voglio solo trasmettere un barcode, che ha un breve numero di caratteri, numerici e alfabetici, questo livello di semplicità è sufficiente.
Ora, da dove prendo questi dati da trasformare in tasti premuti per la mia “tastiera USB” simulata? Semplice, dalla seriale che in questo caso è un modulino Bluetooth tipo HC-06, che si collega alla mia App Android che fa il lavoro pesante, cioè legge il Barcode (o il QR) e trasforma la stringa di caratteri in una serie di comandi da inviare tramite BT al modulo. Quindi, io ho il mio smartphone in mano e vado in giro a leggere i miei barcode, mentre il circuito sta lì, attaccato al mio PC e scrive nell’applicazione che sto usando, come se io fossi lì a digitare sulla tastiera. Il modulo HC-06 è impostato per funzionare da ricevitore e ha il baud rate settato a 9600 bps. Il nome bluetooth è, appunto, HC-06. Nota: se prendete un HC-05 e gli modificate il nome in HC-06 con i comandi AT, funziona lo stesso.
Il file hex zippato serkbd.zip, necessario per programmare il micro ATmega88, può essere scaricato dalla pagina Barcode reader – downloads. La mappa dei fusibili è la seguente: lock=FF ext=FF high=C7 low=FF.
Il progetto continua… leggete le parti successive!
Note:
Ho aggiunto un cond. el. da 100uF-16V montato vicinissimo ai piedini di alimentazione del modulo HC-06, a seguito di uno strano evento: in certi casi, la scansione dei dispositivi BT mi dava solo il MAC address del modulo, ma non il nome! Dopo aver verificato che non si trattasse di un errore nel mio software (usando il tool Nordic nRF Connect), ho pensato a una possibile alimentazione “sporca” proveniente dalla presa USB. Con il condensatore aggiunto, il problema (al momento) non si è più presentato.