1.4 Key Differences Between Simulator and Hardware Tools

In Microchip Studio, the simulator is handled basically like any other hardware tool. It can be selected for both programming dialog and debug sessions. However, there are some key differences:

  • The simulator is volatile, meaning it has no memory between sessions. Anything programmed into the simulator non-volatile memories (like flash contents or fuses) in one session will be forgotten after the session is quit. When a session is ended, the simulated device quite literally ceases to exist, and when a new session is started a new simulated device is created from scratch, starting its existence in its initial state. Specifically, this means you cannot program fuses in the programming dialog, and later start a debugging session with these fuse settings intact. A new session always starts with default fuse settings. Fuses and other options for use in debugging sessions with the simulator have to be set up using a simulator-specific property page active only during a simulator debugging session. A feature allowing parts of or the entire simulator state to be saved between sessions may be considered in the future.

  • The simulator has no selectable programming or debugging interfaces. This because the simulated device is implemented by a software model, and all access of internals within the model is done via a software API; no physical interface is involved, and all access is completely non-intrusive since nothing needs to be clocked to retrieve or write data.

  • Presently, only a single instance of the simulator can be run at a time. Also, the simulator lacks serial numbers like most of the hardware tools have.

  • The simulator is not real-time. This means that the speed of the simulation (measured in simulated CPU cycles per second) is significantly lower than on a real device. The simulator can only utilize a single CPU core in a multi-core CPU, so upgrading your PC with more cores will not make it faster, but there are indications that a larger CPU cache gives better performance.

  • The simulator is not a complete model of the device. While digital logic is simulated cycle-accurately, all analog periphery is presently lacking. Also, the modeling of NVM1 is incomplete. The degree of incompleteness varies between devices, see Known Issues in Simulator.

  • Device support is not complete. The simulator depends on a software model of each device/family to be simulated. Supported devices are shown in the device selector when the simulator is selected.

  • The simulator runs in isolation, meaning the surroundings of the simulated device is not simulated. To run real-life applications on the simulator, stimuli must be provided to the inputs of the simulated device. Stimuli can be provided by simple stimuli files, as shown in Simulator Stimuli.

  • For the ATmega128 simulator model the ATmega103 compatibility fuse (M103C) is not programmed by default, and SUT is set to the shortest possible value in some devices

  • In most tinyAVR® devices, the SELFPRGEN fuse is unprogrammed by default, preventing SPM from working. Set this fuse when working with SPM.

  • Many tinyAVR devices have external reset as an alternative port function, and an RSTDISBL fuse to disable the external reset pin. When unprogrammed (the default setting), the corresponding port pin will not work as expected.

  • The CKDIV8 fuse is normally unprogrammed to increase simulation speed

1

Flash, EEPROM