<AlexS>
Hi! Is it possible to ask glasgow/software/setup.py to install "toolchain" extra dependency during the same "python3.7 setup.py develop --user" command?
AlexS has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
<whitequark>
pip3 install -e software[toolchain]
<d1b2>
<Attie> @alen thanks! sorry it was too late for you... there is a VoD if you'd like to catch up, and I'll push to YouTube soon
<d1b2>
<alen> @Attie NP, just finish watching TNX
AlexS has joined #glasgow
<AlexS>
Thank you!
AlexS has quit [Remote host closed the connection]
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
bvernoux has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
electronic_eel_ has joined #glasgow
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel_ has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
<d1b2>
<Attie> @whitequark - am I correct in thinking you've got / had an SCD30 working?
<d1b2>
<Attie> did you see the "no response" during startup
<d1b2>
<Attie> ... i'd like to add a note or a small delay if the supply voltage is "turned on" to avoid this
<d1b2>
<Attie> (i can't see anything in the docs about a statup delay)
<electronic_eel>
maybe attie has a small capacitor on the psu of the SCD30?
<electronic_eel>
or whitequark is using a usb port with a higher output voltage, resulting in faster rise time of the programmed port voltage?
<electronic_eel>
adding a small delay sounds reasonable to me
<electronic_eel>
maybe also different revisions or lots of the SCD30 at play here
<whitequark>
not a fan of the delay
<whitequark>
that's a layering violation and ultimately not guaranteed to work
<whitequark>
since it makes largely unfounded assumptions about the electrical interface
<electronic_eel>
maybe some query at the beginning then till the SCD30 answers?
<electronic_eel>
with a timeout of course
<whitequark>
that would be more reasonable, though i'm not sure if anything really needs to be done
<electronic_eel>
@Attie do you use the same polymer bulk cap on your built of revC1 as specified or some different model? this could also be a reason for the difference here
<electronic_eel>
whitequark: the SCD30 looks to me like it is not just some dumb i2c device, but is much more complex and actually has some mcu inside
<electronic_eel>
that such stuff can take considerable amount of time to start seems to be reasonable to me
<whitequark>
electronic_eel: yes, but the reason i object is that "turning on Vio" and "SCD30 startup" are not inherently linked events
<d1b2>
<Attie> I've just wired a glasgow to bare SCD320 with dupont wires
<whitequark>
yep, i did that too
<d1b2>
<Attie> *SCD30 (i keep typing SCD32 for some reason...)
<d1b2>
<Attie> if i run glasgow run sensor-scd30 -V 3.3 calibrate off the bat, then i see that error
<d1b2>
<Attie> either running it again, or running glasgow voltage AB 3.3 --no-alert first resolves it
<whitequark>
i'm not sure i *really* want retries as the default behavior for single-shot measurement, but on the other hand, it has to be the default to be useful (since anyone who already knows about it can use glasgow voltage)
<d1b2>
<Attie> looks like it's only <=50ms startup
<d1b2>
<Attie> i agree that a delay isn't a nice way to deal with this... perhaps a note in the doc text?
<electronic_eel>
I don't see how we could check for "SCD30" startup from the outside other than waiting and retrying until it ACKs a read
<d1b2>
<Attie> I've got a patch that will insert a delay if the port's output is currently 0v
<d1b2>
<Attie> let me push, and you can consider it
<whitequark>
Attie: i would like *less* coupling between the applet code and Vio manipulation code than we have now, not more
<whitequark>
every single instance of this will bite us when we'll start rolling out multi-applet
<electronic_eel>
whitequark: we wouldn't have to add a delay. just an automatic retry in case the device doesn't ack. so no delay for cases where it is directly online
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
<d1b2>
<Attie> @whitequark thanks very much for the invitation and acknowledgement, i really appreciate it
<d1b2>
<Attie> as you've approved it, perhaps i'll make #237 my first push to master? (!)
massi_ has quit [Remote host closed the connection]
<whitequark>
sure
<electronic_eel>
Attie: just as a reminder: your membership in github starts out marked as "private", so only other members of the org can see it. if you want to have it visible to everyone, you have to change it in the options
<electronic_eel>
...and welcome to the team
<d1b2>
<Attie> ah yes, thanks for the tip... i have to admit, i've not been super involved with orgs / teams on github in the past, so this is new to me
<d1b2>
<Attie> and thanks!
egg|laptop|egg_ has joined #glasgow
<d1b2>
<Attie> rebasing the branch onto master and pushing fails because it needs approval, so what would be the procedure here?
<d1b2>
<Attie> rebase & push, ask for approval, then merge (if master hasn't advanced)?
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] attie pushed 2 commits to scd30 [+0/-0/±2] https://git.io/JImxl
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] attie-argentum bc357ba - applet.sensor.scd30: add a note about starting the sensor first
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] attie-argentum b0559cd - applet.sensor.scd30: add a note about the startup delay
egg|laptop|egg has quit [Ping timeout: 240 seconds]
<whitequark>
let me check, i might have went overboard with branch settings
<d1b2>
<Attie> interestingly, rebasing onto master, and pushing the branch, the pr is still marked as approved, but i can't push because i don't have at least 1 approval
<whitequark>
leaning towards "it mostly goes into forks", which would include my own WIP stuff
<whitequark>
with only unfinished but partially usable applets going into branches in the main repo
<whitequark>
(for discoverability)
<d1b2>
<Attie> i'm, happy to keep WIP on my own repos...
<whitequark>
i'll probably move my own WIP to my own fork i think
<d1b2>
<Attie> i guess unless it's a big / exciting feature that wants people to use / test
<whitequark>
yes, pretty much
<electronic_eel>
having the wip stuff in the main repo makes the workflow more easy i'd say, because then you don't have to cross-merge between different upstreams all the time
<whitequark>
hm, when would you do that?
<whitequark>
my workflow is basically `git pull --rebase origin master` then `git push -f`
<whitequark>
and you need that pull command with explicit upstream regardless of repo situation i think
<electronic_eel>
you have to update your private repo all the time and push the commits to master to your github-fork
<whitequark>
okei, i got rid of random WIP stuff that won't ever be useful as-is
<whitequark>
the rest has some chance of surviving (though i'm still bitter about the AUI adapter)
<d1b2>
<Attie> what happened with the AUI adapter? (unless you want to pretend it doesn't exist)
<whitequark>
i asked for review on here, and i got a review, but it was not particularly kind
<whitequark>
so i just gave up on that schematic
<d1b2>
<Attie> oh...
<whitequark>
technically, i think everything that was pointed out was fair
<whitequark>
but i haven't really looked forward to making any adapters myself since
<d1b2>
<Attie> sorry to hear that
<electronic_eel>
i don't remember - have i taken part in that review process? you set some high standards for the code quality and proper modeling and so on, that i try to strive for a similar level for the electronics...
<electronic_eel>
might get carried away by that sometimes
<whitequark>
you have, and i appreciate the high standards. really the only issue is that i'm a novice digital designer, and i know even less about analog stuff
<whitequark>
which is probably easy to forget if you only read my code
<whitequark>
i would treat a junior programmer very different in review (which creates some highly unfortunate dynamics in OSS maintenance, but i digress)
<electronic_eel>
sorry for any bitterness i've caused
<whitequark>
like, to be clear; (for context, iirc the AUI adapter had a switcher) i've never designed a switcher that actually worked like it should have. even when i mostly copied the appnote example it didn't work out as it should have
<whitequark>
no problem. just keep it in mind next time.
<whitequark>
also, whoever likes making adapters can pick up the AUI one :p
<whitequark>
the review is in the irc log (i can probably find it) and i think it'd be a fun adapter to have
<electronic_eel>
if you want, we could make a up to high standards aui adapter as a team effort?
<d1b2>
<0x53A> any quick idea why glasgow list might throw usb1.USBErrorIO: LIBUSB_ERROR_IO [-1] on windows? It worked some time ago, but in the meantime I did a git pull, windows updated itself and I updated python to 3.9... The device is visible in device manager
<whitequark>
electronic_eel: that sounds very nice
<whitequark>
(and something i'd really expect from asking for a review at my skill level, really...)
<whitequark>
0x53A: it probably doesn't have to do anything with glasgow or python
<whitequark>
is your device flashed? i.e. does the FX2 LED light up?
Stormwind_mobile has quit [Ping timeout: 256 seconds]
<d1b2>
<0x53A> yes, and list already worked about a month ago
<electronic_eel>
0x53A: could it be that the python libusb dll doesn't fit to the new python version?
<whitequark>
that seems unlikely
<whitequark>
i mean, do you have a particular hypothesis as to what doesn't fit?
<whitequark>
0x53A: you can always use Zadig as a nuclear option
<electronic_eel>
no particular hypothesis, just that the dll has to be in the correct path
<whitequark>
hang on
<electronic_eel>
and the path could have changed with the update
<whitequark>
0x53A: did you update the python dependencies of Glasgow as well?
<whitequark>
electronic_eel: because if yes, that will pull in the binary wheel, which I built *exactly to avoid this problem*
<d1b2>
<0x53A> I ran setup.py again after git pull
<whitequark>
yep, that should be using the binary wheel
<whitequark>
(in any case, if it couldn't find the DLL, the error would be different, but it's useful to know anyways)
<d1b2>
<0x53A> I put libusb into system32 a month ago because I didn't get it to work otherwise. If I remove it from system32 I get a file not found, so it does NOT seem to be installed by the script
<whitequark>
oh, that's worrying
<whitequark>
can you do uh
<whitequark>
pip install -U libusb1 ?
<d1b2>
<0x53A> I'm not sure what I did before, but now it works even without the one in system32, so the script does work (sorry for the confusion!)
<d1b2>
<0x53A> pip only said it was already installed
<whitequark>
huh.
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JIYeL
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark 1b927ca - software: require libusb1 version with Windows binary wheels.
<whitequark>
for good measure, i updated the version requirement
<d1b2>
<0x53A> hm I used zadig to change the driver from libusb to libusbk, and now it works, though I'm 65% sure it previously worked with libusb
<whitequark>
try changing it to libusb again
<whitequark>
actually, WinUSB is probably the best choice
<d1b2>
<0x53A> glasgow list works, that is. glasgow run sensor-scd30 --port A --pin-scl 0 --pin-sda 1 -b 100 -V 3.3 calibrate failed with 'yosys' is not recognized as an internal or external command. Do I need to install that seperately, or is it just missing from path?
<whitequark>
since that's what everyone without zadig will use
<whitequark>
uh, sort of both at the moment
<whitequark>
do this:
<whitequark>
(in glasgow checkout) pip install software[toolchain]
<whitequark>
(or install -e if you want develop mode)
<whitequark>
then, do the following before glasgow run:
<whitequark>
(three separate commands) set YOSYS=yowasp-yosys ; set NEXTPNR_ICE40=yowasp-nextpnr-ice40 ; set ICEPACK=yowasp-icepack
<whitequark>
okay, try running it, after doing the `set`s
<d1b2>
<0x53A> I'm running it inside the software subdirectory, is that ok?
<d1b2>
<0x53A> or should it be run at root
<d1b2>
<0x53A> C:\glasgow\repo\glasgow\software>pip install software[toolchain] Requirement already satisfied: software[toolchain] in c:\users\lr\appdata\local\programs\python\python39\lib\site-packages (0.0.0) WARNING: software 0.0.0 does not provide the extra 'toolchain'
<whitequark>
no, at root
<whitequark>
i have no idea what the heck you just installed
<d1b2>
<0x53A> C:\glasgow\repo\glasgow>pip install software[toolchain] Requirement already satisfied: software[toolchain] in c:\users\lr\appdata\local\programs\python\python39\lib\site-packages (0.0.0) WARNING: software 0.0.0 does not provide the extra 'toolchain'
<whitequark>
hm
<whitequark>
hang on
<whitequark>
try `./software[toolchain]` instead of `software[toolchain]`
<whitequark>
i wasn't thinking of this edge case
<whitequark>
mildly annoying
<d1b2>
<0x53A> ok that does more: LookupError: setuptools-scm was unable to detect version for 'C:\\Users\\lr\\AppData\\Local\\Temp'.
<whitequark>
needs more context
<d1b2>
<0x53A> C:\glasgow\repo\glasgow>pip install ./software[toolchain] Processing c:\glasgow\repo\glasgow\software ERROR: Command errored out with exit status 1: command: 'c:\users\lr\appdata\local\programs\python\python39\python.exe' -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\lr\\AppData\\Local\\Temp\\pip-req-build-mgwngumu\\setup.py'"'"';
<d1b2>
not available. Traceback (most recent call last): File "<string>", line 1, in <module> File "C:\Users\lr\AppData\Local\Temp\pip-req-build-mgwngumu\setup.py", line 15, in <module> setup( File "c:\users\lr\appdata\local\programs\python\python39\lib\site-packages\setuptools\__init__.py", line 165, in setup return distutils.core.setup(**attrs) File "c:\users\lr\appdata\local\programs\python\python39\lib\distutils\core.py",
<d1b2>
line 108, in setup _setup_distribution = dist = klass(attrs) File "c:\users\lr\appdata\local\programs\python\python39\lib\site-packages\setuptools\dist.py", line 429, in __init__ _Distribution.__init__(self, {
<d1b2>
<0x53A> File "c:\users\lr\appdata\local\programs\python\python39\lib\distutils\dist.py", line 292, in __init__ self.finalize_options() File "c:\users\lr\appdata\local\programs\python\python39\lib\site-packages\setuptools\dist.py", line 721, in finalize_options ep(self) File "c:\users\lr\appdata\local\programs\python\python39\lib\site-packages\setuptools\dist.py", line 728, in _finalize_setup_keywords ep.load()(self,
<d1b2>
ep.name, value) File "c:\users\lr\appdata\local\temp\pip-req-build-mgwngumu\.eggs\setuptools_scm-4.1.2-py3.9.egg\setuptools_scm\integration.py", line 17, in version_keyword dist.metadata.version = _get_version(config) File "c:\users\lr\appdata\local\temp\pip-req-build-mgwngumu\.eggs\setuptools_scm-4.1.2-py3.9.egg\setuptools_scm\__init__.py", line 148, in _get_version parsed_version = _do_parse(config) File
<d1b2>
"c:\users\lr\appdata\local\temp\pip-req-build-mgwngumu\.eggs\setuptools_scm-4.1.2-py3.9.egg\setuptools_scm\__init__.py", line 110, in _do_parse raise LookupError( LookupError: setuptools-scm was unable to detect version for 'C:\\Users\\lr\\AppData\\Local\\Temp'.
<whitequark>
please use pastebin, this channel is bridged to IRC and what you pasted is completely unreadable
<d1b2>
<0x53A> I assume the cwd: C:\Users\lr\AppData\Local\Temp\pip-req-build-abyvogf2\ is the issue?
<d1b2>
<0x53A> yup that downloads
<whitequark>
i suspect this is related to pip isolation
<whitequark>
*pip build isolation
Stormwind_mobile has joined #glasgow
<whitequark>
easier to just not deal with that for now
<d1b2>
<0x53A> ERROR: Could not install packages due to an EnvironmentError: [WinError 5] Access is denied: 'C:\\Users\\lr\\AppData\\Local\\Temp\\pip-uninstall-pue1wk8u\\glasgow.exe' Ill retry as admin
<whitequark>
that sounds vaguely wrong but go ahead
<d1b2>
<0x53A> Successfully installed glasgow
<whitequark>
no idea what broke there
<whitequark>
ok, good
<d1b2>
<0x53A> yes! Preparing to run yowasp-yosys. This might take a while...
<d1b2>
<0x53A> CO₂ concentration : 3330 ppm temperature : 25.02 °C relative humidity : 53 % thank you!
<whitequark>
\o/
<whitequark>
another success for yowasp
<d1b2>
<0x53A> so except for the usb weirdness at the beginning, the only change was pip install -e .\software[toolchain] instead of pip install software[toolchain] I think (and I had to run it as admin for some reason)
<whitequark>
yep
<whitequark>
the admin thing is probably related to the way you installed python
<whitequark>
though i'm not sure
<d1b2>
<0x53A> the 3.9 setup.exe, though no venv because I'm a python noob
<whitequark>
did you tick a box that says "install for all users" or sth?
<d1b2>
<0x53A> yes
<whitequark>
yep, so now you need to be admin to install stuff via pip
<whitequark>
there's install --user but i'm not sure if that does anything on windows
<whitequark>
ok, wait, it does
<electronic_eel>
hmm, these continuos toolchain problems are annoying. whitequark, i can understand why you invest so much energy into impoving this
<electronic_eel>
let's hope we just see a few edge cases popping up here in the channel and not most of the people that built their own glasgow
<whitequark>
electronic_eel: this is basically flawless, most projects require orders of magnitude more effort
<electronic_eel>
or could it be the target audience? i mean glasgow has appeal for people not into fpga development. but anyone into fpga dev will need a good skillset in toolchain management or they won't even get so far as a blinky
<whitequark>
what do you mean by "it" here?
<electronic_eel>
if this is basically flawless, we still see enough people coming to the channel with toolchain problems
<whitequark>
oh, i was unclear
<whitequark>
the problems are real, it's just that most people shipping python software are far more tolerant to them than i am
<whitequark>
so it's not that we can't fix this (we can, and i will); it's that this is flawless compared to the usual situation
<d1b2>
<0x53A> Minor issue, but I thought I'd still report it: after unplug and replug, the first glasgow command will error out: https://pastebin.com/tPUU4jSq The second command then works.
<whitequark>
(doubly so compared to the usual fpga toolchain situation, which is a complete disaster)
<whitequark>
0x53A: hrm, you should report that on the tracker
bvernoux has quit [Quit: Leaving]
bvernoux has joined #glasgow
<_whitenotifier-f>
[glasgow] 0x53A opened issue #239: On windows, first glasgow command after plug-in errors, second one works - https://git.io/JIYIq
<_whitenotifier-f>
[glasgow] whitequark commented on issue #239: On windows, first glasgow command after plug-in errors, second one works - https://git.io/JIYIs
<d1b2>
<0x53A> I did get a heap corruption crash after two consecutive measure, callstack seems to point to libusb, though it could have been corrupted earlier. should I report it at all, and if yes, to glasgow repo or libusb repo? (I do have a dump-file, though not sure if it is usefull)
<whitequark>
neither
<whitequark>
dumbass heap corruptions during interpreter shutdown are sort of unavoidable with the current python-libusb1 design
<whitequark>
i mean, you can report them, but i think everyone with the motivation and skill to fix them already well knows
<d1b2>
<0x53A> alright. I did >10 more, and it didn't reproduce.
<whitequark>
it definitely happens occasionally, depending on luck and GC destruction order
<whitequark>
note that you
<whitequark>
*you'll probably see it only when something throws an uncaught exception
<whitequark>
successful shutdown should not segfalut
<whitequark>
though i've seen that segfault as well...