Large ADC Commit

[Dado Sutter]

On Mon, Feb 16, 2009 at 21:18, James Snyder <jbsnyder at fanplastic.org> wrote:

> ...........I've also updated adcscope.lua to be faster (using local
> actually sped things up about 3x) and to use the terminal to output results
> rather than the RIT display found on LM3S.
>

Is it still sending results to the RIT OLED display also ?
If not, I'll remove the "Runs on LM3S" note on the doc.

It will be a pitty to lose that cute version though :) and I might keep a
platform dependent example using the disp module or even plotting some
graphs on the RIT display. Afterall, you've called your program an ADC
"scope" :)

Best
Dado

> On Feb 16, 2009, at 11:15 AM, James Snyder wrote:
>
> Hi -
>
> Thanks for the comments :-)
>
> ----- "Bogdan Marinescu" <bogdan.marinescu at gmail.com> wrote:
> > Hi,
> >
> > I still have to look at the code carefully and figure out what exactly
> you did there :), but for now a few simple observations:
> >
> > 1. it occured to me that since buf_init already expects a logarithmic
> parameter, it probably makes sense to make it expect two logarithmic
> parameters, so instead of this:
> >
> > int buf_set( unsigned resid, unsigned resnum, u8 logsize, size_t dsize )
> >
> > we'll have this:
> >
> > int buf_set( unsigned resid, unsigned resnum, u8 logsize, size_t *log*dsize
> )
>
> I was thinking about doing this, I'll make the change.
>
> >
> > 2. Since you did this:
> >
> >   pbuf->logsize = logsize + ( pbuf->logdsize );
> >
> > in buf_set, you probably need to modify this:
> >
> > #define BUF_MOD_INCR( p, m ) p->m = ( p->m + ( ( u16 )1 << p->logdsize )
> ) & ( ( ( u16 )1 << ( p->logsize + p->logdsize) ) - 1 )
> >
> > (because you add logdsize to logsize once again, and I don't think this
> is right).
>
> Ooops.  That would likely be the cause of some of the random crashes I was
> seeing :-)  (currently worked around somewhat)
>
> >
> > 3. The data size of an ADC is not always 16 bits, so we should add
> another (probably also logarithmic) parameter to elua_adc/adc_init_state.
>
> True..  Are you anticipating use of higher or lower bit depth?  There are
> certainly lower and higher ones out there, though I've not seen >16-bit ones
> built-in to uCs.  If we want to accomodate larger sizes, the return types
> for some things will need adjustment, perhaps by defining a type that
> reflects the maximum size that will be returned?  This type would be
> selected at compile time depending on the maximum bits-per-sample one might
> want to work with?
>
> Something like:
>
> #if MAX_ADC_BIT_RESOLUTION <= 8
> typedef u8 t_adc_data
> #elif MAX_ADC_BIT_RESOLUTION <= 16
> typedef u16 t_adc_data
> #elif MAX_ADC_BIT_RESOLUTION <= 32
> typedef u32 t_adc_data
> #else
> #error "No matching type for MAX_ADC_BIT_RESOLUTION, check your selected
> bit depth or add larger type"
> #endif
>
> >
> > 4. As for the change you proposed, as I said I still have to figure out
> what exactly your code does :), but for now it makes sense. I'll get back to
> you with more information. Fortunately we don't really have a pre-existing
> paradigm, we just have some proposals, so we can change everything we don't
> like.
>
> OK, sounds good.  The one midly complicated thing to make this approach
> work with dynamic buffer sizing is to have buf_set handle increasing buffer
> size gracefully.  I think the main case to handle is when wptr < rptr.  i.e.
> the write pointer has wrapped around to the beginning of the buffer, but the
> read ptr has not.  If one just adds space in this case, the read pointer
> will start going into as yet unwritten space thinking it is picking up valid
> data.
>
> One way to handle this would be copying data so that the freshly resized
> buffer is coherent again.  Another would be to somehow grow the buffer in
> the space between the rptr and the wptr.  This, however, without moving data
> around, even if it were possible, would result in fragmentation.
>
> If I were to just do an implementation without further research it might
> look like this:
>
> 1. If wptr > rptr, just realloc.
> 2. If rptr > wptr, move all of the elements between buf (array start
> pointer) and wptr to space after the wrapping point of the original,
> smaller, buffer.
>
> If we could also grow the buffer at the starting end, maybe we could decide
> whether adding at the start or the end would result in more copying.
>
> I'm not as concerned about algorithms for downsizing the buffer to conserve
> space.  I think instead of dealing with copying in this case, the downsizing
> might just be done whenever the buffer runs dry, and if no new interesting
> requests are pending, drop down to some reasonable default size.
>
> Any thoughts or ideas would certainly be appreciated.
>
> >
> > Best,
> > Bogdan
> >
> > On Mon, Feb 16, 2009 at 3:12 AM, James Snyder <jbsnyder at fanplastic.org>
> wrote:
> > > Hi -
> > >
> > > I've dropped in another large ADC commit.  I've mentioned most of what
> was done in the commit message, but here's a rundown:
> > >
> > > - When samples are available from ADC, they're initially copied into an
> elua buf.
> > > - buf length is adjusted according to number of expected samples coming
> in (when burst is requested, buf is resized to accomodate the number of
> burst samples, size is dropped back down when single samples are requested)
> > > - if smoothing is enabled, and has no samples, smoothing buffer (not an
> elua buf) is filled first to warm up the filter, then samples begin to
> accumulate in the main buffer.
> > > - a flush function has been added to manually clear out both smoothing
> and primary buffers in case one doesn't want old samples or old smoothing
> data being used for future measurements
> > >
> > > Also, I forgot to mention one thing in the commit message:  As per a
> discussion with Bogdan, the type checking on buf_write and buf_read have
> been pulled out.
> > >
> > > One adjustment that I'd like to consider before the 0.6 freeze is to
> remove the option for blocking and non-blocking as it applies to sample and
> burst functions (used to initiate sampling) and to instead make these always
> non-blocking, and never have them return any samples (only errors, if
> needed).  A separate function, say getsamples would pull in data collected
> using either mode.  Right now, if one uses non-blocking mode, samples will
> always be returned for the last time you ran sample or burst.  This means
> that if you want to get the data already requested, you also have to always
> request new samples, even if you don't want them.
> > >
> > > I should be able to make this change with minimal code changes, but I
> haven't done it yet because it changes the pre-existing paradigm, and I
> wanted to get these changes in sooner rather than later :-)
> > >
> > > I think it might just take me another hour or so to get adjustments
> along those lines working.  There wouldn't be as long of a delay as this ADC
> commit.
> > >
> > > Suggestions/comments are welcome :-)
> > >
> > > -jsnyder
> > > _______________________________________________
> > > Elua-dev mailing list
> > > Elua-dev at lists.berlios.de
> > > https://lists.berlios.de/mailman/listinfo/elua-dev
> > >
> >
> >
> > _______________________________________________ Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: [phone]
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/110c530d/attachment.html 

