Follow us on Facebook
Follow us on Twitter
Signalogic on LinkedIn

MATLAB Technical Support

Case Incidents:


FTP Site Links:

Web Site Links:


Playback Function, Continuous

From: Jeff 
Subject: Re: DSP-Matlab
To: Dr. Zhe 
Cc: George 
Date: 04/12/00

Dr. Zhe-

>I understand that you have some DSP based Data Acquisition /Waveform
>generator systems which can be used with MATLAB.

This is correct.

>Could  you please give me some more details on them?  How does  the
>playback function work? Can it play continuously?

If you mean from MATLAB, yes it can play continuously, but depending strongly on 
the number of channels, sampling rate, and speed of host machine.  MATLAB is not 
known for speed; we have typically found that 5 to 20 kHz one-channel operation 
is the limit if MATLAB is handling the buffering, and if the MATLAB code is in a 
tight loop.  I have attached an example .m file that illustrates both continuous 
input and output from MATLAB.

We currently have several University customers who are using the DSPower-HwLib 
software + DSK C54x for lab setup, both for MATLAB interface and Visual C/C++ 
interface.  This can be DSK C542 or DSK C5402, which is similar to C549.  
Alternatively, Signalogic also has a SigC54x Development system which supports 
C549 processor.

We would suggest that you look at the following web pages:


The DSPower-HwLib software is popular with Universities because of its direct 
interface to DSP board from MATLAB, Visual C/C++, and Visual Basic.

For a list of current University customers using Signalogic software, please see 

Jeff Brower

Data Acquisition/Waveform Generator Systems

From: Jeff
Subject: Re: DSP-Matlab
To: Zhe
Cc: George
Date: 03/14/00


>I understand that you have some DSP based Data Acquisition /Waveform
>generator systems which can be used with MATLAB.
>Could  you please give me some more details on them?

What sample rate, number of channels, bits per channel (resolution) do you need?

Also, is this for control system, where sensitivity to delay between input and
output is high?  Or for acoustic/audio or other measurement system where some
input (and/or) output delay can be tolerated?

What type of real-time processing should be performed?  What should the DSP on
the board be doing, if anything?

The above questions can help us determine which of the many different types of
DSP/data acquisition boards supported under MATLAB, by the DSPower-HwLib
software, that we should send info to you about.  There any many types of boards
available, all supported under MATLAB, Visual C/C++, Visual Basic, and LabVIEW.
 Maximum sample rates range from 48 kHz to 40 MHz; number of channels per board
from 2 to 64.

>How does the playback function work? Can it play continuously?

Yes, it can play continuously.  You can call "turn key" MATLAB functions which
will continuously play out .wav or .tim files, or you can handle individual
buffers in MATLAB and send them to D/A channels using lower level functions.  In
the latter case, the maximum continuous real-time rate is usually about 5 kHz to
10 kHz.  In the former, the rate can be up to 200 kHz, depending on the type of
hardware being used.

Jeff Brower

Error While Running Mex-File

From: Jeff
Subject: Re: PC32 Boards Test (01-10-00)
To: Morgan
Cc: Yolanda
Date: 01/10/00


This is a surprise MATLAB problem; we have not seen it before.  The
DSPower-HwLib DLLs have worked reliably with MATLAB 5.x since 1997, including
enmgr32.dll.  But recently MathWorks has managed to break MATLAB a few times
where external Win32 DLLs are concerned, and we have had to do a work-around. 
It looks like this could be the case again.

Here are some suggestions:

  -can you temporarily use R11 (i.e. previous version of MATLAB)?  Do you still
   have R11 installed on another machine?  Do you still have R11 CD available?

  -we do not have R11.1 at Signalogic yet; it takes longer for 3rd parties
   to get updates.  Is it possible that you can send us your R11.1 CD and
   we can temporarily install it and debug this problem immediately? 
   We will send the CD back same-day after we install on Win98 machine.

  -returning '53' should be Ok in GetMVer.  Note that the return value is used
   prior to any DLL calls; make sure that hwtest1.m is executing the Win32 "load"
   commands; i.e. make sure the hwtest1.m code loads hwlib32.con, hwmgr32.con, etc.

Jeff Brower

On Mon, 10 Jan 2000, Morgan wrote:
>Mr. Jeff Brower:
>I received the new file (GetMVer.m) and replace the old one. The problem
>is still occurred. It doesn't look like it was the problem for GetMVer.m
>file I tried a couple things as following:
>- Force the output value from GetMVer.m to be '53' by modifying the file
>- Tried to run the commands piece by piece of Hwtest1.m program.
>I found out the problem is from the EnMgr32.dll. This Mex-type file is
>not accepted by Matlab.  See the following MATlLAB command line.
>Please send me the detail information about " EnMgr32.dll " file and let
>me know what can I do next.
>Best Regards
>--------    MATLAB Command Line -----------------------------
>     2
>Ľ enmgr32(DS_SHOWSTAT)
Error in ==> C:\WINDOWS\SYSTEM\EnMgr32.dll
>       Segmentation violation detected at Mon Jan 10 14:37:58 2000
>  MATLAB Version: (R11.1)
>  Operating System: Microsoft Windows 98
>  Window System:    Version 4.10 (Build 1998:      )
>Register State:
>  EAX = 025e9ef8  EBX = 025af6c0
>  ECX = 81650000  EDX = 81650000
>  ESI = 01b3d5ec  EDI = 01b3d7f0
>  EBP = 00000001  ESP = 01b3d3e4
>  EIP = 01b3d7f5  FLG = 00010246
>Stack Trace:
>This error was detected while a MEX-file was running.  If the MEX-file
>is not an official MathWorks function, please examine its source code
>for errors.  Please consult the MATLAB API Guide for information on
>debugging MEX-files.
>If it is an official MathWorks function, please
>follow these steps in reporting this problem to The MathWorks so
>that we have the best chance of correcting it:
>    1. Send us this crash report.  For your convenience, this information
>       has been recorded in: C:\WINDOWS\TEMP\matlab_crash_dump.45159
>    2. Provide a brief description of what you were doing when this
>       problem occurred.
>    3. If possible, include M-files, MEX-files, or MDL-files that aid
>       in reproducing it.
>    4. E-mail or FAX this information to us at:
>                  E-mail:
>                     FAX:   508-647-7201
>Thank you for your assistance.  Please save your workspace and restart
>MATLAB before continuing your work.

