00:15 <esden[m]> graziano.m (@_discord_119160277555085314:catircservices.org) `glasgow run --help`

00:48 <grazianom[m]> that works, though I was looking for something online so I could read up on it on my work computer 🙂

00:53 <tomkeddie[m]> You can browse the repo at https://github.com/GlasgowEmbedded/glasgow/tree/main/software/glasgow/applet

03:25 <embeddedpenguin[> is it normal that my glasgow still hasnt shipped yet? i thought they were shipping in march

04:08 <josHua[m]> https://glasgow.1bitsquared.com/ see where you are in line

04:30 <whitequark[cis]> <tomkeddie[m]> "You'll want to name it zmod or..." <- yes, this is why I'm saying SYZYGY-like, I do not intend to actually use their trademark

04:30 <whitequark[cis]> I do not like their I2C autodiscovery stuff and do not plan to follow it, but following the pinout and maybe mechanical spec seems valuable

04:30 <Darius> ooh my Glasgow case arrived, very swish

04:31 <whitequark[cis]> just like how revABC follow the ARM 20-pin JTAG connector somewhat

04:45 <esden[cis]> <Darius> "ooh my Glasgow case arrived..." <- Congrats! I am glad you like it. :)

04:46 <Darius> of course I am on macos and now the tools crash so it's not all rainbows and lollypops

04:46 <josHua[m]> hm, am I the only one who had success with the tools on macos?

04:47 <Darius> I did run them OK a while ago, but that was quite a while ago now

04:52 <Darius> from, uh.. 2021, wow

04:58 <Darius> ffs rebuild python3.12 with dtrace but I can't use it because of SIP

05:02 <Darius> OK I told pipx to use python 3.9 (also installed via macports) and it doesn't crash anymore

05:05 <Darius> also tried 3.10 and 3.11 - no problem

05:07 <Darius> open to suggestions for how to track the issue down

05:09 <esden[m]> Not just you. Things seem to work for me too, on an M2 machine as well as an intel iMac...

05:16 <Darius> esden[cis]: as in broken with Python 3.12?

05:17 <whitequark[cis]> what was the crash while it did crash?

05:19 <Darius> same as nf6x[m] above I think - https://gist.github.com/DanielO/ddd6670f7165fc43676105a65973dfba

05:20 <esden[m]> darius0949 (@_discord_217059800037457921:catircservices.org) things seem to work:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/nauFodAtunzEQgLxNEfcrINS>)

05:20 <Darius> hmm OK, I have 3.12.2

05:21 <esden[m]> so yeah, the whole stack seems to be doing things...

05:21 <Darius> I'll see if MP has 3.12.3

05:22 <esden[m]> that is on the M2 machine... I use the iMac for provisioning and testing of the glasgows... it is running Python 2.7.16 ... and I am not touching that as it works 😉

05:23 <esden[m]> ok that is not clear, the M2 is a MacMini, and the iMac is an intel machine.

05:23 <Darius> hah, vintage

05:24 <esden[m]> yeah, I am following a "it works so don't touch it" attitude there

05:28 <esden[m]> 🤦 ... of course I meant Python 3.12.3 ... (venv vs system python ... sigh)

05:29 <esden[m]> so both machines are running 3.12.3 for glasgow

05:45 <Darius> I just updated MP and it went to 3.12.4 but has the same behaviour as .2

05:52 <Darius> esden[cis]: what version of libusb?

07:50 <Darius> are there any plans to add some wiring guides to the intro? a diagram with pinouts would be nice IMO

07:54 <whitequark[cis]> what kind of guide?

08:00 <Darius> whitequark[cis]: well, I just connected VIN of my WS2812 strip to VCC because I didn't realise the 2 left most pins were VCC

08:03 <Darius> which is PEBKAC but still :)

08:04 <whitequark[cis]> hm

08:04 <whitequark[cis]> have you got the cardboard thing from 1b2?

08:05 <whitequark[cis]> there's a diagram on the cardboard ... however you call it, and on the case

08:05 <whitequark[cis]> and on the back of the PCB

08:05 <whitequark[cis]> we could definitely add the same diagram to the website, I'm just a little surprised it wasn't enough

08:06 <Darius> whitequark[cis]: I have the aluminium case

08:06 <Darius> I got a board made a while ago built by someone who made a batch

08:06 <Darius> probably the cardboard thing would be enough - if it is like the 1 bitsy thing that was great

08:14 <josHua[m]> the wiring harness that comes with the 1b2 boards also helps mitigate this

08:21 <whitequark[cis]> <Darius> "I got a board made a while ago..." <- ah i see

08:21 <whitequark[cis]> yeah 1b2 distributes something that is much more like a commercial product

08:23 <Darius> ahh nice, fair enough then

08:56 <whitequark[cis]> i mean we do need to put the card on the website

09:06 <Attie[m]> @darius - possibly one of mine? that was indeed just the board - 1b2 have bundled a USB C cable, wire looks, info cards, cases, etc...! it's very neat what @esden has put together

09:24 <FireFly> having a pdf version of that card would be neat yeah

09:26 <ewenmcneill[m]> FireFly: see https://github.com/esden/glasgow-diagrams/tree/main/pdf (Esden uploaded the diagrams in a few formats yesterday)

09:33 <FireFly> ohh nice, thanks ^^

10:54 <Darius> Attie[m]: yeah could be, was a while ago - I am slumming it with micro USB :D The case looks 💯

10:55 <Darius> yep I reckon that card would have helped 😂

