<whitequark>
as for monitor, yes, I want to eg boot a router and reconstruct (most) of flash from trace
<whitequark>
the Glasgow RLE LA is not nearly fast enough for this I think
<tnt>
Just transmitting the 5 bits (CS + 4 IOs) of the flash + an indicator rising/falling at each SCK transition would be fairly easy, and not that inefficient (assuming the flash does uses qspi/ddr).
<tnt>
if the flash just does normal spi then it's insanely wasteful though.
<whitequark>
right, spi monitor and spiflash monitor would be different applets
<whitequark>
right now qspi flash isn't really supported
<whitequark>
that said... qspi gearbox in hardware would be very nice too
<whitequark>
that said #2... if the flash comes up in qspi because of a bit somewhere, it might only make sense to detect that in software, not gateware
<whitequark>
that said #3, i'm not even sure how to detect it and maybe the user should specify it, or run an LA applet on this first
<tnt>
usually just sending a stream of 0xff will return it to normal spi mode, so to just access it, it's not much of an issue.
<whitequark>
but not for monitoring
<whitequark>
ie if your SoC starts from QSPI flash that resets to QSPI mode
<whitequark>
i think COBS is probably the best possible choice
<whitequark>
it's interesting that it actually has benefits beyond self-synchronization that TLV doesn't have
<whitequark>
cc marcan
<electronic_eel>
IIRC marcan suggested to use the usb urbs as frames and put datatype information in the first byte of the urb
<electronic_eel>
using the urbs means you don't have to add another framing layer
<electronic_eel>
or is there a problem with this approach so that you are rethinking this?
<whitequark>
electronic_eel: this works for between-applet multiplexing but not for intra-applet multiplexing
<whitequark>
urbs as framing make the most sense for between-applet multiplexing, surely
<sorear>
Under what conditions does COBS self-synchronize?
<whitequark>
sorear: any. all zero bytes are delimiters
<electronic_eel>
hmm, could the urb framing be extended to also work for intra-applet?
<whitequark>
that's actually the point of COBS
<whitequark>
electronic_eel: no, and i would be completely against this because revE will use TCP
<whitequark>
which obviously does not have URBs
<marcan>
TCP does have packets but... :p
<marcan>
oh hey TCP URG!
* marcan
hides
<sorear>
urgent data *ducks*
<ar>
ETHERNET PAUSE FRAME
<whitequark>
marcan: NO
<whitequark>
i didn't even implement URG in smoltcp
<whitequark>
because fuck all vendors can agree on what it means
<whitequark>
it's completely ignored, so if you send any urgent data you receive it in-band
<marcan>
that's what makes it F U N!
<whitequark>
and from then it's not my problem anymore lol
<electronic_eel>
how many different types of frames do you think are realistic for intra-applet?
<whitequark>
electronic_eel: uh, it depends on the applet?
<whitequark>
you can make any framing convenient for application
<electronic_eel>
if there are just a hand full, you could use separate tcp sockets for them
<sorear>
if you have two pipes you could do framing by sending unframed data on one pipe and long (32/64/varint) length fields on the other pipe
<whitequark>
sorear: the 2nd pipe is used by analyzer if it's enabled
<sorear>
sorry, don’t think this actually works
<electronic_eel>
but of course all this means that the tcp and usb gateware concepts will diverge more and more
<whitequark>
electronic_eel: well
<whitequark>
we could actually have up to 256 "ports" both in usb and in tcp
<electronic_eel>
and each applet could reserve some of them
<whitequark>
however
<whitequark>
this doesn't actually work
<whitequark>
because in the case of SPI flash analyzer i want the sequencing between main and sideband data to be precise
<whitequark>
and with TCP there's no way to recover the "phase relationship" between the sent bytes
<whitequark>
i.e. "SS low" will be a sideband
<whitequark>
and the idea is that derivatives of the spi-monitor applet could register other sidebands
<whitequark>
eg RESET# low
<whitequark>
or maybe you have multiple CE# signals
<whitequark>
or maybe you have a DATA/COMMAND signal
<whitequark>
all of this is actually pretty common
<whitequark>
so basically, the "drive" applets have a SERDES+sideband architecture, and "monitor" applets have an "inverse SERDES+sideband" architecture
<sorear>
there is a simple approach which is dual to “scramble then escape”: escape unscrambled data, but pseudorandomly change the escape sequence each time it’s used
<whitequark>
yes, Erika suggested it, actually
<whitequark>
I know 2x worst case overhead is not that bad if it's statistically bounded but I hate the uncertainty
<whitequark>
it also still sucks for debuggability
<whitequark>
because you can decode COBS in your head but good luck decoding scrambled escaped data in your head
<sorear>
it’s not scrambled though
<whitequark>
like you have a long string of 00s and which one of these is scrambled? who the fuck knows
<whitequark>
the escape bytes are scrambled
<whitequark>
i mean, the content is kept as is but the *positions* are scrambled
<whitequark>
this is nearly as bad
<Ultrasauce>
i definitely agree with parameterizing the timing of all state changes of the sideband/strobe/whatever lines
<Ultrasauce>
a major use case for the applet i see is debugging that sort of timing issue
<Ultrasauce>
i'd be tempted to generalize things to the point where spi is just an edge case of a parallel interface like the 8080 bus or whatever
<Ultrasauce>
finding a balance between 'a dumb implementation of a bus device' and 'a full-on LA shitting out a dozen samples per clock pulse' for the applets is not a design task i would want to take on though
<sorear>
bad idea: “just” make LA compression smarter
<kc8apf>
whitequark: CBOR byte strings would be 1-3 byte overhead for up to 64kB chunks. Also gives primitives for encoding additional info.
<davidc__>
re boards - I ordered a bunch of bare boards from JLCPCB. I've never used JLC before, so we'll see what their quality is like. I'll have a bunch extra that I'd be happy to sell at cost, or donate to anyone that promises to use it to write an applet.
<davidc__>
I'll ping the channel once I have the boards in hand (if they are any good). Or feel free to msg me with contact details and I'll ping you directly once I have them.
<tnt>
the board is only half, you really need two stencils to assemble that board.
<electronic_eel>
if you really wanted to and have the experience, you could probably solder a board without stencil and paste
<electronic_eel>
just using the balls for the bga
<electronic_eel>
often when I solder qfn I just tin the pads with soldering iron and then use hot air to solder the part
<davidc__>
tnt: sure; but ordering a stencil in qty 1 doesn't usually come with the same NREs as a 4 layer PCB
<tnt>
davidc__: here when I order, my cost are dominated by shipping and the fixed/flat fee for import of 25 eur :/
<davidc__>
tnt: (FWIW, I've got stencils for myself, but only the BGA's really require it)
<tnt>
yeah you _could_ do it without stencil, but that board is painful to do by hand with a stencil, so without it, when you're done, you probably changed your mind about "required".
<electronic_eel>
yeah, doing it without stencil is just for the really skilled
diverger has quit [Ping timeout: 245 seconds]
<_whitenotifier-3>
[Glasgow] electroniceel opened pull request #149: Merge test jig pcb schematics & layout - https://git.io/fjdBY
<davidc__>
tnt: heh.... that board isn't bad. I've done similar density/complexity, all 0402s, on a board 5x as big; all by hand and hot-air soldering.
<tnt>
you're more patient than I am :p
<davidc__>
tnt: eh, 'twas actually impatience. Our fab couldn't get stuff assembled in a reasonable schedule and I wanted prototypes now