Re: Question about digital i/o cmd buffer data format in new driver

On Monday 24 January 2005 01:15 pm, Ian Abbott wrote:
> Hi David, Frank, et al.,
>
> I'm working on a new driver that supports streaming aquisition on a
> digital I/O subdevice with 24 channels (physically, its a 8255, but I'm
> not using the generic 8255 driver for various reasons).
>
> There are two ways I could treat the buffered data and I'd like some
> opinions on which is the best approach.  In both cases, cmd->convert_src
> will be forced to TRIG_NOW.
>
> The first way is store the scan as a single lsampl_t value with all
> channels' values stored at corresponding bit positions within the
> lsampl_t value.  So the acquired value for channel 0 is always stored at
> bit position 0 in the lsampl_t and the acquired value for channel 23 is
> always stored at bit position 23.  If I use this method, I'll set the
> SDF_LSAMPL flag in the subdevice.
>
> The second way is to pack the channel data into the minimum required
> number of bytes (rounding up to a whole number of bytes), storing the
> channels in the order they appear in the command's channel list.  So if
> the channel list contains 9 channels, the scan will use two bytes; bit 0
> of byte 0 will contain the data for the first channel in the list; bit 1
> will contain the data for the second channel in the list, etc.  If I use
> this method, I'll set the SDF_PACKED flag in the subdevice (nothing uses
> that yet!).

You should do it the second way, except rounding up to a multiple of 
sizeof(sampl_t) or sizeof(lsampl_t) depending on your use of SDF_LSAMPL (I 
fixed bytes_per_scan() to do this).  You don't need a new SDF_PACKED flag.  
The ni_pcidio driver could be thought of as a special case where only 
chanlists starting at zero and incrementing are supported (although the 
driver doesn't actually enforce that).

-- 
Frank