What the For Loop?

Go To Last Post
32 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to make a nested delay loop with this in VMLAB coding for a ATtiny22.

	for (i=0;i<=255;i++) {
		for (j=0;j<=255;j++) {
			for (k=0;k<=255;k++);
		}
	}

It keeps giving me this err:

[PC = $0011, Time =    2.07 ms, {GEN}]: Y index not supported on this device

???

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try changing the loop indexes to <255 instead of <=255. Just a guess.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep, did that already. Same result.

Even tried a single for loop.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know why this error is occurring, but even if you do fix it, the loop will do nothing. Avr-gcc will see that the code does nothing and optimize it out. If you want delays, use the functions provided in .

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think it's an issue with VMLAB. First, that error doesn't look like an output that gcc would produce. Secondly, the code compiles with WinAVR 20100110.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The code compiles fine, this a is simulation err that pops up when the sim hits the loop. It gives this err a few times then jumps over the loop.

How frustrating. AVRStudio refuses to run under wine, VMLAB seems to be glichy, and Codevision fails to run right too.

And now I got wine messed up from trying to make it work with AVRStudio.

Drat...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

syberraith wrote:
I'm trying to make a nested delay loop with this in VMLAB coding for a ATtiny22.

	for (i=0;i<=255;i++) {
		for (j=0;j<=255;j++) {
			for (k=0;k<=255;k++);
		}
	}

If i, j or k is unsigned char,
the corresponding loop will run forever.
Occasionally a compiler will warn about such things.
Quote:
It keeps giving me this err:

[PC = $0011, Time =    2.07 ms, {GEN}]: Y index not supported on this device

Sorry, can't help.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

for a ATtiny22

Wow--pretty scarce info on the Web for this model. Are you sure? As a "non-mainstream" model support may be sketchy. Perhaps some of these models don't have the "Y index" instruction mode(s) implemented?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

tiny22? Interesting... a device you can buy, yet no mention of it on the Atmel site as a current, or mature product. Datasheet I found is dated back to '99, has all 32 working registers, so it would have a Y register. [even the new reduced core AVR's have a Y register, their 16 registers run from r16-r31]

Perhaps it is an instruction [using a Y index] that is not supported? Take a look at what is at that PC location and then check to see if that instruction is supported by the tiny22.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But before anyone gets too concerned about this exactly what can one expect from VMLAB? My understanding is that they stopped development and made it freely available several years ago. I think development has restarted recently to add more modern devices but what guarantees are there about the quality of it's simulation? - no one seems able to produce accurate simulators if Atmel sim1, Atmel sim2, simulavr, Proteus all apparently get so many things wrong? If they happen to have simulated an AVR that virtually no one's ever heard of then presumably that particular model has not been heavily exercised/tested by the users - so there could well be simulation errors. But I'd start with glitch's advice, look at the Asm and find out what the faulting code actually is.

I was going to ask why would Y be involved in a bunch of nested for() loops anyway - but, of course, if GCC code is built -O0 then everything happens on the stack and Y is the stack frame pointer. If this is the sae the OP might want to consider their use of -O0 (except that we all know why they would be using it! Did someone mention ? ;-))

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff wrote:
Did someone mention ? ;-)
Yup!
Steve wrote:
If you want delays, use the functions provided in .

Cliff wrote:
no one seems able to produce accurate simulators if Atmel sim1, Atmel sim2, simulavr, Proteus all apparently get so many things wrong?
I can say with some assurance that it is nigh-on impossible to back-engineer a completely faithful simulator of something as complex as a CPU. During the design of an IC, simulations are performed on the original design files and we would find errors in the simulations even then! We would run the design files through different simulators and would get different results from the different simulators.

Simulators have the advantages of providing in-depth cycle-by-cycle information about the program as well as providing the ability to run the program without the hardware. I personally have a dim view of running simulations of processors, but I understand their value both in the education and professional environments.

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got the dissassembly listing from VMLab. The index err occurs before the code for the loop. I added some comments:

;    Generated by VMLAB AVR disassembler
;    ===================================
;

.org $00
l_0000:
   rjmp  l_0003
   rjmp  l_0011
   rjmp  l_0011
l_0003:			; Init
   clr   R1		; Zero R1
   out   $3F, R1	; Export R1 to SREG 
   ldi   R28, $DF	; Load RAMEND into R28
   out   $3D, R28	; Export R28 to SPL
   ldi   R17, $00	; Load 0x00 into R17
   ldi   R26, $60	; Load 0x60 into XL
   ldi   R27, $00	; Load 0x00 into XH
   rjmp  l_000c		; Jump to l_000c
