AVR Simulators

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

Hey Everyone,

I would like to start a discussion about AVR simulators. I have not had much experience with AVR version before, but have found simulators a very import part of my development. I would like anyone to make comments about the simulators they have used.

Information on things like, UART, IO control, GUI/Command Line, external API should be included.

Thanks

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

Well the totally free one from Atmel built into AVR Studio ain't too shabby (especially considering how much you pay for it!)

http://www.atmel.com/dyn/product...

Cliff

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

Only used the simulator a few times when first looking at the AVR because I didn't have any hardware, then I put a chip on a bit of verobard, purchased an ICE200 and never looked at the simulator again...that's about 6 years or more now. Why simulate when you can do the real thing and run your code on a chip?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

Why simulate when you can do the real thing and run your code on a chip?

Time routines/algorithms. Yes, certainly, one can instrument the real chip but it is far easier to drill down to find the ugly part that way.

You ICE users probably test/debug your routines that way. I use my head; ICE connections are too scary. [Another topic, we've been there before: you gotta make the connections, give up the pin(s), and bet the farm that the ISE isn't changing the app at all (which we all know is not true in all cases).]

Using the real chip ain't necessarily that easy when you are, say, using the laptop while waiting for the wife & dauhters to shop for a prom dress at the department store.

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:
Using the real chip ain't necessarily that easy when you are, say, using the laptop
The Dragon would be wonderfull to use in the car I would say :), sit it on the dashboard next to the target and away you go (You don't actullay allow them to drag you into the store do you??). I haven't tried using my head for debug. Do you have RS232 or USB implants? :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

No, you program your algorithm. You >>think<< about how the pieces go together. You test subsystems and then rely on them. You look at the symptoms.

Anyway, I don't use the simulator often anymore, either, but "run it on the chip" implies a reliable setup. Dragon or no Dragon, you are still draggin' something around. If you mean using it as an ICE then all my other comments apply.

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

The main reason i want to run a simulator is that i want to run multiple (up to 10) simulations at the same time. The project is a sensor network of sorts... Much easier then using 10 real hardware units. Plus a simulator allows for easy unit testing (ie automated testing)

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

Quote:

Much easier then using 10 real hardware units.

But like 1000 times slower?

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

Is it? This is what i started the discussion about. I have not had experience with AVR simulators. I have used others and they have sufficed.

Trust me, it is much easier to have 500 automated unit test that can be run after someone has done a "patch" for the firmware to ensure the correct functionality then it is to sit and hope that u might pin point the problem in a real world test.

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

Quote:

to ensure the correct functionality

You can never "assure" with 100% certainty that a simulator or emulator or ICE system is not affecting the results.

Second, you could test subsystems. But IMO not a microCONTROLLER app. If there was no interface to the real world it is not a significant microcontroller app.

[Tat one can go round and round like the other Wars. Let's take an AVR as a simple bridge device of some kind. Even if your simulator/emulator stimulates the inputs according to a test pattern those signals are not going to be the same as the real-world triggers.]

I see your point, though, for regression testing. Perhaps a large-budget project could invest in the prep and maintenance of the test suite, and run the checks on the tool ("Who will watch the watchers?") to "ensure" the correct stimuli. I'm thinking of all the ways a Mega48 can be configured in an app and how daunting it would be to construct an exhaustive "test rig" stimulator--real world or simulator--to cover all the possibilities. For a fixed-configuration, specific app, large budget, yes. Otherwise not.

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

The AVR Studio simulator is pretty functional, however there are still very important things that it does not support.

"TWI, USI and analog peripheral simulation is not yet implemented. All instructions, interrupts and other peripherals are supported.

Shadow register support is missing in AVR Studio. As a consequence when operating PWM in fast- and phase correct mode, the OCR register should not be updated until TCNT is at TOP.

The Asynchronous Status Register (ASSR) is not supported in timers with asynchronous mode. This is due to lack of a generic external clock implementation.

The simulator will output a warning each time it encounters an instruction that is not supported by the device that is executing. This function cannot be turned off. To avoid the message, rewrite the application so that it does not use the instruction that generates the warning."

Right now I switch between the simulator in IAR and AVR studio. If I need to work with the input/output of alot pins I will use AVR studio Simulator because it is more visual. If I need anything else I will use the IAR simulator.

One of the biggest problems I have with the AVR studio simulator is that I can not Evaluate arithmetic expression in the WATCH. With IAR that is possible.

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

Thanks guys for your input.

Most of my products i am working on at the moment consist on UART communications and maybe 1 or 2 interrupt driven inputs, so in terms of IO, they are very simple. I think i might give each simulator a run using my application and see how they perform.

The second reason i want to use a simulator is for demonstrations and to help test the application side of the project. At this stage a simple representation of the hardware has been made in c#, and the application developer uses this extensively to test his work. I have 3 huge problems with this,

1. If changes are made to the firmware, they need to made in the c# version as well.
2. The c# version is nothing like the real version!!!
3. The application programmer thinks if it works with the c# version it will work on the hardware version.

So what i would like to write is a simple c# interface that communicates to a simulator or jtag(TCP/IP) device that will allow the application to be tested against the real firmware. Due to the extensive use of unit tests in the application program, it is not viable to test against real hardware during development (4000+ unit tests)

From your guys experience, do you think this would work well?

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

How did C# get mixed into this?

You are in for a world of pain. If you are saying that you want to make an AVR siulator in C# then it will be alot of work. If you want to simply "hook up" the simulator to a C sharp application then I have no idea how much work is required ( I do not think that the simulaor in AVR studio is very kind to interfacing with external stimulus, but i never tried it before)

I also do not understand why you can not just run real hardware with an ICE? There are 4000+ plus test units, but there are not 4000+ differrent hardware versions?
Or is does the real hardware consist of 4000+ units somehow linked together, so when you test it you need to have 4000+ units connected together? If that is the case how on earth are you going to simulator 4000+ units of anything?

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

Quote:
how on earth are you going to simulator 4000+ units of anything?
4000 PCs?? :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

not 4000+ units being tested, 4000+ "unit tests" meaning 4000+ simple tests geared at a particular subsystem/scenario/input/behaviour/etc.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

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

Quote:
how on earth are you going to simulator 4000+ units of anything?

I think that is ultimately the problem the OP is trying to solve.
Quote:
I do not think that the simulaor in AVR studio is very kind to interfacing with external stimulus

And therefore the need for a different simulator, preferably a command line one or a GUI one which can be programatically directed.

I have a set of unit tests split into two projects, since the AVR flash is limited in size. To run the first set I have to load it and run it. For me the results are indicated by flashing one of two LEDs; a more sophisticated method would utilize RS232. Anyways, then I have to load the second set of tests and run those.

Now imagine I have 100 of these. "Automated test" turns into a manual nightmare. So writing a shell, if you will, to configure a simulator, run the tests, record the results, and repeat for each test suite, would be a really handy thing.

Unit tests are both expensive and invaluable. But they are under-utilized if the difficulty of running them is very high.

C: i = "told you so";