Thanks..

The error in my program was that in the same loop, I was initiating a
conversion, waiting for the conversion to finish, saving and
reinitiate a new conversion...

I broke it to two loops like..

while ( i < 25000 ) {

        do {
                bit_7 =3D *base & 0x80; //check if conversion is finished
        } while (bit_7 =3D=3D 0);


        iptr[i] =3D *RESULT_REG; //save to iptr

        *base =3D 0x00; //reinitiate a new conversion

        i++;
        }


doing like that I got ~38Ksps...
of course this loads the cpu and the jitter is high

I will try to write a driver for the adc board

christos

On 12/4/05, Werner Backes <werner@bit-1.de> wrote:
> Hi Christos,
>
> I'm not shure if usleep gives such a high resolution
> as 10us. You should probably test this with an empty
> loop that contains only the usleep(10) call.
>
> Christos Eleftheriadis wrote:
> > The SBC runs a kernel compiled from CVS some weeks ago.
> > Do I need to tweak the kernel files in some point ?
>
> No, I think it's pretty unlikely that you have to tweak
> something here.
>
> > Or this is the higher speed that a userland program can go ?
>
> No, there is no such thing as a "userland speed limit" ;). Of
> course, userland programs can be slow down by other programs
> that are running, but on an idle system, you should not have
> a problem with this.
>
> > Should I try to write a driver to achieve the speed I want ? 50Ksps
> > would be OK for me..
>
> Maybe you need to do this, but not for speed but timing accuracy.
> If you don't care much about the exact timing, you should be fine
> with a userland program.
>
> > The manufacture company says that 100Ksps are feasible...and the ADC
> > chip can do 125Ksps
>
> Don't you have to tell the ADC the sampling speed? Or does it
> automatically starts a new conversion on every read?
>
> greetings
>             Werner
>