Het implementeren van USB

Voor embedded systems

Er zijn twee manieren om USB toe te voegen aan een ontwerp. Dit kan bijvoorbeeld met een applicatie-specifieke geïntegreerde schakeling (ASIC) of door te kiezen voor een microcontroller met USB hardware ondersteuning. Elke benadering heeft zijn eigen pro’s en contra’s.

Alhoewel USB het meest ingeburgerde seriële communicatieprotocol is dat wordt aangetroffen op grote microcontrollers (MCU’s) en microprocessoren (MPU’s), is het niet altijd beschikbaar op embedded systems. Dit is te danken aan een aantal factoren: elektrische signaaleisen, protocol-overhead en de beschikbaarheid van eenvoudigere communicatieprotocollen, zoals de seriële periferie interface (SPI), I²C of UART. Alhoewel USB de eenvoudigere communicatieprotocollen niet zal vervangen, loont het de moeite om dit voor draagbare toepassingen eens te overwegen.

Het implementeren van USB met een ASIC

Een eenvoudige manier om USB toe te voegen aan een ontwerp is het gebruik van een ASIC die de USB communicatie intern verwerkt en die de gewenste data en de signalen die nodig zijn uitsplitst. Een van de meest gangbare USB ASIC’s is een USB-UART brug. Dit is een (relatief) transparante interface voor het verplaatsen van data van een USB host naar een embedded system. Heel vaak ziet dit er uit als een virtuele COM poort op de host, die kan worden geopend door een seriële terminal applicatie voor bidirectionele communicatie. Vaak beschikken deze ASIC’s nog over een aantal extra functies, zoals USB-I²C, besturen van I/O-lijnen, analoge bemonstering enzovoort. Deze componenten zijn al voorbereid om in een systeem te worden opgenomen. Daardoor vraagt de implementatie een minimum aan inspanning, hetgeen ze perfect maakt om ze op het laatste moment toe te voegen aan een ontwerp.

Niettemin zijn er enkele beperkingen om deze ASIC’s te kunnen gebruiken. Het is wel een ‘het is wat het is’ benadering en dat kan een nadeel zijn. Als er bepaalde functies nodig zijn die niet door de ASIC worden ondersteund, dan is deze benadering niet werkbaar. Een ander nadeel vormen de extra componenten die aan de onderdelenlijst worden toegevoegd. Deze componenten vragen om extra ruimte op de printplaat en verhogen de prijs van het ontwerp.

Het implementeren van USB met een microcontroller

Als het al bekend is dat er USB-communicatie nodig zal zijn voordat er een bepaalde microcontroller wordt geselecteerd, overweeg dan eens om voor een component te kiezen met ingebouwde USB hardware-periferie. Er is een ruime keus aan microcontrollers van zeer efficiënte 8-bit tot uiterst krachtige 32-bit componenten. Het selecteren van de juiste microcontroller is afhankelijk van de toepassing.

Voor eenvoudige toepassingen, zoals toetsenborden, muizen en USB-UART-omzetters vormen 8-bit MCU’s een goede keus. Deze componenten bieden een combinatie van kleine afmetingen, minimaal stroomverbruik, lage kostprijs en gangbare +5V voedingsspanning.

Voor rekenintensieve toepassingen komen 32-bit MCU’s in overweging. Deze zijn krachtiger en beschikken over een groter werkgeheugen. Niettemin kunnen 32-bit MCU’s duur zijn, groot en hebben ze vaak een beperkt voedingsspanningsbereik. Een vergelijkingstabel met de voor- en nadelen van de verschillende benaderingen is weergegeven in afbeelding 1. 

Bouwen van USB toepassingen op een AVR DU

Er zijn allerlei microcontrollers met USB periferie beschikbaar. In dit geval richten we ons op de AVR DU serie microcontrollers, een intellectuele opvolger van de XMEGA D serie microcontrollers.

De AVR DU serie introduceert diverse verbeteringen ten opzichte van de oudere componenten. Zo is er bijvoorbeeld niet langer een extern kristal nodig en dat beperkt het kostenplaatje. De DU serie bevat eveneens een geïntegreerde lineaire spanningsregelaar met minimale eigen spanningsval (low drop-out, LDO). Deze voedt de USB schakeling als de microcontroller een voedingsspanning krijgt van 3,9 V of hoger. Bovendien beschikt de AVR DU serie over de functie ‘program and debug interface disable (PDID)’ die de component permanent blokkeert. Dit voorkomt dat de microcontroller wordt uitgelezen, gewist of opnieuw wordt geprogrammeerd.

