the CM can't always detect if the EC changes state; this is
especially true after an update or a forced reset where
the state caches are not reliably updated. If no packets are
seen for a while, poll the actual state and force a sync-up.
Also try to make sure that the interrupts are enabled correctly.
This macro will be removed, since it is no longer necessary. Remove this
macro across the project and replace it with a standard `main()`
function.
Signed-off-by: Sean Cross <sean@xobs.io>
smoltcp is written to allow multiple adapters, so 0.0.0.0 as
the binding for UDP is illegal. However, in Rust, it seems that
0.0.0.0 is "totally fine" and most OSes will resolve this to
a "default" adapter.
this patch introduces the behavior of taking 0.0.0.0 and mapping
it to a default adapter. In fact, we only allow binding to the
default adapter. The reasoning behind this is that if our IP
address changes, we would expect that 0.0.0.0 resolves to that.
Where this scheme fails is if someone binds to 127.0.0.1 expecting
it to not respond to packets coming in from the outside, e.g.
they are using UDP as a loopback interface. I think this isn't
a common use case for Xous, but if it does become one I suppose
we could add a code path to also check for the 127.0.0.1 case
and try to handle it...
smoltcp requires some polling to be done in the future for it
to work with low latency. It returns a time in the future for
the next poll.
This refactors the polling algorithm to:
1. use a fixed thread pool. This burns a little extra memory in
exchange for not having to allocate/de-allocate threads every
time a follow-up is needed.
2. use a short/long scheduler, where short delays (shorter than
the scheduler quantum) are grouped together, and only a single
follow-up is fired off within that time range if needed. Longer
delays have a larger window (roughly +/- 100ms) of grouping,
so fewer such events are also required in the distant future.
Empirically the delays seem to fall into two groups, either "short"
(less than 20ms) or "long" (around 700ms).
This improved scheduler uses fewer threads and generates less
messages, so instead of 16 threads and encountering exhaustion
we have 9 and have yet to see more than 7 used even under the
most strenuous tests (multiple while-true curl loops + fountain
test + ping simultaneously).
Some helpful debug is also printed now when scheduler runs out
of slots, so we can see the distribution of pending delays.
we no longer create a new interface on net reset, which means that
the socket handles don't blow up if we change IP addresses.
However, the ARP cache is still stale and there seems to be on way
to force it to flush....but I guess in theory, eventually it
should fix itself, if smoltcp is working correctly?
the refactor changes the way sockets are handled, so now, when
the interface is rebound we are certain to get panics.
working on resolving this detail now, but at least the interface
is working now and it seems more stable than before.
total threads in the net crate are around 10 right now, 32 max, so
increasing the sleeping thread limit to 16, since every now and then
we get exhaustion notes.
- allow for zero-length tx/rx returns
- implement "shutdown" function, which is different from close:
shutdown requires any pending connections to return Ok(0) immediately,
but the socket is not dropped.
now that the suspender is in its own thread, we can do this safely.
It's nice to have a bit of a delay because we want other system recovery
things to take precedence and settle out before we try pinging the COM
to see how the wifi changed while we were asleep.
the connection manager actually wants a ping on resume,
and when we suspend we suspend -- "it is what it is". However,
the connection manager is a hairball that can block for a while,
so, to prevent failures to suspend, we put the suspend listener
in its own thread, and on resume the suspend listener will
automagically kick out an event to tell the connection manager
to deal with stuff.
Due to overly liberal use of `.take()`, file handles were getting closed
when doing ordinary operations. This stops that.
Signed-off-by: Sean Cross <sean@xobs.io>
