HSERIN & HSEROUT - Todo un dilema...

[Abago]

Hola a todos...
Ante todo, daros las gracias por entrar a echar un ojo a mi consulta...
Bueno, os cuento lo que me sucede...
estoy liado con un proyecto, que desde hace varios meses, va siendo mi quebradero de cabeza, y lo que me hace tener ganas de vivir..
Mi interés se basa en las comunicaciones serie...
Empecé con una pic 16f84 trabajando con el serin y serout, en invertido...
después, me decidí a ir metiendome con el max232, y hasta hay todo funcionó muy bien, claro está, después de leer, leer y leer... y sobre todo cacharrear y perder muchas horas de sueño.

Finalmente, y bajo la orientación del genio de sispic, me decidí a usar un 16f876, y usar la uart.
Todo funciona perfectamente...
mi circuitillo se conecta con el hiperterminel a las mil maravillas.

PERO!!!!!!!!
aqui viene el problema.
Ahora estoy intentando conectarme con un modem.
Con el HSEROUT, todo funciona bien, mando por ejemplo un atdt6090909 y el modem llama a ese numero, sin problemas.
pero con el HSERIN, no consigo hacer nada...

bueno, parece que empieza a recivir datos, y de pronto, se cuelga...

os dejo un programilla de ejemplo a ver si veis que puede ser...
En principio, pienso que puede ser por un desbordamiento del buffer de recepción... Pero admito sugerencias...

El programa hace lo siguiente.
enciende dos led, para saber en que parte del código estoy.
llama al +346090909
y espera a tener conexión.
para leer algun dato, lo que hago es colgar mi teléfono para que el modem responda con un BUSY, o espero a que la central telefonica le indique al modem, que no descuelgo, leyendo un NO CARRIER.

una vez que recivo los datos desde el modem, con la función hserin, leo los cuatro primeros dígitos, y los guardo en la eprom.

asi sucesivamente...
despues, leo el pic con el grabador, y sorpresa... no ha cogido ningún dato, o a escrito algún caracter raro..
Si simulo este mismo proceso con el hiperterminal, todo funciona bien...

A nivel de hardware, para usar el hiperterminal o el modem, uso dos cables distintos, dado que los pines de rx/tx, se invierten..


DEFINE OSC 4
DEFINE HSER_RCSTA 90H
DEFINE HSER_TXSTA 20H
DEFINE HSER_BAUD 4800

tmp var byte[5]
cont var word
i var byte

cont = 0

inicio:
high portb.7
pause 1000
hserout["ATDT+346090909",13]
low portb.7
hserin[tmp(1),tmp(2),tmp(3),tmp(4)]
high portb.6
for i = 1 to 3
write cont , tmp
cont = cont + 1
next
low portb.6
pause 1000
high portb.7
high portb.6
pause 1000
low portb.6
low portb.7

goto inicio

[jorgeansuini]

Buenas:

Normalmente no utilizo hserin, pero viendo el codigo ,te comento un problemita:
esto

for i = 1 to 3
write cont , tmp
cont = cont + 1
next

deberia ser asi:

for i = 1 to 3
write cont , tmp(i)
cont = cont + 1
next
 
Igualmente,usando serin,en pic basic plus, me sucedió que no me tomaba variables indexadas,no analice mucho el tema y puse variables individuales.-
saludos

jorge

[Abago]

Tienes razón...
Voy a ver si por un fallo tan tonto,  el  programa no leia la uart...
TNKS.

[Abago]

Al parecer, el fallo es algo mas complicado...
Ya cambié los errores de código, y tras cacharrear, he conseguido leer algo...
Tambien me he dado cuenta de que con el hiperterminal, también puedo llegar a colgar el pic..
El tema está en que con el hiperterminal, no se colgaba, dado que le pasaba los datos escribiendo desde el teclado, a una velocidad muy lenta, para lo que es la velocidad a la que trabaja el pic...
Espero algún dia llegar a escribir a 4Mhz...

