Como dice el comentario de Andy Aka, es muy probable que haya más que un solo pin para enviar y recibir datos, y actualmente a la pregunta le faltan detalles importantes. Sin embargo, esbozar una de las opciones podría ayudarlo a comprender los detalles que necesita una respuesta.
Algunos ejemplos del tipo de detalle que pueden ser importantes, sin ningún orden en particular, para responder a la pregunta:
- Velocidad de datos: ¿a qué velocidad deben transferirse los datos?
- latencia: ¿cuánto tiempo puede durar la demora entre el envío y la recepción de datos?
- ¿el bit de datos o el byte están orientados, y es binario arbitrario?
- es la transferencia de una manera o son algunos de los casos de uso que requieren
¿Transferencias bidireccionales?
- por ejemplo cualquiera de los dos puede terminar iniciar una transferencia; Puede Arduino 2 solicitar datos,
¿O solo es controlado por Arduino 1?
- por ejemplo ¿el 'esclavo' siempre estará listo para recibir datos, o es su
posibilidad de que no esté disponible o pueda perder datos, y así
puede necesitar una retransmisión?
- cuántos pines Arduino están disponibles para implementar la transferencia
mecanismo?
- cuánta sobrecarga de CPU es aceptable para lograr la tasa de datos en
el remitente y el receptor están disponibles al 20%, o 10 µs / byte, pueden o
¿Ambos extremos 'bloquean' esperando una transferencia?
- sobre qué distancia va a ocurrir la transferencia, pulgadas (cm),
yardas (m), millas (km)?
El diagrama de esquema sugiere que solo hay una pequeña cantidad de datos en cada transferencia, pero incluso eso no está claro.
La solución más sencilla es conectar los periféricos ATmega SPI de Arduinos juntos, Arduino 1 como maestro y Arduino 2 como esclavo. Esto requiere al menos dos pines, reloj y MOSI, entre Arduino 1 y Arduino 2. Es el mismo número de pines que usaría cualquier solución basada en el registro de cambios síncrono usando chips externos; El periférico SPI a bordo de ATmegas está diseñado para implementar el mismo mecanismo.
Si la transferencia puede ser a veces más rápida o anterior que la del esclavo, Arduino 2, puede usar los datos, entonces un búfer sería un poco de RAM en el ATmega receptor (esclavo, Arduino 2). O se podría usar un pin adicional para enviar datos del esclavo, Arduino 2, al maestro, Arduino 1 para controlar la velocidad de transmisión. El control de flujo se manejaría en software, y no por el periférico SPI.
El periférico SPI de ATmega transfiere 8 bits a la vez, lo que parece comparable al esquema de su solución.
El periférico ATmega SPI es síncrono, por lo que tiene una señal de reloj, generada por el maestro. El reloj se puede detener mientras no haya datos para transferir. El SPI esclavo establecerá una bandera cuando se haya recibido un byte. Así que hay una manera de informar al esclavo que los datos están listos.
Además, el periférico SPI esclavo puede provocar una interrupción cuando se recibe un byte, por lo que una rutina de servicio de interrupción que se ejecuta en el esclavo puede copiar el byte en un búfer en la RAM. Por lo tanto, no es necesario que la transferencia se limite a un byte.
Además, el periférico SPI maestro puede provocar una interrupción cuando se completa la transferencia de un byte, por lo que una rutina de servicio de interrupción podría enviar múltiples bytes de datos desde un búfer en la RAM con una sobrecarga relativamente pequeña.
El periférico SPI es capaz de enviar y recibir datos simultáneamente, por lo que cualquier "handshaking" que el software que se ejecuta en el maestro pueda necesitar para asegurarse de que no está enviando datos demasiado rápido también se puede implementar en su software.
Además, como la velocidad de datos periféricos de SPI puede ser de hasta 4 Mbit / segundo, la velocidad de datos es mayor que una transferencia asíncrona, y es tan rápida como la ATmega podría transferir datos a través de cualquier conexión en serie a un dispositivo externo. Además, la latencia (tiempo de espera) entre el envío de datos desde el maestro al esclavo puede ser bastante baja, a unos pocos ciclos de reloj de más de 2µs. A este ritmo, podría tener sentido enviar cantidades más pequeñas de datos si las necesidades de transferencia de datos son inferiores a un byte a la vez.
Finalmente, el periférico SPI también admite una señal de habilitación o selección, de modo que un maestro puede controlar más de un dispositivo esclavo.
Por supuesto, todo esto podría implementarse en software, sin el uso del periférico SPI, pero utilizando solo la lectura y escritura digital de pines GPIO. Algún beneficio sería que un enfoque de software podría usar cualquier pin disponible, y la transferencia no tendría que estar orientada a bytes, o utilizar un paquete de tamaño de byte. El software se transferirá más lentamente y tendrá una mayor sobrecarga de CPU que el hardware SPI periférico, pero es más flexible.
