RTOS/TMS320C6748: NDK migration

Dean Hofstetter

Expert 2585 points

Part Number: TMS320C6748
Other Parts Discussed in Thread: SYSBIOS, OMAP-L138, OMAPL138

Tool/software: TI-RTOS

Processor: C6748

SYSBIOS: 6.75.2.00

XDC: 3.51.1.18

NDK: Attempting to upgrade to 3.40.1.01

NS: 2.40.01.02

CCS: 8.2.0

Long time NDK 2.x user attempting to update to 3.40. Problem #1: I've installed both NDK 3.40.01.01 and NS 2.40.01.02 to my computer. After relaunching CCS, it picked up the new NDK and installed it. However, it did not find the NS. Both the NDK and NS are in the same directory on my computer (C:\ti). I'm thinking we should get this figured out first before moving onto my other problems. Any suggestions?

Thanks, Dean

over 6 years ago

0 Yordan Kovachev over 6 years ago

TI__Guru**** 161600 points

Hi,

What is the result if you install the just older NS 2.40.01.02 in ~/ti, does CCS detects the package as newly installed? And then install the later NDK 3.40.01.01

Best Regards,
Yordan

0 Dean Hofstetter over 6 years ago in reply to Yordan Kovachev

Expert 2585 points

I exited CCS, then removed the NDK 3.40.1.01 and NS 2.40.01.02 folders from C:\ti. Restarted CCS, and it recognized that NDK 3.40.1.01 was missing and it uninstalled that and rebooted. Exited CCS once more, and then moved just the NS 2.40.01.02 folder back into C:\ti. Restarted CCS, and it didn't find the NS.

How I aquired the NDK / NS is via downloading the SDK-RTOS-OMAPL138-LCDK-05.03.00.07-WINDOWS-X86-INSTALL executable. During the "Select Components" stage of the install process, I unchecked everything except the NS and NDK. Perhaps that is wrong?

By the way, I don't need anything in the NS. So, if NDK 3.40.1.01 can run without the NS, that is fine by me. As far as I know the NS only provides: HTTP client, MQTT client, MQTT server, SNTP client, and JSON parser. None of those are need for my application. I just need DHCP, DNS, IPV4, TCP, and UDP. So, if there is a way to just setup NDK 3.xx without an NS, lets explore that.

Thanks, Dean

0 Dean Hofstetter over 6 years ago in reply to Dean Hofstetter

Expert 2585 points

More information. So I'm proceeding ahead as if I don't need the NS. The compile error I get if I use NDK 3.40.1.01 is "cannot open source file sys/time.h". This is coming from file "ti\ndk\inc\socketndk.h". Furthermore there is a #ifndef around the #include for time.h. What is NDK_NOUSERAPIS? I can't find that mentioned anywhere in the user guide or any documentation?

0 Yordan Kovachev over 6 years ago in reply to Dean Hofstetter

TI__Guru**** 161600 points

Ok, here are my observations. I installed latest Processor SDK RTOS for OMAP-L138 v. 05.03.00.07 in ~/ti (I already had the NDK 3.40.1.01 installed in the path, because I use other processor sdks and ndks is shared between devices) I did full installation of the SDK. Upon opening CCS only the omap-l138 pdk package was detected (As I said NDK 3.40.1.01 is already installed in my case), NS 2.40.01.02 was not.

So I think this should be ok for the latest Processor SDK RTOS.

However I'd like to note that despite your need just for NDK, you should know that NDK sources use header files from other Processor SDK RTOS components (bios, edma and so on), so I'd recommend to install the full Processor SDK RTOS package for your development.

Best Regards,
Yordan

0 Dean Hofstetter over 6 years ago in reply to Yordan Kovachev

Expert 2585 points

Yordan,

I installed the full SDK, but this did not resolve my issue. By the way, if TI knows that the NDK requires other components from the SDK, why allow the user to select the bits can pieces they want? If there really are dependencies, then TI should only allow the full SDK install.