MATLAB-to-DSP Source Code Examples

From: Jeff
Subject: MATLAB-to-DSP source code examples
To: Michael
Cc: Hanh
Date: 01/01/99


Here are the MATLAB source code examples I mentioned.  These are what ships with
the DSPower-HwLib software.

Jeff Brower

Matlab Interface to Real Time DSP

From: Jeff
Subject: Re: Matlab Interface to Real Time DSP
To: Harvey
Cc: Hanh
Date: 01/05/99


>I carry out all my DSP algorithm development in Matlab. I am looking for
>software that will take my Matlab files and convert them into code that can
>be directly downloaded to a DSP chip.

>1) Do you produce such software.

Yes and no.  The DSPower-HwLib software does not convert or translate .m code
automatically.  However, it does:

  -allow direct access from MATLAB workspace to DSP, onchip and offchip
   SRAM, data acquisition (if the board has it)

  -download of standard COFF files (executable DSP program files) produced
   by Analog Devices, Motorola, Texas Inst, and Lucent Tech. vendor tools

  -provide numerous support functions; examples include board and DSP type
   interrogation, calculating nearest-fit sampling rate, IEEE-DSP

  -provide higher-level functions, such as continuous disk file acquisition
   with a single MATLAB call, stimulus & response measurement, advanced
   triggering options, etc.

  -provide DSP functions (FFT, digital filters, etc.)

  -provide DSP code debugging functions, like symbol (variable or buffer
   name) table look-up and access

  -allow access to onchip and offchip SRAM while the DSP code is running
   (which is NOT like JTAG, or standard debugger)

  -provide a framework for dynamically loading and running user-defined
   real-time C/asm DSP code, including simultaneous analog I/O
   processing, host-notification options, and various DSP/math functions

So the HwLib software is like an advanced DSP API accessible from within MATLAB.
But it does not convert your .m code.  Here are some important points about DSP

  -to generate DSP code and real-time processing which is not covered by
   the HwLib API, you still have to use the DSP vendor tools manually
   and create either COFF executable or library files which can be
   downloaded and used from the MATLAB environment

  -your efforts to convert code are facilitated by not having to leave
   the MATLAB workspace; for example, you can "move" segments of code onto
   the DSP by setting flags which either tell the DSP to do it, or continue
   to use MATLAB code.  Your existing MATLAB displays, GUI, file access,
   etc. does not change.

  -auto .m code conversion this is a project we are considering for 1999;
   we already have a product called DSPower-Block Diagram which generates
   real-time DSP code from signal flow diagrams

>2) Do you manufacture a DSP board  that will accept such converted code.

Yes, several, and we resell several.  It depends on what processor you need,
type of analog I/O, etc.  For some examples, see:

We need to know a lot more about your application before we can recommend
hardware types.
>3) Can we use one of your boards in one of our products or does it have to
>be in a PC

Either.  Some of our boards are intended for PC development, followed by
subsequent embedded use, such as the SigC44-PC/104 or SigC32-PC/104.  Others
have options for eventual stand-alone operation, such as the SigC32-2, which has
boot EEPROM site.

>4) With regard to you data capture boards is there enough processing power
>available for me to perform - say real time beamforming and signal
>detection etc.

Of course--depends on sampling rate, type of processor, number of processors,
etc.  We have a number of sonar and acoustic customers who do this with
single-DSP boards, for example 8-channel boards.  Please let us know if you want
some references.

Jeff Brower

Running Matlab Program File

From: Jeff
Subject: Re: Latest *.m file
To: James
Date: 01/16/99


>From the scope trace, it appears to pick up the output part
>way through the buffer.  I can say this because the sine wave in the buffer
>starts from zero and goes positive first.  Whereas what I see on the scope
>begins at zero but goes negative first.

This is because of the PC32.  It has inverting amplifiers, so the samples that
go to the D/A converter on the board get inverted before they hit the endplate

> From the scope trace, the end of
>the output does not stop at zero as is the case in the buffer data.

Insert the line:

  BufNum = 1 - BufNum;

