Hi,
Every time I have to look at the SPI settings, I get the problem of the different ways of understanding: CPOL CPHA CKE CKP SMP. It simply knots my brain, even though I can read it ok.

Here is my SPI set-up all commented for me to scan through, but it doesn't have CPHA or CPOL anywhere.
Can someone inject CPOL and CPHA in to it as simple as possible please? No explanations needed, just the minimum to make it clear.

Cheers, C.

'*******************************************************
'* *
'* START UP SPI ROUTINE *
'* *
'*******************************************************
Proc init_spi() 'PIC 18F46K20
TRISC.3 = 0 'SCK to Slave ****** output *******
TRISC.5 = 0 'MOSI ****** output *******
TRISC.4 = 1 'MISO ****** input *******

'MODE ????
SSPSTAT.SMP = 0 '1 = Input data sampled at end of data output time
'0 = Input data sampled at middle of data Output time
SSPSTAT.CKE = 0 '1 = Output data changes on clock transition from active to idle
'0 = Output data changes On clock transition from idle To active
SSPSTAT.5 = 0 'I2C only
SSPSTAT.4 = 0 'I2C only
SSPSTAT.3 = 0 'I2C only
SSPSTAT.2 = 0 'I2C only
SSPSTAT.1 = 0 'I2C only

SSPCON1 = 0 'RESET THE CONTROL REGISTER **ADDED
SSPCON1.WCOL = 0 'Collision detect
SSPCON1.SSPOV = 0 'Overflow
SSPCON1.SSPEN = 1 'Configure SCK,SD0,SDI,/SS ** HAS TO BE 1. To reset or reconfigure SPI mode, clear the SSPEN bit,
'reinitialize the sspcon registers And Then set the SSPEN Bit from the datasheet !!
SSPCON1.CKP = 1 '1 = Idle state for clock is a high level
'0 = Idle state For clock is A Low level
SSPCON1.SSPM3 = 0 '0000 = SPI Master mode, clock = FOSC/4
SSPCON1.SSPM2 = 0
SSPCON1.SSPM1 = 0 ''SPI Master mode, clock = F OSC/4
SSPCON1.SSPM0 = 0
End Proc
*************************************************************************************

 

You have the CKE and CKP bits here. Look at the datasheet pictures to see what combo gives the needed SPI mode. Use pictures instead of words to understand what's needed. It is confusing because the early documents were wrong.



https://microchip.my.site.com/s/art...-and-phase-reword-for-PIC18F-microcontrollers

Think about what SPI mode you need , then set the controller bits for that mode.

In general:
In SPI there is only one clock edge that matters to the receiver. In modes 0 and 3 it is the rising edge, in modes 1 and 2 it is the falling edge.

The only responsibility of each transmitter is to meet the requirements of the receiver.

 

You have the CKE and CKP bits here. Look at the datasheet pictures to see what combo gives the needed SPI mode. Use pictures instead of words to understand what's needed. It is confusing because the early documents were wrong.

View attachment 346005

https://microchip.my.site.com/s/art...-and-phase-reword-for-PIC18F-microcontrollers

Hi N,
Thanks but I can read and understand these and I've looked at them lots of times.

What I want if you're good enough, is as few words added to the comments of the SPI CODE I posted to show the above please.
C

 

Why would my words make any difference from other words in your comments if you have dyslexia?

IMO It's not going to help. As I had and still do have mild dyslexia. My countermeasures are to think/diagram/understand in pictures instead of words when things get twisted with words.

CPHA or CPOL are just words for signal timing requirements. The words are not important, understanding the timing sequences for SPI mode is. Don't get stuck on getting the words right, think about the waveform edges and timing that's needed in pictures you draw or search for.

 

Why would my words make any difference from other words in your comments if you have dyslexia?

IMO It's not going to help. As I had and still do have mild dyslexia. My countermeasures are to think in pictures instead of words when things get twisted.

Hi N,
It's probably not dyslexia I have, but a too creative mind, that adds things in where they may not be needed.

It's hard to explain, but the way I have commented my SPI CODE is clear until I have to change either my CODE or the digital analyser to match.
e,g, Change the clock polarity, and then does the phase also change because it's now upside down?
With what seems to be a simple concept changes to mind blowing, beacause of too many variables.

As previously with this exact problem, I would receive explanations and animations, which although being how a beginner would learn, once it's in the muscle memory,in not quite the correct clearness, that's it for life.