Here is the compile error I'm getting: "cannot open source file sys/time.h". The file that is throwing this error is: socketndk.h. Within this .h file is a #ifndef statement around the inclusion of time.h: NDK_NOUSERAPIS.

"time.h" is a C library file. When I explore the 8.3.3 compiler folder, I see that time.h lives in the root include directory, NOT in the /sys directory. The compiler that is included with the SKD is 8.3.2, but that also has time.h in the root include directory. It shouldn't matter if I'm using C6000 compile tools 8.3.3 or 8.3.2, "time.h" lives in the same place for both.

So big question: "Is NDK_NOUSERAPIS supposed to be defined, which would prevent the header file from wanting time.h?" ..or.. "Is socketndk.h wrong to include the /sys in the time.h path"?

Thanks, Dean

0 Dean Hofstetter over 6 years ago in reply to Dean Hofstetter

Expert 2585 points

I really would like to keep things moving along to find a solution to my problem. Any other NDK experts out there?

Thanks, Dean

0 Dean Hofstetter over 6 years ago in reply to Dean Hofstetter

Expert 2585 points

Hello, anyone out there?

0 Yordan Kovachev over 6 years ago in reply to Dean Hofstetter

TI__Guru**** 161600 points

Hi,

Apologies for the delay, I was OoO.

So big question: "Is NDK_NOUSERAPIS supposed to be defined, which would prevent the header file from wanting time.h?" ..or.. "Is socketndk.h wrong to include the /sys in the time.h path"?

Can you share which NDK example are you building? Or is this a custom application? If yes, then check that you updated your include paths in the CCS Project Properties. See this thread: e2e.ti.com/.../166601

Best Regards,
Yordan

0 Dean Hofstetter over 6 years ago in reply to Yordan Kovachev

Expert 2585 points

This is a custom application. My include paths are fine. "time.h" is a standard C header file, and therefore doesn't need special adjustments to the include path. en.wikipedia.org/.../C_standard_library. I have other standard C header files in my project ("string.h" and "stdio.h") and the compiler finds them just fine. The problem is "socketndk.h" puts a /sys in the path name.

For example, when a source file in my project needs to include "string.h" the code is:
#include <string.h>

The "socketndk.h" file has the following code:
#include <sys/time.h>

The compiler I'm using is 8.3.3, and the standard C header files are located in "C:\ti\ccsv8\tools\compiler\ti-cgt-c6000_8.3.3\include". Notice there is no /sys in that path.

So, we circle back to why does "socketndk.h" have /sys in the path when it wants to include "time.h"? Possible explanations.

1. NDK_NOUSERAPIS is suppose to be defined somewhere, and if so, then "socketndk.h" never tries to include "time.h". Please find out if NDK_NOUSERAPIS is suppose to be defined or not, and if so, where does it get defined?

2. NDK_NOUSEAPIS is not supposed to be defined. In that case, it looks like "socketndk.h" has a bug by including /sys in the path. Either that, or there is some other "time.h" that "socketndk.h" wants to include (not the standard C library time.h). That would be a bad practice.

Please focus on NDK_NOUSERAPIS. That is the key to answering my problem. I've search the NDK users guide and API reference guide and there is no mention of NDK_NOUSERAPIS.

Thanks, Dean

0 Yordan Kovachev over 6 years ago in reply to Dean Hofstetter

TI__Guru**** 161600 points

Hi Dean,

NDK_NOUSERAPIS is a temporary fix to enable NIMU drivers to avoid a POSIX dependency. User code typically doesn't throw it (and therefore has a POSIX dependency). This is described in the socketndk.h file itself.
When NDK_NOUSERAPIS is NOT defined the code uses TI POSIX to get timeval, needed by fdSelect(). So it is possible to use the NDK_NOUSERAPIS and see if it will fix your problem.