before calling the LAST WaitForBuffer() function.  Without this you are asking
the program to wait for buffer 0 again, which is what the program just did.  The
next buffer will be 1, so you want to wait for buffer 1 to finish.  (Note:  for
continuous operation it repeats, and the next buffer will be 0.  Please go back
over my previous e-mails, where we discussed "double-buffer" and continuous

>Finally, the data that appears in the buffer (buf3) is not related to the
>analog waveform data that I see on the scope.

I can't find anything wrong with your GetMem input into buf3; it looks fine.
Please tell me exactly which pins on the PC32 endplate connector your input
signal is connected to.  The DSP code is taking input from input channel 0, so
this is what should be connected.  To test your channel 0 input, you can run the
DSPower-HwLib "Dscope" demo program--you should be able to see your input
clearly.  I assume your input is something different than the sine wave you are
sending out.

>In OPMODE = 6 case, I assume
>that the RunProcessor command simultaneously outputs a value from the
>stimulus buffer and inputs a value into the buffer I set up, buf3 in this

More or less.  The RunProcessor command starts a small program (DSP code)
running on the TI 'C32 processor which is on the PC32 board.  This DSP code
inputs a sample into its internal buffer 0 (located at TimBaseAddr) and outputs
a sample from its internal output buffer 0 (located at OutBaseAddr), then
another sample, then another, etc.  It does this for one "buffer size" which in
this case is 1000 samples.  Then it notifies the host that a buffer is done, and
switches over to its internal buffer 1.  In your case you have, ahead of time,
downloaded buf to output buffer 0, buf2 to output buffer 1, and are inputting
from input buffer 0 into buf3.  I hope this makes sense.

Jeff Brower

HWLIB Functions: DSPutMem

From: Yolanda
Subject: HWLIB functions
To: Michael
Date: 02/02/99 

Hi Michael,

For information on using HWLIB functions, please refer to
"Signalogic DSP software Reference Guide" which is shipped together with the
software.  You can also access Reference Guide on your PC from Start -> Programs
-> Signalogic DSP Software -> Reference Guide.

e.g. IEEEToDSP is equivalent to DSIEEEtoDSP in HWLIB functions.
     PutMem    is equivalent to DSPutMem in HWLIB functions.

Basically, in most cases, HWLIB functions are prefixed by "DS" as in DSPutMem,
DSIEEEToDSP.  When they are used in Matlab, usually the prefix is removed.  To
be sure, please look at the corresponding .m file.  For DSPutMem, it will be
PutMem.m, for DSIEEEToDSP it will be IEEEToDSP.m.

With Regards,

Setting Input Gain When Using HWLIB

From: Jeff
Subject: Re: Sig32C-8 board and software help
To: Jian
Date: 02/10/99


>Could you answer the following question for me?  I can't find clear
>information in the manual for the following question.
>How to set the input gain of all 8 channels when using HWlib?
>I guess I can use HWlib DSPutHVarMem(..,DSP_GAINLIST).
>But the manual only says DSP_GAINLIST is of 32 bits and 4 bits for each
>channel.  But what's meaning of these bits.  Is it in integer dB?  The
>program examples all use 0, is that mean all channels of 0dB?  Could you
>give me another example?

Look at the gain table on pg. 6-5 of the Sig32C System Guide.  Each table entry
is a gain value that corresponds to numbers 0-15; i.e. the first table value is
0, the second is 1, etc.  Thus, you put the table number corresponding to the
gain value you want into each 4-bit field in the DSP_GAINLIST property.  For
example, to specify 7.5 dB gain on channel 0, 20 dB gain on channel 1, and 40 dB
gain on channel 2, you would set the DSP_GAINLIST property to a value of:


The other channels would be set to 0 dB (gain of 1).  In MATLAB you would need
to enter decimal numbers, so remember to convert hex numbers like the above to
decimal first.

Jeff Brower

Parameters Used by MATLAB Calls

From: Jeff
To: Chris
Cc: Yolanda
Date: 02/26/99


>We can not find any reference to the parameters used by the MATLAB calls to
>interact with the board.  Is there suppose to be another set of
>documentation to provide some insight into these calls?

The MATLAB calls are, for the most part, the same as their C/C++ counterparts,
but without the "DS" prefix.  Please see the online Reference Guide; click on
"Function Reference", DLL Functions, then on Hardware Library, Engine Manager,
or Hardware Manager.  Alternatively, search for the function name, but be sure
to enter the "DS" prefix.

There are some MATLAB calls which are specific to MATLAB.  For example, the
C/C++ DSAcquireWvfrmFile call takes a pointer to a "CONVINFO" structure with
elements of various sizes, but in MATLAB this won't work.  So instead the
AcquireWvfrmFile call in MATLAB takes a "handle" and we have added calls to
support the handle, such as "AllocConvInfo", "SetConvInfoItem", and
"FreeConvInfo".   See hwtest1.m for an example of this.

In general, the hwtest?.m programs, combined with the Reference Guide, are the
best source of MATLAB documentation for the DSPower-HwLib software.

>Typically, with a TI board there is some type of configuration file
>designating the memory spaces on the board.  Do you have any documentation
>on this for the M44?

Did you receive an M44 Hardware Manual?  If so, then the memory space, from the
C44's perspective, is documented in this manul.  Briefly, the local SRAM on the
M44 board is located at 0x7fe00000, and the global SRAM is located at
0x80000000.  In its default configuration, the M44 has 128k x 32 local SRAM, and
128k x 32 global SRAM; the global SRAM can be expanded to 512k x 32 (I'm not
sure what is the configuration of the USCGA board).  The C44 boots from start of
local SRAM.  Since the PCI bus can transfer data to/from the global SRAM only,
Signalogic uses a "talker" program, which is stored in iim44hi.out, to act as
'traffic cop' and transparently direct memory transfers from the host to
whatever C44 address is required.  Thus, from a host program perspective, memory
starts at 0x7fe00000 and continues.


>Is there suppose to be another software package that comes with an AtoD
>converter?  While running one of the examples, an error reflecting an
>inability to find a .ADC file was returned.  I would guess that this has to
>do with some type of configuration file that is created by some software
>that comes with the AtoD module?  This is just a guess.  Is there any way to
>get this software now so that we can take the next couple of steps?

There is not another software package.  What we will be sending you are these

  -updated Hardware Manager DLL, which allows you to easily select
   which module is in which position on the M44 using the "DSP
   Analaog I/O Hardware Selector" dialog box that comes up

  -updated Hypersignal which accepts new M44 + module entry syntax
   (see comments below)

  -updated tms44iim.out and iim44hi.out files, which include the
   correct C44 code for the AIX module

>I could not find any reference to any of your AtoD boards in the Hypersignal
>package.  What am I suppose to enter in the setup configuration?  Right now,
>it is set at the default "NONE".

As examples, what should be entered is IIM44-AIX (AIX in slot 1), IIM44-AIX-AIX
(AIX modules in both slots), IIM44-A4D4-AIX (A4D4 in slot 1, AIX in slot 2),

Jeff Brower


From: Jeff
Subject: Re: AW: DSP Board and development software
To: Daniel
Cc: Heather
Date: 03/30/99


>I'm now almost ready to order a Board and the software, I also received the
>documentation.  I have 3 other questions:
>1) Talking about the matlab interface does this include links to SIMULINK ?

