Autor Tema: Fallo - Rs232 (Leído 5789 veces)

jaumegs · « **en:** Domingo 8 de Enero de 2006, 17:34 »

Hola,

Se que esto se pide mucho por aqui, pero no me queda otro remedio...

Miren, este codigo (sacado del FTP del foro, un poco modificado) teóricamente tocaría funcionar para la transmisión y recepción serie...

Lo alucinante es que antes me funcionaba, bueno, me explico...
HAce unos dias formatee el ordenador... y me olvidé de guardar todos los programas para los PIC. Entre ellos, un programa que me funcionaba muy bien, era este mismo código(un poco mas modificado). Este código funcionaba bien, pero no se porque ahora no hay forma...

Lo he probado en simuladores y funciona bien, no da ningún error. Puedo pensar que es el hardware... pero estoy mas que arto de montarlo y desmontarlo...

Código: Text

;------------------------------------------------------------------------------
; DECLARACIÓN DE VARIABLES
;------------------------------------------------------------------------------
 
#Define    RxD  PORTB,4  &#59; Receive Data
#Define    TxD   PORTB,5  &#59; Transmit Data
 
tempData1  EQU  0x44
counter2  EQU  0x45
counter1  EQU  0x46
 
;------------------------------------------------------------------------------
 
RS232_setUp:
  bsf STATUS,RP0  &#59; Segundo banco
 
  bsf RxD    &#59; Configura la entrada
  bcf TxD    &#59; Configura la salida
 
  bcf STATUS,RP0  &#59; Primer banco
 
  return    &#59; Retorna donde fue llamada
 
;------------------------------------------------------------------------------
 
RS232_readData:
 
  movlw 0x08
  movwf counter1
 
waitBegin
  
  btfsc RxD  &#59; Bit de START?
  goto waitBegin  &#59; No, sigue esperando
      &#59; Si, sigue el programa
 
  call wait_mc100  &#59; Espera a que termine el bit de START
  call wait_mc50  &#59; Espera medio bit para leer el primer bit de
      &#59; datos medio bit retrasado
readBit
 
  bcf STATUS,C  &#59; Supone que es &#34;0&#34;
  btfsc RxD  &#59; Es &#34;0&#34; realmente?
  bsf STATUS,C  &#59; No, es &#34;1&#34;
 
  rrf tempData1,F
  call wait_mc100
 
  decfsz counter1,F&#59; Ha leido todos los bits de datos?
  goto readBit  &#59; No, lee el próximo bit
 
  call wait_mc200  &#59; Si, espera al bit de STOP
  movf tempData1,W&#59; Pone el resultado en el acumulador
 
  return    &#59; Retorna donde fue llamada
 
;------------------------------------------------------------------------------
 
RS232_sendAsciiNumber:
  addlw '0'
RS232_sendData:
  movwf tempData1  &#59; Guarda el contenido del byte a trans-
      &#59;   mitir
  movlw 0x08  &#59; Número de bits a transmitir
  movwf counter1
  bcf TxD  &#59; Bit de START
  call wait_mc100
 
 sendBit    &#59; Comienza a enviar tempData1s
  rrf tempData1,F  &#59; Lleva el bit que se quiere enviar al
  btfss STATUS,0  &#59;  Carry para deducir su valor. ¿Es un
      &#59;  &#34;1&#34;  el bit a transmitir?
  goto sendZero  &#59; No, pues envía un &#34;0&#34;
 
 sendOne
  bsf TxD  &#59; Transmite un &#34;1&#34;
  goto endSendBit
 
 sendZero
  bcf TxD  &#59; Transmite un &#34;0&#34;
 
 endSendBit
  call wait_mc100  &#59; Este es el tiempo que estará en alto
      &#59;   o bajo
  decfsz counter1,1&#59; Comprueba que es el último bit
  goto sendBit  &#59; Como no es el último bit repite la 
      &#59;   operación
  bsf TxD  &#59; Envía dos bits de stop
  call wait_mc200
 
  return    &#59; Retorna donde fue llamada
 
;------------------------------------------------------------------------------
 
wait_createMc:
  movwf counter2  &#59; Aporta 1 ciclo de máquina
 
waitLoop
  decfsz counter2,1&#59; Aporta 1 c.m. cuando no se salta, y
      &#59;  2 c.m. si se salta.
  goto waitLoop  &#59; Aporta 2 ciclos de máquina
 
  return    &#59; Aporta 2 ciclos de máquina
 
 