Best Regards,
Yordan

0 Dean Hofstetter over 6 years ago in reply to Yordan Kovachev

Expert 2585 points

I don't want to "hack" the NDK to get it working in my project. I've followed the recommended steps to download and integrate the NDK into my project, yet I still have compile errors. I'm the only one?????

If NDK_NOUSERAPIS is supposed to be defined, then how? No where in the NDK 2.x to 3.x migration guide does it mention anything to do with NDK_NOUSERAPIS (file:///C:/ti/ndk_3_40_01_01/docs/ndk/NDK_2_to_3_Migration_Guide.html).

I can use NDK version 2.26.0.08 without any issues. Switching to NDK version 3.40.1.01 causes this issue with NDK_NOUSERAPIS. By the way, the file that is kicking out this error isn't even one of my source files. It is the SYSBIOS file that gets generated: "RackCardC6000_pe674c". SYSBIOS and the NDK aren't playing nice together and I need help understanding why.

Thanks, Dean

0 Yordan Kovachev over 6 years ago in reply to Dean Hofstetter

TI__Guru**** 161600 points

Hi Dean,

Sorry for the delay.
I am not sure what exactly is going wrong in your project.
Can you share which Processor SDK RTOS example are you building (maybe I could try and reproduce it on my side)? Or is this a custom app? If this is a custom app, please describe how you create it (maybe share the sources if possible).

Best Regards,
Yordan

0 Dean Hofstetter over 6 years ago in reply to Yordan Kovachev

Expert 2585 points

Yordan,

Processor SDK = SDK_RTOS_OMAP138_5_03_00_07

I'm not building an RTOS example project. This is a custom app. Not sure what you mean "how you create it". Remember my custom app works just fine with NDK 2.26.00.08. I'm unable to share source code at this time. Below is my best guess at what you mean by "how you create it".

1. In the SYSBIOS .cfg file, I have included the Global NDK. On the System Overview tab, I've selected Global Network Settings, TCP, UDP, IP, ICMP, and ROUTE.

2. My setup is static IP, so DHCP is not enabled.

Please re-read my May 7th and May 9th posts. The issue is with a SYSBIOS created file and NDK_NOUSERAPIS.

Thanks, Dean

0 Sahin Okur over 6 years ago in reply to Dean Hofstetter

TI__Mastermind 27355 points

Hello Dean,

Did you upgrade SYS/BIOS as well? If so, I suspect that's the reason for the error:

In SYS/BIOS 6.52.0.12, time.h was in bios_6_52_00_12/packages/ti/sysbios/posix/sys/, but in SYS/BIOS 6.75.2.00 it's in bios_6_75_02_00/packages/ti/posix/ccs/sys/

If this applies to you, you'll need to add the XDCtools path "${BIOS_CG_ROOT}/packages/ti/posix/ccs" in CCS Project Properties > Build > XDCtools > Package Repositories.

Please let me know if this works for you.

Regards,
Sahin

0 Dean Hofstetter over 6 years ago in reply to Sahin Okur

Expert 2585 points

Sahin,

I tried your suggestion and added the new path to the XDCTools Package Repositories. The error regarding time.h is gone, but now I'm getting a new remark: "remark #195-D: zero used for undefined preprocessing identifier __PRU__. line 54 from signal.h". It appears that SYSBIOS 6.75.2 and NDK 3.40.1 weren't qualified together, but ship together in the same SDK? Why wouldn't the two work together?

Finally, why would TI create a SYSBIOS include file called "time.h" that matches an include file from the C standard library? That seems dumb and dangerous.

- Dean

0 Dean Hofstetter over 6 years ago in reply to Dean Hofstetter

Expert 2585 points

Sahin,

If it wasn't clear in my previous reply, I'm still waiting for TI to solve my compile problem. I don't want to move forward with warnings or remarks. Something is obviously not right. It appears the combination of: C6748 + SYSBIOS 6.75.2 + XDC 3.51.1.18 + NDK 3.40.1 were never tested together. Even though all of those components are found in the latest SDK 5.03.00.07.

Thanks, Dean

0 Sahin Okur over 6 years ago in reply to Dean Hofstetter

TI__Mastermind 27355 points

Hi Dean,

The SDK and components undergo nightly regression tests before being released; I think we're missing something here. Would you be willing to zip up your project and attach it here so that we can take a closer look?

There is a signal.h inside ~\ti-cgt-arm_18.1.5.LTS\include\ and another inside ~\bios_6_75_02_00\packages\ti\posix\ccs\. Are you sure you're using the right one? It looks like the one inside ~\ti-cgt-arm_18.1.5.LTS\include contains the __PRU__ symbol the compiler is complaining about.

I'm looping in the SYSBIOS team to comment on the "time.h" duplication.

Regards,
Sahin

0 Dean Hofstetter over 6 years ago in reply to Sahin Okur

Expert 2585 points

I'm unable to upload my project, as it contains proprietary code. So the project has two "signal.h" files, just like the "time.h" files? What is the deal with the SYSBIOS team using C standard header file names? Instead of you asking me if I'm using the right signal.h file, I'm asking you. Which is right?

Below is a screen shot of the problem. As you can see the error is generated from building the SYSBIOS code for my project. I have no idea which "signal.h" file is correct, or why it is finding the C standard signal.h file before the SYSBIOS signal.h file. I've also uploaded my SYSBIOS *.cfg file to see if that will help lead to answers. By the way, I only get this remark if I use NDK 3.40. Rolling back to NDK 2.26 produces no errors, warnings, or remarks.

RackCardC6000.cfg

0 Steven Connell over 6 years ago in reply to Dean Hofstetter

TI__Mastermind 45025 points

Hi Dean,

I'll be taking a closer look at your issue with my colleague in the morning. In the mean time, I don't know if this will solve your issue, but you might give the following a shot.

We noticed that your config file is missing the below line, can you try adding it? I would just try copying/pasting into the end of your *.cfg script (I'd recommend saving/closing your *.cfg first, if it's open in the XGCONF GUI).

xdc.useModule('ti.posix.tirtos.Settings');

Then try building again.

Steve

0 Steven Connell over 6 years ago in reply to Steven Connell

TI__Mastermind 45025 points

Hi Dean,

It looks like this is due to a compiler bug.

The file C:/ti/ccsv8/tools/compiler/ti-cgt-c6000_8.3.3/include/signal.h is checking for the value of the __PRU__ macro, which I don't think is correct:

#if _PRU_

Since _PRU_ is not defined (and shouldn't be), it doesn't have any value, hence the remark.

I think signal.h should instead be checking for the defined status of the __PRU__ macro. This is what's being done in all other header files in the compiler:

#if defined(_PRU_)

We've also inspected all of the code related to this macro. Since the compiler is assuming a value of zero for the macro, this remark should be benign for you. Other places where it's checked are also OR'ed with a check for C6000 (e.g. defined(__TMS320C6X__) || defined(__PRU__)), so you would get that code regardless since you're building for C6x.

I've filed a bug with the Compiler Team for this issue:

CODEGEN-6300 - signal.h checks __PRU__ macro value instead of its defined status

Given this, I see 2 options for you at this point:

1. Ignore the warning, as it should be benign

2. Update signal.h and rebuild the compiler:

a. in signal.h, change this:

#if __PRU__

to be this:

#if defined(__PRU__)

b. The effect will be the same (the code within will be omitted by the preprocessor), but the remark will be gone. This has been verified here locally.

Steve

0 Dean Hofstetter over 6 years ago in reply to Steven Connell

Expert 2585 points

Steve,

Thanks for making progress on my issue. Many things still don't seem right. Here is what I know.

1. Processor SDK RTOS OMAPL138 V5.03 provides the following components: SYSBIOS V6.75.02.00, NDK V3.40.01.01, C6000 Code Gen tools V8.3.2, and XDCTools V3.51.01.18. These should be the only components necessary to build the SYSBIOS generated C file (which in my project is called "RackCardC6000_pe674.c").

2. When I configure my project to use the combination of components listed above, I get two errors. One it can't find "sys/time.h", and two I get remarks regarding __PRU__ not being defined. NO ERRORS OCCUR IF I SIMPLY REPLACE THE NDK WITH V2.26.00.08. I know there is a migration guide related to moving from NDK 2.x to 3.x, but neither of this issues are covered in the migration guide.

3. Sahin provided a work around for the missing "sys/time.h" by adding a new XDCTools Package Repository. See Sahin's post above for more information. I can't believe everyone using NDK 3.40.01.01 has had to make this adjustment to their project, so the question remains, "Why me"?

4. You have acknowledged a defect to the C6000 Code Gen tools. The same remark problem happens with V8.3.2 and V8.3.3, so I'm not sure how far back this problem was introduced. But again the question remains, "Why am I the only one seeing this issue"? Thanks for filing the bug with the compiler team. At least I know(hope) it will be fixed in the future.

5. Your first recommendation was to add a new line to my *.cfg file. Why do you think my *.cfg file is missing this line? Why wouldn't the tool that generates the *.cfg file add this line if it though it was necessary? Full disclosure, this *.cfg file was created a while ago. Probably using Code Compose V6, and who knows what version of SYSBIOS / XDCTools. Could that be part of my problem?

6. Even though Sahin says the SDK (and components) go through nightly regression testing, I can't believe the combination listed in #1 above has ever been tested. Could it be that I'm using the C6748, and not the OMAPL138? The SDK says it is valid for the C6748, so I don't believe I'm using the wrong one.

7. Finally, what is the logic behind having SYSBIOS use the same header file names as the standard C library? "time.h" and "signal.h" are the two I've stumbled upon, but it appears "errno.h" is another. In case you didn't know, here are the standard C library header files: en.wikipedia.org/.../C_standard_library

8. Obviously using the components within the V5.03 SDK is a no go for getting NDK 3.40 working (I mean without patches / work arounds). Do you think there is a combination that exists that will work? For example, maybe use SYSBIOS 6.52.x plus whatever XDCTOOL version that goes with that?

Thanks, Dean

0 ToddMullanix over 6 years ago in reply to Dean Hofstetter

TI__Guru* 96960 points

Dean,

This is going to take some time for all of these questions. We'll try to answer the ones we can, but will probably ask you to open new threads on many of them to keep this thread readable and allow the correct parties to address them. I'll respond on Thurs or (more likely) Friday.

Todd

0 Steven Connell over 6 years ago in reply to Dean Hofstetter

TI__Mastermind 45025 points

Hi Dean,

Dean Hofstetter said:
7. Finally, what is the logic behind having SYSBIOS use the same header file names as the standard C library? "time.h" and "signal.h" are the two I've stumbled upon, but it appears "errno.h" is another. In case you didn't know, here are the standard C library header files: en.wikipedia.org/.../C_standard_library

This is all related to SYS/BIOS and NDK support of the POSIX spec...

The latest NDK (3.x) and BIOS have been updated to implement the POSIX spec (or at least a subset of the spec). The reason we have to have multiple versions of some header files is because in many cases, the tool chain doesn't provide what POSIX dictates is required.

One example, which you have stumbled upon, is sys/time.h. In NDK 3.x, the NDK gets 'struct timeval' externally from sys/time.h (meaning, NDK doesn't define its own version of this struct, which it did previously and was bad for a number of reasons). And the POSIX spec states that the definition of this struct must be in a file "sys/time.h" (located in a directory called "sys").

(You can see some of these headers on the link mentioning POSIX on that same C standard library page you pointed to above.)

Since the tool chain does not provide sys/time.h, and it does not provide any definition of 'struct timeval', we have to provide that.

The following might be a bit more than you care to know, since I believe you're only using the TI tool chain, but it may help clear things up more -

We also need to support multiple tool chains, such as GCC and IAR. Each of these tool chains have the same/similar issue (e.g. no sys/time.h with struct timeval) or not (e.g. one tool chain might have the sys/time.h file, but another does not. Or there are even cases where a header file is provided by each tool chain, but one tool chain defines a particular struct and is up to spec, but the other tool chain's header does not). Since we're an RTOS that must ensure the same support across many tool chains, we have to handle all of these discrepancies.

This is the reason there are tool chain specific directories found under the BIOS POSIX directory (c:/ti/bios_6_75_02_00/packages/ti/posix/{ccs, gcc, iar}), as well as duplicate header files between tool chains, which won't necessarily be equivalent between them.

It's also why there is overlap of header files for a given compiler. So if the tool chain does provide the required header, but does not define all that's necessary, the ti/posix head will add the required definitions, and then bring in the tool chain header on top of that. For this reason, your app should always have the path to POSIX ahead of the tool chain's include dir (e.g. ti/posix/ccs in the TI tool chain case).

Hope this sheds some light on what's going on here.

Steve

0 Dean Hofstetter over 6 years ago in reply to Steven Connell

Expert 2585 points

Steve,

Thanks for explaining the "sys/time.h" issue. While it is fascinating what is required to be POSIX compliant, it still doesn't explain why I get an error when linking in NDK 3.40. It would appear that NDK V3.40 or SYSBIOS V6.75 (or both) has a bug. When NDK V3.40 is selected, that should force "something" to automatically add the missing "${BIOS_CG_ROOT}/packages/ti/posix/ccs" path to XDCTools.

Just as you filed a bug report for the __PRU__ issue with the C compiler team, shouldn't a bug report be filed with the SYSBIOS (or NDK) team to fix this missing path?

Thanks, Dean

0 Dean Hofstetter over 6 years ago in reply to Dean Hofstetter

Expert 2585 points

Steve,

Two more points.

1. Since my projects *.cfg file was created many many moons ago, I created a test project from scratch. New CCS project, typical SYSBIOS, and included NDK 3.40. I get the "sys/time.h" error. That shouldn't happen.

2. I don't understand why the xdc.useModule('ti.sysbios.posix.Settings') is needed. No project that I have ever created attempts to load this, and the new Test project I created didn't either. Is this required for NDK 3.40? If so, why doesn't it get added to the *.cfg file when NDK 3.40 is selected? You seem to think it is required, SYSBIOS 6.53 mentions it, as does the NDK migration guide. Somehow TI thinks this is important, yet I've never seen it before.

Thanks, Dean

0 ToddMullanix over 6 years ago in reply to Dean Hofstetter

TI__Guru* 96960 points

Dean,

Hopefully the following answers your questions. Since TI-RTOS/NDK does not ship the Processors SDK, can you please open a new thread asking for a NDK example for the desired SDK version. I'll reference this multiple times below.

In general, migrating an existing project from one generation of a component (i.e. NDK 2.x) to the next generation (NDK 3.x) is a difficult task. We don't expect this to happen often. Our customers typically don't do this. When they do choose to migrate, they take the opportunity to "start over" with their own software and make a new beginning.

Also, please note that newer versions of components typically require a newer version of CCS. This implies a migration effort for your CCS projects as well.

Having said that, we make a best effort to support migration, but we certainly are not perfect at it. There will be challenges along the way.

Here are some replies to your questions:

Re #1

Yes, the components you list should be all that is necessary to build an application.

Re #2

When importing an example for NDK 3.x, all necessary project setting will be made.

Can you please start a new thread asking for a NDK example for the desired SDK version you are using?

However, if you have an old project based on NDK 2.x, you will need to apply these settings manually. Our tooling does not have this level of integration with CCS.

Specifically, when using NDK3.x you must add the following include path to your project settings:

-I${SDK_INSTALL_DIR}/source/ti/posix/ccs

Note that 'SDK_INSTALL_DIR' must be replaced with the actual SDK you are using.

It will be helpful if you import a network example (i.e. ns/tcpecho) and then compare the project settings with your own project. This will go a long way to migrate your existing project.

The compiler warning regarding __PRU__ is a bug on our end. We hope to fix it soon. But it is benign and you can ignore it.

Re #3

Updating to NDK 3.40.01.01 also require updating XDCtools and SYS/BIOS. Check the release notes for the exact versions. In general, an SDK will provide all necessary components with their appropriate dependencies. If you are working outside of an SDK, be sure to update your components to match the SDK versions.

I would expect everyone who is migrating an existing project from NDK 2.x to NDK 3.x would encounter the same issues. But then, most people don't migrate from one generation to the next; they would import an example from the new SDK and build on that.

Re #4

Others have seen the same compiler warning regarding the __PRU__ symbol. I apologize it is taking so long to fix.

Re #5

When you start the new thread asking for an NKD example, please specify whether you want the example to include the NDK in the .cfg or not (or both ways).

It would be helpful to compare the *.cfg file from the NDK example for NDK 2.x and NDK 3.x. The differences are the changes you would need to apply to your *.cfg file. In particular, the handling of POSIX support has changed, requiring the addition of the following line:

xdc.useModule('ti.posix.tirtos.Settings');

XGCONF is simply a GUI editor for the *.cfg file. The UI settings you make ultimately resolve to edits in the file. Unfortunately, there is no UI option to enable the POSIX support, you must add this manually.

Re #6

I'm not on the Processor SDK team, so I'm only guessing. But I would expect the warning was simply overlooked.

Re #7

The implementation of POSIX is a collaborative effort for embedded systems. This differs from the classical Linux (Unix) platforms of the past. In the past, a given vendor (i.e. DEC, IBM, Sun) would provide an operating system with POSIX support. All header files would be installed on the file system under /usr/include/. The vendor would also install the compiler and underlying kernel. This provided a unified consistent implementation of POSIX.

With embedded systems, an OEM will pick and choose their components. For example, they would pick which hardware device to use (hopefully Texas Instruments), which compiler they want, and which kernel (i.e. SYS/BIOS, FreeRTOS, ThreadX). For us (i.e. TI) as a vendor, the challenge is that parts of POSIX depend on the compiler, while other parts depend on the kernel. For example, the compiler defines most of the error codes in errno.h, but not all of them. But the compiler knows nothing about pthread, because that is a kernel object. Yet, the POSIX specification indicates what types must be defined in which header file. So, if a given compiler is missing an error code in errno.h, we cannot invent a new header file, we must somehow contribute to the existing header file. We do this by providing our own implementation of errno.h, which must be found on the include path first. We then include the compiler header and then add the missing content. In this way, your source code simply includes errno.h and gets everything needed.

Re #8

The Processor SDK should provide a working network example. Please start the new thread asking for this:)

Finally, creating a CCS project from scratch requires you to add all necessary project setting to support our software. We don't actually recommend this. We instruct all users to import an existing project, rename it, and then go from there to work up your own application. Sorry, that's the best we have to offer at this time.

Todd

0 Dean Hofstetter over 6 years ago in reply to ToddMullanix

Expert 2585 points

Todd,

I've managed to update my project to use NDK V3.40. It required using work arounds from this E2E thread, plus reading all the release notes from NDK V3.00 to NDK V3.40. The "NDK 2.x to 3.x Migration Guide" was of little help, but perhaps that is because I'm not using POSIX. At any rate, here is a summary of my steps.

1. Download the Processor SDK (Processor-SDK-RTOS-OMAP138 05_03_00_07). This will supply NDK V3.40.1, plus the other components you'll need.

2. Change your project settings to use NDK V3.40.1, SYSBIOS V6.75.2, and XDCTOOL V3.51.01. You will also need to select Code Gen Tools V8.3.2 (provided with the SDK), or V8.3.3. Either one will work.

3. You'll need to add a new path to XDCTools -> Package Repositories. Add ${BIOS_CG_ROOT}/packages/ti/posix/ccs. Even though I'm not using POSIX, NDK V3.x insists on including "sys/time.h". For some reason TI seems it is reasonable for developers to manually add this path, instead of having it automatically included when NDK V3.x is include in your project. This is an argument I'm not going to win, just manually include it.

4. If your project uses the NDK Hook for when new IP addresses are added or removed (NDK->Hooks->Network IP Address Hook), the prototype of that function has changed. For NDK V2.x, the first parameter was of type IPN. For NDK V3.x it is now uint32_t. The NDK has evolved to using C99 data types, so you may have to include a new header file to pick up uint32_t (<stdint.h>).

5. If your project uses the NDK Hook for when the NDK aborts (NDK->Hooks->Stack Thread Delete Hook), the prototype of that function has changed. For NDK V2.x, the first parameter was of type HANDLE. For NDK V3.x it is now void *.

6. The prototypes for fdOpenSession() and fdCloseSession() have changed. NDK V2.x used HANDLE, NDK V3.x uses void *.

7. Many socket related functions have changed to add NDK_ to the front end of a function. For example, sendto() is now NDK_sendto(). htons() is now NDK_htons(). connect() is now NDK_connect(). Etc., etc.

8. All of the error codes returned by the socket functions have changed to add NDK_ to the front end. For example, EWOULDBLOCK is now NDK_EWOULDBLOCK. EHOSTDOWN is now NDK_EHOSTDOWN. Etc., etc.

9. NDK V2.x had a typedef defined PSA. That is no longer available in NDK V3.x. You'll have to replace PSA with (struct sockaddr *).

10. The TCP options for the function setsockopt() have changed to add NDK_ to the front end. For example, TCP_NODELAY is now NDK_TCP_NODELAY. TCP_SACKPERMITTED is now NDK_TCP_SACKPERMITTED. Etc., etc.

11. Build your project, and ignore any remarks regarding __PRU__

12. Note: My project doesn't use POSIX or any of the Ethernet functions that have been moved from the NDK to the NS. This is where the NDK 2.x to 3.x Migration Guide helps.

13: Note: I don't use any of the new SINetSock() and SINetifNDK() stuff. I believe this is only necessary if you need to use features provided by the NS.

A few more things for Todd Mullanix.

1. You've asked that I open a new E2E thread regarding many of my observations during this transition to NDK V3.40. I have no idea where to open that thread (this forum, some other forum)? Please take the lead from Steven Connell, and point the SDK team to this post, or you open a new one. That is what he did to start the ball rolling on getting the __PRU__ bug fixed.

2. You say your customers don't normally migrate components from one major version to the next major version. I disagree, it does happen and often. CCS V5 to CCS V8, SYSBIOS V5 to SYSBIOS V6, Code Gen Tools V7 to Code Gen Tools V8. All of these have been done by my team, and now it is time for NDK V2 to V3. If you want the latest and greatest tools, the latest and greatest bug fixes, the latest and greatest features, you are forced to upgrade. Sure you can stay on older versions for a while, but eventually you have to move. There are bug fixes included in NDK V3.40 that aren't available in NDK V2.26. I doubt TI is going to maintain the V2.x chain, therefore we are forced to upgrade to at least keep up with bug fixes.

3. I do appreciate you taking the time to help me out and provide a few clues to eventually solve my problem.

Thanks, Dean

Processors

Processors forum

RTOS/TMS320C6748: NDK migration