generating modified ddk files

[spg]

it would be really swell to be able to redefine many DDK functions to reduce extraneous overhead.  For example the function:

inline tMSeries::tInterrupt_A_Ack& tMSeries::tInterrupt_A_Ack::setG0_Gate_Error_Confirm(u16 fieldValue, nMDBG::tStatus2* s)

{

   if (s && s->isFatal()) return *this;

   u16 newValue;   newValue = ((u16)(_softCopy & 0xffdf)) | (((u16)fieldValue << 0x5) & ~0xffdf);

   setRegister(newValue, s);

   return *this;

}

could be redefined as

inline void tMSeries::tInterrupt_A_Ack::setG0_Gate_Error_Confirm(u16 fieldValue)

{

    u16 newValue;   newValue = ((u16)(_softCopy & 0xffdf)) | (((u16)fieldValue << 0x5) & ~0xffdf);

    setRegister(newValue);

}

removing the status param and getting rid of the function result signficantly reduces the stack requirements for the routine, when inlined.  of course optimization cleans up some of this, but not for debug builds.  i am having a problem with stack overflows, after moving to a new compiler and target (GCC 4.2, x86_64).

can anyone at NI comment on the feasibility of regenerating these files without the extra code?   of course I can do it by hand, but I don't see an easy way to automate removal of the function result...

thanks,

spg

[Steven_T]

Hello Scott,

Thank you for reporting this problem to us.  I'll be looking into this further, and I'm hoping that there is an easy way to generate the types of files you are describing.

Thanks,

Steven T.

[Steven_T]

Scott,

I had some time to look into this some more.  The short story is that these files are not easy to generate in a way that will help you prevent the stack overflows.  Because of this, I doubt that these types of files will be available from NI.

The Measurements DDK driver is meant as an example showing how to access the hardware registers on the NI DAQ boards.  Joe summed it up pretty well in this post.  To prevent your stack overflow issues in the future, you should use the DDK as a reference for creating a driver for your specific operating system and platform.

Thanks,

Steven T.

[spg]

seem to me that joe's post refers to the os interface, not the chip object files, which are massive and don't seem like the kind of thing you want to reengineer.  

anyway, I see that the answer to my question is pretty much the expected:  "ain't gonna happen."    

frankly, the real problem is that this is one of my older driver designs, where everything is in-kernel, with limited stack space.  my newer drivers have all of the chip object code in user-space, where stack isn't a significant problem.

thanks for looking into this.