1 Bit a 9600 baudios y un Timer1 a 48 Mhz cuenta ...

[RedPic]

Un PIC182550, corriendo a 48 Mhz (PLL y eso), con el Timer1 configurado como T1_INTERNAL | T1_DIV_BY_1, debe contar ...

Un tick cada 1 / 48.000.000 * 4 o sea cada 0,083 uS (microsegundos)

Un Bit transmitido a 9.600 Baudios tarda 1 / 9.600 de segundo en pasar o sea 104 uS

Contando con el Timer1 deben pasar 104 / 0,083 ticks de Timer1 para un Bit a 9.600 baudios

O sea 1.253 Ticks de Timer1 por Bit a 9.600 baudios.

Si configurara o configurase la Interrupción por Desbordamiento de Timer1 para que saltase cada 104 uS debería "cebar" el Timer1 en cada interrupción con 65.536 - 1.253 = 64.283 para que al ser incrementado y alcanzar su desbordamiento me "avise" exactamente cada 104 uS.

¿No? ¿Es correcto mi discurso? ¿Es coherente? ¿Me he equivocado en los cálculos? ¿Es cierto? ¿Es una rosa? ¿Es un clavel? 

[MGLSOFT]

Creo que esta bien, pero como haras el cambio entre velocidades??
Y la velocidad de 115.000 Bps que necesitas con que la haras??

[RedPic]

No, esto es para otro tema. Es que tengo que comunicar con un cacharro que usa 2 bits de stop y el PIC solo detecta un bit de Stop por lo que cada vez que leo un byte pierdo un bit. así que me he puesto a desarrollar mi USART particular por Soft.

Detecto el flanco del bit de Start y sé que me van a llegar 12 bits completos a 9600 baudios, 1 bit cada 104 uS por lo que arranco el timer1 para recoger esos bits exactamente cada 104 uS.

Eso es lo que estoy haciendo, pero me encuentro que estoy recogiendo todos los bytes pero no tienen nada que ver con lo que sé que debería recoger, así que estoy cometiendo algún error y lo primero de lo que quiero asegurarme es de que mis timmings son los correctos ... y de ahí esta pregunta. 

P.D. Este hilo es consecuencia de lo tratado en #use RS232 1 bit Start, 8 bits de Data, 1 Parity (E) y ... ¿dos bits de Stop? y que ya estoy poniendo en marcha.

[todopic]

Hola Diego, creo que el error esta en que el primer bit, lo tienes que leer aen la mitad del recorrido, es decir 104/2=52 uS, asi lo "miras" en la mitad del bit, luego si, sigues con tus 104 uS 

espero sea eso!
Un abrazo!

Norberto

[MGLSOFT]

Si, barbaro el calculo, Diego, pero no termina alli...
El bit debe ser muestreado a determinado grado de avance (creo que al 30% dice la norma), y aunque hagas un calculo justo de los microsegundos de cada bit estas defasando indirectamente con las operaciones de reposicion del timer al valor de precarga.
Te recomiendo que estudies muy bien los tiempos que utilizas al hacer las recargas del timer, que por ahi se te escapan las liebres...
Ese tiempo debes restarlo a los microsegundos que te da cada bit, es la unica forma de tener un bit exacto.
Ademas si bien se permite un error de desfase, este cuanto mas parecido a cero mejor, especialmente si es por software.

[MGLSOFT]

Bueno, me ganaste Norberto!!

[RedPic]

Si, queridos Norberto y Marcos, lo he tenido en cuenta.

De hecho lo que hago para recoger un Byte es los siguiente:

• Con la INT_TIMER1 deshabilitada habilito la INT_EXT para detectar el flanco de bajada del bit Start.
• Cuando se dispara INT_EXT la deshabilito para que no vuelva a activarse y sé que este bit va a tardar los 104 uS de rigor así que precargo el TIMER1 con 104+52 uS y habilito la INT_TIMER1 para que se dispare justo en el centro del siguiente Bit, que es el Bit 0 de my Byte.
• Cuando se dispara INT_TIMER1 recogo ese Bit y ahora ya precargo el TIMER1 solo con 104 uS para que se me dispare ahora en el centro del siguiente Bit ...
• Repito esto último hasta recoger todos los Bits del Byte, el Bit de Paridad y los dos Bits de Stop.
• Voy contando los bits que recojo y cuando llego a 12 he terminado y deshabilito definitivamente INT_TIMER1 y vuelvo a habilitar INT_EXT para esperar al siguiente Byte.

Como podéis ver primero espero 104+52 uS para saltarme el Bit Star y aterrizar justo en el centro del primer Bit de datos y después varias veces 104 uS, tantas como Bits quiero leer. 

[MGLSOFT]

Edite porque me confundiste con Mario   

Bueno te recuerdo revisar esto:

Te recomiendo que estudies muy bien los tiempos que utilizas al hacer las recargas del timer, que por ahi se te escapan las liebres...

[Chaly29]

Don RedPic:

¿No? ¿Es correcto mi discurso? ¿Es coherente? ¿Me he equivocado en los cálculos? ¿Es cierto? ¿Es una rosa? ¿Es un clavel? 

Los calculos son correctos, lo unico que te recomiendo es que uses mayor exactitud, son 1250 tick

65535 - 1250 = 64285 (más lo que demore la interrupción en ejecutarce hasta el punto de lectura del bit)

Tal como comentó Norberto el primero (bit start) debés detectarlo a la mitad, luego los otros sí cada 104us

Por lo demas es todo correcto.

Un saludo.

Atte. CARLOS.

Pda. RS-232, lo e sufrido vastante por hardware 

[Nocturno]

Efectivamente son 1250, querido Diego.
De todas formas, aparezco por aquí para aconsejarte una herramienta fantástica para ajustar tiempos con precisión: el simulador de MPLAB. Tiene una ventana que te ayuda bastante porque te indica exactamente en qué microsegundo está ejecutándose cada instrucción.

Tienes que tener en cuenta los ciclos que se pierden al entrar en la interrupción, y antes de hacer la precarga del timer con un nuevo valor.

[maunix]

Diego, consideraste la posibilidad de usar también el CCP en modo de comparación? Lo veo mucho más adecuado para tus propósitos que andar calculando desbordes del timer1.

Alguna vez se me presentó el mismo problema que a vos pero lo resolví en assembly con un 16F876 a 20MHz.  El C se complica cuando se necesitan timings muy precisos como en una comunicación asíncrona como la que planteas sobre todo si recibes "muchos" bytes es probable que empieces a tener un desfasaje.

Ahora te propongo un cambio de enfoque a tu problema que según entiendo es que el dispositivo que deseas controlar trabaja con 1 bits start - 8 bits de datos - 1 bit de paridad - 1 bit de stop

En ese esquema me parece más simple hacer lo siguiente

1) Al recibir no tendrás problemas ya que tener 2 bits de stop no te afectará en nada.  Tu usart lo tomará como que hay un tiempo sin recibir nada (se mantiene la línea en Alto)

2) Al enviar podrías detectar el bit TMRT de la usart el cual te indica cuando salió el ultimo bit, a partir de allí esperas el tiempo del que hablas.

[MGLSOFT]

Igualmente en modo CPP hay que realizar la recarga del valor, pero me parece una buena opcion la que plantea Maunix....
Muy buena Mauricio !!

[maunix]

Igualmente en modo CPP hay que realizar la recarga del valor, pero me parece una buena opcion la que plantea Maunix....

Marcos creo que te estas confundiendo.  En modo CCP el valor queda fijo pero se resetea solito el timer (si lo configuras en el modo adecuado).

 

También está el timer2 y su registro PR2 pero no es tan preciso para delays largos.

[MGLSOFT]

O sea que precargas el valor una sola vez y despues cada vez que el valor del comparador se supera, vuelve al original ??
Joya !!

[maunix]

O sea que precargas el valor una sola vez y despues cada vez que el valor del comparador se supera, vuelve al original ??
Joya !!

La secuencia es así

1) cargas el comparador con el valor a comparar adecuado para los 104useg
2) Disparas el timer
3) cuando el valor del timer es igual al comparador -> se enciende el flag del comparador.  Acá uno puede configurar si el timer se vuelve a 0 o si sigue corriendo (en este caso si solo se lo hará correr un ciclo, da lo mismo).
y el ciclo se repite continuamente


En el caso de diego lo que sugiero es que cargue el CCP, dispare el timer cuando es momento de contar para un segundo bit de stop y cuando salta el flag , detiene el timer1, borra el flag del ccp1 , pone el timer1 a 0 (para dejarlo listo para la proxima comparacion) y ya puede enviar otro dato completo.