Hemos leído: USB Complete. Third Edition (Jan Axelson)

Esta lectura, más que por devoción, ha sido por obligación, aunque cuando compré el libro lo hice por devoción. Es decir, mi idea era leer algo serio sobre USB para ver cómo funcionaba, y trastear un poco para poder añadir esa especialización a mi currículum… Pero tras haberlo leído mejor no pongo nada, que ya tengo suficientes quebraderos de cabeza.

He dicho que la lectura ha sido por obligación, y es cierto. Hace dos semanas me pidieron que evaluara hacer un driver USB para una placa que estamos haciendo, o más bien que estoy haciendo, pues estoy más o menos a cargo del tema completo, como si hubiera vuelto a mis orígenes… Recuerdo el cambio de color de cara del ingeniero cuando le comenté que tenía que hacer una placa conectada por USB (lo que, ahora que conozco el percal, entiendo perfectamente, ya que el chaval no es ningún gallina en cuanto al diseño de hardware se trata). Comenzamos a planificar el tema, y mientras él buscaba y evaluaba microprocesadores, chips necesarios y todo eso, yo leía afanosamente este libraco (encima estaba sin ordenador, con mi anterior placa base en el cielo –o infierno, vaya usted a saber- de las placas base, y esperando lo que ahora disfruto). Nos cruzamos una buena cantidad de llamadas, vamos lo típico, que si esto vale esto, que si necesito xx MPIS, que si puedo usar BGA, que cambia esto del protocolo de comunicaciones porque no voy a poder atenderte… Hasta que acabé de leer el libro. Entonces hice La Llamada.

YO: ¿Querías un USB puro?

JEFE: Sipi.

YO: 6 meses + fase beta + fase de pruebas sólo para el driver…

JEFE: ¿A cualo?

YO: Lo que oyes.

JEFE: ¿No se puede acortar?

YO: No creo… -Pensando que en un par de meses podría estar, pero porsiaca…

JEFE: Pos vaya…

YO: Peeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeero…

JEFE: ¿Sí? – Con tono esperanzado

YO: Podemos usar esta solución. Cada chip lleva número de serie, el driver te lo da el fabricante, acortamos también el desarrollo de nuestro hardware porque la solución nos da un acceso directo a una UART, hay dos fabricantes, si uno falla tenemos al otro aunque cambiarlo requiere cambios en el hardware…

JEFE: Pos fale…

Y luego hice la otra llamada: -Gallinica, que vamos a usar lo que has propuesto. Vuelta del color a su cara, y todos tan contentos.

Bueno, después de la anécdota, vamos al libro.

No está mal, aunque no es lo que esperaba (más bien el USB no es lo que esperaba, pero bueno). Comienza explicándonos qué es el USB, su velocidad y lo compara con otros protocolos serie, describiendo también los cuatro modos y las cuatro velocidades junto a qué soporta cada clase…

Luego entra de lleno a explicar cómo funciona el protocolo en sí, cómo se forman los comandos y su contenido, de qué tenemos que preocuparnos y de qué no (por ejemplo, todo el tema de códigos de control, CRCs y demás lo hacen los chips directamente).

Y aquí es donde me entró el canguelo… En mi vida laboral he diseñado varios protocolos que han ido por encima de hilos RS232, RS485, Paralelo (no necesariamente de 8 bits), sockets, incluso pines sueltos de un microprocesador, pero nunca he visto algo tan barroco ni tan enrevesado. Es increíble la complicación del protocolo, tan increíble que pienso mal de él. Que si transaction que si token packet, que si pid, que si endpoint, que si data, que si frames, que si latencias… Y luego están los cuatro modos. Y no hablemos de la negociación e identificación cuando se enchufa un dispositivo USB con las quince espuertas de mensajes que se tienen que enviar, y más aún cuando arrancan y soportan ahorro de energía y cosas así. Ahora entiendo por qué hay tanto driver mierdoso… Lo que es mierdoso no es el driver, sino el protocolo.

Digo que pienso mal porque un protocolo diseñado con esta mala leche sólo puede tener alguna de estas explicaciones: O bien los que lo hicieron cobraban por tiempo de discusión, o por complejidad o quisieron cerrarlo tanto que sólo unos pocos fueran capaces de entender y desarrollar el protocolo…

Continuando con el libro, el autor nos cuenta cómo funciona cada modo y las APIs que hay para hacerlo funcionar. También comenta –por encima- cómo hacer un driver. Y da algunos ejemplos sin mucha utilidad para trastear desde Visual Basic y C++. El libro está centrado en explicar el funcionamiento de la clase HID (Human Interface Device), quizás la más común de todas las clases de dispositivos USB aunque también entra en las demás.

El libro termina con las especificaciones eléctricas y con un capítulo sobre algo llamado USB-on-the-GO, que no he leído y que tampoco sé qué es ni me interesa saberlo.