[jbsnyder]

For this version I've stripped that out, with the idea that when ADC  
exists on other platforms this script should work on those platforms  
too. Adding it back would be easy.  It could probably optionally do  
one mode or the other depending on available hardware.

What I wanted to do originally with that script was to have it  
actually draw waveforms on the RIT display, but I've not gotten around  
to figuring out how to write something that would do that  
efficiently :-)  Maybe I should look at the raw2rit code to figure  
that out.  It would be quite neat to be able to use eLua as a  
rudimentary oscilloscope :-)

-jsnyder

On Feb 16, 2009, at 6:36 PM, Dado Sutter wrote:

>
>
> On Mon, Feb 16, 2009 at 21:18, James Snyder  
> <jbsnyder at fanplastic.org> wrote:
> ...........
> I've also updated adcscope.lua to be faster (using local actually  
> sped things up about 3x) and to use the terminal to output results  
> rather than the RIT display found on LM3S.
>
> Is it still sending results to the RIT OLED display also ?
> If not, I'll remove the "Runs on LM3S" note on the doc.
>
> It will be a pitty to lose that cute version though :) and I might  
> keep a platform dependent example using the disp module or even  
> plotting some graphs on the RIT display. Afterall, you've called  
> your program an ADC "scope" :)
>
> Best
> Dado
>
>
>
>
>
>
> On Feb 16, 2009, at 11:15 AM, James Snyder wrote:
>
>> Hi -
>>
>> Thanks for the comments :-)
>>
>> ----- "Bogdan Marinescu" <bogdan.marinescu at gmail.com> wrote:
>> > Hi,
>> >
>> > I still have to look at the code carefully and figure out what  
>> exactly you did there :), but for now a few simple observations:
>> >
>> > 1. it occured to me that since buf_init already expects a  
>> logarithmic parameter, it probably makes sense to make it expect  
>> two logarithmic parameters, so instead of this:
>> >
>> > int buf_set( unsigned resid, unsigned resnum, u8 logsize, size_t  
>> dsize )
>> >
>> > we'll have this:
>> >
>> > int buf_set( unsigned resid, unsigned resnum, u8 logsize, size_t  
>> logdsize )
>>
>> I was thinking about doing this, I'll make the change.
>>
>> >
>> > 2. Since you did this:
>> >
>> >   pbuf->logsize = logsize + ( pbuf->logdsize );
>> >
>> > in buf_set, you probably need to modify this:
>> >
>> > #define BUF_MOD_INCR( p, m ) p->m = ( p->m + ( ( u16 )1 << p-
>> >logdsize ) ) & ( ( ( u16 )1 << ( p->logsize + p->logdsize) ) - 1 )
>> >
>> > (because you add logdsize to logsize once again, and I don't  
>> think this is right).
>>
>> Ooops.  That would likely be the cause of some of the random  
>> crashes I was seeing :-)  (currently worked around somewhat)
>>
>> >
>> > 3. The data size of an ADC is not always 16 bits, so we should  
>> add another (probably also logarithmic) parameter to elua_adc/
>> adc_init_state.
>>
>> True..  Are you anticipating use of higher or lower bit depth?  
>> There are certainly lower and higher ones out there, though I've  
>> not seen >16-bit ones built-in to uCs.  If we want to accomodate  
>> larger sizes, the return types for some things will need  
>> adjustment, perhaps by defining a type that reflects the maximum  
>> size that will be returned?  This type would be selected at compile  
>> time depending on the maximum bits-per-sample one might want to  
>> work with?
>>
>> Something like:
>>
>> #if MAX_ADC_BIT_RESOLUTION <= 8
>> typedef u8 t_adc_data
>> #elif MAX_ADC_BIT_RESOLUTION <= 16
>> typedef u16 t_adc_data
>> #elif MAX_ADC_BIT_RESOLUTION <= 32
>> typedef u32 t_adc_data
>> #else
>> #error "No matching type for MAX_ADC_BIT_RESOLUTION, check your  
>> selected bit depth or add larger type"
>> #endif
>>
>> >
>> > 4. As for the change you proposed, as I said I still have to  
>> figure out what exactly your code does :), but for now it makes  
>> sense. I'll get back to you with more information. Fortunately we  
>> don't really have a pre-existing paradigm, we just have some  
>> proposals, so we can change everything we don't like.
>>
>> OK, sounds good.  The one midly complicated thing to make this  
>> approach work with dynamic buffer sizing is to have buf_set handle  
>> increasing buffer size gracefully.  I think the main case to handle  
>> is when wptr < rptr.  i.e. the write pointer has wrapped around to  
>> the beginning of the buffer, but the read ptr has not.  If one just  
>> adds space in this case, the read pointer will start going into as  
>> yet unwritten space thinking it is picking up valid data.
>>
>> One way to handle this would be copying data so that the freshly  
>> resized buffer is coherent again.  Another would be to somehow grow  
>> the buffer in the space between the rptr and the wptr.  This,  
>> however, without moving data around, even if it were possible,  
>> would result in fragmentation.
>>
>> If I were to just do an implementation without further research it  
>> might look like this:
>>
>> 1. If wptr > rptr, just realloc.
>> 2. If rptr > wptr, move all of the elements between buf (array  
>> start pointer) and wptr to space after the wrapping point of the  
>> original, smaller, buffer.
>>
>> If we could also grow the buffer at the starting end, maybe we  
>> could decide whether adding at the start or the end would result in  
>> more copying.
>>
>> I'm not as concerned about algorithms for downsizing the buffer to  
>> conserve space.  I think instead of dealing with copying in this  
>> case, the downsizing might just be done whenever the buffer runs  
>> dry, and if no new interesting requests are pending, drop down to  
>> some reasonable default size.
>>
>> Any thoughts or ideas would certainly be appreciated.
>>
>> >
>> > Best,
>> > Bogdan
>> >
>> > On Mon, Feb 16, 2009 at 3:12 AM, James Snyder <jbsnyder at fanplastic.org
>> > wrote:
>> > > Hi -
>> > >
>> > > I've dropped in another large ADC commit.  I've mentioned most  
>> of what was done in the commit message, but here's a rundown:
>> > >
>> > > - When samples are available from ADC, they're initially copied  
>> into an elua buf.
>> > > - buf length is adjusted according to number of expected  
>> samples coming in (when burst is requested, buf is resized to  
>> accomodate the number of burst samples, size is dropped back down  
>> when single samples are requested)
>> > > - if smoothing is enabled, and has no samples, smoothing buffer  
>> (not an elua buf) is filled first to warm up the filter, then  
>> samples begin to accumulate in the main buffer.
>> > > - a flush function has been added to manually clear out both  
>> smoothing and primary buffers in case one doesn't want old samples  
>> or old smoothing data being used for future measurements
>> > >
>> > > Also, I forgot to mention one thing in the commit message:  As  
>> per a discussion with Bogdan, the type checking on buf_write and  
>> buf_read have been pulled out.
>> > >
>> > > One adjustment that I'd like to consider before the 0.6 freeze  
>> is to remove the option for blocking and non-blocking as it applies  
>> to sample and burst functions (used to initiate sampling) and to  
>> instead make these always non-blocking, and never have them return  
>> any samples (only errors, if needed).  A separate function, say  
>> getsamples would pull in data collected using either mode.  Right  
>> now, if one uses non-blocking mode, samples will always be returned  
>> for the last time you ran sample or burst.  This means that if you  
>> want to get the data already requested, you also have to always  
>> request new samples, even if you don't want them.
>> > >
>> > > I should be able to make this change with minimal code changes,  
>> but I haven't done it yet because it changes the pre-existing  
>> paradigm, and I wanted to get these changes in sooner rather than  
>> later :-)
>> > >
>> > > I think it might just take me another hour or so to get  
>> adjustments along those lines working.  There wouldn't be as long  
>> of a delay as this ADC commit.
>> > >
>> > > Suggestions/comments are welcome :-)
>> > >
>> > > -jsnyder
>> > > _______________________________________________
>> > > Elua-dev mailing list
>> > > Elua-dev at lists.berlios.de
>> > > https://lists.berlios.de/mailman/listinfo/elua-dev
>> > >
>> >
>> >
>> > _______________________________________________ Elua-dev mailing  
>> list Elua-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/elua-dev
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: [phone]
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: [phone]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/73a53111/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/73a53111/attachment-0001.pgp 

