| View previous topic :: View next topic |
| Author |
Message |
hamedkungfu
Joined: 19 Dec 2018
Posts: 6
|
| SPI Set Delay Between Bytes When send 16BIT |
 Posted: Wed Dec 19, 2018 2:21 am |
 |
|
Hi every one
I send 16 bit data to sx1276 ic with pic16f877a.
When i see transfer data in scope i found problem. spi add delay between bytes and i don't know how to disable it.
| Code: | #use spi(DI=PIN_C4, DO=PIN_C5, CLK=PIN_C3, ENABLE=PIN_D3, CLOCK_HIGH=1, CLOCK_LOW=1, BITS=16, MODE=0, MSB_FIRST, FORCE_HW, STREAM=spi_stream)
unsigned int16 data_out = 0;
data_out = make16(addr , 0x00);
data_in = spi_xfer(spi_stream , data_out,16);
|
data capture by scope
[img]http://www.zsp-research.ir/pic16f877a.bmp[/img]
actual data must be:
[img]http://www.zsp-research.ir/sx1276-linux.bmp[/img] |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Wed Dec 19, 2018 3:44 am |
|
|
Why?.
The whole point about SPI, is that it is synchronous. Stops in the clock don't
matter at all.
You are not going to get continuous unbroken clocks from the PIC. You are
asking the chip to read the reply bytes as data is sent. This means it has to
wait for the byte transmission to have physically completed, and read the
first byte, before it can load the next byte. Hence a pause.
The only chips that can do this without a pause, are ones with a 16bit
SPI peripheral (so DsPIC's).
If you don't need the reply, the PIC can load the next byte before sending
of the first one has completed. |
|
|
hamedkungfu
Joined: 19 Dec 2018
Posts: 6
|
|
| Posted: Wed Dec 19, 2018 4:00 am |
|
|
| Ttelmah wrote: | Why?.
The whole point about SPI, is that it is synchronous. Stops in the clock don't
matter at all.
You are not going to get continuous unbroken clocks from the PIC. You are
asking the chip to read the reply bytes as data is sent. This means it has to
wait for the byte transmission to have physically completed, and read the
first byte, before it can load the next byte. Hence a pause.
The only chips that can do this without a pause, are ones with a 16bit
SPI peripheral (so DsPIC's).
If you don't need the reply, the PIC can load the next byte before sending
of the first one has completed. |
I test the transmit only but the result is same.
If you send more than 8 bit it will set delay after byte.
It must not be true because i get answer by PICBASIC and in spi_read() help i got this:
| Quote: |
Function:
Return a value read by the SPI. If a value is passed to SPI_READ the data will be clocked out and the data received will be returned. If no data is ready, SPI_READ will wait for the data.
If this device is the master then either do a SPI_WRITE(data) followed by a SPI_READ() or do a SPI_READ(data). These both do the same thing and will generate a clock. If there is no data to send just do a SPI_READ(0) to get the clock.
If this device is a slave then either call SPI_READ() to wait for the clock and data or use SPI_DATA_IS_IN() to determine if data is ready.
|
So if i send "0" must receive data by clock.
I just don't undrestand how it attach delay.
For that i use this code:
| Code: |
spi_write(addr);
spi_write(0);
data_in = spi_read();
|
and also:
| Code: |
spi_write(addr);
data_in = spi_read(0);
|
But the result is same. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Wed Dec 19, 2018 4:11 am |
|
|
It still has to load the next byte. The delay should be shorter. However I
repeat why do you care about this?. The whole point about SPI, is the master
determines the clock rate and timing. A pause in an SPI transmission does
not matter at all.
If you want more delay, then send in bytes, and wait between each one
instead of telling the code to send as a 16bit word. |
|
|
hamedkungfu
Joined: 19 Dec 2018
Posts: 6
|
|
| Posted: Wed Dec 19, 2018 4:48 am |
|
|
| Ttelmah wrote: | It still has to load the next byte. The delay should be shorter. However I
repeat why do you care about this?. The whole point about SPI, is the master
determines the clock rate and timing. A pause in an SPI transmission does
not matter at all.
If you want more delay, then send in bytes, and wait between each one
instead of telling the code to send as a 16bit word. |
My problem is it must not have delay. It must send second byte after first byte without delay because sx1276 can not understand the message |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Wed Dec 19, 2018 5:40 am |
|
|
Nothing in their data sheet suggests that that is the case. There is no
maximum time between bits.
I'd suspect your problem is more likely to be having the #USE SPI control the
enable. Operate the line yourself, since then you can support burst mode as well.
I have to ask why you are programming the SPI down to such a slow rate
(specifying high and low clock times)?. The chip supports 10MHz SPI, so 'as
fast as possible' would seem to make much more sense.
In fact on another processor, I've found libraries using interrupt driven
SPI, with even longer gaps between the bytes, working OK. This is not
your problem.
Looking at it your issue is much more likely to be voltage. The chip is a 3.3v
device. It's output will not go high enough to drive the SDI input of a 5v PIC.
Your PIC is rated for 4v minimum operation, so is not compatible without
level translators on the SDI line to the PIC, and a little attenuation on
the clock and data outputs. |
|
|
hamedkungfu
Joined: 19 Dec 2018
Posts: 6
|
|
| Posted: Wed Dec 19, 2018 12:24 pm |
|
|
| Ttelmah wrote: | Nothing in their data sheet suggests that that is the case. There is no
maximum time between bits.
I'd suspect your problem is more likely to be having the #USE SPI control the
enable. Operate the line yourself, since then you can support burst mode as well.
I have to ask why you are programming the SPI down to such a slow rate
(specifying high and low clock times)?. The chip supports 10MHz SPI, so 'as
fast as possible' would seem to make much more sense.
In fact on another processor, I've found libraries using interrupt driven
SPI, with even longer gaps between the bytes, working OK. This is not
your problem.
Looking at it your issue is much more likely to be voltage. The chip is a 3.3v
device. It's output will not go high enough to drive the SDI input of a 5v PIC.
Your PIC is rated for 4v minimum operation, so is not compatible without
level translators on the SDI line to the PIC, and a little attenuation on
the clock and data outputs. |
thank you very much
i use 3.3v as pic vdd and disable brwd. so i think SDI can detect but in any way i test level converter and inform you. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Wed Dec 19, 2018 12:30 pm |
|
|
Your PIC is not rated to run at 3.3v.
The _LF_ version is. But at 10MHz max. |
|
|
hamedkungfu
Joined: 19 Dec 2018
Posts: 6
|
|
| Posted: Wed Dec 19, 2018 2:56 pm |
|
|
| Ttelmah wrote: | Your PIC is not rated to run at 3.3v.
The _LF_ version is. But at 10MHz max. |
ooh let me check |
|
|
hamedkungfu
Joined: 19 Dec 2018
Posts: 6
|
|
| Posted: Sun Dec 23, 2018 9:26 am |
|
|
| hamedkungfu wrote: | | Ttelmah wrote: | Your PIC is not rated to run at 3.3v.
The _LF_ version is. But at 10MHz max. |
ooh let me check |
Hi I Use the Code with dspic30f4013 and i got the true answer. thanks you very much. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Sun Dec 23, 2018 9:51 am |
|
|
Good. Glad you have it working now.
It's becoming a rather regular one unfortunately.
3.3v peripheral, solutions:
1) 3.3v PIC or
2) Proper level translators. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Sun Dec 23, 2018 2:34 pm |
|
|
I'm just not convinced this is real hardware. Started by using the obsolete 877 then migrates to a powehouse DSPIC....
Heck it was hard enough for me to get into the 18F46K22 6-7 year ago...
Jay |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
