Scheduled Events

[Poofjunior]

According to the protocol, controller-to-device messages do not include timestamps. If the protocol were to add timestamps, the device could interpret these messages as "do-this-read/write@timestamp," i.e: a scheduled register read or write at a future time.

To handle scheduled/read events, we would need to incorporate a way for handling a schedule of messages. A priority queue would be a great choice here, the ETL has an existing data structure for this, and I've written a snippet of source code in the past to demonstrate how this could work without dynamic memory allocation and a low memory footprint.

It's worth mentioning that messages handled at a later time need to be copied out of the receive buffer. Memcpy would probably be fine here, but we could even borrow a DMA channel to move the data without blocking.

[Poofjunior]

Some details about a possible protocol implementation.

Let a scheduled event be a Harp message (read or write) sent from PC to client that includes the timestamp, indicating that the action should happen at that timestamp.

For a Harp reply, we have two options. Either, (1) we could enforce that a Harp device would reply with the number of slots left in the queue, or (2) we could enforce that no harp reply is issued unless there are no slots left in the queue, in which case, the Harp reply would indicate that the queuing was unsuccessful.

[bruno-f-cruz]

I like this! However, I wonder if the concept of Bytes to allocate, in addition to slots, should be implemented. This would allow different implementations to use different buffer sizes if memory is indeed a problem.

[glopesdev]

One other potential issue with having a reply to the same register containing the number of available slots is that it might break the symmetry of the current request-reply pattern, where the controller simply replies with the updated state of the register at the time the command is executed.

If possible I would rather keep this pattern since it simplifies analysis tremendously that the payload structure of all messages to the same register is identical.

Instead, I would propose the register simply replies with an error message in case the queue is full.

[Poofjunior]

I like this! However, I wonder if the concept of Bytes to allocate, in addition to slots, should be implemented. This would allow different implementations to use different buffer sizes if memory is indeed a problem.

Hmm, that brings up a good point! Since harp read/write messages take up a variable amount of space, returning something akin to bytes left like you suggest seems like a more rigorous way to do this.

Instead, I would propose the register simply replies with an error message in case the queue is full.

@glopesdev That works too. We can essentially get the same resulting behavior with this reply scheme where the device issues no reply on receiving a scheduled message unless there is an error. The Bonsai (or, generally PC) side just needs to be ready to resend a message in the case that there wasn't enough space left. The only risk is the PC not having a way of knowing if the message was ever received at all by the Harp device until the scheduled time that the read/write is supposed to occur, but that's something that the PC side could likely handle as well.

[Poofjunior]

Moving the general part of this discussion to: https://github.com/orgs/harp-tech/discussions/14