Cursillo en C18 para PICS DESDE CERO

[PalitroqueZ]

eh, micro con tanto componente se va poner lento el proteus 

[micro_cadaver]

si amigo, se pone lag pero depende del cristal del pic y de la cantidad de componentes, aunque te comento que en una Pentium4 a 1.8GHz memoria ram 512M, pues se llega a ver ok y no se cuelga para nada. pero si se pone a 100% aunque estaba con varios programas activos y escuchando a los Beatles 

[micro_cadaver]

Bueno ya hemos hablado mucho sobre el PIC18F2525, y tambien sobre DS1307, toca hablar del 4094.

El integrado CD4094
Si revisamos su respectivo datasheet, observaremos que es un registro de desplazamiento serial de un solo sentido (se desplaza comenzando por el bit de menor peso) de 8 bits, con la particularidad de que posee un 3 estado (hi-z o alta impedancia) , y un latch que le permite cargar valores sin modificar la salida actual, gracias a la entrada STROBE.

En resumen, estamos usando el clock, el data y el strobe para controlar estos chips. Luego los estamos concatenando uno tras otro con su pin Q, que es el ultimo bit del latch de cada registro, y lo estamos mandando al data del siguiente chip.


Los 2 Paneles de Leds
Cada panel esta formado por 7 filas x 32 columnas, donde cada CD4094 se encarga de 8 columnas del panel. Las filas son disparadas directamente desde los pines del puerto B. Obviamente hay una gran diferencia entre la realidad y el simulador en lo que respecta a implementar un panel de leds, asi que no vayan a armarlo asi como esta en el simulador  se debe tener en cuenta cosas como la potencia de los leds, su consumo, arreglos para la corriente d elos paneles, etc.

[Duende_Azul]

Tengo la siguiente duda:

Quiero hacer un retardo de 1seg;  dispongo de un cristal de 10MHz y según los ejemplos del manual del C18 el cálculo seria así:

cycles = (delay_time * Fosc)/4

y ese valor es el que se coloca en una de las instrucciones delayXTCYx(cycles)...

en uno de los ejemplos ponen que para obtener 5ms de retardo con un cristal de 16MHz, el número de cycles es:

cycles = (5ms * 16MHz)/4 ; multiplicando ms * MHz    queda:
cycles = (5*E-3 * 16E+6)/4 = 20.000

y la instrucción quedaria:  Delay1KTCYx(20);   y eso es un retardo de 5ms

Ahora, siguiendo este procedimiento tengo que para 1 seg con un cristal de 10MHz sería:

cycles = (1000ms * 10MHz)/4
cycles = (1000E-3 * 10E+6)/4
cycles = 2.500.000

la instrucción sería:  Delay10KTCYx(250);    //es decir 250*10.000 = 2.500.000  => 1seg

EL asunto es que cuando simulo esto en proteus el tiempo es de 1.33 seg  y no 1 seg.

Si hago en CSS  delay_ms(1000)  la simulación me da 1 seg clavado.

La pregunta es: ¿estoy haciendo algo mal?

Código: [Seleccionar]

// Cristal 10MHz
#include <p18f452.h>
#include <stdio.h>
#include <delays.h>

#pragma config OSC=HS
#pragma config WDT = OFF
#pragma config PWRT = ON
#pragma config BOR = OFF
#pragma config LVP=OFF

int i;

void main(){
TRISB =0;    //Puerto b como salidas
PORTB =0;
while (1){
Delay10KTCYx(250); //Retardo de 1 seg; con 189 si da 1 seg
    PORTB = !PORTB;  //Cambia estado del puerto
}
}


[micro_cadaver]

hola he probado tu codigo en el MPLABSIM y si da 1seg clavadito segun el grafico,


ahora en el proteus pues ... tambien veo 1.33seg.

Hay cosas que suceden en el proteus que no entiendo tampoco, debe ser algun problemilla bug con el compilador, aunque en la realidad si se cumplen los tiempos, asi como en el MPLABSIM.

Saludos.

[PalitroqueZ]

offtopic:

...
ahora en el proteus pues ... tambien veo 1.33seg.

