Prev: ping to usb interface fails for large packets
Next: Display Control Application Using Spartan FPGA
From: Bill Davy on 6 Mar 2010 12:54
"MK" <mk(a)nospam.please> wrote in message
news:T7CdnQSTcKTE8A_WnZ2dnUVZ7qudnZ2d(a)bt.com...
>
> "Hans-Bernhard Br�ker" <HBBroeker(a)t-online.de> wrote in message
> news:hmrmg1$qbh$00$1(a)news.t-online.com...
>> kishor wrote:
>>> Hi friends,
>>> I am working on 16 - channel data acquisition project, Silab C8051F310
>>> + ADS1255 + external multiplexer.
>>>
>>> ADC crystal is 7.643 MHz.
>>> SPI clock freq is 1.58 MHz
>>>
>>> Hardware interface-
>>> CS --> permanently tied to ground
>>
>> That's _wrong_. SPI uses edges of the CS line to signal the beginning of
>> a transaction. It can't work without it.
>>
>
> The OP needs to re-visit the data sheet. TI do offer a mode of operation
> for this part with CS tied to ground but of course it's not SPI - it's a
> two wire mode with DataIn and DataOut on th same pin and not all the chip
> functions are supported.
>
> Since the Silab part has proper SPI why not use it ?
>
> Michael Kellett
>


I would just mention I had trouble using the 'F064 SPI in 4 wire master mode
using NSSMD0, but all worked well using three wire mode and another port pin
for CS.


From: kishor on 8 Mar 2010 01:43
Hi friends,

As all of u mentioned, I concentrated on "timing issues".
I set the delay of 500 micro-seconds before "Read register command".

This works, I got the valid readings.

But still this is strange......, cause according to data sheet delay
should be 4 micro-seconds.

As the initialization is performed in once only (at starting),
It will not affect my ADC data scanning rate.

all other commands are working properly.

Thanks & regards,
Kishore.
From: Frnak McKenney on 8 Mar 2010 11:47

Hello, Kishore.

On Sun, 7 Mar 2010 22:43:07 -0800 (PST), kishor <kiishor(a)gmail.com> wrote:
> Hi friends,
>
> As all of u mentioned, I concentrated on "timing issues". I set
> the delay of 500 micro-seconds before "Read register command".

That's a _long_ time, even in "microcontroller years". <grin>

But "working" is always better than "non-working".

> This works, I got the valid readings.

Always a desirable outcome.

> But still this is strange......, cause according to data sheet
> delay should be 4 micro-seconds.

This sounded very fast for a complex chip startup, so I checked The
Datasheet. Under POWER-UP we see this:

"... A self-calibration is then performed automatically. For
best performance, it is strongly recommended to perform an
additional self-calibrarion by issuing the SELFCAL command after
the power supplies and voltage reference have had time to settle
to their final value."

Then, under SELFCAL:

"/DRDY goes high at the beginning of the calibration. It goes
low after the calibration completes and settled data is ready.
Do not send additional commands after issuing this command until
/DRDY goes low indicating that the calibration is complete."

It is not clear whether the "automatic" calibration is exactly the
same as SELFCAL, but it should raise a red (warning) flag as you
read it, especially when you noice from Table 21 that SELFCAL takes
600usec-1227msec to complete. That's 1227000usec; we're talking
microcontroller _centuries_ here. <grin>

It's also not stated in the datasheet (or I missed it) whether /DRDY
can be used to check whether the _automatic_ RESET/power-up
self-calibration has completed, but if I were writing the code I'd
give it a try. Using fixed timing to work around an unknown problem
would make me uncomfortable; your 500usec seems marginal (per Table
21); timings can change, and changing them is one of "Murphy's"
favorite pastimes. <grin>

> As the initialization is performed in once only (at starting), It
> will not affect my ADC data scanning rate.
>
> all other commands are working properly.

Good signs.

Best of luck.


Frank
--
Of all tyrannies, a tyranny sincerely exercised for the good of
its victims may be the most oppressive. It may be better to live
under robber barons than under omnipotent moral busybodies.
The robber baron's cruelty may sometimes sleep, his cupidity may
at some point be satiated: but those who torment us for our own
good will torment us without end, for they do so with the
approval of their own conscience. -- C. S. Lewis
--
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)
From: kishor on 9 Mar 2010 03:22
Hi Frank,

>
>    "...  A self-calibration is then performed automatically.  For
>     best performance, it is strongly recommended to perform an
>     additional self-calibrarion by issuing the SELFCAL command after
>     the power supplies and voltage reference have had time to settle
>     to their final value."
>
> Then, under SELFCAL:
>
>    "/DRDY goes high at the beginning of the calibration.  It goes
>     low after the calibration completes and settled data is ready.
>     Do not send additional commands after issuing this command until
>     /DRDY goes low indicating that the calibration is complete."
>
> It is not clear whether the "automatic" calibration is exactly the
> same as SELFCAL, but it should raise a red (warning) flag as you
> read it, especially when you noice from Table 21 that SELFCAL takes
> 600usec-1227msec to complete.  That's 1227000usec; we're talking
> microcontroller _centuries_ here.  <grin>
>
> It's also not stated in the datasheet (or I missed it) whether /DRDY
> can be used to check whether the _automatic_ RESET/power-up
> self-calibration has completed, but if I were writing the code I'd
> give it a try.  Using fixed timing to work around an unknown problem
> would make me uncomfortable; your 500usec seems marginal (per Table
> 21); timings can change, and changing them is one of "Murphy's"
> favorite pastimes.  <grin>
>

Thanks, you pointed out very important thing.

Now Instead of blind "500 micro-seconds" delay I am monitoring
DRDY line,
after "RESET" & "Write reg" command.

This approach will make my code more "Reliable" &
"Predictable".

Thanks & regards,
Kishore.

First  |  Prev  | 
Pages: 1 2
Prev: ping to usb interface fails for large packets
Next: Display Control Application Using Spartan FPGA