What to do

Okay, the problem is:

  • Some parts of my network stack expect "direct responses" to certain messages - like the discovery code. It might be okay to special case this, but it might not be.
  • Some parts of my network stack expect a "stream of responses", where you are essentially just shuttling the queue

Honestly after worring about this so much - I'm inclined to just ngaf about it. I can declare (for now at least) that you just SHOULDN'T queue packets from a device (on the sub side) until you have a confirmed address, and you shouldn't queue packets to a device (on the dom side) until you have completed the discovery process.

Doing this will let me get on with my life.

Additionally, for now, I can probable cheat with functionality:

Use one port per thing, and just send all broadcast messages.

Since there is no routing yet, everyone will hear everything. Thats fine. We can just process messages using the port as the index to which data type we expect here. For the simple use case of:

  • Set the color
  • Set the brightness
  • Report motion

Ideally also:

  • Send logs
  • Do OTA/"go to bootloader" (where the bootloader also can talk on the bus)

More thoughts

Okay, this is MOSTLY correct, but still problematic on the dom side, because we need to interleave discovery with normal operation, which means we need a completely clear queue to do discovery. I feel like the only method right now would be to inhibit outgoing messages?

I guess the dom could do a couple of messages, and they'd just get interleaved? I guess the bigger problem

More more thoughts

Okay, the high prio outgoing queue seems to fix things, but I'm starting to get to the point for the dispatch and uarte-485 parts might want to be specialized into Dom and Sub variants.

Specifically the sub doesn't need a high prio queue, the dom needs different "authorized to send" logic, etc.

Rethink logic

Okay, let's think about the IO-side logic.

Mostly: How to poke a running system? For the dom side, that isn't so bad. We have receive windows, and will progressively drain the queue. But on the Sub side, we need SOME way for dispatch to "poke" the driver to drop out of receiving and to start a send when prompted. But right now, all the logic involves pending the interrupt, which means I need some back and forth.

Oh, we also need to poke the dom if it is currently idle.

Dom side

  • Should always default to sending
    • Should have a (min?) window of time to listen for
    • Auto-reload listening
    • Once timer expires, return to sending or idle

Sub side

  • Should always default to receiving
  • On command, send one message, then return to receiving