Control de led a travez del puerto serial del microcontrolador

[JBQ]

Holas a todos.

El siguiente es solo un circuito de pruebas, pero ejempliza muy bien el problema en general.
Supongamos que tenemos un circuito como el que se muestra en la figurade abajo. EL led se controlara a travez del hiperterminal mediante comandos que el uc rx  a tavez del puerto serial.

 
Cuando se envie por el hiperterminal el comando "ENCENDER LED"     > pues se debe de encender el led
Cuando se envie por el hiperterminal el comando "APAGAR LED"          > pues se debe de apagar el led
Cuando se envie por el hiperterminal cualquier cosa, digamos "HOLA" > pues no se debe de hacer nada


El meollo del asunto es el sgte. Se supone que lo más habitual sería hacer comparaciones de cada byte que rx en el uc y compararlo con una tabla en la que tenga los comandos ya almacenados; pero me parece que no es lo más apropiado, asi que estoy en la busqueda de otra forma de interpretación en los comandos que lleguen al uc pata manipular el led. El problema es que ya se me agotaron las ideas, asi que si alguien de por aqui desea compartir su experiencia o aportar una nueva idea, se lo estare agradecido... saludos.

[Yoshua]

para ese tipo de comandos no hay otra, sino es enviar un byte para encender y otro para apagar.

[jhozate]

Si. lo mejor es comparar, para asegurarse. Pero no es necesario enviar toda una cadena de caracteres, basta con una letra o número.

[MerLiNz]

no es mejor que si envias 0 se apage, y si envias 1 se encienda?? Lo digo porque de la otra forma tendrias que hacer un control de trama, ya que imagina que pones ENCEN y por cualquier motivo se corta la comunicacion, tendrias que resetearlo para que funcione bien de nuevo. De la otra manera es if (byterecibido=='0') apaga; ...

[JBQ]

Casualmente hacer un control de tramas es la idea, pero evitando el metodo de hacer comparaciones.

Obviamente que para controlar el led por el hiperterminal no es necesario enviar toda una cadena de caracteres, pero el objeto del ejemplo es realizar las respectivas pruebas del algoritmo a diseñar que se encargue de controlar y entender correctamente comandos en cadena de caracteres.

Bueno, si no hay otra solucion, me vere en la necesidad de tener que diseñar tablas para TOOOOOODOS los comandos que tenga que rx del hiperterminal...

Me pregunto y de seguro por aqui alguien sabe la respuesta... esa también es la forma en que entiende los comandos los S.O. como por ejemplo el antiguo DOS (haciendo comparaciones de las tramas de comandos recibidas)???

[BrunoF]

Me pregunto y de seguro por aqui alguien sabe la respuesta... esa también es la forma en que entiende los comandos los S.O. como por ejemplo el antiguo DOS (haciendo comparaciones de las tramas de comandos recibidas)???

Si.

Actualmente muchos lenguajes en su método principal de entrada siguen evaluando y aceptando parámetros como cadena de texto.

Saludos.

[JBQ]

Actualmente muchos lenguajes en su método principal de entrada siguen evaluando y aceptando parámetros como cadena de texto.

Saludos.

Pero tal evaluación lo hacen comparando byte a byte (con el comando correctamente establecido en una tabla), o tienen otro método en hacerlo???

[MerLiNz]

hacer una tabla para todos los comandos es mejor que una cadena, necesitas menos recursos, la velocidad de transmision es mas rapida, si es un proyecto que salga a la venta no dejas tan facil el averiguar que es cada comando.

Yo hace años me dedicaba a la programacion de un juego online, este enviaba los comandos por strings (por ejemplo MOVER1,1 para mandar un movimiento), decir que el juego era codigo libre, pero nosotros lo modificamos para hacer nuestro propio modelo.
Tuvimos problemas de lag, el servidor se saturaba al tener que enviar tantos datos, pues yo mismo me encarge de reducir un 40% la cantidad de datos, y asi fue, despues para mover por ejemplo se enviaba el ascii 'M' unicamente (por ejemplo), para otra cosa pues otro byte, como tenemos hasta 255 combinaciones por byte pues nos sobro comandos aun.
Ademas de tambien codificar las strings grandes, por ejemplo el servidor enviaba 0x90 y en el cliente al recibirla este mostraba una string previamente guardada en el cliente.