Bueno, el caso es que si dejo pulsada una tecla, durante unos segundos... CRASH... El pic se queda loco...

A ver si algún alma caritativa, ha hecho pruevas con los pic y los modem, y sabe por donde viene el error...

[Sispic]

Hola Abago , por que no lo intentas utilizando control de flujo , solo seiran dos lineas mas .

Creo que el moden se puede configurar así .

[MarquesSalsero]

Hola a todos, se que ando muy desaparecido pero a ver si puedo ayudar algo.

Cuando usas las funciones de hardware debes tener en cuenta que el buffer de recepcion se satura enseguida ( solo dos bytes recibidos y crasss ).

Los modems sueles ser muy parlanchines, y en el momento que inicias una conexión ( lo puedes comprobar con el terminal ) se dedican a devolver tanta información que como no tengas un buen sistema de almacenamiento intermedio el buffer de entrada se bloque y deja de funcionar. Esto lo puedes comprobar mirando el bit de saturacion del usart.

En tu caso y con las pausas que has puesto.... pues nada que antes de que te hayas dado cuenta usart saturada.

En la gues de melabs hay un sistema de recepcion con la usart de hardware con almacenamiento intermedio que yo lo probe en su momento y funcionaba bastante bien, se basa en crear un array de n caracteres ( depende de la memoria que tengas libre ) FIFO circular y almacenar en el los caracteres recibidos usando para ello una interrupcion de perifericos. Luego puedes ir leyendo los caracteres uno a uno, segun tengas tiempo, y actuando en consecuencia. Aun asi si tienes un buffer de entrada de, digamos, 32 caracteres y no vas vaciandolo de forma regular y rapidito, te aseguo que el modem o simplemente el terminal mandando carateres en autorepetición te lo van a saturar.

Hechale un viastazo al programa que te comento, se encuentra en

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

y

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

uno lo hace en ensamblador y el otro en basic.

Puedes si lo necesitas hacer un control de flujo for hardware, simplemente debes comprobar cada vez que recibes un caracter cuanta memoria te queda libre en el buffer y si te quedan menos de seis o siete posiciones libres activar la linea de control de flujo. Ten en cuante que el control de flujo no es instantaneo y que aunque le digas al modem que deje de enviar informacion este aun enviara algun caracter. Esta pensado para las USART "serias" que suelen tener un buffer de entrada de un minimo de cuatro bytes y pueden llegar a los 256 bytes.

Otro asunto a tener encuenta es que cuando le digas al moedm que no te envie mas datos el tendrá que almacenar en su propia memoria intermedia lo que vaya recibiendo para luego poder enviarlo al pic cuando este lo solicite... y los modems tampoco tienen un buffer enorme.


no se si te habré aclarado algo o te habre liado aun mas, pero te has metido en uno de los aspectos mas complicados de la programacion, control en tiempo real o casi.

[Abago]

GRACIAS A TODOS...
Como siempre, mis amigos inseparables...
Siempre que tengo una duda, apareceis por aqui para ayudarme...
desde mis principios, cuando empecé teniendo problemas casi para encender un led, hasta ahora, en los momentos en los que ya mi mente se empieza a dirigir a proyectos mas ambiciosos.

Voy a hechar un ojo a la documentación de los links, a ver si saco algo en claro. Gracias Marques

SISPIC. Sobre el tema del control de flujo que comentas, El problema está en que el modem, viene por defecto bloqueado para que no utilice control de flujo.
He intentado cambiarle los parámetros, pero me da error.
Parece ser que viene de fabrica preparado para no usar el control de flujo.

De todos modos, lo que realmente me interesa, es leer una pequeña cantidad de información, asi que creo que con la solución de marques, puede funcionar.
como ya comenté antes, necesito leer las respuestas que dan los comandos AT del modem.
Si algún día, intento descargar ficheros binarios desde el modem al pic y viceversa, creo que tendré que usar el FLOW.
Pero de momento eso lo dejo para mi proxima inquietud.

