Custom DWork datatype in TLC generated code via Level 2 M-file S-function or TLC

Hi,

we are using Simulink Embedded Coder to generate C++ code for use on a embedded system. To inferface with the microprocessor hardware a number of custom driver blocks call C++ classes of our low-level library.

The S-functions of the driver blocks are only used for code generation and are not used during simulation. Therfore - as I understand - the S-function code is mostly used to declare the type, dimension and number of input and output signals of the block. During code generation this information is passed to our TLC file by Simulink.

Now, in order to use our C++ classes we declare a DWork element inside the S-function to hold the object assoicated with each driver block. This element is initialized (constructed in C++ terms) inside the startup routine. Inside the outputs function calls to the respective hardware are made through this Dwork element. By registering a custom data type matching the class name inside the S-Function static memory allocation and static typing are archieved.

It is important to note that the S-function does not need to contain actual code since we provide a TLC file anyway. This is mosty due to the fact that the S-function builder does not give access the the initialize and terminate functions.

Just to sum up, what we want is a Dwork vector declaration in the generated code ( model.h ) that reads similar to this:

rtDwork {
  my_class S_Function_DWORK;  // Dwork holding custom type my_class
  my_foo   S_Function1_DWORK; // Dwork holding custom type my_foo
  my_foo   S_Function2_DWORK; // Dwork holding custom type my_foo
  ...
};

However, we would like to reduce the complexity of the S-function as much as possible. For once the fact that we need to use a C S-Function in order to register a custom type for our only Dwork element (via ssRegisterDataType()) is rather unfortunate, since it requires MEX-ing the S-function which in turn requires a compliant compiler to be present on the machine. All for the sole purpose to tell the TLC to spill out a different string when generating the Dwork vector declaration.

It would be most helpful to declare the typename of a Dwork vector element either inside a Level 2 M-file S-function or inside the TLC file (preferable). Is this possible?

Thanks and apologies for the lengthly post

Arne

Answer 1

[Kaustubha Govind]

It doesn't look like MATLAB S-functions support defining custom datatypes within the S-function - see this page for relevant documentation.

Why not make the name of the datatype an S-function (nontunable) parameter? That way you won't have ti re-compile if the name of the type changes.

Alternately, you might be able to use a PWork vector (I believe only one PWork vector is allowed per S-function) instead of DWork vectors, because Simulink doesn't need to know its type - it is treated like a void-pointer and there is no memory management associated with it. Simulink is more strict about DWork vectors because the engine needs to manage memory for it, so it needs to know the size (which you also need to specify using ssSetDataTypeSize).

Answer 2

[Arne]

Many thanks for your answer.

in fact I looked into PWork vectors but they are not exactly what is called for in my opinion since they are in fact void pointers:

• we loose type safety because casts are needed
• we need some sort of memory allocation for the objects pointed to by the PWork

Both aspects are solved when we were able to create custom work vectors of exact matching type. Since we never use the work vectors inside the Simulink environment but only during code generation this boils down to placing the right text into the header file.

As it seems we will solve the matter by simply writing custom sections into some source file and working around the DWork facility all together.

How can I generate a modelwide-unique and C compliant identifier similar to the one used for the DWork elements?

[Kaustubha Govind]

"How can I generate a modelwide-unique and C compliant identifier similar to the one used for the DWork elements?" - sorry, the question is not clear to me. It seems like you have the process for DWorks in place already. For what (or in what context) did you need to generate the header?