AVR Simulator, again.

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

I am nearly at the point of giving up! I had to write my code that was originally intended for a tiny261 for a tiny26 to simulate it and get the code right then alter the registers to compile it for the tiny261 because the 261 isn't simulated other than a power on reset and PORT i/o (almost) and now i have a problem with a Mega88, i don't like to blame the simulator especially in areas that are not in the bug list but it seems when i write code, my first instinct now is to jump through the simulator problem list rather than my code.

If the datasheet and my understanding is correct should generate an interrupt on ICRF when matched, i can't even get the timer to increment in the simulator

ldi r17,$3E ;load 16bit register ICR1 with timer top.
ldi r16,$80
sts ICR1H,r17
sts ICR1L,r16

ldi r16,$20 ;set to compare match interrupt enable only
sts TIMSK1,r16

ldi r16,$00 ;set wgm to CTC mode
sts TCCR1A,r16

sts TCNT1H,r16 ;clear timer
sts TCNT1L,r16

ldi r16,$19 ;set WGM to CTC and clock on i/o clk
sts TCCR1B,r16

sei

Can anyone point out errors in the above code and is there another simulator available for ATMEL chips that I can use?

Thanks

John (got some hair left, just!)

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

You're right, it doesn't "tick" though rather curiously if you clear WGM13 and WGM12 and single step (so timer now in "normal" mode) then TCNT1 begins to count. Now if you put WGM13 and WGM12 back again it still keeps ticking.

But this does look like yet another limiation of the simulation of timers. No doubt Sim2 will do this properly but the "technology preview" we have available so far does not cover the 48/88/168. I guess we just have to be patient.

Cliff

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

Thanks cliff, i thought i was going mad... i have lost probably a couple of hours to this bug. I don't understand why 1 processor can be simulated almost fine yet another on the same type of i/o isn't. Is there another simulator i can use that doesn't involve me installing linux or are we stuck with this one?
I keep getting mythered by the microchip rep, probably every 2 weeks and things like this make me almost want to defect... if it wasn't for the fact i have designed and commited the hardware i'd be sorely tempted!

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

Well personally, for something like an 88 I'd forget trying to simulate it all together. Just splash $50 on a Dragon and watch the real chip in action (you might have spent more than that on simulation software!)

Cliff

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

I have never used one of those, have had my eye on one... will it run like a simulator and you can put in break points etc?? can you stimulate the i/o just the same or would you have to create real time events?

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

Yup that's exactly what a debugWire/JTAG interface will do for you. You can put in break points and single step, watch memory and variables and SFR registers and do all the other "goodies" that you can when using the simulator but the difference is that the code is running in the real AVR. Amongst many advantages are:

1) when "free running" things happen at realtime speed - not 1/100th normal speed or whatever it is the simulator delivers

2) it is a 100% accurate simulation (because it's not a simulation, it's the real chip in action)

While there are those that work on the Schroedingers Cat principle when it comes to dW/JTAG I have always found it a tool that makes one 10 times more productive but that's probably because I adhere to the lazy school of fixing the broken bits after the fact rather than getting the design 100% correct in the first place ;)

Cliff

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

I probably went to the same school, i know where you're comming from. I have just invested in a JTAGICE MK2 and i'm hoping to be able to do the same thing with the hardware when it is built, i'd normally pain stakingly go through the simulator but i'm hitting more and more problems with the simulation. The dragon thingy sounds great, i might just get one to play with if they are that cheap.

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

Dragon is just a "cut down" version of JTAGICEmkII or, to put it another way, the JTAGICEmkII is the "grown up" version of the Dragon so there's little to be gained in getting a Dragon if you already have a mkII on the cards.

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

cool, i'll look forward to getting it... i put the po in last week so hopefully should get it this week.

Thanks for your help cliff.

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

Quote:
i'd normally pain stakingly go through the simulator
I really DON'T understand using simulators :? in almost 30 years working with micros I have always used the real hardware in some form. A simple monitor program running inside the chip would have been the minimum resource I would have had in all those years. When did people started to use simulator instead of real hardware? :) Yes, I did use the simulator when I looked at the AVR chips...for about 15 minutes, the next thing was an ICE200 and chips on veroboard.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

John,

