Thunderstorms Make Trees Glow

Scientists have long hypothesized that the high electrical charge of thunderstorms could produce an opposite charge in the ground that would discharge from the forest canopy. But this phenomenon, known as a corona, had never been observed on actual trees. A new study, however, has observed this ghostly ultraviolet (UV) glow from the tips of sweetgum leaves and loblolly pine needles during thunderstorms.

Catching these coronae in action required a new kind of UV detector that was ultra-sensitive to the particular band of UV-light emitted by coronas, hot fires, or mercury lamps. Since the latter two weren’t present during the team’s field observations, they were able to conclude that the light they detected came from coronae.

The group observed that corona discharges were transient, jumping from leaf to leaf and branch to branch across the forest canopy. For any creature capable of detecting that glow by eye, it must be incredible to watch the treetops lit by their own ever-shifting auroras during every thunderstorm. (Image credit: W. Brune; research credit: P. McFarland et al.; via SciAm)

so!! i am excited!!! to have finally finished the complete reimplementation of the #GlasgowInterfaceExplorer memory-25x applet for managing SPI NOR flashes. it is called memory-25q and it took an enormous amount of effort, because i have decided to Build It Properly

want to jump to the docs (there are a lot of docs, including on the fundamentals of (Q)SPI flashes) or read the code? here we go:

• pull request introducing memory-25q
• quad SPI controller API
• framework for managing QSPI-style memories
• the CLI of the new memory-25q applet
• and, finally, the API of the new memory-25q applet

now, why did i do that? two reasons. memory-25x is one of the first applets i made, ~7 years ago, and i had no idea what kind of UI i should be building (yet). to make it worse, i thought that SPI NOR flashes were "easy", you could "just send a few bytes and that's basically it".

nothing could be further from truth. first off, SPI NOR flashes don't really exist—there is no spec, no standard organization that can say "no, your thing is not compliant", no order to any of this. every vendor does whatever they want, and then every other year JEDEC writes down all of the unhinged shit they did. here is the list of six incompatible methods to turn a single bit on or off, as a warmup

second, SPI flashes have an absolutely absurd diversity of framings. you cannot even express it without building a meta-framework for abstracting over all the ways people have come up to squeeze 8 bits into 2 or 4 wires. then on top of it you have to manage a bunch of global state that affects framing in subtle or sometimes really fundamental ways, without having any way to find out that you've made an error besides "you compare the actual data with the expected data (or its checksum) and it is not equal"

anyway, the new applet should be excellent at any daily task and at least okay at >90% of the exotic ones. also it's easily generalized for the (completely incompatible on the wire) QSPI NAND 25N series, octal or DTR variants, etc