You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm posting this here rather than making a pull request as I'm not 100% sure if this is an issue with the library or how I am handling it.
Consider the situation where a master is spamming the bus with constant CAN messages. In my case I have a circular buffer holding CAN messages that are sent out when tx buffers are available so I store up to 16 CAN messages at any one time before transmitting when I can.
Each time the RX interrupt is received, the message is decoded and a call to can_send() made. The first time this happens, a message is sent to the MCP2515 but the TX interrupt does not fire as the CAN controller hasn't had a chance to transmit due to the constant master spamming the bus. At this point, mcp2515_txb is 0b00000001. When the next RX interrupt is handled, tx buffer 0 is full but 1 is available, hence mcp2515_txb is then 0b00000011 and when can_spi_command() is sent, this will make both tx0 and tx1 transmit when the controller is available.
Eventually at some point all 3 tx buffers are full and the master stops spamming. The TX interrupt now starts to fire, however at this point mcp2515_txb is 0b00000111 due to having three calls to can_send() without an accompanying TX interrupt. Assuming a normal program flow of:
irq=can_irq_handler();
...
if (irq&MCP2515_IRQ_TX) {
can_send(...)
}
Then the call to can_irq_handler() will clear the tx0 bit, before the can_send command() sets it again following a call to can_tx_available(). After the message is sent to the MCP2515, can_spi_command() is then sent with mcp2515_txb equal to 0b00000111, which causes tx buffers 0, 1 and 2 all to be transmitted.
If the can_spi_command() call is instead changed to
I'm posting this here rather than making a pull request as I'm not 100% sure if this is an issue with the library or how I am handling it.
Consider the situation where a master is spamming the bus with constant CAN messages. In my case I have a circular buffer holding CAN messages that are sent out when tx buffers are available so I store up to 16 CAN messages at any one time before transmitting when I can.
Each time the RX interrupt is received, the message is decoded and a call to
can_send()
made. The first time this happens, a message is sent to the MCP2515 but the TX interrupt does not fire as the CAN controller hasn't had a chance to transmit due to the constant master spamming the bus. At this point,mcp2515_txb
is0b00000001
. When the next RX interrupt is handled, tx buffer 0 is full but 1 is available, hencemcp2515_txb
is then0b00000011
and whencan_spi_command()
is sent, this will make both tx0 and tx1 transmit when the controller is available.Eventually at some point all 3 tx buffers are full and the master stops spamming. The TX interrupt now starts to fire, however at this point
mcp2515_txb
is0b00000111
due to having three calls tocan_send()
without an accompanying TX interrupt. Assuming a normal program flow of:Then the call to
can_irq_handler()
will clear the tx0 bit, before thecan_send command()
sets it again following a call tocan_tx_available()
. After the message is sent to the MCP2515,can_spi_command()
is then sent withmcp2515_txb
equal to0b00000111
, which causes tx buffers 0, 1 and 2 all to be transmitted.If the
can_spi_command()
call is instead changed tothis does not happen.
Hoping someone else can chime in to see if this is an actual issue or if I'm handling something incorrectly.
The text was updated successfully, but these errors were encountered: