TODOPIC
Microcontroladores PIC => Lenguaje Basic para microcontroladores PIC => Mensaje iniciado por: literatronic en 17 de Octubre de 2007, 16:06:30
-
Siempre he tenido esta duda y nunca me había dado por buscar, ahora necesito saberlo para calcular unos tiempos y busque en la red y ninguna de las respuestas que encontré me satisfizó . Si alguien sabe y me puede aclarar esta duda lo agradecería mucho :)
-
No existe una regla, puesto que hay instrucciones más complejas y otras más simples.
Por ejemplo: un goto se compila con una sóla instrucción, sin embargo, una operación matemática como la multiplicación puede ser una simpleza en basic y ocupar bastante en assembler.
Lo mejor, si tienes la inquietud de averiguarlo, es que compiles tu programa y mires el resultado de la compilación.
-
Hola:
No se si te sirva, pero puedes también revisar el archivo .ASM que se crea con cada una de las compilaciones y compararlo, no se nada de ASM así que míralo tu y ve si es correcto el archivo generado trás la compilación.
-
Ya que estamos con Basic, los compiladores de Basic son runtime, generan P-code o directamente traducen a ASM ?
Gracias desde ya !
Salu2!
-
Hola!
Hasta donde se, todos traducen a ASM.
Saludos!
-
Yo ya había mirado el .ASM que se genera al compilar un programa en Pic Basic Pro y no entendí muchas de las líneas, no se si este archivo si me da el número correcto de líneas, será que sí?
Otra duda que me surgió después de leer cosas en la red es si cada instrucción en Assembler se gasta un ciclo de reloj exactamente?
-
Hola!
Hasta donde se, todos traducen a ASM.
Saludos!
Gracias x el dato 8)
jejeje y de paso cañazo llege a los 50 mensajes y me pasaron a categoria "Participante" :D
-
Entender el asm generado por PBP es una loteria!!
Entre los @ que le mete, los nombres que le asigna a las variables y la cantidad de codigo que genera (usa macros) y el extenso codigo, me quedo con el asm que genera el lenguaje C, al menos es asm puro, je..je :D :D
-
Toda una odisea.....
Si quieres saber cúanto código se generó están las dos formas (las más complicadas también):
1.- Compila. Importa tu .hex al mplab. Revisa en VIEW-->program file. Ahí el puro ensamblador puro.
2.- El PBP tiene un archivo que se llama PBPPIC14.MAC, el cual contiene todos los macros que de los que se hacen uso en la compilación. Revisa cada macro en el archivo .ASM que se genera al compilar y entonces, solo entonces, sabrás cuánto código se genera...... si puedes hacer eso me avisas porque aún no he podido "descifrar" todos (de hecho nunca lo he intentado, opto por la primera opción).
Espero te sirva.
-
Yo ya había mirado el .ASM que se genera al compilar un programa en Pic Basic Pro y no entendí muchas de las líneas, no se si este archivo si me da el número correcto de líneas, será que sí?
Otra duda que me surgió después de leer cosas en la red es si cada instrucción en Assembler se gasta un ciclo de reloj exactamente?
Hola:
Bueno, si quieres generar retardos exactos como lo mencionaste en tu primer post, también puedes introducir código ASM en el PBP, puedes hacerlo usando:
ASM
-
-
-
-
-
ENDASM
de esa forma generaas los retardos que quieras de forma más precisa.
-
La mayoria de las instrucciones Assembles se ejecutan en Frecueciacristal/4, menos las de salto que se ejecutan Frecuenciacristal/8.
Una forma muy simple y bastante exacta es utilizar un timer para calcular el tiempo que tarda tu rutina en cuestión.
Cuando entras en la rutina pones el contador del timer a cero y lo activas, y cuando terminas la rutina lo paras, solo tienes que leer el
registro del timer y calcular el tiempo teniendo en cuenta que se incrementa cada 4 ciclos del F. cristal, (frecuenciacristal/4), siempre y cuando
no se le programen prescales o posescales.
Aqui hay un ejemplo:
'********************************** PIC Entrenadora BASIC ***************************************
'NOMBRE: 16F88_Pic_EBasic_LCD_Timer1_MidiendoTiempo_10
http://www.todopic.com.ar/foros/index.php?topic=14917.180
-
Si lo que necesitas es tener retardos exactos, dentro del PBP, creo que lo mejor es utilizar la interrupcion de un timer y generarlos desde alli, ya que un delay de PBP puede ser muy justo o muy malo cumpliendo su tiempo, ya que se insertan tiempos que el PBP no controla en el medio.
La interrupcion es lo mejor, incluso el codigo de la misma deberia ser hecho en assembler, para hacer una interrupcion corta y salir rapidamente... :mrgreen:
-
Amigo dogflu66 ya ví tu programa para medir el tiempo que tarda una rutina cualquiera en ejecutarse y me pareció muy interesante, voy a ver si lo implemento en PBP. Lo que yo necesito saber ahora es cuanto me demoro en enviar un sólo Byte de la trama y la trama completa por serial con la instrucción:
SEROUT2 TX,84,[DATO1,DATO2,DATO3,DATO4]
y cuanto tiempo hay entre el envio de cada uno de los Bytes que conforman la trama.
Yo estoy trabajando con un cristal de 4MHz y por lo que he visto en el .ASM que se me genera al compilar, esta instrucción se "traduce" en cuatro líneas de assembler para el envio del primer Byte y de a una después para los otros, entonces yo supongo que son 4us para el primero y de ahí en adelante sumarle 1us, si estoy equivocado me corriges por favor.
Muchas gracias.
-
Como bien dices en 1uSeg se ejecuta 1 instruccion en lenguaje assembler.
Con el programita del Timer tambien puedes saber el tiempo que se tarda en enviar un byte por el puerto serie.
Y para saber el retraso entre byte y byte de la siguiente forma:
Reg. timer = 0
timer = on
serout ....... byte
serout ....... byte
timer = off
calculo tiempo
fin.
Y como ya sabemos cuanto tarda un byte podemos saber perfectamente la demora entre bytes.
-
Como dijo Mario, esa lectura del archivo PBPPIC14.MAC es un lio, ya que no aparecen todos los macros que se utilizan en el archivo .ASM que se me genera al compilar, pero agradezco el dato Mario ya que ví muchos macros que si aparecen.
Voy a trabajar con el Timer como me propuso dogflu66 a ver si puedo medir los tiempos entre Bytes, muchas gracias.
-
Me tope con una guía de Pic Simulator IDE, programa que tenía desde hacía tiempo pero que nunca había utilizado, y me dí cuenta de que tiene una herramienta para pasar el .HEX a Assembler puro (Disassembler se llama la función) y que mide automaticamente los tiempos entre cada una de las instrucciones al ponerlo a correr, además de traer otras herramientas muy buenas; lo probe con mi programa y me dice que para la instrucción SEROUT2 tarda 1ms. Alguien sabe si esta bien este tiempo?
-
Esto me tarda segun el Pic Simulator IDE 1119uSeg.
Define SEROUT_DELAYUS = 0 'Elimina el tiempo de espera entre bytes
Serout GPIO.4, 9600, "G"
End 'Aqui pongo el BreakPoin
Puedes utilizar la herramienta "BreakPoints Manager" siempre y cuando sepas donde marcar el punto de parada (breakpoin).