Posibles "bugs" del compilador de CCS

[RALF2]

Mira las opciones de Use_Delay() .
Prueba ponerle Crystal en vez de Clock (esta opcion ahora es distinta) y despues me dices si hay resultado...

Porque no trabaja con #use delay(clock= 20000000) y si con #use delay(crystal= 20000000),  MGLSOFT?

En que parte del manual habla de ello?

[MGLSOFT]

Ultimamente los nuevos PICs traen tantos perifericos nuevos que asustan...

Tan solo pensar que el PIC18F26K80 tiene 6 configuraciones posibles del Oscilador interno, mantiene las configuraciones del cristal externo y agrega la posibilidad de otra fuente de oscilador externo, y por ultimo puedes arrancar el micro con un cristal, y luego marchar con el otro, o pasar a usar el oscilador interno....  Uff, me agarro un mareo!!
No les pasa lo mismo ??

Como siempre hacen los de CCS, escriben codigo para que te sea facil e intuitivo hacer esta configuracion, que en C30 debe ser un kilometro de sentencias, seguramente.

En la misma sentencia que escribio Diego le dice que tiene cristal externo a xx Mhz y oscilador interno a la misma frecuencia.
Que hace Diego ?? Se asegura que el micro trabaje siempre a la misma velocidad de clock, de otro modo no le funcionan las comunicaciones. Simple.
Por eso es un Maestro, y nosotros solo podemos ayudarlo a ser mas grande todavia...

[RALF2]

Es bien extraño lo del #use delay, yo lo voy a probar con las dos versiones que te coloque para ver si me funciona la comunicacion o me falla como a Redpic 

[RALF2]

Ok lo probe en el proteus en el modo Debug para ver los registros y al parecer todo esta bien 

#include <18f2550.h>
#use delay(clock= 20000000)
#fuses HS,MCLR,NOWDT,NOPROTECT,NOPUT,NOBROWNOUT,NOPBADEN,NOLVP,NOCPD,NODEBUG,NOWRT,NOVREGEN

#use rs232(baud=115200,xmit= pin_c6,rcv=pin_c7)

void main()
{
   printf("Hola Amigos del Foro");
   
   while(true);
}

Adjunto resultados de la simulacion.
SPBRG = 42, BRG16=1, BRGH=1  esos son los valores que deben tener los registros para operar a 115200 Baud   

Y segun el data sheet el error es de 1.6% aprox   

[MGLSOFT]

No creo que Diego lo haya probado en Proteus, mas bien estoy seguro que lo ha hecho en una placa ya armada, y bien sabemos las diferencias entre simular y probarlo en la practica...

[RALF2]

No creo que Diego lo haya probado en Proteus, mas bien estoy seguro que lo ha hecho en una placa ya armada, y bien sabemos las diferencias entre simular y probarlo en la practica... Mr. Green

Exacto MGLSOFT, intentare probarlo en fisico luego a ver que sucede  

Asi podemos ver si es un bug del CCS como cosa rara o no 

[RedPic]

Exacto. Yo no uso el Proteus (o similar) desde que era un bebé.  

Lo que hemos estado tratando ha sido con un 18F2550 real como la vida misma y compilando con las dos versiones del CCS, la 4.140 y la 3.242, programando después el PIC y mirando los resultados con el SIOW.EXE

Con la configuración del USE DELAY con sólo el CLOCK no calcula bien el Baudrate en la versión 4.140, al añadirle el CRYSTAL ha salido funcionando perfectamente.

Imagino que tiene razón MGLSOFT ya que una cosa es el cuarzo físico que le ponemos al PIC y otra cosa muy distinta es el Clock al que éste va corriendo, este mismo 18F2550 tiene un montón de posibles frecuencias de funcionamiento para un mismo cristal externo, y creo que habrá otros con mas variaciones posibles.

[MGLSOFT]

Di la verdad !!
El Proteus no existia cuando tu fuiste bebe !!

[RALF2]

Bueno realizando las pruebas con un pic18f2550, temo decir que si uno no coloca
#use delay(crystal= 20000000) el circuito no furula 

Al colocar #use delay(clock= 20000000), no solo falla el RS232 como menciono Redpic, sino que tambien los delay y todos los que dependan de este se ven afectados, los probe poniendo a parpadear un led cada 500ms y tardaba mucho en parpadear si colocaba clock en vez de crystal 

Luego realice pruebas con un pic18F252 y este opera bien tanto con clock como crystal, asi qe por si las moscas creo que lo aconsejable sera usar crystal para ir seguro 

[RALF2]

Los bits causantes del fallo son los del CONFIG1L
Cuando se seleccion clock estos toman el valor de 0x3F
Y cuando se coloca crystal toman el valor correcto de 0x04

Misterio resuelto 

[PalitroqueZ]

por lo visto la directiva delay() permite 4 tipos de argumentos aparte de clock, que según la ayuda son: oscillator, internal, crystal y rc.

estos parámetros configuran los word configuration del micro de una forma que desconozco porque no está documentada

[RALF2]

Asi es Palitroquez!
La unica forma es realizando pruebas cambiando el tipo de opcion: crystal, internal,... y ver como se programan los fuses por parte del compilador  

[RedPic]

Lo curioso es que yo he colocado los dos parámetros y así es como me ha funcionado.

Código: CSS

1. #use delay(clock=20000000,Crystal=20000000)

[MGLSOFT]

Lo curioso es que yo he colocado los dos parámetros y así es como me ha funcionado.

Código: CSS

1. #use delay(clock=20000000,Crystal=20000000)

Y funciona bien, porque le estas diciendo la frecuencia del cristal externo y la del oscilador interno.
Esta correcto en el codigo!!

[murphy9]

Hola a todos, siguiendo con los problemas de usart, les comento que hace tiempo publiqué el siguiente mensaje; Problema con interrupción USART y finalmente creí solucionarlos. El tema es que más adelante debí cambiar un poco el programa y ya nunca más pude realizar la comunicación utilizando interrupciones asi que tuve que usar la función kbhit(). Leyendo el foro veo que quizás mi problema estaba en la declaración del cristal, así que mi pregunta es la siguiente:
Si tengo configurado los siguientes FUSES, como debería configurar el #use delay si uso un PLL y un cristal de 20 MHz para que la comunicación pueda establecerse usando la interrupción por RDA?

#include <18f2550.h>
#fuses HSPLL,PLL5,PUT,CPUDIV1,NOPBADEN,NOVREGEN,WDT2048,wdt,NOPROTECT,NOLVP,NODEBUG,MCLR
#use delay(clock=48000000)
#use rs232(baud=1200,parity=n,xmit=PIN_c6,rcv=PIN_c7,bits=8)

Muchas Gracias