Code Composer 3.3 Platinum GEL commands return values?

[peterjim]

I am using Labview 8.2.1 and interfacing to TI Code Composer Studio 3.3 Platinum using the LV DSP Test Integration Toolkit. Specifically, I am running a (CCS) GEL command using the method "TargetEvalExpression" (or "TargetEvalExpresion64). These run a GEL command (in my case, a DSP self test) in CCS and return a numeric value. But the value returned seems to always be 0x00000000 - not the return value of the GEL function as I expected. Is this correct behavior? If so, what does the returned value mean? And how can I get a value with my own meaning (a pass/fail boolean would do!) back from a GEL function?

[John.P]

Hi Peterjim,

I am afraid I am not familiar with Code Composer Studio or GEL commands.

Can you explain a little bit more about your application such as what hardware are you using and how this is set up.

What is the intended aim of the application?

What functions are do you want LabVIEW to perform and what do you want CCS to do?

Are you able to run the commands directly from CCS?  Does this return the values you expect?

It appears that you are trying to get this working in CCS and then control that from LabVIEW, is this the case?

If you can let me know this information we can continue to look into this.

Kind regards,

 John P

[peterjim]

Hi John,

Code Composer Studio is Texas instruments IDE for DSP development. It includes an internal language called GEL (general extension language I think) which looks like C. I want to use this to perform tests on the hardware, but for the purpose of this query I have a GEL function which just writes to stdout and returns a non-zero value. When called from inside CCS (you can attach GEL functions to menus) this function runs without errors but I don't know what happens to the return value - I just see the text on stdout.

TI also provides a dll (CCS_Scripting_Com.dll, version 1.52) which exposes the methods of the CCS external scripting interface (not the same as GEL!). This is designed for use by Visual Basic. Labview successfully picks this up and gives me the methods (most of which are specific direct controls of CCS functionality, like "ProgramLoad" or "TargetConnect"). These methods include "TargetEvalExpression": the documentation says this "Evaluates a C expression or GEL command" and returns "The result of the evaluation". But in Labview, the returned value of any GEL command (function) seems always to be 0x00000000. This is my problem, since I need to return a meaningful value to Labview when I run a test.

TargetEvalExpression64 is similar, but returns a 64-bit result in the form of a string (to avoid truncations in exterrnal scrpting languages). The result is the same though.

So, to explicitly answer your questions, the setup is CCS and Labview - no hardware required. The aim is to get a useful interface between the GEL command system and Labview using TI's dll, so that it can return a pass/fail value from a GEL command (function) which I write. As far as I can tell, everything works as it should in the GEL language environment, although I can't actually tell what happens to the return values of GEL commands at the "main" level.

Unfortunately I have no VB capability on this machine (not even MSOffice) so I can't see whether the dll works this way.

It would be useful to hear if anyone else has either got this to work, or had the same sort of issues.

TIA

[John.P]

Thank you for the clarification.

In general, a dll will return zero whenever there is an error calling it. This is often caused by incorrect specification of the DLL header file or incorrect function parameters.  My suggestion would be that although LabVIEW appears to have correctly identified the functions from the DLL, there is some problem calling it.  It may be you need to create a wrapper DLL that can convert the data from the DLL into something LabVIEW can handle.  Unfortunately this is all speculation due to the lack of information specific to the DLL. 

My suggestion would be to contact TI and try and get some more information on the data types passed by the DLL, also if there is anyway you can access the DLL from another environment, try and see the data type returned. 

Hopefully somebody out in the community has done something similar before and can give you more specific information! 

Best regards,

[peterjim]

Thanks for that info. A "calling-style" incompatibility might well explain it. I have a man from Texas Instruments on the case now - if I get a resolution (or understanding), I'll post it!