Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can_send sending multiple message if all tx buffers full #2

Open
bgstewart opened this issue Apr 3, 2017 · 0 comments
Open

can_send sending multiple message if all tx buffers full #2

bgstewart opened this issue Apr 3, 2017 · 0 comments

Comments

@bgstewart
Copy link

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

can_spi_command(MCP2515_SPI_RTS | ((uint8_t) (1u << txb)));

this does not happen.

Hoping someone else can chime in to see if this is an actual issue or if I'm handling something incorrectly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant