Catherine[m] changed the topic of #glasgow to: digital interface explorer · code https://github.com/GlasgowEmbedded/glasgow · logs https://libera.irclog.whitequark.org/glasgow · Matrix #glasgow-interface-explorer:matrix.org · discord https://1bitsquared.com/pages/chat
m42uko has quit [Ping timeout: 246 seconds]
m42uko has joined #glasgow
bvernoux has quit [Quit: Leaving]
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #glasgow
jn has quit [Ping timeout: 240 seconds]
jn has joined #glasgow
jn has joined #glasgow
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #glasgow
joerg has quit [Ping timeout: 272 seconds]
joerg has joined #glasgow
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #glasgow
<d1b2> <attiegrande> @whitequark - i had a look at supporting yowasp-yosys this week, but didn't get too far
<d1b2> <attiegrande> am I correct that glasgow leans heavily on LatticeICE40Platform (from amaranth), which does most of the lifting, and ultimately resolves yosys at present?
<d1b2> <attiegrande> so this is more of a patch to amaranth than glasgow(?)
<whitequark[cis]> it just needs to set an environment variable when calling the build
<d1b2> <attiegrande> oh!
<d1b2> <attiegrande> AMARANTH_USE_YOSYS (?)
<whitequark[cis]> (this is kind of why I wanted to do it myself... others tend to lack context and often don't acquire it as quickly. but we went through that before, so eh)
<whitequark[cis]> it's simply YOSYS
<whitequark[cis]> AMARANTH_USE_YOSYS is for the yosys that is used for conversion to Verilog
<d1b2> <attiegrande> ok, i didn't think that was correct
<whitequark[cis]> (this part is fairly confusing yeah)
<whitequark[cis]> (I'm actually going to stop relying on Yosys for Verilog conversion eventually, but it's there for now)
<whitequark[cis]> you need to set YOSYS, NEXTPNR_ICE40, and ICEPACK to the right values
<whitequark[cis]> but that's the easy part, the hard one is adding some code to make sure those (or whatever else the user environment provides) are indeed valid executables that we can get the versions of
<whitequark[cis]> well, hard*er*, it's more annoying than hard per se
<d1b2> <attiegrande> pip install yowasp-yosys yowasp-nextpnr-ice40 YOSYS=yowasp-yosys NEXTPNR_ICE40=yowasp-nextpnr-ice40 ICEPACK=yowasp-icepack glasgow build --rev C1 selftest
<d1b2> <attiegrande> seems to do the trick, thanks and sorry for getting the wrong end of the stick!
<whitequark[cis]> yep; the task is essentially automating that
<d1b2> <attiegrande> understood
<d1b2> <attiegrande> i have to admit from digging in amaranth, i didn't see anything about environment variables like that
<d1b2> <attiegrande> but i do see stuff setup in CI for it, now i know what to look for
<d1b2> <attiegrande> (very possibly just didn't dig deep enough)
<whitequark[cis]> it's in the build script
<whitequark[cis]> if you have Amaranth generate the folder with build.sh (which is the default outside of glasgow) you have a build script
<d1b2> <attiegrande> Ohh, I see what TemplatedPlatform.invoke_tool is doing now
<whitequark[cis]> that goes something like YOSYS=${YOSYS:-yosys} or whatever
<whitequark[cis]> it's also documented ^^;
<d1b2> <attiegrande> ha
<d1b2> <attiegrande> thanks / sorry for not reading!
<whitequark[cis]> oh wait I guess it's not
<d1b2> <attiegrande> out of curiosity, what did you put just before the YOSYS above? (i presume it's denoting a code block, but renders as a square for me / in discord)
<whitequark[cis]> (another env var is documented there, I forgot)
<whitequark[cis]> on the matrix side it's a `
<whitequark[cis]> but the Matrix to IRC bridge translates it to some mIRC specific code
<whitequark[cis]> and the IRC to Discord bridge doesn't do anything with it
<d1b2> <attiegrande> hah, fair enough
<d1b2> <attiegrande> i wondered... the first is a box, the presumably trailing is missing
<whitequark[cis]> I want to stop using d1b2 and run our own Matrix to Discord bridge for Glasgow and Amaranth because honestly I'm tired of the non-puppeting bridge d1b2 is
<whitequark[cis]> I have most of the infra for this, actually
<whitequark[cis]> I just need to test it on staging and coordinate the rollout of a bridge that potentially causes very many new IRC connections with the Libera staff
<whitequark[cis]> they've been happy with me bridging channels so far but as I get more experience operating it I'm getting more ambitious with my goals
<d1b2> <attiegrande> sounds good!
<whitequark[cis]> and that's something that needs to be approached with care
<whitequark[cis]> then you will be an IRC user attiegrande|d1b2
<whitequark[cis]> and a Matrix user @1bitsquared_attiegrande:catircservices.org
<d1b2> <attiegrande> sounds good
<whitequark[cis]> and all of this would work transparently with no one getting confused and trying to respond to d1b2 directly
<d1b2> <attiegrande> i'll always be grumpy when people grab 'attie' before i became present on the platform
<whitequark[cis]> awww
<d1b2> <attiegrande> 🙃
<d1b2> <attiegrande> i've now properly understood the "required tool" mechanism in amaranth - it's good, well done
<d1b2> <attiegrande> I initially just skimmed over it / didn't see the env var stuff
<whitequark[cis]> perfect ^^
<d1b2> <attiegrande> glasgow's pyproject.toml lists yowasp-yosys... but _BuiltinYosys calls for amaranth-yosys... is there a preference (or both?)
<d1b2> <attiegrande> I'd guess that if anything, amaranth-yosys is missing some features?
<d1b2> <attiegrande> think I answered my own question... yowasp-yosys and yowasp-nextpnr-ice40, not amaranth-yosys, correct?
<Wanda[cis]> amaranth-yosys is a minimal build with no synthesis capabilities, used only for RTLIL -> Verilog conversion
<Wanda[cis]> amaranth depends on it so it doesn't pull in the whole toolchain for non-yosys synthesis case
<d1b2> <attiegrande> yeah, that's what i settled on - thanks!
jevinskie[m]1 has joined #glasgow
<jevinskie[m]> TYVM! 
<jevinskie[m]> [Catherine](<https://matrix.to/#/@whitequark:matrix.org>) and anyone else who knows about the bridgeocolypse: any pointers to setting up my own irc bridge for other channels? I’m thinking about #litex and some other channels that may not take any actions?
<jevinskie[m]> Or maybe I should just ditch Matrix and use something like https://thelounge.chat Though a native client would be preferred but there don’t seem to be any good iOS IRC clients even if I set up a bouncer like znc
jstein has joined #glasgow
<whitequark[cis]> jevinskie: use heisenbridge in bouncer configuration
<d1b2> <attiegrande> what's the preferred way to check icepack's version? or is the mere existence good enough?
<d1b2> <attiegrande> (i don't see a --version type option)
<whitequark[cis]> uhh let's see
<whitequark[cis]> ok so if it's not a yowasp one, then just hash the binary.
<whitequark[cis]> crude but effective
<d1b2> <attiegrande> sure
<d1b2> <attiegrande> ... and for yowasp, just accept whatever?
<whitequark[cis]> no
<galibert[m]1> "Icepack is a Python library for solving the equations of motion of glacier flow."... not that one I expect?
<whitequark[cis]> for yowasp you can get the exact version using importlib.metadata
<d1b2> <attiegrande> oh, duh... ta
<whitequark[cis]> see the Python documentation for that one; plus grep the sources of my projects (yowasp, amaranth) to see how to use it with older Pythons
<d1b2> <attiegrande> yeah
<whitequark[cis]> this is also much faster than calling the binary, potentially, bc it might have to compile
<d1b2> <attiegrande> do you have insight into how often the binary changes / how many hashes i should be seeking?
<whitequark[cis]> sorry, I don't understand the latter question
<d1b2> <attiegrande> i'll take the latest from oss-cad-suite as a start, but...
<galibert[m]1> Ahhhhh, bitstream generator part of icestorm which is itself for the lattice support
<whitequark[cis]> lattice ice40 specifically
<d1b2> <attiegrande> re last question: .../oss-cad-suite/bin/icepack is MD5: af4d76174e4ac024bf8163c2ca753866
lolock has joined #glasgow
<d1b2> <attiegrande> do you think there might be more versions / hashes i should also accept in recent releases?
<d1b2> <attiegrande> (i'm happy to go pull a handful of releases and see for myself, just wondering if you know off the top of your head)
<whitequark[cis]> uhhh, what?
<whitequark[cis]> why would you accept a handful of hashes?
<galibert[m]1> which is the glasgow fpga, makes perfect sense now
<whitequark[cis]> I'm not suggesting you whitelist versions; I'm saying you should record versions (and hash them into the cache key for when we cache bitstreams, eventually)
<d1b2> <attiegrande> to give an equivelant of >= x.y (?) ... more than happy for just one, but if people are running an older toolchain, the hash might not match
<whitequark[cis]> oh
<whitequark[cis]> it won't work
<whitequark[cis]> we cannot predict what hash someone would have on their Gentoo system
<d1b2> <attiegrande> hah
<whitequark[cis]> or NixOS or any other source based distro
<whitequark[cis]> for icepack, I think there's been basically no bugs/changes as far as I remember
<d1b2> <attiegrande> tempted to just accept whatever exists, and we can revisit if there are issues?
<whitequark[cis]> yes
<whitequark[cis]> but definitely bake it into the cache key anyway
<d1b2> <attiegrande> ok, thanks
<d1b2> <attiegrande> will do (when I get to that task)
<whitequark[cis]> thank you
<Wanda[cis]> we seem to recall some issue on ice40 regarding memory clock polarities, though not sure if it was solved in icestorm or nextpnr
<whitequark[cis]> iirc it was in nextpnr
cr1901_ has joined #glasgow
cr1901 has quit [Ping timeout: 246 seconds]
<d1b2> <attiegrande> first stab, comments welcome
<whitequark[cis]> I'm still not really sure why the eagerness to do version comparisons?
<whitequark[cis]> I don't recall ever having to handle a bug that boiled down to "update Yosys"
<whitequark[cis]> I suppose it is good to have this functionality but I don't understand why you went for it... in Amaranth this is quite important because Amaranth writes a Yosys script in the Verilog backend that uses some Yosys commands that have changed over the years
<d1b2> <attiegrande> oh okay, I used amaranth for inspiration, more than happy to remove it
<whitequark[cis]> don't need `other_candidates`, don't need `version_args` (you don't even use it), `ToolchainAutodetect` -> probably just `Tool`, merge `get_version_info` with `check`
<d1b2> <attiegrande> a simple "is there a binary on the path" for all three satisfies?
<whitequark[cis]> instead of setup mutating the environment I think you should make it easy to fill out a new dict with the additional parameters (which will later get used in the Glasgow build process)
<d1b2> <attiegrande> I spotted "version_args" too
<whitequark[cis]> well you'll need version info later, but if you're not handling that yet, you can just toss it... I personally would build a module that handles both, test it, and then introduce it gradually
<whitequark[cis]> I'm tempted to just implement it myself rather than communicating every requirement precisely, to be honest
<whitequark[cis]> it would be faster and involve less back-and-forth
<whitequark[cis]> there's a fair bit of subtlety later, i.e. I think it makes good sense to have a single environment variable that switches between yowasp toolset and native toolset
<whitequark[cis]> and you aren't handling importlib.metadata for yowasp at all
wifasoi[m] has left #glasgow [#glasgow]
esden[m]1 is now known as esden[cis]
<d1b2> <attiegrande> sure, let's talk more later?
<d1b2> <attiegrande> I was hoping to take some pressure off you - still happy to talk things through, or let you take it on
<d1b2> <attiegrande> rolling versioning and other info require for caching into this does make sense
<d1b2> <attiegrande> *required
cr1901_ is now known as cr1901
<whitequark[cis]> yep sure
<d1b2> <esden> Are we having a meeting today?
<whitequark[cis]> I think so!
<whitequark[cis]> attie, are you around? electroniceel?
<electronic_eel> i'm here
<whitequark[cis]> so... technical progress from the previous time: nothing besides attie working on yosys toolchain invocation above
<whitequark[cis]> personal: my health is getting better and better by the week, so that's great
<electronic_eel> nice to hear!
<whitequark[cis]> oh wait, Wanda doing things was this week?
<Wanda[cis]> last week
<Wanda[cis]> but the meeting in the meantime didn't happen
<whitequark[cis]> no, the one before that
<whitequark[cis]> right
<whitequark[cis]> then, add to the technical progress list: Wanda ported everything off amaranth.compat
<whitequark[cis]> which is excellent news and very good job on her side
<Wanda[cis]> also we have Python 3.11 support now
<d1b2> <attiegrande> i'm here, sorry for lateness
<whitequark[cis]> oh, also excellent
<electronic_eel> oh, both points sound very good!
<d1b2> <attiegrande> re health: fantastic to hear!
<whitequark[cis]> social-ish? point: the Matrix room #glasgow:libera.chat is going away at the end of month due to what I can only describe as organizational incompetence (not on Libera's side)
<whitequark[cis]> so I set up #glasgow-interface-explorer:matrix.org that is bridged to IRC using my infrastructure which actually works well
<d1b2> <esden> it is great to hear that you are feeling better and improving!
<electronic_eel> whitequark[cis]: so that is why you are "[cis]" now...
<d1b2> <attiegrande> apologies ... wanda, are you aka mwk?
<whitequark[cis]> yes, the infra is called https://catircservices.org
<Wanda[cis]> attiegrande: yes
<whitequark[cis]> shortens to cis.
<d1b2> <attiegrande> great, thanks / hi!
<d1b2> <esden> Great work Wanda! 🙂
<whitequark[cis]> re bridging: I am considering doing my own double puppting bridge for Matrix<>Discord, therefore bridging IRC, Matrix, and Discord together
<d1b2> <esden> @whitequark let me know when you do that, I am happy to remove the irc bridge for the glasgow and amaranth channels whenever you are up for it.
<whitequark[cis]> meaning that someone talking on IRC will see Discord users (that actually talk in the channel) as e.g. esden|d1b2 user
<whitequark[cis]> it will require more coordination from your side, esden, to set up webhooks and do a trial run
<whitequark[cis]> so it's not quite as simple as that
<d1b2> <esden> Yes this is what I am expecting. I am here for it 😄
<whitequark[cis]> I will do rollout on https://staging.catircservices.org first, anyway
<d1b2> <esden> Sure sounds good, just let me know when you need anything regarding thes from me.
<d1b2> <esden> *this
<whitequark[cis]> will d
<whitequark[cis]> * will do
<whitequark[cis]> I don't have further updates at the moment
<whitequark[cis]> I've spent the last ~3 weeks mostly caring for my health
<d1b2> <attiegrande> very wise, and i'm happy to hear you're starting to get better
jstein has quit [Ping timeout: 246 seconds]
<d1b2> <attiegrande> @wanda - can you say more on py3.11 support? is that complete?
<whitequark[cis]> I mean I started to get better when I arrived in the UK, for the reason of "being a war refugee instead of just impacted by war"
<whitequark[cis]> it should be complete, yes
<whitequark[cis]> iirc tests pass
<d1b2> <attiegrande> fantastic, well done / thanks
<Wanda[cis]> attiegrande: it should be; tests pass, and so do a few applets we've tested
<d1b2> <attiegrande> apologies, didn't mean to put a date on "starting" (from my own experience, cronic health is very up-and-down)
<d1b2> <attiegrande> @wanda - awesome, I'll mark it off!
<d1b2> <attiegrande> @esden - any update on serials, or shall we track that separately?
<d1b2> <esden> I was just rushing to get an example together that I was working on
<d1b2> <esden> here is the gist with how the serial will look like
<d1b2> <esden> I mean the way I am planning to put it together
<d1b2> <esden> Here is an early sample generated for the zebra printer. I needs more polish. (see cut of characters
<d1b2> <esden> the size of that label is about 20mm wide and 6mm high
<whitequark[cis]> oh, this looks quite alright to me
<Wanda[cis]> (btw, glasgow currently doesn't work on python 3.12, which will be released in 3 months; there's a build error on two of the dependencies that we can't do much about at this point, but it may be worth manually hacking around that issue and checking if anything else is broken)
<whitequark[cis]> those dependencies are optional in spirit
<Wanda[cis]> (the problem is aiohttp, which I think is only required by one applet?)
<whitequark[cis]> yes
<d1b2> <esden> In any case. Current info included in text is lot and serial number.
<whitequark[cis]> and not one most people care about
<whitequark[cis]> esden: y/n on amending the Manufacturer field for 1b2 devices to say 1bitsquared?
<whitequark[cis]> in the USB firmware
<whitequark[cis]> this means you get your own serial block completely non intersecting with anyone else, at the very least
<d1b2> <esden> Yes that would be good
<whitequark[cis]> and if you want you can put like "1bitsquared Lot 1" there or sth
<whitequark[cis]> okay, can someone file this as a bug?
<d1b2> <attiegrande> spec looks great
<whitequark[cis]> I can do this next time I pick Glasgow up... potentially just tomorrow
<d1b2> <attiegrande> re mfg field - this is a firmware change?
<whitequark[cis]> tomorrow I wanted to fix a bunch of OSS bugs that're on me
<whitequark[cis]> yes
<d1b2> <attiegrande> will do
<whitequark[cis]> firmware and config block
<galibert[m]1> It’s not a bug, it’s a feature
<whitequark[cis]> lol
<whitequark[cis]> i stand corrected
<electronic_eel> yeah, the label spec looks good. i rarely see barcodes with properly separated fields.
<d1b2> <esden> @electronic_eel the above gist has the spec document linked
<d1b2> <esden> @whitequark so I guess regarding the firmware, there will be a setting that can be switched to select manufacturer?
<d1b2> <esden> I am not 100% clear how this will work.
<electronic_eel> esden: yeah, i know the specs. it is just that on many products i checked the manufacturers don't use them, they just cobble something together
<d1b2> <esden> this is why I am using the spec, and recently checked labels from mouser and digikey, they use the same spec these days
<d1b2> <esden> mouser wants "us" to use the spec too when sending them hardware
<whitequark[cis]> @esden: it would be a command line option that lets you flash anything you want to the "manufacturer" field in the EEPROM
<d1b2> <esden> @whitequark great! thanks 🙂
<d1b2> <attiegrande> @whitequark - is this also a resize to support the extra characters (IIRC?)
<whitequark[cis]> this seems easier than maintaining e.g. a list of known manufacturers
<whitequark[cis]> @attiegrande: no, the serial stays the same length
<whitequark[cis]> manufacturer is a different USB strings
<whitequark[cis]> s/strings/string/
<d1b2> <esden> here are a few boxes for the glasgow cases, with product labels
<whitequark[cis]> fantastic
<d1b2> <attiegrande> ha, UKCA... woo!
<d1b2> <esden> this is a similar label for the Glasgow hardware itself.
<electronic_eel> those look great!
<d1b2> <esden> still waiting for the cases to ship from china... but they are being worked on 😉
<tpw_rules> is it rev c3 rev a?
<d1b2> <esden> see product name
<whitequark[cis]> nicenicenice
<d1b2> <esden> the rev has nothing to do with that...
<d1b2> <esden> it is our internal manufacturing rev
<d1b2> <esden> I really wish it was model C3 not rev but we had that conversation before and it can't be change
<whitequark[cis]> eternally will i regret the choice of what to have called it
<whitequark[cis]> I mean, it's my first product, honestly it is not the worst mistake to make...
<d1b2> <esden> it is what it is... we can handle it 🙂
<d1b2> <attiegrande> re length - I meant the Manufacturer USB String, but you've already got whitequark research, which is longer... i misremebered
<d1b2> <esden> I will just need to setup a macropad with "no not that rev" 😄
<d1b2> <attiegrande> lol
<whitequark[cis]> attiegrande: "whitequark research" is currently in the firmware
<whitequark[cis]> and it'll be the default if the field is all-0's
<whitequark[cis]> 1bitSquared is 11 characters
<whitequark[cis]> I think if I set it to 24 that's fine?
<whitequark[cis]> the max length that is
<d1b2> <attiegrande> sounds good to me
<d1b2> <esden> I am fine with that too...
<whitequark[cis]> I'm pretty tired so I think I'll sign off for today, I will read the minutes for any other concerns that are brought up
<d1b2> <attiegrande> sure
<whitequark[cis]> gn
<d1b2> <attiegrande> i think i'm done for today too
<d1b2> <attiegrande> minutes on the way
<d1b2> <attiegrande> nn!
<electronic_eel> good night
<d1b2> <esden> Thank you all! have a good night/day 😄
<_whitenotifier-6> [glasgow] attie opened issue #347: Custom USB Manufacturer String - https://github.com/GlasgowEmbedded/glasgow/issues/347
<_whitenotifier-6> [glasgow] attie assigned issue #347: Custom USB Manufacturer String - https://github.com/GlasgowEmbedded/glasgow/issues/347
<_whitenotifier-6> [glasgow] whitequark commented on issue #347: Custom USB Manufacturer String - https://github.com/GlasgowEmbedded/glasgow/issues/347#issuecomment-1636903316
<_whitenotifier-6> [glasgow] attie opened pull request #348: meetings: add minutes from 2023-07-15 - https://github.com/GlasgowEmbedded/glasgow/pull/348
<_whitenotifier-6> [glasgow] attie commented on pull request #348: meetings: add minutes from 2023-07-15 - https://github.com/GlasgowEmbedded/glasgow/pull/348#issuecomment-1636903908
<_whitenotifier-6> [glasgow] attie synchronize pull request #348: meetings: add minutes from 2023-07-15 - https://github.com/GlasgowEmbedded/glasgow/pull/348
<_whitenotifier-6> [glasgow] attie commented on pull request #348: meetings: add minutes from 2023-07-15 - https://github.com/GlasgowEmbedded/glasgow/pull/348#issuecomment-1636904680
<_whitenotifier-6> [glasgow] mwkmwkmwk reviewed pull request #348 commit - https://github.com/GlasgowEmbedded/glasgow/pull/348#discussion_r1264579690
<_whitenotifier-6> [glasgow] attie synchronize pull request #348: meetings: add minutes from 2023-07-15 - https://github.com/GlasgowEmbedded/glasgow/pull/348
<_whitenotifier-6> [glasgow] attie reviewed pull request #348 commit - https://github.com/GlasgowEmbedded/glasgow/pull/348#discussion_r1264580000
Eli2| has joined #glasgow
Eli2_ has quit [Ping timeout: 246 seconds]
icb has quit [Quit: WeeChat 3.0]
icb has joined #glasgow
icb has quit [Quit: WeeChat 3.0]
<d1b2> <esden> ok, cleaned up the sticker a bit
icb has joined #glasgow
<d1b2> <esden> There are some limitations to ZPL2 ... font sizes are more discrete than I would like
<d1b2> <esden> Now I need to test printing them
<d1b2> <attiegrande> looking good... can you split the serial in half, and then put the 1T 1 S(?) all vertical / rotated 90'
<d1b2> <esden> the rotation helps to see what is a field indicator and what is a value
<d1b2> <esden> there is a reason behind it 😉
<d1b2> <attiegrande> (ish)
<d1b2> <esden> umm... yeah I could do that
<d1b2> <attiegrande> or is that layout important
<d1b2> <esden> no it is not
<d1b2> <esden> The S is the field indicator for the serial number
<d1b2> <attiegrande> Ahh okay
<d1b2> <esden> it is (1T) <- Lot Code and (S) <- Serial number
icb has quit [Client Quit]
<d1b2> <esden> they should actually be in brackets
<d1b2> <esden> but I was thinking of putting them in a box instead
<d1b2> <attiegrande> The 1T1 could be there by itself(?)...
<d1b2> <attiegrande> i just looked up your Gist again 😊
<d1b2> <esden> yes it could be on it's own
<d1b2> <attiegrande> your call, i'll stop back seat driving 🙃
<d1b2> <esden> I did want to have the serial number split nicely in half... I have to think how to do that
<d1b2> <attiegrande> does that not work? puts the date on one line, and the time (T__Z) on the other
<d1b2> <attiegrande> drops the S, but perhaps that's acceptable(?)
<d1b2> <esden> I have another idea, let me put that together
<d1b2> <attiegrande> sure
icb has joined #glasgow
<d1b2> <esden> @attiegrande here you go
<d1b2> <attiegrande> shiny!
<d1b2> <esden> I should use more of the margin I think... but I should test it on the actual labels first to see how they align