MESi software products are packages in an InstallShield^® self-extracting file and available for download from the MESi server, or delivered via an encrypted email attachment with a .EX$ extension. This will avoid problems with virus and intrusion detection software that may be running on your machine. Follow these simple steps to extract the software products:

1. Save the delivery file to a temporary location and, if necessary, change the extension to .EXE either by right-clicking and choose rename, or use the command-line "rename" utility. For example, your delivery attachment might be named MESI_002.EX$ which you would rename to MESI_002.EXE.

2. Execute the InstallShield^® Wizard by double-clicking the delivery file or by executing it directly in a command-line window. This will start the extraction process.

3. The InstallShield^® Wizard displays the MESi EULA and prompts for acceptance of the License terms. You should read terms of the EULA and proceed only if you agree. Otherwise, please return the products to MESi and let us know how we can help with any difficulty.

4. The InstallShield^® Wizard then prompts for a password, which is usually supplied by mail, fax, of voice form - never in an email. Be sure to enter the password exactly as it is case-sensitive. If you do not have a password or have lost your password, please contact MESi and we will re-supply it.

5. The InstallShield^® Wizard next prompts for a location to save the files. This is the root directory into which the software source and Object products will be placed. The default directory name is \MESi but you may wish to change it for convenience.

6. Click "Finish" after the InstallShield^® Wizard has completed the extraction and you're ready to work with the products

Please click on the links below for details on Component, LRDM, and Legacy product deliveries.

[Components][LRDM][Legacy]

Component Delivery

MESi Components are shipped either in Source code or Object code formats for various target devices. C Source files with .c or .h extensions, are placed in a csrc directory. Assembly Source files with .asm, .dsp, .s, or .inc extensions are placed in a relevant assembly directory. Examples include c5400 for Texas Instruments TMS320C5400 family DSPs, BF53x for Analog Devices ADSP-BF53x BlackFin family DSPs, ZSP400 for LSI Logic ZSP400 family DSP, etc. Object code files with .obj, .doj, or .o extensions are placed in the directory that corresponds to the Source code that produced them. Also included in each source directory is a test file called "release.txt" which contains a chronological listing of all modifications made to any source files. The most recent release is at the top of the file, and modifications are numbered and dated in chronologically ascending order (i.e. first mod to that release listed first)  It's always recommended that you to review release.txt upon receipt of any software updates to determine if modifications have any impact on your use.

Under each source code directory there are usually one or more 'demo' sub-directories that contain simple demonstration programs to show you how the component might be used. For example, a popular application for the GenDet component includes generic call progress tone detection for tones such as dial tone, ringing, and busy. We've created a simple C source  demonstration called cptddemo.c and located it under the csrc directory in a directory called cptddemo. This demo can then be built in that sub-directory under Borlanc C to create a DOS file I/O demo that generates sample output and logs status. In addition, the same C source is then used to build real-time demos for various commercial DSP target boards, such as the Texas Instruments C5402 DSK or the Analog Devices ADSP-21353 EZ-LITE boards. These DSP real-time demos are located in corresponding sub-directories located under the relevant DSP directory, as shown below:

Each component demo subdirectory contains a makefile (makefile or *.mak), a command-line options file (*.opt), and a linker command file (*.cmd) or linker description file (*.ldf). These files, along with the C source, assembly source, or Object code modules in the higher directories, allow you to build the demo using the vendor's compiler/assembler/linker tools on the command line using Borland's MAKE^® and Microsoft's NMAKE^® utility. Alternatively, you can convert the makefiles to DOS batch files, or use them to indirectly create IDE projects for Texas Instruments Code Composer Studio^®, Analog Devices VisualDSP^®, etc. You can determine the required path information, symbol definitions (i.e. -d assembler/compiler option), and link list from the makefile, options file, and linker description/command file.

BUILDING EXECUTABLE FROM COMMAND-LINE

The typical command-line procedure to build an executable from C or Assembly Source code products is to just run the MAKE utility without any arguments, in the demo subdirectory. For example, to build cptddemo for c5400  DSP you would run :

    c:\MESi\components\modems\c5400\cptddemo\make

The tools will compile/assemble\link from source files and place the executable in the cptddemo subdirectory. If you purchased Object Code modules, then specify them on the command-line for Borland and Microsoft as:

    c:\MESi\components\modems\c5400\cptddemo\make -DOBJ

    c:\MESi\components\modems\c5400\cptddemo\nmake OBJ=1

CONVERTING TO INTEGRATED DEVELOPMENT ENVIRONMENTS

