Hacer una división con ASM del PIC 16F84A

[Meta]

Hola:

Me imagino que hacer una división en ASM para el pic 16F84A es un poco engorroso ya que hay que hasta guardar el resto en una variable, y el resultado en otra.

15 / 3 = 5 (Resto es igual a 0).

¿Alguien sabe hacer o poner un ejemplo en ASM sobre una división con comas?

Ejemplo:

0.15 / 3 = 0.05

¿A qué ya es otra realidad?

Un cordial saludos.

 

[CUSCO]

yo hace un par de meses hice una calculadora cientifica con un lcd
y un teclado matricial pero con el c18 y creanme que lo mas dificil de
toda la calculadora fue programar la interfaz para que el usuario digite lo numeros
y se le entregue los resultados y todo lo demas.

si no es necesario hacerlo en ensamblador yo lo haria en c.
por que operaciones matematicas con enteros y aun en ensamblador
son manejables incluso con numeros de 16 bits, pero en punto flotante
es complicado pero seria una buena experiencia para aquel que lo haga
ya que aprenderia mucho hasta pronto y suerte.

 

[Chico3001]

Hola:

Me imagino que hacer una división en ASM para el pic 16F84A es un poco engorroso ya que hay que hasta guardar el resto en una variable, y el resultado en otra.

15 / 3 = 5 (Resto es igual a 0).

¿Alguien sabe hacer o poner un ejemplo en ASM sobre una división con comas?

Ejemplo:

0.15 / 3 = 0.05

¿A qué ya es otra realidad?

Un cordial saludos.

En micros de 8 bits no me meto en broncas.. multiplico todo por 10, 100 o 1000 para eliminar las decimales y aplico una division estandar, posteriormente si lo muestro en un display solo enciendo el punto decimal adecuado... de otra manera tienes que meter calculos de punto flotante y es un broncon... especialmente con un pic

para divisiones de 16 y 32 bits en el pic, Microchip tiene por alli una nota de aplicacion de formulas matematicas en ensamblador.. solo busca la division de 32/32 (con o sin signo), pegala y listo.. toma en cuenta que va a tardar muuuucho tiempo.. segun recuerdo cuando la implemente tardaba algo asi como 1mS en realizarse....


AN526 Utility Math Routines
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011000

 

[Meta]

si no es necesario hacerlo en ensamblador yo lo haria en c.

Ya decía yo con qué tranquilidad has dicho que lo has hecho. Se que no es necesario hacerlo con ASM, pero lo digo para aprender. Cuanto más aprenda manejar estas cosas, mejor que mejor y irás suelto en el futuro con asm que muchas veces lo pide por todas partes.

Bueno, veo que muy fácil no es.

Chico3001, gracias por el links.

Los demás pueden seguir opinando.

 

[Javier Rambaldo]

En las Application Notes de Microchip encontrarás muchas rutinas en assembler para manejo matemático en punto flotante.
Chico3001 te dio una, pero hay muchas mas...

Ahora yo opino como Chico3001, multiplica x100 o x1000, dependiendo de la precisión que desees y aparte de ser mas fácil, las rutinas son mucho mas rápidas que el punto flotante.

El punto flotante usalo donde necesites hacer -por ejemplo- funciones trigonométricas. Aunque para esto también se pueden usar enteros.

 

[Toño]

Hola amigos, aprovecho este hilo para hacer una pregunta sobre ASM en el pic16f84a;
lo que pasa es que cuando quiero llamar a una subrutina mediante una libreria de subrutinas y me mandan dos errores cuando lo ejecuto, los errores son los siguientes:

Error[113] D:\PIC16F84\SUBRUTINAS_02.ASM 23 : Symbol not previously defined (BIN_a_BCD)
Error[105] D:\PIC16F84\SUBRUTINAS_02.ASM 27 : Cannot open file (Include File "BIN_BCD.INC" not found)

me podrian decir cual es mi posible error

de antemano gracias

 

[Chico3001]

el compilador no encuentra el archivo llamado BIN_BCD.INC, lo mas seguro es que el directorio donde lo tienes no este declarado en los directorios de busqueda de compilacion o incluso no exista el archivo...

Intenta añadiendo el archivo a la carpeta de proyecto o dentro de la carpeta includes del mplab (creo que asi se llama) para que lo compile

El primer error me imagino que esta ligado al segundo.. estoy suponiendo que tienes una funcion BIN_a_BCD dentro del archivo BINC_BCD.INC

 

[Toño]

gracias chico3001...el problema era que yo creaba una subcarpeta dentro de la carpeta de trabajo, solo elimine esa carpeta y ya funciona...

 

[Meta]

Mejor dicho, pon la subrutina dentro del mismo archivo.

 

[asherar]

Hola. Esta es para los PIC-istas "Assembleros".

Les acerco una consulta por un tema de programación que me trae mal.
Hace un tiempo tuve que trabajar excediendo los 2k de la memoria del 16F873/6/6A.
Entonces creí que había superado el problema con el uso de "pagesel". Pero ahora he
vuelto a tener el mismo problema, y no le encuentro la vuelta.

Por un lado usando el MPLAB al ir debuggeando pasa por lugares de algunos archivos
"inc" donde no hay instrucciones (!) o por donde sólo hay comentarios (!).
Es como que el "debugger" se perdiera.
¿ Puede ser problema de la memoria caché de windows ? (XP)

Pero lo peor es que cada tanto los "return" me mandan el PCL al vector de reset.
El debugger desgraciado me pierde la página de memoria de programa.
Y eso no es el debugger, porque al programar el micro también se "cuelga".

