Fix timerAttachInterrupt() and timerDetachInterrupt() in esp32-hal-timer.c

[sweetlilmre]

Description of Change

This PR fixes the timerAttachInterrupt() and timerDetachInterrupt() functions in esp32-hal-timer.c.

In timerAttachInterrupt() the change:

• removes the unnecessary timer_info_t structure
• removes the allocation of the structure in timerAttachInterrupt()
• removes the call to timer_enable_intr() in timerAttachInterrupt()
• rewords the log message for edge handling (this is not relevant in the IDF4.4 timer driver)
• wraps the ISR function in the correct function type as expected by the IDF4.4 timer driver

Note: to handle the ISR function wrapping a default ISR handler function has been added.

In timerDetachInterrupt() the change:

• removes the previous code
• calls the appropriate function in the IDF4.4 driver

Note: the log message in timerBegin() was also reworded.

Tests scenarios

I have tested my Pull Request on Arduino-esp32 core master with an ESP32 Board with this scenario

Related links

Related issue: #6730
Closes #6730

[CLAassistant]

All committers have signed the CLA.

[me-no-dev]

@P-R-O-C-H-Y good timing on the timer ci test

[P-R-O-C-H-Y]

@P-R-O-C-H-Y good timing on the timer ci test

Was waiting for the test merge to add the label hil_test there :D

[sweetlilmre]

@me-no-dev may I ask what is probably a stupid, but genuine question? :)
How does the master merge that you did work? It looks (from the perspective of my fork) that you merged the main repo master into mine. I'm assuming this is a PR option to rebase my PR on your current master, is that correct?
And I guess it follows that it would be better practise in future to make PR changes in a branch.
Always more to learn. :)

[me-no-dev]

@sweetlilmre I updated your branch to have the new changes in our master, which include timer hardware testing. It is more or less rebasing to the upstream master

[VojtechBartoska]

@Ouss4 Any clue why the bot didn't show up? :(

[Ouss4]

@Ouss4 Any clue why the bot didn't show up? :(

I talked with Honza regarding this. I see that the Workflow wasn't triggered at all. The only thing that's different here is that the OP is a "First time contributor". Github introduced few months ago an approval step required for this situation, I'm not sure how this works for workflow_runs (i.e Workflow triggered by another workflow), but my assumption for now is that they require the same "approval" step.
I labeled #6770 from another contributor and the Workflow triggered correctly (Also assuming that the author there was not invited to this repo, if that's the case, I'm gonna have to test with another PR.)

Note, that the tests did run and succeeded, it's only the workflow that adds the comment with the summary that didn't run.

[sweetlilmre]

Is there anything I can do to help?

[sweetlilmre]

@Ouss4 it looks like my upstream fetch has kicked in the approval behaviour.
Would you mind approving so we can move this PR forward and see if that resolves the previous issue?

[P-R-O-C-H-Y]

@Ouss4 it looks like my upstream fetch has kicked in the approval behaviour.
Would you mind approving so we can move this PR forward and see if that resolves the previous issue?

@sweetlilmre
The tests has succeeded so its fine.
Gonna take a look on the PR today :) and make a review.

[sweetlilmre]

@P-R-O-C-H-Y I am excited! :)

[P-R-O-C-H-Y]

Thanks for your PR 👍
Please look on comments I made. After fixing these logs, it can be merged :)

[sweetlilmre]

@P-R-O-C-H-Y  All requested changes have been made :)

[me-no-dev]

Thanks @sweetlilmre ! Merged :)

[sweetlilmre]

Fantastic! Thank you everyone :)