Did you ever get this to work? I would like to do the same thing you
are doing.
--- In "Justin Teems" <> wrote:
>
> --- In "Justin Teems" <jdt141@> wrote:
> >
> > Each command sent to start conversion will cause 2048 samples to
be
> > taken.So if you wanted multiple samples you could just initialize
> > multiple locations to 0xFFFF and then poll for however many you
want.
> > If you send a second command to start conversion before the first
one
> > is complete it will be queued, i.e. 2k samples will be taken, and
then
> > it will start over and take another 2k samples. Only one pending
> > conversion command at a time will be recognized, so a third
command
> > before the first was complete would be discarded.
> >
> > Hi Mike,
> >
> > This doesn't seem to be the case, at least for me. Like Jiri, I'd
like
> > to continuously sample the ADC input for development of a control
> > system. I've been working with the sample code, and haven't had
much
> > luck in getting requests to queue. Here's what I'm up to:
> >
> > //init fpga with mmap
> > //parse channels
> >
> > for(test = 0; test < 3; test++)
> > {
> > for(i=0;i<1024;i++) sram[i] = 0xFFFFFFFF;
> > fprintf(stderr, "Calling twi_select\n");
> > twi_select(AVR_ADDR, WRITE);
> > fprintf(stderr, "Calling twi_write\n");
> > twi_write(chans | 0x40);
> > fprintf(stderr, "Sending stop signal\n");
> > *control = STOP|TWSIEN; // Send stop signal
> >
> > if(verbose) fprintf(stderr,"TEST:Sent Stop signal\n");
> >
> > //usleep(1500000);
> >
> > for(i=0;i<7;i++)
> > {
> > if(raw)
> > {
> > printf("0x%x ", sram[i]);
> > }
> > printf("\n");
> > }
> > }
> >
> > During the first iteration of the test loop, everything is fine
and
> > I'll get valid ADC data. I get a few (3-4) values that aren't
> > 0xFFFFFFFF. On the second iteration, in the twi_select inline
> > function, the status check:
> >
> > if((*status != MT_SLA_ACK) && (*status != MR_SLA_ACK)) { ... }
fails
> > with a code of 0x20. According to the ATmega48/88/168
documentation
> > (pg 225), this means that the slave device is NACKing the last
SLA+W
> > that was transmitted. This only happens when I attempt to queue
the
> > read, as you stated above.
> >
> > Of course, if I add the sleep and wait for the ADC to finish
writing
> > the data, things are fine. I've also tried removing both the stop
> > signal (and sleep), but then no ADC data is ever written to the
memory
> > location.
> >
> > So, is there a way to get a continuous input of ADC bits? Thanks!
> >
>
>
> I should add that adding a small sleep, e.g.,
>
> usleep(10000)
>
> where the 1.5 second sleep is, does not rectify this problem either.
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|