Can a program tell if it is running on the simulator?

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

If no other way, maybe I could use a known simulator bug that causes it to get different results than a real AVR would get.

I have _delay_ms(500) in some test code. It takes an AVR 1/2 second to get past it. It takes the simulator an eternity (approximately). I get tired of changing the code when I bounce back and forth between the simulater and OCD.

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

You could read an input pin. The simulator will assume that it is at 0V unless you use a pull-up. Of course real-life may be different.

You could also use a hardware timer instead of the cycle-wasting. I think you will find it simulates faster.

David.

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

Or you can add another configuration under Project->Project options->Edit configurations, let’s say ‘debug’ and set a label. In your program you can use preprocessor #ifdef/#ifndef to check if label is defined and conditionally include your delays.

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

david.prentice wrote:
You could read an input pin. The simulator will assume that it is at 0V unless you use a pull-up.
David.
Interesting you should mention that. I find that the simulator does not assume high pins when pullups are used. I have Studio 4.18 and am simulating the newfangled xmega128a1.

Attachment(s): 

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

david.prentice wrote:

You could also use a hardware timer instead of the cycle-wasting. I think you will find it simulates faster.

David.

Hardware timers are the way to go. Today I'm learning how to use i/o ports on the xmega. Tomorrow I'll try to figure out hardware timers.

Anyway, when you are blinking LEDs at one Hertz, the technique used isn't critical, especially when it is USB powered rather than batteries. :)

Last Edited: Thu. Dec 10, 2009 - 08:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TFrancuz wrote:
Or you can add another configuration under Project->Project options->Edit configurations, let’s say ‘debug’ and set a label. In your program you can use preprocessor #ifdef/#ifndef to check if label is defined and conditionally include your delays.
You may have a quick point and click solution there, if I was using AVR Studio to do my builds. I run make from the command line.

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

I found a solution that works. Some day in the future I may have to do a quick adjustment to the test.

I read the chip revision ID. That is register REVID in the MCU control group.

My real chip is rev 7, also known as H. The simulator has rev 6. Now I wonder just how well it simulates the bugs in the rev 6 (G) chip. :)

If I upgrade the simulator I'll be screwed. I must keep it at least one rev behind my chips. :)

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

david.prentice wrote:
You could read an input pin.
Actually, that is a good idea when using the Xplain board. The pins connected to the LEDS will be pulled high when set as input pins. All I need to do is check the pins initially before I set the pins to output.

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

steve17 wrote:
TFrancuz wrote:
Or you can add another configuration under Project->Project options->Edit configurations, let’s say ‘debug’ and set a label. In your program you can use preprocessor #ifdef/#ifndef to check if label is defined and conditionally include your delays.
You may have a quick point and click solution there, if I was using AVR Studio to do my builds. I run make from the command line.

So it's even simpler – add another build target, something make release/make debug. Rest is the same – in release you can define flag which makes your delays to be included.