¿Qué clase de usb para un dispositivo destinado a ser lo más preparado posible para el futuro?

Estoy escribiendo especificaciones para un producto y necesito ayuda para minimizar su futura necesidad de mantenimiento.

Para poder ser monitoreado (opcionalmente) desde Internet, se supone que el dispositivo tiene un puerto USB CDC para conectarlo a una computadora (ahora lo estoy desarrollando como un script de Python en raspberry) capaz de sondear datos de él ( menos de 10 bytes por minuto, la velocidad no es el problema aquí) y generar una buena página web.

Mi preocupación es minimizar la necesidad de trabajo futuro en esta función de capacidad de comunicación: decidimos hacerlo como un truco de relaciones públicas, pero esperamos que lo use una minoría de nuestros clientes, pasar días todos los años manteniendo y arreglando el código no es un problema. opción.

Del lado de la computadora, decidimos abrir el código fuente y, por supuesto, también el comando AT para el dispositivo. Del lado del dispositivo, lo que me preocupa es la necesidad de controladores.

¿En qué clase de USB debo colocar mi dispositivo para que sea reconocido como un puerto COM sin necesidad de distribuir controladores? Es decir, si hago que se adhiera a la especificación de clase de dispositivos de comunicación, ¿puedo hacer que se reconozca como un puerto com a través de controladores "estándar, omnipresentes"?

Respuestas (2)

Probablemente desee un puerto serie CDC. No estoy de acuerdo con laptop2d aquí, aunque los controladores HID (por ejemplo, los de un mouse y teclado USB) son comunes, no veo cómo usaría ninguno de los controladores estándar para una comunicación tipo serie. Por supuesto, podría escribir su propio controlador HID, o tal vez haya una compañía que los venda.

Las versiones de Windows desde Vista en adelante (y probablemente también antes) incluyen un controlador serie usb CDC llamado usbser.sys. Por lo que puedo decir, hay dos versiones principales, una en Windows Vista/7/8/8.1 y otra en Windows 10.

Para la primera versión, debe proporcionar un archivo inf para vincular su VID/PID USB al controlador, luego Windows lo cargará. El conductor es un poco basura, no intenta recuperarse de las interrupciones transitorias en el autobús, y hemos tenido problemas para pasar las pruebas de inmunidad estándar europeas con él. Debido a un error en el controlador, no es posible recuperar una conexión interrumpida únicamente en el software (!!).

La versión de Windows 10 es mejor. Si configura la clase y subclase de dispositivo correctas (02/02, IIRC), Windows cargará el controlador sin inf. ¡Todavía tendrá un amarillo! Sin embargo, en el administrador de dispositivos, por lo que para una apariencia profesional aún querrá esa inf. Si usa un inf, tendrá que estar firmado, y un certificado de firma de código le costará menos de £ 100.

También puede comprar un controlador comercial de, por ejemplo, Thesycon . Son mucho mejores que los integrados en Windows y proporcionarán distribuibles personalizados. Aunque cuesta ££££s.

Entiendo que el soporte de Linux para los puertos seriales de CDC es bueno, no se necesita controlador (aunque tal vez algunas reglas de udev), y no tengo idea sobre Mac.

Todo esto supone que usted mismo hace el USB en un microcontrolador equipado con USB, utilizando las bibliotecas apropiadas y luego selecciona un controlador. Otra opción sería trabajar con alguien como FTDI. Probablemente puedan proporcionar controladores si usa uno de sus chips USB/serie.

El controlador HID no está restringido a ratones y teclados. Esa es solo una configuración para ello. Desde los albores de USB, Windows ha tenido soporte para casi cualquier tipo de dispositivo HID, y si se sumerge en las especificaciones, verá que hay una gran cantidad de posibilidades para definir su propio dispositivo personalizado. Para una tasa de datos tan baja, sería mi elección en términos de compatibilidad entre plataformas/versiones y facilidad de implementación (tanto software para PC como integrado).
Sin embargo, no conozco ningún controlador HID de tipo serie con amplia disponibilidad, y eso parecía ser algo que el autor de la pregunta estaba buscando. CDC está integrado en Windows (aunque no muy bien) y es probable que obtenga un mejor soporte en el futuro. Déjame ver si puedo dejar eso más claro.
La clase CDC (comunicación) es horrible desde el punto de vista de USB: la interfaz no tiene un buen protocolo de aceleración de datos y toda la sincronización de datos se produce mediante la actividad del hardware IN-NAK. Esta actividad se produce a nivel de hardware y da como resultado un sondeo casi continuo del punto final a una tasa de sondeo de 3 a 5 us (microsegundos). Dado que esta actividad se transmite mediante la arquitectura de estrella USB a todas las sucursales y dispositivos conectados, contamina todo el árbol USB y es desagradable. Dado que el CDC tiene un legado profundo en RS232, dudo mucho que se pueda mejorar, alguna vez. La clase HID es mucho más amigable.
Win7 usber.sys sondea a intervalos de aproximadamente 10 us, creo, y se ralentiza si el autobús está ocupado. Una pequeña misericordia es que la versión win10 solo sondea cuando algún software tiene un identificador abierto en el puerto, por lo que reduce un poco el tráfico de basura. Sí, es bastante horrible desde el punto de vista del autobús. Pero es compatible sin necesidad de un controlador de modo kernel (porque usbser.sys está disponible de fábrica). Si alguien puede dar una forma de hacer una comunicación en serie con HID sin escribir un controlador de modo kernel, sería una gran respuesta, y la votaré.
Probablemente debería haberlo especificado mejor: cuando pienso en código integrado y abierto, pienso en LINUX. Publicaremos el código y una imagen precocinada para una raspberry pi. Si un día las frambuesas "bajan", pasaremos a otra cosa incrustada barata. Entonces, ¿parece que mi única esperanza de tener algo que una vez conectado a una computadora se vea como un puerto COM para leer y escribir es usar un dispositivo de clase CDC?
@Caterpillaraoz Para obtener un puerto COM sin software o configuración adicional, debe usar CDC.
@Caterpillaraoz Estoy un poco confundido. Cuando hablas de Linux, ¿es el host o el dispositivo?
El anfitrión. El dispositivo en sí está basado en PIC, debe ser sólido como una roca y súper simple. Hemos estado vendiendo con buen éxito la versión anterior desde 1985, sin cambios. Ahora lo estamos modificando para que se ajuste mejor a las normas de seguridad actuales y para mejorar la eficiencia energética. Creo que simplemente le pondré una salida UART y, para aquellos interesados ​​​​en tenerlo conectado a la red, solo proporcione la imagen sd de raspberry lista para usar y configure la parte usb del PIC para alojar una memoria USB para el registro de datos local.

Querrá mirar los controladores de puerto com ocultos. Si puede hacer que su dispositivo se vea como un puerto com HID, la mayoría de los dispositivos tendrán controladores compatibles con USB HID .

De lo contrario, tendrá que proporcionar controladores a la antigua usanza.

+1 Estoy de acuerdo con tu recomendación. Vea mi comentario sobre el problema de la contaminación de los autobuses de los CDC.