
As above, so below, part 2. Bare metal Rust generics - M2Ys4U
https://www.ecorax.net/as-above-so-below-2/
======
scoutt
> We want our driver a bit smarter than that; it should first check whether
> it's possible to write the bytes directly. In other words, we want to ensure
> that every 1 in our intended write is also a 1 in the target space.

Is this standard practice? Everyone knows that one should write only on
previously erased units (sectors/blocks/pages/whatever). Maybe it's just for
the sake of the example, but I think it's kind of insane to produce a routine
to check for EVERY BIT and see if it's 1 AND if we can fit whatever we want to
write. What are the chances one can overwrite (for example) a string TWICE?

~~~
toast0
I didn't read enough of the post to get the context, but...

You might often want to write less than a full block. In that case, if you
always erase, you have to read the full block to ram, make your change, then
erase, then write the full block. If you write byte by byte, that's a lot of
erase cycles. So you add a check to see if the bytes you want to write are
already in the erased state. But it's not much more work to check if the
desired state is attainable instead of just if the current state is erased.
Isn't it just if Current & New == New?

~~~
jlokier
That area full of 1s might not be really erased, though, if power was removed
or the device reset during an erase cycle before.

Those would be partially-charged cells, and should be erased properly before
writing, lest you start getting temperamental read errors later.

But repeatedly erasing blocks just to add a byte will wear out the block, as
well as take a long time as you point out.

I think the solution to these two constraints is filesystem-like book-keeping
of which regions are in which states.

~~~
__cuervo
That's a risk, yes. For our use case, there is very strict error
checking/firmware signature verification on every process involving the flash,
so the corruption case is always handled gracefully, leading to a full erase
anyway.

------
M2Ys4U
NH discussion of part 1 here:
[https://news.ycombinator.com/item?id=24254048](https://news.ycombinator.com/item?id=24254048)

------
bencollier49
Interesting use of the Hermetic Axiom, there. Raised an eyebrow.

------
rkagerer
Anyone out there used Rust on an ATSAML21 MCU? How viable is it these days?

~~~
jamwaffles
Still reasonably early days like the rest of the ecosystem, but there is good
support for a lot of ATSAMD and ATSAME devices here
([https://github.com/atsamd-rs/atsamd](https://github.com/atsamd-rs/atsamd)).

I'm not very familiar with the ATSAM* series so compatibility-wise this might
be wrong, but you could likely add ATSAML support to that repo reasonably
easily.

------
rch
Why are comments by the author (__cuervo) showing up as [dead]?

~~~
__cuervo
I ran into some restrictions for newer accounts, apparently, but a moderator
fixed it quickly. Should be all good now!