Yes and no.  If you use MATLAB blocks inside your SIMULINK diagram, then Ok, as
MATLAB code can make any call to board available in the DSPower-HwLib interface.
It is even possible to view waveform displays and C code variables in SIMULINK
blocks, as the DSP code is running, using this method.  But there is not
built-in support for Real-Time Workshop, although it is not hard to interface C
code generated by RTW to the underlying "C4x Source Code Interface" (SCI) which
I mentioned in my previous e-mail.  Please see my previous discussion of
user-defined C code, described on the page

>2) How can I configure the digital interface to a serial or parallel custom
>made ADC which requires a Mettler specific protocol? (does I need further
>tools like C compiler or can I manage it with the H8 rt sw, DSPower HwLib sw?)

You would need the C4x SCI, and Texas Inst. C Compiler/Asm/Linker. 
The SCI is fully compatible with the HSM and DSPower-HwLib software, so
changes you make to support analog I/O will "snap in" to high-level host
functions like digital scope, continuous disk acquisition, etc.  The C4x SCI
includes interrupt service routine (ISR) and analog I/O initialization examples
for other C4x boards (e.g. M44, PC44, Ariel DSP-C40, etc) so there are lots of
examples to go by when installing a custom analog I/O solution.  The technical
contacts here to support your efforts would be myself and Yolanda

Jeff Brower


From: Jeff
Subject: Re: DSP bug FIXED!
To: Anuradha
Date: 04/02/99


>Hi ! Hope you remember me ! You helped me solve a problem and here am
>I with another and would really appreciate if you could help me out. The
>program offered by signalogic allows us to collect and display the
>signals which arrive at the A/D and i would like to design it such that
>only when the TTL signal or a pulse occurs at the trigger pin of the A/D 
>,then the 2 signals are taken in and sampled and displayed ,otherwise
>the signals needn't be collected and we have to keep checking for a
>pulse in the trigger pin and only when a pulse is present then the 2
>signals are sampled and displayed.

In order to do this efficiently (i.e. in real-time), you have to modify the DSP
source code.  There is no way MATLAB can monitor the TTL signal and then
respond, unless you can tolerate delay between the TTL signal and acquisition or
several msec.  Real-time / DSP code implementation requires changing the "C3x
Source Code Interface" (SCI) software, which is the source code used by the PC32
board when the board is being controlled by MATLAB and C/C++ programs, via the
DSPower and Hypersignal software.

Jeff Brower

MATLAB with Windows

From: Yolanda
Subject: RE: Running Matlab programs in Windows
To: James
Date: 04/16/99

Hi James,

>I finally got some time last night to make the S1 switch setting changes
>from you last e-mail note.  After making the changes, and going through the
>configuration menu associated with the FFT program per the April 9 note, the
>digital scope program and others  in the main Windows menu seem to work. 

When you run any windows program (include Matlab .m files) with Signalogic
Software, usually the first thing that comes up is a Hardware Acquistition
selection dialog box, Please check that the settings are correct.  ie. You
should have highlighted Innovative Integration PC32 board, and the text field
should look like belows:

	Board Designator    : IIC32
	DSP Program File    : tms32ii.out
	I/O Base Addr       : 280
	Mem Base Addr       : DC00
	Processor Clock     : 60
	Voltage Ranges      : 10,10
	Number of Processor : 1

If for some reason, you do not see the Dialog box show up, please go back to
your .m files. Most likely, you have the following files commented out :

[fSelect, BoardStr]=ShowHwSelector(NULL);

>I then went to run the Matlab examples in the HWLIB directory, i.e. hwtest1.m
>through hwtest5.m and I got an initialization error (-12 code).  This is the
>same error message that I got earlier.  Do you have any ideas as to what is

When this occurs, can you look at the status windows and tell me everything that
is in it.  This will help me to identify your problem.

By the way, have you installed the software from CD yet?  which version of the
software are you using? The one that comes with your purchase order or the CD

Please furnish me with the following information:

>Please also let me know the date and
>size of the following files:



>Also, another question.  Did you put in any new hardware into your PC? 
>Sometimes the new hardware may conflict with other hardware that has been
>working on the PC.

Please also send me your config.sys file so I can check it for you.

please also send me your win.ini file and tell me where you have installed
HsMacro and DSPower.


Conversion of Matlab File to COFF File

From: Yolanda
Subject: Re: about matlab
To: xinhua
Date: 05/03/99

Hi Xinhua,

>I am a user of Dspower_hwlib and Hypersignal_Macro software.
>My serial number of Hypersignal_Macro is #991772. I want to know :
>Can I convert a matlab file ,which includes some special functions(of
>wavelet toolbox,e.t.),to a COFF file for my PC31 board (TMS320c31)? And How?
>Where can I get full information about this?

Conversion to C code (COFF file) is not automatic; we do not offer a program
that does this.  You can try something like MathWorks' converter, but the C code
doesn't come out in real-time format, with dual-buffering, analog input/output
interrupt routines, etc.  To solve this problem, the "C3x Source Code Interface"
(SCI) is popular.  For information on adding user-defined real-time C/asm code
to the framework provided by the SCI, please see:

With regards,

Simultaneously Read 2 A/D Channels

From: Yolanda
Subject: Re: MATLAB program
To: James
Date: 06/04/99

Hi James,

>Thanks for the help.  I got the board and hwtest6.m and tested them the
>other night.  Everything looks to be okay. 

Glad to hear that.

> First, I need to read "simultaneously" two A/D channels.  What modifications
>to the basic code you sent me would I have to make to accomplish this? 

You would need to change the CHANLIST variable.  Right now, it is set to 0 which
stands for channel 0.  If you want to use channel 0 and 1, you will set CHANLIST
to 0x10.  CHANLIST is divided into 4 bit fields.  each channel is 4 bits, with
channel 0 occupying the last 4 bits, channel 1 the next 4 bits and so on.