I tried to be as clear as possible with my initial posting
(Here is my SPI set-up all commented for me to scan through, but it doesn't have CPHA or CPOL anywhere.
Can someone inject CPOL and CPHA in to it as simple as possible please? No explanations needed, just the minimum to make it clear. )
but the first reply, was an explanation.
It's difficult I know!

EDIT: I hope this amuses you: https://forum.allaboutcircuits.com/...n-18f46k20-pic-oshonsfoft.189561/post-1768575
Thanks C.

 

Hi N,
It's probably not dyslexia I have, but a too creative mind, that adds things in where they may not be needed.

It's hard to explain, but the way I have commented my SPI CODE is clear until I have to change either my CODE or the digital analyser to match.
e,g, Change the clock polarity, and then does the phase also change because it's now upside down?
With what seems to be a simple concept changes to mind blowing, beacause of too many variables.

As previously with this exact problem, I would receive explanations and animations, which although being how a beginner would learn, once it's in the muscle memory,in not quite the correct clearness, that's it for life.

I tried to be as clear as possible with my initial posting
(Here is my SPI set-up all commented for me to scan through, but it doesn't have CPHA or CPOL anywhere.
Can someone inject CPOL and CPHA in to it as simple as possible please? No explanations needed, just the minimum to make it clear. )
but the first reply, was an explanation.
It's difficult I know!
Thanks C.

Be honest with yourself on what your issues are.


You don't need the confused terms CPOL and CPHA in your comments because they don't apply to the chip you are using, you need the SPI mode and controller bits needed by the receivers/slave devices in the comments because that's what matches what your test equipment sees and what you expect to see. You find the mode needed and put that as a comment.

I'm not a bot, I'm actually trying to help instead of just satisfy a request because you have a long history of asking the same questions.

These are SPI MODES on a chip that does have CPOL and CPHA bit selection. Your PIC has a similar MODE diagram using CKE and CKP bit selection. As you can see, the common factor is the MODES, not the bits that can called anything depending on the controller chip. You can use this to translate between the two types of controller mode setting bits.


Figure 2. SPI Mode 0, CPOL = 0, CPHA = 0: CLK idle state = low, data sampled on rising edge and shifted on falling edge.


Figure 3. SPI Mode 1, CPOL = 0, CPHA = 1: CLK idle state = low, data sampled on the falling edge and shifted on the rising edge.


Figure 4. SPI Mode 2, CPOL = 1, CPHA = 0: CLK idle state = high, data sampled on the falling edge and shifted on the rising edge.


Figure 5. SPI Mode 3, CPOL = 1, CPHA = 1: CLK idle state = high, data sampled on the rising edge and shifted on the falling edge.


The PIC spi MODE diagrams for CKP and CKE

 

Be honest with yourself on what your issues are.


You don't need the confused terms CPOL and CPHA in your comments because they don't apply to the chip you are using, you need the SPI mode and controller bits needed by the receivers/slave devices in the comments because that's what matches what your test equipment sees and what you expect to see. You find the mode needed and put that as a comment.

I'm not a bot, I'm actually trying to help instead of just satisfy a request because you have a long history of asking the same questions.

These are SPI MODES on a chip that does have CPOL and CPHA bit selection. Your PIC has a similar MODE diagram using CKE and CKP bit selection. As you can see, the common factor is the MODES, not the bits that can called anything depending on the controller chip. You can use this to translate between the two types of controller mode setting bits.

View attachment 346015
Figure 2. SPI Mode 0, CPOL = 0, CPHA = 0: CLK idle state = low, data sampled on rising edge and shifted on falling edge.

View attachment 346016
Figure 3. SPI Mode 1, CPOL = 0, CPHA = 1: CLK idle state = low, data sampled on the falling edge and shifted on the rising edge.

View attachment 346017
Figure 4. SPI Mode 2, CPOL = 1, CPHA = 0: CLK idle state = high, data sampled on the falling edge and shifted on the rising edge.

View attachment 346018
Figure 5. SPI Mode 3, CPOL = 1, CPHA = 1: CLK idle state = high, data sampled on the rising edge and shifted on the falling edge.


The PIC spi MODE diagrams for CKP and CKE
View attachment 346019

Hi N,
The reason for You: You don't need the confused terms CPOL and CPHA is the PIC D/S has CKP and CKE and the analyser has CPOL and CPHA.

I'll add the comments to my SPI myself, Just a lot of concentration and proof reading, then I'll not need to ask the question again
Thanks for your efforts.
C.

 