14:02 <grazianom[m]> For the spi controller applet, is there a way to controller the bit order?

14:02 <whitequark[cis]> SPI has a specific bit order

14:02 <whitequark[cis]> if you want the other one it's no longer SPI

14:08 <grazianom[m]> SPI isn't well defined, sure it's supposed to be one way, but there is going to be hardware that is built the other way

14:08 <grazianom[m]> https://github.com/adafruit/Adafruit_SHARP_Memory_Display/blob/master/Adafruit_SharpMem.cpp#L80 configurable in some spi drivers on arduino as we see here

14:09 <grazianom[m]> you allow selecting the CS level, but CS is supposed to be active low

14:09 <grazianom[m]> from the wiki:

14:09 <grazianom[m]> > Data is usually shifted out with the most-significant bit (MSB) first.

14:09 <grazianom[m]> Seems that this hardware is LSB first

14:14 <whitequark[cis]> <grazianom[m]> "SPI isn't well defined, sure it..." <- as far as I know, Motorola SPI is unambiguous that it's MSB first

14:14 <whitequark[cis]> yes, there are other SPI-like serial protocols that are LSB-first, but they're not SPI

14:15 <whitequark[cis]> what we should ideally have is a configurable stream-based block which lets you transmit however much clocked data you like, any order you like

14:16 <whitequark[cis]> (or rather have a block that operates on a bit at a time and lets you easily build any kind of protocol on top of it)

14:16 <whitequark[cis]> but I don't want the SPI controller gateware to grow features for every silly thing a vendor's marketing department calls "SPI" until it's completely unmaintainable

14:16 <grazianom[m]> that would be nice. Until then I am swapping bits manually

14:17 <grazianom[m]> motorola also calls is MOSI and MISO not COPI CIPO

14:18 <whitequark[cis]> that doesn't affect behavior

14:18 <benny2366[m]> https://hackaday.com/tag/cipo/ thanks the woke

14:19 <whitequark[cis]> (if you don't like the naming change you should get a refund)

14:19 <grazianom[m]> yeah I saw that exact article because I had to google how to map miso to w/e of those

14:20 <grazianom[m]> anyway thanks for confirming about MSB, will keep playing with this

14:22 <whitequark[cis]> re: configurable serial block, to get there we'll need to migrate to Amaranth 0.5 first

14:22 <whitequark[cis]> which has streams

14:22 <sigstoat[m]> graziano.m (@_discord_119160277555085314:catircservices.org) you could copy and paste the spi applet and change behaviors for your purposes

14:24 <grazianom[m]> oh actually a quick q about the logic analyzer. It just dumps a vcd file. 1. its fifo seems to fill up in a split second. Is that expected? Maybe I had it sample rate super high, and maybe I have to disable all the other pins. 2. Any plans for a version that lets the glasgow enumerate as a logic analyzer so that I can e.g. use it with pulseview?

14:25 <grazianom[m]> as far as I can tell the spi applet doesn't configure msp/lsp, so I guess it's hardcoded in the spi bitstream. So I would have to manually do it in the `write` method or something. I am writing a script for it anyway, so I just wrap the write method in my own and do it there, without needing to modify the applet

14:30 <Wanda[cis]> the logic analyzer has a really tiny FIFO, so yeah; there are plans to use the RAM-pak addon to provide a properly large FIFO, but that's still in development

14:31 <Wanda[cis]> glasgow enumerating as a logic analyzer (or anything other than glasgow) is not planned, as it'd be a prohibitive amount of work to make it work with anything other than the host-side glasgow software stack, and also make us instantly run out of FX2 firmware space

14:46 <grazianom[m]> roger that. thanks

14:59 <whitequark[cis]> re: FIFO filling up, what is it filling up with?

14:59 <whitequark[cis]> sometimes it's floating pins which hover near Vcc/2, in which case you can add pull-ups on them to fix that

14:59 <whitequark[cis]> and in the SPI applet, MSB shift order is a part of the gateware, yes

14:59 <grazianom[m]> samples? I forget how is had it setup. Does it let you disable a bunch of inputs? I can try again... I just used one of those cheapos instead

15:00 <whitequark[cis]> (I looked at Motorola SPI and concluded that it should not be configurable)

15:00 <grazianom[m]> fair. Just sort of not great for reverse engineering when obviously we can encounter a ton of devices that aren't to spec. I don't blame you though

15:01 <whitequark[cis]> there is an inherent tension between "supporting obscure misdesigned protocols" and "providing legible, well tested behavior"

15:02 <whitequark[cis]> Glasgow makes gateware easy enough to write and test (and, in my view, fun) that it shouldn't be too difficult to write gateware for any obscure thing you want

15:02 <whitequark[cis]> this actually gets harder to do the more complex built-in applets are!

15:02 <whitequark[cis]> * more complex the built-in applets

23:06 <grazianom[m]> I just need to learn amoranth 🙂

23:07 <josHua[m]> MOSI/MISO COPI/CIPO: the latter is obviously correct, but there is a contingent of folks who have decided to rename these pins to SDI/SDO, which is completely fucking wrong

23:17 <threeflour[m]> I've seen it as PICO and POCI too :/. It seems like when one convention goes, everyone throws in their hat resulting in many more conventions.

23:22 <josHua[m]> PICO and POCI are definitely wrong but not as wrong as SDI and SDO

23:54 <wheresheisnt[m]> coming from the digital video world I get confused every time I read SDI and it’s not referring to a multi-gigabit video signal lol