+/*
+ * Process a chunk of capture data in streaming mode. The memory layout
+ * is rather different from "normal mode" (see the send_chunk() routine
+ * above). In streaming mode data is not compressed, and memory cells
+ * neither contain raw sampled pin values at a given point in time. The
+ * memory content needs transformation.
+ *
+ * All enabled channels get iterated over. Disabled channels will not
+ * occupy space in the streamed sample data. Per channel chunk there is
+ * one 16bit entity which carries samples that were taken at different
+ * times. The least significant bit was sampled first, higher bits were
+ * sampled later. After all 16bit entities for all enabled channels
+ * were seen, the first enabled channel's next chunk follows.
+ *
+ * Implementor's note: This routine is inspired by convert_sample_data()
+ * in the https://github.com/AlexUg/sigrok implementation. Which in turn
+ * appears to have been derived from the saleae-logic16 sigrok driver.
+ * The code is phrased conservatively to verify the layout as discussed
+ * above, performance was not a priority. Operation was verified with an
+ * LA2016 device. The LA5032 reportedly shares the 16 samples per channel
+ * layout, just round-robins through a potentially larger set of enabled
+ * channels before returning to the first of the channels.
+ */
+static void stream_data(struct sr_dev_inst *sdi,
+ const uint8_t *data_buffer, size_t data_length)
+{
+ struct dev_context *devc;
+ struct stream_state_t *stream;
+ size_t bit_count;
+ const uint8_t *rp;
+ uint32_t sample_value;
+ uint8_t sample_buff[sizeof(sample_value)];
+ size_t bit_idx;
+ uint32_t ch_mask;
+
+ devc = sdi->priv;
+ stream = &devc->stream;
+
+ /* Ignore incoming USB data after complete sample data download. */
+ if (devc->download_finished)
+ return;
+ sr_dbg("Stream mode, got another chunk: %p, length %zu.",
+ data_buffer, data_length);
+
+ /* TODO Add soft trigger support when in stream mode? */
+
+ /* All channels' chunks carry 16 samples for one channel. */
+ bit_count = 16;
+ data_length /= sizeof(uint16_t);
+
+ rp = data_buffer;
+ sample_value = 0;
+ while (data_length--) {
+ /* Get another entity. */
+ sample_value = read_u16le_inc(&rp);
+
+ /* Map the entity's bits to a channel's samples. */
+ ch_mask = stream->channel_masks[stream->channel_index];
+ for (bit_idx = 0; bit_idx < bit_count; bit_idx++) {
+ if (sample_value & (1UL << bit_idx))
+ stream->sample_data[bit_idx] |= ch_mask;
+ }
+
+ /*
+ * Advance to the next channel. Submit a block of
+ * samples when all channels' data was seen.
+ */
+ stream->channel_index++;
+ if (stream->channel_index != stream->enabled_count)
+ continue;
+ for (bit_idx = 0; bit_idx < bit_count; bit_idx++) {
+ sample_value = stream->sample_data[bit_idx];
+ write_u32le(sample_buff, sample_value);
+ feed_queue_logic_submit_one(devc->feed_queue,
+ sample_buff, 1);
+ }
+ sr_sw_limits_update_samples_read(&devc->sw_limits, bit_count);
+ devc->total_samples += bit_count;
+ memset(stream->sample_data, 0, sizeof(stream->sample_data));
+ stream->channel_index = 0;
+ }
+
+ /*
+ * Need we count empty or failed USB transfers? This version
+ * doesn't, assumes that timeouts are perfectly legal because
+ * transfers are started early, and slow samplerates or trigger
+ * support in hardware are plausible causes for empty transfers.
+ *
+ * TODO Maybe a good condition would be (rather large) a timeout
+ * after a previous capture data chunk was seen? So that stalled
+ * streaming gets detected which _is_ an exceptional condition.
+ * We have observed these when "runmode" is set early but bulk
+ * transfers start late with a pause after setting the runmode.
+ */
+ if (sr_sw_limits_check(&devc->sw_limits)) {
+ sr_dbg("Acquisition end reached (sw limits).");
+ devc->download_finished = TRUE;
+ }
+ if (devc->download_finished) {
+ sr_dbg("Stream receive done, flushing session feed queue.");
+ feed_queue_logic_flush(devc->feed_queue);
+ }
+ sr_dbg("Total samples after chunk: %" PRIu64 ".", devc->total_samples);
+}
+