> Second, the main Matlab program is designed to send out several different wave
>forms (sine, ramp, user specified vector, etc.) under a user selectable GUI.  Is
>it possible to do the initialization and execute the run board functions during
>the first portion of the main program and not have to do this again when I
>send out the different wave forms? Likewise, only execute the closing of the
>board statements once when the main application is being closed down?   Your
>thoughts on these questions would be quite helpful.  Thanks again.

Yes. Definitely.  I would suggest you begin with user selecting the kind of
waveform they would like to send out, generate the data ahead of time, then
invoke the engine, init the board, download the generated waveform, run
processor for the desired period of time and then disabled the board, free the
board and close the engine and then your main application exit.

AS usual, since you are involved in a control system, it is always a good idea
to create a clean up rountine, which stop the board, free it and  close the
engine if some undesirable event should happens.


Debugging hwtest6a.m

From: Yolanda
Subject: RE: suggestion for debugging hwtest6a.m
To: James
Date: 06/21/99

Hi James,

>I finally had a chance to test the new DLL's last night.  Everything was
>going well for about 35 tries and then things started to fail again and the
>whole system "locked up" before the test program got to 50 tries.  Has
>anyone else with Matlab 5.2 and Windows 98 had similar problems?  I have to
>believe that anyone else who is outputting and reading data in a continuous
>way would have experienced similar behavior. 
>My client is asking me for an estimate of when I would be finished.  I'm not
>sure what to tell him as to when this current "road block" will be sorted.
>Thanks for your help.

Here are some suggestion for you.

1) Run Matlab 50 ++ times.  ie. just open MATLAB and then exit without running
any .M files.  See whether this will crash.

2) Run one of our demo program, e.g. DIGITAL scope (by clicking on the scope
icon in START -> Programs -> Signalogic DSP Software -> Digital Scope) 50 ++
times.  See whether this will crash.  I am just trying to see whether this is a
MATLAB issue or our DLL issue.

3) Then run Matlab, strip hwtest6a.m to its bare minimum like OpenEngine and
CloseEngine only.  Run it again 50++ times.
Does it crash?  Keep on  adding more calls until the crash appears.  It would be
important that we know where it crash or what is the actual call that causes the
crash for us to assist you efficiently.


H8 Port vs ONCE/JTAG Port for Access of Variables in MATLAB

From: Jeff
Subject: Re: DSP56307 inquiry
To: Ahikam
Date: 07/03/99


>Please clarify for me some of the points in your answer,


>In Order to use the DSPower - HWlib for accessing variables from matlab, do
>I really need the H8 port, can't I use the ONCE/JTAG port instead?

No.  The DSPower-HwLib MATLAB interface uses a "Toolbox"-like approach to access
several libraries (DLL and OCX) which in turn access either VxD driver (Win9x)
or kernel-mode driver (WinNT).  These drivers only "know" about HI08 port. Our
main problem with JTAG is speed--we cannot make large data transfers fast
enough, which is a problem because we advertise both the HwLib and DSPower
signal flow diagram software as "being able to monitor variables and display
waveforms/buffers as real-time code is executing".  For example, one of the
calls in the DSPower-HwLib interface is GetSymbolAddress, to allow dynamic
GetMem/PutMem type commands on C/asm variables and vectors.  Thus, HwLib is low
on classic debug functions, and high on data transfer and visualization. 
However, it should be noted that currently, at customer request (Ericsson), we
are adding software breakpoints, register readout, and some other debugging
constructs to the MATLAB interface.

>In my next board design (due 9.99) I can ask for H8 port to be connected
>(right now we donít use it),


>Will I need to make adjustment to my DSP563xx code in order to use your
>tools to access variables through matlab,

You would have to use the DSPower-HwLib driver HI command interface, or
adjust/merge yours to support the command vectors the drivers use (about 5 or
so).  Also, the command vectors rely on R7 being avaiable; for example, in the
DSPower-Real Time Code Generator, the generated C/asm code uses a switch to
avoid use of R7.

>If so will your code interface to TASKING'S EDE V2.1 ?

What is EDE V2.1?

Jeff Brower

Putting 16-bit wav Signal Onto Board

From: Jeff
Subject: Re: continuous output
To: David
Cc: Brian
Date: 07/22/98


>Got the 16-bit wavread (I actually wrote my own before yours got
>here) and it works.


>However, putting the signal onto the board seems to distort it. See if you
>follow what I'm doing ...

>PutMem(hBoard, DS_GM_LINEAR_DATA_RT, 	StimBaseAddr,
>	DS_GM_SIZE16_CVT, StimSig, StimSize);
>GetMem(hBoard, DS_GM_LINEAR_DATA_RT, StimBaseAddr,
>	DS_GM_SIZE16_CVT, StimSigBack , StimSize)

Questions:  what kind of data is in StimSig?  Data should range between -32768
and 32767, and be integer values.  Also, has StimSigBack been previously
declared/used?  If StimSigBack does not have enough "size" to handle StimSize
number of 64-bit floating-point values, then the GetMem call will return zero
(FALSE), or error condition.

Attached is a new version of hwtest3.m, which shows use of the _CVT attribute. 
I have tested it on MATLAB 5.  You can use either GM_LINEAR_DATA or
GM_LINEAR_DATA_RT.  The example is similar to your code above, so I'm not sure
what is wrong with your code.

>and the the two plots are completely different (same length,
>different signals). If I do a RunProcessor after these lines, I
>"hear" exactly what StimSigBack looks like

You are using MATLAB v4, correct?  Try the plot without calling Runprocessor. 
Do you still get distorted plot?

>It shouldn't be an IEEEtoDSP thing, since it's all integer data and not
>floating point.

Well, it is *integer values*, but still floating-point data.  MATLAB only works
with 64-bit floating-point data--what values you put into MATLAB arrays is up to

