RESOLVED: SPIMode: Second parameter not working?

[Picsi]

Hello everyone.

First of all: I'm a GC-BASIC beginner, so I apologise for any stupid questions ;)

I'm trying to transfer data via SPI to an OLED display with controller SSD0332.

The output from the PIC works so far, but CPOL and CPHA are always 0, no matter what I specify as the second parameter in SPIMode. However, the display controller expects CPOL=1 and CPHA=1.

In addition, CS (SS1) is H-active, but the controller has a CS# input. Is it possible to configure this differently?

Here is a shortened example code without comments that shows this behavior:

#CHIP 18F16Q41,16
#INCLUDE <lowlevel\hwspi.h>

#STARTUP InitPPS, 85
#DEFINE PPSToolPart 18F16Q41

SUB InitPPS
UNLOCKPPS
  SPI1SDIPPS = 0x000C
  RB6PPS = 0x001B
  SPI1SCKPPS = 0x000E
  RB5PPS = 0x001C
  RC6PPS = 0x001D
  SPI1SSPPS = 0x0016
LOCKPPS
END SUB

#DEFINE SPI_HardwareSPI
#DEFINE HWSPIMode MASTER
SPIMode (Master, 3)

#DEFINE SPI_SCK   PORTB.6
#DEFINE SPI_DO    PORTB.5
#DEFINE SPI_DI    PORTB.4
#DEFINE SPI_DC    PortC.1
#DEFINE SPI_CS    PortC.6
#DEFINE SPI_RESET PortC.2

DIR SPI_SCK   OUT
DIR SPI_DO    OUT
DIR SPI_DI    IN
DIR SPI_DC    OUT
DIR SPI_CS    OUT
DIR SPI_RESET OUT

DIM I AS BYTE

DO
  'SPITransfer 0x75, I
  FastHWSPITransfer 0x75
LOOP

Among other things, I have tested the following:
- Different notations (all of them should work): SPIMode (Master, 3) / SPIMode Master, 3 / SPIMode Master,3 / SPIMode (Master, 2+1) etc.
- SPIMode itself is recognised, if I specify MasterFast instead of Master, the clock frequency changes
- with and without #DEFINE SPI_HardwareSPI
- with and without #DEFINE HWSPIMode MASTER
- with and without #DEFINE HWSPIClockMode 3
- SPITransfer and FastHWSPITransfer
- hwspi.h manually included or not

I created the PPS-Config with the PPS Tool 0.0.6.5. GCstudio is version 1.0121.
I couldn't find anything in the instructions or here in the forum that helped me, although I searched for some time.

Another question:
Can I access the SPIxCLK bits such as CKP, CKE and SMP? Can I change the bits of the SPIxCON1 registers? If so, how? How can I generally access such registers from GCBASIC? Or do the libraries block access?

Many thanks in advance! :)

PS: Using my self-programmed software SPI with CPOL=1, CPHA=1 and CS#, everything works, although a little slowly. The display reacts and shows what it should.

PPS: During the search I discovered a small error in hwspi.h: In line 168 a space is missing before the "then".

[Anobium]

The constant HWSPIClockMode should resolve. tml

#define HWSPIClockMode 0

This will directly set the system constant called HWSPIClockModeSCRIPT. Then, you can use this in your new library.

Example in GLCD_ILI9341.h ( see also glcd_ssd1331.h etc. etc.)

#ifdef ILI9341_HardwareSPI
  ' harware SPI mode
  asm showdebug SPI constant used equates to HWSPIMODESCRIPT
  SPIMode HWSPIMODESCRIPT, HWSPIClockModeSCRIPT
#endif

You will not need to access CKP etc once you HWSPIClockMode working.

---

