Migration DSP/BIOS -> SYS/BIOS, including use of NDK

Hi Jim,

I would remove the NDK references and convert. Then move to the NDK you want and add things back in as needed.

Todd

Thank you, Todd.  

That makes a lot of sense.  I'll edit the .tcf file by hand to back out NDK references.  I think the tci file is the only one, but I'll check carefully.

Now a novice question.  How do I then put the newest NDK back into what will then be my SYS/BIOS configuration?  Is there a CCS5 method of doing that, or is it a text editing operation?  Is there a document I could refer to?  All the NDK docs I have checked refer to DSP/BIOS only.

When you pick a version of the NDK and NSP, I'd look at the examples to see what you have to do. Since you already have StackThread, you'll just need to create a Clock function that is similar to the PRD in the ndk.tci. You also need to fill in the task hooks (like the ndk.tci did). For example in your .cfg, you would have the following.

    var Clock = xdc.useModule('ti.sysbios.knl.Clock');
    var ndkClockParams = new Clock.Params();
    ndkClockParams.startFlag = true;
    ndkClockParams.period = 100;
    Clock.create('&llTimerTick', ndkClockParams.period, ndkClockParams);

    var Task = xdc.useModule('ti.sysbios.knl.Task');
    var hooks = new Task.HookSet();
    hooks.registerFxn = '&NDK_hookInit';
    hooks.createFxn = '&NDK_hookCreate';
    Task.addHookSet(hooks);

Todd

Thanks again, Todd.

We are using bios_6_32_05_54 and ndx_2_20_04_26, which I believe to be the latest versions.  I hadn't planned on using NSP.  Do you think we should?  Within the NDK, we are using nettools like dhcp, telnet and daemon.  I had thought that we would continue to use these.

I'm also planning to continue to use our existing drivers for the C6424, which we picked up from an evaluation module quite some time ago, and modified slightly.  Does that seem reasonable?

Where do you suggest that I go to look at examples?  There used to be an example subdirectory in older versions of the NDK, but it doesn't seem to be present in the new version?

The NSP contains the driver. So the driver you have should be fine. Having said that...

The examples where moved from the NDK into the individual NSPs.You can look at the NSP on this page for examples: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/index.html

Todd

I've found the examples.  I believe that there are 3 of them - helloWorld, cfgDemo and client.  If I have missed any, please let me know.

Having found the examples, I did have some .cfg files to look at, but these certainly raised questions.  I found ndk_2_20_04_26/docs/cdoc/index.html and some stuff beneath it which seems to list variables that can be set, but there is very little explanation given.  Is there some further documentation for this?

The cfgDemo example seems to suggest that the older style of configuration still does exist, though some names seem to be changed.  For example, I think that what was NC_NetStart has become NetBoot.  Again, it would really help if there was some documentation about this function - which doesn't seem to have the same linkage as the old NC_NetStart.

I think I am going to have to use the older style of configuration, because we make a run time decision about either using a static IP address or running a DHCP client to acquire an address.  Am I correct to assume that making such a run time decision forces the use of an ndkTaskParams method of setting non-default parameters? 

I've been trying to get something built, but I'm now hung up on some compile errors in the driver files (nimu_eth.c, etc.) that I had previously been using with NDK2.0.  The errors look serious, and make me believe that these drivers may not work for the updated NDK.

Our CPU is a 6424.  Can you tell me where I should go for drivers for this chip and NDK 2.20?  Please be as specific as you can about web pages, subdirectories, etc.  I've been searching for a while without success in the NDK and NSP packages.

Thanks for your help

Sorry about the post above.  It was a false alarm.  I had missed one of the #defines required by the driver code.  There were a couple of warnings after that was fixed, but nothing serious.  These drivers seem to work.  Still, it would be nice to know where we are supposed to be going for drivers for the new NDK and our particular CPU.