• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 353 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Embedded XDC objects in a struct

Nick Borton
Genius 3595 points

Hello,

In many of my XDC modules I use structs within the module definition to help with managing data. I recently tried to re-architect one of my modules which had a Queue.Object in the Instance state, but needed to move / replicate it into a stuct, of which there is an array of in the instance state.


mod A_orig

{

   struct complex_data{Stuff};

   internal:

   Instance_State

   {

       Queue.Object q;

       complex_data data[];

   }

}

mod A_desired

{

   struct complex_data

   {

       Stuff

       Queue.Object q;

   };

   internal:

   Instance_State

   {

       complex_data data[];

   }

}

the module compile failed, and I needed to switch to a handle, and create them instead. Is that the only way?

Thanks

  • 0
    TI__Mastermind 37985 points

    The objects of the type Instance_State are special in the sense that their size is not known at the time the XDCspec file is processed. There are techniques that we use that allows us to generate header files in such a way that the actual size of Instance_State objects can be changed later, at the configuration time.
    Instance_State objects can also contain other Instance_State objects, and that's what Queue.Object really is. That's why your initial XDCspec worked.
    For structures, there are no special handling. The size has to be known at the time the XDCspec file is processed, so the special objects as Object types whose size is not fixed at that time can't be structure members.
    I don't think I have any better solution than what you had originally. Why did you have to move Queue.Object into complex_data?

  • 0 in reply to Sasha Slijepcevic
    Genius 3595 points

    The move was needed due to complications in the driver this is a part of. It is building lists of DMA descriptors and matching them with GIO packets. To keep up with the data flow, the descriptor lists are built in user, SWI and HWI threads. The list building function was getting interrupted, and the global queue was getting out of sync.

  • 0 in reply to Nick Borton
    TI__Mastermind 37985 points

    I am guessing that the ModA instances are DMA descriptors. I don't know if it's of any help, but all dynamically created instances of a module are kept in a list. You can access the elements on the list using the following functions:

          // get the first "live" runtime instance
          Mod_Object *Mod_Object_first();

          // get the next "live" runtime instance
          Mod_Object *Mod_Object_next(Mod_Object *obj);

    Changes in the list happen when calling Mod_create and the critical section is protected by the system gate.