Hi N,
The reason for You: You don't need the confused terms CPOL and CPHA is the PIC D/S has CKP and CKE and the analyser has CPOL and CPHA.

I'll add the comments to my SPI myself, Just a lot of concentration and proof reading, then I'll not need to ask the question again
Thanks for your efforts.
C.

I knew you could do it, if pushed. Old saying here in the USA.


I don't have a problem with making comments in code but the comments should be about the code, not about the analyser. The key to that issue is to have a nice CKP and CKE to CPOL and CPHA conversion chart next to the terminal or in a header that explains what specific systems are used to test the SPI modes generated from the code.

Code comments should be brief and explain what the code is doing at that point.

 

It's purpose is to be annoying. There are four possibilities, and none of them has become standard. It's there so you can have a microcontroller with an SPI interface, and four SPI peripherals, yet only be able to connect one of them.
A lot to be said for I2C (but it's slow).

 

It's purpose is to be annoying. There are four possibilities, and none of them has become standard. It's there so you can have a microcontroller with an SPI interface, and four SPI peripherals, yet only be able to connect one of them.
A lot to be said for I2C (but it's slow).

I've learned how to switch SPI modes on the fly with most controllers. I have several devices that update LCD panels with 30 MHz SPI clocks at one mode, then switch to a completely different speed 2 MHz and SPI mode for another device(s) round and round in the data update and display cycle on embedded systems. Yes, there is a delay (it varies from 8-bit to 32-bit SPI modules, the simple 8-bit interfaces are usually simpler and faster relative to normal processing processing speeds to switch) in waiting for the current transaction to finish, idle and disable the SPI module, configure the device and restart. I normally do this in a interrupt context with DMA so there is no waiting in the main processing thread for it to complete.

 

But wouldn't it be nice if you didn't have to? If everyone used the same mode, and there were no CPHA and CPOL bits to set?

 

But wouldn't it be nice if you didn't have to? If everyone used the same mode, and there were no CPHA and CPOL bits to set?

If I2C could run at 30 MHz, then yes. I'll take fast over nice, anyday. This is very simple and nice by comparison to most things I work on, try hacking Linux USB kernel drivers to make cheap DAQ devices, designed to only work in windows, work in Linux.
My current USB device is the DT9812. I'm modernizing an old linux driver from 2005 that ran on hardware (that didn't need firmware, and had a slightly difference information index) several revision below the modern hardware. The modern hardware needs firmware loaded just to have the correct productID for the actual DAQ function drivers to work, the first productID for the firmware loader is not even listed in the Linux USB ID database.


Message and reply from the Linux maintainer of this subsystem. I've submitted new drivers and modifications to them before that are in the current Linux kernel.
SImple example: https://gitlab.sdu.dk/sdurobotics/l...5/drivers/staging/comedi/drivers/ni_daq_700.c
https://www.comedi.org/

to Comedi: Linux Control and Measurement Device Interface


Trying to get this to work with a DT9812 but am having some strange problems. The first thing is the returned product ID is sort of reversed from the device model.
usb 4-1: New USB device found, idVendor=0867, idProduct=1298, bcdDevice= 0.00

The driver dt9812_usb_table in dt9812.c was changed to match that number.

static const struct usb_device_id dt9812_usb_table[] = {
{ USB_DEVICE(0x0867, 0x1298) },
{ }
};

The original value inthe driver struct was (0x0867, 0x9812)

Now the recompiled dt9812 module actually loads and tried to run but this is the result:

[240608.280804] comedi: version 0.7.76 - http://www.comedi.org
[240608.298984] comedi comedi0: Wrong number of endpoints
[240608.298990] dt9812 3-9.3:1.0: driver 'dt9812' failed to auto-configure device.
[240608.299072] usbcore: registered new interface driver dt9812

The number of end points returned is zero.


The VM110N driver (also USB) works fine.

[ 3251.595450] usb 1-1.4: new full-speed USB device number 9 using ehci-platform
[ 3251.702245] usb 1-1.4: New USB device found, idVendor=10cf, idProduct=5501, bcdDevice= 0.02
[ 3251.702285] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3251.702302] usb 1-1.4: Product: K8055N/VM110N USB Experiment Board
[ 3251.702315] usb 1-1.4: Manufacturer: Velleman Instruments
[ 3251.736447] comedi comedi0: driver 'vmk80xx' has successfully auto-configured 'K8055 (VM110)'.
[ 3251.736675] usbcore: registered new interface driver vmk80xx

