3 Replies Latest reply on Oct 18, 2020 11:46 PM by DheerajK_81

    Device Configurator and HAL/ PDL compatibility - use cases

    MiMi_1891471

      I'm new to Modus (2.2) and it while seems to be evolving rapidly, I ran into a vexxing error and wonder why this is:

       

      Device configurator builds for PDL, and HAL s based on PDL. But if you use the device configurator to configure the device, you can't use HAL functions because it thinks the pins or peripherals are in use.  This is further compounded by that fact that they actually are not in use,  since the PDL startup code does not initialize them.

       

      Having used other toolsets like STM32Cube that are similar, but do allow these tools and abstraction layers to be mixed, I find this very counterintuitive. Furthermore, the code to initialize the peripherals per the device configurator with either HAL, PDL or both should be executed in the device startup. It's boiler plate, so there does not seem to be any value in writing it from scratch.

       

      So I'm perplexed, there is lots of tooling here, but no obviously right way to use it. What are the recommended use cases with design flows?

        • 1. Re: Device Configurator and HAL/ PDL compatibility - use cases
          DheerajK_81

          You would decide to use the HAL when you want a generic interface that can be used across multiple product families. This would provide ease of use and portability to your application. But note that HAL is just a subset of the features supported by the PDL.

           

          Based on the requirement of your application, you would need to make a choice if you need to make use of the HAL or PDL. If you choose the PDL route, you can enable the resource in Device Configurator and configure it. But you won't be able to interact with this same resource using HAL, it will cause conflicts.

           

          You can choose to have HAL to interact with some hardware blocks, PDL for some others and that's okay. You need to be careful only when you are dealing with the same resource.

           

          ...you can't use HAL functions because it thinks the pins or peripherals are in use.

          When a resource is configured in the Device Configurator but not initialized in the code, HAL can't be used even though the resource is not being used, you are right. I will check with the software team to understand why this restriction exists.

           

          What are the recommended use cases with design flows?

          I would say the right way to use it will be completely dependent on the application. Use HAL whenever you don't need granular control over the hardware block you are interacting with. It will be much more simpler to write code in such cases. For blocks that need finer control, you can make use of PDL considering the large set of APIs available for it when compared to HAL.

           

          Based on the route you choose, you will usually stick to those APIs and I don't think you will want to intermix them. The reason being that, when you configure the parameters for a block in the configurator, config structures and other macros are created. You will need to call the _Init() functions of the PDL to make use of the generated configurations, you cannot take advantage of these generated structures in HAL. You cannot use any HAL APIs in these cases because they require the HAL object as the first parameter which gets initialized only after the init() function is successful (which it won't be if initialized through PDL).

           

          Note: There are some HAL APIs where obj is not required as a parameter and they just call underlying PDL APIs directly. For example, you can intermix HAL and PDL APIs of GPIO and you won't have any problems.

           

          Hope this helps

           

          Regards,
          Dheeraj

          • 2. Re: Device Configurator and HAL/ PDL compatibility - use cases
            MiMi_1891471

            Thanks for your reply, and confirming hey are in conflict. I think anyone using the configurator is looking for the fast path, and forcing them to use the lower level PDL is not the fast path. The layers should be complementary, look at what ST did with STM32Cube. I can use the configurator to shave days of bringing up a new device configuration and also use either the the higher level or lower level API when done.  The work done in the configurator applies to both. I've been a Cypress fan for years, but as designers we are competing for speed, and this toolset is a handicap as designed. It would make more sense for the configurator to target the HAL and / or the PDL, not just the PDL.

            • 3. Re: Device Configurator and HAL/ PDL compatibility - use cases
              DheerajK_81

              The reason that the configurator isn't targeting the HAL layer is because we believe it is sufficiently straightforward to use it and does not need a configurator to help setup. I think the only important thing the developer must take care when intermixing HAL and PDL is to not make a change in the PDL that would violate an assumption made by the HAL causing a conflict.

               

              We will see how we can make this experience even more seamless. Definitely appreciate the feedback!

               

              Regards,
              Dheeraj