Posibles "bugs" del compilador de CCS

[tithanae]

Otro BUG  version 4.049
El archivo .h de el 18F25K20 esta incorrecto utiliza el del 18F2520 la parte que esta mal es la de el oscilador interno para arreglarlo colocar esto en el achivo 18F25K20.h:

Código: [Seleccionar]

////////////////////////////////////////////////////////////////// INTERNAL RC
// Constants used in setup_oscillator() are:
// Constants used in setup_oscillator() are:
// First param:
#define OSC_31KHZ   0// este es el arreglo
#define OSC_250KHZ  0x10
#define OSC_500KHZ  0x20
#define OSC_1MHZ    0x30
#define OSC_2MHZ    0x40
#define OSC_4MHZ    0x50
#define OSC_8MHZ    0x60
#define OSC_16MHZ   0x70
#define OSC_32MHZ   0x4060
#define OSC_64MHZ   0x4070
/*#define OSC_31KHZ   0              esto es  lo que tiene originalmente
#define OSC_125KHZ  0x10
#define OSC_250KHZ  0x20
#define OSC_500KHZ  0x30
#define OSC_1MHZ    0x40
#define OSC_2MHZ    0x50
#define OSC_4MHZ    0x60
#define OSC_8MHZ    0x70*/

[jhozate]

  vaya me sacaron de una duda q tenia, yo programo en assembler y pss no habia leido el datasheet en el 16F84 y resulta q estaba haciendo un programa sencillo de interrupcion por cambio de estado de RB4:RB7 y tambien tenia el problema de q el programa no se me salia de la interrupcion, y tambien me dijeron q agregara a la rutina la instruccion de relleno "movf portb,w" y de esta manera se solucionó el problema

gracias

[Cryn]

queda claro que es un bug de usuario entonces

que mal, los de microchip deberían haber corregido eso, me parece que debería limpiarse solo

[jhozate]

no no no gente, investigando mas,,,no es un bug, lo q pasa es q cuando se habilita interrupcion por cambio de nibble, para esta interrupcion no se especifica si el cambio es de 0 a 1 ó de 1 a 0, es por eso qse hace necesario incluir una rutina ya sea de lectura o escritura, es para dejarle fijado al micro el estado de los bit y de esta manera pueda darse cuenta de q hubo un cambio en el nibble.
esta es la cita textual de donde saque la info
"interrupcion por cambio de estado en las entradas RB4-RB7. se deshabilita mediante el bit RBIE del registro INTCON.cuando en cualquiera de las entradas RB4-RB7 se produce un cambio de estado logico respecto al ultimo valor leido en las mismas, el flag RBIF del registro INTCON refleja dicho suceso. para poner esta interrupcion es necesario leer el puerto B de entrada y registrar el nuevo valor de RB4-RB7 asi como poner a 0 el bit RBIF.

otra cosa,,en el datasheet si esta especificada dicha rutina tambien

aqui esta la cita:
"Four of PORTB’s pins, RB7:RB4, have an interrupt-onchange
feature. Only pins configured as inputs can
cause this interrupt to occur (i.e., any RB7:RB4 pin
configured as an output is excluded from the interrupton-
change comparison). The input pins (of RB7:RB4)
are compared with the old value latched on the last
read of PORTB. The “mismatch” outputs of RB7:RB4
are OR’ed together to generate the RB Port Change
Interrupt with flag bit RBIF (INTCON<0>).
This interrupt can wake the device from SLEEP. The
user, in the Interrupt Service Routine, can clear the
interrupt in the following manner:
a) Any read or write of PORTB. This will end the
mismatch condition.
b) Clear flag bit RBIF.
A mismatch condition will continue to set flag bit RBIF.
Reading PORTB will end the mismatch condition and
allow flag bit RBIF to be cleared.
The interrupt-on-change feature is recommended for
wake-up on key depression operation and operations
where PORTB is only used for the interrupt-on-change
feature. Polling of PORTB is not recommended while
using the interrupt-on-change feature."

esta claro no..??

[Cryn]

si, yo decía que es un error nuestro por no habernos fijado la hoja de datos

cuando uno usa la interrupción por RB ya esta consiente en que estados estarán y solo espera que se modifiquen, bueno al menos cuando se usa pulsadores, quizá para otras aplicaciones si sea necesario, pero por ahora yo no le encuentro razón de reescribir el portb, porque no admite solo una lectura y escritura, debe ser simultaneo para recién borrar el flag

y si esta clarísimo pregúntamelo a mi que me pase muy buen tiempo intentando descubrir la falla que tenía

un saludo

[Suky]

Cuando se usa interrupción por comparadores analógicos del PIC, se debe leer o escribir el registro CMCON. Al igual que para la interrupción por RB4-RB7 no lo veo implementado en el compilador CCS  versión 4.014.

[KALLITOS]

Hola, bueno uso el CCS 4.074 y tengo problemas con las multiplicaciones x100, es raro porque con multiplicaciones con 10, 1000 o 10000 va bien, solo con 100 tengo problemas, y lo soluciono de la siguiente manera:

Código: [Seleccionar]

valor = 0;
while(byte_4 !=0)          //SE REALIZA ESTO POR QUE LA MULTIPLICACION X100 ES ERRONEA
      {
      valor += 100;
      byte_4--;
      }
donde byte_4 es el valor que deseo multiplicar.

Otra es que cuando realizo el anterior procedimiento con una variable del tipo float32 se acumulan errores es decir si multiplico 1 por 500 me da resultado 503.4 y a mayores valores el error se acumula, lo solucione trabajando primero con int32 y luego paso el resultado a float32 para continuar con los calculos

Código: [Seleccionar]

resultado=(float32) resultado_1;
         resultado /= cifra_2;
         printf("resultado: %f%%\r\n",resultado);
Bueno espero le sirva a alguien.
Saludos.

[migsantiago]

Hola Kallitos

Deberías poner el código que supuestamente falla y después las soluciones. Cuesta trabajo imaginarse el error si no muestras cómo declaraste las variables y cómo son modificadas.

[KALLITOS]

Hola y disculpas por no responder, bueno aqui les pego un trozo de codigo como ejemplo:

Codigo fallido

Código: C

1. int16 valor = 0;
2.             byte_3 -= 48;
3.            
4.             valor = byte_3 * 100;

Solucion

Código: C

1. int16 valor = 0;
2.             byte_3 -= 48;
3.            
4.             while(byte_3 != 0){byte_3--; valor += 100;}

[migsantiago]

El valor '100' es un int8. Si la variable byte3 es declarada como int8, entonces no creo que sea bug de ccs.

Al multiplicar un int8 por un int8 el resultado será un int8, a pesar de que puede exceder a un int8. Hay 2 formas de hacerlo correctamente en mi opinión:

Haciendo casting.

Código: [Seleccionar]

int16 valor;
int8 byte_3=48;

valor = (int16) byte_3 * 100;

Declarando a byte_3 como int16

Código: [Seleccionar]

int16 valor;
int16 byte_3=48;

valor = byte_3 * 100;

Al declarar a byte_3 como int16 se crea un casting automático sobre el valor 100, convirtiéndolo en un int16.

No creo que sea un bug de ccs, solo es manejo de tipos de variables.

[KALLITOS]

Hola MigSantiago, realizando el casting funcionó, no realice con byte_3 a int16 debido a que trabaja con otros bytes y en momentos hago comparaciones como

Código: C

1. if (byte_2 == 'S')

o

Código: C

1. if (byte_5 == 'A')

entonces realizar eso con int16 supongo habra problemas por definicion de variables.

El valor '100' es un int8. Si la variable byte3 es declarada como int8, entonces no creo que sea bug de ccs.

Pero realizando multiplicacion por 10 si funciona, como sería en este caso?

Gracias por las respuestas Mig 

[migsantiago]

El valor '100' es un int8. Si la variable byte3 es declarada como int8, entonces no creo que sea bug de ccs.

Pero realizando multiplicacion por 10 si funciona, como sería en este caso?

Gracias por las respuestas Mig 

Hola Kallitos 

Hum, por favor pon un ejemplo. Hasta donde yo sé, si byte3 es un int8 y lo multiplicas por '10', el resultado va a ser correcto mientras sea menor a 255. Por ejemplo,

Código: [Seleccionar]

int16 valor;
int8 byte3 = 25;

valor = byte3 * 10;

Valor valdrá 250. Si byte3 valiera 26, valor ya no contendría el valor completo porque 260 ya requiere más de 8 bits para ser expresado.

[KALLITOS]

Hola mig, escribo desde el trabajo, bueno creo que cometi error en la explicación aqui va el ejemplo completo y explico lo que hago en mis codigos.

Realizo la recepción USART por interrupcion y siempre byte a byte con el sgte codigo

int byte_1,byte_2,byte_3,byte_4,byte_5,byte_6;
int 16 valor;

byte_6 = byte_5;
byte_5 = byte_4;
byte_4 = byte_3;
byte_3 = byte_2;
byte_2 = byte_1;
byte_1 = getc();

if (byte_1 = 13)
   {
      byte_2 -= 48;     
      byte_3 -= 48;     
      byte_4 -= 48;     
      byte_5 -= 48;     
      byte_6 -= 48;     
      valor = 0;

      valor = byte_5 * 10000;
      valor += byte_4 * 1000;
      while(byte_3 != 0){byte_3--; valor += 100;}
      valor += byte_2 * 10;
      valor += byte_1;
      }

[migsantiago]

Ah ya veo, estás pasando de ASCII a entero.

Código: [Seleccionar]

      valor = byte_5 * 10000; //Funciona porque 10000 es un int16 y hace un casting implícito sobre byte_5 a int16
      valor += byte_4 * 1000; //Funciona porque 10000 es un int16 y hace un casting implícito sobre byte_4 a int16
      valor += byte_3 *100; //No te funciona porque 100 es un int8 y no hace casting implícito, debes hacer uno explícito para pasarlo a int16
      valor += byte_2 * 10; //Funciona porque el número va a ser de 0 a 9, el resultado será 0 a 90, que caben en un int8 normalmente
      valor += byte_1;

La forma correcta de lo anterior debería ser:

Código: [Seleccionar]

      valor = byte_5 * 10000;
      valor += byte_4 * 1000;
      valor += (int16) byte_3 * 100;
      valor += byte_2 * 10; //Lo dejo así porque ya se sabe que byte_2 nunca excederá el 9
      valor += byte_1;

Es cuestión de manejo de castings. 

[KALLITOS]

Muy bien Mig, entendido, realice la siguiente prueba:

Código: Microchip Assembler

1. printf("HOLA MUNDO CRUEL!!!\n\r");
2.     byte_1 = 23;
3.     byte_1 *= 10;
4.     byte_2 = 26;
5.     byte_2 *= 10;
6.     printf("byte_1 = 23 : %u\n\r",byte_1);
7.     printf("byte_2 = 26 : %u\n\r",byte_2);

Y en el virtual terminal de PROTEUS, obtuve lo siguiente:

HOLA MUNDO CRUEL!!!
byte_1 = 23 : 230
byte_2 = 26 : 4

Fue un bug CCS, mito o verdad??
Mito, bug humano  .

Ahora a trabajar con castings 

Gracias Mig, me desasnaste!!!