Running Debian 6.12.20-amd64 and I also tried with an Orange PI arm64 machine with the same result after the driver modifications to match the idProduct=1298

Source of the error message.
static int dt9812_find_endpoints(struct comedi_device *dev)
{
struct usb_interface *intf = comedi_to_usb_interface(dev);
struct usb_host_interface *host = intf->cur_altsetting;
struct dt9812_private *devpriv = dev->private;
struct usb_endpoint_descriptor *ep;
int i;

if (host->desc.bNumEndpoints != 5) {
dev_err(dev->class_dev, "Wrong number of endpoints\n");
return -ENODEV;
}

Yes, the DT9812 works using the Windows driver running Win11
...
a reply from the Comedi DAQ library maintainer.

On 2025-03-29 20:45, 'xxxxxxxx' via Comedi: Linux Control and
Measurement Device Interface wrote:
>
> Trying to get this to work with a DT9812 but am having some strange
> problems. The first thing is the returned product ID is sort of reversed
> from the device model.
> usb 4-1: New USB device found, idVendor=0867, idProduct=1298,
> bcdDevice= 0.00

> Yes, the DT9812 works using the Windows driver running Win11

Looking at the "DT9812_Kmdf.inf" file from the Windows drivers installed
by the "Omni-CD"
https://files.digilent.com/#downloads/DTSoftware/Omni-CD/
, in
C:\Program Files (x86)\Data Translation\DeviceDriversEV\DT9812
, the device ID USB\VID_0867&PID_1298 appears to be a "DT9812 Firmware
Loader" device. That .inf file also supports "DT9812" (PID 0x9812),
"DT9813" (PID 0x9813), and "DT9814" (PID 0x9814). The "DT9812 Firmware
Loader" device uses a different kernel driver (.sys) file than the others:

* DT9812 Firmware Loader: DT9812ld_x86.sys or dt9812ld_x64.sys
* DT9812, DT9813, DT9814: DT9812k.sys or DT9812k_x64.sys

Perhaps the ID changes after the firmware is updated? Or perhaps the
"DT9812 Firmware Loader" device is a hardware re-spin of the old device?
I don't really know, to be honest.

A few days later made some progres.

Great, making some progress. Used windows to load the firmware on the battery powered (to the PCB) DT9812, unplugged from that and reconnected the normal USB plug to the Linux machine. Driver loads to the correct product ID now on Linux dt9812.
Now there are issues with dt9812_read_info (it does read the correct serial) but at least it's alive and able to be debugged.

[17404.053736] usb 1-1.3.4: new full-speed USB device number 25 using ehci-platform
[17404.246561] usb 1-1.3.4: New USB device found, idVendor=0867, idProduct=9812, bcdDevice= 0.04
[17404.246596] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[17404.246616] usb 1-1.3.4: Product: DT ECON DAQ
[17404.246632] usb 1-1.3.4: Manufacturer: Data Translation
[17404.264882] comedi: version 0.7.76 - http://www.comedi.org
[17404.270408] comedi comedi0: USB DT9812 (ffff.ffff.0000) #0x0117fcd4
[17404.270451] comedi comedi0: driver 'dt9812' has successfully auto-configured 'dt9812'.
[17404.272462] usbcore: registered new interface driver dt9812

Now I can finally start hacking the driver back into proper operation and then add a firmware loader to the new driver.

 

I knew you could do it, if pushed. Old saying here in the USA.
View attachment 346049

I don't have a problem with making comments in code but the comments should be about the code, not about the analyser. The key to that issue is to have a nice CKP and CKE to CPOL and CPHA conversion chart next to the terminal or in a header that explains what specific systems are used to test the SPI modes generated from the code.

Code comments should be brief and explain what the code is doing at that point.

Hi N,
No I'm not American 1/I think the word should start with a capitol A. 2/ comment not added!

The image in #7 shows why I mention CPOL and CPHA, did you view it?
C.

 

But wouldn't it be nice if you didn't have to? If everyone used the same mode, and there were no CPHA and CPOL bits to set?

Hi I,
Yes wouldn't it.
I'm still having difficulty. Here is the image that was posted to the same question, I made a couple of years ago, from another person having difficulties.
I'm stuck at the START, MIDDLE and END part.
C.

 

Hi N,
No I'm not American 1/I think the word should start with a capitol A. 2/ comment not added!

The image in #7 shows why I mention CPOL and CPHA, did you view it?
C.View attachment 346091

Not American version.

Yes, I've viewed things like that many times. The secret to less confusion is to think in SPI mode numbers, not the stupid bit names (as they are nonstandard and change from controller to controller) to get those modes. In the post above you have good translation chart, use IT. Don't try to remember the stupid confusing names,




Don't try to remember the stupid confusing names, Don't try to remember the stupid confusing names. Look at the waveform traces in the datasheets and on your scope or analyzer.

Unless you are more that 50 years old, I've been programming/hacking/reverse engineering SPI/shift register interfaces for longer than you've been alive. Trust me with this one.

 

Not American version.

Yes, I've viewed things like that many times. The secret to less confusion is to think in SPI mode numbers, not the stupid bit names (as they are nonstandard and change from controller to controller) to get those modes. In the post above you have good translation chart, use IT. Don't try to remember the stupid confusing names,

View attachment 346119


Don't try to remember the stupid confusing names, Don't try to remember the stupid confusing names. Look at the waveform traces in the datasheets and on your scope or analyzer.

Unless you are more that 50 years old, I've been programming/hacking/reverse engineering SPI/shift register interfaces for longer than you've been alive. Trust me with this one.

Hi N,
I can't tell if you're missing the point or not, but the analyser needs CPOL and CPHA settings, and the PIC d/S needs CKP and CKE settings, and this mixes me up, nothing more to it.

I can just about remember when I was 50
C.

 

"the analyser needs CPOL and CPHA settings, and the PIC d/S needs CKP and CKE settings"

I'm not missing the point. The common between them is the SPI MODE numbers. FInd (it's usually somewhere on the device datasheet) what SPI mode number is needed to talk to X slave device from Y master device. Then set that on the PIC and your analyzer using the words used in each device for spi MODES. The MODE is what's important as your KEY to unlock the correct data and clock setting on any SPI device.