Hay cosas que suceden en el proteus que no entiendo tampoco, debe ser algun problemilla bug con el compilador, aunque en la realidad si se cumplen los tiempos, asi como en el MPLABSIM.
...

ese detalle lo había oido antes, los tiempos, ahora pregunto: ¿restaste el tiempo anterior? y debe ser al ejecutar la siguiente línea, es decir, pones 2 breakpoints y al detenerte en el primero anotas el tiempo transcurrido. Luego te paras en el segundo break y ese tiempo le restas el anterior.

no olvidarse de poner la frec. del cpu del micro

[Duende_Azul]

He hecho unas pruebitas para no quedarme con la duda.

Compile el ejemplo de los 5ms en C18, lo simule en proteus y lo medi en un osciloscopio, luego hice lo mismo pero con CCS y los resultados que obtuve fueron estos:

Programa con 5ms de retardo:

C18:
Proteus:    7.96ms
Osciloscopio:  8ms   

CCS:
Proteus:  5ms
Osciloscopio: 5ms


Conclusión:  EL compilador perfecto no existe 

[micro_cadaver]

vaya de 5 a 8ms gran diferencia....
podrias subir tu codigo para mirar y ver esa falla del compilador? a eso llamo un bug. 

[Kedutpic]

He hecho unas pruebitas para no quedarme con la duda.

Compile el ejemplo de los 5ms en C18, lo simule en proteus y lo medi en un osciloscopio, luego hice lo mismo pero con CCS y los resultados que obtuve fueron estos:

Programa con 5ms de retardo:

C18:
Proteus:    7.96ms
Osciloscopio:  8ms   

CCS:
Proteus:  5ms
Osciloscopio: 5ms


Conclusión:  EL compilador perfecto no existe 

bueno no hay que llegar a conclusiones aun , como henry dijo seria interesante que subas tu codigo para poder revisarlo con mayor detenimiento, y asi poder llegar a una solucion ,pero a mi me parece mucha la diferencia de 5ms a 8ms  .

Bueno yo tambien voy a realizar las pruebas , para verificar lo que tu estas afirmando .... asi que me pongo manos a la obra

PD : HENRY  ya tienes tarea que hacer

[micro_cadaver]

debido a mi bendita curiosidad quise verificar primero lo del proteus con 5ms, pues hice esto:
el codigo para xtal=10MHz:

no hacer caso a los comentarios, pues habia modificado el codigo anterior del ejercicio de la primera pagina de este hilo.

el proteus:


y los resultados:


Solo me quedaria ver en el osciloscopio, pero recien podre verlo el lunes, amigo DuendeAzul.

[micro_cadaver]

un detalle mas, revisa tu codigo usando LATx.

[Duende_Azul]

Revisando y revisando me he dado cuenta de que meti la pata hasta el fondo con lo que puse anteriormente  , en Proteus no habia cambiado la frecuencia a 16MHz, la deje en 10MHz y por eso la diferencia de 3ms. segui probando y al parecer la rutina Delay10KTCYx(cycles) es la que no da los valores correctos; 1000mSeg dan 1330mSeg, 300mSeg me dan 399mSeg, 252mSeg me dan 335mSeg.  Solo faltaria comprobar esto en un osciloscopio pero esa frecuencia tan baja no se ve bien en el que tengo.

[micro_cadaver]

Ah claro que si, debeis verificar antes de postear pero bueno gracias por tu auto-aclaracion, dejame decirte que yo me guio fielmente por los valores que bota el mplabSIM ahora, hay que tomar en cuenta los retardos en caso de usar LATx y PORTx,  y asi pes, pero bueno, ya todo esta resuelto para bien.

Otra cosa, es cierto que no hay compilador perfecto, nadie ha dicho que lo sea el C18, simplemente que como el C18 no es muy usado por la gente del foro " aun " no han aparecido dichos bugs (porque de que hay los hay), y siempre habrán caminos alternativos para evitar dichos bugs, en resumen, A SEGUIR DANDOLE AL C18!

[micro_cadaver]

La Matriz de Leds 7x64

