| View previous topic :: View next topic |
| Author |
Message |
Desert Leo
Joined: 08 Jun 2011
Posts: 7
|
| #pin_select for HW SPI problem |
 Posted: Thu Mar 11, 2021 5:33 am |
 |
|
MPLAB X IDE v5.30
CCS C v5.061
PIC24FJ1024GA606
| Code: |
#pin_select SCK1OUT = PIN_G7
#pin_select SDI1 = PIN_G6
#pin_select SDO1 = PIN_G8
#use spi(MASTER, SPI1, MODE = 0, BAUD = 1000000)
|
getenv("SPI1_CLK") return 14050 = PIN_G2
getenv("SPI1_DI") return 14051 = PIN_G3
getenv("SPI1_DO") return 14050 = PIN_G2
What I am missing? |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9255
Location: Greensville,Ontario
|
|
| Posted: Thu Mar 11, 2021 5:39 am |
|
|
I don't use that PIC, or any PPI ones but....
maybe #USE SPI ( ..), needs a 'use hardware' option ?
I've read hear that other PICs, you have to specify HW, otherwise the compiler creates SW to run the peripheral.
just a guess, without seeing rest of program or what error you're getting.
also maybe 1MHz is too fast for the attached peripheral device ?? |
|
|
Desert Leo
Joined: 08 Jun 2011
Posts: 7
|
|
| Posted: Thu Mar 11, 2021 5:54 am |
|
|
| Code: |
#pin_select SCK1OUT = PIN_G7
#pin_select SDI1 = PIN_G6
#pin_select SDO1 = PIN_G8
#use spi(MASTER, FORCE_HW, SPI1, CLK = PIN_G7, DO = PIN_G8, DI = PIN_G6, MODE = 0, BAUD = 1000000)
|
Same result.
Only:
| Code: |
#use spi(MASTER, FORCE_HW, SPI1, CLK = PIN_G7, DO = PIN_G8, DI = PIN_G6, MODE = 0, BAUD = 1000000)
|
Gives Error#99 Option invalid SPI unit not assigned, use #PIN_SELECT
In the same code #pin_select and #use rs232 select correct pins.
SPI peripheral is 23K640-I/SN (max 20MHz clock @ 3,0V) powered from 3,3V LDO. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19566
|
|
| Posted: Thu Mar 11, 2021 7:36 am |
|
|
The problem is that 'getenv', is a preprocessor command, returning the
default pin allocation. It knows nothing about PIN SELECT operations that
have been performed.
I don't know why you want to use getenv like this. Simplest way is to
make your own allocations for the PIN numbers, and then use these
allocations for your PIN SELECT operation, and the same allocations will
be right in place of whatever you are using getenv for here.
So something like:
| Code: |
#define SSP1CK PIN_G7
#define SSP1DI PIN_G6
#define SSP1DO PIN_G8
#PIN_SELECT SCK1OUT=SSP1CK
#PIN_SELECT SCK1IN=SSP1CK //Beware some chips need this selected
#PIN_SELECT SDI1=SSP1DI
#PIN_SELECT SDO1=SSP1DO
#use spi(MASTER, SPI1, MODE = 0, BAUD = 1000000)
//Then for whatever you were using the getenv for, you can just use
//SSP1CK etc..
|
Note that I setup the SCK1CKIN as well. On some chips the shift register
for input data is not clocked unless this is done. These are the ones where
the SPI allows separate input and output clocks. |
|
|
Desert Leo
Joined: 08 Jun 2011
Posts: 7
|
|
| Posted: Tue Mar 16, 2021 4:41 am |
|
|
Final result: getenv() is not working with parameters "SPIх_CLK", "SPIх_DI" or SPIх_DO", but with "UARTx_RX" and "UARTx_TX" is working perfect.
RPx pin mapping can be checked by reading RPINRх and RPORх registers. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9255
Location: Greensville,Ontario
|
|
| Posted: Tue Mar 16, 2021 6:04 am |
|
|
re: These are the ones where
the SPI allows separate input and output clocks.
hmm....curious.. does this allow you to clock in data faster than clocking out data ? Not too sure why anyone would want to ..... and do these PICs have 2 clock pins ?
just curious..new PICs are just too complcated ! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19566
|
|
| Posted: Tue Mar 16, 2021 8:15 am |
|
|
I think they are all PPS chips, so the clocks can be set to different pins.
The key is that the connection back to the incoming shift register is
separate to the obe to the outgoing register. So 'yes', it potentially
would allow different rates in different directions. However given that
on SPI a byte is normally clocked in while another is clocked out, how
the logic of the actual functions would work, gets scarey!...
I met is because like the original poster here, I just setup a single clock
and then found data was not being clocked back in.  |
|
|
Desert Leo
Joined: 08 Jun 2011
Posts: 7
|
|
| Posted: Tue Mar 16, 2021 8:37 am |
|
|
This
| Code: |
#pin_select SDI1 = PIN_G6
#pin_select SDO1 = PIN_G8
#pin_select SCK1OUT = PIN_G7
#use spi(MASTER, SPI1, MODE = 0)
|
SPI setup gives:
RPINR20 = 0b 00011010 00010101
6 of LS bits in MS byte (011010 = 26) set SPI_1_CLK_IN to RP26 (PIN_G7)
6 of LS bits in LS byte (010101 = 21) set SPI_1_DI to RP21 (PIN_G6)
RPOR9 = 0b 00000111 00000000
6 of LS bits in MS byte (000111 = 7) set RP19 (PIN_G8) to be SPI_1_DO
RPOR13 = 0b 00000000 00001000
6 of LS bits in LS byte (001000 = 8) set RP26 (PIN_G7) to be SPI_1_CLK_OUT.
So, in MSTER mode CLK_IN and CLK_OUT are connected together automatically by setup.
If in setup MASTER is replaced by SLAVE, only difference is that RPOR13 is cleared, so SPI_1_CLK_OUT is not connected.
By default RPINRx registers are set to 0x3F3F that corresponds to RP63 - out of valid RPx range and RPORx registers are cleared - not used.
Probably is possible to set CLK_IN and CLK_OUT to separate pins by directly writing in related registers after issuing OSCCON unlock sequence. This separation could be used for transmitting without receiving and receiving without transmitting. This is not my case. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19566
|
|
| Posted: Tue Mar 16, 2021 8:59 am |
|
|
You are slightly missing the point.
There are some chips, where this connection is not automatically made.
I hit one a little while ago, and found you had to make the clock in connection
as well as the clock out for it to work correctly.
So on the basis that it costs nothing to tell the compiler to make both, 'it is
safer' to get into the habit of always making both. Even if your chip does not
need this. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
