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-native-macosx-rpi-pico
Description: Binary data
_______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
