f



converting C/Visual BASIC code to MATLAB

I'm trying to convert some vendor provided C and/or Visual BASIC code into MATLAB, so that MATLAB can utilize a driver that can interface a camera.

Three questions:

1.  How do I convert global constants into MATLAB?

For example:
/* C */
#define CE_ERROR_BASE 1

' Visual BASIC
Global Const CE_ERROR_BASE = 1

% MATLAB
??????

2.  How do I convert "typedef struct"  into MATLAB?

For example:
/* C */
typedef struct {
  unsigned short cameraFound;
  unsigned short /* CAMERA_TYPE */ cameraType;
  char name[64];
  char serialNumber[10];
} QUERY_USB_INFO;
typedef struct {
  unsigned short camerasFound;
  QUERY_USB_INFO usbInfo[4];
} QueryUSBResults;

' Visual Basic
Type QUERY_USB_INFO
  cameraFound As Integer
  cameraType As Integer ' CAMERA_TYPE
  name As String * 64
  serialNumber As String * 10
End Type
Type QueryUSBResults
  camerasFound As Integer
  usbInfo(0 To 3) As QUERY_USB_INFO
End Type

% MATLAB
??????


3.  How do I do an external driver function declaration?

For example:
Assume SBIGUnivDrvCommand is defined in the driver file.

/* C */
#if TARGET == ENV_WIN
  #ifdef __cplusplus
    extern "C" short __stdcall SBIGUnivDrvCommand(short command, void *Params, void *Results);
  #else
    extern short __stdcall SBIGUnivDrvCommand(short command, void *Params, void *Results);
  #endif
#else
  #ifdef __cplusplus
    extern "C" short SBIGUnivDrvCommand(short command, void *Params, void *Results);
  #else
    extern short SBIGUnivDrvCommand(short command, void *Params, void *Results);
  #endif
#endif

' Visual BASIC
Declare Function SBIGUnivDrvCommand Lib "sbigudrv.dll" (ByVal command As Integer, ByRef params As Any, ByRef results As Any) As Integer

% MATLAB
??????

____________

I've already figured out how to convert "typedef enum" into "classdef ... enumeration":

For example:
/* C */
typedef enum { BTDI_SCHEDULE_ERROR=1, BTDI_OVERRUN_ERROR=2 } BTDI_ERROR;

becomes ...

% MATLAB
classdef BTDI_ERROR < uint16
  enumeration
    BTDI_SCHEDULE_ERROR              (1)
    BTDI_OVERRUN_ERROR               (2)
  end % enumeration
end % classdef    % MATLAB


Thanks in advance!

Kevin Crosby
0
Kevin
1/6/2011 1:58:04 AM
comp.soft-sys.matlab 211265 articles. 25 followers. lunamoonmoon (257) is leader. Post Follow

8 Replies
1257 Views

Similar Articles

[PageSpeed] 48

On 11-01-05 07:58 PM, Kevin Crosby wrote:
> I'm trying to convert some vendor provided C and/or Visual BASIC code into
> MATLAB, so that MATLAB can utilize a driver that can interface a camera.
>
> Three questions:
>
> 1. How do I convert global constants into MATLAB?
>
> For example:
> /* C */
> #define CE_ERROR_BASE 1

That is not a global constant in C. In C, that is a preprocessor definition. 
The preprocessor works "above" the source language, and anything #define'd in 
C is treated very much as if the replacement section was just typed in to the 
source code at the appropriate place. No storage allocated, no data types, 
just text that gets put in to the source.

> ' Visual BASIC
> Global Const CE_ERROR_BASE = 1

I do not know Visual BASIC. If I were to analyze that bit of source code by 
analogy to C, I would suspect that that actually allocates space at execution 
time for an actual variable named CE_ERROR_BASE . But that's speculation on my 
part.


> % MATLAB
> ??????

MATLAB does not have preprocessor definitions, and it does not have global 
variables whose values are automatically imported in to every module. MATLAB 
_does_ have global variables, but they have to be declared as global in every 
function that wants to use the global value. The effect is different than 
preprocessor definitions.


> 2. How do I convert "typedef struct" into MATLAB?
>
> For example:
> /* C */
> typedef struct {
> unsigned short cameraFound;
> unsigned short /* CAMERA_TYPE */ cameraType;
> char name[64];
> char serialNumber[10];
> } QUERY_USB_INFO;
> typedef struct {
> unsigned short camerasFound;
> QUERY_USB_INFO usbInfo[4];
> } QueryUSBResults;

There is no equivalent in Matlab. Every Matlab variable or temporary 
expression is an array and has a run-time header that describes its type and 
shape and which contains a pointer to where the actual data is. (The pointer 
cannot be accessed at the Matlab level, by the way.) A C "struct" describes an 
area of consecutive memory with possibly different types for each adjacent 
segment of actual memory. There is nothing equivalent in Matlab.