;------------------------------------------------------------------------------
; RETARDOS
;------------------------------------------------------------------------------
 
wait_mc50:    &#59; La llamada &#34;call&#34; aporta 2 c.m.
  nop    &#59; Aporta 1 ciclo de máquina
  movlw 0Eh  &#59; Aporta 1 ciclo de máquina
  goto wait_createMc&#59; Aporta 2 ciclos de máquina
 
wait_mc100:    &#59; La llamada &#34;call&#34; aporta 2 c.m.
  movlw 1Fh  &#59; Aporta 1 ciclo de máquina
  goto wait_createMc&#59; Aporta 2 ciclos de máquina
 
wait_mc200:    &#59; La llamada &#34;call&#34; aporta 2 c.m.
  nop    &#59; Aporta 1 ciclo de máquina
  movlw 40h  &#59; Aporta 1 ciclo de máquina
  goto wait_createMc&#59; Aporta 2 ciclos de máquina
 

Bueno, aquí les dejo el código haber si me pueden hechar una mano.

SALUDOS

lalo_soft

Siempre me ha intrigado por que algunos insisten el crear por codigo los modulos que
existen por hardware en versiones de chips posteriores al que estan usando

.

1.-Por costo dicen algunos :
El codigo que posteo nuestro amigo tiene cara de pic16F84 y este micro es reemplazado con creces por el pic16F877 con un costo en dinero no muy mayor que F84
y con prestaciones de modulos de hardware(UART,ADC,PWM,TIMER,COUNTERS) que haran que el codigo sea mas poderoso y eficiente .Por que los que cren que ahorran dinero entre un modelo y otro, la verda es que lo gastan tratando de implementar los modulos que necesitan por codigo

dejando poca memoria para la aplicacion es si misma, bajas prestaciones y largos tiempo de desarrollo.

2.- Por espacio dices Otros.
Donde cave uno de 16Pines cave uno de 28Pines sin grandes coseciones de espacio.

3.-Por aprender mas.
Si se acostumbran a las malas pacticas de querer reinvertar la rueda su vida laboral sera dificil y llena de proyectos a medio terminar.

Como humilde desarrollador de sistemas embebidos con 15 años de experiencia les aconsejo elegir sus chip de acuerdo a los requerimientos reales de su proyecto y no ahorren centavos pensando que lo solucionaran todo por codigo .

Recuerden cliente satisfecho = fama y fortuna.

Saludos.

Kain589

Cita de: "lalo_soft"

2.- Por espacio dices Otros.
Donde cave uno de 16Pines cave uno de 28Pines sin grandes coseciones de espacio.

Yo pienso igual que tu.
Y ni por el espacio, existen micros superiores al f84 con mas modulos, incluido usart y que tiene el mismo patillaje para poder sustituirlo en el mismo circuito

Huguen_aus_Tirol · « **Respuesta #3 en:** Lunes 9 de Enero de 2006, 00:08 »

Hola! Estoy muy de acuerdo con Lalo_soft! Personalmente, cuando me hace falta un periférico, busco el micro que ya lo tenga implementado. Después es solo configurar algunos registros y, depende el caso, un poco de código.

Pero también veo que aquí en el foro la mayoría es gente que se inicia en este mundo, aparentemente muchos estudiantes. Por este motivo no veo mal que hagan experimentos y pruebas, mientras se disponga de tiempo y ganas. Ya se darán cuenta con el tiempo y la experiencia de qué es lo más conveniente...

En cuanto a costos, es mejor tener un micro con algún periférico que no usemos (es decir, pagar por un periférico extra) que implementar alguno por soft. Y en lo que respecta al 84, podemos ir olvidandonos de él; es más caro, e incluso está empezando a ser difícil conseguirlo...

Conclusión: como dice Lalo_soft, para cualquier proyecto, busquemos el micro que tenga el periférico que necesitemos. Si es para practicar, fines didácticos, o jugar, podemos buscar de hacerlo por soft... pero no nos compliquemos mucho

Saludos a todos!

jaumegs · « **Respuesta #4 en:** Lunes 9 de Enero de 2006, 18:12 »

Bueno, realmente yo también estoy deacuerdo... pero me interesaba practicar un poco...

Definitivamente utilizare el 16f876. Pero ahora el problema está en que solo he programado el 16f84... y desconozco los registros del 16f876 y como realizar tareas tales como la utilización de la UART.

Alguien podría recomendarme un lugar que explique esto?

SALUDOS

