Multiplexación de línea serie

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

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

Se me ocurrieron estas posibilidades:

  1. Simplemente conecte todas las líneas seriales "directamente" al pin RX del PIC18 y espere que dos autos no pasen ningún sensor que se cierre a tiempo para que las señales se superpongan entre sí. En realidad, esto podría ser un buen comienzo y probablemente funcionará el 99,9% del tiempo. Quiero decir, la probabilidad matemática de que se detecten dos autos que se acerquen en el tiempo no puede valer el esfuerzo de las otras sugerencias... después de todo, es un proyecto de pasatiempo.
  2. Implemente una señal de ocupado que se emita cuando los sensores de identificación envíen datos y se verifique antes de enviarlos.
  3. Agregue un chip multiplexor elegante que coma las señales en serie y las envíe en una sola línea.

Cada chip sensor de ID se codificará con un identificador que se envía como parte de los datos, para que puedan separarse en el extremo receptor.

Actualización: se agregó más información sobre el hardware del sensor.

Este es realmente un trabajo para CAN. Usar un UART para esto es una chapuza.
CAN incorpora una gran cantidad de equipaje de protocolo y limita su elección de microcontroladores, pero si puede cambiarlo, seguro.
En realidad, creo que CAN es una solución muy exagerada para este pequeño proyecto. Me gustaría mantenerlo lo más simple posible.
Agradezco todas sus respuestas y comentarios. Sin embargo, todavía me gustaría mantenerlo mucho más simple (no soy un experto en electrónica, pero estoy aprendiendo...). Como mencioné en mi primera alternativa, la probabilidad de que ocurra una colisión de datos es muy baja y, si ocurre, no es el fin del mundo (después de todo, es un juguete). Puedo actualizar la solución en el futuro si la encuentro demasiado "frágil". Dé un ejemplo de cómo conectar todos estos sensores PIC al mismo pin RX en el PIC receptor. ¡Gracias!

Respuestas (5)

Si configura su protocolo para que los autos solo respondan a las consultas del controlador, entonces puede vincular (al menos en el nivel lógico) a todos juntos.

El truco es si tiene RS-232 real (con 1 = -6 a -12 V y 0 = 6 a 12 V) o solo una línea lógica estándar (1 = VCC, 0 = GND). O la hoja de datos o un alcance deben responder a esto.

Si es lógica estándar, podría ser muy fácil. Si sus sensores pueden controlar sus controladores de salida, prográmelos para que no controlen la salida a menos que se envíe un mensaje. Si tiene que dejar el controlador de salida encendido todo el tiempo, haga que maneje uno o dos transistores para hacer una configuración de "colector abierto", conecte todos los colectores de los sensores juntos, levante la línea conectada a VCC y conéctela a el pin RX de su controlador principal. Esto funciona porque el protocolo RS-232 está inactivo en un estado lógico 1. Si se utilizan niveles de señal RS-232, entonces debe cambiar un poco la configuración del transistor, pero seguirá siendo de colector abierto en el fondo.

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

Ahora, si no puede hacer que sus sensores hablen solo cuando se les habla... entonces su problema se volvió mucho más difícil. Tanto que la respuesta simple es darle a cada sensor su propio puerto serie, tal vez usando controladores de 8 pines como administradores de sensores, que luego se pueden conectar en un bus serie cooperativo. Otras técnicas, como la detección de colisiones con retransmisión de mensajes (como lo hizo 10base-T Ethernet), son mucho más complejas.

Esperaría, después de haber mirado muy brevemente el enlace publicado, que sería difícil para los controladores remotos observar simultáneamente un comando desde una CPU remota mientras buscan un automóvil. Sin embargo, lo que podrían hacer sería esperar a que llegue un automóvil y luego dejar de observar los automóviles mientras esperan la oportunidad de enviar el que vieron.
@supercat Sí, esa es mi suposición también. Sin embargo, me gustaría usar la lógica de empuje, sin tener que sondear los PIC del sensor de ID, de modo que cada sensor tenga el mismo retraso desde la detección hasta la computadora, ya que esto se usará para el tiempo de vuelta de los autos.
@Anttu: si no le importa cambiar el código de los sensores, es posible que pueda ampliar el informe de cada sensor para que los datos transmitidos incluyan el tiempo entre el momento en que se activó el sensor y el momento en que se envió el informe. De lo contrario, si la velocidad de datos y la capacidad de respuesta de los sensores son lo suficientemente rápidas, es posible que pueda sondear cada sensor 100 o incluso 1000 veces por segundo.
Debe hacer que el controlador principal envíe un mensaje de sincronización que configure todos los temporizadores integrados del sensor, para que los sensores puedan marcar sus datos con una marca de tiempo. En cuanto a una solución de empuje, vea mi último párrafo. Empuje vendrá a empujar; Es solo cuestión de tiempo.
@MikeDeSimone estos autos son a escala 1:32 o 1:45. Estoy seguro de que sus controladores son solo el PIC con salidas de nivel lógico.