The closest you can get in Matlab would be to have a routine which packaged 
the struct up in to a Matlab array of uint8 (unsigned bytes), and then at the 
Matlab level, you manipulated the bytes to get what you wanted. Of course, if 
you are going to do that, you could also pull apart the struct and save it in 
to a Matlab "struct" but note that a Matlab "struct" is NOT stored in 
consecutive memory.


> 3. How do I do an external driver function declaration?
>
> For example:
> Assume SBIGUnivDrvCommand is defined in the driver file.
>
> /* C */
> #if TARGET == ENV_WIN
> #ifdef __cplusplus
> extern "C" short __stdcall SBIGUnivDrvCommand(short command, void *Params,
> void *Results);
> #else
> extern short __stdcall SBIGUnivDrvCommand(short command, void *Params, void
> *Results);
> #endif
> #else
> #ifdef __cplusplus
> extern "C" short SBIGUnivDrvCommand(short command, void *Params, void *Results);
> #else
> extern short SBIGUnivDrvCommand(short command, void *Params, void *Results);
> #endif
> #endif

You can't do access such a thing from Matlab.


You are probably going about things the wrong way for Matlab. Matlab can call 
C routines, but the C routines have to accept pointers to internal Matlab 
structures and work with those structures. So instead of re-implementing the C 
driver code, leave it as-is, and instead implement a "shim" layer that packs 
or unpacks variables between Matlab and the existing C code.

And if you find that there are state variables that have to be carried around 
but whose values you do not really need to know or set in Matlab, then there 
is no crime in leaving them in raw binary format and wrapping them up as a 
Matlab uint8 array that the caller is expected to save and pass down as 
needed. For example, as a first pass, you probably don't need to be concerned 
about the possibility of multiple cameras, so you could probably hide the 
details of what is in that "typedef struct" example you showed.
0
Walter
1/6/2011 2:22:46 AM
Walter Roberson wrote:
....

>> ' Visual BASIC
>> Global Const CE_ERROR_BASE = 1
> 
> I do not know Visual BASIC. If I were to analyze that bit of source code 
> by analogy to C, I would suspect that that actually allocates space at 
> execution time for an actual variable named CE_ERROR_BASE . But that's 
> speculation on my part.
....

Not that it really matters, but... :)

Const in VB is essentially the same as PARAMETER in Fortran.  It's a 
named entity but isn't a variable.  It's folded into the source code at 
compile time (or interpreter) much like a neutered to some extent 
preprocessor.  (AKA Fortran, one can do a limited number of compile-time 
operations w/ CONSTants such as arithmetic, etc., similar to 
initialization statements therein).
> 
> You are probably going about things the wrong way for Matlab. Matlab can 
> call C routines, but the C routines have to accept pointers to internal 
> Matlab structures and work with those structures. So instead of 
> re-implementing the C driver code, leave it as-is, and instead implement 
> a "shim" layer that packs or unpacks variables between Matlab and the 
> existing C code.
....

That would seem the sensible direction, agreed...

--
0
dpb
1/6/2011 3:53:32 AM
On Jan 6, 2:58=A0am, "Kevin Crosby" <Kevin.L.Cro...@nasa.gov> wrote:
> I'm trying to convert some vendor provided C and/or Visual BASIC code int=
o MATLAB, so that MATLAB can utilize a driver that can interface a camera.

That's a specialist's job. Judging from the questions you ask,
you do not have sufficient detailed knowledge to do that job
yourself. Judging from your email domain, you likely have
access to specialists at a far different level than anything
you can reasonably hope to get in touch with via USENET.

Use your agency's resources on such questions.

Rune
0
Rune
1/6/2011 4:21:30 AM
On 05/01/11 10:21 PM, Rune Allnor wrote:
> On Jan 6, 2:58 am, "Kevin Crosby"<Kevin.L.Cro...@nasa.gov>  wrote:
>> I'm trying to convert some vendor provided C and/or Visual BASIC code into MATLAB, so that MATLAB can utilize a driver that can interface a camera.

> That's a specialist's job.

Nah, it can be done by a generalist like me, but a specialist would 
probably do it faster. I'd have to pause to read documentation from time 
to time.

Now if it were a matter of writing the device driver from scratch, then 
it would help a lot to have someone with specific experience with that, 
or some really good example code.


Oh wait, is this my week for being a generalist or a specialist? I do so 
get the two confused...
0
Walter
1/6/2011 7:57:20 AM
Rune Allnor <allnor@tele.ntnu.no> wrote in message <b8436175-2f08-4f10-912a-8224466fc956@o4g2000yqd.googlegroups.com>...
> On Jan 6, 2:58 am, "Kevin Crosby" <Kevin.L.Cro...@nasa.gov> wrote:
> > I'm trying to convert some vendor provided C and/or Visual BASIC code into MATLAB, so that MATLAB can utilize a driver that can interface a camera.
> 
> That's a specialist's job. Judging from the questions you ask,
> you do not have sufficient detailed knowledge to do that job
> yourself. Judging from your email domain, you likely have
> access to specialists at a far different level than anything
> you can reasonably hope to get in touch with via USENET.
> 
> Use your agency's resources on such questions.
> 
> Rune

