CCSv5, SysBios, ndk 2.21 - how to choose legacy NDK configuration method?

I'm going to partially answer my own question.  I read the user guide a little more closely, and I believe that it suggests that the NDK should be left out of the RTSC set entirely.  I think that would work with a lot of fixups for NDK hooks, llTimerTick, paths, etc.

There seems to be an easier way.  I found that if I enabled only the NDK Global stuff via XGCONF, and then, in the Advanced tab, set enableCodeGeneration to false, everything worked out.  The paths were installed for me.  The hooks were installed, the timer tick was installed.  But there were no calls to NC_SystemOpen, NC_NetStart, etc.  Just what I needed.  Though this is not the approach suggested in the User Guide, I think it might be the best way to use dynamic configuration.

There is also a very interesting hook function available if code generation is enabled.  This is stackInitHook.  It is called immediately after CfgNew.  The problem is that I can't find the linkage definition for it.  I'm hoping that it passes in the Cfg handle from CfgNew.  If that is the case, then it could be used to dynamically configure one of the modules - in my case that would be IP - while allowing static configuration of all others.

So, I guess my partial answer leads to two more questions.

First, does my solution of setting enableCodeGeneration to false seem reasonable?  Or might it lead to trouble?

Second, how can I find out the linkage for the stackInitHook function? 

Hi JimG,

Which hardware platform are you using?

JimG said:

First, does my solution of setting enableCodeGeneration to false seem reasonable?  Or might it lead to trouble?

You are definitely on the right track here.  There are a couple of ways to avoid the NDK auto configuration, one is to completely leave out the NDK from the RTSC configuration.  The other way is to add it to the configuration, but to set the enableCodeGeneration parameter to false, as you've discovered already.

JimG said:

I found that if I enabled only the NDK Global stuff via XGCONF, and then, in the Advanced tab, set enableCodeGeneration to false, everything worked out.  The paths were installed for me.  The hooks were installed, the timer tick was installed.  But there were no calls to NC_SystemOpen, NC_NetStart, etc.  Just what I needed.  Though this is not the approach suggested in the User Guide, I think it might be the best way to use dynamic configuration.

Yes.  When the NDK is part of the RTSC configuration, you will get some stuff for free - hooks, the heartbeat timer tick, linking in of correct NDK libraries automatically (instead of manually adding the libraries needed into your project file).  When enableCodeGeneration is set to true, you get even more - it auto generates code for a Task thread (ti_ndk_config_Global_stackThread) which will contain calls to NC_* functions, as well as calls to the NDK run time configuration APIs (CfgAddEntry(), Cfg*() ...).  These calls are populated with the values that have been set in the RTSC configuration script.  (I'm not sure if you are new to the NDK or not, but if you have ever used a previous version, the code of the ti_ndk_config_Global_stackThread() function is modeled from the function that was called "StackTest()" in the older NDK examples (client, helloWorld, ...).

However, you are free to set enableCodeGeneration to false in order to allow more control over the code of that thread.  In this case, you should define your own version of ti_ndk_config_Global_stackThread() which contains all NC_*() and Cfg*() API calls.

For the other option - leaving the NDK out of the RTSC config entirely - this is allowed too but just means you will have to do a bit more work yourself (as the stuff listed above as being done automatically won't happen).

In either case, you'll want to ensure that you keep the configuration for the EMAC driver present in your RTSC config (if it exists for your hardware platform) as that will give you the driver library automatically.

JimG said:

There is also a very interesting hook function available if code generation is enabled.  This is stackInitHook.  It is called immediately after CfgNew.  The problem is that I can't find the linkage definition for it.  I'm hoping that it passes in the Cfg handle from CfgNew.  If that is the case, then it could be used to dynamically configure one of the modules - in my case that would be IP - while allowing static configuration of all others.

The reason you don't see the definition for that function is because it must be defined by the user (Also, this function would only apply to the case of enableCodeGeneration == true).  So, you would need to define that function, and then set its name to the config parameter "Global.stackInitHook".  Then, when the code for ti_ndk_config_Global_stackThread() is generated, it will also generate the call to the function named in the "Global.stackInitHook" configuration paremeter.

Unfortunately, I see a limitation with this hook function in that it is expected to have no arguments.  So, you wouldn't be able to pass the cfg handle returned from CfgNew to it ... This is a bug in the design of this generated code.  I see a way to work around this though (you would modify a template file which generates that fxn call) ... so let me know if you think you'll want to go with the code generation enabled route and I can help you with that.

Steve

Thank you, Steve.  In answer to your earlier question, the hardware is a 6424.  We had done a previous implementation with CCS3.3 and NDK 1.0.  Then there was no option for static configuration.

I had feared that the function might be parameterless, since so many of the hook functions are.  I think it will be very good if something can be done to improve that.  As matters stand, we won't be able to use static configuration.  We have to make our IP addressing decisions based on other things we discover when the system is coming up.  (For background, when the system is operating on a lab bench, we need to use a static IP address.  When it is in a larger system chassis, then we need to use a variation on BOOTP - for which we adapted the DHCP code.)  In any event, it is a run time decision.  To be quite frank, I can't see how anyone using a static address could define it at compile time.

The system seems to be behaving very well right now.  I agree about the benefits of including the NDK then not enabling code generation.  At first I thought I was going to have to define some hooks, but when I tried to do so, I found out they were already present.  That was good.  I only wish I had anticipated it.  

I think I've been through that docs directory before, but I'll try once more.

Thanks again for your help.