Path: news.mathworks.com!newsfeed-00.mathworks.com!panix!bloom-beacon.mit.edu!llnews!53ab2750!not-for-mail
Newsgroups: comp.soft-sys.matlab
Subject: Re: reading binary file from mexFunction
References: <fc1fri$au3$1@fred.mathworks.com> <fc1r8j$iql$1@fred.mathworks.com> <fc6kvd$1ul$1@fred.mathworks.com> <muymyvtnkj8.fsf@G99-Boettcher.llan.ll.mit.edu> <fc7ai3$hu8$1@fred.mathworks.com> <muyr6l4m1rn.fsf@G99-Boettcher.llan.ll.mit.edu> <fc9ivs$odj$1@fred.mathworks.com>
From: Peter Boettcher <boettcher@ll.mit.edu>
Message-ID: <muyabrrmwmj.fsf@G99-Boettcher.llan.ll.mit.edu>
Organization: MIT Lincoln Laboratory
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.0 (gnu/linux)
Cancel-Lock: sha1:QFPROuwgq1HcC3ztESEhUZwmOgY=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 74
Date: Wed, 12 Sep 2007 16:55:48 -0400
NNTP-Posting-Host: 155.34.163.114
X-Complaints-To: news@ll.mit.edu
X-Trace: llnews 1189630227 155.34.163.114 (Wed, 12 Sep 2007 16:50:27 EDT)
NNTP-Posting-Date: Wed, 12 Sep 2007 16:50:27 EDT
Xref: news.mathworks.com comp.soft-sys.matlab:428182


"basudha pradhan" <lucky_faith_911@hotmail.com> writes:

> Thanks Peter. It works now. That mex function was for 
> decoder. I have mex function for encoder . The encoder runs 
> ok in C but when i call it from matlab, the encoded file is 
> not right. So i am guessing my mex function is bad. 
>
> input to the mex function is char array(input_buf). then it 
> call C subroutine where it pass this input_buf and buflen
> (length of input). C subroutine process the input and write 
> the output to a file. So there is no output variable for 
> mex function. this is what i tried. 

OK, makes sense.

> void mexFunction(int nlhs, mxArray *plhs[],
>                  int nrhs, const mxArray *prhs[])
> {
>    char *input_buf; 
>    int buflen;
>    int status;  
>      
>    /* Check for proper number of arguments. */
>   if (nrhs != 1) 
>     mexErrMsgTxt("One input required.");
>   
>     
>   /* Input must be a string. */
>   if (mxIsChar(prhs[0]) != 1)
>     mexErrMsgTxt("Input must be a string.");
>
>   /* Input must be a row vector. */
>   if (mxGetM(prhs[0]) != 1)
>     mexErrMsgTxt("Input must be a row vector.");

All good.

>   /* Get the length of the input string. */
>   buflen = (mxGetM(prhs[0]) * mxGetN(prhs[0])) + 1;

Good.  mxGetNumberOfElements() is a shortcut.

>   /* Allocate memory for input strings. */
>   input_buf = mxCalloc(buflen, sizeof(char));
>   
>   /* Copy the string data from prhs[0] into a C string 
>    * input_buf. */
>   status = mxGetString(prhs[0], input_buf, buflen);

OK.  MATLAB strings are funny.  They are stored internally as 16-bit,
which is why you use mxGetString.  In fact, I'd say this should work.
But, since what you probably really want to send is 8-bit ASCII
characters, the whole thing will be more efficient (and may work!) if
you cast the MATLAB string to an explicit integer type: uint8.

Then, you can use mxGetData(prhs[0]) just like mxGetPr() to grab a
pointer to the actual data, and process directly from there.  That
means skip mxCalloc, mxGetString, etc.

>   if (status != 0) 
>     mexWarnMsgTxt("Not enough space. String is 
> truncated.");    
>       
>     /* Call the C subroutine. */
>   MQ_enc(input_buf, buflen);
>   mxFree(input_buf);
> }

You might want to do some debugging by dumping the first and last 16
bytes of your input_buf before you call MQ_enc, and compare that to
your straight C version.  Or even dump the full contents of input_buf
to a file in both places and compare.

-Peter