Jeff Brower

Listen to Speech using Dscope.m File

From: Jeff
Subject: Re: Few technical questions from ASU
To: Erfan
Date: 10/19/98

Erfan -

>To refresh your memory I'll try to explain the current problems that we've been
>having. In order to see the speech that is input to the board in real time we
>have been using "dscope.m" file. We were trying to add some features to that
>so that we could listen to the speech as well. We were taking help from the
>"RT c code.cpp" and "HWtest(4-5).m".

Be careful with dscope.m program.  This program currently works only with MATLAB
v4.2x, because it uses callback messages for buffer ready.  With v4.2x, a
"hidden child control" is used to provide the window handle needed by
DSPower-HwLib to send messages, but this is tricky and does some
behind-the-scenes window stuff.  In v5.x MATLAB, this is not as easy, and the
callback messages do not work.

>We have noticed that that different opmodes were used at different times. So
>we tried with different opmodes(6 &1) in the dscope program, but none of them 
>seemed to work. We have also looked at the reference guide, but it doesnt
>tell a whole lot about opmodes.

Look at the DSP Source Code Interface sections in the Users Guide ("Using DSP
Source Code Interface Software" in table of contents, click on TMS320C3x
section, then first "Main Topic").

Mode 1 is continuous output, mode 6 is continuous input/output.  Mode 6 is what
you want if you want to both visualize speech input and hear it.

>We do not expect you to write the entire code for us, but if you could mention
>what changes to make in a hwtest.m or dscope.m file so that we could listen
>to the speech as well as see it in time domain (dscope), it would be very
>helpful. We cannot go any further in our project if we cannot listen to the
>input speech in real time using MATLAB.

Have you successfully run the rtcode.cpp program?  Without DSP source code
changes, the default mode for this program is analog I/O loopback, with input
being displayed onscreen.  My suggestion is to take this program, combine with
hwtest5.m to make a new .m program, and make sure all PutVarMem calls in
rtcode.cpp are reproduced in the new .m program.  All DSP code properties need
to be set as they are in rtcode.cpp.  The main difference is that instead of a
callback message for buffer-ready (i.e. WM_DSPENGINE_BUFRDY message processing),
you should use a while-loop, with GetMem calls.

If you use one channel at 8 kHz sampling rate, it *may* be possible to do some
simple .m code processing on the speech buffers in real-time.  In this case,
your while-loop would also use PutMem calls, and I would suggest a buffer size
of at least 8k, and maybe even 12k.  If you decide to do this, please let me
know, there is more example .m code I can send to you.  However, please note
that for more channels, higher sampling rate, and/or significant real-time
processing, you will need to do it on the DSP.

Note also that when using op. mode 6, as in rtcode.cpp, you can add user-defined
real-time C code to the DSP.  For example, you could apply filters,
compression-decompression, or other speech processing and hear the results in
real-time.  You could use the .m program to control what the DSP is doing; for
example to set filter coefficients, change variable/parameter values, etc.  For
more information on this method, please see

Jeff Brower

DSP Option Definations, A/D and D/A Operations

From: Jeff
Subject: Re: DSP_XXXXX definations
To: Hal
Date: 08/24/98


>1. I still need specific infomation on the DSP option definations
>the Reference quide is too general ie. for DSP_OPMODE it says
>"Specifies processing or analog I/O function operating mode to Hypersignal
>DSP sorce code interface"

In the Users Guide help file, see section "Using DSP Source Code Interface", and
under that, "TMS320C3x Source Code Interface".  The first three (3) 'Main
Topics' provide more explanation about the operating mode and general
organization of the DSP Source Code Interface (SCI) software for C3x-based

>I sort of know that from the sample code, what I need is the list of options.
>(for all the defines ie DSP_FILTTYPE etc). Is there a mode to do both A/D
>and D/A (see below)?

Yes, mode 6.  Mode 6 is continuous input and output; it is up to host code to
read the input buffers and supply new output buffers.  My suggestion is to start
with hwtest4.m and hwtest5.m examples, but use mode 6.  Also, I am asking the
other customer I previously mentioned about getting some excerpts from their
mode 6 MATLAB code.

>I could not find the t30def.asm reference that you also mentioned.

It should be on the "TMS320C3x Source Code Interface Software" disk.  It's
possible that wasn't ordered.  The main purposes of the SCI are:

  -to allow additions and modifications to DSP code while maintaining DSPower
   and/or Hypersignal compatibility

  -provide analog init. and interrupt service routine code for specific boards

  -provide basic DSP/math library functions

>2. How can I run (from matlab) both A/D and D/A operation ie. acquire data,
>do something with it then send it back out then repeat ? This seems like a
>reasonable sequence of operations for a DSP board.

Jeff Brower

To Output Long Random Signal Past Buffer of 8192

From: Jeff
Subject: Re: Continious operation from Matlab
To: Hal
Date: 08/20/98


>We got the new software and the MAtlab demos run OK on Version 5.2. Thanks


>I want to output a long random signal from the D/A but your HWTest4.m
>sample only outputs a short buffer. I cannot seem to make it work past 8192.

In mode 1 "continuous output" (which is used by hwtest4.m), you must set the
DSP_BUFLEN property to control the length of output.

>The code mentions that to operate continiously I need to use the "BUFFER
>READY" callback messages and the RegMsgWnd and WaitForBuffer functions must
>be used.

First, what is your sampling rate?  MATLAB is not fast, and so achieving
real-time or continuous operation above 8 kHz might not be possible in any case.
Second, registering window handles and using callback functions in MATLAB v5.x
(RegMsgWnd) is not easy and we are still having problems with that, so try
instead putting the example code in a loop; for example after doing the PutMem
(output) line, then use WaitForBuffer(..., DS_WFB_POLLED), and then loop back to
another PutMem statement.  Of course, if the output samples must change you need
other statements in this loop which calculate (or read from file) the new
samples--and therein is where MATLAB slows down.