Voy a ver si saco algo en claro estos días.
TNKS.
Si se os ocurre algo más, o veis algo de documentación o código que funcione, estoy por aqui...

[Abago]

Empiezo a pensar que esto de aprender es mas que una ciencia...

Bueno, resulta, que he migrado el proyecto de un 16f876-04
a un 16f876-20
he subido la frecuencia del reloj a 20Mhz
He establecido la comunicación a 9600 bps.
Y parece que FUNCIONA!!!!!!!!!!!!!!!!

@ DEVICE HS_OSC

DEFINE OSC 20
DEFINE HSER_TXSTA 20H
DEFINE HSER_RCSTA 90H
DEFINE HSER_BAUD 9600
DEFINE HSER_CLROERR 1

inicio:
high portb.6
pause 2000
 hserout["ATDT+34NNNNNNNNN",10,13]
 pause 2
 hserin 5000,inicio, [wait("BUS"]
low portb.6

goto inicio

Ahora el pic hace una llamada a mi telefono movil, le doy a la tecla colgar del tfl, y  en la protoboard, se enciente el led de portb6...


AHORA MI CONSULTA:
me gustaría hacer una función, que estubiese escuchando el puerto RX constantemente.
Como se maneja la interrupción de la uart???
Bueno, sigo estudiando, y ya os voy contando mis progresos...

Espero que este post le sirva a mas de uno de los que como yo, nos leemos el foro de arriba a abajo...

MUCHAS GRACIAS A TODOS POR EL ASESORAMIENTO....
Y ya sabeis, si teneis idea de como gestionar la interrupción por RX en asm, o sabeis como me puedo currar la función de escucha del puerto, SOY TODO OIDOS....

TNKS

[MGLSOFT]

Como podras ver en varias consultas en algunos de los foros de diferentes lenguajes, deberas hacer manejo del control de errores que posee la usart.
Hay un bit quem te indica error de recepcion, por lo tanto deberas testearlo transcurridos algunos milisegundos (Hserin posee esa opcion) y saltas a una etiqueta donde reseteas el bit de error.
Sino el micro se cuelga!!

El hecho que hayas cambiado de velocidad de micro hace que el error posible de recepcion de la UART sea mas aceptable, por lo cual tarda mas en producirse.
Esto es comprobable cuando hay tramas muy largas (preguntale a Pacala sino) y el error porcentual se acumula, originando un error de recepcion por falta de sincronismo.

Aqui va un ejemplo de como utilizar la interrupcion y considerar el bit de error:

Codigo:   
    disable
 Interrupcion:
    INTCON.7 = 0        "apago interrupciones generales
    INTCON.6 = 0        "idem con perifericas
    INTCON.5 = 0        "idem con Int de TMR0

    if (PIR1.5 = 1) then    "no es interrupcion del TMR0, es TX
        hserin Espera,LabelExit2,[WAIT (">",hex2 DirIn,SKIP 1,hex2 CheckIn]    
"        hserin Espera,LabelExit,[WAIT (">",RX4),SKIP 1,hex2 CheckIn]
       " hserin Espera,LabelExit,[hex2 DirIn,SKIP 1,hex2 ChecKIn]   
        gosub  CalcCheckIn
        if (DirIn = Direccion)and (ChecKIn = MiCheck) then
            Gosub   PrepDigitos
            gosub   TXint
        endif
    endif  
    if (INTCON.2 = 1) then  "Si hay bandera de interrupcion por Timer0  
        ticks = ticks + 1      " Cuenta partes de segundo
        INTCON.2 = 0    " Reseteo bandera de interrupcion por Timer0  
        IF ticks < 61 Then LabelExit   
        " 61 ticks por segundo (16.384ms por tick)
        ticks = 0   " Paso un segundo - actualizo tiempo
        Convert = ticks
        second = second + 1
        CantConv = AuxConv "guardo cantidad de conversiones por segundo
        AuxConv = 0        "limpio auxiliar de conversiones por segundo
        Var1 = Var2        "guardo actualizaciones de display por segundo
        Var2 = 0           "limpio actualizaciones de display por segundo
        IF second >= 3600 Then  "si algo no paso antes borro cuenta
            second = 0
        endif
    endif  
 LabelExit2:
    RCSTA.4 = 0        "reparo error de recepcion
 LabelExit:
    RCSTA.4 = 1        "habilito recepcion continua
    INTCON.7 = 1        "enciendo interrupciones generales
    INTCON.6 = 1        "idem con perifericas
    INTCON.5 = 1        "idem con Int de TMR0
    RESUME

[Abago]

Gracias MGLSOFT
La idea, es ampliar el handler de interrupción que ya tengo hecho para otras utilidades.
El handler está en ASM, gracias a la ayuda de sispic.
Ahora, me gustaría poder ampliarlo, para que me maneje las interrupciones de la uart.
La idea, es hacer un sniffer del puerto serie.
Leo datos continuamente, y si detecto algo que me sea de utilidad, ejecuto una función.

Ahora, me he encontrado con un problema banal, para lo que el proyecto puede llegar a ser, pero yo pregunto a los maestros,
por si os surge alguna idea de porque viene el error...

hserin 5000,inicio, [wait("AT+", str resp9]
if resp(1) = "C" then
 Hserout["COMANDO -  ",resp(,resp(9), 10,13]
endif

Leo 9 caracteres, desde el momento en el que detecto la cadena AT+
Introduzco la cadena AT+COMANDO01 por terminal
Ahora al comparar resp(1) con "C", no entra en el IF.

Sin embargo si al igual que haces tu en el código que dejaste antes,  al principio del programa asigno a una variable, el caracter "C" y lo meto en la comparación... Funciona BIEN...

Muchas gracias...
Cada dia aprendo mas gracias a vosotros....

[MGLSOFT]

Estas seguro que el caracter inicial del string no es el resp(0)?

Yo probaria mandarle dos C con Hiperterminal...

[Abago]

Si pongo a rest(0), no funciona de todas todas...
si pongo rest(1)
y preasigno el valor que quiero comparar a la var tmp, funciona.

Ahora tengo otro problema.
haciendo los tests pertinentes para buscar errores, lo que he hecho ha sido guardar el dato a comparar en la memoria interna del pic.
he guardado el valor "6" en la posición 0 de la memoria.
ahora con el hiperterminal, introduzco
AT+61

dejo un ejemplo, porque el codigo real , no lo tengo en este equipo

tmp var byte
resp var byte

inicio:
read 0,tmp
hserin 5000,inicio, [wait("AT+", str resp2]

if resp(1) = tmp then high porta.0

goto inicio

----
En principio resp(1) = "6"
y tmp = "6"....

Pues no funciona...
En principio, resp(1), está guardado como un caracter ascii, y tmp????

Tengo graves problemas con la conversión de tipos...
Otra cosa mas que tengo que aprender...

TNKS.

[Abago]

A que te refieres con lo de mandar dos C con el hiperterminal???

Tnks

[MGLSOFT]

Es otra forma de comprobar en que posicion inicia a guardar los datos llegados por el COMM.
Si le llegan dos C seguidas y recibes solo la segunda pueden ser dos cosas, una que se desincronice la Usart, la otra es que realmente guarde a partir de la segunda C....

[Abago]

Para comprovar que los datos que envio al pic, llegan corectamente, acabo de ponerle que los guarde en la memoria interna del micro...
Tras un rato de escribir, ya tengo parte del quijote en la memoria interna del pic.
parece que leer lee bien, pero no se porque no puedo comparar???