This is a small helper function which sends the SR_DF_HEADER packet that
drivers usually emit in their hw_dev_acquisition_start() API callback.
It simplifies and shortens the hw_dev_acquisition_start() functions
quite a bit.
It also simplifies the input modules which send an SR_DF_HEADER packet, too.
This patch also automatically removes some unneeded malloc/free in some
drivers for the 'packet' and 'header' structs used for SR_DF_HEADER.
Check the relevant arguments for != NULL before calling the actual
driver-specific function, so that the driver can safely assume those
arguments are non-NULL. This removes the need to duplicate these
checks in every driver.
Also, do some minor whitespace and consistency improvements.
Check the relevant arguments for != NULL before calling the actual
driver-specific function, so that the driver can safely assume those
arguments are non-NULL. This removes the need to duplicate these
checks in every driver.
Also, change one SR_ERR to the more correct SR_ERR_MALLOC, and assign
sr_ctx in the rigol-ds1xx2's hw_init() function, like all the other
drivers do.
Sending an SR_DF_META packet at the start of every stream is not
mandatory; the frontend should ask for what it needs, and any extra
information the driver wants to send will come in due time.
Check whether a sample limit was actually set (> 0) before checking if
that sample limit is reached. This also fixes continuous acquisition mode
for drivers which have that.
We already have an event-based mechanism in place. Using a thread just
adds unneeded complexity, especially for a driver designed not for
performance, but for providing a testbed to frontends.
Generate the data in the event handler, not in a separate thread.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The demo driver was using sr_session_source_add_channel() to add
a poll source, but was relying on sr_session_run_poll() to call
sr_session_source_remove(). This, coupled with the design of the
driver caused errors once the samples were collected.
The error stream was most likely related to failing to properly close
one of the channels.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This is the first step in fixing the demo driver: figuring out what is
being called and what is not _and_ have it show up in the logs.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In the case of USB drivers, a driver's dev_acquisition_stop() cannot
simply remove its fd sources from the session and close its devices:
a USB transfer might still be underway, and it needs to be finished
(and its memory freed) properly.
An sr_dev_inst->status value is added: SR_ST_STOPPING, which should
be set when the driver's dev_acquisition_stop() is called, and acts
as a marker for the USB event handler to wind up its operations.
In order for dev_acquisition_stop() to be able to set the sdi status,
however, it needs to be unconstified.
These are used to list the device instances currently known to the driver,
and clear that list.
Drivers that don't necessarily clear their list of instances on every scan,
such as genericdmm, need to provide these to the frontend to keep instance
management sane.
Since probes now live in a struct sr_dev_inst owned by the driver, it
already knows about them. Instead of a frontend telling the driver to
configure probes, all driver now do this just before starting acquisition.
It's obsolete: no frontend ever used it, and neither did libsigrok.
The sdi->status field is only used internally by some drivers, and
should probably be moved to the driver-specific context structs.
This changes the semantics of the init() call as well. That now only
initializes the driver -- an administrative affair, no hardware gets
touched during this call. It returns a standard SR_OK or SR_ERR* code.
The scan() call does a discovery run for devices it knows, and returns
the number found. It can be called at any time.
Bert Vermeulen
Uwe Hermann
Peter Stuge
Alexandru Gagniuc