The great thing I think the simulator delivers is a way to learn microcontroller programming with NO hardware and no outlay (and no complexity of getting ISP programmers working and breadboarded AVRs connected up right)

If you just give someone a 10 line C or Asm program they can build it and then "watch it running" with just 1 or 2 easily installed programs (and doing so and watching the "blobs" showing which bits in which SFRs you are setting is very educational)

It is, however, a shame that folks then seem to become totally reliant upon said and waste hours only to find out that the reason their timer1 program isn't working is actually because the simulator doesn't do a great job of simulating that bit.

Cliff

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

Ha! point taken.... think i have just learned the hard way!! I have never come accross the problem before, maybe i have just been lucky with the devices i have chosen. I do like to, while the pcb is being designed write a skeleton program just to verify the hardware design can support the software design to reduce the hardware 'mods' during prototype stage and to annoy the pcb designer with revisions while he is doing it!
I guess the JTAG ICE (just landed on my desk) coupled with a STK500 (somewhere under the mess on my desk) would actually perform the same function with the appropriate processor plugged in to it.

John.

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

Hi everybody,

as many have commented the current state of peripheral support in the AVR Studio simulator is not so good, particularly for some of the recently introduced devices.

As some may have noticed, we introduced a new simulator (AVR Simulator V2) in AVR Studio 4.13. At the present time it supports too few devices and lacks too many features to be really useful, but we intend to broaden both the device support and feature set shortly. The new simulator is derived from the actual chip designs and therefore will be much more accurate and complete in digital simulation (initially we won't support simulation of analog peripherals).

Maintenance of the old simulator has suffered lately, for which I am sorry. I recommend all users to check the "known issues" in the Simulator help section (both the general issues and the device-specific issues), before assuming your program is faulty. If you have a hardware emulator the best option is to check if it works on the real thing, of course.

If any of you happen to work with the devices currently supported by Simulator V2 (ATmega128 and ATtiny25/45/85), we appreciate any feedback you have on the new simulator. Beware that it is somewhat unstable in 4.13, it tends to crash particularly when leaving debugging mode. Save your files frequently.

- roland

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

rkruse wrote:
Maintenance of the old simulator has suffered lately, for which I am sorry. I recommend all users to check the "known issues" in the Simulator help section (both the general issues and the device-specific issues), before assuming your program is faulty. If you have a hardware emulator the best option is to check if it works on the real thing, of course.

Roland,

I guess this comes too late now, but an idea I've suggested here a number of times is that when the (old) simulator is used it should throw a dialog saying "Before using this it's important to understand its limitations and you should read the Known Issues section of the helpfile" with a tick box to say "don't show me this warning again".

I've lost count of the number of posts I've made here simply saying "but the Known Issues already said you shouldn't have expected this to have worked" (or words to that effect). Usually after the poster has wasted many hours "fixing" something they think they've done wrong.

Cliff

PS BTW, as you are around, do you have any plans to change the avr-gcc plugin so that:

(a) it defaults projects to -Os rather than -O0

(b) it always links projects against libm.a by default

You wouldn't believe the number of posts generated by code not working correctly because of one of these two issues!

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

Quote:
change the avr-gcc plugin so that:
....the project configutation options has lots more check boxes for things like compiler and project options in the "custom options" ... lots of them...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Good point - bottom line is that default options should be set to match those in the Mfile template. Another one that catches people is the missing -std=gnu99 and then they wonder why:

for (int i=0; i<10; i++)

won't work.

Cliff

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

Quote:
-std=gnu99
This should be one of the radio buttons/checkboxes.
Quote:
match those in the Mfile template
Better still not have to look at Mfile or Makefiles at all :) , the project configuration tool should do all of that....just like Codevision or ICC (???)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

John,

No I don't mean that Studio should dynamically look at the makefile template just that the engineer responsible for the avr-gcc plugin at Atmel should take a once and for all look at an Mfile template, note down all the settings it uses by default and build those in as the project defaults for Studio projects (but with radio buttons/droplists allowing the user to switch them to the other potential settings). When I compile a .c file using the default Mfile template (apart from mcu setting) I see:

Compiling: fred.c
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=8000000UL  -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=fred.lst  -std=gnu99 -MD -MP -MF .dep/fred.o.d fred.c -o fred.o

So those are all the default compiler settings that the Studio system should be using too.

Cliff