HSERIN & HSEROUT - Todo un dilema...

[Abago]

nueva pregunta...
en el código que dejó Marques

http://www.melabs.com/resources/samples/x1/pbp/serbufAx.bas

utiliza un buffer de reccepción de 30 caracteres tipo byte
yo he incrementado el valor a 64, que es el valor maximo si no me equivoco de una variable array tipo byte
Bueno, mi idea, es incrementar el buffer a 128 o mas...
Es posible???
bueno, haciendo 2 variables array de 64, ya tendría el doble de buffer, y haciendo una pequeña modificación al codigo, sería biable...
Pero???
hay alguna forma de hacerlo directamente sobre la misma variable??

hay alguna forma de detener la recepción, interpretar datos, y volver iniciar la recepción para rellenar el buffer, sin arriesgarme a tener errores o saturar el buffer del dispositivo externo???

Influirá mucho en el consumo de memoria el crear 2, 3 o 4 variables para incrementar el buffer???

Como puedo calcular la memoria utilizada al declarar las variables? y saber la que me sobra para declarar mas???



Pero como se nota que soy novato...
TNKS.

[MarquesSalsero]

Antes de nada siento estar tan perdido y no poder dedicarle tiempo a mis aficiones pero hay otras cosas importantes que me comen dmasiado tiempo.

Ahora por partes...

Simular wait si usas la recepcion en un buffer y por interrupciones no tiene ningun sentido. La intencion del wait en el comando de recepcion serie del pbp es para evitar que si no recibes nada en el puerto el programa se quede detenido por siempre, de esa manera le puedes decir que esperas recibir algo y si no lo comienzas a recibier en cien milisegundos ( por ejemplo ) le das una pasada al resto del programa y lo vuelves a intentar. Si estas recibiendo caracter a caracter por medio de una interrupcion no necesitas quedarte parado en una linea del programa a la espera de los datos asi que deduce tu mismo porque el simular el wait no tiene sentido.

El tamaño maximo de los arrays en pbp para el tamaño byte depende unica y exclusivamente de la memoria del pic que estes usando. Es decir si tienes un pic con 84 posiciones de ram nunca podras tener un buffer de 64 bytes ¿OKAPA? lo que es muy importante es que los arrays deben encontrarse en un mismo banco de memoria  en los pics de 12 bits, 14 bits y en la serie 17Cxxx en los pics de la serie 18Xxxx pueden ser tan grandes como RAM tengas (todo esto lo pone en el manual ¿EH? ).

No necesitas detener la recepción para nada, pero si es absolutamente necesario ( si no te da tiempo a procesar los datos recibidos ), puedes hacer una interrupcion por hardware como ya te comente en el anterior mensaje.

Suerte y me algro de que te vaya bien.

[Abago]

Gracias Marques

A ver... estoy utilizando una pic16f876 y es posible que migre a la 877, aunque creo recordar, que la unica diferencia, radica en que tiene mas puertos...

Sobre el tema del wait.. Ya llegué a la misma conclusión que tu comentas...
lo que he hecho, es crear la variable
buffer var byte[63]
en vez de usar el
buffer_size que pone en el programa que me dejaste de ejemplo,
en el cual se define a 30

Bueno, el problema, es que como mi idea, es poder conectarme a cualquier maquina que envie tramas por puerto serie, no se exactamente la cantidad de caracteres, que puedo llegar a recivir...
ahora en principio, como estoy empezando, pues lo que hago, es leer comandos mandados por mi desde el hiperterminal... y no superan los 30 caracteres...
pero????
y si una máquina, manda una trama de 500 caracteres??? y al programa, no le da tiempo a interpretar antes de ir vaciando el buffer???
BUFFER OVERRUN!!!
Me he hecho un pequeño programa en VB, para ver que es lo que pasaba, y al mandarle una trama de golpe de mas del tamaño del buffer.... El buffer se satura... Y!!! BUFFER OVERRUN....
Si le meto comandos a mano.. como mis dedos van muy despacito... Nuca llego a saturar el buffer...
definí el tamaño del array de buffer a 63, creyendo que era el tamaño máximo que podia definir, y aparentemente, todo funciona bien si mando datos a mano....

