5 Replies Latest reply on Nov 10, 2020 9:04 AM by RakshithM_16

    which pins should be defined in Device Configurator and which pins should not?


      I am still at a loss about how to use Device Configurator. I thought that I would use it to define the usage of every pin on my board, just like I would with PSoC Creator. It seems to me that in MTB apps, that pins are defined in several places.


      I was graciously provided an example project for using a TFT panel the ST7789. That project uses the the mtb_st7789v library for driving an LCD. For that library, the pins for the LCD interface are defined in a data structure in main.c and passed into the library initialization function. The pin mappings for the TFT display were in libs\CY8CKIT-028-TFT\cy8ckit_028_tft_pins.h. In that same project, I enabled the retarget IO library. In that case, the UART pins were libs/TARGET_CY8CPROTO-062-4343W/cybsp_types.h. Who/what created that include file? Was that created for the BSP for the Cypress proto board I am using? Why weren't the UART pins defined in Device Configurator?


      In my project, there are three UARTs, two I2C busses, two SPI busses, a parallel interface TFT display with 4 control signals and 8 data signals, four analog inputs, a uSD card interface, a handful of GPIOs for LED control and reading switches. I was expecting to start my project by defining all these devices/pins in Device Configurator. From the example code I am seeing, this doesn't seem to be the right way to define the pins.


      So, I guess this all leads me to: Are there step by step instructions on how to define the SBCs and GPIOs that are used on a project?


      Any help is greatly appreciated.

        • 1. Re: which pins should be defined in Device Configurator and which pins should not?

          Hi JoLl_4741886,


          Let me try to help clear the confusion.

          If you are using PDL Driver (Peripheral Driver Library) in your ModusToolbox application, then the pins/peripherals need to be enabled in the Device Configurator.

          If you are using the HAL Driver (Hardware Abstraction Layer) in your ModusToolbox application, then your application is not dependent on the Device Configurator and should not be enabled there. The pins/peripherals need to be provided in your source code. The HAL APIs start with 'cyhal_'

          A similar discussion can be found here - Running Hello World with CY8CKIT-062-WiFi-BT using Modus Toolbox

          Was that created for the BSP for the Cypress proto board I am using?

          Yes, BSP is a layer over HAL to completely abstract your code from the device. Some of the most common pins like the debug UART pins, LED pins, buttons are defined here. These defines map to the appropriate pins for each target device. By using these pins, you need not worry about changing your code or configuration when you change the device. It should just work. As you are using a custom board, you can create your custom BSP about which you can learn here - Make Your Own BSP for Fun and Profit


          Finally about the CY8CKIT-028-TFT library, the library is designed for the CY8CKIT-028-TFT shield which is why the pinout of the shield is already present in the library. The TFT display library - display-tft-st7789v, does not restrict you to use the same set of pins. You can use your own pins according to your configuration in the pins structure. The pin structure and the way to initialize and use the library can be found here - GitHub - cypresssemiconductorco/display-tft-st7789v: This library provides code to support a 2.4 inch TFT LCD driven by …


          Hope this helps. Please let me know if you have any further queries.


          Thanks and Regards,

          Rakshith M B

          • 2. Re: which pins should be defined in Device Configurator and which pins should not?



            Rakshith is correct.


            Here is another way to look at it.


            If you use the Device Configurator (DC), you are using the PDL structure which allocates resources and makes connections to these resources to the pins at DESIGN_TIME.   Once you define it in DC, it will generate the code.


            The HAL structure can be created solely in your code.  There is no need to involve the DC.   It is a RUN-TIME feature.  The HAL code uses PDL calls.  The HAL also has a resource manager which locks down the resources when allocating them including the pins.   Therefore if you code tries to allocate the resource in the code again, the allocation will FAIL (with an error code).  To reuse the allocation, you need to deallocate first then to allocate it later in the code.


            Which better? ... (crickets).


            The PDL method has the advantage of you the designer using a tool to visually see allocations and some degree of signal flow.  IMHO, this is the big advantage of Creator's TopDesign method.   Since 99% of embedded designs have dedicated connections to external HW, the PDL will be just as fine.


            The HAL method is more like the majority of CPU architectures.   Since HAL structure allocation is occurring during RUN-TIME it can also be changed "on-the-fly" depending on the application needs.   Although this is not a commonly used feature, it can be done.


            To further complicate this discussion:  Both the PDL (using DC) and the HAL methods can be used in the same project.  I must state the following caution:  The PDL method doesn't use the HAL-style of resource allocation.  So be careful.



            1 of 1 people found this helpful
            • 3. Re: which pins should be defined in Device Configurator and which pins should not?

              Rakshith, thanks once again for your help. I have a glimmer of understanding how the PDL/DeviceConfigurator and HAL work. I will be relying heavily on example projects that use DC/PDL so I will go that route for the implementing the code controlling the communication blocks (UART, I2C, etc.).


              Regarding the TFT library... I was able to use it successfully for my project. I rewrote the low-level functions so that the port addresses and GPIO masks are calculated during compile time. I grouped all of the data signals in one GPIO port and all the control signals in another GPIO port. With this approach, the data write time is around just 29ns. Just 6 ARM assembly language instructions to write 8 bits of data to the controller. I don't think there is any way to access the display controller any faster than that.

              • 4. Re: which pins should be defined in Device Configurator and which pins should not?

                Len, thanks to you too for your help. You very clearly explained how when to use PDL vs HAL. Outstandinig!

                • 5. Re: which pins should be defined in Device Configurator and which pins should not?
                  Which better? ... (crickets).

                  Well, the answer to this question, in my opinion, is situational. Personally, I think for a beginner HAL would be more friendly as you have a smaller subset of APIs and your application depends only on the main.c file. HAL is easier to use. But an advanced user or someone who is familiar with the PSoC Creator environment might choose the PDL approach as it uses the Device Configurator and it provides APIs for better control over the peripheral. You can have more configuration options when PDL drivers are used which are not available in HAL yet.


                  Thanks and Regards,

                  Rakshith M B

                  1 of 1 people found this helpful