Re: Large ADC Commit

classic Classic list List threaded Threaded
1 message Options
jbsnyder jbsnyder
Reply | Threaded
Open this post in threaded view
|

Re: Large ADC Commit

Ooops... setsmoothing isn't being set on the same channel as acquisition is being done on. One other modification for that:
adc.setsmoothing(0,4)

Thanks again!

-jsnyder

----- "James Snyder" <jbsnyder at fanplastic.org> wrote:

>
> Very neat! Thank you for posting this. It works well on my LM3S6965 board.
>
> Note: There is one minor modification to make it work with the latest svn version of the ADC module (as of today).
> replace this:
> v = adc.sample(0)
>
> with this:
> adc.sample(0)
> v = adc.getsamples(0,1)
>
> With this script there is now an oscilloscope for eLua!
>
>
>
> Best.
>
> -jsnyder
>
> ----- "CF Kwok" <kcfkwok2003 at yahoo.com.hk> wrote:
> >
> >
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 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: (847) 644-2322

> >
> > _______________________________________________
> > 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: (847) 644-2322
> >
> >
Yahoo!???????????????????! ????
> > _______________________________________________ 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/060e8923/attachment-0001.html