Pero??? como puedo ampliar el tamaño del buffer??? hasta por ejemplo 500???
cual el el tamaño maximo con el que puedo declarar el array buffer??? en un 16f876???
Cual es el tamaño recomendado???
De que modo puedo gestionar el buffer de un modo mas inteligente,  sin usarun control de flujo por hardware???

Muchas gracias!!!

[MarquesSalsero]

Vamos a ver hombre que hay que leerse los manuales de los chips, pero en este caso y sin que sirva de precedente te voy a hacer yo los deberes.

Segun la hoja que te de datos del 876/877, puedes ver que en el Bank0 tienes 96 bytes consecutivos de RAM disponibles y en los otros bancos mas o menos lo mismo pero organizados de forma rara.

Asi que el maximo tamaño del buffer puede ser de 96 Bytes.

[Abago]

Gracias marques, lo que me pasa, es que tengo un pequeño problema de entendimiento con los datasheet....
Vamos, que no me entero de la mitad de lo que leo...
Gracias por hacerme los deberes....

Este problema, viene, por no empezar a aprender desde el principio, como todo el mundo...
SIEMPRE EMPEZANDO LA CASA POR EL TEJADO!!!!

Y luego vienen, estas dudas existenciales....

bueno, y sobre el tema que comenté antes, que solución me darías en el caso de recivir mas datos de los que el buffer pueda aguantar???

y pregunta de novato...
si dimensiono el array con los 96 caracteres que el banco 0 me permite.... Voy a dejar un poco falto de memoria al pic para otros menesteres no????

TNKS

[MarquesSalsero]

En realidad hay cuatro bancos, hablo de memoria ya que ahora no tengo el datasheet a mano, el primer banco tiene 96 Bytes, el segundo y el tercero tienen 80 bytes mas los 16Bytes sepueriores del banco uno reflejados mas otros 16 bytes añadidos en la parte inferior y el cuarto banco ( creo recordar ) que tiene 80 bytes mas los 16Bytes sepueriores del banco uno reflejados.

Lo de los 16 bytes reflejados quiere decir que estes en el banco que estes, si intentas leer o escribir en alguno de los 16 bytes superiores, siempre vas a acceder a lo mismo, a lo del banco uno. Esto es muy interesante pues te permite acceder a esas posiciones de memoria sin importar en que banco de memoria te encuentras.

En cuanto a tu proyecto, es muy majo, pero yo qde vez en cuando necesito espiar los buses de comunicaciones para descifrar un protocolo, o bien para localizar problemas de comunicaciones y siempre lo he hecho con un ordenador ( Macintosh o Pc ) y un programa de comunicaciones, de hecho hay varios programas especificos para esta funcion incluso como freeware. Ten en cuenta que a veces hay que analizar bloques de comunicaciones de cientos e incluso miles de caracteres y que eso nunca lo podras hacer con un simple pic. POdrias poner memoria RAM externa y almacenar los datos temporalmente... pero seria complicar mucho el tema y es como esos que se compran un opel corsa y le ponen alerones y pegatinas por todos los lados, queda "muy majo"  pero nunca haran lo que un verdadero deportivo. Asi que si lo estas hacienmdo como un ejercicio para tu autoformación, perfecto. Si lo que quieres es una herramienta de trabajo fiable que te ayude a soluciones futuros problemas, pues ¿ que quieres que te diga ? gastate 10Euros en un programa shareware y como el Pc ya lo tienes, pues bueno, pues eso, que al cesar lo que es del cesar y al pic lo que puede hacer.

[Abago]

