/* Get High byte of the an word */
#define HI( Data ) \
(( byte ) (((( word ) Data ) >> 8 ) & 0xFF )) \
/* Get Low byte of an word */
#define LO( Data ) \
(( byte ) ((( word )( Data )) & 0xFF )) \
En mi caso estas macros las tengo implementadas en un modulo que exporto de proyecto en proyecto y asi no dependo tanto de las funciones que me brinde el compilador.Pero no es solamente el goto o el call; también te evitas que guarde contexto en el stack.
Os recomiendo reviséis el ASM porque, sobre todo en micros pequeñitos, podemos ganar bastante haciendo ligeros cambios en nuestros programas.
Aqui hay algo que no me cuadra, la primera instruccion que pones es variable > 0x0A00 , si variable es igual a 0X0A01 se cumplira la condicion, en tu ultima "optimizacion" comparas la parte alta de variable con 0x0A y si variable vale 0x0A01 no se no entra el if , entonces lo primero y lo ultimo no es lo mismo.
...Habría otra forma de inicializar ese bucle de forma más rápida aún, si no me equivoco: mediante punteros.
Obtenemos el puntero al primer elemento del array y hacemos un bucle que lo vaya incrementando hasta el 4096 (32x128), ya que los elementos del array estarán situados de manera contigua en la RAM.
no entiendo porque puntero es long ¿? Gonzalo el tamaño del puntero es independiente del tipo de datos que manejes.
for(A=0;A<= Espacio;A++){for(A=0;A<Espacio;A++){
Gonzalo:
Ante todo, cualquier ejemplo es válido siempre que cumpla su cometido, como en ccs no se puede manejar punteros a nivel de bits (al menos no se como y no he averiguado), entonces una forma corta que ví, fué trabajando por bytes. Una Matriz[32][128] -> 32x128=4096bits / 8bits = 512Bytes contiguos. Es mas rapido trabajar con int8 que con int16 (*)
*Con un pic con registros de 16bits, otro gallo cantaría
Es mas rapido trabajar con int8 que con int16 (*)
Es mas rapido trabajar con int8 que con int16 (*)
...y mas ha alguien con tu reputación Pedro y no quedar en verguenza me he tomado el trabajo de comprobar que mi comentario realmente es válido.
.................... delay_cycles(1);
003A: NOP
.................... a=input_state(PIN_B0);
003B: CLRF 3B
003C: BTFSC 06.0
003D: INCF 3B,F
.................... delay_cycles(1);
003E: NOP
.................... a=input(PIN_B0);
003F: BSF 03.5
0040: BSF 06.0
0041: BCF 03.5
0042: CLRF 3B
0043: BTFSC 06.0
0044: INCF 3B,F
.................... delay_cycles(1);
0045: NOP
Estaba optimizando un programa en CCS para que quepa en un PIC 16F727 porque ya anda a tope, y para mi sorpresa, un array de bytes ocupa menos si lo dimensiono a 16 que si lo dimensiono a 12.
(http://img248.imageshack.us/img248/7995/compilandoconarray16y12.jpg)
No sé de qué va eso del stack, ¿cómo puedo optimizar mi código para que utilice un nivel menos?, ¿qué tipo de funciones lo llenan?
No sé de qué va eso del stack, ¿cómo puedo optimizar mi código para que utilice un nivel menos?, ¿qué tipo de funciones lo llenan?
Es decir que es mejor usar funciones que retornen datos (asi no los retornen) para asegurar la descarga del STACK?
Magnífico Don Bruno, lo tendré en cuenta.
Me parece que mi programa no llega ni a 4 niveles de pila, por lo que imagino que CCS ha supuesto un caso que no podrá darse.
En cualquier caso lo revisaré.
Gracias
:z) Así me dejaste y me corrió un chucho por la espalda! :D :D
:z) Así me dejaste y me corrió un chucho por la espalda! :D :D
Es que los enfermos del ASM tenéis unas costumbres muy raras: ¡Una pila para recordar el camino de vuelta!, con lo fácil que es tirar de GPS, hombre.
Magnífica herramienta de depuración. Siempre he visto el botón del Call tree y nunca me había dado por pulsarlo.
He encontrado hasta 7 niveles de profundidad, porque la librería del LCD hace muchas llamadas, así que no me extraña que en alguna parte se consuman los 9 niveles que indica la compilación, aunque aún no lo encuentro.
Sigo buscando.
Jejeje! En los 16F preocúpate de forma sería que tienen 8 niveles, en los 18F es de 32, y en los PIC24 es por software :PEl 18f4550 tiene solo 24 niveles, pero ya es mucho más que un 16.