SPI timing

[Dany]

Hi,

when using

Code: Select all

SPI1_Init_Advanced(_SPI_MASTER_OSC_DIV64, _SPI_DATA_SAMPLE_Middle, _SPI_CLK_IDLE_LOW, _SPI_LOW_2_HIGH);

the SCL and SDO signals look like this (SCL on top, SDO - value $aa - below it):

As you can see clearly the data is transmitted on the clock change from high to low, while the last parameter in the init command says "_SPI_LOW_2_HIGH" (the "transmit_edge" according to the help file).

If I check the CKE_bit then I see it has the value 1 ("transmit edge active to idle").

So, something is wrong here (either the help file or the compiler). Anyway, the "transmit edge" parameter causes the opposite result in the "CKE_bit".

See also http://www.mikroe.com/forum/viewtopic.php?f=107&t=37781 where I mentioned first this problem.
The suggestion there was to change the help file (renaming the parameter and the help file contents to something like "output data valid edge") and leave the compiler as it is. Disadvantage of that way of working is the deviation of the datasheet where CKE_bit is actually the "transmit" (not "valid") edge.
The dsPIC help file is Ok.

Thanks in advance!

[Durango]

Hi Dany,

It sure looks to me that the PIC is outputting data on the rising edge as you have it configured.
Remember the data has to set(valid), prior to the clock edge being set( rising or falling edge). In your example picture that appears to be the case at least to me.

It looks like you sent a hex(AA). If you think it is sending the data on the falling, I can not say for sure what the data is because it appears to be changing at the same time. Not a good thing for your external SPI device.

Durango

[janni]

It sure looks to me that the PIC is outputting data on the rising edge as you have it configured.
Remember the data has to set(valid), prior to the clock edge being set( rising or falling edge). In your example picture that appears to be the case at least to me.

It's a question of definition. If Microchip datasheets state that 'transmit occurs' on clock edge where data changes on the bus (quite logically as it's the only distinctive moment from transmitter's point of view) then 'Transmit edge' in Help should follow this definition to avoid confusion.

Naturally, reception should take place away from the moment when data changes, like on opposite clock edge, but then, as Dany said, such moment should be called differently.

[Dany]

Thanks Janni.

Naturally, reception should take place away from the moment when data changes, like on opposite clock edge, but then, as Dany said, such moment should be called differently.

This is already done in the dsPIC compiler's help. The "edge" parameter there has 2 possible values:

Code: Select all

                       Clock Edge 
Description                                   Predefined library const 
Data is valid on ACTIVE-to-IDLE transition   _SPI_ACTIVE_2_IDLE 
Data is valid on IDLE-to-ACTIVE transition   _SPI_IDLE_2_ACTIVE 

It states clearly that the "edge" is the "data valid" edge and not the "transmit" edge.

[Dany]

Hi Dany,

It sure looks to me that the PIC is outputting data on the rising edge as you have it configured.
Remember the data has to set(valid), prior to the clock edge being set( rising or falling edge). In your example picture that appears to be the case at least to me.

It looks like you sent a hex(AA). If you think it is sending the data on the falling, I can not say for sure what the data is because it appears to be changing at the same time. Not a good thing for your external SPI device.

Durango

Thanks!
The help states that the "edge" is the "transmit edge" (both in the naming of the parameter and the explanation of the values), and the MCHP datasheet states that the transmit edge is the clock edge at which the SDO data changes.
So, If I choose "Low_2_High", the data should change on that clock edge.
In reality it is the other way around: the data changes at the high to low edge (blue is clock, red is data in the oscillogram).

Excerpt of the help:

Code: Select all

                       Transmit edge: 
Description                               Predefined library const 
Data transmit on low to high edge        _SPI_LOW_2_HIGH 
Data transmit on high to low edge        _SPI_HIGH_2_LOW 

As you can see this parameter should control clearly the "transmit" edge according the helpfile.

p.s. I do indeed send $AA as SDO.

[Durango]

Hey I know it is confusing but here is some images from Microchip SPI document.

untitled.JPG (107.76 KiB) Viewed 6861 times

untitled1.JPG (114.3 KiB) Viewed 6861 times

The transmits data edge in your example and in Microchip's is the low to high clock edge.
The data get changed on the opposite edge high to low. It is not getting transmit at this time it is just getting change for the next low to high transition if the data needs to be changed. You can not have the clock edge and the data changing at the same time. How would the SPI device that is being communicated with know for sure the data value is when it is changes on the clock edge. There is a certain amount time of required for the data to be valid before the clock edge clocks it in.

I think that since you see the data changing at the same time the clock is going high to low, that this is when it is trasmitting.
This is not the case it is just changing the data for the next clock pulse high.

[Dany]

Thanks Durango.

I my first post I was trying to use mode "0,1" which is:
clock idle low,
transmit edge low to high.

What I got was mode "0,0":
clock idle low,
transmit edge high to low.

That is the whole problem.

[Durango]

Okay now I see the issue, sorry about the confusion.

I believe your PIC is behaving as you stated in your Mikro code Init, but is disagrees with Microchips data sheet.

I think issue falls on Microchip and their documentation. Here is some information from two PIC 18F's on the SSPSTAT register.
The first is from a 18F2xK22.

bit 6 CKE: SPI Clock Edge Select bit (SPI mode only)
In SPI Master or Slave mode:
1 = Transmit occurs on transition from active to Idle clock state
0 = Transmit occurs on transition from Idle to active clock state

The next is from 18F252.

bit 6 CKE: SPI Clock Edge Select
When CKP = 0:
1 = Data transmitted on rising edge of SCK
0 = Data transmitted on falling edge of SCK
When CKP = 1:
1 = Data transmitted on falling edge of SCK
0 = Data transmitted on rising edge of SCK

Unless Microchip changed their SPI module on the PIC18's which I doubt.
These two PIC's with the same bits(CKE=1, CKP=0) are completely opposite per the data sheets.

Mikro seems to configure the register for the older PIC and not the newer one. I think the newer PIC data sheet is incorrect in my opinion.

Not sure Mikro can do anything about this.

Durango

[janni]

Unless Microchip changed their SPI module on the PIC18's which I doubt.

You're right. Diagrams in old and new datasheets are the same so the SPI module works as it used to.

I think the newer PIC data sheet is incorrect in my opinion.

I don't think so. Dany's measurements are identical to the diagrams and description in PIC18xxK22 (or PICFxx20) for the same settings (CKP=0, CKE=1). Same diagrams are presented in PIC18FXX2 datasheet, but description of CKE bit indeed opposes what's shown there.

[Durango]

Janni,

I guess I mis-spoke about being incorrect.

Yes Microchip diagrams are the same for the older and newer PICS
Also Dany's measurement confirm the diagrams.

What I mean is that Microchip documents define the CKE bit differently and I am not sure why.
If they are indeed the same why change the CKE decription.

I also still believe with Dany's settings, that the external SPI device is getting the data sent to it on the clocks rising edge when the data is stable. In the diagram's case it occurs at the center of the data Then the data is changed on the clocks falling and at the same time the PIC would read in any data sent to it on the SDI pin on the same falling edge.

I think Mikro libs set up the SPI correctly it just does not agree with the new CKE description.

[janni]

Hi Durango,

Note that this discussion is not about who is right and why Microchip used descriptions disagreeing with diagrams and other vendors, but how to change description in Help to avoid misunderstandings. Your opposing opinion actually proves that present description is not adequate.

I also still believe with Dany's settings, that the external SPI device is getting the data sent to it on the clocks rising edge when the data is stable. In the diagram's case it occurs at the center of the data Then the data is changed on the clocks falling and at the same time the PIC would read in any data sent to it on the SDI pin on the same falling edge.

There's no doubt about this. It's depicted as the mode set with CKP=0 and CKE=1 (mode 0,0) in datasheet diagram and we all agree how it works.

I think Mikro libs set up the SPI correctly it just does not agree with the new CKE description.

Well, that's where we disagree . But it should be enough to look at the diagrams to clear things up. We agree that transmitter changes data on falling edge of clock. From transmitter point of view, it's the only distinctive moment - the moment when it starts transmitting new data. Not some arbitrary time after, or before. And, for CKP=0 (clock idle state low) and CKE=1, the datasheet says: 'Transmit occurs on transition from active to Idle clock state', i.e. on transition from high to low clock state. That's in par with other descriptions of SPI interface. While different terms are used, mostly describing the moment when data is read/latched/captured, this moment is distinctly differentiated from the moment when data is changed/transmitted/propagated.

Unfortunately, one obtains the CKP=0 and CKE=1 settings with _SPI_CLK_IDLE_LOW and _SPI_LOW_2_HIGH value of 'Transmit edge' parameter in SPI1_Init_Advanced call. This value is described as 'Data transmit on low to high edge'. Well, I wouldn't interpret this as 'data should be read on low to high edge' .

While it's probably a leftover from older Microchip datasheets and no fault of mE, I agree with Dany that something should be done. Easiest and not affecting already written code would be to change description in Help. 'Data valid clock edge' seems unambiguous.

[Dany]

Hi,
I took the opportunity to update my article about SPI timing, see http://www.rosseeld.be/DRO/PIC/SPI_Timing.htm.
I hope it does not contain faults, it is very confusing with these inversions and unclarities described in the posts above.
If you see errors, please inform me.
Thanks in advance!

[janko.kaljevic]

Hello,

Thanks for reporting this.

SPI clock timing should be explained better in Help file, and we will correct this in next version of compiler.

Best regards.

[Dany]

Hello,

Thanks for reporting this.

SPI clock timing should be explained better in Help file, and we will correct this in next version of compiler.

Best regards.

Nice! Thanks.

[Dany]

Hi all,

It seems the "problem" described in above posts was discovered already some time ago, and was apparently never corrected.
It also seems I forgot about the earlier detection of the problem and did the complete investigation over again. I must be getting old...

See http://www.mikroe.com/forum/viewtopic.php?f=107&t=37781.