Huguen_aus_Tirol · « **Respuesta #5 en:** Lunes 9 de Enero de 2006, 22:30 »

Hola Jaumegs!
aquí te adjunto un archivo donde están declarados los registros para el 16F873; no debería haber problemas si lo usas con el 876. Solo tienes que incluirlo en tu .asm
Te recomiendo bajar de la página de Microchip el manual del 16F876, te será de gran ayuda.
Luego es solo configurar un par de registros... Pruebalo, y nos cuentas. No creo que tengas mayores problemas.

Saludos

lalo_soft

Hola tambien Jaumegs!

El 16F873 es un buen punto de partida para empezar a familiarizarte con la configuracion y uso de modulos de hardware (timers,countest,adc,pwm,i2c,uart,spi) ya que este modelo los intrengra en una capsula de 28 pines con un ancho de 0.3 ,si con el tiempo puedes emigrar a

lenguaje C para PICs en lugar de asembler tus aplicaciones seran mas poderosas.

Saludos y sabia desicion

.

lalo_soft

Otra cosa comiensa desde ya a a probar con interrupciones si es que aun no lo has hecho ,te sera de inmensa ayuda .

Kain589

En C es mas facil programar pero menos poderoso que en asembler

Huguen_aus_Tirol

Hola muchachos!
Desde hace un tiempo estoy entrando en el lenguaje C. Me simplifica muchas cosas, como por ejemplo el manejo de un LCD, ó trabajar con números reales...
Pero en algunos aspectos el asembler tiene sus ventajas.
De cualquier manera, creo que debemos empezar con el asembler, y luego pasar al C; esto nos dá más poder sobre el micro

Además, según mi punto de vista, el asembler nos "forma" una manera de pensar que simplifica bastante las cosas con, por ejemplo, el C.

Saludos!

lalo_soft

Discrepo con Tirol el asembler te estreza (debes concentrarte mucho con cada linea de codigo para no llevarte por delante un registro o celda de memoria que ya esta ocupado).En cambio C te permite concentrarte unicamente en la aplicacion y que el compilador se las arregle con los bancos de memoria y asignacion de registros.

lalo_soft

Kain589 ¿que es lo poco poderoso de C ? con fundamento!!

Huguen_aus_Tirol

Hola! (de nuevo!)
Es cierto, con asembler, normalmente, necesito el mismo, o más, tiempo para depurar el programa de lo que me lleva escribirlo

Pero con asembler podemos ahorrarnos algo de memoria, depende el caso bastante. Si, si... cada vez salen micros con más capacidad de memoria; están orientados a la programación en C.
Y, sostengo lo que dije en el mensaje anterior, porque me estoy iniciando en C. Cuando le agarre la mano, seguramente pensaré de otra forma

Bueno, parece ser que nos estamos desviando y deberíamos pasar a la sección de programación en C

Y ya que estamos en el baile... cómo usar rutinas en asembler en un programa escrito en C?

Desde ya las gracias y un saludo cordial a todos!

Kain589

No he dicho que sea poco poderoso, sino que lo es menos que assembler.

La velocidad para realizar los procesos es mayor en assembler, ya que los compiladores no minimizan al maximo el tamaño de codigo, cosas que si eres tu el que programa y sabes te saldra un codigo mucho mas compacto y por tanto mas veloz en ejecucion, para encender un led da igual pero habra procesos en los que el tiempo es critico.

Assembler te permite entender y comprender mejor a los microcontroladores y tener un dominio mayor sobre ellos, en C se pierde un poco la esencia del micro: el tener que configurar registros, activas bits de un registro...por ejemplo el configurar el adc, en assembler tienes que saber en cada momento que significa cada bits de los registros implicados y como configurarlo, en c tienes que configurar pero de una forma menos completa(ya te lo hace el)

En C lo mismo estas programando un pc, que un micro, que una tostadora(ya se que no se programan) lo que quiero decir es que se pierde de vista el concepto del hardware y en gran parte de su funcionamiento y configuracion. la prueba es que cualquiera puede programar en C pero no en assembler

P.D. Esto se desvia del mensaje pero lo pongo porque la pregunta esta en este hilo

lalo_soft

Citar

La velocidad para realizar los procesos es mayor en assembler, ya que los compiladores no minimizan al maximo el tamaño de codigo, cosas que si eres tu el que programa y sabes te saldra un codigo mucho mas compacto y por tanto mas veloz en ejecucion, para encender un led da igual pero habra procesos en los que el tiempo es critico.

