¿Hay alguna diferencia entre ambos, o es sólo una cuestión de abstracción? Mi intuición dice que no hay diferencia, pero me encantaría estar equivocado.
Respuestas
¿Demasiados anuncios?
Usuario no registrado
Puntos
0
Un periférico controlador de SPI real en la MCU a menudo puede funcionar mucho más rápido que golpear con bits la interfaz. Por supuesto, depende de la MCU, pero no me sorprendería ver un controlador SPI funcionando a más de 30 MHz, mientras que el bit banging podría estar limitado a alrededor de 1 MHz (si tienes suerte).
Pero hay algo más que eso. Cuando el bit-banging, el MCU está ocupado en el bit-banging. Está desplazando los datos hacia fuera y manipulando las líneas GPIO. Es decir, no puede estar haciendo nada más. Cuando se usa un controlador SPI, el controlador está ocupado haciendo todas esas cosas y la MCU está libre para hacer otras cosas.
Así que con un controlador SPI real, la transferencia SPI real es mucho más rápida y la MCU recupera algunos ciclos que puede utilizar para hacer otras cosas.
Kevin Read
Puntos
5544
No hay ninguna diferencia en cuanto a que se puede conseguir el mismo resultado utilizando ambos métodos, pero hay algunas razones por las que se puede elegir uno sobre el otro.
El uso de un periférico SPI liberará al procesador de tener que preocuparse de 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 utilizará menos energía que el bit banging I/O. Puede haber casos en los que se quiera hacer un bit bang de E/S para interconectar con SPI si tu aplicación exige que elijas un procesador sin un periférico SPI. Por razones de cordura, yo recomendaría evitar eso a menos que sea absolutamente necesario.
RelaXNow
Puntos
1164
El SPI es un Sincrónico con el maestro controlando el reloj. Esto significa que si eres el maestro, puedes elegir la velocidad del reloj y la temporización. Los dispositivos esclavos tendrán algún límite superior en la frecuencia de reloj que pueden manejar, pero normalmente no les importa lo lento que sea el reloj por debajo de eso. Más concretamente, suele haber un tiempo mínimo que cada esclavo necesita para ver el reloj en estado alto y bajo antes de poder conmutar de nuevo, y habrá unos límites mínimos de preparación y retención de datos en la línea de datos que rodean el flanco de reloj en el que el esclavo lee la línea de datos.
Por ello, implantar un maestro SPI en el firmware es realmente sencillo. He hecho esto a menudo como una 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 el firmware es lo más fácil que se puede hacer.
Muchos dispositivos esclavos SPI son bastante rápidos, por lo que a menudo los tiempos mínimos de reloj y configuración se cumplen simplemente asegurándose de que cada uno de ellos tiene al menos un ciclo de instrucción. 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 eso tampoco es difícil de garantizar. El bucle de bits SPI de bajo nivel requiere hacer algún desplazamiento del siguiente bit de salida a su posición, agarrar el bit de entrada, y comprobar el contador del bucle. Por lo general, se puede cumplir con los requisitos de tiempo mínimo de dos o tres ciclos, simplemente organizando el momento de conducir y muestrear las líneas con algunos de los otros gastos generales insertados en los lugares correctos. Si la velocidad es importante, puedes usar el preprocesador del ensamblador para escribir un bucle desenrollado. Con técnicas como esta, a menudo se puede lograr un SPI puro de firmware a la velocidad que el dispositivo esclavo puede manejar de todos modos.
Hay algunas ventajas de hacer el maestro SPI en el firmware. El hardware SPI es a veces un poco ridículo en la forma en que puede ser configurado. Siempre está la cuestión de qué es exactamente lo que se supone que sucede inmediatamente cuando se afirma la selección de esclavo. ¿Se escribe entonces 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 son enclavadas en el flanco descendente? A veces esto importa, a veces no. Con un firmware SPI maestro, puedes ser más indulgente y posiblemente usar la misma rutina para comunicarte con diferentes esclavos. Por ejemplo, puedes asegurarte de que la línea de datos MOSI (Master Out Slave In) es estable en ambos flancos del reloj. El hardware SPI generalmente no hará eso, por lo que dicho hardware necesitaría ser reconfigurado dependiendo del esclavo con el que se esté comunicando en ese momento.
Otra ventaja de un maestro SPI de firmware es que se puede elegir un número arbitrario de bits por secuencia SPI. El hardware suele estar limitado a múltiplos de 8 bits. La mayoría de los dispositivos están diseñados para permitir transferencias de bytes enteros, pero a menudo no los requieren. Por ejemplo, un A/D de 10 bits probablemente enviará los 10 bits de datos primero, y luego enviará 0 o basura después de eso, si sigues haciendo el reloj. Si usas el hardware SPI, te verás forzado 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 sólo transfiere el mínimo requerido de 10 bits.
La principal ventaja de los maestros SPI por hardware es que el firmware puede iniciar una transferencia de bytes y luego ir a hacer otra cosa. La sincronización también puede ser normalmente más rápida de lo que puede lograr incluso un bucle de firmware desenrollado. Ten en cuenta que aunque estas dos ventajas pueden ser importantes en ciertas circunstancias, a menudo son irrelevantes. La mayoría del código SPI que utiliza el hardware para transferir un byte entra inmediatamente en un bucle de espera para que el hardware termine la transferencia. Comprueba también los requisitos de temporización de los esclavos. Los dispositivos SPI son generalmente rápidos en su conjunto, pero hay casos en los que es necesario ralentizar el hardware de todos modos para que coincida con la velocidad máxima que el esclavo puede manejar.
Todo ello desde el punto de vista del maestro. En resumen, a menudo hay pocas ventajas en usar el hardware SPI como maestro, e incluso algunas ventajas en no usarlo a veces. Sin embargo, todo esto es diferente para los esclavos. Dado que el maestro controla el reloj, los esclavos tienen que estar preparados para lo que haga el maestro siempre que éste lo haga. Los requisitos de tiempo suelen ser bastante cortos en relación con los tiempos de instrucción, por lo que tener un hardware que implemente un esclavo SPI suele ser lo que se desea.
Puedes hacer esclavos SPI en firmware, pero es complicado, tienes que contar los ciclos y la latencia cuidadosamente, y normalmente acabas implementando algún subconjunto del protocolo que sabes que usa tu maestro en particular. Por ejemplo, una vez tuve que diseñar un equivalente digital de una vieja placa controladora analógica (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 se conectaba al 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 leer los valores medidos. Implementar ambas cosas en un solo procesador era complicado, e incluía averiguar qué subconjunto del protocolo SPI del hardware D/A y A/D utilizaba realmente el maestro existente. También implicaba un procesador que pudiera funcionar significativamente más rápido que la velocidad del reloj SPI. Al final, utilicé tres interrupciones, una para cada selección de esclavo y otra para el flanco de subida de la línea de reloj. Esta última tenía que 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 maestro SPI de firmware 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 despertar y pensar muy cuidadosamente sobre la sincronización, la latencia, y similares.
Steven M. Cherry
Puntos
642
Depende de para qué hagas el SPI. Si tu interés es obtener las tasas de datos más altas, el hardware es siempre más rápido que el bitbanging (por ejemplo, el chip arm cortex en el teensy 3 puede enviar datos a 22Mbps utilizando el soporte SPI por hardware, frente a ~4.5Mbps con bitbanging (también puede manejar números arbitrarios de bits por transferencia de 3-16 - ¡útil cuando se envían datos en trozos de 12 bits para ciertos controladores de led!) En avrs de 16Mhz, la diferencia es un poco menos extrema, la tasa de datos más alta con el hardware parece ser alta 4/baja 5Mbps, mientras que el bitbanging es alrededor de 2.3Mbps).
Además, si utilizas el soporte de hardware, de nuevo, dependiendo del microcontrolador en cuestión, tienes opciones disponibles para utilizar los controladores DMA para desplazar tus datos hacia fuera, dejando que tu código vuelva a hacer otras cosas potencialmente más interesantes que cuidar la escritura de datos.
Todo lo anterior depende de si el hardware SPI es o no una opción.
shash
Puntos
668
