Block downloads are now supported (or will be when PR is merged), but block uploads are not. The main reason is that they have implications for the way that message sending is setup on the node.
For block downloads, the SDO server needs to be able to send up to 127 block segment messages asynchronously, "as fast as possible". However, I do not want this to delay sending of other messages. So I think that it is going to require rethinking the way that message sending is currently implemented.
Currently, when the sender callback passed to Node::process cannot queue a message, it is dropped. This has been generally fine, because the node only sends a small number of messages -- theoretically it is possible to set-up a large number of TPDOs and for them to all be sent at once, but it hasn't come up -- and the application can easily provide a sufficiently deep queue. This will break that. So, what is needed is some pushback so that the node knows how many block segments it can send on one call to process, and I think, some form of message prioritization.
To put some perspective on this: it is something like ~150ms to send 127 block segments on a 1Mbit bus, with no other traffic. It's kind of a long time to block other messages.
Options
Second message transmit queue
The application could be required to provide two separate transmission queues: One for normal command and response messages, and one for asynchronous messages. When sending, the response queue would be sent with higher priority, and the asynchronous messages would be sent as bus time allows. This way, the Node::process() call could queue block segments until the second queue was full or all were sent.
Prioritized queue
Another option is to build a prioritized send queue. CAN message IDs could be used for prioritization, and the default SDO IDs are rather low priority so most other messages (SYNC, NMT, PDOs) would go ahead. Perhaps the biggest challenge here is that now every time the node sends a message, it would have to be prepared to TAKE a lower priority message out of the queue, and hold it until the next time around when it could try to send it again (assuming it did not have another higher priority message to send).
Forget about it
Don't worry about prioritization. Set up the node so that on every process() call it will attempt to send any non SDO messages first, and then send as many SDO messages as it can until the queue is full. The size of the queue then will affect how long message transmission may get delayed, but also too short of a queue would mean that the bus may not be fully utilitized if process() is not called frequently enough. The application could alleviate this by always calling after transmitting the last message in the queue.
Pushback considerations
A separate, but related and even more important issue is that message senders need to handle the possibility of having their message rejected due to lack of queue space. This includes
- SDO server
- NMT server
- TPDOs
Block downloads are now supported (or will be when PR is merged), but block uploads are not. The main reason is that they have implications for the way that message sending is setup on the node.
For block downloads, the SDO server needs to be able to send up to 127 block segment messages asynchronously, "as fast as possible". However, I do not want this to delay sending of other messages. So I think that it is going to require rethinking the way that message sending is currently implemented.
Currently, when the
sendercallback passed toNode::processcannot queue a message, it is dropped. This has been generally fine, because the node only sends a small number of messages -- theoretically it is possible to set-up a large number of TPDOs and for them to all be sent at once, but it hasn't come up -- and the application can easily provide a sufficiently deep queue. This will break that. So, what is needed is some pushback so that the node knows how many block segments it can send on one call to process, and I think, some form of message prioritization.To put some perspective on this: it is something like ~150ms to send 127 block segments on a 1Mbit bus, with no other traffic. It's kind of a long time to block other messages.
Options
Second message transmit queue
The application could be required to provide two separate transmission queues: One for normal command and response messages, and one for asynchronous messages. When sending, the response queue would be sent with higher priority, and the asynchronous messages would be sent as bus time allows. This way, the
Node::process()call could queue block segments until the second queue was full or all were sent.Prioritized queue
Another option is to build a prioritized send queue. CAN message IDs could be used for prioritization, and the default SDO IDs are rather low priority so most other messages (SYNC, NMT, PDOs) would go ahead. Perhaps the biggest challenge here is that now every time the node sends a message, it would have to be prepared to TAKE a lower priority message out of the queue, and hold it until the next time around when it could try to send it again (assuming it did not have another higher priority message to send).
Forget about it
Don't worry about prioritization. Set up the node so that on every
process()call it will attempt to send any non SDO messages first, and then send as many SDO messages as it can until the queue is full. The size of the queue then will affect how long message transmission may get delayed, but also too short of a queue would mean that the bus may not be fully utilitized ifprocess()is not called frequently enough. The application could alleviate this by always calling after transmitting the last message in the queue.Pushback considerations
A separate, but related and even more important issue is that message senders need to handle the possibility of having their message rejected due to lack of queue space. This includes