Freeing default UART ISR in ESP-IDF v5.2

johnab
Posts: 3
Joined: Fri Jun 02, 2023 7:34 pm

Freeing default UART ISR in ESP-IDF v5.2

Postby johnab » Fri Jun 02, 2023 8:11 pm

I am trying to create a new UART interrupt service routine and have looked at many examples and the ESP-IDF documentation on how to do this. Everything I have seen points to the function uart_intr_free() as the function to call in order to free the default handle and then assign your own using esp_intr_alloc() or uart_intr_alloc(). However, in version 5.2 of ESP-IDF framework it seems that the uart_intr_free function has been deprecated as I (and more importantly the build chain) cannot find it. It was not too hard to setup esp_intr_alloc() in place of the also missing uart_intr_alloc(), but uart_intr_free() requires access to the UART object and its member parameters. This object and its members are all private meaning I cannot reference the default handle by name nor can I free a non-default handle without access to uart_intr_free().
I have found no existing documentation to resolve this issue and was wondering if anyone had advice on how to proceed.

ESP_Sprite
Posts: 8884
Joined: Thu Nov 26, 2015 4:08 am

Re: Freeing default UART ISR in ESP-IDF v5.2

Postby ESP_Sprite » Sat Jun 03, 2023 6:28 am

Unless you install the UART driver beforehand, the UART for stdout doesn't use any interrupts (it's a simple polling driver) so you shouldn't have to uninstall anything.

johnab
Posts: 3
Joined: Fri Jun 02, 2023 7:34 pm

Re: Freeing default UART ISR in ESP-IDF v5.2

Postby johnab » Mon Jun 05, 2023 12:54 pm

ESP_Sprite wrote:
Sat Jun 03, 2023 6:28 am
Unless you install the UART driver beforehand, the UART for stdout doesn't use any interrupts (it's a simple polling driver) so you shouldn't have to uninstall anything.
Do you not need to install the UART drivers for the peripheral to work? I am using non-default settings (baud, parity, stop bits, and data bit length) so how would I set that up without installing drivers?
Overall it seems counterintuitive that I have to seemingly not setup UART in order to use UART interrupts.

ESP_Sprite
Posts: 8884
Joined: Thu Nov 26, 2015 4:08 am

Re: Freeing default UART ISR in ESP-IDF v5.2

Postby ESP_Sprite » Mon Jun 05, 2023 2:25 pm

If you want to set up the uart parameters, you're probably better off using the HALlayer. (Note that it says use in applications is unsupported, but I'd say your setup of relying on a driver uninstall to keep the settings intact is more unsupported-er.)

johnab
Posts: 3
Joined: Fri Jun 02, 2023 7:34 pm

Re: Freeing default UART ISR in ESP-IDF v5.2

Postby johnab » Mon Jun 05, 2023 2:34 pm

ESP_Sprite wrote:
Mon Jun 05, 2023 2:25 pm
If you want to set up the uart parameters, you're probably better off using the HALlayer. (Note that it says use in applications is unsupported, but I'd say your setup of relying on a driver uninstall to keep the settings intact is more unsupported-er.)
It feels like this doesn't answer my original question. After a driver install specifying the UART operating parameters, is there no longer a way to use a custom interrupt? Should I convert back to a previous version of ESP-IDF where this was still possible? Why was this functionality removed?
I see no reason why I should have to use an unsupported API module in order to do something as standard as configuring a UART interrupt.

ESP_Sprite
Posts: 8884
Joined: Thu Nov 26, 2015 4:08 am

Re: Freeing default UART ISR in ESP-IDF v5.2

Postby ESP_Sprite » Tue Jun 06, 2023 2:07 pm

johnab wrote:
Mon Jun 05, 2023 2:34 pm
It feels like this doesn't answer my original question. After a driver install specifying the UART operating parameters, is there no longer a way to use a custom interrupt? Should I convert back to a previous version of ESP-IDF where this was still possible? Why was this functionality removed?
I see no reason why I should have to use an unsupported API module in order to do something as standard as configuring a UART interrupt.
You are right, it doesn't answer the question. Her'e's why an answer is hard.

The issue is that the previous API had two functionalities that clashed: one is to act as a high-level driver, the other one is to act as a low-level driver. Installing a driver handle is a high-level operation, installing an interrupt is a low-level one. It was kinda-sorta implicit that you shouldn't use the two combined, and having to do things like relying on a partial driver uninstal to keep the uart parameters untouched is really relying on undefined, unspecified behaviour, but that happens to be the only sane way you can do things in the old system.

If you think that is a shitty architecture, we agreed, so we split it into an actual driver (that doesn't allow you to mess with the internally-used interrupt anymore), and the HAL that allows you to do the low-level peripheral poking. Unfortunately, with HAL layers, we do not have the same guarantees wrt semantic versioning as with the rest of ESP-IDF (which is that the API only changes on major revisions, e.g. 4.x.y -> 5.x.y, not 5.a.b -> 5.x.y), hence the 'unsupported' warning. I personally disagree with marking it entirely unsupported because of that and I know in practice the HAL layer is pretty solid, but that's how it is now.

Who is online

Users browsing this forum: No registered users and 58 guests