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.

IWR1843BOOST: IWR1843BOOST

Part Number: IWR1843BOOST

Hi,

I'm writing my own code, based on 18xx OOB demo from the HTB & SDK.  As in the docs, I'm copying bits (e.g. from SDK) to a new location so I can rename/change etc without affecting the originals.  I'm at the stage where I need to make things tidier, so have 2 questions. NB this is a CCS 11.1 query, rather than IWR.

1)

How do I make a "path shortcut", like the <ti/pakages> construct used in #DEFINE statements?  I want to make something like a "myLibs" to replace e.g. "C:/a/b/c" etc.  I've managed to add "preferences:build:environment", but that doesn't seem to be how its done, or at least it doesn't work and I get "can't find path" errors at compile time.

2)

Similarly: if I put new files (*.c) in the project, then all OK.  However, I want to put everything in libraries - just as files fetched from within the SDK, where they're not explicitly mentioned/called in the project, so presumably there's a "path" or similar mechanism to do this?  I have things like the functions are mentioned as EXTERN in the .h file included in the main code.  Accessing the .h seems fine.

I have managed to add the relevant path into "properties:compiler&linker" flags but, again, this doesn't seem to be how its done - I get linker errors for un-resolved symbols for the functions etc defined in the (now in a separate library folder) .c files.

Maybe these sorts of things are covered in some on-line training?  I've see the getting started guide, but I'm getting deeper in bow.

many thanks

