10:56 <josuaH[m]> I suppose the Russian government will not blame companies trying to find workarounds, and China will certainly not spit on it: it's a very big client for them in the end: low on support.

10:57 <josuaH[m]> Whoa, it's getting close by the way! 😄

10:57 <josuaH[m]> > Estimated to ship: Aug 30, 2024

10:58 <josuaH[m]> No hurry though.

11:00 <josuaH[m]> Glasgow is like an attention timebomb: as soon as I receive it, I'll be on "forced Glasgow holiday" for at least a week to poke at it ^_^

13:08 <whitequark[m]> the Russian government has passed a number of laws to that end; last time I checked, piracy of software that can't be exported is simply legal

13:09 <whitequark[m]> not just "we will close eyes on it", but an actual federal law enabling it

13:10 <whitequark[m]> there were also some enablements via customs to allow "parallel import" (basically, import of e.g. Apple technology by third parties without Apple's permission) but I think the situation with that is more complex and I don't know how that's going now, I just recall it's been changing

14:07 <anuejn> is there a glasgow applet for an spi-peripheral somewhere?

14:07 <anuejn> (I want to capture what an spi master sends)

14:13 <whitequark[cis]> nope, but there should probably be... however, overruns are an issue

14:13 <whitequark[cis]> maybe we could have an spi-capture applet? that does need packetization though to work well

14:14 <whitequark[cis]> anuejn, we could collaborate on this, developing a COBS framing that would allow capturing all sorts of useful stuff

14:14 <anuejn> COBS?

14:15 <anuejn> I actually need only very basic functionality for my current problem but would be happy to develop that

14:15 <anuejn> (log 16 bit transactions that are delimited by cs being deasserted)

14:16 <whitequark[cis]> consistent overhead byte stuffing

14:16 <whitequark[cis]> allows adding framing to byte streams without having pathologically high overhead for small frames

14:17 <whitequark[cis]> er, sorry, that's incorrect

14:17 <whitequark[cis]> without having pathologically high overhead for certain byte sequences, as a naive escaping based solution would

14:19 <anuejn> ah I see

14:21 <anuejn> I think in a first version it would be fine for my application to just escape naively

14:21 <anuejn> but I see that this might be undesirable

14:21 <whitequark[cis]> I realize that, but my interest here is in a more generic solution

14:21 <whitequark[cis]> which could be used in the Glasgow framework itself, eventually

14:21 <anuejn> I see

14:21 <whitequark[cis]> now that we have streams, we have the basis for developing it

14:27 <anuejn> now that I think about it, a length field might actually be more helpful than cobs?

14:27 <anuejn> because there could be spi transfers that have non-multiple of 8 bit length

14:27 <anuejn> and it would be cool to log these as well

14:27 <whitequark[cis]> you don't find out what the length is before the transfer ends

14:28 <whitequark[cis]> and there may not be enough buffer space to buffer an entire transfer on the whole FPGA

14:28 <whitequark[cis]> (but in any case I think using more than 1K of buffer per applet is usually a mistake)

14:29 <anuejn> True

14:29 <anuejn> we could do something like sending the length after the packet

14:29 <anuejn> but then we need some escaping again

14:29 <anuejn> fine

16:25 <Guest76> howdy folks - i'm trying to use Glasgow as a SWD interface with OpenOCD, and have been having some performance issues. i'm running in a VM (Windows host, Mint guest) and suspect that's the culprit, but just trying to make sure the bad perf in this case is expected behavior before I go digging around for one of my other debug probes to use instead

16:25 <whitequark[cis]> it's not super fast natively either

16:26 <whitequark[cis]> openocd's bitbang interface is not a speed demon (and was never intended to be); it's just a backstop before a better interface can be built

16:27 <Guest76> *nodnod* As far as i can tell, SWD reads involve several network+USB round-trips /per bit/ w/ the swd_openocd applet, and as measured in my VM that's ~1-2ms so my total bandwidth is on the order of "hundreds of bits per second" so sounds like dumping the firmware on this chip w/ Glasgow over SWD for now is a no-go

16:28 <whitequark[cis]> it runs at uh... less than 300 baud

16:28 <whitequark[cis]> in terms of actual download speed of data

16:29 <q3k[cis]> is there another openocd interface that could be used, or do you think something new would have to be implemented?

16:29 <Guest76> yeah, and then openocd seems to be continuously polling the CPU core status as a bonus which uses up more of the already-limited bandwidth, cool, just wanted to make sure i hadn't horribly misconfigured something

16:31 <whitequark[cis]> something new would have to be implemented, starting with a proper stream based SWD interface

16:31 <whitequark[cis]> and i don't know if that would even integrate with openocd. I'd rather implement ADIv5

16:32 <whitequark[cis]> I had a branch but had a limited time

16:36 <Guest76> I was actually looking briefly at hacking up the openocd FTDI MPSSE driver, which at least talks to the hardware in chunks of more than 1 clock edge, to talk over sockets (& then doing "bootleg MPSSE" as a Glasgow applet) - might at least make it usable for basic debug, if not flash dumping, and would support things besides ADI (but still be much

16:36 <Guest76> slower than a specialized ADI applet)

16:38 <whitequark[cis]> that was actually the original thing Glasgow was supposed tondo

16:38 <whitequark[cis]> s/tondo/to do/

16:38 <whitequark[cis]> people here wanted to resurrect it, on top of a janky usbip based scheme

16:38 <Guest76> similar to the way Tigard does it but with proper tri-stating- the gateware would basically get "clock these N bits out while sampling the input" and send back the N input bits it sampled

16:39 <whitequark[cis]> the IOStream component does exactly that

16:39 <whitequark[cis]> well, it needs a protocol

18:22 <whitequark[cis]> btw

18:57 <altracer[m]> coincidence

18:57 <altracer[m]> https://mynickname.com/id860130

19:00 <altracer[m]> I think I looked at JLCPCB, LCSC & EasyEDA, but they stopped shipping. Using a middleman sounds interesting. I'll consult some of my contacts who actually did it this way. Thank you for elaborating on this situation.

19:04 <altracer[m]> Rezonit is too expensive and will take longer. Tehnoteh sounds more approachable but I'd need to source any ICs (they only have SMD resistors and caps, IIRC).

19:06 <altracer[m]> Anyway, I am not your client (yet), don't have enough Python or FPGA knowledge, so I'll simply stay away from the channel and go program a few more MCUs as a workaround. That'll be easier for everyone.

19:06 <whitequark[m]> oh yeah, Rezonit is ... not a budget option

19:07 <whitequark[m]> from what I heard, even if they dedicate an entire line for your volume, they aren't exactly a joy to work with

22:17 <anuejn> I now wrote a more shitty spi applet

22:17 <anuejn> (wanted to get the job done)

22:17 <anuejn> should I still do a PR?

22:18 <anuejn> (it uses only 7 bits of every byte and reservs the last bit to indicate the end of a transfer)

22:32 <whitequark[cis]> that doesn't seem very useful even as a starting pojnt

22:32 <whitequark[cis]> s/pojnt/point/

22:35 <anuejn> okay, fair :)