Most vendors offer an Integrated Development Environment (IDE) for their development tools, such as Code Composer Studio^® from Texas Instruments, or VisualDSP^® from Analog Devices. Migrating from command-line makefiles to a project under these environments requires a few basic steps:

1. Create the project in the IDE

2. Add the source and/or object files from the MESi delivery directories.

3. Add the MESi linker description command files. If your tool does not permit more than one linker definitions/command file then you will need to merge the MESi LDF or CMD files into one.

4. Locate and add the MESi compiler/assembler options file with a *.opt file name under "compiler additional options", or "compiler files", or other method for inserting a file in the compiler AND assembler command line. If the tool does not support command-line options files (i.e. a @filename or -@filename), then you will need to manually transfer the definitions in the *.opt file to the appropriate entry for the tool. For example, the "-DDUMP_LEN=10000" symbol definition in cptddemo.opt would need to be added as a preprocessor definition in VisualDSP^®.

5. Add run-time library support as required.

6. Build and run from within the IDE.

It is strongly recommended that you avoid moving MESi Objects or Source files from their delivered subdirectories as this can cause name-space collisions (i.e. files with the same name but different directories get copied over). MESi deliveries use makefiles and relative paths to maintain portability and support build automation, and moving the products also makes maintenance difficult when receiving updates.

Low Rate Data Modem System Delivery

Legacy Delivery Zipfiles

MESi software products were delivered in an encrypted, zipfile (*.zip) format either as an email attachment or on a floppy disk (if requested).  The decryption key is delivered by an alternate means - either by voice, fax, or postal mail - and is unique to your delivery. This added level of security protects MESi from software theft, but also protects you from unauthorized access to your technology as well. You can visit  http://www.pkware.com to download pkunzip if needed.

When you receive your software (example: WXYZ_001.zip) and your decryption key (example 1234abcD), then the procedure is:

1. Open a DOS^® window
2. use pkunzip to unzip the delivery zipfile with the -d and -s<decryption key> options. For example:
               c:\pkunzip WXYZ_001 -d -s1234abcD

The -s specifies a decryption key, and 1234abcD in the example is the decryption key and it is case-sensitive. The -d causes one or more subdirectories (such as \CSRC, \TI-C54x, \AD21XX, etc.) to be created, and non-encrypted zipfiles (such as csrc.zip, c54x.zip, 21xx.zip, etc.) to be placed in them.   

The non-encrypted zipfile always includes a MAKEFILE suitable for use with Borland's MAKE^® and Microsoft's NMAKE^®. You simply type:

c:\make                        (Borland)
c:\nmake                      (Microsoft)

For C Source deliveries, this will build vsim.exe under the Borland C Compiler, bcc.exe. You may need to add egavga.obj to your graphics.lib library by executing the Borland utilities bgiobj and tlib:

1. bgiobj egavga                                     (this creates egavga.obj)
2. tlib graphics.lib +egavga.obj                 (this adds egavga.obj to your graphics library)

For DSP deliveries, there are generally two types of builds available: a digital loopback demo with no target dependency, and a real-time executable for specific hardware boards that we support. To avoid confusion with Code Composer^® project makefiles, we supply makefiles without the .mak extension:

• vfax - this will compile, assemble, link, and build an executable that sequentially executes the fax modems (v.21, v.27, v.29, and v.17) in a digital loopback if the -dDIGITAL_LOOPBACK command line define is present for the vfax.c compiler.  If -dDIGITAL_LOOPBACK is not present, then vfax will build to operate in real time on the target board specified for the c54x.c driver.  For example, on the Analog Devices 2181 EZ-KIT the modem signals will come from the left speaker jack, and you should loop them back into the left mic input.
• vdata - this will compile, assemble, link, and build an executable that can make real-time v32bis/v22bis CALL or ANSwer mode connections with a commercial modem.  For boards without a phone line interface, you'll need a Quick-and-Dirty interface and a telephone to dial with.
• vdata2 - this will compile, assemble, link, and build an executable that implements both the CALL and ANSwer channels for a v32bis or v22bis data connection in digital loopback. This is a very useful tool for starters because it shows you every step of the training process for both sides of a v32bis or v22bis in a format where you can start and stop without real-time constraints.   Thus it forms a reference that you can first run to see what the modem signals and states are supposed to look like prior to trying to work with real-time signals. In addition, the 8 kHz samples produced by vdata2 are identical to those output from vsim when simulating v32bis or v22bis.

The MAKEFILE shipped with DSP deliveries depends on the components that you selected, and it generally builds a real-time executable similar to vdata such as "v32demo" or "dtmfdemo".