l_000b:
   st    X+, R1
l_000c:
   cpi   R26, $62	; Compare XL with 0x62 
   cpc   R27, R17	; Compare with carry XL with 0x00
   brne  l_000b		
   rcall main
   rjmp  l_002e
l_0011:
   rjmp  l_0000
SIGNAL:
   push  R29
   push  R28
   rcall l_0015
l_0015:
   rcall l_0016
l_0016:
   in    R28, $3D
   in    R29, $3E
   std   Y+2, R25
   std   Y+1, R24
   pop   R0
   pop   R0
   pop   R0
   pop   R0
   pop   R28
   pop   R29
   ret
my_function:
   push  R29
   push  R28
   in    R28, $3D
   in    R29, $3E
   nop
   pop   R28
   pop   R29
   ret
main:
   push  R29
   push  R28
   in    R28, $3D
   in    R29, $3E
l_002d:
   rjmp  l_002d
l_002e:
   cli
l_002f:
   rjmp  l_002f

Any idea why VMLab puts $60 in to XL hen test for $62?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Any idea why VMLab puts $60 in to XL hen test for $62?

VMLAB has not done that. It is the C runtime supplied by GCC that has done it. What you are looking at there (though it's very difficult to follow this disassemblers hopeless output) is the .bss loop in the C pre-amble.

Here it is in more cosmetic form taken from the .lss which at least label annotates the Asm:

00000060 <__do_clear_bss>:
  60:	10 e0       	ldi	r17, 0x00	; 0
  62:	a0 e6       	ldi	r26, 0x60	; 96
  64:	b0 e0       	ldi	r27, 0x00	; 0
  66:	01 c0       	rjmp	.+2      	; 0x6a <.do_clear_bss_start>

00000068 <.do_clear_bss_loop>:
  68:	1d 92       	st	X+, r1

0000006a <.do_clear_bss_start>:
  6a:	a2 36       	cpi	r26, 0x62	; 98
  6c:	b1 07       	cpc	r27, r17
  6e:	e1 f7       	brne	.-8      	; 0x68 <.do_clear_bss_loop>
  70:	0e 94 41 00 	call	0x82	; 0x82 

If you use an Mfile template for building your code you should be getting a .lss generated when you build anyway - it's basically an avr-objdump of the .elf with the -S option.

You can see the C runtime in even more detail within the published source of AVR-LibC:

http://svn.savannah.gnu.org/view...

By the way I assume you've spotted that your entire program consists of:

main: 
   push  R29 
   push  R28 
   in    R28, $3D 
   in    R29, $3E 
l_002d: 
   rjmp  l_002d 

So this is a "do nothing sensible" program. You have something you have labelled "SIGNAL:" yet it is not a SIGNAL() handler (there is no RETI) and you have myfunction: - neither of these are used and might as well not exist.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Uh, well, there's this:

Disassembly of section .text:
00000000 <__vectors>:
   0:	02 c0       	rjmp	.+4      	; 0x6 <__ctors_end>
   2:	07 c0       	rjmp	.+14     	; 0x12 <__bad_interrupt>
   4:	06 c0       	rjmp	.+12     	; 0x12 <__bad_interrupt>

00000006 <__ctors_end>:

   6:	11 24       	eor	r1, r1
   8:	1f be       	out	0x3f, r1	; 63
   a:	cf ed       	ldi	r28, 0xDF	; 223
   c:	cd bf       	out	0x3d, r28	; 61
   e:	02 d0       	rcall	.+4      	; 0x14 
10: 42 c0 rjmp .+132 ; 0x96 <_exit> 00000012 <__bad_interrupt>: 12: f6 cf rjmp .-20 ; 0x0 <__vectors> ...

Is this happening because I neglected to define the ISRs for int0 and int1?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Again if you look at the generic C runtime source in gcrt1.S you'll see (as the manual explains and that listing shows) that by default any interrupt vector that has not been hooked will vector by default to "__bad_interrupt:" and at that location it is simply:

00000078 <__bad_interrupt>:
  78:	0c 94 00 00 	jmp	0	; 0x0 <__vectors>

So your listing above - with both vectors making a jump to that code shows that the vectors have not been hooked. Often this is because if you write:

#include 

ISR(INT0_vect) {
 // something
}

ISR(INT1_vect) {
 // something else
}

int main(void) {
  configure_INT_sources();
  sei();
  while(1) {
  }
}

then the lack of #include in that causes the ISR()s to be compiled as normal functions, not vectors (actually the use of sei() should be a fatal error).

So my guess is that you forgot:

#include 

but lets not guess - your program is clearly so trivial that I don't see why you couldn't simply post the entire source rather than small snippets which don't tell the complete picture.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK. I tried subbing in the above int routines and got an misspelled interrupt handler err on them. As it is it gave the x index err. I'm just trying to find out what the minimum shell code is.

// ***********************************************************
// Project:
// Author:
// Module description:
// ***********************************************************

#include               // Most basic include files
#include        // Add the necessary ones
#include           // here

// Define here the global static variables
//
int My_global;

// Interrupt handler example for INT0
//
SIGNAL(SIG_INTERRUPT0) {

}

// It is recommended to use this coding style to
// follow better the mixed C-assembly code in the
// Program Memory window
//
void my_function(void) {  // Put the open brace '{' here

   asm("nop");          // Inline assembly example
}

// ***********************************************************
// Main program
//
int main(void) {

   while(1) {             // Infinite loop; define here the
      my_function();      // system behaviour
   }

}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From iotn22.h:

/* Interrupt vectors */

/* External Interrupt 0 */
#define INT0_vect			_VECTOR(1)
#define SIG_INTERRUPT0			_VECTOR(1)

/* Timer/Counter0 Overflow */
#define TIMER0_OVF0_vect		_VECTOR(2)
#define SIG_OVERFLOW0			_VECTOR(2)

but a better reference is the user manual:

http://www.nongnu.org/avr-libc/u...

When I build your code I get:

c:/winavr-20100110/lib/gcc/../../avr/include/avr\signal.h:36:2: warning: #warning "This header file is obsolete.  Use ."

Did you not think this was important enough to do something about? Anyway try:

#include               // Most basic include files 
#include        // Add the necessary ones 

// Define here the global static variables 
// 
int My_global; 

// Interrupt handler example for INT0 
// 
ISR(INT0_vect) { 

} 

// It is recommended to use this coding style to 
// follow better the mixed C-assembly code in the 
// Program Memory window 
// 
void my_function(void) {  // Put the open brace '{' here 

   asm("nop");          // Inline assembly example 
} 

// *********************************************************** 
// Main program 
// 
int main(void) { 

   while(1) {             // Infinite loop; define here the 
      my_function();      // system behaviour 
   } 

}

after pre-processing this yields:

int My_global;

void __vector_1 (void) __attribute__ ((signal,used, externally_visible)) ; void __vector_1 (void) {
}

void my_function(void) {
   asm("nop");
}

int main(void) {
   while(1) {
      my_function();
   }
}

After compilation the Asm passed to avr-as is:

	.file	"test.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__  = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
 ;  GNU C (WinAVR 20100110) version 4.3.3 (avr)
 ; 	compiled by GNU C version 3.4.5 (mingw-vista special r3), GMP version 4.2.3, MPFR version 2.4.1.
 ;  GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 ;  options passed:  -I. -iprefix
 ;  c:\winavr-20100110\bin\../lib/gcc/avr/4.3.3/ -MMD test.d -MF
 ;  .dep/test.s.d -MP -MQ test.s -DF_CPU=1000000UL test.c -mmcu=attiny22
 ;  -auxbase-strip test.s -gdwarf-2 -Os -Wall -Wstrict-prototypes
 ;  -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct
 ;  -fshort-enums -fverbose-asm
 ;  options enabled:  -falign-loops -fargument-alias -fauto-inc-dec
 ;  -fbranch-count-reg -fcaller-saves -fcommon -fcprop-registers
 ;  -fcrossjumping -fcse-follow-jumps -fdefer-pop -fearly-inlining
 ;  -feliminate-unused-debug-types -fexpensive-optimizations
 ;  -fforward-propagate -ffunction-cse -fgcse -fgcse-lm
 ;  -fguess-branch-probability -fident -fif-conversion -fif-conversion2
 ;  -finline-functions -finline-functions-called-once
 ;  -finline-small-functions -fipa-pure-const -fipa-reference -fivopts
 ;  -fkeep-static-consts -fleading-underscore -fmath-errno
 ;  -fmerge-constants -fmerge-debug-strings -fmove-loop-invariants
 ;  -fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls
 ;  -fpack-struct -fpeephole -fpeephole2 -freg-struct-return -fregmove
 ;  -freorder-functions -frerun-cse-after-loop -fsched-interblock
 ;  -fsched-spec -fsched-stalled-insns-dep -fsigned-zeros
 ;  -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing
 ;  -fstrict-overflow -fthread-jumps -ftoplevel-reorder -ftrapping-math
 ;  -ftree-ccp -ftree-copy-prop -ftree-copyrename -ftree-dce
 ;  -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im
 ;  -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops=
 ;  -ftree-reassoc -ftree-salias -ftree-scev-cprop -ftree-sink -ftree-sra
 ;  -ftree-store-ccp -ftree-ter -ftree-vect-loop-version -ftree-vrp
 ;  -funit-at-a-time -fvar-tracking -fverbose-asm -fzero-initialized-in-bss

 ;  Compiler executable checksum: 61d68a374065d489330774d2533cbbdf

.global	__vector_1
	.type	__vector_1, @function
__vector_1:
.LFB2:
.LM1:
	push __zero_reg__	 ; 
	push r0	 ; 
	in r0,__SREG__	 ; 
	push r0	 ; 
	clr __zero_reg__	 ; 
/* prologue: Signal */
/* frame size = 0 */
/* epilogue start */
.LM2:
	pop r0	 ; 
	out __SREG__,r0	 ; 
	pop r0	 ; 
	pop __zero_reg__	 ; 
	reti
.LFE2:
	.size	__vector_1, .-__vector_1
.global	my_function
	.type	my_function, @function
my_function:
.LFB3:
.LM3:
/* prologue: function */
/* frame size = 0 */
.LM4:
/* #APP */
 ;  20 "test.c" 1
	nop
 ;  0 "" 2
/* epilogue start */
.LM5:
/* #NOAPP */
	ret
.LFE3:
	.size	my_function, .-my_function
.global	main
	.type	main, @function
main:
.LFB4:
.LM6:
/* prologue: function */
/* frame size = 0 */
.L6:
.LBB4:
.LBB5:
.LM7:
/* #APP */
 ;  20 "test.c" 1
	nop
 ;  0 "" 2
/* #NOAPP */
	rjmp .L6	 ; 
.LBE5:
.LBE4:
.LFE4:
	.size	main, .-main

And disassembly after linking (which includes the CRT) yields:

Disassembly of section .text:

00000000 <__vectors>:
   0:	02 c0       	rjmp	.+4      	; 0x6 <__ctors_end>
   2:	10 c0       	rjmp	.+32     	; 0x24 <__vector_1>
   4:	0e c0       	rjmp	.+28     	; 0x22 <__bad_interrupt>

00000006 <__ctors_end>:
   6:	11 24       	eor	r1, r1
   8:	1f be       	out	0x3f, r1	; 63
   a:	cf ed       	ldi	r28, 0xDF	; 223
   c:	cd bf       	out	0x3d, r28	; 61

0000000e <__do_clear_bss>:
   e:	10 e0       	ldi	r17, 0x00	; 0
  10:	a0 e6       	ldi	r26, 0x60	; 96
  12:	b0 e0       	ldi	r27, 0x00	; 0
  14:	01 c0       	rjmp	.+2      	; 0x18 <.do_clear_bss_start>

00000016 <.do_clear_bss_loop>:
  16:	1d 92       	st	X+, r1

00000018 <.do_clear_bss_start>:
  18:	a2 36       	cpi	r26, 0x62	; 98
  1a:	b1 07       	cpc	r27, r17
  1c:	e1 f7       	brne	.-8      	; 0x16 <.do_clear_bss_loop>
  1e:	0e d0       	rcall	.+28     	; 0x3c 
20: 0f c0 rjmp .+30 ; 0x40 <_exit> 00000022 <__bad_interrupt>: 22: ee cf rjmp .-36 ; 0x0 <__vectors> 00000024 <__vector_1>: // int My_global; // Interrupt handler example for INT0 // ISR(INT0_vect) { 24: 1f 92 push r1 26: 0f 92 push r0 28: 0f b6 in r0, 0x3f ; 63 2a: 0f 92 push r0 2c: 11 24 eor r1, r1 } 2e: 0f 90 pop r0 30: 0f be out 0x3f, r0 ; 63 32: 0f 90 pop r0 34: 1f 90 pop r1 36: 18 95 reti 00000038 : // follow better the mixed C-assembly code in the // Program Memory window // void my_function(void) { // Put the open brace '{' here asm("nop"); // Inline assembly example 38: 00 00 nop } 3a: 08 95 ret 0000003c
: // follow better the mixed C-assembly code in the // Program Memory window // void my_function(void) { // Put the open brace '{' here asm("nop"); // Inline assembly example 3c: 00 00 nop 3e: fe cf rjmp .-4 ; 0x3c
00000040 <_exit>: 40: f8 94 cli 00000042 <__stop_program>: 42: ff cf rjmp .-2 ; 0x42 <__stop_program>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that's still going to give an err, because of the ST X+,R1 on line 16.

The data sheet says this is a valid instruction for the T22, although the simulator seems to be balking at it.

I'll try what you mention here, and see what happens.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The data sheet says this is a valid instruction for the T22, although the simulator seems to be balking at it.


Why are you so insistent about doing this work with such an oddball AVR model, that the simulator may or may not have gotten right 10 years ago? (Oddball? Extinct? Non-existent? Fabled?)

There is a really nice active 8-pin Tiny25 family.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah...

Although, there's a absence of any nice ATtiny25 model for VMLab.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It doesn't seem (from your posts) that VMLab is very happy with your model choice all around. If this is an "academic exercise" to work with the simulator and AVR constructs, then pick a model that >>is<< supported to an acceptable level for you. Other than a few mentions such as for using in the STK500 Atmel's Web site has no useful information at all on a Tiny22, not even in "mature devices".

I'm out.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I understand it. The 22 was one of the first models Atmel made based on the 8051. It's historic...

In anycase I'm building a model for the ATiny25/45/85 series. That I guess will be another academic exercise.

And I do have the 22 working well enough with assembler, so I guess C is just out of the question for that one.

I appreciate your help.

Best regards,

Fred

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

As I understand it. The 22 was one of the first models Atmel made based on the 8051. It's historic...

Huh? The AVR origin from all reports that I know of is well documented. "Based on the 8051"? Well, I suppose that the features of microcontrollers were examined so that corresponding capabilities could be matched. What exactly part(s) of AVRs are based on 8051, and what exactly features are unique to the Tiny22 (which is really AT90S2343, right? https://www.avrfreaks.net/index.p... )

Historic? The 1997 databook lists the following models:

AT90S1200
AT90S2313
AT90S4414
AT90S8515

Now, >>those<< models are historic. I'll have to look at the 1999 databook on Monday to get that list.

The '8515 did/does indeed [nearly--/RESET vs RESET] match the pinout of a generic x51 40-pin. But matching pinout doesn't mean "based" to me.

So much for being "out". Can't resist responding to spewing. "I need to run my 1963 Chevy using the computerized parts from a 2005 Ford. Why doesn't everything match up?"

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I think that's still going to give an err, because of the ST X+,R1 on line 16.

The data sheet says this is a valid instruction for the T22, although the simulator seems to be balking at it.


The conclusion I draw from that is that the simulator is a piece of crap - what conclusion do you draw?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

syberraith wrote:
As I understand it. The 22 was one of the first models Atmel made based on the 8051. It's historic...

No, the ATtiny22 was the first 8-pin AVR with 128 byte SRAM.
Unfortunately it has a critical bug (wrong fuse reading after power on), so it stopped execution most the time.

This bug was corrected in a really curious way, the ATTiny22 was discontinued. :shock:

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
wrong fuse reading after power on

According to the datasheet it only had one fuse: SPIEN. Since this fuse only affected whether or not you could program the chip, I don't know how it would stop execution.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danni wrote:
syberraith wrote:
As I understand it. The 22 was one of the first models Atmel made based on the 8051. It's historic...

No, the ATtiny22 was the first 8-pin AVR with 128 byte SRAM.
Unfortunately it has a critical bug (wrong fuse reading after power on), so it stopped execution most the time.

This bug was corrected in a really curious way, the ATTiny22 was discontinued. :shock:

Peter

I think that's what I read, that the T22 was the first avr based on the 8051 that had sram memory.

In any case the I think it a moo point.

I've made an ini file for the ATtiny25, I'll make a inc file for it next. The only involved part I see is coding the DLLs for TIMER1 and it's special registers. The rest of the peripherals can probably use the basic VMLab internal models.

Hopefully I'll be able to handle that. The VMLab forum is awful quiet. Eventually I'd like to have the code for different models on source forge so anybody can easily improve them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

According to the datasheet ...

Keep in mind Orwell's 1984--the datasheet you read >>now<< might only have one fuse. :twisted:

Is this what some refer to as "trolling"? Make obscure complaints about the simulation in some arbitrary 3rd party system of an obscure/flawed/phantom/long obsolete/inferior AVR model, and then throw in references to "historic" and "based on 8051". I guess it kind of got me to come along for the ride.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The VMLab forum is awful quiet.

But it was abandonded and made PD wasn't it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I think that's what I read, that the T22 was the first avr based on the 8051 that had sram memory.

But it was not based on the 8051 (and with only 8 pins, wasn't even pin compatible), and it was not the first AVR with SRAM, so if you did read it, then it was most certainly incorrect.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

The VMLab forum is awful quiet.

But it was abandonded and made PD wasn't it?

The source code is still closed.

The compiled binaries are available as freeware.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

compiled binaries are available as freeware.

Then expect as much support as you paid for.