[CF Kwok]

Hi

I have made following script to show wave form on the LM3S8962 OLED.
It can be tested in elua:
dofile('/rom/oscscope.lua')

test(100000)  -- for 0.1 s sample interval
 
-CF

the script:-------------------------------------------------------------------
-- oscscope.lua
require("LM3S")
disp.init(1000000)
disp.clear()
adc.setsmoothing(1,4)

--adc_base=ADC.ADC_BASE
img_horz=string.rep(string.char(0x40),64)
img_vert=string.rep(string.char(0x40)..string.char(0x00),40)
function frame()
  disp.clear()
  -- horz
  for i=10,80,10 do disp.imagedraw(img_horz,0,i,128,1) end
  -- vert
  for i=10,120,10 do disp.imagedraw(img_vert,i,0,2,80) end
end


function test(interval)
  local img
  frame()
  tmr.start(0)
  i=0
  j=0
 odd=1
 pv=0
 while 1 do
   t1=tmr.read(0)
   v = adc.sample(0)
   if i>127 then
     frame()
     i=0
   end
   v1=math.floor(v * 80 / 1024 +0.5)
   if odd==1 then
      img=string.char(0xf0)
      disp.imagedraw(img,j,80-v1,2,1)
      odd=0
      pv=v1
   else
      if v1==pv then
        img=string.char(0xff)
      else
        img=string.char(0x0f)
      end
      disp.imagedraw(img,j,80-v1,2,1)
      odd=1
      j=j+2
    end
    t2=tmr.read(0)
    diff=tmr.diff(0,t2,t1)
    print(v,80-v1,diff)
    while diff < interval do
      t2=tmr.read(0)
      diff=tmr.diff(0,t2,t1)
    end
    tmr.start(0)
    i=i+1
  end