Las tramas las implementarias en caso de que necesitaras recibir varios datos, por ejemplo, pon led 5 apagado.

La trama seria asi (inicio trama)(tamaño*)(datos)(final trama*)(crc*) *=opcional.

por ejemplo:
0x33;0x02;0x05;0x01

asi cuando recibes 0x33 inicias el estado de trama, luego recibirias el tamaño, y los datos (0x05=led 5) (0x01=on)

[JBQ]

OK MerLiNz, gracias por tomarte el trabajo de darme una alternartiva con ejemplo y todo.

Soy consiente que es mucho más práctico y más eficiente el control de salidas por medio de comandos en tamaños de bytes, que el de comandos en cadena de caracteres (strings); pero como dije al comienzo, la idea de estas pruebas es optimizar el algoritmo de comunicación en forma de cadenas de caracteres.

Ahora, en un mensaje anterior mencionaste acerca de un control de tramas... justamente a eso tiene que llegar esto, pero tratando de salir de los paradigmas habituales de hacer comparaciones byte a byte con la trama rx y la trama correcta en una tabla ya establecida (que sería el comando correctamente almacenado en el uc en forma de tabla).

Bueno, de repente no me estoy dejando entender... quizas debo de ser mas detalloso em mis preguntas pero parece que tú si me has captado la idea. Saludos

[Suky]

Los protocolos especiales para envío de datos para sistemas scada (Control supervisor y adquisición de datos) tratan de enviar la menos cantidad de bytes con la mayor información posible.

En todo caso, si la idea continua, podes utilizar las funciones incluidas en string.h. En C18 por ejemplo sería:

Código: C

1. if(memcmppgm2ram(BufferRecepcion,"ENCENDER LED",12)==0){
2.                 LED=1;
3.         }else if(memcmppgm2ram(BufferRecepcion,"APAGAR LED",10)==0){
4.                 LED=0;
5.         }

Lo que hay que hacer es recibir la cadena en un arreglo de chars y entrar a la comparación.


Saludos!

[JBQ]

Código: C

1. if(memcmppgm2ram(BufferRecepcion,"ENCENDER LED",12)==0){
2.                 LED=1;
3.         }else if(memcmppgm2ram(BufferRecepcion,"APAGAR LED",10)==0){
4.                 LED=0;
5.         }

WOW... primera vez que veo esa instrucción...

Por lo que entiendo, lo que hace es leer un buffer de RX del USART tantos bytes como se le indique (en la primera línea sería 12, debido a que son 12 los caracteres enviados), y compararlos con el almacenado en el uc; hasta aqui estoy bien??? lo que no me queda claro es donde están almacenados esos datos con los que los vas a comparar (obviamente que están en el uc, pero a lo que me refiero es de que forma). Intuyo que están en una tabla, verdad???

Bueno, no me imagino que codifo ensamblado genererá esta instrucción...

Por lo que me doy cuenta, parece que no hay de otra que la de hacer comparaciones.

Muchas gracias por tomarte las molestias Suky... saludos.

[MerLiNz]

lo que pones entre " " se almacena en la memoria rom del pic.

en asm seria bastante mas complejo que poner esa funcion, lo bueno es que las funciones del C18 son todas en asm, si quieres bajatelo y echale un vistazo, el archivo se llama: mcmpp2r.asm

[Suky]

  No me fije que era en ASM! En ese caso si, lo que está en " " estaría guardado en una tabla en la memoria de programa, y bufferRecepción serían un conjunto de bytes en donde se guardarían temporariamente la cadena recibida desde la PC. No queda otra que ir comparando bytes.


Saludos!

[JBQ]

Bueno, muchas gracias a todos por sus sugerencias... saludos.