Autor Tema: Dudas del perro guardián  (Leído 6196 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado Clemen89

  • PIC10
  • *
  • Mensajes: 30
Re: Dudas del perro guardián
« Respuesta #15 en: 06 de Julio de 2012, 14:32:08 »
Estas usando 9600 8N1 en ambas terminales? Puede ser un problema de polaridad de las lineas TX y RX...

Si estoy usando esos valores en ambos terminales :(.

Y perdona la ignorancia, ¿como puedo saber si el problema es de polaridad de las lineas TX y RX?

Un saludo y muchas gracias de nuevo! Es desesperante ver que todo parece funcionar bien y en la práctica no :S

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Dudas del perro guardián
« Respuesta #16 en: 06 de Julio de 2012, 14:39:34 »
Pues por lo que veo tampoco parece ser un problema de polaridad.

No podés ver los valores que recibís en hexadecimal? Lo estás probando con el hard real?
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado Clemen89

  • PIC10
  • *
  • Mensajes: 30
Re: Dudas del perro guardián
« Respuesta #17 en: 06 de Julio de 2012, 14:46:49 »
Pues por lo que veo tampoco parece ser un problema de polaridad.

No podés ver los valores que recibís en hexadecimal? Lo estás probando con el hard real?

No se lo que es el hard real así que supongo que no jeje.

Para la simulación estoy usando el MPLAB, y funciona perfecto en la simulación claro.

En la práctica solamente uso dos ventanas de hyperterminal y los conectores RS232 para conectar por un lado de la placa y por el otro lado a las 2 UART. Para ver lo que llega en hexadecimal pues sería ir pasando los ascii del hyperterminal a hexadecimal. Ahora edito y paso lo que me ha llegado al hyperterminal de la captura de antes a hexadecimal.

En principio todo funciona bien, puesto que en diseños anteriores funcionaba bien la comunicación. El problema ha venido cuando he metido el sleep, el WDT, y el querer recoger lo que llega en una cadena de caracteres antes de enviarlo ( en las pruebas anteriores iba enviando conforme llegaban los caracteres ). Y estoy muy frustrado, porque encima es que la comunicación del otro lado ( de dispositivo 2 a dispositivo 1 ) funciona bien ...

Algo que se me ha ocurrido que podría ser, es que con el despertar del WDT o al meterse en sleep cambie algun registro o algo relacionado con la transmisión, o que tras despertar la UART necesite un tiempo antes de empezar a enviar datos.

EDITO:

Vale lo que llegaba antes eran:

Los dos puntos esos que no se como ponerlos, no se si es el "NULL" en ascii, en cuyo caso sería el 00 en hexadecimal, o es "¨" en cuyo caso sería F9 en hexadecimal.

Y la ó es el 162 en ascii, lo que sería A2 en hexadecimal.

Y eso es lo que me ha salido como he dicho antes en la captura, al enviar ATATAT, tiene poco sentido la verdad.
« Última modificación: 06 de Julio de 2012, 14:53:22 por Clemen89 »

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Dudas del perro guardián
« Respuesta #18 en: 06 de Julio de 2012, 14:55:42 »
Bueno. Sí, eso sería Hard Real. Cuando estás utilizando el PIC físicamente, lo solemos llamar Hard REAL, contrario al simulado.

Pues está rara la cosa.

Cómo estas conectando de la PC al PIC los RS-232? Los niveles de tensión y corriente no son los adecuados para conectar el PIC a la PC directamente... Deberías usar un MAX232 o simil antes de conectar desde/hacia la PC.

Yo probaría algo más sencillo. Antes del loop principal, probá enviar un par de caracteres a la terminal 2 a ver si recibe bien. Ese sería un buen comienzo.

"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado Clemen89

  • PIC10
  • *
  • Mensajes: 30
Re: Dudas del perro guardián
« Respuesta #19 en: 06 de Julio de 2012, 14:58:58 »
Bueno. Sí, eso sería Hard Real. Cuando estás utilizando el PIC físicamente, lo solemos llamar Hard REAL, contrario al simulado.

Pues está rara la cosa.

Cómo estas conectando de la PC al PIC los RS-232? Los niveles de tensión y corriente no son los adecuados para conectar el PIC a la PC directamente... Deberías usar un MAX232 o simil antes de conectar desde/hacia la PC.

Yo probaría algo más sencillo. Antes del loop principal, probá enviar un par de caracteres a la terminal 2 a ver si recibe bien. Ese sería un buen comienzo.



El pic lo tengo en una placa que he diseñado y tengo el MAX232 puesto claro, descarto que sea algo de la placa puesto que antes de complicarlo con el WDT, el sleep y la cadena de caracteres funcionaba la transmisión :S.

Iré probando cosillas un poco mas sencillas, pero me da mucha rabia porque al final no tendré mas alternativa que volver a esta situación, porque necesito usar el WDT con el sleep si o si :S.

Y gracias de nuevo Bruno!

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Dudas del perro guardián
« Respuesta #20 en: 06 de Julio de 2012, 15:07:10 »
Probá lo básico. Si envía bien sin el WDT, entonces hay que analizar mejor por qué surge el problema. Espero novedades.
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado Clemen89

  • PIC10
  • *
  • Mensajes: 30
Re: Dudas del perro guardián
« Respuesta #21 en: 06 de Julio de 2012, 16:03:21 »
Bien traigo noticias nuevas.

He estado haciendo pruebas transmitiendo antes de que haya una interrupción, y despues del wake up del WDT, y he descubierto dos cosas:

-1º: La transmisión funciona bien.

-2º: La transmisión con el puerto RS232 del ordenador no funciona bien, solo funcionaba una parte porque solo me iba el conector que iba al USB del ordenador, el que iba directamente al RS232 no iba bien, por lo que puede que fuese problema del ordenador.

Además, intuyo que el CLRWDT fastidia la transmisión. Seguire haciendo pruebas pasando del puerto del ordenador, y tirare directamente al modem. ¡A ver si hay suerte!

Iré trayendo las novedades... por lo menos ya he descubierto algo despues de mas de 15 horas buscando algo.

EDITO: Pues no, el CLRWDT no fastidia nada de nada, todo funciona bien... ¿apostamos a que lo conecto al modem en vez de al ordenador y le envio cualquier chorrada para que me responda aunque sea ERROR y funciona? Como funcione... me pego un tiro, habré hecho el panoli toda la semana
« Última modificación: 06 de Julio de 2012, 16:15:41 por Clemen89 »

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Dudas del perro guardián
« Respuesta #22 en: 06 de Julio de 2012, 17:06:47 »
Pues no sería raro, parece estar todo bien. Debe ser un problema de hardware.

Ya nos contarás. Todos hemos perdido mucho tiempo y esfuerzo en cosas sencillas.

Saludos.
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado Clemen89

  • PIC10
  • *
  • Mensajes: 30
Re: Dudas del perro guardián
« Respuesta #23 en: 08 de Julio de 2012, 13:30:20 »
Aquí estoy de nuevo jeje.

Bueno pues ha fallado de nuevo, con el modem GSM no se comunica bien, he hecho una pruebecilla, he puesto en el while(1) de la funcion principal la instrucción INTF=1 para activar la interrupción de RB0 automáticamente, y he metido en la cadena de caracteres "AT+CPIN", y la UART por hardware funciona perfecto. Por lo que no se que es lo que falla, pero ya esta bastante bien acotado el problema.

El problema debe de estar en una de estas dos cosas diría yo:

- La interrupción de RB0 no funciona del todo bien o hay algo que no estoy teniendo en cuenta. He pensado que podría haber algun retardo al despertarse del SLEEP, pero he quitado el WDT y el sleep y sigue sin funcionar, por lo que queda descartado, seguimos acotando el problema.

- La recepción de la UART software no esta funcionando bien.


Tengo una dudilla que se me ha ocurrido en la ducha (jaja) y que puede que sea algo obvio pero como soy algo novatillo en esto... pues bueno, he estado pensando en como funciona la UART, y sino me equivoco se podría decir que es una señal cuadrada ( 0s o 1s, lo que vendría a ser 0V o 5V ), primero pone el bit a 0 para empezar la conexión, en nuestro caso 9600 baudios corresponden a un bit cada 104us, es decir pone un 0 durante 104us, luego un 1 por ejemplo de datos durante otros 104us y asi hasta el bit de stop.

Pues bien yo en la UART por software para la recepción, en el momento que se genera la interrupción, espero 104us ( para pasar el bit de START ) y cojo el primer dato, y asi sucesivamente hasta el bit de STOP. Y he pensado que puede que al estar recogiendo los datos en el límite de tiempo, es decir cada 104us nada mas cambiar el bit, puede que este cogiendo el bit anterior por cualquier retardo mal calculado o cualquier cosa. ¿Sería mas eficiente si una vez que llega el bit de start me espero 154us en vez de 104us para no estar tan al límite?

Es decir sería algo así.


  START           1er BIT         ..........................
                ____________
_________|                   |________________________________
     aquí             aqui


Coger los datos donde pone "aquí", es decir en el centro en vez de al principio, porque tal vez no tenga nada que ver en el problema, pero para ir descartando cosillas. Pero no estoy seguro si esto que he pensado es algo obvio y es como debería de haberlo hecho o no se puede hacer así por alguna razón.

Seguiré contando novedades!

Un saludo y gracias como siempre!
     

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Dudas del perro guardián
« Respuesta #24 en: 08 de Julio de 2012, 13:42:21 »
Hola.

Sí, puede tener que ver. Pero cuidado, que al uC le lleva varias instrucciones atender la interrupcion, que también es tiempo que debes de considerar y quitarle a los 154 ideales.

Saludos.
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado Clemen89

  • PIC10
  • *
  • Mensajes: 30
Re: Dudas del perro guardián
« Respuesta #25 en: 09 de Julio de 2012, 13:07:35 »
Hola de nuevo,

Traigo novedades, he comprobado que no fallan ni las interrupciones ni la transmisión, por lo que el error debe de estar en la recepción de la UART software sin mas remedio.

He hecho esto:

Código: [Seleccionar]
probando[0]='A';
probando[1]='T';
probando[2]='+';
probando[3]='C';
probando[4]='P';
probando[5]='I';
probando[6]='N';
probando[7]='?';
probando[8]=0x0D;
for(i=0;i<=indice;i++){
while(TRMT==0);
TXREG=probando[i];
}

Justo antes de enviar le he añadido yo lo que quería y funciona correctamente, además, entra en las interrupciones bien porque el valor de indice va en la interrupción, y envía el numero correcto de carácteres, por lo que sino me equivoco no queda otra que problemas en la recepción, pero es que es muy extraño porque en el simulador el tiempo esta correcto, además ahora he hecho lo que había dicho antes, de coger los datos en el centro de cada dato, por lo que tengo un margen bastante grande para recoger el dato :S.

¿Alguna idea de que puede ser el problema? Pongo la funcion de recepción aquí de nuevo:

Código: [Seleccionar]
if(INTF==1){
__delay_us(130);
for(i=0;i<8;i++){
recibido=recibido>>1;
if(RB0==1){
recibido = recibido | 0x80;
}
if(RB0==0){
__delay_us(3);
}
if(i!=7)__delay_us(83);
}
probando[indice]=recibido;
control_uart=1;
indice++;
CLRWDT();

Es a 9600 baudios, por lo que es un bit cada 104us, he colocado un retardo de 130 al principio para coger el dato en el medio, que serían los 104us + 26us añadidos por mí + retardo por la interrupción + retardo por las instrucciones = aproximadamente 156 diría yo.

EDITO: He hecho otra prueba, he recogido los datos por la UART software, pero le he metido un retardo de 8 segundos antes de enviar para que me diera tiempo a cambiar el cable RS232 en la placa  :lol: para ver exactamente que estoy enviando, y efectivamente, recoge los datos erroneos, y de 8 caracteres que he enviado 7 erán el caracter 253 en ascii, que es este "²", el superindice 2 ese, en binario "11111101", casi todo unos, cuando yo he enviado "atatatat", donde la 'a' es "11111101" y la t "1110100".

No comprendo que puede estar pasando... ¿que retardo puede haber en la generación de la interrupción?¿Y al despertarse del sleep? Bueno eso suponiendo que sea problema de la recepción en la UART software, que yo creo que con esto ha quedado claro que si.

Un saludo!

EDITO 2:

He visto en esta página http://www.cursomicros.com/avr/proteus/configuracion-propiedades-pic.html lo siguiente:



¿Eso es cierto? ¿Al despertar el pic hay un retardo de 1024 ciclos de reloj?
« Última modificación: 09 de Julio de 2012, 14:01:35 por Clemen89 »

Desconectado Clemen89

  • PIC10
  • *
  • Mensajes: 30
Re: Dudas del perro guardián
« Respuesta #26 en: 10 de Julio de 2012, 08:37:30 »
Ah y otra cosilla mas, tengo a disposición el MPLAB ICD 2, ¿se podría hacer algun tipo de debugger para saber exactamente donde esta fallando con este dispositivo? Es que se que se puede usar de debugger pero no tengo muy claro hasta que punto.

Un saludo de nuevo!

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Re: Dudas del perro guardián
« Respuesta #27 en: 10 de Julio de 2012, 15:03:25 »
Hola.

Pues según el datasheet:

Citar
12.6 Oscillator Start-up Timer (OST)

The Oscillator Start-up Timer (OST) provides a delay of
1024 oscillator cycles (from OSC1 input) after the
PWRT delay is over (if PWRT is enabled). This helps to
ensure that the crystal oscillator or resonator has
started and stabilized.
The OST time-out is invoked only for XT, LP and HS
modes and only on Power-on Reset or Wake-up from
SLEEP.

Parece que cumples con los requisitos, por lo que debería estar generando dicha demora. Podrías ajustar los tiempos y volver a intentarlo, teniendo en cuenta esta demora adicional.

Con respecto al ICD2, la verdad que no soy un gran debugueador utilizándolo. De hecho sólo utilizo el Pickit 3 para debuguear. Por ahí un osciloscopio sería de mayor interés si puedieses medir la demora entre que envias una señal para que despierte al uC, y el uC responda. (por ej. utilizando RB0 para desperar al uC del sleep y toggleando una pata inmeditamente luego de levantarse)

Saludos.
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.


 

anything