This is a start on issue #111, where instead of starting a throw-away
server and doing a "yield" loop to emulate blocking behavior, messages
are instead stored so they don't drop, thus keeping a blocking
message blocking.
Add a "Later" stage, and have exactly one "Last" stage.
"Last" to suspend is the ticktimer -- this is crucial for
basically everything else to work. The other really
low level stuff that needs to work to the last minute is
now in the "Later" bin.
now you set time in local time. If time zone hasn't been set already,
it'll prompt you to enter a time zone.
The main oddity is now that you have to know your time zone as
an offset from UTC. This can be fixed later with a proper symbolic
TZ to numeric mapping, but, that's actually a surprisingly hard
feature to implement.
std::time::SystemTime returns time in UTC.
That's great, but a lot of times we want local time.
Unfortunately, we can't use `chrono` to do that, because
chrono figures out what your time zone is usind `libc`, which
is a thing Xous doesn't have.
the `LocalTime` server is Xous' solution to that problem. it
returns the corret time offset based on the time zone.
You can still use `chrono` to convert the returned time into
strings and to compute durations.
the u64 in and of itself is meaningless, without the context
from the PDDB that adds the offset to wall clock time plus
time zone. This is glued together by the time.rs stub inside
the status service.
This will create a 100MiB file in tools/ppdb-images/hosted.bin
(sorry!!) which is persistent storage for hosted mode.
Delete the file if you want to start over from scratch.
It's...pretty brittle. I expect problems, but maybe it will at
least get things moving.
since xous 0.9.5, we've had a Box and we've had threads, so now we
can put the callback in a Box and pass it to a thread, instead
of relying on an `unsafe` work-around to get the callback function
pointer into the thread's environment.
also remove async write callbacks: in practice, these aren't used
Downside of this refactor is that threads for handling the
callbacks are not spawned on demand, they are spawned at boot,
leading to about an extra 68k of RAM used (most of it being
consumed in the codec block, actually). Some of this is also
probably extra object code because we're using more of the stdlib
primitives, which carry some weight.
Was doing disjoint loads and stores on an Atomic, really, should
be using the fetch_add, fetch_sub variants to be proper.
Didn't seem to impact anything but maybe there's a future version
of me that high fives me for doing this.
Saves a bit on resources and the RTC crate doesn't need
to be stand-alone now that the modals crate is a thing;
we are able to split the UX routine to manage the RTC out
of the code that actually manages the hardware.
The hardware code ended up in LLIO, and the UX ended up in the status
routine.
Each Cargo.toml now includes a comment which remnids maintainers
of the dependency policy for Xous (that is, nail down every dependency
to the minor number).
Versions are pinned down to the minor number. Yes, this means that
we don't automatically pull in features and bug updates from crates.io,
but it also means we don't pull in new attack surfaces and code that
hasn't been tested or reviewed. I'd like this process to be very deliberate
and not automatic for Xous.
The `rand` crate is almost pinned down to a single version, except
for an odd dependency that's pulled in by hosted mode that depends
on rand 0.8.4 via a subordinate dependency via the `tempfile` crate.
Pondering if it's worth it to try and eliminate that, because the
0.8.4 version doesn't get compiled into any version that touches
real hardware. It just makes it harder to analyze the Cargo.lock
file, mostly. I think I'll leave it as-is.
sleep killbounce wouldn't work because we started limiting the
number of connections to the LLIO.
This change makes connections to the LLIO unlimited, but perhaps later
on we should split out the I2C bus into a separate security domain,
so that the LLIO's unlimited connection policy doesn't introduce a
risk into a rogue process being able to overwrite the RTC contents.
Probably about time to push some of this net stuff into main, even
though it's got a ways to go. This adds UDP/ICMP/DNS to the net stack,
but the ping probably needs to be refactored a bit to be *much simpler*
and more reliable, and there's some corner cases to chase.
