I'm just doing simple serial protocol stuff now, but I think that for more complex exploration, AI could write custom applets for the #glasgowinterfaceexplorer (which I am not capable of) — that could be a *really* powerful tool.
As it turns out, AI can use the #glasgowinterfaceexplorer and Saleae Logic very well, too. This *really* cuts down on development and debugging time. Especially useful for reverse-engineering Chinese modules with shoddy or non-existent documentation.

Does someone in my bubble want to sell me their #glasgowInterfaceExplorer so I don't need to wait more than a year for one to be produced :(? (rev C preferably, shipping to Germany or at #gpn24, #40c3 etc.)
The more I'm looking into coreboot, the more I'm tapping into buses where my logic analyzer hits its limits (and also, playing with FPGAs!!1)

boost welcome

also because this wire harness is a lot shorter, i can use quad mode and read it at 4 MB/s with the #GlasgowInterfaceExplorer memory-25q applet

i'm working on a SPI NAND Flash applet for #GlasgowInterfaceExplorer. i would like to add the ability to read (and write) data dumps... however, unlike with SPI NOR flashes where the data is located in an flat address space, SPI NAND devices are structured as pages (each consisting of data + spare + ECC)

how should i format these dumps? is there a standard format? is "use msgpack with a simple custom schema" good enough, considering msgspec promises fast (de)serialization for Python and other languages?

Client Challenge

if you have a #GlasgowInterfaceExplorer, please try out the new memory-25q applet and let me know if it works for you!

https://glasgow-embedded.org/latest/applets/memory/25q.html

memory-25q - Glasgow Interface Explorer

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:

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

applet.memory.25q: new applet by whitequark · Pull Request #1130 · GlasgowEmbedded/glasgow

This is a complete functional replacement for the memory-25q applet and it obsoletes and deprecates the latter. To do: figure out why 1-2-2 and 1-4-4 modes are broken not broken, just crosstalk ...

GitHub
@tim @elly this is viable, you could do it on a #GlasgowInterfaceExplorer most likely; main concern is that PSRAM doesn't have all the commands that QSPI hosts may expect. eSPI solves this entirely by letting the device inject wait states, IIRC
I would like to formally announce that the #GlasgowInterfaceExplorer revD development (the next iteration: with the same FPGA but 32 digital I/Os and 8 single-ended analog channels that can be configured as 4 differential ones) is well underway with a CrowdSupply campaign planned later this year; stay tuned!

So #HackerBoxes dropped of number 124 today "Bus Driver", and I'm looking forward to using it. But I also realized that it has the basis for a good workshop on exploring hardware interfaces which I use #GlasgowInterfaceExplorer for.

https://hackerboxes.com/collections/past-hackerboxes/products/hackerbox-0124-bus-driver

HackerBox #0124 - Bus Driver