Tengo la intención de construir algunos chips de monitoreo doméstico basados en Atmega. Quiero controlar la temperatura, la humedad y los niveles actuales. El monitoreo del nivel de corriente se haría con una captación inductiva en las líneas de CA. Además, quiero tener algunos pines en cada monitor que se puedan usar como GPIO controlado de forma remota.
Mi plan es usar chips Attiny84 para implementar esto. Cada placa se alimentaría con +15 VDC y +7 VDC. Puedo regular esto con reguladores de la serie 780x a +5 VDC y +12 VDC para alimentar los chips y cualquier otro sensor o relé que desee.
La entrega de energía usaría dos pares en cable Cat5e. Los dispositivos deben conectarse en cadena. Esto deja dos pares en el cable restante. Por lo que he leído, RS-485 parece una solución atractiva para datos y control. El último dispositivo necesita una resistencia de terminación conectada a él, pero eso debería ser fácil.
Si entiendo correctamente, agregar un chip a mi circuito como un MAX485 solo agrega la capacidad física para la señalización RS-485. Todavía necesito una implementación de software para comunicarme y, además, un protocolo real para que múltiples dispositivos intercambien datos. Tendría hasta 12 dispositivos conectados en cadena con un solo maestro. En un sistema RS-485 semidúplex, el bus actúa básicamente como una línea compartida.
El dispositivo maestro realizaría las siguientes funciones en orden durante cada ronda de comunicación.
Enviando una señal de sincronización. Este sería un patrón de bytes conocido, seguido de un identificador y una suma de comprobación. El identificador sería un identificador único para esta comunicación "ronda". Además, esta secuencia de datos incluiría el identificador de un dispositivo esclavo que está permitido en esta ronda para enviar datos.
Esperando un período de gracia. Este período de gracia se utiliza para permitir que cualquier dispositivo desconocido transmita al maestro una solicitud para unirse a la red.
Recibir datos del dispositivo esclavo designado en los datos de sincronización enviados en el paso 1.
Envío de comandos de control a cualquier número de dispositivos esclavos. Esto incluye comandos GPIO y reconocimientos de unión a la red. Todos los comandos de control deben ser reconocidos posteriormente por el esclavo en una transmisión de regreso al maestro.
Los dispositivos esclavos estarían en uno de dos estados
No reconocido por el maestro. Se sincroniza en la señal de sincronización y transmite en el período de gracia. En una situación ideal, el maestro transmite un acuse de recibo durante el paso 4 de la próxima ronda de comunicación. Si el dispositivo no recibe esto, espera un número aleatorio de rondas antes de volver a intentarlo. Esto permite que eventualmente se resuelvan las colisiones en el período de gracia causadas por múltiples dispositivos que intentan transmitir.
Reconocido por el maestro. El dispositivo transmite datos del sensor cuando lo indica la señal de sincronización enviada por el maestro. El dispositivo también envía reconocimientos de comandos de control durante este período de tiempo. Ignora las comunicaciones hacia y desde otros esclavos con el maestro.
La idea detrás de esto es que la implementación de RS-485 en el controlador Atmega será solo software. Obviamente, el dispositivo no puede transmitir y recibir datos todo el tiempo o no sería útil como dispositivo sensor. La duración de una ronda en el mundo real debe ser lo suficientemente grande como para que el error en el oscilador integrado de chips sea insignificante. De esta manera, la sincronización basada en la señal del maestro se puede mantener durante varias rondas sin necesidad de recibir o transmitir datos.
Durante la fase de unión, esto permite la sincronización y permite que el esclavo identifique correctamente el período de tiempo para transmitir una solicitud de unión.
Una vez que el esclavo está en la red, permite que el dispositivo sepa cuándo escuchar para obtener permiso para transmitir y recibir datos. También significa que el dispositivo tiene una opción para "saltar" una ronda o rondas de comunicaciones para realizar mediciones de sensores, comandar GPIO o lo que necesite. La teoría es que si al dispositivo solo se le permitió enviar datos del sensor, no se le pedirá que lo haga nuevamente de inmediato, ni tampoco tiene ningún dato nuevo.
El problema con esto es que, dado que un esclavo sale efectivamente de la capa de comunicaciones durante al menos una ronda, todos los comandos a los esclavos deben reconocerse con un mensaje de vuelta al maestro. Esto permite que el maestro simplemente retransmita comandos hasta que se reconozca. Esto también significa que los comandos deben ser descripciones de estado, no cambios de estado. Existe una posibilidad muy real de que un esclavo ejecute un comando más de una vez. No sé exactamente cómo funcionarán los reconocimientos, pero probablemente solo será un mensaje que constará de un número de identificación y una suma de verificación.
Cualquier suma de verificación que use en este sistema debe ser económica de calcular porque lo haré en chips que solo tienen una velocidad de reloj de aproximadamente 8 Mhz y son computadoras de 8 bits.
El mayor inconveniente de este sistema que puedo ver es que si todos los esclavos se apagan y encienden por alguna razón, todos colisionarán cuando intenten unirse a la red en el período de gracia. Esto significa que puede pasar mucho tiempo hasta que todos vuelvan a unirse a la red.
¿Me estoy perdiendo algo significativo con esto? ¿Hay alguna decisión importante que deba tomar que haya ignorado por completo? ¿Es correcto mi entendimiento de RS-485 como una línea de gran fiesta?
El mayor inconveniente de este sistema que puedo ver es que si todos los esclavos se apagan y encienden por alguna razón, todos colisionarán cuando intenten unirse a la red en el período de gracia. Esto significa que puede pasar mucho tiempo hasta que todos vuelvan a unirse a la red.
Si tiene un número limitado de direcciones potenciales (por ejemplo, 256), el maestro siempre puede sondear una dirección esclava actualmente desconectada para ver si ha entrado en acción. Entonces, si tiene 20 esclavos activos, entonces el maestro sondea un esclavo número 23 en cada "ronda" e incrementa numéricamente la dirección_esclavo_desconectado para la próxima "ronda". Solo tomará unos segundos hacer suficientes rondas para encontrar un nuevo esclavo y luego el trabajo estará listo.
No es necesario tener un período de gracia; solo una ranura de esclavo más hará el truco y cuando se encuentra un nuevo esclavo (o un esclavo errante), aparece como "activo".
Y sí, RS485 es una capa física adecuada para esto.
Mi plan es usar chips Attiny84 para implementar esto. Cada placa se alimentaría con +15 VDC y +7 VDC. Puedo regular esto con reguladores de la serie 780x a +5 VDC y +12 VDC para alimentar los chips y cualquier otro sensor o relé que desee.
Usaría reguladores de caída baja y le daría un poco más de margen al voltaje de caída; tal vez habrá una inducción de voltios del cableado de CA de su hogar local y esto significa que los reguladores necesitan un poco más de espacio para regularse correctamente.
También consideraría usar la codificación Manchester para que pueda filtrar los datos recibidos sin temor a la corrupción. La polarización de 100 kohm después del capacitor debería estar bien, sin importar cuántos esclavos tenga en su lugar, es decir, no destruirá la coincidencia de impedancia de extremo a extremo del cable. No sé a qué velocidad de datos pretende ejecutar, pero trabajar a 9600 baudios o más parece sensato para ayudar al filtro de paso alto a bloquear cualquier pertubación de CA. Sí, sé que RS485 es un bucle de corriente, pero si puede inyectar un poco más de seguridad de hardware en la etapa de diseño, dará sus frutos.
Diseñar para la codificación Manchester también le brinda una mejor oportunidad de implementar enlaces de RF en caso de que sea necesario en el futuro.
Solo algunas ideas sobre cómo hacer esto si escribe su propio protocolo.
En el nivel del cable, RS-485 es una "línea compartida". RS-485 es fácil de implementar cuando hay un solo maestro. Si sus dispositivos no requieren conectividad "P2P" (p. ej., al sensor de corriente no le importa cuál es la humedad), Modbus es una solución comprobada y simple. No reinventes la rueda.
He usado FreeMODBUS con muchos AVR para implementar esclavos (está bastante inflado, pero la memoria es barata). Puede comprar un adaptador USB<->RS485 y ejecutar software como qModMaster para probar su sensor o usar libmodbus para escribir sus propios programas.
Si necesita "multimaestro", entonces RS-485 es una muy mala elección y su control de acceso medio será complejo (estuve allí, lo hice). En ese caso, CAN sería la opción habitual.
Cuando conecte muchos dispositivos a un solo bus, asegúrese de no exceder la carga unitaria máxima de sus transceptores.
krambo
eric urbano
Tom O´Connor