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.

Phone us at 1-888-944-1942 or 1-734-975-0577 or at http://www.xembedded.com.

No related posts.

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

Related posts:

1. Press Release – XSRV, 1U Rugged Server

Part 2. XVMEStat in VMEman.

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.

Feel free to send your questions to support@xembedded.com.

Related posts:

1. Programming on the VMEBus with Xembedded Series

Xembedded, LLC.

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:

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:

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.

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.

Figure 3-19. VMEman Help menu

Related posts:

1. Programming on the VMEbus with Xembedded Part 2. XVMEStat in VMEman.

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

No related posts.