De volgende voorbeelden zijn eenvoudige toepassingen die zijn ontwikkeld op de AVR DU serie. Deze voorbeelden maken gebruik van de MPLAB codeconfigurator (MCC), een gratis hulpmiddel voor het configureren en genereren van een API voor de on-board hardware met de bijbehorende USB-stack-bibliotheek. De bibliotheek ondersteunt de gangbare communications device class (CDC) en human interface devices (HID), zoals toetsenborden en muizen.

CDC toepassing: USB naar SPI/I²C

Dit voorbeeld (zie afbeelding 2) implementeert een USB naar SPI/I²C omzetter die werkt zonder een klantspecifieke driver. Dit wordt gerealiseerd door de microprocessor te beschouwen als een generieke component van de CDC klasse. De meeste besturingssystemen beschikken over een generieke driver voor dit soort communicatie. Hiermee is de gebruiker in staat om data te zenden en te ontvangen zonder dat daarvoor een speciale driver is geïnstalleerd.

Om een seriële bewerking te starten, stuurt de gebruiker een speciaal geformatteerde commandoregel naar de microcontroller. De data die door de microcontroller wordt ontvangen, wordt ontleden en omgezet (indien mogelijk) in een SPI- of I²C-bus-bewerking. Daarna rapporteert de microcontroller commandofouten, communicatiefouten (uitsluitend I²C) of gelezen data tijdens de uitwisseling. Voor SPI worden de commandoregels als volgt geformatteerd:

spi eeprom/dac/usd <byte data to send>

Daarbij verwijzen “eeprom”, “dac” en “usd” naar componenten op de Curiosity Nano Explorer (afbeelding 3) die in deze toepassing wordt gebruikt. Het volgende fragment is een voorbeeld van een commandoregel van de gebruiker om te communiceren met een EEPROM (25CSM04) op de Explorer-kaart. Dit commando leest het identificatieregister van de geheugenchip uit.

spi eeprom 9F 00 00 00 00 00
> FF 29 CC 00 01 00

Ook I²C heeft drie overeenkomstige, maar verschillende formaten voor de commandoregels, omdat de I²C-bus wordt gedeeld met alle aangesloten componenten.

i2c <address> r <number of bytes to read>
i2c <address> w <bytes to write>
i2c <address> wr <register address byte> <number of bytes to read>

Net als bij de SPI bestaat een snelle test hiervan uit het lezen van de ID die een fabrikant heeft toegewezen aan een sensor – bijvoorbeeld de MCP9808 temperatuursensor.

i2c 1c wr 06 02
> 00 54

Een voorbeeld van de software is hieronder te vinden op Github.

HID toepassing: USB toetsenbord

Een eenvoudig, maar gemakkelijk over te nemen voorbeeld van USB-communicatie is het implementeren van een toetsenbord. Normaliter zal er, als er een ingedrukte toets wordt gedetecteerd door een toetsenbord, een rapport naar de host worden gestuurd dat aangeeft welke toets(en) de gebruiker heeft ingedrukt. Als de toets wordt losgelaten, wordt er een ander rapport verzonden om aan te geven dat de toets is vrijgegeven door de gebruiker.
In een voorbeeld (die u via een link op- onze site kunt vinden) wordt dit op een ietwat andere manier geïmplementeerd. In plaats van het rapporteren van een enkele toets of knop als bij een standaard toetsenbord, rapporteert dit voorbeeld multi-toets-invoer voor het indrukken van een enkele knop om functionele macro’s te genereren. Door het indrukken van bijvoorbeeld SW0 op de AVR64DU32 Curiosity Nano (afbeelding 4) wordt een rapport verstuurd met de toetsen “AVR DU” naar de host computer. De LED op de Curiosity Nano geeft de toestand aan van Caps Lock op het host systeem.
Als aanvulling op de Curiosity Nano, wordt een dubbelklik (2×2) eveneens aangesloten via de Curiosity Adapter Board. De knoppen zijn toegewezen aan de macro’s: CTRL + C (copy), CTRL + V (paste), CTRL + Z (undo) en CTRL + X (cut). Een optionele externe knop kan eveneens worden toegevoegd voor het zenden van ALT + F4 naar de host.

Auteur: Robert Perkel, Application Engineer bij Microchip Technology’s 8-bit MCU bedrijfseenheid.