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.

CCS: User input before building a library or prj -- How to?

Tool/software: Code Composer Studio

Can someone tell me if there is an console I/O such that a user could be queried and that input could then be used as an input to a function in CCS?  

Is this possible best done in something like Python and sent to a JSON or CSV file then brought into C?

Thanks

  • Hi Steve,

    I'm not quite sure I understand your use case. I originally thought that you were interested in stdin type functionality...but based on your headline, it looks like this input is something that you are looking to during build time? Can you explain what your main goal for this is?

    Thanks

    ki

  • Hi Ki....

    The vision was a way to query the user for arguments for say an algorithm/function or peripheral hardware setup, then have the code build and register that input somehow into variable (persistent) FRAM and then use that input to do specific customer functionality. 

    Thanks

    Steve

  • Ah, ok. This is not natively supported by CCS during a project build. Maybe you can do some tricks with the pre-build steps but I am not aware of any existing examples

    ki 

  • Ki....

    Ok ....so maybe that is a little beyond what I can do.  Let me ask this then.  I have created a library and it contains a "bunch" of code.  Is there an input mechanism (pre-processor ?? with user input or maybe a text file) to somehow tell it which pieces of MSP hardware to use so that when I compile it to create the .lib it will compile out that which I don't need?

    If so how do I go about this?

    Steve

  • Here is one suggestion to consider.

    In the library source code have C code that looks like this ...

    /* file.c */
    
    #if   defined(HW_CONFIG_1)
    /* do something one way */
    #elif defined(HW_CONFIG_2)
    /* do the same thing another way */
    #else
    #warn "No HW configuration for this thing!"
    #endif

    When you build it, use the compiler option -D to indicate the build time decision on which HW configuration to use.  For example ...

    % armcl -DHW_CONFIG_2 /* other options here */ file.c

    If you forget to specify the HW configuration, or spell it wrong, you'll a diagnostic similar to ...

    "file.c", line 8: warning: #warning directive: "No HW configuration for this thing!"

    You may want to create different CCS build configurations, one for each HW configuration.  Each CCS build configuration could correspond to a group of -D settings that match a particular configuration of the hardware.

    Please let me know if this suggestion resolves the problem.

    Thanks and regards,

    -George

  • George..

    Is there a way to move the -D build decision to the user application code?  Could I do what you suggested, perform a build then send the .lib to the user (without the source) then they could do something at there end which would either enable HW_CONFIG_1 or 2?

    Steve

  • I presume you need to supply your customers with a combination of header files and libraries, or maybe just one library.

    The header files can use the same -DHW_CONFIG technique I describe in my last post.

    As for the library ... I can think of two ways to go.

    One way ... Supply a single library.  Adopt a naming convention for the functions in the library.  The first part of the function name is the corresponding HW configuration.  Your customers call the functions as needed.  

    The second way ... Supply multiple libraries.  Each library corresponds to one HW configuration.  These libraries contain functions of the same name.  Your customer chooses which HW configuration to use by choosing the corresponding library.

    I'm sure there are other variants to consider.

    Thanks and regards,

    -George