Esta matriz de leds constituye el mejor looking para muchos proyectos que podamos tener en mente, lo malo es su coste de implementación, pues el precio oscila según la calidad de led que se use, además del driver o circuiteria de potencia que en esta versión simulada no estará presente, pues en el proteus no es necesario  .

Existen muchos fundamentos que ignoro en relación al tiempo óptimo de encendido y apagado del panel, aunque ya se ha hablado mucho sobre esto en varios hilos dentro del foro TODOPIC, es cuestión del interesado en recopilar dicha información, nuestro objetivo es simplemente desarrollar una aplicación para practicar el compilador C18.

Análisis in profundix:
Imaginen 7 registros constituidos por 8 bytes cada uno, si lo graficamos sería algo asi:

     1                 2                 3                4                5                 6                7                8   
00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000    Reg1
00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000    Reg2
00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000    Reg3
00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000    Reg4
00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000    Reg5
00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000    Reg6
00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000    Reg7

Ahora, esto mismo para el C18:

Código: C

1. unsigned char panel[7][8] = { 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,
2.                               0X4E,0XAE,0XEE,0X00,0X00,0X00,0X00,0X00,
3.                               0XC2,0XA2,0X8A,0X44,0X00,0X00,0X00,0X00,
4.                               0X4E,0XEE,0XEE,0X00,0X00,0X00,0X00,0X00,
5.                               0X48,0X22,0X22,0X44,0X00,0X00,0X00,0X00,
6.                               0X4E,0X2E,0XE2,0X00,0X00,0X00,0X00,0X00,
7.                               0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00};

Observemos que se trata nada más que de una simple matriz 7x8  , ahora, con un simple indexado dentro de la matriz podriamos escribir dentro de ella:

panel[2][1] = 0x00;

Y así dibujar en la matriz algún caracter o figura que deseemos mostrar en el panel de leds, esa es la manera en que vamos a atacar la matriz con el programa escrito para el C18, no obstante debido a que se trata de 2 paneles simplemente lo he partido en 2:

Código: C

1. unsigned char panel[7][4] = { 0X00,0X00,0X00,0X00,
2.                               0X4E,0XAE,0XEE,0X00,
3.                               0XC2,0XA2,0X8A,0X44,
4.                               0X4E,0XEE,0XEE,0X00,
5.                               0X48,0X22,0X22,0X44,
6.                               0X4E,0X2E,0XE2,0X00,
7.                               0X00,0X00,0X00,0X00};
8.  
9. unsigned char mensaje[7][4] = { 0X00,0X00,0X00,0X00,
10.                               0X4E,0XAE,0XEE,0X00,
11.                               0XC2,0XA2,0X8A,0X44,
12.                               0X4E,0XEE,0XEE,0X00,
13.                               0X48,0X22,0X22,0X44,
14.                               0X4E,0X2E,0XE2,0X00,
15.                               0X00,0X00,0X00,0X00};

Ahora, debido al hardware que hemos implementado la forma de dibujar en el panel es la siguiente:

• 1. Apuntar al primer registro correspondiendte a la primera fila del panel.
• 2. Desplazar serialmente através de los 4094 este primer registro, esta rutina desplazará 8 bytes consecutivamente.
• 3. Activar fila correspondiente y clockear el STROBE dek 4094 para actualizar.
• 4. Aplicar retardo para la aparición de cada fila.
• 5. Continuar asi hasta llegar a la ultima fila, luego repetir todo el proceso.

[micro_cadaver]

Entonces siguiendo este razonamiento sucedería lo siguiente al momento de escribir en el panel, digamos que tengo el siguiente mensaje dibujado:


Ahora veamos como lo está haciendo el programa pero en camara lenta....
Para la fila 1:

Para la fila 2:

Para la fila 3:

Para la fila 4:

Para la fila 5:

Para la fila 6:

Para la fila 7:


Donde cada fila tiene un retardo que puede ser digamos de 10mseg (estos tiempos no se definirlos bien, solo lo hago por prueba y fallo) luego tendriamos que el tiempo para escribir todo el panel sería de 70mseg + algunos useg de las instrucciones del pic, finalmente volver a hacer todo el bucle infinitamente.

Asi se consigue el efecto de un panel de leds, dibujando por las columnas y habilitando por las filas.