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
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
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
