2 Replies Latest reply on Feb 25, 2019 9:11 AM by scotta_91

    What is the best practice for creating nested components?

    user_443952341

      I'm creating a custom component - a driver for a peripheral. I want to use an UDB based design, clocked at a specific rate so to accomplish this, I create component ```compUDB``` which is the "meat" of the component using UDB editor and then create ```compBase``` which uses ```compUDB``` and feeds it with a specific clock rate. (If there is a better way of creating an UDB-based component with a specific clock rate please let me know!)

       

      Anyway, I don't particularly want ```compUDB``` to be exposed to the end user of ```compBase```. Three also seem to be problems with ```compUDB```'s API headers not being available to ```compBase``` because they live in their own generated API directory in the project rather than being generated in a sub-folder of ```compBase```'s API.

       

      I wasn't able to find any information regarding nested component designs (I tried broad search online and looking into the PSoC Component Author Guide). Does the community have any words of wisdom regarding the issue?

        • 1. Re: What is the best practice for creating nested components?
          BoTa_264741

          I also wish to know if deep encapsulation of components is possible. So far, I believe that all components have same level of hierarchy and the Core components appear in same project root, and the only means to hide them from plain view is to set a visibility property ''show in catalog' in component->symbol->properties, which can be 'undone' by Creator option 'show hidden components'.

          /odissey1

          • 2. Re: What is the best practice for creating nested components?
            scotta_91

            So as I mentioned on another post a component can be implemented in one of 3 ways:

            Verilog

            UDB Document

            Schematic

             

            If you implement a component using a schematic, the underlying component's APIs will still be generated, and it is usually a good idea to create nice wrappers around them (specifically the start, stop, sleep and wakeup) so that users don't need to go hunting for the standard functions.  The user can still call the underlying component APIs of course, but that's not very user friendly.

             

            There is another item that should be mentioned here, schematic macros.

             

            If the item your building does not require any code, (you just want the component or components setup in a specific way) you can create a schematic macro.  This is just a shortcut for a particular setup of one or more components (and their wiring).  This basically is a lightweight component, where the user can modify the pieces after it is dropped.

             

            Select the items you want in the schematic, right click and generate macro.