All, Sorry for the slow delay here, I was on vacation. @Gerard Sitting : If possible I'd like to get the discussion going about how to get pull 181 integrated. Arguably, Pulseview likely does not need a library driver for every MCU out there that happens to have some GPIOs and an ADC, so maybe we need to talk about what a more common driver might look like. Though the PICO is probably one of the most capable due to the PIO being able to provide fast and accurate samples and a pretty darn fast 500Ksps ADC. I originally was trying to code a more generic driver but ended up adding a lot of PICO related limitations to help prevent users from doing bad things. That may need to be rethought for a more generic driver. I'm also still on USB CDC rather than a native USB implementation, though I'm not aware of any real benefit to migrating as CDC performance seems to approach maximum throughput. USB CDC also avoids hacky issues around trying to leverage left-over USB VIDs from now defunct companies...
I also apologize for the non-git-ness of the build instructions. I'm barely functional using git and most of the new github related flows were something I was fumbling on pretty badly (notice all of the previous attempts to get 181 right). Though I was assuming that things might get merged sooner so that folks wouldn't have to deal with any of it. @Dan - if you learned anything about how to do better build flows please file a ticket against the pico-coder repo. For the most part, the real difficulties with people getting builds to work are figuring out the library dependencies. Thus I prefer that people build a baseline first to make sure their libraries are good so that they can isolate build problems from their environment rather than problems with my driver. I don't own a Mac so any Mac specific info would be helpful. Thanks, Shawn (pico-coder) On Tue, Jun 14, 2022 at 9:46 PM Dan Crocker <d...@crockerworld.org> wrote: > Ok, it looks like I got it working! > > Basically, I cloned all repositories except libsigrok from sigrok.org > and I cloned libsigrok from github.com/pico-coder (the pico driver). > The build script is essentially the same as the original with the > following changes: > > -Grabbing libsigrok from pico-coder instead of sigrok.org > -A handful of changes specific to my environment (not checking for > python2, using qt@5) > > I also got the raspberry pi pico firmware from pico-coder. > > I attached the script. > > The resulting pulseview still fails the test I mentioned. I haven't > yet tried to figure out why. But, I was able to trigger on and capture > a trace of a clock signal. I did see some odd results, but this could > be because I really don't know how to configure and use pulseview. > Note that all I did was capture one signal so it's not like I did a > huge amount of testing. It still could be only partially functional. > Soon, I will try to hook it to something more interesting to see what > happens. > > Thanks very much for all the help. > Dan > > > On Tue, Jun 14, 2022 at 12:03 PM Dan Crocker <d...@crockerworld.org> wrote: > > > > Yes, having it already in mainline would have been nice (and would be > > nice in the future). But, I'm also kind of enjoying trying to sort all > > this out. It's forcing me to learn new things. If any of you is an > > engineer, you probably know that, sometimes, having a problem to solve > > is fun (when you have the luxury of time). > > Anyways, I'll keep plugging along... :) > > Thanks, > > Dan > > > > > > On Tue, Jun 14, 2022 at 9:53 AM Rene Kita <m...@rkta.de> wrote: > > > > > > On Tue, Jun 14, 2022 at 06:47:58AM +0200, Gerhard Sittig wrote: > > > [...] > > > > The other issue is that manually patching the source to introduce > > > > the non-operational skeleton, and then to manually copy in more > > > > file content, which is not under version control, and is getting > > > > lost in iterations, is tedious and non-reproducable. Would have > > > > expected some addition of another remote, checkout of that > > > > branch, and be done with two additional commands and no other > > > > manual work involved. > > > > > > > > Another option would be to globally change the common prefix for > > > > repos that are being fetched from at the start of the script, in > > > > the tunables section. To not get the sigrok.org master but > > > > somebody else's code base instead. Consistently as it is kept > > > > there in a set of repos that belong to each other, similar to > > > > what sigrok.org provides. The script is prepared to do that, it's > > > > not (by design) prepared to run an arbitrary combination of > > > > unrelated changes from different repos. Notice that this remote > > > > repo might as well reside on your disk. Nobody said that a > > > > network needs to be involved. > > > > > > > > I'm aware this is not your fault Dan for trying to follow these > > > > instructions. It's the instructions that are weird and un-gitty > > > > > > The best way from a user perspective is probably getting the changes > > > into mainline; we are talking about a PR on a sigrok repo. ;) > > > > > > And yeah I know... Maybe it helps when Dan gets it to work and can > > > confirm that it works as expected. > > > > > > > virtually yours > > > > Gerhard Sittig > > > > > > Gruß Rene > > > > > > > > > _______________________________________________ > > > sigrok-devel mailing list > > > sigrok-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/sigrok-devel > _______________________________________________ > sigrok-devel mailing list > sigrok-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sigrok-devel >
_______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
