¿Es posible implementar un host en stm32 (sin soporte de hardware) con solo el código del programa para escribir datos en la unidad flash USB? [cerrado]

¿Es posible implementar un host en stm32 (sin soporte de hardware) con solo el código del programa para escribir datos en la unidad flash USB? No encontré ninguna información en Internet sobre este tema. Hay un dispositivo de implementación, pero no un host. Estoy estudiando la especificación usb para la respuesta, pero todavía no la entiendo bien.

Hay cientos de diferentes STM32
¿Te refieres al host USB? ¿Y quieres arrancar eso sin un frimware especial en el STM32?
@EugeneSh. Si, pero tengo uno que no tiene soporte de hardware
¿Qué es el "soporte de hardware"?
@Jasen Sí, me refiero al host USB. Quizás con capacidades limitadas, ya que solo necesito escribir en una unidad USB.
"soporte de hardware" sería el bloque periférico USB OTG (o al menos un dispositivo USB). Y no, este no es un proyecto sensato: solo obtenga un STM32 que tenga el puerto OTG; esa función se ofrece en todo, hasta los M0, incluidos los paquetes TQFP con los que es fácil trabajar. O use una SDCARD en modo SPI o bit-bang incluso en los más primitivos, en lugar de USB.
@MarcusMüller Quiero decir que la función de intercambio ya existe dentro del microcontrolador en un nivel lógico y los registros
@ChrisStratton Entiendo que esto no es razonable, porque no vi a nadie haciéndolo. Pero la respuesta a la pregunta "¿por qué?" No fue encontrado.
Porque el bit-banging USB está a la vanguardia de las posibilidades; y, por lo general, la implementación del lado del dispositivo depende de que el host sea regular mientras toma atajos. Escuché que alguien lo hizo en una hélice, pero ese es un chip extraño. En última instancia, el mayor argumento es que tendrías que estar haciendo grandes cantidades de producción antes de que valga la pena intentarlo.
@ChrisStratton totalmente de acuerdo; será prácticamente imposible manejar también un sistema de archivos completo mientras se hace fahrplan.events.ccc.de/congress/2016/Fahrplan/events/8031.html
El sistema de archivos probablemente no sea realmente un problema en absoluto: esa parte se puede hacer tan lentamente como sea necesario, en realidad se trata solo de almacenar y avanzar en el estado.
@ChrisStratton bueno, si necesita adaptar todo su firmware solo para cumplir con el tiempo del autobús que está conduciendo, ¿cómo sigue intercambiando datos? (Mi elección de redacción fue desafortunada: no me refiero al sistema de archivos como estructura de datos, sino al hecho de que alguien tiene que manejar los datos mientras todavía trata con USB)

Respuestas (1)

¿Por qué la función de host no se puede implementar con hardware solo para dispositivos? Porque el USB no es simétrico con respecto al host y los dispositivos.

En el lado del dispositivo, la función USB es admitir el protocolo USB básico llamado "SIE", Serial Interface Engine. Este motor incluye la capacidad del dispositivo para RECIBIR solicitudes de host, comenzando con "tubería predeterminada", y responder correctamente obteniendo datos con respuesta ACK, o enviando datos y esperando que el host ACK complete las transacciones. Debido a las limitaciones de tiempo de USB (tiempo de respuesta de 1,7 us), la etapa final de la transacción de control no se puede implementar por medios de software, y la mayoría de las partes de los motores SIE del dispositivo están codificadas por hardware. Otras funciones de SIE son aceptar la asignación de direcciones y aceptar/habilitar la configuración, lo que concluye la fase de enumeración del protocolo de conexión USB. Luego, el SIE admite IN/OUT/otros conductos básicos, dentro de las mismas restricciones de protocolo. En definitiva, la función del dispositivo es RESPONDER.

Debido a estas limitaciones de hardware, es imposible usar el motor del dispositivo para la función de host, principalmente porque las funciones del host son completamente opuestas a las funciones del dispositivo. El manejo del bus sigue máquinas de estado muy diferentes. El host debe GENERAR paquetes de tramas periódicas e INICIAR todas las transacciones. Y luego proporcione un flujo fluido de datos, todo generalmente hecho usando hardware Direct Memory Access. El host debe proporcionar la función de alimentación del puerto y la función de reinicio del puerto, que no está presente en las implementaciones del dispositivo.

Estas son las principales razones por las que las MCU están diseñadas con controladores de hardware de dispositivo y hardware de host separados.

Sin mencionar que en realidad estaría encantado si alguien estuviera en una capa física y fuera capaz de usar FS USB con un STM32 barato. No es como si pudieras usar LS para hablar con un dispositivo de almacenamiento masivo, ¿verdad? Y hacer LS (dispositivo) en un Cortex-M es apenas posible en el software, incluso con mucha buena voluntad del lado del anfitrión.
@MarcusMüller, si tiene USB PHY externo a través de UTMI/ULPI, podría ser posible crear un host FS utilizando BYTE-banging, si tiene acceso directo al puerto UTMI. que no sueles tener. Sin embargo, puedes hacer un envoltorio FPGA. Y sí, no hay almacenamiento masivo a velocidades LS.
sí, pero agregar un FPGA solo para no tener que comprar un MCU que viene con acceso UTMI o hardware de controlador de host dedicado real sería... un movimiento sorprendente, por decir lo menos. Sin mencionar el hecho de que la cantidad de inteligencia básica necesaria para manejar un potencial 2 7 -el bus de dispositivos de dispositivos mixtos podría ser un poco más intenso de lo que un dispositivo "tonto" necesita poder hacer.
¿Es posible implementar un host en stm32 (sin soporte de hardware) con solo el código del programa para escribir datos en la unidad flash USB? [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v