About a year ago Xembedded was approached by a company that designs and manufactures a system that is enclosed in those little metal shacks next to the railroad tracks all over the world. Those shacks hold equipment that ensures the safety of our railroad system looking at things like train car wheels, brake hoses, speed of the train cars, temperature of the rails, weight of the cars and other items that could affect the safety of the public and the rail system.
An out of round train car wheel can damage the track and can cause a derailment of the whole train. Using transducers on the track, this system picks up the signature of the wheels rolling past and reports any irregularities to a central location. The system was built around a SBS VR7 processor board that uses a custom P2 pin out for the rear I/O and the chassis uses a custom backplane to connect the rear I/O. When the VR7 processor was End-Of-Life, it left this manufacture without a system processor, necessitating an immediate redesign, unless a solution could be found.
I once worked for an engineering manager that said, “with infinite time and cubic money we can do anything…. but we don’t have either”. This was very true in this case; the customer needed a solution and did not have the luxury of time and a lot of NRE money.
This customer needed a drop-in, pin-for-pin replacement board eliminating the need for new chassis, backplanes and wiring in the rail side systems. Some of these systems are so remote in location that the service personnel needed to backpack everything to the site so reliability along with the ability to live in extreme hot and cold climates without fans was an absolute requirement. In addition their system requirement had grown through the years with the growth of their application code; more memory and a faster CPU were on the list of new requirements along with a more accurate Time-Of-Day clock.
Xembedded worked closely with this customer to develop a drop in replacement with the added features for very little NRE and a low commitment of orders for the custom modules.
Let Xembedded help you with your End-Of –Life module replacement needs. Don’t let a single module going EOL in your system send you into a complete system redesign. Contact us at sales@xembedded.com.
Within the last two years the .concept of “Stand-Alone Rugged Boxes” has become a fixture in this market. The trend has now broadened out to include a larger con¬tingent of smaller form factor board vendors. The term stand¬alone rugged boxes applies to complete system boxes—which often support standard form factor boards inside them. These systems provide a complete, tested and enclosed computing so¬lution that eliminates complex integration chores for military customers. This idea has been gathering momentum in the past couple years whereby traditional embedded board vendors are adding stand-alone rugged box-level systems to their military market offerings.
As the product roundup in this section shows, at present, there arc more than a dozen vendors that have some sort of stand-alone rugged box-level system in their offerings—many even have whole product lines in that category. As a product cat¬egory, stand-alone rugged boxes are somewhat difficult to define because they’re available in a variety of shapes, sizes and capabil¬ities. They typically comprise a set of modular embedded boards housed in a rugged enclosure that has its own power supply and interface ports to link to a variety of user terminals.
Often the boards in the box are standards-based cards such as PC/104, PMC and 3U CompactPCI. But the enclosures by and large aren’t in any industry standard footprint, although that may change as standards like MicroTCA and some box-level VITA standards gain acceptance in the military realm. Recently a number of vendors from the PC/104 community have joined the stand-alone rugged box trend. This stacked multi-board PC/104 architecture provides for a shock- and vibration-resis¬tant off-the-shelf computing solution by eliminating backplanes and metal card cages, making PC/104 ideal for military vehicles such as tanks or even Humvees.
Earlier this month—on Election Day in fact—this topic of complete integrated systems was discussed at a luncheon panel session at RTC Group’s Real-Time Embedded Com¬puting Conference (RTECC) in Reston, VA. The panel discussed how stand-alone rugged box solutions have emerged as a second center of gravity alongside SBCs. Board-level systems, according to the panel, remain tremendously important—and active— especially in the areas of tech upgrades and tech refresh where board-level products shine. But some new military programs are opting for complete box-level systems—and some older pro¬grams are shifting from a slot-card scheme to a box-level imple¬mentation. The panel also discussed the technology forces that have brought this trend toward integrated system solutions into the forefront—such as FPGAs and the emergence of multi-func¬tion boards. Also analyzed by the panel was the issue of how mergers and acquisitions in the embedded computing industry pushed forward this trend toward integrated solutions. COTS Journal Online – John Sayer – Xembedded
This week let’s talk a little about the Status function in our board support package. This is an application within the XVME-984 software support library that allow a user to look at the module IDs on the VMEbus. This includes our processor boards and any Input/Output modules on the VMEbus.
XVMEstat is a 32-bit menu-driven Windows application that displays the contents of the PC/AT status registers module type, system resource, master/slave interface information, VMEbus ownership, and front panel LED information.
XVMEstat Window
The XVMEstat window is automatically updated every second (default). Select the Timer… option from the Configure menu to change this update rate. You can force an immediate read of the status registers by selecting the Read option in the menu bar.
Figure 4-1. XVMEstat window
Clicking the icon in the window title bar or right-clicking anywhere in the title bar will open the System menu, which will allow you to size or close the window.
Figure 4-2. System menu
Configure Menu
This section describes the menu options associated with the Configure Menu.
Figure 4-3. XVMEstat Configure menu
Configure->Timer
This menu option opens a dialog for configuration of the time interval for reads and writes. The two choices are:
The default option, Time (ms), enables the operating system to send a WM_TIMER message to the application at periodic intervals. The default value is 1000 milliseconds.
The Continuous option generates continuous reads or writes.
Figure 4-4. Configure->Timer
Configure->Title
This menu option opens a dialog that allows you to change the window title.
Figure 4-5. Configure->Title
View Menu
This section describes the menu options associated with the View menu. If your Xembedded CPU board only supports four master and four slave images, the Master Interface (5-8) and Slave Interface (5-8) options will not be available and the other options will be Master Interface and Slave Interface.
Figure 4-6. XVMEstat View menu
View->General
This menu option selects general information to be displayed. This is the view seen when the XVMEstat window is first opened. Note the processor module model number is displayed along with information about the system resource controller (see part 1 for this information), the Bus Request Level being used, the request mode and release mode. You can also see the display of the front panel lights, these can be set or reset in the VMEman monitor functions (see last weeks Part 1).
Figure 4-7. General View
View->Master Interface
This menu option displays information related to the master interface. There are two master interface windows, one for images 1-4 and one for images 5-8. If your XVME CPU board only supports four master images, there will be only one window, for images 1-4.
Figure 4-8. Master Interface View
View->Slave Interface
This menu option displays information related to the slave interface. There are two slave interface windows, one for images 1-4 and one for images 5-8. If your XVME CPU board only supports four slave images, there will be only one window, for images 1-4.
Figure 4-9. Slave Interface View
View->Interrupts
This menu option selects information related to VMEbus and Auxiliary interrupts to be displayed.
Figure 4-10. Interrupts View
Read Menu Command
This function performs an immediate read of the XVME PC/AT status registers and updates the display.
Help Menu
This menu lets you access the BSP help file and the About XVMEstat window, which displays version information for the XVMEstat executable.
As you can see this XStat function in our VMEman product can be very helpful in understanding your current setup and how those actions are programmed.
The VMEbus processor can be an intimidating device to program. Just getting started can be a daunting task, where to start? how do you know you can “talk” to the other modules on the VMEbus? Can you talk to the other modules on the VMEbus?
In this series I have brought in sections of our user manual for the XVME-984, Microsoft Windows software support library. With this software you can get on the VMEbus and “talk” to other boards in the backplane in a matter of a few minutes. Most is point, click and enter address and data. In this document we will talk about the use of the VMEbus Manager application. The other applications listed in the overview below will be covered in the coming weeks in this series.
It is important to understand the three major components of the VMEbus; System Controller, Master Interface and Slave Interface. All of the Xembedded VMEbus processors incorporate all three components.
System Controller: Only one module on the VMEbus can be the system controller.
The system controller provides for bus arbitration, a 16 MHz system clock, and the IACK daisy chain driver. This functions major purpose is to determine which bus master get to “talk” on the VMEbus. The Bus Grant function is used to determine who the system controller on the VMEbus is where multiple bus masters are present. Only one module on the VMEbus can be the system controller.
Master Interface: The VMEbus master interface is sometimes referred to as the “TALKER”. Only a module capable of talking on the VMEbus and has been given permission by the system controller to talk on the VMEbus. The master interface is the method to talk between modules on the VMEbus.
Slave Interface: The VMEbus slave interface is sometimes referred to as the “Listener”. Only a module capable of listening on the VMEbus and has been given permission by the system controller to listen on the VMEbus. The slave interface is the method to talk between modules on the VMEbus.
Overview
The XVME-984 Windows® Board Support Package (BSP) is a comprehensive package that simplifies the process of designing VMEbus application programs for Xembedded VME hardware in the Microsoft® Windows 2000 and XP, Vista and Windows® 7 environment.
The Windows® BSP has the following components (distributed on CD):
Installation program
Application Programming Interface (API) used to develop VMEbus applications
Operating system (OS) specific VMEbus device driver
32-bit Dynamic Link Libraries (DLLs)
VMEbus Manager (VMEman) application
XVME Status (XVMEstat) application
VMEbus probe (VMEprobe) application
Dual-access probe (DAprobe) application
Figure 1-1. Component diagram Boards Supported
The following Xembedded VMEbus processor boards are supported:
Single-Slot 233 MHz Intel® Pentium® MMX™ processor; hardware byte-swapping; 0, 32, 64, 128, or 256 MB DRAM; SVGA graphics controller; two serial, one parallel, one USB connectors; floppy/IDE hard disk controllers; 10Base-T/100Base-TX Ethernet.
Two-Slot; 600 MHz Intel Pentium III or 566 MHz Intel Celeron™ processor; hardware byte-swapping; 0, 32, 64, 128, or 256 MB SDRAM; AGP graphics controller; two serial, one parallel, one USB connectors; floppy/IDE hard disk controllers; 10Base-T/100Base-TX Ethernet; PMC site; IP site, UltraSCSI.
Two-Slot; 700 MHz Intel Pentium III processor; hardware byte-swapping; 0, 32, 64, 128, or 256 MB SDRAM; AGP graphics controller; two serial, one parallel, one USB connectors; floppy/IDE hard disk controllers; Dual-10Base-T/100Base-TX Ethernet; PMC site;.
Single-Slot VMEbus Processor with Pentium M 1.8GHz or Celeron M, 256MB to 2GB DRAM, dual Giga-Bit Ethernet, PMC site (PCI-X), USB ports, Serial ports and EIDE and SATA drive interfaces.
Same P2 VMEBus pinout as a SBS VR7 with Single-Slot VMEbus Processor with Pentium M 1.8GHz or Celeron M, 256MB to 2GB DRAM, dual Giga-Bit Ethernet, PMC site (PCI-X), USB ports, Serial ports and EIDE and SATA drive interfaces.
Single-Slot VMEbus Processor with Intel Core Duo Processor or Core2 Duo Processor 1.5GHz to 2.16GHz, 512MB to 8GB DRAM, dual Giga-Bit Ethernet, PMC and XMC site, dual Gigabyte Ethernet, USB ports, serial ports and EIDE and SATA drive interfaces.
VMEbus Manager Application
Xembedded’s VMEbus Manager (VMEMan.exe) is a Win32® application program that gives you a simple mechanism for accessing and monitoring the VMEbus on Xembedded VMEbus PC/AT processors. Xembedded has developed standalone applications to support the VMEbus Manager so that you can test your VMEbus system configuration easily and efficiently. Those applications are:
Application Name
Description
XVMEstat
Displays and monitors the status of VMEbus interrupts, VMEbus control registers, and VMEbus status registers in graphical form.
VMEprobe
Reads from and writes to VMEbus dual-access memory;
DAprobe
Reads from and writes to PC/AT dual-access memory.
Accessing the VMEbus
Windows require a device driver to manage the Tundra Universe II, PCI to VMEbus bridge interface. Its responsibilities include:
Managing VMEbus master resources
Managing VMEbus slave resources
Generating VMEbus interrupts
Handling VMEbus and auxiliary interrupts
Software reset of BIOS
Dynamic Link Libraries (DLLs) provide a 32-bit, high-level application programming interface (API) to the driver. This interface is a comprehensive set of functions that simplifies the development of VMEbus application programs. All of the VMEbus manager tools were written using these libraries.
This chapter describes the API in detail as well as the VMEbus master interface, VMEbus slave interface, and interrupt capability.
VMEbus Master Interface
Xembedded’s VMEbus PC/AT processor modules, which contain a VMEbus master interface, have one or more resources that can be configured to provide a “window” to the VMEbus. The number of resources or “windows” is dependent on the XVME CPU module being used. At a minimum, each “window” is configured with the VMEbus Address Space (A16, A24, A32), VMEbus base address, Program/Data address modifier, and Supervisory/Nonprivileged address modifier. Depending on which XVME CPU module is being used, other configurations such as VMEbus bound address, maximum data width, and cycle type may be configured as well. The device driver accepts VMEbus access requests through the provided API from application programs and configures a “window” accordingly to fulfill the request. The driver also ensures the integrity of the configuration when receiving multiple requests from different processes and/or threads.
VMEbus Slave Interface
Xembedded VMEbus PC/AT processor modules that contain a VMEbus slave interface have one or more resources that can be configured to provide an external “window” to the XVME CPU local memory. The number of resources or “windows” is dependent on the XVME CPU module being used and is configured in the BIOS setup menus (see your XVME CPU hardware manual for information on configuring the VMEbus slave interface). The device driver allocates and reserves the specified amount of local memory from Windows 2000 and XP and maps it accordingly to the “windows.” This memory must be allocated as physically continuous and non-pagable, which can only be done during initialization of the device driver. The device driver accepts access requests to this local memory from application programs through the provided API.
Interrupts
All Xembedded VMEbus PC/AT processor modules are capable of handling interrupts on all seven VMEbus interrupt levels. Some VMEbus PC/AT modules also contain a VMEbus interrupter circuit. This local interrupter allows the VMEbus PC/AT processor module to generate a VMEbus interrupt on any of the seven VMEbus interrupt levels.
Device Driver
The device driver (VMEbus4.sys) is required to access the XVME CPU VMEbus control and status registers and the VMEbus. The functionality built into this driver includes:
VMEbus access
Dual-access memory allocation and access
VMEbus interrupt generation
VMEbus interrupt handling
General access to control registers
Tundra Universe chip (PCI to VMEbus Bridge) control
XVME4.DLL/XVME.LIB/XVME.H
XVME4.dll provides a 32-bit, high-level interface to the device driver. Programming for the DLL requires users to include the XVME.h header file in their C source code. This header file contains all of the function prototypes and VMEbus constant definitions. After the application has been developed and compiled, it must be linked with the XVME.lib file. This links the application to the DLL so that the functions can be accessed at runtime.
Note
See the appropriate Windows programming manuals for more information on building and linking to DLLs.
XVME.DLL/XVMEISR.DLL
These DLLs are provided to support applications which were developed using the XVME-984/3 Windows 32-bit VMEbus Toolkit. Applications developed with XVME-984/3 will run unmodified with the Windows NT BSP. However, to gain improvements in both performance and functionality, it is necessary to reprogram these applications to use the API documented in this manual.
Library Routines
This table summarizes the library routines, in our next installment we will go into the functions and how they are used.
Routine
Description
auxintAlloc
Allocates an auxiliary interrupt object
auxintDisable
Disables an auxiliary interrupt
auxintEnable
Enables an auxiliary interrupt
auxintFree
Frees up the auxiliary interrupt object allocated by the auxintAlloc
auxintWait
Waits for an auxiliary interrupt
daAlloc
Returns a pointer to an allocated dual-access memory region
daFree
Frees up the dual-access memory region allocated by daAlloc
daMove
Copies data from dual-access memory to dual-access memory
daRead
Dual-access memory read
daRMW
Performs read-modify-write operation on dual-access memory
daWrite
Dual-access memory write
ioRead8
Reads an 8-bit value from an I/O port
ioRead16
Reads a 16-bit value from an I/O port
ioRead32
Reads a 32-bit value from an I/O port
ioWrite8
Writes an 8-bit value to an I/O port
ioWrite16
Writes a 16-bit value to an I/O port
ioWrite32
Writes a 32-bit value to an I/O port
univRead8
Reads an 8-bit value from the configuration space of the Universe chip
univRead16
Reads a 16-bit value from the configuration space of the Universe chip
univRead32
Reads a 32-bit value from the configuration space of the Universe chip
univWrite8
Writes an 8-bit value to the configuration space of the Universe chip
univWrite16
Writes a 16-bit value to the configuration space of the Universe chip
univWrite32
Writes a 32-bit value to the configuration space of the Universe chip
vmeAlloc
Allocates a VMEbus memory region and returns a pointer
vmeFree
Frees up the VMEbus memory region allocated by vmeAlloc
vmeMove
Copies data from VMEbus memory to VMEbus memory.
vmeRead
VMEbus memory read
vmeRMW
Performs read-modify-write operation on VMEbus memory
vmeSysReset
Executes a VMEbus SYSRST and restores the state of the Universe chip
vmeWrite
VMEbus memory write
vmeintAlloc
Allocates a VME interrupt object
vmeintDisable
Disables a VME interrupt
vmeintEnable
Enables a VME interrupt
vmeintFree
Frees up the VME interrupt object allocated by vmeintAlloc
vmeintGenerate
Generates a VMEbus interrupt
vmeintWait
Waits for a VME interrupt
vmeintWaitEx
Waits for a VME interrupt
VMEbus Manager
The Xembedded VMEbus Manager (VMEMan.exe) is a 32-bit Windows application program that provides a simple mechanism for accessing and monitoring the VMEbus. When using a Xembedded PC/AT processor, the program allows you to quickly test your VMEbus system configuration, by providing a convenient mechanism for reading and writing to VMEbus memory, and monitoring the status of VMEbus interrupts and the PC/AT status registers. This program, like all Windows programs, is menu driven.
Figure 3-1. XVME-984/5 Windows 2000 and XP applications
To execute the VMEman application, select the VMEman icon from the XVME 984-5 group. The VMEman window will open.
Figure 3-2. VMEman window
Clicking the icon in the window title bar or right-clicking anywhere in the title bar will open the System menu, which will allow you to size or close the window.
Figure 3-3. System menu
Monitor Menu
This section describes the menu options associated with the Monitor menu.
Figure 3-4. VMEman Monitor menu
Monitor->XVMEstat
This menu option executes the XVMEstat application, which displays general information about the status of the VMEbus master interface, VMEbus slave interface, and VMEbus interrupts. See Chapter 4 for information on the XVMEstat application.
Monitor->VME IDs
This menu option searches the VMEbus short I/O address space for Xembedded ID PROMs. If any are found, a window is opened and a description of the board is displayed. This description includes the short I/O address where the board resides. If the board found is intelligent, the result of its power-on self test is displayed (PASS/FAIL). If the board is not intelligent, its green LED is turned on and its red LED is turned off.
Figure 3-5. Monitor->VME IDs
Probe Menu
This section describes the menu options associated with the Probe menu.
Figure 3-6. VMEman Probe menu
Probe->VMEprobe
This menu option executes the VMEprobe application, which has the ability to read, write, search, and fill VMEbus memory. See Chapter 5 for information on the VMEprobe application.
Probe->DAprobe
This menu option executes the DAprobe application, which has the ability to read, write, search, and fill dual-access memory. See Chapter 6 for information on the DAprobe application.
Probe->Pass/Fail LEDs
This menu option opens a dialog that allows changing the status of the front panel red and green LEDs on the Xembedded PC/AT VME processor.
Figure 3-7. Pass/Fail LED dialog
Probe->Lock/Unlock VMEbus
This menu option opens a dialog that allows the VMEbus to be obtained using the bus lock bit. The VMEbus will be locked until specifically released by this menu option or by another application.
Figure 3-8. Lock/Unlock VMEbus dialog
Probe->Initiate SYSRST*
This menu option initiates full local and VMEbus resets.
Interrupts Menu
This section describes the menu options associated with the Interrupts menu.
Figure 3-9. VMEman Interrupts menu
Interrupts->Wait for Interrupt
This menu option allows you to specify on which VMEbus levels (1-7) and/or ANMIs (ACFAIL, SYSFAIL, ABORT) to be notified. Once selected, VMEman generates a task displaying the following information:
A status message indicating that it is waiting for the interrupt
A message showing the number of interrupts received since it started
A message showing the number of interrupts per second since it started.
A “Close” button to quit processing, closing the dialog.
Figure 3-10. Wait for Interrupt dialog
Interrupts->Generate VME Interrupt
This menu option allows you to generate a VMEbus interrupt. If the interrupt cannot be generated, a message box will appear.
Figure 3-11. Generate VME Interrupt dialog
Interrupts->Interrupt Sources
This menu options opens a dialog that allows VMEbus levels 1-7 as well as ACFAIL, SYSFAIL, and ABORT push button interrupts to be enabled or disabled.
Figure 3-12. Interrupt Sources dialog
Configure Menu
This section describes the menu option associated with the Configure menu.
Figure 3-13. VMEman Configure menu
Configure->Master Interface
This menu option opens a dialog that allows driver parameters relating to the master interface to be configured. These parameters are specific to the XVME CPU module being used.
Figure 3-14. Configure Master Interface dialog
Configure->Slave Interface
This menu option opens a dialog that allows driver parameters relating to the slave interface to be configured. These parameters are specific to the XVME CPU module being used.
Figure 3-15. Configure Slave Interface dialog
Configure->Block Hardware
This menu option opens a dialog that allows driver parameters relating to special block transfer hardware to be configured. These parameters are specific to the XVME CPU module being used.
Figure 3-16. Configure Block Hardware dialog
Configure->Interrupt Support
This menu option opens a dialog that allows driver parameters relating to the interrupt support to be configured. These parameters are specific to the XVME CPU module being used.
Figure 3-17. Configure Interrupt Support dialog
Configure->PCI Memory Exclusions
This menu option opens a dialog that allows specified blocks of PCI memory address spaces to be reserved from being used by the driver. This may be necessary when third party drivers are installed which require certain areas of PCI memory space, and that space cannot be dynamically determined by the Xembedded driver.
Figure 3-18. PCI Memory Exclusions dialog
Help Menu
This menu lets you access the BSP help file and the About VMEman window, which displays version information for the VMEman executable, driver, and DLL.
In 1979, Motorola in the development of its new Motorola 68000 CPU, and one of its engineers, Jack Kister, decided on the creation of a standardized bus system for 68000-based systems, which he described as VERSAbus. He was later by John Black, of the specifications and refined the concept VERSAmodule product. Sven Rau and Max Lösel of Motorola Europe a mechanical specifications for the system, basing it on the Eurocard standard, was then late in the Standardisevaluation. TDas result was first known as E-VERSAbus but was later renamed the VMEbus for VERSAmodule Eurocard bus (although some call it Versa Module Europe).
At this point, a number of other companies involved in the ecosystem, 68,000 agreed to use the standard, including Signetics, Philips, Thomson, and Mostek. Soon, it was officially standardized by the IEC as IEC-821-VMEbus and IEEE and ANSI as ANSI / IEEE 1014-1987.
The original Standard was a 16-bit bus, which in the existing Euro-Card DIN connectors. However, there were numerous updates to the system allow a wider bus widths. The current VME64 contains a full 64-bit bus at 6-DB-size maps and 32-bit cards in 3-DB. The VME64 protocol of a typical performance of 40 MB / s. Other standards have hot-swapping (Plug and Play) in VME64x, smaller “IP” cards that plug into a single VMEbus card and various interconnect standards for linking VME systems.
In the late 1990s, synchronous protocols proved to be effective. The research project was VME320. The VITA Standards Organization called for a new standard for unmodified VME32/64 backplanes. The new protocol has been approved in 2eSST ANSI / VITA 1.5 in 1999.
Over the years, many extensions have been added to the VME interface, providing ’sideband’ channels of communication in parallel to VME itself. Some examples are IP Module, RACEway Interlink, SCSA, Gigabit Ethernet on VME64x Backplanes, PCI Express, RapidIO, StarFabric and InfiniBand.
VMEbus was also closely in the development of standards, and VXIbus
Excellent Tutorial!!!