Objetivos
Material requerido.
 |
Kit inicio UNO |
 |
Kit Inicio Mega |
https://learn.sparkfun.com/tutorials/serial-peripheral-interface-spi
Paciencia y buena disposición de espíritu, porque esta va ser una de esas sesiones teóricas que si bien te puedes saltar casi sin que se note, es conveniente que entiendas los conceptos que hay detras de un bus de comunicaciones.
Esta sesión es prácticamente una traducción literal de la página de Sparkfun en inglés sobre el mismo tema, que podéis encontrar en
https://learn.sparkfun.com/tutorials/serial-peripheral-interface-spi
Los errores que haya en esta sesión son ciertamente míos, pero lo que de bueno hay es directamente atribuible a Sparkfun.
La comunicación serie
Si ya tenemos un protocolo de transmisión de datos asíncrono como las puertas series que vimos anteriormente ¿Por qué necesitamos otro bus serie? ¿Hay algo malo con la comunicación serie del que no hayamos hablado?
Teóricamente no hay ningún problema, pero ya sabéis que el demonio está en los detalles, y así dijimos que bastaba con definir una velocidad común para transmitir datos inmediatamente entre dos puntos, pero la realidad es terca.
No tenemos ninguna garantía de que ambos extremos estén, de hecho, a la misma velocidad, lo que puede hacer que enviamos todos nuestros datos y la otra parte no se entere, bien porque no está a la misma velocidad o bien porque sencillamente esta en babia.
No tenemos ninguna manera de garantizar que la otra parte ha recibido el mensaje, sencillamente suponemos que todo ha ido bien.
El primer problema que suele aparecer es que las velocidades a en los dos extremos sean diferentes. Fin de la comunicación (Seguro que a estas alturas ya habéis experimentado este problema entre Arduino y la consola en algún momento)
El segundo problema es que la forma de fijar la velocidad pactada se debe hacer con un reloj propio a cada extremo. O sea dos relojes a poner de acuerdo, Murphy se frota las manos. Es cuestión de tiempo de que pequeñas diferencias entre los cuarzos que los sincronizan den lugar a problemas de comunicación.
Para corregir este problema, en las comunicaciones seria se pacta otro aspecto que hasta ahora no habíamos comentado, Se añade un par de bits extra a la comunicación en forma de un bit de Start y otro de Stop. (Fijaros que para enviar 8 bits de datos ahora tenemos que enviar 10 bits)
De este modo aumentado en un 25% (8bits / 2) en la carga de trasmisión serie, podemos re sincronizar los relojes de ambos extremos usando estos bits de Start y Stop.
Pero esto supone además un aumento en el hardware para decodificar la señal y sincronizar los relojes. Y puestos a complicar las cosas ¿Porque no buscar una solución síncrona al problema?
La solución que dio la industria fue múltiple, entre las que se encuentran el bus I2C que ya vimos en su día y el bus SPI que vamos a ver ahora.
El bus SPI, Una solución síncrona
El SPI es un protocolo de comunicación síncrona de 4 hilos, entre dispositivos electrónicos presentado por Motorola en 1982, que ha ganado bastante aceptación en la industria como sistema de comunicación de muy corta distancia, normalmente dentro la placa de circuito impreso.
Es un protocolo de transmisión que permite alcanzar velocidades muy altas y que se diseñó pensando en comunicar un micro controlador con distintos periféricos y que funciona a full dúplex (Una forma retorcida de decir que puede enviar y recibir datos al mismo tiempo).SPI utiliza una solución síncrona, porque utiliza unas líneas diferentes para los datos y el Clock. El Clock es una señal que indica al que escucha exactamente cuándo leer las líneas de datos, con lo que el problema de perdida de sincronía se elimina de raíz.
Por eso mismo, no se necesita pactar la velocidad de transmisión, ya que será el Clock quien fije la velocidad y puede ser variable a lo largo de la comunicación sin que sea un problema (Aunque por supuesto según el dispositivo habrá un límite de velocidad).
Uno de los motivos por los que SPI es tan popular es que el hardware de recepción puede ser un sencillo Shift register como los que vimos en la sesión N, Lo que es una solución mucho más simple (Y barata) que una UART (Universal Asíncronous Receiver Transmitter o sistema universal asíncrono de recepción y transmisión serie) de comunicación serie.
Como se reciben los datos
En un bus SPI una de las partes genera el Clock al que llamamos master, y el resto son los esclavos, pudiendo haber uno o varios en el bus. A la señal de reloj se le suele llamar CLK por Clock o SCK por Serial Clock.
Cuando el master envía información, lo hace por una línea de datos que normalmente de nombre MOSI (Master Out Slave In) y si el esclavo responde lo hace a través de una línea llamada MISO (Master In Slave Out) siguiendo una de esas tradiciones de imaginación desbordante en los nombres tecnológicos.
Como es el master quien genera el Clock, necesita saber de antemano, si un esclavo va a devolver una respuesta y de que longitud, para mantener el Clock hasta que la transferencia esté completa.
Esto no es normalmente un problema porque cuando el master pide a, digamos un sensor, que le envié una lectura, normalmente sabemos que van ser 2 bytes.
Selección de esclavo Slave Select SS
Hay una última línea de control, llamada Slave Select o SS, que indica a un esclavo que el mensaje que viene es para él, o bien que se reclama que envié una respuesta a una petición del master.
La línea SS normalmente se mantiene HIGH y se activa con LOW, lo que despierta al esclavo seleccionado. Cuando se termina la transferencia la línea se levanta a HIGH y el esclavo se desactiva.
Bus con múltiples esclavos
Hay dos maneras de conectar múltiples esclavos a un bus SPI. Con una línea SS por cada esclavo o en cascada:
En general cada esclavo requiere su propia línea SS para ser activado, y así evitar que dos hablen a la vez, porque el resultado sería ruido inútil. Basta con activar la línea correspondiente y el esclavo esta listo para recibir sus órdenes
Es un sistema cómodo, siempre y cuando no sean muchos esclavos porque podemos necesitar muchas líneas.
Cuando el número de esclavos crece suele ser más frecuente conectarlos en cascada, con el MISO de uno (Salida), conectado al MOSI (Entrada) del siguiente. En este caso solo usamos una única línea SS, que se comparte entre todos los esclavos.
Esta configuración es típica de una situación en la que le master envía datos pero no recibe nada de vuelta, como en el caso de una cadena de múltiples display LEDs ( Matrices de 8×8) , en los que se envía información para ser mostrada pero, no hay datos de vuelta. En este caso incluso podemos desconectar la línea MISO
Por último y para cerrar esta sesión, comentar que naturalmente vuestro Arduino soporta de serie el bus SPI, con una librería estándar que sorprendentemente se llama SPI y que podéis instalar tranquilamente, que gestiona todas las complicaciones y el arbitraje del protocolo.
Comparación con I2C y con puerto serie normal
Ventajas del Bus SPI
Y como en la vida no hay nada gratis, las desventajas son:
Pines SPI en Arduino
Aunque últimamente han aparecido algunas librerías que nos permiten mover de sitio los pines de control del SPI en nuestros Arduino, tradicionalmente estos, estaban fijados a unos ciertos pines.
Eso significa, que para controlar el bus SPI es necesario usar esos pines inexcusablemente, aunque podemos elegir entre dos juegos de ellos, entre ciertos pines digitales, según el modelo y la tabla que especificamos abajo, y usando los equivalentes en el bus ICSP.
Esos pines son:
| Modelo Arduino | MOSI | MISO | SCK | SS Slave | SS Master |
|---|---|---|---|---|---|
| UNO | 11, ICSP-4 | 12, ICSP-1 | 13, ICSP-3 | 10 | Z |
| MEGA | 51, ICSP-4 | 50, ICSP-1 | 52, ICSP-3 | 53 | Z |
| Leonardo | ICSP-4 | ICSP-1 | ICSP-3 | Z | z |
| DUE | ICSP-4 | ICSP-1 | ICSP-3 | z | 4,10,52 |
Los pines ICSP son esos que están a la derecha centrados cuando leemos los rotulos en la placa: [one-half]
Resumen de la sesión
En este curso arduino hemos aprendido lo siguiente: