Posibles "bugs" del compilador de CCS

[PalitroqueZ]

anotado Bruno 

Gracias.

[migsantiago]

Estoy casi seguro de que éste es un bug.

Este código funciona perfectamente en otros compiladores (AVR):

Código: [Seleccionar]

      for (char j=0; j<8; j++)
      {
        if (Hello_World[i][k] & 1<<(7-j))    //Should there be a letter pixel here?
        {
          LCD_Out(0x00, 0);            //yes - draw it in black
          LCD_Out(0x00, 0);           
        }
        else
        {
          LCD_Out(0xFF, 0);            //no - draw background in white
          LCD_Out(0xFF, 0);
        }
      }
La parte clave es el desplazamiento hacia la izquierda de 7-j veces.

Por ejemplo, si se tiene un uno y se rota j=1...

0x01 << (7-1)

El resultado es

0x01 << 6 = 0x40

Pero CCS hace otra cosa que no entiendo. No puedo depurarlo porque estoy trabajando con un PIC24 y una LCD 3595.

Cosa rara, pero ya le encontré un workaround y aquí queda...

Código: [Seleccionar]

    for (k=0; k<5; k++) //Scan Columns
    {
    m=0x80;
      for (j=0; j<8; j++)
      {
        if (Hello_World[i][k] & (m>>j))    //Should there be a letter pixel here?
        {
          LCD_Out(0x00, 0);            //yes - draw it in black
          LCD_Out(0x00, 0);           
        }
        else
        {
          LCD_Out(0xFF, 0);            //no - draw background in white
          LCD_Out(0xFF, 0);
        }
      }
    }
El problema es que el pedazo de código que no funcionaba debía dibujar HELLO WORLD en la LCD Nokia pero en vez de eso dibujaba esto:

http://img169.imageshack.us/img169/6757/abcd0003z.jpg


Y con la corrección ya funciona bien:

http://img705.imageshack.us/img705/7476/abcd0004k.jpg


Datos del bug:
PIC24FJ64GB002
CCS 4.104

Por cierto, la LCD 3595 vino de una donación a la caridad de parte del Sr. Akenafab XD. Gracias ^^

[BrunoF]

Voy a advertir sobre algo que ya me ha cansado con CCS, y que me ha fallado, desde la version 4.088(incluso puede ser desde antes, no lo recuerdo) hasta la 4.104 que es la que uso ahora.

Intentar utilizar un puntero de una estructura para recorrer un array de dicha estructura resulta en DESASTRE. El problema es bastante evidente. El CCS muchas veces, no acomoda los elementos del array de la estructura consecutivamente en la RAM. Esto hace que obviamente luego, al querer recorrerlos con un puntero, el puntero se ubique en posiciones de memoria que no corresponden a ningun elemento del array, generando estragos en la ejecución del programa.
Considerense advertidos...

[BrunoF]

Hola Santiago. Seguramente sea un error del CCS.

Podrias hacer sino tambien,

Código: [Seleccionar]

      char j;
      char m=128;
     
      for (j=0; j<8; j++)
      {
        if (Hello_World[i][k] & m)    //Should there be a letter pixel here?
        {
          LCD_Out(0x00, 0);            //yes - draw it in black
          LCD_Out(0x00, 0);           
        }
        else
        {
          LCD_Out(0xFF, 0);            //no - draw background in white
          LCD_Out(0xFF, 0);
        }
        m/=2;
      }
Para eliminar por completo errores asociados a la funcion << y hacer el bucle un poquito mas rapido(aunque consumiendo un byte mas de RAM)...

Saludos.

[migsantiago]

Hola Bruno, es cierto que eliminaría el uso de <<, pero la división como tal introduciría más código rom... ¿? 

[BrunoF]

Hola Bruno, es cierto que eliminaría el uso de <<, pero la división como tal introduciría más código rom... ¿? 

No, para nada. El CCS lo traduce como una rotacion de 1 bit hacia la derecha(ya que recordemos que rotar 1 bit a la derecha es lo mismo que dividir el valor por dos). Es una optimizacion muy basica de los compiladores. Deberia solo generar 1 linea ASM en los PIC24(rotacion a la derecha sin carry, no se como sera en ese instruction set el nombre preciso)

[migsantiago]

OK, gracias.

[elperrov]

Gracias Pocher por este aporte, hace dias que estoy luchando con esto, y no podia simular la logica. Te mereces un premio.

Saludos.

Maxi.

Este hilo se abre para intentar que otros no pierdan el tiempo que nosotros perdimos por culpa de un mal funcionamiento del compilador de CCS.

Particularmente es el compilador que más uso y es uno de los más usados, por no decir el que más.

1^er PROBLEMA: mal funcionamiento de la interrupción por cambio de estado RB4..RB7

[BrunoF]

La solución que propone Potcher para la interrupción de cambio de estado en [RB4;RB7] no es del 100% correcta en mi opinión.

Deberíamos intentar no recurrir al ASM dentro del compilador, debido a que movf port_b,0 es una instrucción que depende de la página actual donde se encuentre actualmente trabajando el programa. Si por algún motivo el programa está en otra página, podemos leer en lugar del PORTB el TRISB u otro dependiendo del uC en cuestión, fracasando en ese caso en la intención original de refrescar el latch interno del PORTB asociado a dicha interrupción.

Podríamos entonces, antes de hacer el movf, forzar el código al banco 0, pero si bien sirve para efectuar correctamente el movf, entramos ahora con un potencial problema, debido a que le hemos cambiado el banco al CCS, quien seguramente no contemple ésto, y cuando continúe con su código compilado puede afectar a las variables incorrectas debido al cambio de banco no contemplado por él. Entonces, completamente seguro sería guardar el banco que está usando el CCS en una variable auxiliar, pasar al banco0, leer el puerto y restaurar el banco antes de devolverle el control al compilador...

Personalmente yo uso:
   input_b();

y el mirando el código ensamblado hace precisamente éso. Lee el PORTB.

Un saludo.

[chasmam]

hola a todos, he estado utlizando el compilador ccs 4.093 y 4.1 y veo que estos dos ultimos presentan problemas , he intentado probar el algoritmo ya implementado del la FFT y veo que presenta problemas en el calculo de los twid factors, debido a que utiliza las funciones seno y coseno para crearlos respectivamente.  si ha alguien le funciona perfectame este ejemplo hacerlo saber, gracias... el elemplo se llama EX_FFT, parece que a nadie le a funcionado :>(

[Mario]

Estoy trabajando con el PIC18F45K22 en la versión "actual" 


Se ha enviado un correo a los de CCS y se supone ya tomaron el caso, inclusive asignaron un número de identificación para el seguimiento.

El problema es con la nueva definición de estos k22 (1.8 hasta 5.5 de riel a riel) en sus registros. Para los k20 (3.3v) los registros no cambian.

Acá dejo lo que se envió (en el adjunto).


Ahora estoy teniendo problemas con el UART#1, ya que es posible enviar información pero cuando se pretende recibir, no prospera el asunto. Se publicarán los resultados pero quizá sea el domingo.

[facuenta]

Yo tuve un problema con la biblioteca flex_lcd.c. Estoy programando el nuevo PIC 16F1936 en CCS y cuando probé de usar el MPLAB SIM para medir los tiempos con el STIMULUS agregándole los dos canales ADC... en la simulación se me quedaba en la biblioteca flex_lcd.c como si hubiera un lazo infinito... la cuestión que me dijeron que el MPLAB SIM toma al LCD como si estuviera apagado entonces esa biblioteca(flex_lcd.c) tiene un bug ahí??? Alguien sabe como solucionar eso?


Me estoy volviendo loco para medir los tiempos que necesito calcular para agregarle a mi programa un reloj... y el "PIC SIMULATOR IDE" todavía no cuenta con este microcontrolador y la opción que me quedaba hasta donde se es el MPLAB SIM ya que los del CCS y del PROTEUS no son de tiempo exactos ya que dependen del reloj de la máquina.

Si hay algún experto que me lo pueda responder se lo voy a agradecer.

Saludos,
Facundo

[richardjr]

Hola! ya postee mi duda por fuera de este hilo, pero quisiera pedir ayuda aca tambien, no repito el post, simplemente dejo el link de mi consulta, he estado pensando que podria ser un bug del CCS tambien... ustedes diran!

Consulta sobre PPS e intercambio de puertos para UART

Gracias!!

[PalitroqueZ]

en la simulación se me quedaba en la biblioteca flex_lcd.c como si hubiera un lazo infinito... la cuestión que me dijeron que el MPLAB SIM toma al LCD como si estuviera apagado entonces esa biblioteca(flex_lcd.c) tiene un bug ahí??? Alguien sabe como solucionar eso?

¿y lo has probado en físico?

recuerda que la lcd debe responder al pic, y si no le das esa respuesta manalmente por mplab-sim, siempre se quedará esperando

[facuenta]

Muchas gracias PalitroqueZ!
Voy a probar a ver si es eso.
Saludos,
Facundo