end



________________________________
???? James Snyder <jbsnyder at fanplastic.org>
??? eLua Users and Development List <elua-dev at lists.berlios.de>
????? 2009 ? 2? 17 ? ??? ?? 8:45:51
??? Re: [eLua-dev] Large ADC Commit

For this version I've stripped that out, with the idea that when ADC exists on other platforms this script should work on those platforms too. Adding it back would be easy.  It could probably optionally do one mode or the other depending on available hardware.

What I wanted to do originally with that script was to have it actually draw waveforms on the RIT display, but I've not gotten around to figuring out how to write something that would do that efficiently :-)  Maybe I should look at the raw2rit code to figure that out.  It would be quite neat to be able to use eLua as a rudimentary oscilloscope :-)

-jsnyder


On Feb 16, 2009, at 6:36 PM, Dado Sutter wrote:




On Mon, Feb 16, 2009 at 21:18, James Snyder <jbsnyder at fanplastic.org> wrote:

...........
I've also updated adcscope.lua to be faster (using local actually sped things up about 3x) and to use the terminal to output results rather than the RIT display found on LM3S.

Is it still sending results to the RIT OLED display also ?
If not, I'll remove the "Runs on LM3S" note on the doc.

It will be a pitty to lose that cute version though :) and I might keep a platform dependent example using the disp module or even plotting some graphs on the RIT display. Afterall, you've called your program an ADC "scope" :)

