there's something....weird....going on in the initializers
here and ... something about configurations not being
applicable to expressions??
i'm a little confused, but, the original work-around I had to
this isuse somehow side-effected things in some way that I didn't
expect. this reverts those side effects.
a "small" memory target is created, which maps only a subset
of fonts to memory for targets that have extremely limited amounts
of on-chip storage.
the main thing I'm not happy about with this change is that the
origin offset of the font table is hard-coded into the template,
but also, I'm not quite sure if there's a better way to do this
that doesn't make things unnecessarily complicated. The origin
offset *is* target specific, and the templates already
reference targets specifically in the config lists...so if this
were to be made more generic, the path you'd end up on is something
like parsing link.x files out of various configurations which seems
like an extreme amount of work for a constant that rarely changes.
So, it's a footgun, but one where mending the foot is several times
less effort than putting a safety on the footgun.
far from complete, lots of warnings, but a good start.
most of the io setup and FB manipulation is done.
The main thing left is to puzzle through the UDMA block and
setup the SPIM accordingly.
Regenerate the font files after adjusting the template to generate files
that will not get changed by rustfmt.
Signed-off-by: Sean Cross <sean@xobs.io>
Generate code that can be put through rustfmt without being altered.
This removes an issue where the font tables can be rearraged by simply
running `rustfmt` on the repository.
Signed-off-by: Sean Cross <sean@xobs.io>
XOR op should not be usable to create fake security boxes
but it also looks really ugly to have it defaced.
This small tweak makes the XOR function look decent for the initial
purpose of the function (chat status bar wait indicator).
Eventually, this will be a controversial decision, but I'll kick
that down the road.
this it to avoid abusing the primitive to create inverted text
(for secure UI elements only). It does degrade from the aesthetics
of a busy bar but it is a computationally efficient way to patch
around the concern.
This is just the TextView primitive with a "state" variable added
that controls how far the strips should march across the screen.
Users can specify with or without a bounding box.
The exact location of the text within the bar depends on the
BoundingBox option picked.
The primitive computes the total region to animate based upon
the typesetting engine's output. Thus it is not recommended
to "compress" the amount of whitespace allocated to the animation,
because it can cause the animation to have artifacts due to
whitespace overflow of typesetting.
Mark `MemoryRange::as_slice()` and `MemoryRange::as_slice_mut()` as
unsafe.
This is due to the fact that not all representable types can be cast to
an arbitrary value. For example, if Process A sends random values to
Process B, then Process B casts the memory to a slice of `bool`, then
any values that are not 0 or 1 are undefined.
Because these functions can leak UB into the program, they are marked as
unsafe.
This patch adds `unsafe {}` blocks to all instances where this function
is called. Additionally, all instances have been checked to verify that
they do not cast to any invalid types -- most use `u8` or `u32`.
Additionally, the long-deprecated `MemoryRange::from_parts()` call was
removed, since that causes UB without being marked as unsafe.
Signed-off-by: Sean Cross <sean@xobs.io>
