XDC Proxy and different instance configs

Nick Borton

Hello,

Is there a way to use proxies of modules which have different instance configs? I'm just looking to create a set of modules which have the same function interface, but implement things differently under the hood. I would like each implementation of the interface to have different config parameters. But the proxy's handle will not take an inherited modules handle, and the proxy's params are only that of the interface.

example

interface IMod

{

// do not want all inherited mods configs here, otherwise why have the proxy

void runModule();

}

module ModA inherits IMod

{

instance:

int BufferSize;

}

module ModB inherits IMod

{

instance:

int bufferSize;

int numBuffers; // multi run version

}

module runMods

{

proxy PMod inherits IMod

instance:

PMod.Handle PModH

}

prog.cfg

multiDataRun = ModB.create(ModBParams);

runMods = xdc.useModule('runMods');

runMods.PMod = xdc.useModule('ModB');

runModsInst.PModH = multiDataRun; // not allowed

runModsInst.PModH = runMods.PMod.create(params); // here I cannot set the parameters I want

over 14 years ago

0 Sasha Slijepcevic over 14 years ago

TI__Mastermind 37985 points

You can use the last line in your script to set the common parameters:

runModsInst.PModH = runMods.PMod.create(params); // use only IMod create parameters

and then set the parameters for ModB through:

runModsInst.PModH.delegate$.bufferSize = ...;
runModsInst.PModH.delegate$.numBuffers = ...;

The property delegate is documented here.

The functionality you are asking for, to specify all parameters that ModB can accept in the call to create(), is described as "coming soon" in this primer lesson http://rtsc.eclipse.org/docs-tip/RTSC_Interface_Primer/Lesson_15. However, we still haven't implemented it because it requires significant changes in the configuration engine with the only benefit that you specify everything in one line instead of two or three. We still have it on the list of things to do, but no one is actively working on it as of now.

0 npb17 over 14 years ago in reply to Sasha Slijepcevic

Expert 1615 points

Hi Sasha,

I'm trying to do something similar to your example above. When building my project, the process fails after invoking XDC tools. Here's the error message:

**** Build of configuration Debug for project core3 ****

C:\TI\ccsv4\utils\gmake\gmake -k all
'Building file: ../core3.cfg'
'Invoking: XDCtools'
"C:/TI/xdctools_3_20_03_63/xs" --xdcpath="C:/TI/ipc_1_21_02_23/packages;C:TI/ti_rtsc/ndk_2_20_04_26/packages;C:/TI/bios_6_30_02_42/packages;C:/TI/xdais_7_10_00_06/packages;C:/TI/xdais_7_10_00_06/examples;C:/Users/nbedbury/rtsc_repository;C:/Users/nbedbury/rtsc_repository/messaging;C:/Users/nbedbury/rtsc_repository/tasks;" xdc.tools.configuro -o configPkg -t ti.targets.C64P -p platform.src3748_ev_core -r debug -c "C:/TI/ccsv4/tools/compiler/c6000" "../core3.cfg"
making package.mak (because of package.bld) ...
generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...
configuring core3.x64P from package/cfg/core3_x64P.cfg ...
js: "C:/TI/xdctools_3_20_03_63/packages/xdc/cfg/Main.xs", line 31: XDC runtime error: can't find the library 'lib/messaging.a64P' specified by package messaging. It wasn't found along the path 'C:/TI/ipc_1_21_02_23/packages; .....and more XDCPATH as above ....

I'm not sure what the .a64P file does or how it's generated, but there isn't any such file in my project directory. There's a file called "messaging.a64P.mak", but adding a direct path to the file didn't seem to make a difference in the build. Do you have any suggestions for what causes this type of warning? I think it means I'm not configuring a module properly in my .cfg file, but the error message doesn't show anything wrong syntactically.

In general, I my project is laid out as follows:

//////////////////////////////////////////////////////////////////
//XDC modules and interfaces
//////////////////////////////////////////////////////////////////

interface IMessaging
{
   instance:
      Int Init();
      Int Send(Ptr buffer);
      Int Receive(Ptr* buffer);
} // interface IMessaging

module MessageQMessaging inherits IMessaging
{
   instance:
       config String QName = "queue";
       config Bool QCreate = false;
       config MessageQ.Handle QHandle = null;
   internal:
       struct Internal_state
       {
           // Vars to create/open a MessageQ
           String           QName;
           Bool             QCreate;
           MessageQ.Handle QHandle;
       }
}

module MessagingTask
{
   proxy PMessaging inherits IMessaging;

   instance:
       config PMessaging.Handle PMessagingH = null;
   internal:
       struct Instance_state
       {
           PMessaging.Handle PMessagingH;
       }
}

//////////////////////////////////////////////////////////////////
//prog.cfg
//////////////////////////////////////////////////////////////////

var MessagingTaskVar = xdc.useModule('tasks.MessagingTask');
var MessageQMessaging = xdc.useModule('messaging.MessageQMessaging');

MessagingTaskVar.PMessaging = MessageQMessaging;

var MessagingTaskParams = new MessagingTaskVar.Params();
// ...initialize parameters as needed ....

var MyMessagingTask = MessagingTaskVar.create(MessagingTaskParams);

MyMessagingTask.PMessagingH = MessagingTaskVar.PMessaging.create();
MyMessagingTask.PMessagingH.delegate$.QName = "myMessageQ";
MyMessagingTask.PMessagingH.delegate$.QCreate = true;

Does that setup look correct? Is there something special I will need to do if my proxy inherits MessageQ to pass the proxy parameters to functions like MessageQ_create() or MessageQ_open() ? Thanks for any suggestions!

Nick

0 npb17 over 14 years ago in reply to npb17

Expert 1615 points

Ok, the problem there was that MessageQMessaging.c was using a parameter variable that I removed from MessageQMessaging.xdc. I didn't realize the compile of the MessageQMessaging module was failing, which caused the .a64P file to not be generated.

Processors

Processors forum

XDC Proxy and different instance configs