Los procesadores tipo Risc como los Pics se caracterizan por optimizar codigo por dos
caminos (Tamaño o Tiempo de ejecucion).Caso curioso que para lograr la mayor velocidad hay que evitar compactar codigo, si no crees revisa los ejemplos de Microchip
para tamaño y velocidad,te daras cuenta que para velocidad no escatiman en el gasto de memoria.Asi que no va lo de mas compacto = mas velocidad por el contrario.

Citar

Assembler te permite entender y comprender mejor a los microcontroladores y tener un dominio mayor sobre ellos, en C se pierde un poco la esencia del micro: el tener que configurar registros, activas bits de un registro...por ejemplo el configurar el adc, en assembler tienes que saber en cada momento que significa cada bits de los registros implicados y como configurarlo, en c tienes que configurar pero de una forma menos completa(ya te lo hace el)

El entendimiento de un micro no te lo da su asembler sino el conocimiento de bloques y modulos,caracteristicas electricas de sus puertos,etc.
No se si tiene algun sentido en estos tiempos sumergirse (lo hice en el pasado) en los detalles de que el bit5 del registro N hace tal o cual cosa si existe una funcion en
C que lo configura en forma correcta (si esto no es un dominio mayor, no se que lo es) de acuerdo a los parametros que le entregas para despues trabajar en forma eficiente con ese modulo que C configuro y que te funciona a la primera.

Citar

quiero decir es que se pierde de vista el concepto del hardware y en gran parte de su funcionamiento y configuracion.

No es cierto por que el Hardware que estas programando lo diseñaste y construiste tu mismo por tanto estas siempre ligado a su esencia.

Citar

la prueba es que cualquiera puede programar en C pero no en assembler

Durante años programe para varios micros (Z80,8031,68000,6800,Pics,ARM) en asembler se lo que es lidiar con asemblers de diferente tipo pasando horas revisando rutinas que parecian optimas y que no funcionaban por que colocates datos en un registro o memoria ya ocupada del cual no te diste cuenta.Ahora con el cambio a C (que no es una moda sino una necesidad) no retorno al asembler.

jaumegs

Bueno... creo que nos hemos desviado un poquito del tema, pero al crearse estas discusiones siempre da gusto leerlas

Creo que la elección de programar en ASM o C es algo que debe realizar uno mismo. El ASM te hace tomar un contacto mayor con el micro, programar en C (no he programado en C nunca para un microcontrolador... para PC si) es mejor para optimizar el tiempo y no pasarte horas con algo que no te sale, o si quieres un programa para un PIC y otro tipo de micro y canviar unas cuantas lineas de código, no un programa entero (no se si eso es posible, pero si se sigue la misma teoria que en los computadores...).

Todo es cuestión de uno mismo, si uno es un poco masoca, como yo, y le gusta decirle al micro lo que ha de hacer en cada preciso instante sin importarle el tiempo que gasta en ello... pues adelante, ASM. Si uno prefiere pasarse mucho menos tiempo, le da igual que el programa ocupe unos bits mas, y quiere que su programa sea mas portable, pues C.

Yo cuando le coja mas práctica al ASM me gustaria aprender C para PIC, alomejor resulta que me gusta mas

... no que va, creo que nunca se ha de perder el contacto con el ASM, programes en lo que programaes.

SALUDOS

P.D.- Bueno, a lo que íbamos, me estoy volviendo loco en canviar de micro... del 16f84 hay mucha documentación (en castellano) sobre sus registros, para que sirven, como usarlos,... en cambio con los 16f876 y otros no encuentro nada, escepto los documentos de Microchip en ingles, que por desgracia no es idioma que domino, y menos para aprender algo de programación, aunque mi interés por reforzarlo no desaparece.

NO existe por alli algo que te explique como usar la UART en un 16f876, el bus I2C, y esas cosas? (en ASM)

Kain589

Citar

Los procesadores tipo Risc como los Pics se caracterizan por optimizar codigo por dos
caminos (Tamaño o Tiempo de ejecucion).Caso curioso que para lograr la mayor velocidad hay que evitar compactar codigo, si no crees revisa los ejemplos de Microchip
para tamaño y velocidad,te daras cuenta que para velocidad no escatiman en el gasto de memoria.Asi que no va lo de mas compacto = mas velocidad por el contrario.

A ver, yo no soy el master de los pics, pero si no me equivoco segun los datasheet las instrucciones solo gastan 1 o 2 ciclos de reloj, dependiendo de cual sea. Por tanto a mas instrucciones, mas tiempo eso no tiene vuelta de hoja

