Hi Ladislav, Steve,
You are both correct but to me personally, such an effort feels misguided
simply because it would further increase the complexity of libsigrok while
cementing its role in the architecture.
>From my perspective, the only sane way to move forward is to push
libsigrokflow. Having
Hi Steve,
I'm not quite sure what made you ask about the API documentation but since
Ladislav already gave you the link, let me elaborate on my initial
statement a little:
My point is that to me personally, C is the wrong language to write device
drivers in when no bit fiddling and no high-perfor
Hi Ladislav,
Any help is appreciated, so if you have the motivation and time to help
then I'll gladly give you PR modification permissions. If this is something
you'd do, just mail me your github user name privately.
I do very much want to clean up the PR queue of the sigrok projects but
given my
It is great to see the interest in keeping sigrok alive! It fills an important
function and I really hope it will be kept alive.
I recently implemented a device driver for an FPGA based LA board I developed.
It was difficult because documentation is incomplete and in the end reverse
engineering
On Wed, Oct 15, 2025 at 10:06 AM Ladislav Laska wrote:
> https://sigrok.org/wiki/Hardware_driver_API
Nice, thanks!
Seems quite straightforward indeed.
> I would prefer if this could be C++, that is a matter of choice.
Well, I'd very much prefer C for an "public" API as it tends to be
easier to
What if we request to add gatekeepers to the project, and additional
domain/wiki managers?
I would prefer for clarity it doesn't fork, there's a strong brand/history and
moving it all would lead to confusion.
Did you talk at length with any of the original owners?
Cheers,Luc
On Saturday, O
AFAIK the current implementation is also lacking on ways to relay the
device limitations from the driver to the user, ie. max sample rate with
the selected amount of channels, max sample depth for non-streaming
devices.
On Wed, 15 Oct 2025, Ladislav Laska wrote:
> That makes a complete sense and
I also have permissions on github to close and thus triage pull requests.
Currently I do not have the time to do triage myself, but if given strong
hints to where to look I can then help clean the queue of stale or bad
pull requests.
On Mon, 13 Oct 2025, Soeren Apel wrote:
> Hi Ladislav,
>
> I co
8 matches
Mail list logo