Si su sensor puede acomodar una línea "lista" y diferir cualquier evento que llegue cuando no está confirmado, transmitiéndolos cuando lo esté, su mejor apuesta puede ser enviar un cable ocupado separado a cada sensor y usar una puerta "Y" para combinar las señales de todos los sensores. Sugeriría que si tiene cuatro sensores, debe alternar los cables "listos" en forma rotativa, con algún tiempo "muerto" entre ellos (cuando nadie está "listo"); si entra un byte durante el tiempo "muerto", asuma que fue enviado por el último sensor activo. Establezca el tiempo "listo" lo suficientemente largo para que un sensor pueda reaccionar, y el tiempo muerto lo suficientemente largo para que un sensor tenga tiempo de terminar de transmitir un evento que ocurre justo antes de que su línea "listo" sea desactivada.

Editar

Según descripciones adicionales, dado que aparentemente cada sensor tiene un número de identificación conocido distinto, creo que el mejor enfoque puede ser tener una sola línea en serie que esté conectada a una salida PWM a través de una resistencia y un diodo paralelos, para que se extraiga sube por 1,900 us cada 2 ms pero baja por 200 us (si uno pudiera tener un interruptor PWM entre activo-bajo y flotante, eso sería aún mejor). Tan pronto como se ve un automóvil, un sensor debe iniciar la siguiente máquina de estado, realizando un seguimiento de cuántas decenas de microsegundos han transcurrido desde que comenzó a ejecutarse.

  1. Espere a que la línea de datos sea alta.
  2. Espere a que la línea de datos sea baja.
  3. Borrar temporizador de línea baja
  4. Espere a que la línea de datos suba, incrementando el temporizador de línea baja (y el temporizador principal) mientras espera.
  5. Si el temporizador indica que la línea estaba baja a menos de 200us, regrese al paso 2
  6. Continúe incrementando el temporizador de línea baja mientras observa que la línea baja, hasta que ese temporizador alcance una duración que sea única para la ID del nodo. Si la línea baja dentro de ese tiempo, regrese al paso 3.
  7. Configure la línea de datos para la salida, transmita los datos a una velocidad de 16 us/bit más o menos (impulsando la línea activamente tanto para alta como para baja) y comience a buscar el próximo automóvil. Tenga en cuenta que los datos deben incluir el número de intervalos de 10 us que han transcurrido entre ver el automóvil y comenzar la transmisión.

Usando un UART, este enfoque debería permitir procesar los autos que llegan a cualquier sensor, en cualquier orden, y resolver sus tiempos dentro de 10 us, con la condición de que los autos se procesen secuencialmente a una velocidad de uno cada 2 ms, y los sensores serán "ciegos" entre el momento en que ven un automóvil y la CPU principal se pone a procesarlo. A menos que haya una gran cantidad de sensores, eso no debería representar un problema. Tenga en cuenta que la CPU principal no tiene que tener ningún tiempo preciso en nada más que su salida PWM. Todo lo demás se puede inferir del flujo de datos en serie (incluidas las "largas pausas" que resultan de los pulsos "bajos" de PWM).

