¿Hay alguna diferencia entre usar un módulo SPI integrado y hacer bit-banging?


Respuestas:


33

Un periférico de controlador SPI real en la MCU a menudo puede funcionar mucho más rápido que la interfaz de bits. Por supuesto, depende de la MCU, pero no me sorprendería ver un controlador SPI funcionando a más de 30 MHz, mientras que los golpes de bits podrían estar limitados a alrededor de 1 MHz (si tiene suerte).

Pero hay más que eso. Al realizar bit-banging, la MCU está ocupada haciendo bit-banging. Está cambiando los datos y haciendo girar las líneas GPIO. Es decir, no puede estar haciendo otra cosa. Cuando se usa un controlador SPI, el controlador está ocupado haciendo todo eso y la MCU es libre de hacer otras cosas.

Entonces, con un controlador SPI real, la transferencia SPI real es mucho más rápida y la MCU recupera algunos ciclos que puede usar para hacer otras cosas.


11

No hay diferencia en términos de que puede lograr el mismo resultado utilizando ambos métodos, pero hay algunas razones por las que elegiría uno sobre el otro.

El uso de un periférico SPI liberará al procesador de tener que preocuparse por generar el tiempo para golpear los pines de E / S, permitiéndole realizar otras tareas computacionales y simplificando su programación de la CPU. Debido a que el periférico está implementado en hardware, funcionará más rápido y usará menos energía que las E / S de bits. Puede haber casos en los que desee realizar un bit bit I / O para interactuar con SPI si su aplicación exige que elija un procesador sin un periférico SPI. Por razones de cordura, recomendaría evitar eso a menos que sea absolutamente necesario.


La razón de la cordura es la basura. A menudo, configurar el hardware SPI exactamente con la configuración que necesita lleva más tiempo leer la hoja de datos periférica SPI que simplemente escribir el código maestro SPI y, por lo tanto, solo tiene que leer la hoja de datos del dispositivo esclavo.
Olin Lathrop

Admito que estaba siendo un poco sensacionalista con mi observación sensata, pero la intención (ciertamente no escrita) era que a medida que aumenta la complejidad de la aplicación, también aumenta la carga de garantizar que el sistema en su conjunto continúe funcionando dentro de los tiempos previstos. Lo he implementado en ambos sentidos y sé que preferiría usar el periférico, incluso si me toma unos minutos adicionales leer la hoja de datos.
Amoch

6

SPI es síncrono interfaz , con el maestro controlando el reloj. Eso significa que si eres el maestro, puedes elegir la velocidad y el tiempo del reloj. Los dispositivos esclavos tendrán un límite superior en la frecuencia de reloj que pueden manejar, pero generalmente no les importa qué tan lento esté el reloj por debajo de eso. Más específicamente, generalmente hay un tiempo mínimo que cada esclavo necesita para ver el reloj en el estado alto y bajo antes de que pueda cambiar nuevamente, y habrá una configuración mínima de datos y límites de retención en la línea de datos que rodea el borde del reloj en el que esclavo lee la línea de datos.

Debido a esto, implicar un maestro SPI en firmware es realmente bastante fácil. He hecho esto a menudo por conveniencia para usar ciertos pines, cuando no había hardware SPI incorporado, o no estaba disponible para ese propósito por cualquier razón. Hacer un maestro SPI en firmware es tan fácil como parece.

Muchos dispositivos esclavos SPI son bastante rápidos, por lo que a menudo se cumplen los tiempos mínimos de reloj y configuración simplemente asegurándose de que cada uno tenga al menos un ciclo de instrucciones de ancho. En ese caso, el código es muy corto y rápido. En algunos casos, un dispositivo esclavo puede requerir dos o tres ciclos de instrucción por fase de reloj, pero tampoco es difícil de garantizar. El bucle de bits SPI de bajo nivel requiere un cambio del siguiente bit de salida a su posición, tomar el bit de entrada y verificar el contador del bucle. Por lo general, puede cumplir con los requisitos mínimos de tiempo de dos o tres ciclos simplemente organizando cuando conduce y muestrea las líneas con algunos de los otros gastos generales insertados en los lugares correctos. Si la velocidad es importante, puede usar el preprocesador del ensamblador para escribir un bucle desenrollado. Con técnicas como esta,