A sugerencia de un amigo estoy pasando todo a C, que arregla eso de taquito (?), pero es
un bajón. Son "kilometros" de código en ASM que, salvo por eso, probando cada parte por
separado andaba lo más bien.
Y por desgracia no puedo reducir el tamaño del programa. He tratado de convertir lo más
posible "macros" a "rutina", pero por ejemplo los "banksel" son muchos e inevitables.
Cuando pongo todo junto llego casi hasta 3k y pico. Eso sin cargar los bitmaps para el
display gráfico.

La pregunta es si alguien conoce alguna forma de resolver ese tema.

La idea que pienso poner a prueba ahora es separar el código en "grueso" de modo que
cuando ejecute una parte se limite a la región 0-2k y en otro tramo se limite a la región
2k-4k, por ejemplo. Eso reduciría las instrucciones que cruzan la frontera entre bloques de 2k.
El problema que veo con eso son las interrupciones, que ocurren con el PCL en cualquier lado
y saltan al vector 0x04.

Antes de ponerme a modificar todos los códigos de vuelta, cosa que
seguro me llevará horas: ¿ les parece que resulte ?

Un saludo !

 

[Chico3001]

Por eso odio el PIC... la paginacion en esos micros es la muerte, y fue la razon por la cual deje de usarlos y me cambie a los Atmel, Freescale y Texas....

Intenta revisar si estas colocando bien la direccion en el registro PCLATH, segun recuerdo una parte va en PC y la otra en PCLATH

Los return no creo que sean el problema por que todos los bits de PC son empujados al stack al hacer llamados de interrupciones o de subrutinas...

La idea que dices de dividir el programa en 2 partes es correcta y recuerdo que tambien termine haciendola... pero sinceramente para programas largos mejor usa un ATMEL.. y esos tienen la ventaja de poderse programar bien en C

Saludos...

 

[asherar]

Gracias Chico3001 ...

Ese martillito rojo de tu avatar me está dando una idea !

 

[Meta]

sinceramente para programas largos mejor usa un ATMEL.. y esos tienen la ventaja de poderse programar bien en C

Saludos...

¿Desde cuándo?

Otra cosa, ¿alguien ha completado la memoria de 1k completa del 16F84A de su propio código que ha hecho uno mismo en ASM?

 

[Chico3001]

Desde cuando los programo? tengo 2 años usandolos...

 

[Meta]

Desde cuando los programo? tengo 2 años usandolos...

Se serio. Si fueran tan buenos y fácil como dices, los AVR de Atmel arrasaría a los PIC de Microchip en un plis plas, incluido documentación por todas partes.

Tus palabras dicen una cosa, los hecho dicen otra. ¿Qué creer, las mil cosas que nos dicen o una cosa que se muestra?

Saludos.

 

[asherar]

Che, esa discusión tiene ya un foro abierto y todavía no se han puesto de acuerdo.

Yo aporto al tema original algo que estuve mascullando en estos días.
La división mediante operaciones elementales en assembler.
Parte de algo elemental pero apunta al problema planteado.

Sirvanse comentar plis!

 

[eidtech]

sinceramente para programas largos mejor usa un ATMEL.. y esos tienen la ventaja de poderse programar bien en C

Saludos...

¿Desde cuándo?

Como se ve que no te tocado batallar con los "infernal banks" de PIC... perdon "internal banks"

 

[Meta]

Lo voy a analizar de arriba abajo y deja ver si lo saco en un ejemplo real para el 16F84A al menos yo, otros que lo hagan en ASM con AVR om uC que sea.

Muchas gracias.


...

 

[Chico3001]

Desde cuando los programo? tengo 2 años usandolos...

Se serio. Si fueran tan buenos y fácil como dices, los AVR de Atmel arrasaría a los PIC de Microchip en un plis plas, incluido documentación por todas partes.

Tus palabras dicen una cosa, los hecho dicen otra. ¿Qué creer, las mil cosas que nos dicen o una cosa que se muestra?

Saludos.

Haber... yo nunca he dicho que los AVR vendan mas que los Microchip... pero una cosa es cierta.. los Microchip se venden mas por el excelente trabajo que hace Microchip en las escuelas, va a todas las escuelas y regala kits de demostracion, entrena profesores, baja sus precios para estudiantes, etc etc etc..., que es lo que sucede? que cuando el alumno sale de la escuela lo que quiere usar es Microchip por que es lo que conocio toda su carrera de estudiante, pero NO POR QUE SEA LO MEJOR..... definitivamente Microchip tiene problemas y graves en sus micros... su emulacion es muy deficiente, la paginacion te afecta mucho en los programas largos, los micros consumen demasiada energia y dividen internamente los relojes, son lentos para arrancar y salir del sleep, etc etc...

El cambio de mercados en los micros se esta dando y de manera muy fuerte con Atmel y Texas, solo que no es un cambio que se pueda lograr de la noche a la mañana, este cambio va a tardar unos 10 años y tal vez nosotros solo veamos el final. Pero por el momento si es definitivo que Microchip es el #1 en micros de 8 bits.. y eso aun esta debatido por que si incluyes en las estadisticas los mercados de micros automotrices de 8 bits los claros ganadores son Renesas y Freescale

 

[Meta]

sinceramente para programas largos mejor usa un ATMEL.. y esos tienen la ventaja de poderse programar bien en C

Saludos...

¿Desde cuándo?

Como se ve que no te tocado batallar con los "infernal banks" de PIC... perdon "internal banks"

Digamos que hay que saber aceptar lo que a uno le estreza. Todo es cuestión de prácticas y acostumbrarse al ambiente que le rodea. Aún así, con el tiempo aprenderé el C para PIC, si lo domino ya entraré a los AVR por curiosidad.