Línea serie de multiplexación

Question

He construido este Sensor de identificación para una pista de coches de slot Scalextric, basado en un PIC12F629. El sensor ID envía el ID de un coche detectado como una señal RS232 en un pin (nivel TTL).

Mi pregunta es, ¿cómo puedo recibir datos de unos cuatro de estos microcontroladores en la USART de otro microcontrolador (PIC18F2550)?

Se me ocurrieron estas posibilidades:

1. Simplemente conecta todas las líneas serie "directamente" al pin RX del PIC18 y espera que dos coches no pasen ningún sensor tan cerca en el tiempo para que las señales se superpongan. Esto podría ser un buen comienzo y probablemente funcionará el 99,9% de las veces. Es decir, la probabilidad matemática de que dos coches sean detectados tan cerca en el tiempo no puede valer el esfuerzo de las otras sugerencias... después de todo, es un proyecto de hobby.
2. Implementar una señal de ocupado que se levanta cuando los sensores de identificación envían datos y se comprueba antes de enviarlos.
3. Añade algún chip multiplexor de lujo que se coma las señales en serie y las saque en una sola línea.

Cada chip sensor de identificación estará codificado con un identificador que se envía como parte de los datos, para que puedan separarse en el extremo receptor.

Actualización: Se ha añadido algo más de información sobre el hardware del sensor.

Answer 1

Si configuras tu protocolo para que los coches sólo respondan cuando el controlador les pregunte, entonces puedes atar (a nivel lógico, al menos) a todos.

El truco está en saber si tienes un RS-232 real (con 1 = -6 a -12 V, y 0 = 6 a 12 V) o sólo una línea lógica estándar (1 = VCC, 0 = GND). La hoja de datos o un osciloscopio deberían responder a esto.

Si se trata de una lógica estándar, podría ser muy fácil. Si tus sensores pueden controlar sus drivers de salida, entonces prográmalos para no conducir la salida a menos que un mensaje esté saliendo. Si tienes que dejar el driver de salida encendido todo el tiempo, haz que conduzca un transistor o dos para hacer una configuración de "colector abierto", conecta todos los colectores de los sensores juntos, y tira de la línea conectada a VCC y conéctala al pin RX de tu controlador principal. Esto funciona porque el protocolo RS-232 está en un estado lógico 1. Si se utilizan niveles de señal RS-232, hay que cambiar un poco la configuración del transistor, pero en el fondo seguirá siendo de colector abierto.

El controlador principal simplemente pide a cada sensor sus datos en secuencia. Cada sensor responde cuando se le pregunta. De esta manera no tienes más de uno manejando la línea RX a la vez, que es el objetivo principal.

Ahora bien, si usted no puede conseguir que tus sensores hablen sólo cuando se les habla... entonces tu problema se ha complicado mucho. Tanto que la respuesta simple es dar a cada sensor su propio puerto serie, tal vez usando controladores de 8 pines como gestores de sensores, que luego pueden ser enganchados en un bus serie cooperativo. Otras técnicas, como la detección de colisiones con retransmisión de mensajes (como hacía Ethernet 10base-T), son mucho más complejas.

Answer 2

Si su sensor puede acomodar una línea de "listo", y diferir cualquier evento que llegue cuando no esté afirmado, transmitiéndolo cuando lo esté, su mejor apuesta puede ser enviar un cable ocupado separado a cada sensor y usar una puerta "AND" para combinar las señales de todos los sensores. Yo sugeriría que si tiene cuatro sensores, debería hacer un ciclo de los cables "listos" en forma redonda, con algún tiempo "muerto" entre ellos (cuando nadie está "listo"); si un byte entra durante el tiempo "muerto", asume que fue enviado por el último sensor activo. Establezca el tiempo "listo" lo suficientemente largo como para que un sensor pueda reaccionar, y el tiempo muerto lo suficientemente largo como para que un sensor tenga tiempo de terminar de transmitir un evento que ocurra justo antes de que su línea "lista" se desactive.

Editar