>Any specific examples ?

I may be able get a modified hwtest4.m example for you which has looping
operation.  It's from another customer; I'll have to check first.

>I guess the same sort of thing is true for continiuos A/D operation.

Yes, but the mode is 0 and the WaitForBuffer call goes first, and then you use a
GetMem call to read acquired samples from the board.  See hwtest5.m.

>How do I find out more about the DSP board options/ flags:
>   ie. DSP_OPMODE
>       ETC.

Two ways:  a) you can look at the descriptions in the Signalogic DSP Software
Reference Guide (refguide.hlp; see DSP/Analog Hardware Reference section, DSP
Variables or DSP Properties subsection), and b) you can look at the t30def.asm
section in the C3x Source Code Interface (SCI) software, which is where these
properties are defined in the DSP source code.

For more information about the SCI, see Using DSP Source Code Interface Software
in the SDS Users Guide (useguide.hlp).

Jeff Brower

Stimulus-Response using MATLAB

Date: Wed, 28 Jan 1998 22:35:52 GMT
From: Jeff
Subject: Re: HWLib question
To: David


>In all of the examples (dscope.m, hwtest1.m, etc) , you seem to be
>registering a MSWindows window handle as the recipient of the DSPEngine
>callback messages. Great for "real-time" c programs, but we don't want to do
>that. We simply want to do the following stimulus-response things
>sequentially ... download a short stimulus signal (white noise) onto the
>board's memory, and then play it while sampling the response of all 4
>channels into 4 MATLAB variables. We don't want to be continuously updating
>some display window, like dscope does. We don't need asynchronus operation -
>we're happy to wait in a "while loop" until the buffers fill up and the 4
>variables get their info.

OK, then use a WaitForBuffer call with the polled method, as in hwtest2.m.
This should work at low samplng rates.  To do stimulus and response, you need
mode 6 (instead of mode 2), and you need to download (PutMem) the output
(stimulus) data in advance.  I think you can do a GetVarMem(hBoard,
DSP_STIMDATADDR) call to get the base address of the stimulus memory buffer
(very similar to what is done for the input buffer).

>How can we "register" something else other than a window to find out when the
>buffers are ready, or to put it in another way, what flag can we check to find
>out when the acquisition has been completed ?

Don't register, just use DSWaitForBuffer, as in the hwtest2.m example, but put
in a loop; after each buffer is ready, you need to do a GetMem.  Remember that
the buffers will switch, so the first GetMem is at input base addr, the second
is at input base addr + buffer length, and then it repeats.

>And then how does the data get from the board's buffers into the MATLAB variables? 
There must be some HWLib calls to do this.



Multichannel Acquisition in MATLAB

From: Jeff
Subject: Re: multichannel acquisition in MATLAB
To: John


>I tried the things you said but I am sure I am not doing them in the correct
>place or maybe I'm doing them right at all.  When I change DSP_NUMCHAN = 2,
>it does go faster but I am not sure exactly how to extract the data or
>whether the second channel is even there.  Do I need to change the bit-width
>constant from DS_GM_SIZE16_CVT to maybe DS_GM_SIZE32_CVT?

No, don't change that!

>I try that and it
>pretty much doesn't collect anything.  What about changing the DSP_NUMCHAN
>in the hwlib32.con file or just in the program?

No, don't change that!

All you have to do for 2 channels is use every other sample in the MATLAB buffer
that you read.  I.e.

  buf[1]    -->  1st sample, 1st trace
  buf[2]    -->  1st sample, 2nd trace
  buf[3]    -->  2nd sample, 1st trace
  buf[4]    -->  2nd sample, 2nd trace
  buf[5]    -->  3rd sample, 1st trace
  buf[6]    -->  3rd sample, 2nd trace
  buf[N-1]  -->  last sample, 1st trace
  buf[N]    -->  last sample, 2nd trace

Where N is the value you have assigned to the DSP_BUFLEN property during
initialization.  Is that Ok?  This is what we mean by interleaved, or
"multiplexed" acquisition buffers.  If you are using M channels, i.e. more than
2 traces (channels), then the interleaving pattern repeats in groups of M buffer

Please keep in mind what I mentioned previously:  you may want to read twice as
many points in the GetMem() call if you are using 2 channels -- this will
maintain the same receive-buffer rate.

>Sorry for all the questions.  There are just so many ways to grab and store
>digitized data.  I am sure that I can understand it, I just need to get the
>basics down.  I can understand that the DSP board is digitizing audio data
>at the requested rate.  If I run the strip program, I see my data on both
>channels.  So, does the board put the first channel in the first 4 bytes,
>the second channel in the second 4 bytes and so on?  Does that mean I need
>to read 32 bits at a time in order to get the data?  I'm still a bit fuzzy on it.

Don't worry about reading in bytes.  In MATLAB, the GetMem() function call with
the DS_GM_SIZE16_CVT attribute reads the DSP acquisition buffers in samples, and
converts data on the fly to MATLAB 64-bit floating-point format.  All you have
to do is access the buffer correctly.  John, I have to say I think you're making
this too hard ;-)

> What do the strange numbers mean in the hwlib32.con file for the DSP
>and DS variables.  It loads in 1115 for DSP_NUMCHAN which, to me, doesn't
>mean 1,2, or whatever number of channels.  All those variables have large

These are constants that translate in some weird way to physical memory
addresses inside the on-board DSP memory.

> I also tried changing the OPMODE to 0 instead of 2 (0 is what the
>strip chart had but the oscope had 2).

Built-in operation modes are explained in the DSP Source Code Interface section
of the online DSPower Software Users Guide (there should be a Users Guide
standard Windows help file in the "Signalogic DSP Software" folder).  I think
this is chapter 5, titled "Using DSP Source Code Interface Software" or similar.
Operation mode 2 is digital scope, which uses fixed-frame based acquisition,
with pauses between the frames controlled by trigger parameters.  Operation mode
0 is continuous acquisition, with no gaps.  Mode 0 can handle N channels; mode 2
is limited to 2 channels.