Best
Dado








On Feb 16, 2009, at 11:15 AM, James Snyder wrote:

Hi -

Thanks for the comments :-)

----- "Bogdan Marinescu" <bogdan.marinescu at gmail.com> wrote:

> Hi,
>
> I still have to look at the code carefully and figure out what exactly you did there :), but for now a few simple observations:
>
> 1. it occured to me that since buf_init already expects a logarithmic parameter, it probably makes sense to make it expect two logarithmic parameters, so instead of this:
>
> int buf_set( unsigned resid, unsigned resnum, u8 logsize, size_t dsize )
>
> we'll have this:
>
> int buf_set( unsigned resid, unsigned resnum, u8 logsize, size_t logdsize )

I was thinking about doing this, I'll make the change.

>
> 2. Since you did this:
>
>   pbuf->logsize = logsize + ( pbuf->logdsize );
>
> in buf_set, you probably need to modify this:
>
> #define BUF_MOD_INCR( p, m ) p->m = ( p->m + ( ( u16 )1 << p->logdsize ) ) & ( ( ( u16 )1 << ( p->logsize + p->logdsize) ) - 1 )
>
> (because you add logdsize to logsize once again, and I don't think this is right).

Ooops.  That would likely be the cause of some of the random crashes I was seeing :-)  (currently worked around somewhat)

>
> 3. The data size of an ADC is not always 16 bits, so we should add another (probably also logarithmic) parameter to elua_adc/adc_init_state.

True..  Are you anticipating use of higher or lower bit depth?  There are certainly lower and higher ones out there, though I've not seen >16-bit ones built-in to uCs.  If we want to accomodate larger sizes, the return types for some things will need adjustment, perhaps by defining a type that reflects the maximum size that will be returned?  This type would be selected at compile time depending on the maximum bits-per-sample one might want to work with?

Something like:

