No hay buena adquisición

[PICpegaso]

Hola amigos!
Resulta que tengo un pequeño inconveniente con la adquisicion de los datos enviados por el PIC al computador, es un poco complejo de explicar pero trataré de ser lo mas claro posible. Pero me gustaría para empezar preguntarles si alguna ves a uds les ha pasado que uno de los registros del ADC no llega, es decir que uds deben transmitir 10 bits de datos y envian primero un registro y luego el otro y en algun momento de la transmision uno de estos falla.

Creo que por ahora lo dejo hasta ahi, si les ha pasado esto me gustaria saber como han hecho para solucionarlo, gracias
Saludos!

[maunix]

Hola amigos!
Resulta que tengo un pequeño inconveniente con la adquisicion de los datos enviados por el PIC al computador, es un poco complejo de explicar pero trataré de ser lo mas claro posible. Pero me gustaría para empezar preguntarles si alguna ves a uds les ha pasado que uno de los registros del ADC no llega, es decir que uds deben transmitir 10 bits de datos y envian primero un registro y luego el otro y en algun momento de la transmision uno de estos falla.

Creo que por ahora lo dejo hasta ahi, si les ha pasado esto me gustaria saber como han hecho para solucionarlo, gracias

mmm, me ha pasado que llegue deteriorado por algún problema de mala conexión pero no que no llegue en lo absoluto.

Has revisado bien el hardware? te falla siempre o de vez en cuando?  Si es la 2da opción tal vez estés sobreescribiendo el buffer de la usart de transmisión antes de que éste finalice.

[PICpegaso]

Hola maunix, mira te comento un poco más de este problema.
Estoy enviando datos por puerto serie al hyperterminal, utilizo un cristal de 4 MHz y una tasa de 19200 Baudios, convierto el dato con el ADC y procedo a enviar el registro bajo( ADRESL) al terminar y luego de que pase un tiempo prudencial envio el registro alto(ADRESH), bien, pues tengo un programa que me identifica que datos he enviado, hago un barrido desde GND hasta Vref+ y si al parecer lo hace muy bien, sin embargo en algunos momentos no envia el registro bajo, es decir, en el Hyperterminal me aparecen seguidos dos registros altos.

Entonces mi pregunta es si esto tiene que ser necesariamente por el cristal que estoy utilizando?, lo digo porque el datasheet me dice que para un cristal de 3.6864MHz tengo un porcentaje de error de envio de 0% mientras que para el de 4MHz tengo uno de 0.16%.
Sera necesariamente eso?, en todo caso voy a ver si puedo conseguir ese cristal.

[reiniertl]

prueba primero a enviar una cadena ASCII, porque lo más probable es que Hiperterminal no "entienda" alguno de los datos, crees que no llega pero si lo hace, lo que pasa es que probablemente el dato no sea un caracter ASCII y por tanto no "imprimible".

Hay dos soluciones, transmites el dato en formato ASCII, o cambias el programa en la PC. Pero primero lo primero, comprobar que el PIC y la PC se comunican bien, nada mejor que un "Hola Houston" enviado del PIC a la PC, si una cadena de ASCII plano puede ser enviada por el y recibida íntegramente en la PC entonces, el problema no está en la comunicación sino en la interpretación de los datos. Alguien no "entiende" lo que envías por el puerto serie.

Saludos
Reinier

[PICpegaso]

