12:37 <d1b2> <brainstorm> The ESP32S2+Glasgow-jtag-openocd-bitbang saga continues, now JTAG TDO/TCK signals seem within spec I reckon?: https://github.com/espressif/openocd-esp32/issues/135#issuecomment-766340269 ... now it works "fine", but there are errors in the target remote :3333 init, memory region enumeration is very slow and breakpoints are still quite slow too... I've found a matching error on their esp32.com forums, let's see if we can figure out that last bit and

12:37 <d1b2> have functional breakpoints (not having to wait 20-30 seconds per breakpoint). Speeds between 500kHz and 10MHz seem to be fine for Glasgow), higher than that there seems to be another host of errors I'm not willing to explore at this point X"D

12:49 <whitequark> yes, it is expected that JTAG on Glasgow will break above ~8 MHz

12:49 <whitequark> this will be fixed in due time

12:50 <d1b2> <brainstorm> Oh! Is it a software or hardware issue to be fixed?

12:51 <whitequark> it is a consequence of a deliberately simplistic design

12:51 <whitequark> think of it as an MVP JTAG

12:52 <whitequark> I -could- make it work faster, but it would be messy, so I'd rather keep it simple until we sort out the mess

12:55 <d1b2> <brainstorm> So you mean the jtag-openocd applet, right?

12:56 <d1b2> <brainstorm> Btw, hats off for the Glasgow, it managed to tell me politely that I was shorting VIO and IO pins on my dev board: E: g.cli: cannot set I/O port(s) A pull resistors to low={} high={} ... all without magic smoke, so kudos for this dummy-proof board, love it! 🙂

12:58 <d1b2> <brainstorm> According to the USB power monitor it was consuming ~300mA at 3-4 second intervals, so it got a little bit warm, but did not toast it, which is remarkable.

13:04 <whitequark> glasgow was designed to be safe to misuse insofar as it is practical

13:05 <d1b2> <brainstorm> Yup, well done

13:05 <whitequark> keep it away from car batteries and it will be highly unlikely that you'll break it accidentally

13:05 <d1b2> <brainstorm> lol, will do 🙂

13:40 <d1b2> <brainstorm> OTOH, it might as well be the host (OpenOCD) side of things spending too much time in the bitbang code...

13:40 <d1b2> <brainstorm> https://cdn.discordapp.com/attachments/613461005392936961/802895610956349480/Skarmavbild_2021-01-25_kl._00.39.09.png

13:41 <d1b2> <DX-MON> Glasgow is definitely an incredibly well built and designed bit of hardware with great attention to detail :3

13:43 <whitequark> quite a lot of effort by many people went into it, yup!

15:29 <_whitenotifier> [glasgow] mndza opened pull request #265: Add bitarray implementation to eliminate external dependency - https://git.io/JtZfr

17:17 <modwizcode> niceeee

17:17 <modwizcode> Someone should just publish that as a library for all the other hapless people suffering from using bitarray :p

17:26 <mndza> hehe i could do it once the code is a bit more polished

17:26 <mndza> feedback welcome

17:27 <modwizcode> I agree the names you mentioned are questionable but I don't have a great suggestion

17:28 <modwizcode> except maybe the exteremely long idea of "byte_reversed" and "byte_reverse_inplace"

17:31 <mndza> i also added that distinction because i thought it might be useful, but maybe a single method is enough

17:32 <modwizcode> Honestly I think maybe that's a good point you can probably drop non-inplace reverse

17:33 <modwizcode> You should probably add docstrings to all the public stuff though at least imo

17:33 <modwizcode> like what "reversed" does is non-obvious

17:33 <mndza> yeah, you are right, i will try to document a bit

17:35 <modwizcode> Jeez python gets really messy when you mess with stuff like memoryview doesn't it?

17:36 <mndza> yes... i spent some time trying to clean the code, but there are definitely areas of improvement

17:36 <mndza> memoryview works nicely though

17:36 <modwizcode> I was commenting mostly because I haven't successfully fully learned this part of python because their docs are extremely vague imo about how all this stuff works

17:38 <mndza> i only use it internally to avoid some copies, and a user never sees a memoryview object (which might be faster, but also more complex)

17:38 <modwizcode> I noticed that. hmm

17:40 <whitequark> mndza: without having context: we do expose memoryview objects in API already

17:40 <whitequark> when you read from USB FIFOs that's what you get

17:41 <whitequark> that said it's definitely more complex (the FIFO code has a bunch of cases to normalize everything so it's always memoryview, for example_

17:41 <mndza> in bitarray we could maybe expose a memoryview on slices, but fallback to a new buffer on writes, or something like that

17:42 <mndza> but right now it is simpler

17:43 <whitequark> it'll probably take me a few days to get to reviewing this but, thank you for doing this work! it's really one of the most thorny issues at the moment

17:43 <mndza> thank you for glasgow!

17:44 <modwizcode> I've been trying to do a minireview of the code, nothing really stands out to me

17:45 <mndza> i know your initial idea was using word-sized elements, but i started with bytes

17:45 <mndza> so it definitely has room for improvement

17:47 <whitequark> bytes are OK, we can always change that later

17:47 <whitequark> makes the implementation a lot simpler I would think

17:50 <_whitenotifier> [glasgow] mndza synchronize pull request #265: Add bitarray implementation to eliminate external dependency - https://git.io/JtZfr

22:52 <d1b2> <brainstorm> Most of the time is actually spent on the host side of OpenOCD... it takes a while for the xtensa openocd extensions to go through the IC's memory but the biggest bottleneck is related with the jtag bitbang queues and its accompanying blocking socket: https://github.com/espressif/openocd-esp32/issues/135#issuecomment-766452220

23:05 <d1b2> <brainstorm> ... I guess that having OpenOCD read more than 1 char at a time might help? At least it's better than 3 years ago when it actually read bit by bit: https://github.com/espressif/openocd-esp32/commit/64f1f7b1c179dcce4e008bef6bf9515c47ae4100#diff-9bae0e28b2e1c3e23b0ff6231b3c34d619768b4071795f4a013645e979c17ca8 🙂

23:30 <fridtjof[m]> I hope this is not too off topic, but the way that nordic's online documentation always has the same useless page title has been annoying me so much that I wrote a small extension to fix that: https://github.com/fridtjof/nordic-doc-titles

23:31 <whitequark> ha

23:31 <whitequark> i'm gonna install that

23:37 <fridtjof[m]> great to hear i'm not the only one annoyed by that :D

23:39 <whitequark> i don't work with nordic devices much but i distinctly remember that aggravating website

23:42 <fridtjof[m]> i recommend you don't take a closer look at how it's built (either by inspecting the website, or my extension). it made building the extension... harder than it should have been

23:44 <whitequark> way to attract my attention

23:44 <whitequark> they... what

23:44 <whitequark> why

23:45 <whitequark> i'm just going to pretend i've never opened it

23:47 <fridtjof[m]> lmao

23:51 <gruetzkopf> hm, icestorm not building well on irix puts a damper in my stupid stunt plans :D

23:51 <whitequark> what breaks?

23:52 <gruetzkopf> integer length stuff

23:52 <gruetzkopf> i'll go build a 64bit gcc and try again

23:54 <d1b2> <brainstorm> Woah, Irix, parked on my brain since the times of OSF/1 :-!

23:55 <gruetzkopf> at least building gcc parallises better than building icebox