Retardo básico en un PIC

Hola muy buen dia a todos, estoy aqui de nuevo por una duda muy básica: quiero hacer un retardo en un pic 16f84 o 16f877a el cual al encenderlo espere durante 5 segundos en alto y a continuación me envie un bajo permanente asta que se le quite la alimentación esto es con motivo de hacer un sumobot para una competencia, y les prometo que envio los detalles de como quedó por completo el proyecto para que todos lo puedan ver y lo prueben si gustan gracias a todos por su ayuda de antemano.
 
Aqui te va una rutina de 5 segundos

Código:
; Delay = 5 seconds
; Clock frequency = 4 MHz

; Actual delay = 5 seconds = 5000000 cycles
; Error = 0 %

	cblock
	d1
	d2
	d3
	endc

Delay
			;4999993 cycles
	movlw	0x2C
	movwf	d1
	movlw	0xE7
	movwf	d2
	movlw	0x0B
	movwf	d3
Delay_0
	decfsz	d1, f
	goto	$+2
	decfsz	d2, f
	goto	$+2
	decfsz	d3, f
	goto	Delay_0

			;3 cycles
	goto	$+1
	nop

			;4 cycles (including call)
	return

o el link http://www.golovchenko.org/cgi-bin/delay
 
muchas gracias a los dos seguro que me servirá que esten bien, ha una cosa mas, estuve investigando y me encontre conla directiva INCLUDE<RETARDOS.INC> que tan de confianza podrá ser? se supone que ahi vienen retardos predeterminados listos para usar
 
Si yo pongo el include Retardos.INC, que mas debo hacer para tener el de 10uSg de retardo? no he tenio oportunidad de estudiar mucho los includes.
 
abre la libreria usando mplab y mira el nombre de los retardos y usa call para llamarlos:
por ejemplo

call Retardo_10ms ;llama al retardo de 10 mili segundos
 
Alguna formula para aprender a hacer el retardo usando tecnologia de papel y lapiz???
Muchas gracias me seria de mucha ayuda ya q en la universidad no me permiten usar el picdelay
 
Porque se sabe la cantidad de ciclos que toma cada instruccion, y si les das tambien el dato del reloj saben cuanto dura el ciclo, y de ahi se calcula el retardo.
 
Yo apostaria que se basa en la descomposición en factores primos XD
el numero a descomponer obviamente es el resultado del tiempo y la frecuencia del oscilacior.
¿para que necesitas saber?
 
La explicación matemática la tienes aquí, mientras que la obtención del código está al final de aquí.

¡Ojo! No es exactamente el mismo código que genera, pero sí casi el mismo. La diferencia está en la posición de los goto $+1 dentro de los bucles anidados.

El cálculo se basa en dividir el número de ciclos de instrucción, por lo que tarda en ejecutarse cada bucle anidado. El límite, para tres bucles anidados, veo que es de 117 millones de ciclos (menos de 2 minutos, a 4 Mhz). El generador tiene capacidad para 4 bucles anidados, así que se pueden hacer esperas aún más largas.
 
Muchas gracias amigos por responder.
Joaquin la verdad lo estaba viendo ya desde mas antes toda esa teoria pero esta complico... pero muchas gracias por el dato... lo seguiré estudiando y haber si alguien sabe algo mas sencillo que toda esa teoria!!! muchas gracias
 
Esto...

Acabo de descubrir que ese generador funciona bien hasta los 458763 ciclos, pero a partir de ahí, falla.

Para 458764, tengo un resultado de 1785 ciclos demás.

Para 4 000 000 de ciclos, el error se eleva a 12376.

¿Alguien más puede verificarlo?

He hecho las pruebas con los siguientes valores:

* Frecuencia: 4 Mhz
* Cálculo a partir de ciclos (no segundos)
* No generar código para subrutina.

Adjunto hoja de cálculo donde estoy haciendo las cuentas.
 

Adjuntos

  • delays.ods.zip
    11.1 KB · Visitas: 40
Última edición por un moderador:
Usad los timers es una locura un retardo de mas de 100~200 ciclos. El sistema está muerto y enterrado.

Y gastando energía... no es importante para hobby, pero para diseñar un producto con pilas a vender miles de unidades (o más) ese tipo de cosas puede redundar en que duplicas la cantidad de pilas de desecho como consecuencia de tu diseño (es el equivalente a un auto que consume el doble de gasolina para recorrer la misma distancia).

Tener a un micro con timers ejecutando instrucciones en vacío para hacer retardos es lo más cercano a usarlo de pisa-papeles :oops:
 
Bueno tienen mucha razón que utilizar los timer del pic es la mejor opción, que estar perdiendo el tiempo con los retardos. Pero lo que yo propongo y trato de investigar es con fines educativos. Espero que entiendan al punto al que voy.
 
Ruego no te ofendas por lo siguiente, voy a ser muy vehemente y tan solo refleja MI forma de pensar, no es un dogma ni pretendo estar en posesión de la verdad absoluta:
¿Fines educativos?¿Vas a educar en los malos usos y malos vicios?
Bajo mi punto de vista si es didáctico razón de mas para NO enseñar malos hábitos.
Según lo veo yo en un sistema "de verdad", "profesional", "serio" o como se le quiera llamar. SIEMPRE, SIEMPRE, SIEMPRE, SIEMPRE, SIEMPRE hay algo que hacer, NO SE PUEDE, o no se debe dejar dummie, zombie, o echando una siestecita, un sistema varios segundos. Eso es una eternidad en la que pueden pasar mil cosas, hay que atender al paro de emergencia, informar del proceso, admitir datos de configuración y un largo etcétera.
Los bucles vacíos para unos pocos muy muy pocos ms y cuantos menos mejor.
Yo nunca he hecho bucles vacíos ni de 256µs. Solo decrementar un registro de 8 bits y unos 20~100 ciclos de 1MHz. Mas me parece una aberración enorme.
 
Última edición:
Atrás
Arriba