Hola reiniertl, eso que dices ya lo he hecho y no hay problema cuando envio datos conocidos, por ejemplo hice un pequeño programa que enviaba numeros de 0-255 con lo cual se barre toda la tabla ascii que el hyperterminal muestra, yo pienso que el problema esta con el cristal pero no estoy seguro, si no es porque me pongo a ver detenidamente todos los datos no me doy cuenta que en ocasiones no envía uno de los registros.
Otra cosa es que este error en la adquisicion no es periódico, es decir no se repite con una frecuencia determinada, por ejemplo, pueden pasar 300 datos y todos recibidos bien pero al siguiente no envia uno de los registros y luego pueden pasar 20  datos bien recibidos y el siguiente falla.
para que tengan una idea mas amplia les pongo la siguiente lista de numeros
120
0
110
0
65
1
1
59
0
106
1
25
1
98
2
...
esta lista corresponde a lo que recibo en el Hyperterminal, estoy justificando a la derecha, como ven los numeros grandes corresponden al registro bajo (ADRESL) el cual envío de primero, lo numero bajitos corresponden al registro alto(ADRESH) el cual envío despues. Si intercambio el orden de envio aparecen datos asi:
1
125
1
58
0
98
107
1
147
2
63
...
Si se dan cuenta, de acuerdo a cual registro envíe primero este es el que sufre el daño, el que envío de ultimo al parecer siempre llega.
Bueno amigos la verdad es que este problema lo puedo solucionar por software ya con los datos que tenga en el PC, pero no pensaba que cosas asi pasaran, eso me quita un poco de confianza en los PICs, pero bien puede ser que yo éste haciendo algo mal. Es por eso que les preguntaba si a uds le ha pasado.
SAludos

[PICpegaso]

Has revisado bien el hardware? te falla siempre o de vez en cuando?  Si es la 2da opción tal vez estés sobreescribiendo el buffer de la usart de transmisión antes de que éste finalice.

Efectivamente es la segunda opcion, tal ves sea eso que tu dices maunix pero como estar seguro?, aqui dejo el link del programa que estoy utilizando para la transmision, el cual hace ratico lo habia hecho tambien con tu ayuda programa
esta al final del hilo. Gracias

[PICpegaso]

Bueno, les comento que sucedio con el problema de adquisicion. En el programa que estoy utilizando al parecer no hay problema en colocar al registro TXREG el dato que quiero mandar al PC, pero resulta que tal como dice el maestro maunix el buffer de trabsmisión sigue lleno cuando llega el nuevo dato, por lo tanto, lo que hice fue borrar el registro TXREG justo antes de enviar el dato, esto para asegurar que el buffer se encuentre vacio cuando el nuevo dato llegue. Listo creo que he solucionado el problema al fin, si acaso se presenta alguna anormalidad les comento por aqui mismo, gracias por el interes, chaos.
Saludos!

[PICpegaso]

Hola a todos!, pues que lata seguir con el problema, pero ahora es algo que la verdad no se de que se trata. Ya los registros no tienen el problema de enviarlos bien excepto porque a veces se repite uno de los datos, es decir que aparece dos veces, esto no sería problema si solo necesitara de 8 bits pero el problema es que requiero los 10 bits de conversion del ADC y por esto es que repetir dos veces seguidas el mismo dato es un gran problema para mi, ya que luego de recibirlos debo agruparlos de a dos bytes para formar un único valor.

Gracias por las sugerencias
Saludos

[maunix]

¿Podes mostrar el código donde haces la transmisión?

[PICpegaso]

