> I'm confused about the following situation:

> A transceiver is connected in SPI mode to a microcontroller(LPC12xx).
> The transceiver outputs a continous clock ,and it does not drive any SSEL
> line to enable the SPI section of the microcontroller.
> The microcontroller should decide when to start a data transmission,but just
> enabling its SPI module it goes in Busy condition and i have found no way to
> change it.
> Polling the BSY flag goes to a never ending loop,just as the uC is still
> sending out something,or receiving and it is always busy.

> How is the right way to deal with similar situations?

> Many thanks for help or hints or links
> Diego

>>> Please can i have your help?

>>> I'm confused about the following situation:

>>> A transceiver is connected in SPI mode to a microcontroller(LPC12xx).
>>> The transceiver outputs a continous clock ,and it does not drive any SSEL
>>> line to enable the SPI section of the microcontroller.
>>> The microcontroller should decide when to start a data transmission,but
>>> just
>>> enabling its SPI module it goes in Busy condition and i have found no way
>>> to
>>> change it.
>>> Polling the BSY flag goes to a never ending loop,just as the uC is still
>>> sending out something,or receiving and it is always busy.

>>> How is the right way to deal with similar situations?

>>> Many thanks for help or hints or links
>>> Diego

>> If your transceiver outputs a continuous clock, and has no SSEL, then
>> how does it expect the receiving device to frame the data?

> Thanks for your answer
> Mine is..I dont'know...
> the transceiver is
> http://www.analog.com/static/imported-files/data_sheets/ADF7021-N.pdf
> if you take a look at page 46 Figure 60 you can see how microcontroller and
> transceiver are connecter.None of lower output signals SWD or SREAD acts as
> SSEL.

> At least i could use those signals to write into control registers,to enable
> TX mode only when i need it,but i don't think that i could have a known
> number of clock pulses in this way.

> Thanks for your attention
> Diego

>>>> Please can i have your help?

>>>> I'm confused about the following situation:

>>>> A transceiver is connected in SPI mode to a microcontroller(LPC12xx).
>>>> The transceiver outputs a continous clock ,and it does not drive any
>>>> SSEL
>>>> line to enable the SPI section of the microcontroller.
>>>> The microcontroller should decide when to start a data transmission,but
>>>> just
>>>> enabling its SPI module it goes in Busy condition and i have found no
>>>> way
>>>> to
>>>> change it.
>>>> Polling the BSY flag goes to a never ending loop,just as the uC is
>>>> still
>>>> sending out something,or receiving and it is always busy.

>>>> How is the right way to deal with similar situations?

>>> If your transceiver outputs a continuous clock, and has no SSEL, then
>>> how does it expect the receiving device to frame the data?

>> Thanks for your answer
>> Mine is..I dont'know...
>> the transceiver is
>> http://www.analog.com/static/imported-files/data_sheets/ADF7021-N.pdf
>> if you take a look at page 46 Figure 60 you can see how microcontroller
>> and
>> transceiver are connecter.None of lower output signals SWD or SREAD acts
>> as
>> SSEL.

> You mean this figure 60, the one that states:
> Figure 60. ADF7021-N (UART Mode) to Asynchronous Microcontroller Interface

> This is NOT using the SPI interface for this mode of operation.

> The paragraph heading should have told you something: UART Mode

> Please re-read these paragraphs and form your question from there.

> Its figure 61 that uses SPI.

> hamilton

>>> Please can i have your help?

>>> I'm confused about the following situation:

>>> A transceiver is connected in SPI mode to a microcontroller(LPC12xx).
>>> The transceiver outputs a continous clock ,and it does not drive any SSEL
>>> line to enable the SPI section of the microcontroller.
>>> The microcontroller should decide when to start a data transmission,but
>>> just
>>> enabling its SPI module it goes in Busy condition and i have found no way
>>> to
>>> change it.
>>> Polling the BSY flag goes to a never ending loop,just as the uC is still
>>> sending out something,or receiving and it is always busy.

>>> How is the right way to deal with similar situations?

>>> Many thanks for help or hints or links
>>> Diego

>> If your transceiver outputs a continuous clock, and has no SSEL, then
>> how does it expect the receiving device to frame the data?

> Thanks for your answer
> Mine is..I dont'know...
> the transceiver is
> http://www.analog.com/static/imported-files/data_sheets/ADF7021-N.pdf
> if you take a look at page 46 Figure 60 you can see how microcontroller and
> transceiver are connecter.None of lower output signals SWD or SREAD acts as
> SSEL.

> At least i could use those signals to write into control registers,to enable
> TX mode only when i need it,but i don't think that i could have a known
> number of clock pulses in this way.

> Thanks for your attention
> Diego

>>>> Please can i have your help?

>>>> I'm confused about the following situation:

>>>> A transceiver is connected in SPI mode to a microcontroller(LPC12xx).
>>>> The transceiver outputs a continous clock ,and it does not drive any
>>>> SSEL
>>>> line to enable the SPI section of the microcontroller.
>>>> The microcontroller should decide when to start a data transmission,but
>>>> just
>>>> enabling its SPI module it goes in Busy condition and i have found no
>>>> way
>>>> to
>>>> change it.
>>>> Polling the BSY flag goes to a never ending loop,just as the uC is
>>>> still
>>>> sending out something,or receiving and it is always busy.

>>>> How is the right way to deal with similar situations?

> The payload interface (TxRxCLK and TxRxDATA) transfers just a raw bit
> stream with no framing provided, see figures 8 and 9 in the linked
> data sheet. It is up to you to decode the bit porridge. A suggested
> framing is in figure 54 of the data sheet. The raw bit stream is not
> very well suited to a SPI interface, though it is so named by AD.

> You might be better off using the UART mode with an UART interface
> on the host processor.

> --