Re the typo. Are you using the latest hwspi.h - should be `15/02/24 ... on line 53'

Evan

[Picsi]

Hello Evan,
thank you very much for the quick reply.

And especially for the great work on GC-BASIC. :)

I have already tested HWSPIClockMode, as I wrote above.
However, with the hwspi.h from probably 28/09/24 (the file says 28/09/29), as it was included with GCstudio.

Can I get the latest hwspi.h from somewhere without having to reinstall the whole suite?

And did you perhaps mean 15/02/25, not 15/02/24?

[Anobium]

You have updated to the latest GCSTUDIO?

[Picsi]

I would have liked to test only the new hwspi.h first.
But well, I will install the new suite. But that will take time, because I will create a backup first.

I'll get back to you. Thank you very much!

[Picsi]

First i used only the new hwspi.h along with the old environment: Problem unchanged.
Then I completely uninstalled GCstudio and installed the version I downloaded today. The problem is still the same.

Current code:

#CHIP 18F16Q41,16
#INCLUDE <lowlevel\hwspi.h>

#STARTUP InitPPS, 85
#DEFINE PPSToolPart 18F16Q41

SUB InitPPS
UNLOCKPPS
  SPI1SDIPPS = 0x000C
  RB6PPS = 0x001B
  SPI1SCKPPS = 0x000E
  RB5PPS = 0x001C
  RC6PPS = 0x001D
  SPI1SSPPS = 0x0016
LOCKPPS
END SUB

#DEFINE SPI_HardwareSPI
#DEFINE HWSPIMode MASTER
#DEFINE HWSPIClockMode 3
SPIMode (Master, 3)

#DEFINE SPI_SCK   PORTB.6
#DEFINE SPI_DO    PORTB.5
#DEFINE SPI_DI    PORTB.4
#DEFINE SPI_DC    PortC.1
#DEFINE SPI_CS    PortC.6
#DEFINE SPI_RESET PortC.2

DIR SPI_SCK   OUT
DIR SPI_DO    OUT
DIR SPI_DI    IN
DIR SPI_DC    OUT
DIR SPI_CS    OUT
DIR SPI_RESET OUT

DIM I AS BYTE

DO
'SPITransfer 0x75, I
FastHWSPITransfer 0x75
LOOP

I have attached a screenshot of the logic analyzer.

BTW: The small bug in hwspi.h is still there, but now in line 177.

[Anobium]

Good spot on the SS usage on the Q41.

We should adapt the HWSPI library to support. It will be easy for me to do.

Would you test if I modify?

[Picsi]

Here is a screenshot of my software SPI with which the display works:

[Picsi]

Hi Evan,

i noticed that the 18F16Q41 is the only one of the PICs I have here that seems to support hardware CS (SS) at the output side.

I have therefore tested the following:

1) Removed the hardware control for SS from the PPS configuration: Unchanged, except that I can now control SS properly manually.

2) Used a 16F18326 instead of the 18F16Q41. Pin assignment adapted to the possibilities. No hardware SS here either:
It works! The second parameter of SPIMode is evaluated correctly, the PIC does all 4 modes correctly.
But

SPIMode Master
#DEFINE HWSPIClockMode 3

does not work, you have to set the CPOL/CPHA mode directly with ‘SPIMode Master,x’.

3) To test whether it is due to the pin assignment I used (which corresponds to the standard assignment as defined in the data sheet):
Used the above pin assignment of the 16F18326 for the 18F16Q41: Does not work, always CPOL=0, CPHA=0.

So it seems to be a problem with the 18F16Q41 or the corresponding data.

I hope this information will help you with troubleshooting.

With kind regards.

[Picsi]

As an old (!) assembler programmer (many, many years ago, on a completely different CPU) and after a look at the data sheet i added

  bsf 0x085,2,1 'set SSP
  bsf 0x085,5,1 'set SKP
  bcf 0x085,6,1 'clear CKE

The PIC now does what it is supposed to do! And yes, I have to clear CKE, which also corresponds to the timing diagram in the datasheet. CKE seems to be an inversion of CPHA?

Then I looked at the .asm file generated by GCB:

  bcf SPI1CON1,CKE,BANKED
  bcf SPI1CON1,CKP,BANKED
  btfss SPICLOCKMODE,0,ACCESS
  bsf SPI1CON1,CKE,BANKED
  btfsc SPICLOCKMODE,1,ACCESS
  bsf SPI1CON1,CKP,BANKED
  movlw 64
  movwf SPI1CON1,BANKED

If I understand this correctly, CKP and CKE are deleted first and possibly set according to the SPICLOCKMODE bits. Therefore CKP is correct, but CKE is inverted.
But then the whole register is overwritten with 64 = 0b01000000, so that only CKE is set.
And SSP, which is 1 by default, is overwritten with 0, which sets SS to unusual L-active. So all three bits are in the wrong state for my purpose.

P.S.:
The above also works with aliases:

  bsf SPI1CON1,SSP,BANKED
  bsf SPI1CON1,CKP,BANKED
  bcf SPI1CON1,CKE,BANKED

[Picsi]

Addendum:

SPI1CON1.SSP = 1
SPI1CON1.CKP = 1
SPI1CON1.CKE = 0

This also works. This version was missing .SSP, which I was now able to derive from Assember and the data sheet.

[Anobium]

@PICSI.

You gave me a great really insight regarding the Q41.

My research

The 18FQ and 18FK42 and 18FK83 chips all support PPS SPI Client Select Input/Output Polarity Control.

The GCBASIC library, currently, does not support the SPI Client Select Input/Output Polarity Control. This is because I had not spotted this bit! :-)

How should this work

We can set the SPI Client Select Input/Output Polarity Control bit if it exists ( Q, K42, K83 ) and this will only have an impact if the user has set the PPS.

Can you help me work out a good method to resolve?

Any method should be easy for a user.

1. We can add a check that SPI1SSPPS is not equal to zero ( on these chips ) and then set the SSP to some constant ? This way the user defines the PPS, the library checks that SPI1SSPPS <> 0 and then set .SSP= SPI_SS_POLARITY. We can add a script that does all the magic to set the .SSP = 1 as the default.
2. We can that SPI1SSPPS is not equal to zero and simply state this is not supported. And, the user can resolve manually.
3. Resolve some other way. Your thoughts?

[Picsi]

@ Anobium:

My suggestion, if feasible, would be the following:

You could evaluate an additional bit in the second argument of SPIMode:
The function of bits 0 and 1 remains as before (apart from any previous bugs) and sets CKP and CKE of SPI1CON1 corresponding to CPOL and CPHA.

Bit 2 sets SSP of SPI1CON1 and thus controls the polarity of the hardware SS. But only if the PIC type supports this, not that this bit has a different function on another PIC (in the future) (no idea if this happens).

You can do this depending on the default value of SSP and the PPS config. But is that even necessary? If I remember correctly, the SSP bit does not matter as long as the function is not assigned to a port bit via PPS-config, because the PIC does not do hardware SS anyway. But I can't judge that for sure, as I'm a PIC novice.

In addition, the user can influence each bit individually with SPI1CON1.CKP, SPI1CON1.CKE and SPI1CON1.SSP, which already works.

[Anobium]

I think the evaluation of BIT 2 would work.

Re the influence... this will not work, in every case, the setting of the SSP1CON1 bits would happen after the initialisation process. So, the program would initialise the SPI device with the potentially incorrect polarity, unless the user put the SSP1CON1 bits in a #STARTUP routine.

I will revise the library now. And, post a change later.

[Picsi]

And that reminds me:
What about SPI2? The Q41 has two hardware SPIs, the corresponding registers exist a second time, SPI2CON0, SPI2CON1 and so on. So you would need a second SPI mode instruction to address them? And a second SPITransfer, FastHWSPITransfer etc., or a parameter for all of them to select the channel?

It would be nice if the second SPI channel could also be used, perhaps one as a master and the other as a slave. But that would be on a completely different scale to this...

[Anobium]

We have worked offline to resolve and enhance SPI operations for the 18FQ and 18FK42 and 18FK83 chips with PPS SPI Client Select Input/Output Polarity Control.

See https://ko-fi.com/post/Hardware-SPI-Update-Support-for-Second-SPI-Channel-H2H11BZ6S7

SPI now works on both SPI channels.