Alan Milne, UK

  • Hello Alan,

    1)

    How do I make a "path shortcut", like the <ti/pakages> construct used in #DEFINE statements?  I want to make something like a "myLibs" to replace e.g. "C:/a/b/c" etc.  I've managed to add "preferences:build:environment", but that doesn't seem to be how its done, or at least it doesn't work and I get "can't find path" errors at compile time.

    I believe you are referring to build variables:

    https://software-dl.ti.com/ccs/esd/documents/ccs_portable-projects.html#variables

    You can create build variables that point to a directory and then use the variable in your build options - such as youe include search paths or library paths

    2)

    Similarly: if I put new files (*.c) in the project, then all OK.  However, I want to put everything in libraries - just as files fetched from within the SDK, where they're not explicitly mentioned/called in the project, so presumably there's a "path" or similar mechanism to do this?  I have things like the functions are mentioned as EXTERN in the .h file included in the main code.  Accessing the .h seems fine.

    You mentioned libraries. You can create a library project that will generate a C library that you can reference from your main project by specifying the path to it in the linker options.

    I suggest talking a look at Chapter 6 of the CCS User's Guide:

    https://software-dl.ti.com/ccs/esd/documents/users_guide/index_project-management.html

    Several sections in there should contain the information you are looking for.

    Hope this helps

    ki

  • Hi Ki,

    thanks for the reply and links - always nice to see it in print.  This is all in exactly the right place (was already looking at chapter 6), but I haven't succeeded yet.  I suspect that I'm pretty close, and its going to be something trivial or too obvious to see!  I think I just need to keep trying variations for a while and it ought to work.

    I'll leave this open for a couple of says if you don't mind, so there's a thread to attach any further questions to.

    thanks

    Alan

  • Sounds good. Please let me know how it goes and if you need clarification or more details on anything.

    ki

  • Hi Ki,

    well, I think I've tried everything, but it still doesn't work.  Hopefully something trivial I'm doping wrong (so hard to see!), maybe you'll spot what it is...

    In the attached doc: the commented #include works (i.e. .h IS where it says it is, and is OK), the other doesn't.  I've tried all combinations of "environment" and "variables" in both "preferences" and "properties". I've show "properties:variables" so you can see what I'm entering ... and I've tried all possibilities of string/path/directory and so on.  At the end is the error massage: can't find the .h.

    This is (first) to get the <> format to work for the *.h - although the links you sent seem to be saying that for path&directory, I should also be setting what's needed for linking.  I've been round all the possibilities I can find on that one to, also without success as yet.

    Darn - it won't let me select the doc file to attach - I've done this before, I thought under INSERT - LINK or similar, but can't seem to do it this time.  I'll try to add this later, as you need to see the details.

    //#include <d:/dram_5/libraries/ti/mmw/cmplxmix_Mss/cmplxmix_Mss_Dsp.h>

    #include <DRAMlibraries/cmplxmix_Mss/cmplxmix_Mss_Dsp.h>

     

     

     

    Description        Resource            Path      Location             Type

    #1965 cannot open source file "DRAMlibraries/cmplxmix_Mss/cmplxmix_Mss_Dsp.h"              DRAM_cmplxMix_mss_main_Dsp.c              /DRAM_cmplxMix_18xx_mss_Dsp          line 637 C/C++ Problem

    OK, paste worked a bit, that'll help a little.

    thanks,

    Alan

  • #include <DRAMlibraries/cmplxmix_Mss/cmplxmix_Mss_Dsp.h>

    Oh I see what you want to do. My apologies, I misunderstood your use case. You want to create define a variable to use in your actual source code, not in the project settings.

    The technique I suggested is for variables to be used in the project settings.

    To use variables in your source code, you'd probably want to define a preprocessor macro

    But I'm not sure if the compiler supports trying to use the macro in a #include. I would need to check with the compiler experts.

    ki

  • But I'm not sure if the compiler supports trying to use the macro in a #include. I would need to check with the compiler experts.

    I confirmed that this would not work.

    The best is to specify the DRAMlibraries build variable in the compiler --include_path option and then specify:

    #include "/cmplxmix_Mss/cmplxmix_Mss_Dsp.h"

    Thanks

    ki

  • Hi Ki,

    no problem, can be easy for words to mean different things to different people ... would be much easier if we could sit in front of the project with a coffee!

    I'll look at include_path and see what I can manage.  If nothing else, I'd have thought that I may be able to "decypher" the syntax already used i.e.:

    <ti/demo/xwr18xx/m...   format, and see how the "ti" bit of the path is defined somewhere in preferences or properties - so I could copy the form, but I haven't actually seen that.

    There was the second part to my question, perhaps more on how you were originally thinking: how do I specify where files are, so compile & link can find them - i.e. when say .c file is in a library somewhere, as opposed to in the project itself.  Again, I've been trying the various things I can find for paths, file locations etc in preferences and properties, but so far without success.

    I get the "unresolved symbols" error, for names in the various .c files - I'm not sure if this is just at link time, or whether the compiler hasn't found them either.  For completeness ... this all works if I put the files in the project, so all the other mechanisms e.g. EXTERN etc seem OK, its just that the build can't find the libraries.

    many thanks

    Alan

  • Hi again Ki,

    success on the first part!  Rather than trying to define my own "path name" i.e. DRAMlibraries = something then include <DRAMlibrarie... ,use the properties:compiler:include pathe etc setting, then #include, but without the "front bit" of the path, this being supplied via properties.  Got it!

    Always the problem when delving deeper into how tools work: you have to know how it wants you to ask the question, which affects what the answer is .... all part of the tool training the user!

    Just need to sort out compile/link with files in libraries, an I should be ready to go.

    thanks

    Alan

  • <ti/demo/xwr18xx/m...   format, and see how the "ti" bit of the path is defined somewhere in preferences or properties - so I could copy the form, but I haven't actually seen that.

    "ti" is just a folder. It is the start of a relative path.

    For example, lets look at the below:

    In the Include Options, there is the below path:

    ${COM_TI_MMWAVE_SDK_INSTALL_DIR}/packages

    COM_TI_MMWAVE_SDK_INSTALL_DIR is a build variable that is set to whatever the mmWave SDK intall directory is. In my environment, it is:

    C:/ti/mmwave_sdk_03_05_00_04

    Hence the include path expans to:

    C:/ti/mmwave_sdk_03_05_00_04/packages 

    Now lets take a look at the below include statement:

    #include <ti/drivers/soc/soc.h>

    We can see that soc.h resides in:

    C:/ti/mmwave_sdk_03_05_00_04/packages/ti/drivers/soc/soc.h

    Since we already have C:/ti/mmwave_sdk_03_05_00_04/packages in the include search path, we can just use a relative path from that directory. Something like: "ti/drivers/soc/soc.h". Or:

    #include <ti/drivers/soc/soc.h>

    That is why the above include statement works.

  • success on the first part!  Rather than trying to define my own "path name" i.e. DRAMlibraries = something then include <DRAMlibrarie... ,use the properties:compiler:include pathe etc setting, then #include, but without the "front bit" of the path, this being supplied via properties.  Got it!

    Ah you already figured it out. I should have read your second post before replying to your first.

    Anyway glad to hear you got it working now!

    Thanks

    ki

  • Hi Ki,

    great answer thanks - I may be getting the hang of this now.  So, I've tidied out everything I tried before, and added my library as a build variable, then using this to set the PATH details for both the compiler and linker ... assuming that's how it finds everything. This looks llike:

    I've also added paths for the next level of the library i.e. dpm (where I'm working at the moment). This seems to be how the rest is done, i.e. I can't just specify the "start" of the path, I need explicit entries for each sub level?

    Presumably I've still got something wrong here, as I'm still getting messages for unresolved symbols - those in my dpm library & file.  As said, this works OK with the dpm.c file IN the project, but not once I've moved it out to a library.

    Something more I need to understand, I presume?

    many thanks

    Alan

  • I've also added paths for the next level of the library i.e. dpm (where I'm working at the moment). This seems to be how the rest is done, i.e. I can't just specify the "start" of the path, I need explicit entries for each sub level?

    Yes. The compiler/linker does not do a recursive search (i.e. does not look in all the subdirectories)

    Presumably I've still got something wrong here, as I'm still getting messages for unresolved symbols - those in my dpm library & file.  As said, this works OK with the dpm.c file IN the project, but not once I've moved it out to a library.

    How are you referencing the actual library file in your project? Did you explicitly add it to the project? Or did you add it to the --library list? 

    ki

  • Hi again Ki,

    this is where learning the exact terminology used by the tool becomes important, so I can give you the information you need...

    As per our last mail, I had added my paths by putting them into the compiler & linker include options & search paths, NOT  the linker library area (hope this shows on previous screen shots).

    I've now added into the linker library bit ... and for some reason, I get a different response today: adding the library by selecting the variable was OK, but when previously I had tried the EXTEND option to add the sub-directory, it came up with an error "has to be in ?? format" - of course it hasn't given me the error today so I can't tell you exactly what it was!  Obviously, I've change or corrected something else in the meantime.

    OK - so I've got entries under LIBRARIES - but now rebuild fails saying it hasn't got permission to read the directory, error 6001.  Interesting, as I know it can access the files to compile the .h's.

    I hope that answer what you're asking re project & library additions.  In chapter 6 of the docs, it also talks about resource:linked resources - in case that's where you mean.  I can add the library here, but it doesn't fix the problem.

    many thanks

    Alan

  • I see you added ${DRAMlibraries} and ${DRAMlibraries}/dpm to the --libraries options. Those are simply directories, are they not? Note that this option is looking for the name of the actual library file and NOT the path to it

  • Hi ki,

    perhaps go back a step or two: forgive me, I'm not a software engineer!  My background is in dsp algorithms, mostly with FPGA implementations and more recently overall system architecture - yes this involves software, but others actually do the coding - so I may not use the terminology correctly!  I have used eclipse before for the embedded processor in my FPGA - but in a VERY much simpler configuration, so I know there is much to learn.

    What I need to do, is to copy out bits of the SDK (and also add my own completely new functions), and to have these in separate directories i.e. not actually in the project directory itself.  I need to be able to tell the compiler & linker how/where to find these so the whole system is created.  I'm assuming this is not too dissimilar to how it accesses all the bits of the SDK which it needs?

    So, I have files in separate directories (yes, I was calling these libraries .. probably wrong and there's more I have to do) which I want to bring into the project at comiple&link time.  Unless I've got it completely wrong and this is not how it all works!

    many thanks

    Alan

  • What I need to do, is to copy out bits of the SDK (and also add my own completely new functions), and to have these in separate directories i.e. not actually in the project directory itself.  I need to be able to tell the compiler & linker how/where to find these so the whole system is created.  I'm assuming this is not too dissimilar to how it accesses all the bits of the SDK which it needs?

    So, I have files in separate directories (yes, I was calling these libraries .. probably wrong and there's more I have to do) which I want to bring into the project at comiple&link time. 

    Ah, I get it now! Thanks for the clear explanation. You don't have an actual static library file but instead wish to referencesource files in separate folder (outside the project folder) to your project so that they will be compiled with the rest of the source files in the project folder. This is called "linking" source files to the project:

    https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_project-management.html#adding-or-linking-source-files-to-project

    Linked files can reside outside the project folder. The project simply has a reference to them. They will be part of the project build. 

    You can remove the additional options you added to the linker options (lbrary search path and libraries options). You just need the include search path in the compiler options.

    Let me know if this is what you are looking for,

    Thanks

    ki

  • Hi ki,

    I wondered if perhaps I was confusing things with the use of terminology!

    That gives lots more activity now in the CONSOLE window.  I still don't build without errors, but I think these are being caused by how I've copied bits of directories, renames etc.  I can put the .c file back into the project and its A-OK, so I suspect you've answered my question completely, and its now down to me to sort out the rest.

    Just for interest (and do to point to docs if that makes more sense that writing here) ... as obviously I don't have what CCS is expecting as a library, static or otherwise, is there any great advantage of making a proper library? And if so, how?

    As before, I think I'm nearly there for this question, but I'll leave open for a day or two longer just in case!

    many thanks

    Alan

  • Just for interest (and do to point to docs if that makes more sense that writing here) ... as obviously I don't have what CCS is expecting as a library, static or otherwise, is there any great advantage of making a proper library? And if so, how?

    There are a variety of reasons for using a library. From my experience, the most common reason is when a third party develops software module (like drivers, kernel, etc) that they wish to provide (sell) to others (customers) so that they can integrate into their application, but they do not wish to provide the actual source for various (IP) reasons. The third party can then simply provide the generated object files from the compiled source in a library format (a static library is just a collection of object files) along with the required header files so that the customer can make function calls to the code in library and then link the library in during the linking phase. Some vendors will even strip out much the debug symbols from the library to protect IP. This would make the code in the library harder to reverse engineer at the cost of providing very little debug visibility when stepping through the library code during debug.

    Another reason is modularity. If you have multiple groups working on different modules for an application and the various groups will not modify each others code, then working with libraries can be easier. It is easier to just share a single library of your module instead of having people include all the separate source files into their project. It can also make building faster if your need to clean the whole project. If you have all the individual source files in the project, then it would have to compile them. If only a library is being included, then there is no re-compliation of the code in the library. It would just be linked in again during the link phase.

    There are also other reasons like keeping the number of source files in a project small, which helps for project navagation and CCS performance. Of course the files in a library would be the ones that you are not actively working on.

    The above are just some reasons. Hope that helps

    ki

  • Hi KI,

    got, understand & agree with all that!  I still don't have an error free build, but as far as I can see this is all to do with the WHAT I'm trying to do, not the HOW, which you have answered.  I'll close this thread now - many thanks for your help!

    Alan