1 2 Previous Next 20 Replies Latest reply on Mar 26, 2020 5:25 PM by PaSw_2578827

    Include Cypress Headers in Library Project

    PaSw_2578827

      I'm trying to create a library project for source that will be reused across a few platforms (PSoC6 and PSoC4). But I haven't been able to find a way to include any Cypress specific header files. For normal application projects these files all get pulled in when the source is generated by PSoC Creator, is there a way to manually include necessary header files so I can at least use Cypress #defines in my library?

        • 1. Re: Include Cypress Headers in Library Project
          LePo_1062026

          PaSw,

           

          The project.h file and all the files referred to in it are generated based on the application.  In many cases, the constants and other references can change as your application build changes.  For example:  BCLK__BUS_CLK__HZ can change if you define a different BUS_CLK in the Clocks DWR panel.

           

          I realize you're trying to test out your library .h and .c files independent of the project.  This can be done with a "compile-only" if you don't need project.h defines.

           

          I've created library files (.h and .c) before and I try to avoid calling project.h or any defines listed in the project.

          If I must use anything defined in project.h in my library files, I create a demo project with calls to the library files.  I compile the project (with TopDesign application) and the library .h and .c files get tested with the project.h defines.

           

          Are there specific project.h defines you want to access?  There might be an alternate method.

           

          Len

          • 2. Re: Include Cypress Headers in Library Project
            PaSw_2578827

            Specifically looking for cypress system level defines (in the PDL they are mostly in cy_syslib.h), for example I can't use and cy_ types or cy_ registers, or CY_ definitions. In the case of the PSoC6 I can't use any IPC stuff.

             

            I can find the headers in the PDL and manually copy them in but that doesn't seem very portable, I'm just wondering if there is a 'correct' way to do it. An alternative approach is to build the library as a component, but that's extremely cumbersome to compile and debug.

            • 3. Re: Include Cypress Headers in Library Project
              LePo_1062026

              PaSw,

               

              I've built components too.  In fact, some of my library functions started out as components with NO schematic elements.  Since they didn't need calls to project.h then it made more sense to remove the component aspect.

               

              If you need certain calls to the underlying PDL calls, you can set the Build Settings...\Compiler\General\Additional Include Directories

              To the directory where the PDL files you're interested are located.

              The downside is that you are tied to the PDL version you select.

               

              Len

              • 4. Re: Include Cypress Headers in Library Project
                PaSw_2578827

                Yea I tried including the PDL file directly but it's not ideal but it could work. I ran into some issues with it looking for the "cy_device.h" file, which I think is a generated file, along with that the PSoC4 doesn't use the PDL so that's a whole other ball game.

                 

                I think the component strategy might be a better approach for now, it's just unfortunate that components are so difficult to compile and debug.

                • 5. Re: Include Cypress Headers in Library Project
                  LePo_1062026

                  PaSw,

                   

                  The component strategy might be a better approach for now.

                   

                  I'm within a few days of release to the forum with a library that includes library functions and one component.

                  As I mentioned in an earlier post, the library functions used to be components.  If found that there was a limited connection in the function calls to other components.  I was able to remove the component structure and make them library calls once I installed a new function that allowed the component references by using a callback function.

                  For example, my library functions used GetChar() and PutChar() inside them.  By creating a callback function that needs to be executed early at initialization, the designer inserts the pointers to these functions in the callback.  When the library function is executed, the internal function code executes the callbacks to GetChar() and PutChar().

                   

                  Hope this helps.

                   

                  Len

                  • 6. Re: Include Cypress Headers in Library Project
                    PaSw_2578827

                    Follow up question (and perhaps this warrants a new thread). I'm porting into a component which should actually work fairly well but I'm having an issue with one thing. How do I include common source code along with platform specific code?

                     

                    90% of my code is platform agnostic but one or two files needs to be rewritten depending on the target hardware. Thankfully it's easy to make target specific code in a component but I can't get it to pull in the generic API code unless I also make it target specific (in which case I would need multiple copies of it which makes it painful for updating).

                     

                    I tried adding the generic code as an API doc with the 'Target Generic Device' box ticked, but when I added it to an application it ignored that and just used the device specific code instead (I want it to use both). This is my preferred method if I can make it work.


                    My second option was to create a second component that has all of the generic code and then add both components to the project. This works but it is super messy and I need to add the name of the generic component as a parameter for the platform specific component in order for it to find the the header files.

                    • 7. Re: Include Cypress Headers in Library Project
                      LePo_1062026

                      PaSw,

                       

                      There are two ways to do this that I'm aware of.

                       

                      Option 1

                      In the Components tab of the Workspace Explorer select your Component (Shown here as Term_v2_2).

                      Right mouse button click on Add Component Item ...

                      On the Add Component Item window select either API C File or API Header file.

                      As you know, Selecting Target generic device will add a file in the API directory of your component.

                      If Target generic device is deselected, you can select the Family, Series and/or Device to make the file specific to a Target.

                      As you can see in the component Term_v2_2 shown above, I can create both generic and specific API files.  When the component gets called and built, both the generic and specific items get pulled into the project.

                       

                      Option 2

                      If you create only general API files, there are Cypress-defined #defines for the Family/Series/Device that are generated when the project is assigned a device.  You can use these defines to perform conditional compiles.  The down-side with this approach is that the API code can get pretty bloated with compile-disabled code.

                       

                      Len

                      • 8. Re: Include Cypress Headers in Library Project
                        PaSw_2578827
                        As you can see in the component Term_v2_2 shown above, I can create both generic and specific API files.  When the component gets called and built, both the generic and specific items get pulled into the project.

                        I have found this not to be the case, that was my first attempt also but if API files exist for both the generic device and a specific device it prefers the device specific files and ignores the generic device API files.

                         

                        Len, I appreciate your responses.

                         

                        Thanks

                        • 9. Re: Include Cypress Headers in Library Project
                          LePo_1062026

                          PaSw,

                           

                          Question:  Are the file names the same in the generic and specific folders?

                          If so.  This might be the reason why Creator favors one over the other.  In this case, rename the generic files.

                           

                          Len

                          • 10. Re: Include Cypress Headers in Library Project
                            PaSw_2578827

                            They are not the same filenames. Even if I just add a simple 'test.c' file in the generic target API folder it doesn't get included in the generated source. Have you been able to achieve this? Is it possible there's a setting I'm missing, seems like it should be available functionality.

                            • 11. Re: Include Cypress Headers in Library Project
                              LePo_1062026

                              PaSw,

                               

                              Sorry.  I thought Cypress would include both.

                              I added "PaSw_test.h" in my Component's Family specific directory but it does not get included during the "Generate Application" phase.

                              Maybe Cypress Tech can provide a solution.

                               

                              Len

                              • 12. Re: Include Cypress Headers in Library Project
                                LePo_1062026

                                PaSw,

                                 

                                I haven't given up yet.

                                 

                                A thought:

                                I know you are trying to avoid repeating the same code across multiple Family specific configurations.  Hopefully you can achieve this.

                                I have an idea.

                                • Place the generic code in separate .h and .c files.  Locate it somewhere in the Component directory.
                                • DO NOT include the generic .h and .c files as Target generic device.  Therefore there is no API folder at the root of the Component.
                                • Include these generic files under EACH Family/Series/Device as "Add Existing" instead of "Create New".  Hopefully in this case, the generic files only exist ONCE on the Component's directory but each specific configuration will logically include it.
                                • Add the Family/Series/Device specific files under each configuration as needed.

                                 

                                (Shoulders shrugged!?)

                                 

                                Len

                                • 13. Re: Include Cypress Headers in Library Project
                                  PaSw_2578827

                                  Great thought but it seems like when you use the "Add Existing" feature Creator makes a copy of that file in the target specific folder, it does not reference the original file. I guess I'll have to stick with making the common code be a separate component, that works ok, it's just super messy at least in part due to the prefix that Creator adds when it generates the common code.

                                  • 14. Re: Include Cypress Headers in Library Project
                                    LePo_1062026

                                    PaSw,

                                     

                                    I agree.  I personally dislike having multiple copies of the common code in the specific API folders.

                                    If I make a change to the common code, I have to make sure that the change is duplicated in EACH copy in the specific folders.  Yuck!

                                     

                                    ... just super messy at least in part due to the prefix that Creator adds when it generates the common code.

                                    Do you know about the Doc.APIPrefix parameter in the .cysym file?  Maybe this will help.

                                    Len

                                    1 2 Previous Next