Modificar fuses en simulación de AVR Studio

Salu2 compañeros, sigo aprendiendo la programación a bajo nivel de los AVR's, utilizo como simulador el mismo AVRStudio.

Me he encontrado con un problema, no sé como modificar los "fuses" para el micro en la simulación, necesito modificar los bits que asignan el divisor de reloj al CPU (CKSEL).

¿En que menú se editan estos ajustes dentro de la interfaz del AVRStudio?

Gracias
 
Gracias Cosme, buscando en el mismo AVRStudio hallé otra manera de hacerlo y es modificando directamente el valor de frec que se muestra en la ventana "Registers" al momento de la simulación

frec.png

ya he hecho el cambio pero la simulación sigue dándome problemas.

Siendo preciso ando simulando una rutina de retardo de 4S; ejecuto el debug y al finalizar el "Stop Watch" marca que en verdad el retardo ha durado cerca de 4S (cerca porque no pude lograr el valor exacto) pero desde el momento en que ejecuto el debug y detengo la simulación en realidad dura como 2 mins :confused:

¿Será que mi PC es muy lenta?, de antemano se que no mediré los 4S reales como tal pero si al menos una aproximación, no quisiera tardarme media hora en simular mi programa completo :(
 
El AVR Studio tanto el 5 como el 6, son pesaditos. Sin embargo a la hora de simular el "debuggeo", no tuve mayor inconvenientes, tampoco llegué a simular tanto tiempo como 4 s.
 
Como alternativa livianita, podés usar el AVR - GCC (el AVR Studio usa ese compilador) + un IDE como el Code::Blocks o Code Lite, la única contra es que no tenés el simulador :unsure:.
 
Pues no, ya hice la prueba corriendo solamente el AVRStudio y la cosa no mejoró. Acá igual tienen este problema, hice lo que comentaron de cerrar las ventanas "watch" y tampoco :cry:

http://www.avrfreaks.net/forum/slow-simulator

Gracias por los consejos pero lo que en realidad me importa es el simulador; como un recurso más, intentaré conseguir un AVRStudio más antiguo
 
Última edición:
Y en vez de trabajar con tiempos taaan largos, ¿no podés trabajar con tiempos menores? (mS) Una vez que obtenés un tiempo considerable, es cuestión de calcular cuanto será el desvio máximo que vas a tener a los 4s.
 
Ups, moderaron mi antiguo mensaje, mencioné que ya descargué la versión 4.18 del AVRStudio y el problema se redujo, no siguen siendo los 4 segundos reales pero ya la simulación es más rápida.

De hecho la rutina por hardware del AVR más larga es la de 100mS, para lograr la de 4S hice un lazo para llamar a la rutina de 100mS 40 veces.

Por si sola la de 100mS tarda como 2 segundos en ejecutarse, por ello al llamarla 40 veces pues se va acumulando el retardo.
 
La rutina esta hecha usando el cnt0 como temporizador, el programa sólo espera a que se ponga en 1 la bandera de desborde. He buscado y parece ser que la lentitud es un problema inherente al mismo atmel studio, no tiene que ver con las instrucciones puestas :/
 
hola
La rutina esta hecha usando el cnt0 como temporizador, el programa sólo espera a que se ponga en 1 la bandera de desborde. He buscado y parece ser que la lentitud es un problema inherente al mismo atmel studio, no tiene que ver con las instrucciones puestas :/
bueno lo que te podria acotar yo ., es que tambien influye en su velocidad ., la optimizacion del programa que estas realizando ., no se si eso lo tenes en cuenta ., yo por lo general lo coloco en -Os capture_02182015_062736.jpg
capture_02182015_062431.jpg
 
Eso que dice el Locodelafonola es importante, si la rutina de delay dependiera de una instrucción que se la pasa repitiendo todo el tiempo (en assembler para tener mayor precisión), la optimización puede descartar ese delay haciendo creer al compilador que la rutina no tiene sentido alguno. Ejemplo de esto, es la función "void _delay_ms(double __ms)" que incluye la librería "#include <util/delay.h>".

En cambio si está implementado con contadores, ya se evita el problema de optimización, aunque obviamente se sigue dependiendo de la frecuencia del clock.

De todas formas, si se puede evitar los delays, mejor.
 
Olvidé mencionar que la rutina de retardo está hecha en ensamblador:

Código:
Espera_100mS:							;Tiempo de espera de 100mS	
	
	ldi			ACC1,0x01
	out			SFIOR,ACC1				;Reinicia preescaler del TCNT0
	ldi			ACC1,61					;Constante para contabilizar 100mS
	out			TCNT0,ACC1				;Carga constante en registro temporizador
	ldi			ACC1,1<<TOV0			;Bandera TOV0 se borrará
	out			TIFR,ACC1
	ldi			ACC1,0x05
	out			TCCR0,ACC1				;Configura preescaler 1024:1 como fuente de reloj para el TCNT0
	in			ACC1,TIFR	
	sbrs		ACC1,TOV0				;Espera a que transcurra el lapso de tiempo programado
	rjmp		PC-2					;Lazo de espera
	ldi			ACC1,0
	out			TCCR0,ACC1				;Detiene TCNT0
	ret									;Retorno de la subrutina



Espera_4S:								;Tiempo de espera de 4S

	ldi			CONTA1,40				;Numero de veces que se llamará a la rutina de retardo de 100mS
	rcall		Espera_100mS			;para sumar los 4S de retardo
	dec			CONTA1
	brne		PC-2					;Lazo de espera
	ret									;Retorno de la subrutina


Como les comenté, he medido los tiempos que tarda en ejecutarse la rutina de 100mS y el resultado se muestra acorde al tiempo programado:

Frec.png

Sin embargo en realidad, desde que inicio el simulador hasta que se detiene al finalizar la rutina de 100mS pasa como un minuto:confused:
 
La rutina esta hecha usando el cnt0 como temporizador, el programa sólo espera a que se ponga en 1 la bandera de desborde. He buscado y parece ser que la lentitud es un problema inherente al mismo atmel studio, no tiene que ver con las instrucciones puestas :/

Mmm tambien puedes probar con interrupciones para no estar -sondeando-
 
Estas rutinas las tengo usadas para reemplazar las funciones "delay" en C, las implementé así pues casi no hago uso de ellas, sólo al iniciar el programa para tiempos de estabilización.

Las rutinas de retardo que más se invocan desde el programa si están optimizadas para usar interrupciones pero no las he simulado pues el tiempo que tarda sigue siendo bastante :/
 
Lo dejé de lado un momento y me dediqué a la simulación en ISIS, donde también tuve algunos problemas pero menores.
He terminado la primera etapa del programa y lo he grabado en el AVR, hasta ahora no ha habido problemas en su circuito físico, más adelante quizá se tenga que modificar algo.
 
Atrás
Arriba