Hay algunas ventajas de hacer el maestro SPI en firmware. El hardware SPI a veces es un poco ridículo en cuanto a cómo se puede configurar. Siempre existe el problema de qué se supone que debe suceder inmediatamente cuando se afirma la selección de esclavos. ¿Se escribe el primer bit en las líneas de datos? ¿Qué pasa si el reloj comienza bajo y las líneas de datos se supone que están bloqueadas en el borde descendente? A veces esto importa, a veces no. Con un firmware SPI master, puede ser más tolerante y posiblemente usar la misma rutina para comunicarse con diferentes esclavos. Por ejemplo, puede asegurarse de que la línea de datos MOSI (Master Out Slave In) sea estable en ambos extremos del reloj. El hardware SPI generalmente no hará eso, por lo que dicho hardware debería reconfigurarse dependiendo del esclavo con el que se está comunicando en ese momento.

Otra ventaja de un maestro SPI de firmware es que puede elegir un número arbitrario de bits por secuencia SPI. El hardware generalmente está limitado a múltiplos de 8 bits. La mayoría de los dispositivos están diseñados para permitir transferencias de bytes completos, pero a menudo no los requieren. Por ejemplo, un A / D de 10 bits probablemente enviará los 10 bits de datos primero, luego enviará 0 o basura después de eso si sigue sincronizándolo. Si usa SPI de hardware, se verá obligado a transferir 16 bits y enmascarar la basura. Todo funcionará bien, pero un maestro SPI de firmware podría ser más rápido que el hardware en este caso debido a que solo transfiere los 10 bits mínimos requeridos.

Las principales ventajas de los maestros SPI de hardware es que el firmware puede iniciar una transferencia de bytes, luego apagarse y hacer otra cosa. El cronometraje también suele ser más rápido de lo que puede lograr incluso un bucle de firmware desenrollado. Tenga en cuenta que si bien estas dos ventajas pueden ser importantes en ciertas circunstancias, a menudo son irrelevantes. La mayoría del código SPI que usa hardware para transferir un byte, inmediatamente entra en un ciclo de espera para que el hardware termine la transferencia. También revise los requisitos de sincronización del esclavo cuidadosamente. Los dispositivos SPI son generalmente rápidos en su conjunto, pero hay casos en los que necesita ralentizar el hardware de todos modos para que coincida con la velocidad máxima que puede manejar el esclavo.

Eso fue todo desde el punto de vista maestro. En resumen, a menudo hay pocas ventajas de usar el hardware SPI como maestro, e incluso algunas ventajas de no usarlo a veces. Sin embargo, eso es todo diferente para los esclavos. Como el maestro controla el reloj, los esclavos deben estar preparados para lo que sea que haga el maestro siempre que lo haga. Los requisitos de tiempo son a menudo bastante cortos en relación con los tiempos de instrucción, por lo que tener hardware que implemente un esclavo SPI suele ser lo que desea.

Puede hacer esclavos SPI en el firmware, pero es complicado, debe contar los ciclos y la latencia con cuidado, y generalmente termina implementando un subconjunto del protocolo que sabe que utiliza su maestro particular. Por ejemplo, una vez tuve que diseñar un equivalente digital de una placa controladora analógica antigua (querían características adicionales que no podían hacerse razonablemente en analógico, y querían algo más pequeño, más barato de producir y más estable). Esta placa interactúa con el resto del sistema a través de un bus SPI. La antigua placa analógica tenía un D / A de dos canales para establecer los valores de control y un A / D de dos canales para volver a leer los valores medidos. Implementar ambos en un solo procesador fue complicado e incluyó averiguar qué subconjunto del hardware D / A y el protocolo A / D SPI que el maestro existente realmente usaba. También envolvió un procesador que podría funcionar significativamente más rápido que la velocidad de reloj SPI. Al final, utilicé tres interrupciones, una para cada selección de esclavos y otra para el borde ascendente de la línea del reloj. Esa última debía ser la interrupción de mayor prioridad en el sistema; de lo contrario, no se podría cumplir el requisito de latencia.