Example: https://newhavendisplay.com/content/specs/NHD-0420D3Z-NSW-BBW-V3.pdf



PIC


I can easily about remember when I was 50, those were great times.

 

"the analyser needs CPOL and CPHA settings, and the PIC d/S needs CKP and CKE settings"

I'm not missing the point. The common between them is the SPI MODE numbers. FInd (it's usually somewhere on the device datasheet) what SPI mode number is needed to talk to X slave device from Y master device. Then set that on the PIC and your analyzer using the words used in each device for spi MODES. The MODE is what's important as your KEY to unlock the correct data and clock setting on any SPI device.

Example: https://newhavendisplay.com/content/specs/NHD-0420D3Z-NSW-BBW-V3.pdf

View attachment 346126

PIC
View attachment 346127

I can easily about remember when I was 50, those were great times.

Hi N,
Thanks, but remember, all I want to do is edit my comments of my SPI set-up, so I won't have to go through this again.

Now on first look this morning, this all looks clear and easy, but with the D/S open and the MODE chart open, and the CPHA explanation open, I'm faced with TRANSITION, VALID and TRANSMIT, between the three.
Can you explain the difference and relationship between these please?

I'm sure my brain sees the none standard way that SPI is documented, and it just rejects it and won't remember.
C

 

Hi,
OFF TOPIC, but a diversion!

I have fitted some windows in what was an outside toilet wall, and know the building regulations for here, state, that any window below waist height must be toughened glass.
The supplier evidently didn't use toughened glass, so the building control have rejected them.
New glass perhaps £300.

It didn't make my day.
C

 

Hi N,
Thanks, but remember, all I want to do is edit my comments of my SPI set-up, so I won't have to go through this again.

Now on first look this morning, this all looks clear and easy, but with the D/S open and the MODE chart open, and the CPHA explanation open, I'm faced with TRANSITION, VALID and TRANSMIT, between the three.
Can you explain the difference and relationship between these please?

I'm sure my brain sees the none standard way that SPI is documented, and it just rejects it and won't remember.
C

You will go through it again, and again. I do it every time I design in a new SPI device. Documenting what works in comments is fine but it's of little use for the next project or device you need to use with SPI.

This is a true trick we learned in code school long ago, called redaction (sanitization) of memory. Put tape (or blackout the pdf today) over the parts of text or ductuments you don't need think about or study when doing code conversions. It stops the busy, must know everything, part of the brain from going astray on extra information that not needed.

We can't change our brains but we can learn how to optimize what we have.