Maunix mira asi es como lo estoy haciendo,

      list p=16f873A

      include "p16f873A.inc" 

      org 0x00       

         nop
       
         nop
       
         bcf STATUS,RP0 ;Ir banco 0       

         bcf STATUS,RP1
       
         movlw b'01000001' ;A/D conversion Fosc/16 para el tiempo necesario de conversion ADC       

         movwf ADCON0
       
         bsf STATUS,RP0 ;Ir banco 1
       
         movlw b'00000001'
       
         movwf TRISA ;PORTA salida y AN0 entrada       

         clrf TRISB ;PORTB salida
           
         clrf TRISC ;PORTC salida
       
         movlw b'11001110' ;A/D Port AN0/RA0, justificado a la derecha
       
         movwf ADCON1
       
         movlw D'12' ; 19200 baud rate Xtal=4Mhz, es decir 19.2 bits por mS
       
         movwf SPBRG
       
         bsf TXSTA,BRGH ;Selección de alta velocidad
       
         bcf TXSTA,SYNC ;Modo asíncrono
       
         clrf OPTION_REG ;TMR0 preescaler, 1:2       

         bcf TXSTA,TX9 ;8 bits de datos a transmitir       

         bsf TXSTA,TXEN ;Activa la transmisión serial, TXIF = 1
       
         bcf STATUS,RP0 ;Ir banco 0       

         bsf RCSTA,SPEN ;habilita el puerto serie

      _bucle
     
         movlw D'40' ; Cuando llegue a 80uS, que es mas del tiempo necesario (20uS) para carga del sample and hold

         subwf TMR0,W ; Resta TMR0-W y lo guarda en W       

         btfsc STATUS,C
       
         goto _bucle ;Esperar que el timer0 llegue a 40
       
         bsf ADCON0,GO ;Start A/D conversion
       
      _espera
       
         btfsc ADCON0,GO ;ADCON0 es 0? (la conversion esta completa?)       

         goto _espera ;No, ir _espera

    clrf TXREG ; AQUI BORRO EL BUFFER

         bsf STATUS,RP0 ; ir a banco 1

         movf ADRESL,W ;Si, W=ADRESL       

         bcf STATUS,RP0 ; vuelve a banco 0   

    movwf TXREG

      _esperatx       

         btfss PIR1,TXIF ;Espera hasta que transmisión registro bajo culminó
       
         goto _esperatx

         nop ;

      _bucle33 ; RETARDO PARA ASEGURAR 1KHz DE MUESTREO   

         btfss INTCON,T0IF
       
         goto _bucle33 ;       

         bcf INTCON,T0IF ;Limpiar el indicador de desborde   

    clrf TXREG ; AQUI BORRO EL BUFFER

         movf ADRESH,W ;Si, W=ADRESH

         movwf TXREG

      _esperatx2

         btfss PIR1,TXIF ;Espera hasta que transmisión registro alto culminó

         goto _esperatx2

      _bucle44 ; RETARDO PARA ASEGURAR 1KHz DE MUESTREO
     
         btfss INTCON,T0IF       

         goto _bucle44 ;Esperar que timer0 desborde
     
         bcf INTCON,T0IF ;Limpiar el indicador de desborde

    clrf TXREG ; AQUI BORRO EL BUFFER

         goto _bucle ;Ir a bucle

         end

quedo muy atento de tus comentarios, gracias!
Saludos

[PICpegaso]

Hola amigos tengo una duda, he conseguido un cristal de 3.64Mhz pero es de tres patitas y pues para ser sincero no se como utilizarlo, si alguno de uds me da una manito en eso  , no se si este tipo sirva para el PIC. De todas formas sigo buscando el de 3.6864 Mhz de dos patas que aparece en el datasheet. Gracias!

Saludos

[maunix]

Antes que nada sugiero que el chequeo del flag TXIF lo hagas 'antes' de mover el registro WREG al TXREG.  Algo que tienes que tener en cuenta es que el hecho de que el flag se apague solo implica que el buffer esté lleno pero no que el dato ya fue enviado.

Si quieres realmente verificar que se haya vaciado el buffer debes verificar el bit TRMT del TXSTA.

También puedes modificar ligeramente tu programa para que siempre envíe lo mismo, por ejemplo 0x55 o 'A' , lo que tu quieras.  La idea es comprobar si es que el pic se está reseteando o no por algún defecto de hardware.



En cuanto a la otra pregunta, del 'cristal' de 3 patas supongo que hablas de un resonador.  El pin del medio suele ser masa y suelen venir ya compensados por lo cual no hace falta ponerle capacitores.

[PICpegaso]

En cuanto a la otra pregunta, del 'cristal' de 3 patas supongo que hablas de un resonador.  El pin del medio suele ser masa y suelen venir ya compensados por lo cual no hace falta ponerle capacitores.

eso quiere decir que las patas de las esquinas las conecto a OSC1 y OSC2 y la del medio a la tierra del circuito sin agregar condensadores?, la verdad no tenia idea de estos resonadores que imagino cumplen de igual forma la labor de los cristales convencionales.., gracias maunix, ahora debo hacer las pruebas que me indicas, tan pronto las realice comento los resultados.

Saludos