Jeff Brower

General Discussion of DirectDSP Software Approach

From: Jeff Brower
Subject: general discussion of DirectDSP software approach
To: Milan


>Is it possible to program Your Boards in a high level Language or even
>Matlab real time workshop alt. Labwiev RT ?
>Do You recommend this type of approach to program the board?

DirectDSP software allows MATLAB programs and LabVIEW VIs to communicate with
the DSP processor and board resources, download executable DSP code, control the
board, "interrogate" the board for capabilities (sampling rate, memory
architecture, etc), set properties in the DSP data and code, and transfer data
to/from the onchip DSP and board memory.  Communication with the DSP and memory
can occur while the processor continues to run in real-time; i.e. the processor
does not have to be stopped or paused, and DSP code does not have to be
"instrumented" or otherwise altered.

But, DirectDSP does not allow you to "re-compile" MATLAB programs or LabVIEW VIs
and turn them into real-time DSP code.  To create executable DSP code, you have
to create and/or port MATLAB simulations in C code and compile and link using
the Texas Instruments Code Composer Studio (CCS) tools.  Signalogic provides the
DSP Source Code Interface software for this purpose, which is a DSP code
framework with basic board drivers (and analog I/O module drivers) and host
interface, and includes example CCS projects and source code.  Although not a
"MATLAB compiler", DirectDSP does make it possible to move MATLAB simulations to
real-time using a step-by-step approach; i.e. you can get part of a MATLAB
program running on the DSP, and leave other parts (displays, file storage, etc)
as-is.  When running an algorithm section on the DSP board, it becomes mainly a
case of downloading data to the board and waiting for results to come back; a
more sophisticated host program might use callback functions to receive "data
ready" notifications from the board in order to allow parallel host and DSP
board processing.  Also, some of our customers use flags to switch back and
forth between running parts or all of a MATLAB program on the DSP board and on
the host.

I've included an API summary, detailed reference, and source code examples
showing how the API is used.

When accessing onchip DSP or onboard memory, the DSPutMem, DSGetMem, and
DSGetSymbolAddress functions are typically used.  The DSPxxxMem functions allow
parameters to be set, or results to be read, in the DSP C/asm source code at any
time, while code runs in real-time.  The DSGetSymbolAddress function allows DSP
data/results to be accessed by symbol name (e.g. variables, arrays, buffers, in
C/asm source code); these "physical addresses" are gathered at run-time, during
host program initialization.  The DirectDSP API supports callback functions, for
example, when analog input buffers are available from the DSP software.

Jeff Brower

Basic CCS Project on Signalogic CD question

Subject: RE: [Fwd: Basic CCS Project on Signalogic CD question]
Date: Wed, 27 Nov 2002 15:15:41 -0600
From: Hanzi
To: Dr. Cap

Hi Dr. Cap,

I am sending you a Matlab example that will solve your question.  It is a
modified version of hwtest6 with extra functionality of GetSymbolAddress.
Basically, you can define your filter coefficient as an global variable in
SCI and use GetSymbolAddress to retrieve the address of that variable in DSP
memory.  You read and write to it by using GetMem and PutMem function.  In
the attached code example, the global variable inside DSP code would be aa
and we do GetSymbolAddress on aa (note that the assembler always append a
'_' in front of the variables defined in C and Case matters).  PutMem and
GetMem last parameter specified number of elements, so it can be number of
filter coefficient and aa can be an array.

ptr_aa = GetSymbolAddress(hBoard, NULL, "_aa");

DSGetMem(hBoard, DS_GM_LINEAR_DATA, ptr_aa, DS_GM_SIZE32_CVT, aa, 1);

aa = 123;
DSPutMem(hBoard, DS_GM_LINEAR_DATA, ptr_aa, DS_GM_SIZE32_CVT, aa, 1);


-----Original Message-----
From: Dr. Cap
Sent: Wednesday, November 20, 2002 12:53 PM
To: Dave, Hanzi
Subject: RE: [Fwd: Basic CCS Project on Signalogic CD question]

Hi Hanzi,

I spent some more time working on dspTeam01.m, which is our streamlined version of
hwtest6.m.  A lot of the housekeeping chores of selecting a board, getting a board
handle,etc, have been placed in a new m-file called HouseKeeping.m which is called
from within dspTeam01.m.  A paper copy of this file is sitting in the DSP lab
right next to the PC.  The directory where it can be found is E:\dspTeam.

Hwtest6.m has a lot of general code that was written to be compatible on a
wide variety of machines and to be able to select from a lot of different
DSP boards.  I went through and eliminated a lot of the choices we don't
need, because we are using only ONE type of board.  This makes the
housekeeping and other parts of the code more streamlined for out
particular combination of PC, MATLAB version, and DSP board type.

The results from dspTeam01.m and hwtest6.m are now exactly the
same.  So, we can now begin concentrating on modifying this code (dspTeam02.m) to work
with UserProc.c and whatever particular algorithms we need to write.  This
also requires more knowledge and experience with CCS.  I tried to begin
learning about CCS and UserProc.c last Sunday, but got stuck with
delays in getting dspTest01.m to match the results of hwtest6.m.

Any thoughts on what specific "hands on" CCS stuff we should immediately
focus on?  Any specific project file, with specific results?

For example, we want to:

Write a UserProc.c (compiled as FIR3rd.out) file that performs

y[n] = h[0]*x[n] + h[1]*x[n-1] + h[2]*x[n-2]

where h[n] is a vector array of FIR filter coefficients sent from
the Host to FIR3rd.out on the Target.

So, besides sending data x[n] from Host to Target, we want to
send vector array h[n] from Host to Target.

How do we modify the simple example of user-defined real-time 'C' code
"Signal Arithmetic Example - FIR Filter" to do this?

Dr. Cap