Dear All,

 

I'm sorry for the trivial question but I've tried to do a google on udelay but couldn't shed any light. I could not find examples on how the udelay had been done in the gumstix code. I’m really a newbie to Linux and programming.

 

I've got the following error when I included the udelay sub-function in the example code and replaced "usleep" with "udelay" as advised. I've also tried to include <time.h> and <delay.h> and it still couldn't work. I realised that the function "nanodelay" also implemented "while(timercmp(&current_time, &end_time, <))".

 

spi1867f.c:160: error: conflicting types for 'udelay'

spi1867f.c:140: error: previous implicit declaration of 'udelay' was here

spi1867f.c: In function `udelay':

spi1867f.c:178: error: syntax error before '<' token

 

 

Can you tell me what is the bit that I've been missing?

 

Thanks.

 

Peck

 

 

-----Original Message-----
From: gumstix-users-bounces@lists.sourceforge.net [mailto:gumstix-users-bounces@lists.sourceforge.net] On Behalf Of Grahame
Jordan
Sent:
05 February 2008 23:48
To: General mailing list for gumstix users.
Subject: Re: [Gumstix-users] SPI C-code example

 

 

Apparently the usleeps/nanosleeps will be fixed in a later kernel for

ARM.  I believe that in 2.6.21 that it is OK for i386.

 

For the mean time I am using:

 

/****************************************************************************/

// nanosleep and usleep are currently useless unless it is greater than

20 msec

static void udelay(int usecs)

{

    struct timeval delay;

    struct timeval start_time;

    struct timeval current_time;

    struct timeval end_time;

 

    if(usecs < 20000)

    {

        // Time to run gettimeofday() ~5 usecs

        delay.tv_sec = 0;

        delay.tv_usec = usecs;

        gettimeofday(&start_time, NULL);

        timeradd(&start_time, &delay, &end_time);

 

        do

        {

            gettimeofday(&current_time, NULL);

        }

        while(timercmp(&current_time, &end_time, <));

    }

    else

    {

        usleep(usecs);

    }

 

}

 

Cheers

 

Grahame

 

 

 

Steve Sakoman wrote:

> Peck,

>

> On my schematic the vref comes from my input amplifier section and is

> approximately 2.048V which is the midpoint of the adc's 0-4.096V

> range.

>

> Dave is probably right about the usleeps.  You need a short delay

> there to meet the acd timing specs.  You could probably just use a

> short for loop to delay a few usec (I forget what the spec is offhand)

>

> Steve

>

> On Feb 5, 2008 12:02 PM, Peck Hui Koh <pkoh@medphys.ucl.ac.uk> wrote:

>  

>>

>>

>> Hi Steve and Dave,

>>

>>

>>

>> Thanks for all the great information, including the schematic and the

>> modified codes for the SPI. I've now managed to get the gumstix to talk to

>> the ADC and it worked beautifully. Just one quick question: In your

>> schematic, you connected Pin 9 (RefComp) to "Vref". Are you referring to the

>> Pin 10 as Vref in this case? I did not connect RefComp to Vref and merely

>> tied RefComp to ground. The ADC seems to be reading the values correctly. Am

>> I correct in doing that?

>>

>>

>>

>> Knowing that everything is working fine, I'm now trying to measure the

>> maximum speed at which it can sample. The specs for LTC1867 (ADC) indicate

>> that it can sample up to 200 ksps. However I could only measure 100 sps for

>> one channel and 25 sps for two channels. I was really surprised by these

>> miserable outputs and knowing that the gumstix and ADC are more than capable

>> of processing at higher sampling rate, I would suspect the problem lies with

>> the coding. I've slightly modified the main SPI example program (as below)

>> and I need your advice.

>>

>>

>>

>> Can anyone advise me if there is anything I can do to improve the sampling

>> rate? I'll need to collect samples at 10ksps using two of the channels

>> measured in sequence (i.e. CH1-CH2-CH1-CH2-CH1..).

>>

>>

>>

>> Any suggestions will be greatly appreciated.

>>

>>

>>

>> Thanks.

>>

>>

>>

>> Peck

>>

>>

>>

>>

>>

>>

>>

>> //**************************MAIN PROGRAM*********************************

>>

>>

>> int main(int argc, char *argv[])

>>

>> {

>>

>>       int i,j,ch;

>>

>>       long data[100000][4];

>>

>>

>>       int ClockDivider = 0;

>>

>>       int delay = 5;

>>

>>

>>

>>       int channel[] = {0x8400,

>>

>>                        0xc400};

>>

>>

>>

>>

>>       int result = SPIinit(ClockDivider); // Initialize NSSP / SPI Port

>>

>>

>>

>>       int count = 100000;

>>

>>       time_t      prevTime;

>>

>>       time_t      endTime;

>>

>>

>>

>>       prevTime = time( NULL );

>>

>>       while ( time( NULL ) == prevTime )

>>

>>       {;}

>>

>>       endTime = prevTime + 10;

>>

>>

>>

>>       i=0;

>>

>>

>>

>>       while ( (i<count) && (time( NULL ) <= endTime) ) {

>>

>>             for (ch=0; ch < 2; ch++) {

>>

>>             SPI_TxRx(channel[ch]); // request channel i data, discard result

>>

>>             usleep(delay);

>>

>>

>>

>>             data[i][ch]=SPI_TxRx(channel[ch]);

>>

>>             usleep(delay);

>>

>>             }

>>

>>             i++;

>>

>>       }

>>

>>

>>

>>       for (j=0; j < i; j++) {

>>

>>             printf("%ld\t%ld\t\n", data[j][0], data[j][1]);

>>

>>       }

>>

>>       printf("count rate:%d\n",i);

>>

>>

>>

>>

>>       fflush(stdout);

>>

>>       close(gpio_fd);

>>

>>       return 1;

>>

>> }

>>

>> //**************************************************************************

>>

>>

>>

>> -----Original Message-----

>>  From: gumstix-users-bounces@lists.sourceforge.net

>> [mailto:gumstix-users-bounces@lists.sourceforge.net] On Behalf Of Steve

>> Sakoman

>>  Sent: 28 January 2008 20:10

>>

>>

>>  To: General mailing list for gumstix users.

>>  Subject: Re: [Gumstix-users] SPI C-code example

>>

>>

>>

>>

>>

>> Peck,

>>

>>

>>

>> I've attached a schematic snippet that includes the ADC connection to

>>

>> a connex/basix 60 pin header.  R11 and 12 are a resistive divider for

>>

>> level shifting the ADC serial output (which is a 5V signal).

>>

>>

>>

>> The code works exactly as I posted it -- nothing else required.

>>

>>

>>

>> Really it is all pretty simple!

>>

>>

>>

>> Steve

>>

>>

>>

>>

>>

>>

>>

>> On Jan 28, 2008 11:54 AM, Peck Hui Koh <pkoh@medphys.ucl.ac.uk> wrote:

>>

>>    

>>> Hi Steve and Dave,

>>>      

>>> Thanks for the advice. Even after replacing the Frame signal with the ADC

>>>      

>>> /CS input, I just couldn't get the ADC to work. The *Ref_FIFO just

>>>      

>> returned

>>

>>    

>>> int 0 after each sample.

>>>      

>>> To simplify the troubleshooting procedure (I've got no idea if the problem

>>>      

>>> is due to hardware connection or/and software i.e. addressing the ADC

>>>      

>>> correctly), I've now placed order for free samples of the LTC1867. Anyway

>>>      

>> I

>>

>>    

>>> would need to implement faster sampling ADC eventually.

>>>      

>>> Just to re-confirm with you a couple of things, although the addressing

>>>      

>> part

>>

>>    

>>> looks pretty straightforward on this ADC: Based on the example code which

>>>      

>>> you shared with me for LTC1867, there is no need to initialise the various

>>>      

>>> registers (eg communication, setup, clock, data) for the LTC1867. I just

>>>      

>>> need to assign the first word that is being sent out to indicate the

>>>      

>> channel

>>

>>    

>>> number to sample, single/diff, uni/bipolar and sleep mode and SPI will

>>>      

>> pick

>>

>>    

>>> up the sample from the ADC data register for each channel. In your

>>>      

>> example,

>>

>>    

>>> you had quoted the eight sequential channels as {0x8400, 0xc400, 0x9400,

>>>      

>>> 0xd400, 0xa400, 0xe400, 0xb400, 0xf400}. And on the hardware, your direct

>>>      

>>> connection to the gumstix is as what you have illustrated in your earlier

>>>      

>>> thread. No additional components needed on the circuitry, and no need to

>>>      

>> run

>>

>>    

>>> any other SPI program/driver in parallel.

>>>      

>>> I'll try this out as soon as I've got the free samples (I'll need to find

>>>      

>> a

>>

>>    

>>> SSOP to DIP package adapter as well). Any advice for good soldering on

>>>      

>> these

>>

>>    

>>> tiny pins?

>>>      

>>> I'll update you once I managed to sort it out. Thanks.

>>>      

>>> Peck

>>>      

>>> -----Original Message-----

>>>      

>>> From: gumstix-users-bounces@lists.sourceforge.net

>>>      

>>> [mailto:gumstix-users-bounces@lists.sourceforge.net] On Behalf Of Steve

>>>      

>>> Sakoman

>>>      

>>> Sent: 28 January 2008 15:47

>>>      

>>> To: General mailing list for gumstix users.

>>>      

>>> Subject: Re: [Gumstix-users] SPI C-code example

>>>      

>>>> Do you mean you actually connect the Frame signal (on the gumstix) and

>>>>        

>> CS

>>

>>    

>>>> together? I've tried to fix the CS signal to low throughout the

>>>>        

>>> measurement

>>>      

>>>> because I've only got one chip on the SPI bus. Is that what you do for

>>>>        

>> the

>>

>>    

>>>> LTC1867 to work?

>>>>        

>>> Yes, I connect it like so:

>>>      

>>> ADC          Gumstix

>>>      

>>> SDI <---NSSP_TXD

>>>      

>>> SDO--->NSSP_RXD

>>>      

>>> SCK<---NSSP_CLK

>>>      

>>> /CS<---NSSP_FRAME

>>>      

>>> And Dave, yes of course there is a common ground :-)

>>>      

>>> I have no idea whether this connection scheme will work for your ADC

>>>      

>>> -- you should study the data sheet.  For the LTC1867 the CS serves

>>>      

>>> three functions: selecting the chip, framing the serial transfer, and

>>>      

>>> initiating the next sample/convert operation.  I would imagine that

>>>      

>>> your ADC functions in a simialr manner, but you should verify by

>>>      

>>> reading the data sheet.  I don't see how your chip could possibly work

>>>      

>>> with CS grounded, because there is no facility for framing the serial

>>>      

>>> transfers.

>>>      

>>> Steve

>>>      

>>> On Jan 28, 2008 6:40 AM, Peck Hui Koh <pkoh@medphys.ucl.ac.uk> wrote:

>>>      

>>>> Hi Steve,

>>>>        

>>>> Do you mean you actually connect the Frame signal (on the gumstix) and

>>>>        

>> CS

>>

>>    

>>>> together? I've tried to fix the CS signal to low throughout the

>>>>        

>>> measurement

>>>      

>>>> because I've only got one chip on the SPI bus. Is that what you do for

>>>>        

>> the

>>

>>    

>>>> LTC1867 to work?

>>>>        

>>>> Can I ask if you mind sharing with me your schematic (only on the

>>>>        

>>>> gumstix-ADC) as I'm really interested to know how you are able to read

>>>>        

>> the

>>

>>    

>>>> samples by using the same program, and it will point to us if it's a

>>>>        

>>>> hardware problem.

>>>>        

>>>> Your help will be greatly appreciated. Thanks!

>>>>        

>>>> Peck

>>>>        

>>>> -----Original Message-----

>>>>        

>>>> From: gumstix-users-bounces@lists.sourceforge.net

>>>>        

>>>> [mailto:gumstix-users-bounces@lists.sourceforge.net] On Behalf Of Steve

>>>>        

>>>> Sakoman

>>>>        

>>>> Sent: 28 January 2008 14:23

>>>>        

>>>> To: General mailing list for gumstix users.

>>>>        

>>>> Subject: Re: [Gumstix-users] SPI C-code example

>>>>        

>>>>> On the hardware bits, do we need to have pull-up resistors for the

>>>>>          

>> data

>>

>>    

>>>>> lines (like in i2c bus)? Other than the decoupling capacitors, I've

>>>>>           

>>>> directly

>>>>        

>>>>> connected the SCLK, MOSI, MISO to the ADC and having hardwired the CS

>>>>>          

>> to

>>

>>    

>>>>> logic 0 via the GPIO. The Frame line is unused. Am I missing

>>>>>          

>> something?

>>

>>     

>>>> Yes, I think you have a hw issue.  You probably need to connect the CS

>>>>        

>>>> to the Frame signal.  The ADC likely requires that signal to function

>>>>        

>>>> properly.  I know the LTC1867 uses the CS signal to initiate the ADC

>>>>        

>>>> conversion as well as to frame the serial data transfer.

>>>>        

>>>> No pullups required, though if you are running the ADC at a different

>>>>        

>>>> supply voltage you may want to make sure you don't need to do any

>>>>         

>>>> level conversions.

>>>>        

>>>> Steve

>>>>        

>>>> On Jan 28, 2008 4:05 AM, Peck Hui Koh <pkoh@medphys.ucl.ac.uk> wrote:

>>>>        

>>>>> Thanks Dave, Steve for your great help.

>>>>>          

>>>>> Dave - I've taken your advice and modified the PXm_map and CR_map.

>>>>>          

>>>> However,

>>>>        

>>>>> the data output remains saturated as:

>>>>>          

>>>>> Transmit OK

>>>>>          

>>>>> 0x0000(0xffff)

>>>>>          

>>>>> Transmit OK

>>>>>          

>>>>> 0x0001(0xffff)

>>>>>          

>>>>> Transmit OK

>>>>>          

>>>>> 0x0002(0xffff)

>>>>>          

>>>>> Do you need to run any other program to enable the SPI bus?

>>>>>          

>>>>> Steve - I tried running using your example on my ADC (AD7706).

>>>>>          

>> However,

>>

>>    

>>>>> there seems to have no data output on the screen this time. I did some

>>>>>          

>>>>> slight changes to read the actual values on one channel (I've copied

>>>>>          

>> the

>>

>>    

>>>>> main program as below while the rest remained unchanged as in your

>>>>>          

>>>> example).

>>>>        

>>>>> I realised that the LTC1867 does not require any initialisation (the

>>>>>          

>>> first

>>>      

>>>>> word being sent out indicates which channel to sample). With or

>>>>>          

>> without

>>

>>    

>>>> the

>>>>        

>>>>> initialisation process, I could not retrieve any data from the SPI

>>>>>          

>> bus.

>>

>>    

>>> Am

>>>       

>>>> I

>>>>        

>>>>> doing something wrong here?

>>>>>          

>>>>> On the hardware bits, do we need to have pull-up resistors for the

>>>>>          

>> data

>>

>>    

>>>>> lines (like in i2c bus)? Other than the decoupling capacitors, I've

>>>>>          

>>>> directly

>>>>        

>>>>> connected the SCLK, MOSI, MISO to the ADC and having hardwired the CS

>>>>>          

>> to

>>

>>    

>>>>> logic 0 via the GPIO. The Frame line is unused. Am I missing

>>>>>          

>> something?

>>

>>    

>>>>> Too bad I do not have a logic analyser which will then allow me to

>>>>>          

>>>>> investigate the data flow. Observing the SCLK via a scope, I'm able to

>>>>>          

>>> see

>>>      

>>>>> the oscillation. Any advice will be greatly appreciated.

>>>>>          

>>>>> Peck

>>>>>          

>>>>> // ---------------------------------------Main Program

>>>>>          

>>>> ---------------------

>>>>        

>>>>> int main(int argc, char *argv[])

>>>>>          

>>>>> {

>>>>>           

>>>>>         int i,j;

>>>>>          

>>>>>         long data[16][1];

>>>>>          

>>>>>         int ClockDivider = 0;

>>>>>          

>>>>>         int delay = 5;

>>>>>          

>>>>>         int channel[] = {0x38};

>>>>>          

>>>>>         int result = SPIinit(ClockDivider);     // Initialize NSSP /

>>>>>          

>> SPI

>>

>>    

>>>>> Port

>>>>>          

>>>>>         int count = 10;

>>>>>          

>>>>>           for (i=0; i < 1; i++) {

>>>>>          

>>>>>                 SPI_TxRx(channel[i]); // request channel i data,

>>>>>          

>> discard

>>

>>    

>>>>> result

>>>>>          

>>>>>                 usleep(delay);

>>>>>          

>>>>>             for (j=0; j < count; j++) {

>>>>>          

>>>>>                 data[j][i]=SPI_TxRx(channel[i]);

>>>>>          

>>>>>                 usleep(delay);

>>>>>          

>>>>>                 }

>>>>>          

>>>>>         }

>>>>>          

>>>>>         return 1;

>>>>>          

>>>>>         for (i=0; i < count; i++) {

>>>>>          

>>>>>         printf("%ld\t\n", data[i][0]);

>>>>>          

>>>>>         }

>>>>>          

>>>>>         fflush(stdout);

>>>>>          

>>>>>         close(gpio_fd);

>>>>>          

>>>>>   return 1;

>>>>>          

>>>>> }

>>>>>          

>>>>> -----Original Message-----

>>>>>          

>>>>> From: gumstix-users-bounces@lists.sourceforge.net

>>>>>          

>>>>> [mailto:gumstix-users-bounces@lists.sourceforge.net] On Behalf Of

>>>>>          

>> Steve

>>

>>    

>>>>> Sakoman

>>>>>          

>>>>> Sent: 25 January 2008 15:30

>>>>>          

>>>>> To: General mailing list for gumstix users.

>>>>>          

>>>>> Subject: Re: [Gumstix-users] SPI C-code example

>>>>>          

>>>>> Peck,

>>>>>          

>>>>> Here's a quick & dirty command line program to get data from a LTC1867

>>>>>          

>>>>> 8 channel 16 bit A/D over spi using a user mode program.

>>>>>          

>>>>> It samples all 8 channels 4 times each, averages them and prints the

>>>>>          

>>>>> averages on the console.

>>>>>          

>>>>> I tested it on a connex 200.

>>>>>          

>>>>> Steve

>>>>>          

>>> -------------------------------------------------------------------------

>>>      

>>>>> This SF.net email is sponsored by: Microsoft

>>>>>          

>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.

>>>>>          

>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

>>>>>          

>>>>> _______________________________________________

>>>>>          

>>>>> gumstix-users mailing list

>>>>>          

>>>>> gumstix-users@lists.sourceforge.net

>>>>>          

>>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users

>>>>>          

>> -------------------------------------------------------------------------

>>

>>    

>>>> This SF.net email is sponsored by: Microsoft

>>>>        

>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.

>>>>        

>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

>>>>        

>>>> _______________________________________________

>>>>        

>>>> gumstix-users mailing list

>>>>        

>>>> gumstix-users@lists.sourceforge.net

>>>>        

>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users

>>>>        

>> -------------------------------------------------------------------------

>>

>>    

>>>> This SF.net email is sponsored by: Microsoft

>>>>        

>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.

>>>>        

>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

>>>>        

>>>> _______________________________________________

>>>>        

>>>> gumstix-users mailing list

>>>>        

>>>> gumstix-users@lists.sourceforge.net

>>>>        

>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users

>>>>        

>>> -------------------------------------------------------------------------

>>>      

>>> This SF.net email is sponsored by: Microsoft

>>>      

>>> Defy all challenges. Microsoft(R) Visual Studio 2008.

>>>      

>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

>>>      

>>> _______________________________________________

>>>      

>>> gumstix-users mailing list

>>>      

>>> gumstix-users@lists.sourceforge.net

>>>      

>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users

>>>      

>>> -------------------------------------------------------------------------

>>>      

>>> This SF.net email is sponsored by: Microsoft

>>>      

>>> Defy all challenges. Microsoft(R) Visual Studio 2008.

>>>      

>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

>>>      

>>> _______________________________________________

>>>      

>>> gumstix-users mailing list

>>>      

>>> gumstix-users@lists.sourceforge.net

>>>       

>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users

>>>      

>> -------------------------------------------------------------------------

>> This SF.net email is sponsored by: Microsoft

>> Defy all challenges. Microsoft(R) Visual Studio 2008.

>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

>> _______________________________________________

>> gumstix-users mailing list

>> gumstix-users@lists.sourceforge.net

>> https://lists.sourceforge.net/lists/listinfo/gumstix-users

>>

>>

>>    

>

> -------------------------------------------------------------------------

> This SF.net email is sponsored by: Microsoft

> Defy all challenges. Microsoft(R) Visual Studio 2008.

> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

> _______________________________________________

> gumstix-users mailing list

> gumstix-users@lists.sourceforge.net

> https://lists.sourceforge.net/lists/listinfo/gumstix-users

>

>  

 

 

-------------------------------------------------------------------------

This SF.net email is sponsored by: Microsoft

Defy all challenges. Microsoft(R) Visual Studio 2008.

http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________

gumstix-users mailing list

gumstix-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/gumstix-users