azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
<_whitenotifier> [scopehal-apps] 602p forked the repository - https://github.com/602p
<_whitenotifier> [scopehal-apps] 602p opened pull request #410: Fix crash on CSV export (and other bugs) in protocol analyzer window - https://github.com/glscopeclient/scopehal-apps/pull/410
<_whitenotifier> [scopehal-apps] azonenberg closed pull request #410: Fix crash on CSV export (and other bugs) in protocol analyzer window - https://github.com/glscopeclient/scopehal-apps/pull/410
<_whitenotifier> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://github.com/glscopeclient/scopehal-apps/compare/e8599d763112...df8efa38a954
<_whitenotifier> [scopehal-apps] 602p 582e028 - Fix crash on CSV export (and other bugs) in protocol analyzer window
<_whitenotifier> [scopehal-apps] azonenberg df8efa3 - Merge pull request #410 from 602p/proto_analyzer_csv_fix Fix crash on CSV export (and other bugs) in protocol analyzer window
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #scopehal
<_whitenotifier> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/glscopeclient/scopehal/compare/05454b085041...823cfb498662
<_whitenotifier> [scopehal] azonenberg 823cfb4 - Continued work on CSV export. Can now choose list of channels to export, but not the final file name or CSV generation yet. See #571.
<azonenberg> @arjenroodselaar bad news, i just checked digikey and the correct-speed-grade artix7 is now listing an ETA of january 4th
<azonenberg> ... 2024
<azonenberg> meanwhile the two artix ultrascale+s that i ordered (capable of handling the full rate AD9213, not just the slow one) have an ETA of March 2023
<azonenberg> So it might make sense to design that fpga board around the au+ instead
<azonenberg> in any case, the fpga board is... not going to be a near term design priority
<azonenberg> neither is the ADC board, as it's useless without a host
<azonenberg> last time i checked i had one of the two key amplifiers for the frontend though, and the other was due in may
bvernoux has joined #scopehal
<Degi> RIP
<Degi> Hm, you could make an interposer between ADC board and a dev board but also that might introduce errors, like wanting a different connector layout later on, so maybe not the best idea
<azonenberg> i mean i could design the adc board
<azonenberg> but it's useless without a host that has 12 jesd204 lanes
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
<GyrosGeier> I bought the last Cyclone FPGA in existence
<GyrosGeier> no more low cost Intel FPGAs
<azonenberg> lol
<GyrosGeier> and it was a CycloneV SX
<GyrosGeier> now I need to add DDR3 memory on both sides
<GyrosGeier> Micron are no longer building 1G8 memory, only 512K8
<GyrosGeier> currently pondering Alliance Memory Inc.
<azonenberg> alliance and ISSI seem to be the go-to vendors for embedded memory that is no longer leading edge
<azonenberg> But I generally dont buy loose memory chips
<azonenberg> its cheaper to just slap down a sodimm
<GyrosGeier> yes
<GyrosGeier> but the CycloneV doesn't have write leveling
<azonenberg> ah ok
<GyrosGeier> still, 11 EUR per GB is steep
<GyrosGeier> and that's for 512K8
<GyrosGeier> wait
<GyrosGeier> 512K8 is 22 EUR per GB
<azonenberg> yeah this is why i use parts that can do a full dimm :p
<GyrosGeier> if I want a full loadout, with 8GB+ECC for the HPS, and 8GB+ECC for the FPGA side, I need 20 1G8 chips
<GyrosGeier> that would be 520 EUR
<azonenberg> o_O
<azonenberg> yeah, and how much is a sodimm at newegg?
<azonenberg> lol
<GyrosGeier> heh, I could unsolder a few chips
<azonenberg> well soo
<azonenberg> there is also the potential of getting a cheap sodimm and just only using say the first 16 bits or something
<azonenberg> if it's a 4x 16 module
<azonenberg> that might be cheaper especially if you get ebay memory
<azonenberg> lol
<GyrosGeier> or measuring the trace lengths on the cheap SODIMM
<GyrosGeier> 16 bit wide is a no go though, because I wouldn't have ECC then
<azonenberg> i mean you can always diy write leveling in a custom controller
<GyrosGeier> it's a Hard IP block
<GyrosGeier> and the DLLs are used for read leveling
<GyrosGeier> lol a 16 GB ECC DDR3 DIMM costs 35 EUR
<GyrosGeier> the picture has 8 chips though
<azonenberg> yeah you see why i use sodimms lol
<GyrosGeier> hmm
<GyrosGeier> ah, these are x4
<GyrosGeier> that won't work
bvernoux has quit [Read error: Connection reset by peer]
<azonenberg> GyrosGeier: btw, what is the status on the debian packages you were working on?
<GyrosGeier> still no testers
<GyrosGeier> other than that, they are done, but will need to be updated
<GyrosGeier> i.e. someone needs to designate another version as "release"
<azonenberg> ok
<azonenberg> i also want to start looking into packaging of several of the bridges
<azonenberg> these all have dependencies on various third party SDKs (pico, digilent, dreamsourcelabs)
<GyrosGeier> mh
<azonenberg> the first two have non-free licenses, the latter is i think GPL as it's a sigrok fork
<GyrosGeier> those would have to go into contrib
<GyrosGeier> ah
<azonenberg> The pico and digilent SDKs are available as .deb packages so we can make packages that depend on e.g. the "picoscope" package
<azonenberg> but if that package is not in distro repos i'm not quite sure how this works
<azonenberg> i think having unofficial binary packages on a PPA or otherwise not upstreamed is probably the best way to handle this
<azonenberg> while glscopeclient proper should aim to be in the mainline distro repo
<azonenberg> This is precisely why these components are isolated into separate repos and packages
<azonenberg> to provide a clean boundary between the components
<azonenberg> the pico/digilent bridges are BSD licensed code but link to non-free libraries and the dreamsourcelabs bridge is BSD licensed source but links to GPL code so the binaries are GPL
<azonenberg> Anyway this is not a super near term priority as we're a ways from being ready to do a release still
<azonenberg> But if you could start thinking about what the best way to do this from a packaging perspective is, i'd appreciate your input
<azonenberg> the Pico binaries are here https://www.picotech.com/downloads/linux
<azonenberg> (ooh there's a version 7 out now, i'm still using 6 - ishould update and try it)
<azonenberg> GyrosGeier: so for example, if our package is in contrib but depends on a package not in contrib, how does that even work?
<jacekowski> this is why i really like gentoo
<azonenberg> Would we have to work with pico to get their package into contrib?
<azonenberg> or non-free i guess
<jacekowski> pico would have to be willing to do it
<jacekowski> or someone would have to maintain the package
<jacekowski> and generally this is where linux sucks, you have to build 100 packages for 100 different distros
<jacekowski> snap sort of aims to work around that
<azonenberg> I have contacts at pico and am willing to facilitate a relationship with them and distros/maintainers if that's what it takes
<azonenberg> They have limited engineering resources so can't put a ton of time in on their end
<azonenberg> but are supportive of the project in general
<jacekowski> azonenberg: are they willing to put the resources in to keep it in the repo
<azonenberg> What is needed on their end to do that?
<azonenberg> at this point they periodically release binary blob .deb packages
<azonenberg> Probably not in the near term but we'll see how things go longer term
<jacekowski> why debian and not ubuntu
<azonenberg> Because that's what i run
<jacekowski> or .rpm based distro
<azonenberg> if someone else wants to make rpm packages i'm fine with that
<azonenberg> i just have no way to test them etc
<azonenberg> anyway near term i think what will probably be simplest is to use CPack or some other simple script to generate debs of the bridges, and have them downloadable as artifacts from the github repo for each project
<azonenberg> mark them as depending on the picoscope or digilent package names as appropriate
<azonenberg> and rely on the user to obtain and install those packages on their own
<azonenberg> without making any effort to get the bridges into distros
<azonenberg> if there's enough outcry from users we can look into changing that state of affairs
<azonenberg> jacekowski: does that sound reasonable?
<azonenberg> in terms of not making users compile everything themselves, but not carrying the workload of making someone at pico become an official package maintainer for their blob
<azonenberg> although that would certainly be nice to do longer term
<azonenberg> i mean i would love if one day pico open sourced their drivers
<azonenberg> but idk how likely that is
<azonenberg> Their software is free-as-in-beer but there may be some secret sauce in it they don't want to give out, idk
<monochroma> just do one flatpak/snap/appimage *nodsnods*
<azonenberg> lol
<azonenberg> in all seriousness, i do want binary releases of the bridges eventually
<azonenberg> but i don't have any time to put into making it happen personally
<jacekowski> afaik you are not allowed to have "broken" dependencies in a repo
<azonenberg> jacekowski: yeah
<azonenberg> so if i make a package that depends on "picoscope"
<jacekowski> as in, package in official repository can only depend on packages in official repository
<azonenberg> it has to either be in a PPA / just downloadable from github
<jacekowski> it will not be allowed in official repositories unless "picoscop" is there as well
<azonenberg> or we have to get "picoscope" into the distro non-free repos
<azonenberg> the latter is definitely the better long-term option
<azonenberg> I'll reach out to the folks there and see if they're potentially interested
<azonenberg> but near term i think unofficial repos are the only option
<jacekowski> interested is one thing
<jacekowski> willing to actually do something about it is another
<azonenberg> Yeah
<jacekowski> that's why i run gentoo, i end up having to build packages for a lot of stuff i want, with gentoo i only have to write ebuild once
<jacekowski> and it will automagically pull from git/svn as needed and build stuff
<azonenberg> Feel free to work on gentoo packaging for glscopeclient/libscopehal and the bridges
<azonenberg> the more the merrier
<azonenberg> Just make sure they're clearly marked as prerelease/alpha level stability
<azonenberg> for now
<jacekowski> with gentoo you just add
<jacekowski> ~amd64 keyword
<azonenberg> (I dropped Alan a ping to see, hasn't replied yet)
<azonenberg> it's after 9pm in the UK though
<azonenberg> On a friday evening
<azonenberg> Also @mubes i have feelers out to siglent to get a sds2000x+ and/or 5000x+ demo unit in the indefinite near future for use to optimize the glscopeclient drivers and general system performance on slower hardware
<azonenberg> no commitment on specific timing etc yet
<d1b2> <mubes> 2000+ and 5000+ should be reasonably interchangable.
<azonenberg> yeah its a question of which they can get a demo of first
<azonenberg> it sounds like they dont have a 2000 available at my local rep
<GyrosGeier> 21:46 < azonenberg> but if that package is not in distro repos i'm not quite sure how this works
<GyrosGeier> that's what "contrib" is for
<GyrosGeier> that's meant for things that have dependencies that are not free software
<azonenberg> yes but does the dependency still have to be in non-free?
<azonenberg> or can the dependency be on some third party company's server
<azonenberg> as in, we need pico to get their packages into the debian non-free repo
<azonenberg> in order for me to get my bridge into contrib?
<GyrosGeier> so hmm
<GyrosGeier> I have to check that, actually
<GyrosGeier> but AFAIK it is okay if the dependency isn't in non-free
<GyrosGeier> like, my FPGA sources are GPL'd, and you need Quartus to compile
<GyrosGeier> and ftpmasters said that was okay for contrib
<azonenberg> In that case, can you look into setting up packaging for scopehal-pico-bridge? which depends on the pico packages i linked above
<azonenberg> it's nowhere near release ready but i want to get the ITP and process moving
<GyrosGeier> mmh
<GyrosGeier> will be a while, my life is chaos right now
* GyrosGeier writes down links
<azonenberg> absolutely not a rush, next few months would be nice if possible
<azonenberg> also note that the github location for the main glscopeclient repo has changed for the debian package
<azonenberg> it's now under the "glscopeclient" org rather than my personal "azonenberg" account
<azonenberg> (although the old url should redirect to the new one)
<GyrosGeier> ah good
<azonenberg> all of the other bridges and such have moved over there too
<azonenberg> i will eventually probably set up a github.io web presence for the project to host documentation and a landing pad and such
<azonenberg> oh and before i forget i need to change the repo url in the channel topic
azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
<GyrosGeier> long term there should also be someone who wants to take over
<GyrosGeier> I'm happy to do the initial work and help out later, but there might be a time when I'm just too busy
<azonenberg> we'll cross that bridge when we get there
<azonenberg> i'm trying to ramp up industry support of the project