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

Triggering SupervisorType/SupervisorOutPin #322

Open
m8pple opened this issue Jul 13, 2022 · 0 comments
Open

Triggering SupervisorType/SupervisorOutPin #322

m8pple opened this issue Jul 13, 2022 · 0 comments

Comments

@m8pple
Copy link
Contributor

m8pple commented Jul 13, 2022

When trying to write test-cases I couldn't work out how SupervisorType/SupervisorOutPin is supposed
to work. (AFAICT it isn't supported in the Orchestrator yet, but I'm trying to work out what the
semantics are supposed to be, in order to see how to replace external devices and have tests
for simulated supervisors)

I'm assuming only a single implicit supervisor output pin, as the grammar and documentation
describe it as [0..1].

For replying within SupervisorInPin it is reasonably clear (I think?):

  • We can use RTSREPLY to send a reply to the sender of the incoming packet.
  • We can use RTSBCAST to send a message to all devices.
  • We can (presumably) do both a reply and a broadcast (AFAICT it is not disallowed).
  • Both RTSREPLY and RTSBCAST are not asking for the opportunity to send. They mean "the messages
    I have prepared within this handler must be sent."

That means RTSBCAST as it appears in the SupervisorInPin handler is not related to being
ready-to-send in the normal way, and RTSREPLY has no meaning outside the receive handler.

So how does a supervisor indicate that it wants to send on the SupervisorOutPin?
e.g. if during OnSupervisorIdle it decides that it now has something to send, how does it
express that? Or if it wants to do a broadcast after OnInit, how does it indicate that?

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