Autor
|
Tema: protocolo para controladores (Leído 5,884 veces)
|
@synthesize
Wiki
Desconectado
Mensajes: 640
Another Brick in the Wall
|
Buenas
Estoy haciendo un pequeño trabajo, que trata de diseñar un protocolo de comunicación, para comunicar, en mi caso, 2 Arduinos. Quiero exponer mi idea, y que me digáis si lo veis eficaz o no.
Quería hacer algo con arquitectura cliente-servidor, de esta forma: El cliente hace una petición al servidor, y el servidor emite nodos (Ahora explicaré como se forman) hasta que termine de emitir el mensaje o hasta que el cliente envíe una interrupción.
Los nodos, son nibles, separados en 2 grupos que son "Status" y "Data"
el primer grupo de 2 bits, status, define la acción (Osea, si emite el servidor, si emite el cliente, si es una interrupción) y en data, se envía 0, 1, o return.
Me olvido de explicar alguna cosilla mas, pero en general esta es la descripción
¿Qué os parece?
|
|
|
En línea
|
|
|
|
cbug
Desconectado
Mensajes: 147
|
|
|
|
En línea
|
|
|
|
@synthesize
Wiki
Desconectado
Mensajes: 640
Another Brick in the Wall
|
Servir me sirve para aprender cosas nuevas por lo que se agradece el enlace, pero no se parece mucho a lo mío, lo es distinto, además de que lo intento hacer desde 0 con mis propias ideas xD
|
|
|
En línea
|
|
|
|
cbug
Desconectado
Mensajes: 147
|
Bien... Veamos si comprendo... Lo que necesitas es un "Cliente - Servidor", que en electrónica es lo mismo... Para ello se utilizan protocolos de comunicación igual a los de programación ... Ahora bien, lo único es que necesitas un hardware para establecer los niveles de tensión y este puede ser el MAX232... Generalmente este es el circuito: Ahora bien, como sabrás TX = Transmisor RX = Receptor... Luego lo de el envío de señales es a través de bits, y son secuencias de ellos, que en este caso utilizarás seguramente una comunicación asicrónica... No sé sinceramente con que pic trabajas, pero tendrás que ver la forma de enviar y recibir información, ya que hasta lo que sé, no se puede enviar un "paquete/estructura", y ahi es dónde entra el ingenio de como codificar/decodificar a nivel bit Esto último es una idea, espero no estar errado. Mucha suerte
|
|
|
En línea
|
|
|
|
@synthesize
Wiki
Desconectado
Mensajes: 640
Another Brick in the Wall
|
Te has alejado bastante de lo que planteo, seguo que me he explicado mal, a ver si me entiendes ahora:
Es un protocolo simple, sin utilizar mas hardware que 2 Arduinos (atmega 328p) (y un par de cables)
Los conectas, uno a otro, a través de los cables y aplicas mi protocolo (Cuando lo tenga claro XD)
para comunicarse, por los cables se envían nibbles, que yo agrupo acorde con mi protocolo, y que son interpretados por el cliente para recibir mensajes del servidor, y viceversa.
¿AHora mejor?
|
|
|
En línea
|
|
|
|
JCCC
Desconectado
Mensajes: 17
|
yo estaba inventado la polvora.... cuando aparecio un chino con sus juegos artificiales..... XD.... lo q haces es lo mismo.... bueno lo veo asi... alguna vez me toco hacer un protocolo de comunicacion, pero nada complicado solo para enviar un par de mensajes.... si quieres para enviar bastante informacion... ya hay bastantes protocolos de comunicacion... uno mas... no ps.... si lo haces para aprender acerca de los protocolos.... no seria mejor preguntarle a un libro o san google como son los protocolos....
como te dije aun no la tengo clara el xq :S
|
|
|
En línea
|
|
|
|
@synthesize
Wiki
Desconectado
Mensajes: 640
Another Brick in the Wall
|
yo estaba inventado la polvora.... cuando aparecio un chino con sus juegos artificiales..... XD.... lo q haces es lo mismo.... bueno lo veo asi... alguna vez me toco hacer un protocolo de comunicacion, pero nada complicado solo para enviar un par de mensajes.... si quieres para enviar bastante informacion... ya hay bastantes protocolos de comunicacion... uno mas... no ps.... si lo haces para aprender acerca de los protocolos.... no seria mejor preguntarle a un libro o san google como son los protocolos....
como te dije aun no la tengo clara el xq :S
1. Superación personal 2. Superación personal 3. Aprender sobre protocolos, sin hacer lo que hacen otros (Que ya me tocará hacerlo) 4. Superación personal
|
|
|
En línea
|
|
|
|
JCCC
Desconectado
Mensajes: 17
|
Un ciego no puede caminar sin caerse y no llegara lejos. Te recomiendo que antes de hacer protocolos primero consulta algún libro que de esos hay bastantes, cuando lo tengas todo claro puedes comenzar a hacer tus protocolos….. Es la recomendación de un ciego…. XD Yo por falta de tiempo no la tengo claro en todos los protocolos, solo los q use alguna vez… El cliente hace una petición al servidor, y el servidor emite nodos (Ahora explicaré como se forman) hasta que termine de emitir el mensaje o hasta que el cliente envíe una interrupción.
¿Qué os parece?
El servidor es el que pregunta y el esclavo responde si quieres enviar algun mensaje, otro... no veo tu clock.... :S :S :S
|
|
|
En línea
|
|
|
|
Tokes
Desconectado
Mensajes: 140
|
Pues mira, mi hermano, no sé si te sirva lo que te voy a decir. Yo estoy haciendo un proyectito para comunicar una PC con un ATMEGA16.
En un principio, cuando se energiza el circuito, el microcontrolador tiene desactivado prácticamente todos sus recursos (los timer's, el ADC, el TWI, etc.), excepto la USART.
Cuando el usuario de la PC oprime un determinado botón, por ejemplo "INICIAR COMUNICACIÓN", el software (que está hecho en visual basic 6.0) le envía al microcontrolador una cadena de caracteres, que es: "CNT" (CoNecTar).
Al final de cada cadena se envía también el ASCII 13 (retorno de carro) para indicar que hasta ahí llegó la cadena de caracteres.
El microcontrolador entonces, al recibir el caracter ASCII 13 (retorno de carro) sabe que ha recibido una cadena completa y que tiene que procesarla para saber que es lo que debe hacer, por ejemplo:
Si la cadena que recibió es: "LED1-OFF", el micro apaga un pin del puerto. Si la cadena recibida es: "LED1-ON", el micro enciende el pin del puerto correspondiente. Si la cadena recibida es: "FIN-COM", el micro sabe que la comunicación ha terminado y se pone en modo de bajo consumo.
El código de transmisión (a grandísimos rasgos) podría ser algo así como:
// En caso que se quiera encender el led 1. USART_puts("LED1-ON\r"); // el caracter \r es el retorno de carro que indica // que hasta ahí llega la cadena.
El código de recepción (tamién a grandísimos rasgos) sería algo así:
char srx[10]; // Se declara un vector de 10 carateres.
USART_gets(srx); // Recibe carateres por la USART y los guarda en el vector // srx hasta encontrar un retorno de carro.
if(strcmp(srx, "LED1-OFF")==0) bit_clear(PUERTO, LED1); else if(strcmp(srx, "LED1-ON")==0) bit_set(PUERTO, LED1);
Espero que te sirva. Nos vemos.
|
|
|
En línea
|
|
|
|
|
|