gracias marques....
Bueno, la idea,que me das es buena, y como muy bien dices, la idea es un proyecto para aprender, pero me tomo los proyectos como retos, y hasta que no los hago funcionar, no paro....
pensando este fin de semana, me he puesto a conectar de nuevo el circuito con el modem, y he visto que las tramas, no son demasiado largar, como para saturar el buffer, menos en el caso de recepción de un SMS.
en este caso, el pic, recive una trama algo mas larga que el buffer... y CRASH!!!!

la trama es algo como
+CMT: "+34609090909", 0,0,0, "A ver si capturo el contenido del SMS y hago funcionar mi idea.... "
con un buffer de 30 bits, el buffer se satura....

alguna idea, de como puedo desglosar la recepcción??? para poder extraer el numero de telefono?? y el contenido del sms???
sin saturar el buffer???

Por una parte, el handler de interrupción, me va llenando el buffer
y por otra parte, en el módulo principal, estoy gestonando la entrada del comando +CMT como comando valido

una vez que detecto el comando válido, actuo en consecuencia,  y desgloso la trama para separar el numero de telefono, y el contenido, y guardarlo en la eeprom interna del pic...

pero lo que no se, es si al ser el contenido del sms, mas grande que el buffer, será posible ir limpiando buffer segun le van entrando los datos y desglosando los datos al mismo tiempo....

Vamos, que estoy un poco perdido...
aun estando muy contento de haber conseguido que la recepción por uart, me funcione...

TNKS

[Abago]

se me olvidaba....
Una preguntilla maslll

Me gustaría poder gestionar los tiempos de funcionamiento del programa de un modo, mas o menos real
pero al activar la interrupción del timer0, el programa, empieza a hacer cosas raras....
hay alguna idea de como puedo incrementar el código que me mandaste, para poder habilitar el timer0, y gestionar los tiempos???

TNKS

[MarquesSalsero]

Bueno, el problema principal consiste en ir vaciando el buffer por lo menos a la misma velocidad que se va llenando, mejor si es algo mas rapido

Las soluciones son basicamente dos, o procesas los datos mas rapidos, o los recibes mas lento. Así que o bien mejoras tus algoritmos de parseado ( toma palabro ) y analisis del texto recibido o fuerzas al modem a que se comunique a una velocidad mas baja. Tampoco es mala idea usar un pic mas rápido.

Yo recuerdo hace años que en un proyecto me vi obligado a poner un Z80 ( que tiempos aquellos ) para control de todo el sistema y otro mas con una ram de 2Kbytes y un UARTpara poder soportar los bloques de informacion que me llegaban a veces. Una solución´puede ser usar una memoria externa de 1Kbye y usarla como tampon o buffer.

[Abago]

JEJE...
Yo también empecé con el Z80...
Y recuerdo lo que me costó aprender lo poco que nos enseñaban en clase...
Y lo que mas recuerdo es lo de tener que convertir el programa a mano a HEX, y luego meterlo el entrenador... PUFFFF... Que suplicio.....


Bueno, a lo que ivamos....
La idea que me das, es la que mas o menos estaba empezando a enfocar...
Mi idea es, dado que el pic, lo tengo trabajando a 20Mhz, y depuro las funciones de interprete de comandos al maximo, hacer una lectura en tiempo real... Vamos como si el pic fuese multitarea...

Me explico....
en el módulo principal... El pic, hace sus cositas.. Lee, los pines del portb, enciende los del porta... o lo que sea...
y cada determinado tiempo, entro en la rutina de detección de comando serie....
Bueno, la idea, es la siguiente....
Una vez que entro en la interrupción,  comparo el tamaño del buffer, y si es mayor que 2 caracteres, que es el comando mas corto que he puesto (SI/NO), entonces, lanzo la llamada a la función de interprete de comandos....
Pero claro... hay que hacerlo fuera del handler, para que no se me meta en modo recursivo....

