Switching 2 pins between UART, GPIO and switch others between ADC and GPIO

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
JoLl_4741886
Level 3
Level 3
10 replies posted 10 sign-ins 5 replies posted

Platform: CY8CPROTO-062-4343W, MTB 2.2

1) I need two pins to function as either GPIOs for bit-banging a proprietary protocol,  or as a high-speed UART. I need to switch between these functions in real time. What is the "cleanest" way to implement this: HAL, PDL-only, PDL plus DeviceConfig?

With HAL, the resources are allocated in real-time, so I'd need to "free" the UART or GPIOs before initializing/allocating the pins for the other function, right?

2) I have a similar situation with a 4-pin resistive touch display panel where I have to switch pins between ADC inputs and GPIO outputs. Here I am thinking of also using HAL but this would require allocating and freeing the ADC and GPIOs on every scan of the touchscreen. Would using PDL be cleaner?

I'm still not clear when to use HAL or PDL. I wish there was a checklist that would help answer that question. I feel like using the HAL is always the the best approach... except when isn't.  🙂 

Thanks for any help.

0 Likes
1 Solution
JoLl_4741886
Level 3
Level 3
10 replies posted 10 sign-ins 5 replies posted

For now, I'm trying HAL code that allocates the pin for one function, performs the function (ADC read or drive GPIO) and then frees the pin, using cyhal_adc_free() or cyhal_uart_free(). Kind of clumsy but the PDL implementation I was trying was awkward in other ways.

[Update] It turns out that I could not use the HAL for the ADC/GPIO case because the HAL APIs are limited to the dedicated analog GPIO port (Port 10 on my PSoC6). My project uses pins from port 9 as ADC inputs therefore I had to route them to AMUXBUSA and AMUXBUSB. I couldn't find HAL APIs that support that. I'm glad that the PDL has a section with examples of routing Port 9 pins or I don't think I would have made it work.

View solution in original post

0 Likes
4 Replies
ChRe_4711096
Level 4
Level 4
50 replies posted 25 replies posted 25 sign-ins
  1. Where is the decision between UART and proprietary protocol made?
    1. If it comes from a hardware signal, AND if you can place the UART on a port that supports SmartIO, route the UART signals and the selection signal through SmartIO
    2. if the decision is made by the CPU, use Cy_GPIO_SetHSIOM(...) to switch the pins between UART hardware and CPU control. Otherwise, use the pin's output enable input.
  2. You should be able to switch the GPIO drive mode between analog in and GPIO out using Cy_GPIO_SetDrivemode(...)

Now, if switching back and forth is done by the CPU, I don't see any huge difference between HAL and PDL. If the surrounding code is mainly written with PDL, use PDL. If not, use HAL? Make it look reasonably consistent?

0 Likes

Thanks for the response.

The decisions to switch pin functions comes from the CPU. The desire is to use HAL since the example code we're using for other functions uses HAL.

It was my impression that enabling a function in HAL would allocate the pin to that function. I thought that trying to use the same pins for another function in HAL would result in an error. My impression was that you have to free the resource (such as with cyhal_uart_free() or cyhal_adc_free()) before using it for another function such as GPIO. In my opinion, this would make scanning the touch panel messy since the could would need to re-init the ADC, perform a scan and then free the ADC for every X and Y scan of the touch panel. OTOH, the cleanest ADC example code is done in HAL which pushes me in that direction.

I can read the ADC just fine with example code using HAL, now I need to switch the pins to GPIOs. You say just use Cy_GPIO_SetDriveMode() which is PDL. I was told by Cypress folks not to mix and match HAL and PDL code because there would be conflicts. Is this not true?

0 Likes

I guess no library is really made for this type of functional multiplexing.

You'll need a piece of code that owns all the relevant resources and can do proper switching between the different functions. In the end, you'll have some component that steals a GPIO from the ADC (which then cannot perform proper measurements on that pin), do something with it, and then hand it back to the ADC. From the HAL's point of view, this is a clear conflict, but a managed one. It's hard to tell what happens, and what's best, without knowing more details about your project's and code's structure.

 

0 Likes
JoLl_4741886
Level 3
Level 3
10 replies posted 10 sign-ins 5 replies posted

For now, I'm trying HAL code that allocates the pin for one function, performs the function (ADC read or drive GPIO) and then frees the pin, using cyhal_adc_free() or cyhal_uart_free(). Kind of clumsy but the PDL implementation I was trying was awkward in other ways.

[Update] It turns out that I could not use the HAL for the ADC/GPIO case because the HAL APIs are limited to the dedicated analog GPIO port (Port 10 on my PSoC6). My project uses pins from port 9 as ADC inputs therefore I had to route them to AMUXBUSA and AMUXBUSB. I couldn't find HAL APIs that support that. I'm glad that the PDL has a section with examples of routing Port 9 pins or I don't think I would have made it work.

0 Likes