Dispositivo que usa un puerto USB para descargar aplicaciones en una aplicación / modelo ejecutivo. ¿Qué clase debería ser?

1

Entonces, estoy construyendo un dispositivo (es una lámpara LED RGB programable, alimentada por USB, así que es bastante tonta :) pero este problema surge también en contextos más serios, como cuando un PLC proporciona una interfaz USB para la descarga de la aplicación al PLC) que va a utilizar una aplicación / modelo ejecutivo para el firmware: el ejecutivo está programado en Flash, implementando el dispositivo USB y las funciones principales de E / S, así como un intérprete para el firmware de la aplicación, que se compila en algún tipo de formato intermedio antes de descargarlo en el dispositivo, que lo almacena en un espacio de memoria separado (una EEPROM o un Flash separado).

Sin embargo, esto plantea la pregunta de "¿qué clase debería ser mi dispositivo?":

  • La clase de proveedor siempre es una opción, pero es algo a lo que preferiría no recurrir a menos que tuviera que hacerlo, ya que hace que la herramienta sea mucho más molesta sin ganarme mucho con una solución "tonta", a menos que ¿Existen protocolos estándar de facto de facto de proveedores que puedo seguir para esto?

  • Usted pensaría que DFU tendría sentido, pero está realmente diseñado para el firmware de dispositivo monolítico, no las aplicaciones en una aplicación / modelo ejecutivo

  • El almacenamiento masivo no es fácil de implementar (debido a que tiene que lidiar con conjuntos de comandos optimizados para dispositivos de almacenamiento complejos del orden de GB o TB, con más cosas dentro de ellos que una EEPROM simple, aleatoriamente accesible o los gustos)

  • CDC tiene un par de opciones: CDC-ACM funciona en todas partes, pero requiere un poco más de gook para lidiar con el negocio del comando encapsulado. Linux también admite CDC sin un modelo de control a través del controlador usb-serial "genérico", pero no está claro si Windows puede ser convencido para que soporte una implementación de CDC "esquelética" sin tener que escribir código. (Puedo sacrificar el soporte de Windows en esta aplicación, pero sería bueno tenerlo incluso si está en un estado "debería funcionar").

  • HID también ofrece un par de opciones: uno puede implementar un "conducto flexible" sobre HID si el CDC no es una opción por alguna razón, o también es posible hacer protocolos más sofisticados a través de HID. Esto tiene la ventaja de que tanto Windows como Linux tratan bien con hablar con los dispositivos HID de la zona del usuario, pero también tienen sus inconvenientes, ya que esto no es lo que HID pretendía hacer.

  • El Protocolo de transferencia de medios ofrece una alternativa de almacenamiento masivo que funciona más en la línea de un sistema de archivos (y, por lo tanto, es más simple en algunos aspectos) pero tiene el inconveniente de que no es compatible de forma muy clara en Windows (Explorer lo maneja correctamente) , pero no se maneja limpiamente desde el punto de vista de la secuencia de comandos / línea de comandos en absoluto). Linux tiende a ser un poco delicado con los dispositivos MTP también ...

¿Alguien por ahí sabe lo que se ha hecho antes en este tipo de aplicación?

    
pregunta ThreePhaseEel

1 respuesta

0

Un dispositivo que al reiniciarse comienza como DFU, luego, mientras se desconecta y vuelve a conectarse como VCP. O puede realizar un comando que lleve el dispositivo del modo VCP al modo DFU.

Tal dispositivo existe, un clon de Arduino en STM32. enlace: enlace

    
respondido por el Marko Buršič

Lea otras preguntas en las etiquetas