To clarify, I am trying to access an existing driver for a vendor supplied camera. I'm not trying to rewrite the driver, but was rather trying to implement a working C header file and/or Visual BASIC code in MATLAB to utilize the existing driver.

Since NASA did not create the camera, I seriously doubt that we have specialists that have expertise with programming and controlling this camera.

I will try what Walter Roberson has suggested in making a "shim" layer between MATLAB and the C header file.

Although I do need to read the universal driver documentation further, I've downloaded a vendor provided Windows Development Kit that contains the C header file, as well as five executables to aid in controlling the camera.

Kevin
0
Kevin
1/6/2011 5:23:04 PM
Walter Roberson <roberson@hushmail.com> wrote in message <ig393h$rgh$1@nrc-news.nrc.ca>...
> You are probably going about things the wrong way for Matlab. Matlab can call 
> C routines, but the C routines have to accept pointers to internal Matlab 
> structures and work with those structures. So instead of re-implementing the C 
> driver code, leave it as-is, and instead implement a "shim" layer that packs 
> or unpacks variables between Matlab and the existing C code.
> 
> And if you find that there are state variables that have to be carried around 
> but whose values you do not really need to know or set in Matlab, then there 
> is no crime in leaving them in raw binary format and wrapping them up as a 
> Matlab uint8 array that the caller is expected to save and pass down as 
> needed. For example, as a first pass, you probably don't need to be concerned 
> about the possibility of multiple cameras, so you could probably hide the 
> details of what is in that "typedef struct" example you showed.

Thanks for your advice!

I will try the "shim" layer which I assume is like a wrapper function, although I've never tried this.  I had assumed that if a C header file or Visual BASIC code could do the trick, then the existing driver might also be controllable directly through MATLAB.

I did notice that the documentation states that the C header file, which contains the function prototypes and struct definitions, should be included for calling the driver.  I've downloaded a vendor provided Windows Development Kit that contains the C header file, as well as five executables to aid in controlling the camera.
0
Kevin
1/6/2011 5:32:04 PM
Kevin Crosby wrote:
....

> To clarify, I am trying to access an existing driver for a vendor 
> supplied camera. I'm not trying to rewrite the driver, but was rather 
> trying to implement a working C header file and/or Visual BASIC code in 
> MATLAB to utilize the existing driver.
> 
> Since NASA did not create the camera, I seriously doubt that we have 
> specialists that have expertise with programming and controlling this 
> camera.

Risking a assumption, I presume Rune was speaking of C-coding expertise 
within NASA to do the code work, not actual camera expertise.

> I will try what Walter Roberson has suggested in making a "shim" layer 
> between MATLAB and the C header file.
> 
> Although I do need to read the universal driver documentation further, 
> I've downloaded a vendor provided Windows Development Kit that contains 
> the C header file, as well as five executables to aid in controlling the 
> camera.

It's not feasible in Matlab-alone code; but, as Walter says, it's 
relatively straightforward to build external interface functions with 
mex w/ Matlab.  Look at the external Matlab API documentation as well as 
how to call external C/Fortran code (and by extension other languages 
that have/allow an external interface binding) and pass data to/from 
Matlab and the foreign language code.

You shouldn't find it too hard (presuming you do have at least a modicum 
of C facility) to use the vendor SDK in conjunction w/ that from TMW and 
build that glue/shim layer.

--
0
dpb
1/6/2011 8:22:28 PM
dpb <none@non.net> wrote in message <ig58a8$o77$1@news.eternal-september.org>...
> > I will try what Walter Roberson has suggested in making a "shim" layer 
> > between MATLAB and the C header file.
> > 
> > Although I do need to read the universal driver documentation further, 
> > I've downloaded a vendor provided Windows Development Kit that contains 
> > the C header file, as well as five executables to aid in controlling the 
> > camera.
> 
> It's not feasible in Matlab-alone code; but, as Walter says, it's 
> relatively straightforward to build external interface functions with 
> mex w/ Matlab.  Look at the external Matlab API documentation as well as 
> how to call external C/Fortran code (and by extension other languages 
> that have/allow an external interface binding) and pass data to/from 
> Matlab and the foreign language code.
> 
> You shouldn't find it too hard (presuming you do have at least a modicum 
> of C facility) to use the vendor SDK in conjunction w/ that from TMW and 
> build that glue/shim layer.
> 

I am currently reviewing "MATLAB Interface to Shared Libraries" documentation that may be what you and Walter were alluding too @ http://www.mathworks.com/help/techdoc/matlab_external/f23224dfi7.html

Thanks!
0
Kevin
1/6/2011 9:33:04 PM
Reply: