✧✦Catherine✦✧
just had someone report that they used the #GlasgowInterfaceExplorer SPI analyzer applet (and 25-series memory decoder) to read out an SPI flash from their router, which they previously believed they would have to desolder
things like this is why i'm so committed to building better tooling! the full boot trace is about 50 MB of raw data, and it's captured and decoded in seconds. very few tools can do this, and most of them are pretty expensive
✧✦Catherine✦✧
what kind of tool should i build next?..
i'm thinking a really good JTAG applet
✧✦Catherine✦✧
@OwOday no but someone else is working on that
OwOday
@whitequark is there a proto CAN applet? :3
✧✦Catherine✦✧
@jpm hm, got any docs for the debug protocol?
Joel Michael
@whitequark Right now I’m staring daggers at WCH’s shithouse Link-E debug probe, which somehow achieves about 2 seconds per character doing SDI print functions. So yeah a really good debug probe that can work with the ultra-cheap WCH parts would be a hell of a relief.
✧✦Catherine✦✧
@biggestsonicfan this is why Glasgow has *very* good support for old school TTL buses, actually, but no I haven't got any access personally
biggestsonicfan
@whitequark You ever thought of experimenting on arcade hardware? This kind of diagnostic stuff could revolutionize how they are repaired and reproduce components, hell maybe even give an edge in understanding things for emulation.
✧✦Catherine✦✧
@dragonhunter274 oh that's really easy, with one caveat. what PC side protocol do you expect?
DragonHunter274
@whitequark a uart applet that supports an arbitrary amount of data bits would be really useful, i have a project that needs 9 data bits and its really hard to find adapters for that
✧✦Catherine✦✧
@Mr_Hat_2010 I think a tracer is quite feasible once we have RAM-Pak support
Mr_Hat_2010
@whitequark A tracer for example ARM microcontroller would be neat, but that could be a bit too much for the hardware
✧✦Catherine✦✧
@jpm hmm i think i cant justify REing the debug protocol probably
Joel Michael
@whitequark (unfortunately it’s not standard JTAG - the higher-end parts use something that kinda sorta vaguely resembles ARM SWDIO 2-wire debug, and the low-end parts use a custom 1-wire protocol)
Joel Michael
@whitequark lolno, the debug protocol documentation appears to be completely missing for the QingKeV4 CPU. There’s versions floating around for V2, but that’s a different wire protocol. There are references to the debugger manual in the QingKeV4 Processor Manual in the section about debug registers at https://www.wch-ic.com/downloads/QingKeV4_Processor_Manual_PDF.html
✧✦Catherine✦✧
@bytex64 yep, that's an explicit design goal! so is being able to rip out entire applets and integrate into random other FPGA projects without too much difficulty
Chip
@whitequark The ability to use the building blocks to script my own variant protocols has been very handy. I built a script for doing SMBus battery queries in about an hour. And another time I built a reader for old I2C EEPROMs (the <128 byte ones that are addressed purely through the I2C address).
✧✦Catherine✦✧
@dragonhunter274 I mean there's no single way to pack 9 bits into hex
DragonHunter274
@whitequark I'd be fine with just hex on stout/in
the protocol is MDB
✧✦Catherine✦✧
didn't build that yet but you now have a Xilinx Virtual Cable applet https://glasgow-embedded.org/latest/applets/interface/jtag_xvc.html
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.