Basado en otras descripciones, dado que aparentemente cada sensor tiene un número de identificación conocido y distinto, estoy pensando que el mejor enfoque puede ser tener una única línea serie que esté conectada a una salida PWM a través de una resistencia paralela y un diodo, de manera que se suba durante 1.900us cada 2ms pero se baje durante 200us (si se pudiera tener un interruptor PWM entre activo-bajo y flotante, sería aún mejor). En cuanto se vea un coche, un sensor debería iniciar la siguiente máquina de estados, llevando la cuenta de cuántas decenas de microsegundos han transcurrido desde que empezó a ejecutarse.

1. Espere a que la línea de datos sea alta.
2. Espere a que la línea de datos esté baja.
3. Borrar el temporizador de línea baja
4. Espera a que la línea de datos se ponga alta, incrementando el temporizador de línea baja (y el temporizador principal) mientras espera.
5. Si el temporizador indica que la línea estuvo baja menos de 200us, vuelva al paso 2
6. Siga incrementando el temporizador de línea baja mientras espera que la línea baje, hasta que el temporizador alcance una duración que sea única para el ID del nodo. Si la línea baja dentro de ese tiempo, vuelve al paso 3.
7. Ponga la línea de datos en salida, transmita los datos a una velocidad de 16us/bit más o menos (manejando la línea activamente tanto para alta como para baja), y empiece a buscar el siguiente coche. Tenga en cuenta que los datos deben incluir el número de intervalos de 10us que han transcurrido entre ver el coche y comenzar la transmisión.

Utilizando una UART, este enfoque debería permitir procesar los coches que llegan a cualquier sensor, en cualquier orden, y resolver sus tiempos en 10us, con la condición de que los coches se procesarán secuencialmente a un ritmo de uno cada 2ms, y los sensores estarán "ciegos" entre el momento en que ven un coche y la CPU principal llega a procesarlo. A menos que haya un número realmente enorme de sensores, esto no debería suponer un problema. Ten en cuenta que la CPU principal no tiene que tener una sincronización precisa en nada más que en su salida PWM. Todo lo demás se puede inferir del flujo de datos en serie (incluyendo las "pausas largas" resultantes de los pulsos "bajos" del PWM).

Answer 3

Utiliza la multiplexación por división de tiempo. El maestro envía un impulso de sincronización en una línea separada que los esclavos utilizan para reiniciar un temporizador. Cuando un esclavo tiene datos que enviar, espera hasta que el temporizador sea igual a (número de esclavos * ancho de la franja horaria) antes de enviarlos. El intervalo de tiempo debe ser lo suficientemente largo para enviar el paquete y tener en cuenta la inexactitud del reloj entre los sensores.

Eléctricamente, es posible que desee pull-up de la línea TX compartida y alternar entre 0 y tri-estado para transmitir en lugar de abastecerse de corriente para afirmar un 1.

Answer 4

Usted puede implementar un protocolo MODBUS en modo RTU con la interfaz RS485 que funciona bien en el PIC (No estoy seguro de su PIC).

Puedes tener una línea multidrop para descansar tus diferentes dispositivos microcontroladores y tener una buena comunicación entre ellos en la UART serial.

Puedes hacer que tu PIC18F2550 sea un maestro que inicie la transacción desde cualquier otro de los 4 controladores.

Answer 5

He encontrado este con una solución llamada BlackNet. Se basa en un protocolo bastante sencillo en el que la idea es que cada nodo de la red tenga su propia franja horaria. Es decir, es una especie de lógica round-robin. El último imagen en la página muestra un esquema con la menor cantidad de componentes necesarios para que funcione.

He utilizado esta idea y sólo he conectado los dos sensores que he construido directamente al pin RX del PIC18F2550. Sin embargo, no he implementado el protocolo round-robin, sino que me he limitado a introducir los datos en la línea (y esperar que sólo uno transmita a la vez). Hasta ahora ha funcionado bastante bien...

Para los futuros lectores: Si es fundamental que tus datos lleguen siempre, la solución que he utilizado probablemente no sea una buena idea. Sin embargo, si rara vez envías datos y puedes vivir con la posibilidad de que choquen y quieres la solución más fácil posible, creo que esta es lo suficientemente buena.