De todos modos, el punto general es que un firmware SPI master es fácil, pequeño, rápido y flexible, y hay pocas razones para evitar hacer uno. Por otro lado, para un esclavo realmente quieres hardware, o tienes que despertarte y pensar con mucho cuidado sobre el tiempo, la latencia y demás.


¿Ha encontrado implementaciones esclavas de microcontroladores que pueden comportarse como dispositivos SPI de hardware típicos (por ejemplo, permitiendo que el maestro le dé una ventaja sobre CS y lea el estado en cualquier momento, y use CS para marcar los límites de los comandos? La mayoría de las implementaciones que he visto no incluso informe si hubo un límite CS entre el byte actual y el anterior.
supercat

@supe: Sí, eso es un problema. El hardware esclavo SPI generalmente ignora los datos de entrada y reloj y mantiene la línea de datos de salida a alta impedancia cuando no se establece la selección de chip, pero generalmente no le dice dónde están los límites de selección de chip. Al menos con el hardware PIC SPI que recuerdo haber usado, tendrías que configurar tu propia interrupción en la selección de chip para eso.
Olin Lathrop

Me preguntaba si sabías de implementaciones decentes. Supongo que no. El problema con el uso de una interrupción de hardware en el cable de selección es que si ocurre una transición en el cable de selección muy pronto después de enviar un byte, el esclavo puede tener dificultades para resolver si sucedió antes o después del byte en cuestión. Me resulta desconcertante que casi todos los chips tengan una implementación esclava SPI, pero parece que ninguno de ellos se puede utilizar como un dispositivo esclavo de hardware SPI típico. La situación es algo así como el puerto esclavo procesador en el PIC en comparación con el 8048.
supercat

El puerto esclavo del procesador 8048 tiene un pin de dirección; cuando los datos se escriben externamente en el 8048, el 8048 bloquea el estado de ese pin y lo pone a disposición de su código (generalmente, el primer byte de un comando se escribirá en una dirección y los parámetros o datos en el otro). Una lectura de una dirección producirá lo que el código 8048 ponga allí, pero el hardware 8048 genera algunos bits que se leen de la otra dirección para indicar si está listo para leer o escribir datos.
supercat

+1 para señalar la diferencia de ser un maestro de golpes de bits (fácil) y un esclavo (mucho más difícil).
tcrosley

1

Depende de para qué esté haciendo el SPI. Si su interés es obtener las velocidades de datos más altas, el hardware siempre es más rápido que el bitbanging (p. Ej., El chip de corteza de brazo en el adolescentes 3 puedo extraer datos a 22Mbps usando el soporte SPI de hardware, en comparación con ~ 4.5Mbps con bitbanging ( también puede manejar números arbitrarios de bits por transferencia de 3 a 16, ¡útil cuando se envían datos en fragmentos de 12 bits para ciertos controladores led!)). En 16Mhz avrs, la diferencia es un poco menos extrema, la velocidad de datos más alta con hardware parece ser alta 4 / baja 5Mbps, mientras que el bitbanging es de alrededor de 2.3Mbps).

Además, si usa soporte de hardware, nuevamente, dependiendo del microcontrolador en cuestión, tiene opciones disponibles para usar controladores DMA para cambiar sus datos, permitiendo que su código regrese a otras cosas potencialmente más interesantes que cuidar los datos. escribir.

Todo lo anterior depende de si el SPI de hardware es o no una opción.


0

Si golpea bit SPI, no puede usar la interrupción SSP para manejar las comunicaciones. Esto no es tan importante para SPI para muchos usos


1
No se mencionó ningún procesador específico, por lo que "interrupción de SSP" es un término sin sentido en este contexto.
Olin Lathrop
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.