Citar

No es cierto por que el Hardware que estas programando lo diseñaste y construiste tu mismo por tanto estas siempre ligado a su esencia.

Y luego lo que se pierde de vista el hardware es inevitable, digas lo que digas de todas formas yo no voy a discutir mas este tema. Exite una regla en programacion, y es que a mayor nivel en el lenguaje, mayor facilidad de programacion y menor dominio del hardware y optimizacion, cada vez esto va a menos pero sigue estando ahi. Aunque a lo mejor eso solo pasa en el resto del mundo excepto en tu caso.

Citar

Durante años programe para varios micros (Z80,8031,68000,6800,Pics,ARM) en asembler se lo que es lidiar con asemblers de diferente tipo pasando horas revisando rutinas que parecian optimas y que no funcionaban por que colocates datos en un registro o memoria ya ocupada del cual no te diste cuenta.

En ese caso no es assembler quien falla, es el programador

Para Jaumegs en la seccion de soluciones de hard y de soft puse un ejemplo de como usar la uart y de como use el adc

jaumegs

OK. Lo acabo de ver revisando los mensajes

eso pasa por no usar el buscador...

SALUDOS Y GRACIAS

Huguen_aus_Tirol

Hola muchachos! antes que se cierre la discución, quería decirles una cosita más...
Aquí hay mucha gente nueva que recién comienza, y no queremos confundirlos más. Lo mejor es comenzar con asembler y luego pasar al C. El C funciona bien con micros grandes, con bastante memoria de programa; pero si pensamos alguna vez usar algún 10F, ó algún 12F (por ejemplo), podemos olvidarnos del C.
Tanto C como asembler son solo herramientas, depende de nosotros saber cual es la herramienta adecuada para cada trabajo

Saludos

lalo_soft

Bueno Kain589 recojos tus respuestas con humildad y buen humor en el entendido que son para colaborar con la comunidad

.

Citar

En ese caso no es assembler quien falla, es el programador

No seas sobervio pues tu tambien y en mas de una ocacion debiste fallar en tus primeras rutinas de asembler, en C tampoco se esta libre de cometer errores , tambien
requiere de estudio y ensayo sobre todo si se viene del asembler .

Recuerda que siempre habra mas de una manera de hacer las cosas. Asembler y C son
herramintas poderosas cada una en su campo,la expreriencia y el trabajo con ambas dara la pauta de cual nos llevara a mejor puerto en nuestros proyectos.

Saludos.

Kain589

Cita de: "lalo_soft"

No seas sobervio pues tu tambien y en mas de una ocacion debiste fallar en tus primeras rutinas de asembler

No pretendia ser soberbio, y si eso ha parecido lo siento. Ademas aunque haya sido un dialogo entre dps este es uno de los puntos a tener en cuenta cuandop vas a resolver un problema, en que lenguaje lo haces.

Lo de que es fallo del programador y no assembler, no era a ti en particular sino en general porque mucha gente le ve esa desventaja ,que es cierta, a assembler que es mas facil cometer un error. Yo al inicio cometia errores, ahora los cometo y seguire cometiendolos, es ley de vida.

Toda mi defensa de assembler es porque creo que para el que comienza le permite y obliga a una mayor comprension del pic y de que pasos hacer para usar cada modulo: adc,usart, timers... y porque creo que en cuanto a potencia, en referencia a tiempo de ejecucion, el programa supera al hecho en C, diciendo esto como opinion sin querer volver a entrar en la polemica.

C tambien tiene sus ventajas, yo lo he utilizado poco pero leido bastante, como el hecho de que permite un programa que realice multiples funciones y usar los distintos perifericos tardando en realizar el codigo menos tiempo entre oytras cosas y supongo que tendra mas

lalo_soft

Citar

No pretendia ser soberbio
Lo de que es fallo del programador y no assembler, no era a ti en particular

Disculpado

. C es aun un mundo nuevo para los que programamos microcontroladores su potencial y aceptacion deben recorrer el largo camino que ya tiene el Asembler .No devemos olvidar que fuimos hijos del Asembler y en cierta manera durante esta discucion yo lo olvide.

Saludos a todos y sigamos enriqueciendo este foro desde nuestras trincheras.

lalo_soft

Como dato anecdotico el C (CCS) para Pics es el menos standar y portable hacia otros micro (como Atmel,ARM).