#if MAX_ADC_BIT_RESOLUTION <= 8
typedef u8 t_adc_data
#elif MAX_ADC_BIT_RESOLUTION <= 16
typedef u16 t_adc_data
#elif MAX_ADC_BIT_RESOLUTION <= 32
typedef u32 t_adc_data
#else
#error "No matching type for MAX_ADC_BIT_RESOLUTION, check your selected bit depth or add larger type"
#endif

>
> 4. As for the change you proposed, as I said I still have to figure out what exactly your code does :), but for now it makes sense. I'll get back to you with more information. Fortunately we don't really have a pre-existing paradigm, we just have some proposals, so we can change everything we don't like.

OK, sounds good.  The one midly complicated thing to make this approach work with dynamic buffer sizing is to have buf_set handle increasing buffer size gracefully.  I think the main case to handle is when wptr < rptr.  i.e. the write pointer has wrapped around to the beginning of the buffer, but the read ptr has not.  If one just adds space in this case, the read pointer will start going into as yet unwritten space thinking it is picking up valid data.

One way to handle this would be copying data so that the freshly resized buffer is coherent again.  Another would be to somehow grow the buffer in the space between the rptr and the wptr.  This, however, without moving data around, even if it were possible, would result in fragmentation.

If I were to just do an implementation without further research it might look like this:

1. If wptr > rptr, just realloc.
2. If rptr > wptr, move all of the elements between buf (array start pointer) and wptr to space after the wrapping point of the original, smaller, buffer.

If we could also grow the buffer at the starting end, maybe we could decide whether adding at the start or the end would result in more copying.

I'm not as concerned about algorithms for downsizing the buffer to conserve space.  I think instead of dealing with copying in this case, the downsizing might just be done whenever the buffer runs dry, and if no new interesting requests are pending, drop down to some reasonable default size.

Any thoughts or ideas would certainly be appreciated.

>
> Best,
> Bogdan
>
> On Mon, Feb 16, 2009 at 3:12 AM, James Snyder <jbsnyder at fanplastic.org> wrote:
> > Hi -
> >
> > I've dropped in another large ADC commit.  I've mentioned most of what was done in the commit message, but here's a rundown:
> >
> > - When samples are available from ADC, they're initially copied into an elua buf.
> > - buf length is adjusted according to number of expected samples coming in (when burst is requested, buf is resized to accomodate the number of burst samples, size is dropped back down when single samples are requested)
> > - if smoothing is enabled, and has no samples, smoothing buffer (not an elua buf) is filled first to warm up the filter, then samples begin to accumulate in the main buffer.
> > - a flush function has been added to manually clear out both smoothing and primary buffers in case one doesn't want old samples or old smoothing data being used for future measurements
> >
> > Also, I forgot to mention one thing in the commit message:  As per a discussion with Bogdan, the type checking on buf_write and buf_read have been pulled out.
> >
> > One adjustment that I'd like to consider before the 0.6 freeze is to remove the option for blocking and non-blocking as it applies to sample and burst functions (used to initiate sampling) and to instead make these always non-blocking, and never have them return any samples (only errors, if needed).  A separate function, say getsamples would pull in data collected using either mode.  Right now, if one uses non-blocking mode, samples will always be returned for the last time you ran sample or burst.  This means that if you want to get the data already requested, you also have to always request new samples, even if you don't want them.
> >
> > I should be able to make this change with minimal code changes, but I haven't done it yet because it changes the pre-existing paradigm, and I wanted to get these changes in sooner rather than later :-)
> >
> > I think it might just take me another hour or so to get adjustments along those lines working.  There wouldn't be as long of a delay as this ADC commit.
> >
> > Suggestions/comments are welcome :-)
> >
> > -jsnyder
> > _______________________________________________
> > Elua-dev mailing list
> > Elua-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/elua-dev
> >
>
>
> _______________________________________________ Elua-dev mailing list Elua-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
Elua-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: [phone]

_______________________________________________
Elua-dev mailing list
Elua-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/elua-dev


_______________________________________________
Elua-dev mailing list
Elua-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/elua-dev


--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: [phone]



      Yahoo!???????????????????! ??? http://hk.promo.yahoo.com/security/ ????!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/952ab1ce/attachment-0001.html