Enable/Disable MCP251XFD_INT_TX_EVENT at runtime

[xmurx]

First of all, great work. I am trying to use the library in CAN 2.0 mode. I can't find a way to enable/disable MCP251XFD_INT_TX_EVENT when the controller is already in CAN 2.0. I found this function MCP251XFD_ConfigureInterrupt(), but calling the function with parameter MCP251XFD_INT_ENABLE_ALL_EVENTS does not enable the MCP251XFD_INT_TX_EVENT event. Is there another way to activate or deactivate interrupt events even if the controller is already in CAN2.0 mode? Many thanks in advance...

[Emandhal]

Hi, I see no reason for you to not be able to enable/disable Tx interrupts at runtime. Datasheets does not say any restriction for this.

The enable of MCP251XFD_INT_TX_EVENT in MCP251XFD_ConfigureInterrupt() is the first step. Next, you need to configure one or more of the following flags on each TXQ/TxFIFO that you need a Tx interrupt:

• MCP251XFD_FIFO_TX_ATTEMPTS_EXHAUSTED_INT
• MCP251XFD_FIFO_OVERFLOW_INT
• MCP251XFD_FIFO_TRANSMIT_FIFO_EMPTY_INT
• MCP251XFD_FIFO_TRANSMIT_FIFO_HALF_EMPTY_INT
• MCP251XFD_FIFO_TRANSMIT_FIFO_NOT_FULL_INT

Set the interrupt config in your list of MCP251XFD_FIFO configuration (in .InterruptFlags member) for the MCP251XFD_ConfigureFIFOList() function.

Hope this help

[xmurx]

Hi, thanks for quick reply. I dived a little deeper on your suggestion. For me it looks like you designed the library to be configured at startup - only once in configuration mode (or switch back to configuration mode). If I have seen it correctly:

• MCP251XFD_ConfigureInterrupt() - clears all interrupt events before setting the new interrupt flags - not sure if this leads to loss of events during runtime.
• MCP251XFD_ConfigureTXQ() which is called in MCP251XFD_ConfigureFIFOList() requires MCP251XFD_CONFIGURATION_MODE

Enable or disable TX events during runtime is not supported. So, I have to work around this ;-) Otherwise the library works great.

Thanks!

[Emandhal]

Hi,

Now I understand perfectly what you want to do. Yes, the configuration at startup is its primary purpose, but modifying this parameter at runtime is important too. After checking how I can implement a new solution, I see one problem for this: the MCP251XFD_FIFO_AUTO_RTR_RESPONSE flag (ie. CiFIFOCONm.RTREN bit). I have 2 solution for this:

• Read the configuration's byte and change the interrupt configuration and rewrite the configuration's byte (slower)
• Authorize the use of the eMCP251XFD_FIFOCtrlFlags.MCP251XFD_FIFO_AUTO_RTR_RESPONSE enum member with the eMCP251XFD_FIFOIntFlags when setting the interrupt configuration but the user shall remember the configuration for each TEF/TXQ/FIFO (faster but not secure)

And for MCP251XFD_ConfigureInterrupt() you are right, it is not necessary a good idea to clear the clearable flags when changing the interrupt configuration.

As a "runtime changing interrupt configuration" user ( :blush: ), what do you think of this?

[xmurx]

Hi,

I would go for solution one (read - modify - rewrite configuration) - even though there is a bit of overhead changing this at runtime. May be you can think about a configuration-API which primary purpose is static configuration at startup and a "runtime"-API to change the configuration later.

[Emandhal]

Hi, I made a new commit for this "feature". Can you try it so I we can close this issue ?

Thanks