• start
  • proteus
  • utstyr
  • bøker
  • skolesider
  • kontakt oss

  • Proteus VSM USB Simulation

    Proteus VSM USB simulation represents the worlds first (and only) schematic based USB Simulation engine. You can now design your own USB peripheral device entirely in Proteus (using one of the supported microcontrollers) and then test both the firmware and the hardware by simulating the circuit. Communication is modelled down to Windows driver level, with all requests to and replies from the simulated USB device displayed in the USB Transaction Analyser. Proteus VSM is discussed in more detail here.

    Overview

    The main aim of the Proteus VSM USB Simulation is to allow complete simulation of those microcontrollers having an on-board USB peripheral. Since the vast majority of such devices have a USB device peripheral as opposed to a USB host controller peripheral Proteus VSM is currently limited to simulation of USB devices (devices that attach to the USB socket on the computer), and specifically to simulation of the following USB Device classes:

    • Mass Storage Device Class (MSD)
    • Human Interface Device Class (HID)
    • Communications Device Calss (CDC)

    Support for additional classes (and indeed additional microcontroller variants) is on-going and, depending on demand, implementation of USB host simulation support may also be considered.

    How it Works

    The schematic in Proteus represents the peripheral device (e.g. a USB memory stick or a USB mouse). A special schematic part called the USB connector is wired to the USB enabled microcontroller and clicking on this schematic part during simulation is equivalent to plugging in the device to a USB slot on your PC. The microcontroller executes the firmware through the schematic and USB communication will take place with the PC operating system in the same way as plugging in a physical equivalent device to a spare USB socket on the computer.

    The USB Transaction Analyser can be used to decode and display all URB transactions and register access operations during simulation and the full range of Proteus VSM debugging techniques are also available. This means that you can design, debug and test your USB peripheral entirely within the Proteus software environment before you construct a physical prototype.

    What You Need

    • A licence for a microcontroller family with supported USB variants. This includes our schematic capture engine and enables USB simulation on the variants which include on-board USB peripherals.
    • A licence for the USB Transaction Analyser. This enables you to monitor and analyse USB traffic and register access operations during simulation.

    Analysis capabilities can be upgraded to include Graph Based Simulation via the Advanced Simulation Options module.

    Please see the commercial price list for pricing information or contact us to further discuss requirements.

    Proteus VSM PIC18F4550 model simulating Microchip Technologies Mass Storage firmware to present a file stored in the simulated MMC model to Windows via USB.

    Running a USB Simulation

    In practise, running a USB simulation differs little from any other VSM simulation. The typical procedure is outlined below.

    • Install the USB Drivers - these are supplied as standard with your Proteus installation.
    • Design the schematic in ISIS for the USB Peripheral device you want to make. Remember to place and wire the USB connector schematic part on the schematic.
    • Take the firmware framework for the USB device class you are implementing and modify the top level to be application specific. Manufacturers typically supply free firmware that will handle the low level communications - for example, the Microchip Technologies PIC18 USB code can be downloaded here.
    • Apply the COF/HEX file to the program property of the microcontroller schematic part in ISIS.
    • Run the simulation via the PLAY button at the bottom of the ISIS application.
    • Click on the USB Connector schematic part to connect the USB device - this is equivalent to plugging in the physical equivalent device to your PC.
    • Use the USB Transaction Analyser to monitor and verify USB traffic as your simulation progresses.
    • Debug and test your firmware and circuit as per any normal Proteus VSM simulation - bearing in mind that the USB Protocol has a 30 second timout limitation (your simulation needs to respond to requests within 30 seconds).
    • Stop the simulation via the STOP button at the bottom of the ISIS application.
    • Modify firmware or 'hardware' as required and re-run the simulation to test.
    • When complete use the netlist command to transfer to ARES and commence PCB Layout.

    Supported Variants

    Currently modelled Microcontrollers Supporting USB Simulation:

    • PIC18F4450, PIC18F4553
    • PIC18F2450, PIC18F2455, PIC18F2458, PIC18F2550
    • PIC18F2553, PIC18F4450, PIC18F4455, PIC18F4458
    • AT90USB646, AT90USB1286

    USB Transaction Analyser

    The Proteus USB Analyser is a seperately licenced product that displays all requests and replies to and from the simulated USB device. This provides an invaluable aid both to understanding the USB protocol and in verification of firmware implementation. The main Analyser window consists of two parts: the Requests List and the Requests Description as shown below.

    The USB Analyser in Proteus

    The Requests list on the left hand pane of the Analyser displays all requests in tree format. There are three levels of requests; IRP requests (IOCTL, MJ_PNP), Transaction requests (IN, OUT, SETUP) and register operations associated with a given transaction.

    The request description forms the right hand side of the Analyser and provides detailed tabular information on the currently selected item in the Requests List. Given that the Requests list is granular to three levels it follows that comprehensive information can be retrieved at either the IRP Level, the transaction level or the register level.

    The small toolbar at the top of the Analyser provides options to start logging, stop logging and also to clear the log. This is particularly useful where you are interested in communications after the setup phase or in response to activity from the host controller.