Como escribí en otro comentario, me gustaría tener una solución push. ¿Qué tal si los PIC del sensor tiran de una línea común de "transmisión" alta y verifican esa línea antes de enviar los datos?
@Anttu: Como se señaló en mi comentario a su comentario anterior, hacer que el transmisor registre el tiempo preciso entre el momento en que se ve el automóvil y el inicio de la transmisión debería proporcionar la precisión que necesita, incluso si dos automóviles golpean diferentes sensores simultáneamente. Uno podría tener todos los nodos sentados en un bus externo y usar algún protocolo de resolución de colisiones, pero eso probablemente agregaría más incertidumbre a los tiempos de transmisión que el sondeo. Por cierto, una cosa a considerar sobre las encuestas, que olvidé mencionar arriba: ...
@Anttu: a menudo es más fácil para los microcontroladores generar tiempos consistentes para las señales salientes que medir con precisión los tiempos de las señales entrantes. Si el sensor esperó hasta el flanco descendente de su línea de 'transmisión' para transmitir, y si el procesador principal generó el flanco descendente para cada transmisor precisamente una vez cada 40 ms (100 intervalos de sondeo por segundo, divididos en cuatro formas), sabiendo cuándo envió el el pulso de sondeo y el tiempo informado (del sensor) entre el evento y el pulso permitiría que la CPU principal resuelva los tiempos con una precisión de subms.
Probablemente tengas razón en eso. El único problema entonces es que el receptor PIC18F2550 solo tiene 2 pines disponibles. Entonces, en ese caso, tendría que actualizar a un PIC18F4550 que tiene más pines de E/S.
@Anttu: Sugeriría que considere usar un chip de contador externo impulsado por una de las líneas PWM de PIC; quizás algo así como un 74HC4017. Tal vez alimente una de las salidas de eso a un inversor que está conectado a través de una resistencia al "bus" (por lo que se elevaría 9/10 del tiempo y se reduciría 1/10, lo que le permite saber en qué estado el el contador está adentro). Si puede configurar la salida para la operación PWM, podría generar buenos tiempos precisos independientemente de lo que esté haciendo el código.

Puede implementar un protocolo MODBUS en modo RTU con interfaz RS485 que funciona bien en PIC (no estoy tan seguro acerca de su PIC).

Puede tener una línea multipunto para descansar sus diferentes dispositivos de microcontrolador y tener una buena comunicación entre ellos en el UART serial.

Puede hacer que su PIC18F2550 sea un maestro que iniciará la transacción desde cualquier otro controlador 4.

Vuelva a escribir su respuesta con el lenguaje adecuado; este sitio tiene como objetivo crear una referencia permanente, que es mejor si se formatea correctamente.
Disculpas si encuentras que el lenguaje es inapropiado. Acabo de utilizar el formato predeterminado. ¿Puede decirme dónde está el problema real?
Solo preocúpate por la gramática y no uses abreviaturas o ese tipo de cosas. He editado tu respuesta por ti. ¡Bienvenido!
@clabacchio Está bien. Tendré cuidado a partir de la próxima.

Utilice la multiplexación por división de tiempo. El maestro envía un pulso de sincronización en una línea separada que los esclavos usan para restablecer un temporizador. Cuando un esclavo tiene datos para enviar, espera hasta que el temporizador iguala (número de esclavo * ancho de intervalo de tiempo) marcas antes de enviar. El intervalo de tiempo debe ser lo suficientemente largo para enviar el paquete y dar cuenta de la inexactitud del reloj entre los sensores.

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

Hay algunas ventajas en tener todos los procesadores de los sensores ejecutando el mismo código; también hay alguna ventaja en tener todo sentado en los mismos cables (en lugar de, por ejemplo, usar un 74HC4017 para encender cada sensor en secuencia). Sin embargo, una complicación que veo para la multiplexación por división de tiempo es que no estoy seguro de cuánto puede hacer la CPU del sensor mientras espera un automóvil. Si uno usara TDM, lo más probable es que esperara un automóvil, luego esperara el siguiente pulso de sincronización y luego enviara los datos. Si lo desea, el cable de datos también podría manejar fácilmente el pulso de sincronización si fuera más largo que los datos.
Cada uno de los sensores ya conoce su identificación única. No tiene por qué importar si el micro pierde un pulso de sincronización. Configure el temporizador de 16 bits del micro para que tenga el mismo período que el pulso de sincronización, reinicie el temporizador en un pulso de sincronización y espere a que el temporizador iguale (número de identificación) * (ticks del temporizador por intervalo de tiempo) antes de enviar.

Encontré este sitio con una solución llamada BlackNet. Se basa en un protocolo bastante simple en el que la idea es que cada nodo de la red tenga su propio intervalo de tiempo. Es decir, es una especie de lógica de todos contra todos. La última imagen de la página muestra un esquema con la menor cantidad de componentes necesarios para que funcione.

Usé esta idea y simplemente conecté los dos sensores que construí directamente al pin RX en el PIC18F2550. Sin embargo, no implementé el protocolo round-robin, sino que solo puse los datos en la línea (y espero que solo uno transmita a la vez). Hasta ahora ha funcionado bastante bien...

Para futuros lectores: si es fundamental que sus datos siempre lleguen, la solución que he usado probablemente no sea una buena idea. Sin embargo, si rara vez envía datos y puede vivir con la posibilidad de que colisionen y quiere la solución más fácil posible, creo que esta es lo suficientemente buena.

Multiplexación de línea serie
RespuestasAquíPolítica de privacidad1y, 0v