Really clear up the roles and structures of word wrapping.
Significantly, we have now figured out that the word wrapper
should be the word wrapper, and that the text bounds should
be computed by a text bounds computation.
Conflating flexible text bounds with word wrapping makes
the math really hard.
So, the word wrapper always works with a bounding area starting
at 0,0, and will wrap until it hits a Point designated as its
absolute max bounds.
The returned typeset block is referenced to 0,0, and then it
is shifted to the correct location by the rendering function.
This externalizes the computation of the final location plus
the rendering bounds to the outer functions that need to care
about this, thus simplifying the word wrapper significantly.
this just grafts in the new crate, while leaving the old crate
unscathed. once this is somewhat functional we'll excise the old
crate and reformat the loader for the "hard binary" image of
the fonts.
Always reset the EC on boot. If we have a cold-boot situation,
it's hard to know what state the EC is in versus our stack;
a hard reset on the EC guarantees we at least always start from
the same point.
Note that on suspend/resume, there is no reset - the EC continues
trundling onwards, but the system was designed for this.
This is not the fix I was hoping for for connection stability,
but unfortunately this is where we are at.
The problem is that at some point the WF200 throws a "host interface
error"; but the error codes show no specific error. After throwing
this error, it can respond to some basic commands (such as the one
asking what the current status and error codes are), but higher level
APIs seem to time out. There's no command to bring the WF200 stack
to a sane state (like a warm reset or buffer flush) as far as I
can see, so, the solution is to detect the issue and send a reset
to the WF200. This keeps the link up in the long term, but
you will experience drop-outs about once every 2-3 hours for
about 20 seconds while the system detects and fixes the problem.
I think for this one, more data will be needed from customer units
to see if this could be just a local network issue with my config
or a more pervasive problem.
Add the loader into the main workspace, removing it from its own
sub-workspace. We can do this now that we can specify the linker script
in `build.rs`.
This improves IDE support, and should shrink disk storage requirements.
Signed-off-by: Sean Cross <sean@xobs.io>
This moves the kernel into the main monorepo, allowing it to share
packages with the rest of the system. This change will allow us to
reduce the number of rebuilds that take place, as well as reducing disk
usage.
Note that the loader is still an indepenent project, and the integration
of that into the monorepo is pending.
Signed-off-by: Sean Cross <sean@xobs.io>
- code is merged into shellchat so there's less alignment overhead
and some library reuse
- server is not spawned until it's needed, so the RAM load is less
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.