asi que la idea a sido la siguiente.
En la función de interprete de comandos, le he puesto un flagBit para controlar si estoy o no en ella.
Al entrar, lo pongo a 1 y al salir del interprete, lo pongo a 0.
Bueno, pues si recivo datos de la usart estando en esta función, da igual, porque cogemos los datos, los metemos en el buffer, y seguimos con el proceso de la función, que a su vez, va limpiando según interpreta.

pero la idea, es que si no estoy en la función interprete, al entrar en el handler, llenar el buffer, comparar el tamaño, y si es mayor que 2, y el flagbit del interprete esté a 0 entonces esto significa, que tengo datos a interpretar y que no los estoy interpretando, asi que saltamos a la función interprete de comandos....

aqui es donde está mi pequeña duda....
Como hago, para llamar a la función interprete de comandos, fuera del handler, pero de un modo directo????

No se si me he explicado.... Espero se entienda la idea principal de mi exposición....

[MarquesSalsero]

amo a ve" que m"e peddio, peddio de noencotra"me.

Por lo que dices perece que el analisis de lo recibido lo haces en la interrupcion asi como el verificar si tienes datos en el buffer. Yo sinceramente y a no ser que el programa me lo exigiera, la comprobacion del estado del buffer y su analisis lo haria fuera de la interrupcion. Yo compruebo el estado del buffer en el bucle principal, y si veo que tengo suficientes datos como para analizar, entonces salto a una rutina en la que analizo lo recibido y tomo decisiones en funcion de esto. De esta manera tengo siempre al chip en background, por la interrupción, recibiendo datos y poniendolos en el buffer.

[Abago]

Realmente!!! Me he explicado mal....

Lo que hago, es exactamente lo que dices....
almaceno datos en el buffer por medio de la interrupción, y en el programa principal, los interpreto, pero mi duda, está en si al programa principal, le dará tiempo a leer un comando grande, como pueden ser 100 caracteres, e ir vaciando el buffer al mismo tiempo, para no saturarlo... trabajando dentro del bucle del programa principal...

la idea, es gestionar unicamente el llenado y el tamaño del buffer en la interrupción, y si el buffer cumple con caracteres suficientes, dejar lo que hace el programa principal e ir a la función de interprete de comandos... y luego volver a trabajar en el programa principal....

algo asi como hacer un
if lenBuffer > 5 then call command_com
en determinadas partes del programa principal
de este modo, puede funcionar, pero la idea, es que la llamada, fuese inteligente, y no dependiese de comprovaciones constantes...

[MGLSOFT]

Creo que tu error esta por aqui:
while (bufchar <> 34) or (cont < 10)

Yo lo escribiria asi, por el tema del orden de asignaciones y precedencias:

while ((bufchar <> 34) or (cont < 10))

[Abago]

El error, está en el parentesis para definir la doble comparación....

Mira que lo he pensado, y me he venido al trabajo con la duda, sin probarlo....

Me meto a hacer cosas complicadas, y cometo fallos en las cosas mas simples!!!

Tnks MGL

[Abago]

y para colmo, tengo el mismo error en la siguiente función que he creado....

una vez que con la anterior función leo los datos del buffer,
lo que hago, es comparar la cadena con una lista de comandos creada en la eeprom del pic....
Y plash!!!!
con el mismo error... en vez de comparar la matriz de datos de 25 caracteres....
me recorre toda la memoria....

Creo que va siendo hora de tomarme unas pequeñas vacaciones!!!!

Ahora la pregunta del millón......
Estoy utilizando un 16f876...
y creo que es posible que llegue a las 2000 Words, sin tener completado el programa....
Y creo que dentro de las 16f8xx.. No hay ninguna con mas memoria...



Hay alguna pic con la misma disposición de puertos, con mas memoria????

Creo que me va a tocar depurar mas el programa....
CADA VEZ SE HACE MAS GRANDE!!!!