 |
 |
| View previous topic :: View next topic |
| Author |
Message |
akin54
Joined: 11 Jan 2021
Posts: 7
|
| PIC18F47Q43 SPI communication problem |
 Posted: Fri Nov 12, 2021 7:47 am |
 |
|
| Code: | #use spi (MASTER, CLK=PIN_D0, DI=PIN_D3, DO=PIN_D1, BAUD=4000000, MODE=0, BITS=8, STREAM=SPI_1)
setup_spi(SPI_MASTER | SPI_H_TO_L );
output_low(pin_d0);
spi_write(0x11);
spi_write(0x00);
output_high(pin_d0);
|
I want to adjust the MCP41010 digital potentiometer with these codes. But there is no play in the digital potentiometer. I tried by sending 8 bit data like 0x00, 0xFF. None of them were played. I think I made a mistake in the codes because it is a new processor.
_________________
@electsoftware |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Fri Nov 12, 2021 8:16 am |
|
|
2nd spi write data is 0, so pot wiper would be zero ?
Have you got the pot wired to VDD and VSS ?
What speed is the PIC ?
Does the PIC flash an LED at 1Hz ?
Is the spi 'mode' correct for that device ? there's TWO bits to control mode, so 4 different 'modes'.
Really you need to post a complete, compilable program |
|
|
akin54
Joined: 11 Jan 2021
Posts: 7
|
|
| Posted: Fri Nov 12, 2021 8:23 am |
|
|
| temtronic wrote: | 2nd spi write data is 0, so pot wiper would be zero ?
Have you got the pot wired to VDD and VSS ?
What speed is the PIC ?
Does the PIC flash an LED at 1Hz ?
Is the spi 'mode' correct for that device ? there's TWO bits to control mode, so 4 different 'modes'.
Really you need to post a complete, compilable program. |
| Code: | #pin_select SCK1=PIN_B0
#pin_select SDI1=PIN_B2
#pin_select SDO1=PIN_B1
#use spi (MASTER, SPI1, MODE=1, BITS=8, STREAM=SPI_1)
output_low(pin_b0);
spi_write(0x11);
spi_write(0x00);
output_high(pin_b0);
|
I created a new project and got such a code from the SPI settings, but it still didn't work.
_________________
@electsoftware |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19549
|
|
| Posted: Fri Nov 12, 2021 12:49 pm |
|
|
Using #USE SPI, you should be using spi_xfer, not spi_read or spi_write.
Basically the spi_read, write and setup_spi, are the 'old' commands.
#USE, with spi_xfer are the new commands. You should not mix them (they often don't work correctly if you do). If you look in the manual, each of
the two types, are kept separate, the manual entry for spi_write does not at
any point refer to #use, while #use only refers to xpi_xfer.
Now, setup_spi, on a modern chip with PPS, does not know about PPS, and
how to control the TRIS for it's pins. So use #USE, with the PPS settings as
you show, but use spi_xfer to perform the transfers. |
|
|
akin54
Joined: 11 Jan 2021
Posts: 7
|
|
| Posted: Fri Nov 12, 2021 1:55 pm |
|
|
| Ttelmah wrote: | Using #USE SPI, you should be using spi_xfer, not spi_read or spi_write.
Basically the spi_read, write and setup_spi, are the 'old' commands.
#USE, with spi_xfer are the new commands. You should not mix them (they often don't work correctly if you do). If you look in the manual, each of
the two types, are kept separate, the manual entry for spi_write does not at
any point refer to #use, while #use only refers to spi_xfer.
Now, setup_spi, on a modern chip with PPS, does not know about PPS, and
how to control the TRIS for it's pins. So use #USE, with the PPS settings as
you show, but use spi_xfer to perform the transfers. |
| Code: |
#pin_select SCK1=PIN_B1
#pin_select SDI1=PIN_B2
#pin_select SDO1=PIN_B3
#use spi (MASTER, SPI1, MODE=1, BITS=8, STREAM=SPI_1)
int i = 34;
output_low(pin_b0);
spi_xfer(i);
output_high(pin_b0);
|
Can I write this code 34 value to my connected integration? So do I need to make low and high from the clock pin? I knew it as spi_write. Thank you.
_________________
@electsoftware |
|
|
Woody
Joined: 11 Sep 2003
Posts: 83
Location: Warmenhuizen - NL
|
|
| Posted: Tue Nov 16, 2021 4:42 am |
|
|
I would set the mode to 0, the baud to 500000 (5 zero's, not 6), remove the SDI1= as this is not needed, make sure that PIC/PIN_B1 is connected to MCP/SCK and PIC/PIN_B3 is connected to MCP/SI, and (if they're on your chip) check that MCP/RS and MCP/SHDN are high.
Then see if that works.
You do not have to do anything to the clock pin; the SPI hardware does that for you. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19549
|
|
| Posted: Tue Nov 16, 2021 11:04 am |
|
|
OK. First thing is mode 1, is wrong. The chip supports 0,0, and 1,1. Now
these are in a different format to the basic mode numbers, Look at the
Wikipedia page about SPI mode numbers. 0,0 is mode 0. 1,1 is mode 3.
Then if you are giving the stream a name, use it in the spi_xfer. It'll
probably work without the name, but 100% better to use the names
when using these functions. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19549
|
|
| Posted: Wed Nov 17, 2021 7:09 am |
|
|
| Code: |
#pin_select SCK1=PIN_B1
#pin_select SDI1=PIN_B2
#pin_select SDO1=PIN_B3
#use spi (MASTER, SPI1, MODE=0, BITS=8, STREAM=SPI_1)
int i = 34, dummy;
output_low(pin_b0);
dummy=spi_xfer(SPI_1,i);
output_high(pin_b0);
|
Key difference here is reading the byte coming back.
This actually means nothing, but makes the command _wait_ till the
data has been clocked out/in. Problem otherwise is that the command
will return immediately, meaning you raise the CS before the data has
been clocked out.
This applies to spi_write as well, when using the hardware peripheral. |
|
|
Woody
Joined: 11 Sep 2003
Posts: 83
Location: Warmenhuizen - NL
|
|
| Posted: Thu Nov 18, 2021 3:30 am |
|
|
| Ttelmah wrote: |
Key difference here is reading the byte coming back.
This actually means nothing, but makes the command _wait_ till the
data has been clocked out/in. Problem otherwise is that the command
will return immediately, meaning you raise the CS before the data has
been clocked out.
This applies to spi_write as well, when using the hardware peripheral. |
Are you sure? You had me worried as I used this with a DAC a while ago, so I tested this with an 18F27Q43 on a breadboard; AFAICS spi_xfr does wait for the command to finish. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19549
|
|
| Posted: Thu Nov 18, 2021 7:35 am |
|
|
A compiler version thing. They changed things a little while ago,
when they added the new 'extra' spi_xfer functions (spi_data_is_in etc.).
Yes, the current compilers do now wait for the transfer to complete.
They have added the new spi_prewrite function to load the byte without
waiting.
The software SPI always waited. The early spi_xfer versions did not wait
if you did not read. The current versions do wait, unless you use prewrite.
I prefer to be 'safe' and reading the reply forces the wait....
It's worth also saying that a few versions ago, if you used spi_xfer it
resulted in less efficient code than spi_write. They always added the extra
code to support multi-byte transfers, even if you specified bits=8. However
on the latest compiler versions they have massively improved this and
now spi_xfer results in just as efficient code as spi_read and spi_write.  |
|
|
Woody
Joined: 11 Sep 2003
Posts: 83
Location: Warmenhuizen - NL
|
|
| Posted: Thu Nov 18, 2021 8:26 am |
|
|
| Ttelmah wrote: | The software SPI always waited. The early spi_xfer versions did not wait
if you did not read. The current versions do wait, unless you use prewrite.
I prefer to be 'safe' and reading the reply forces the wait....
|
I guess I was lucky then, although I probably would have found out had my DAC not worked as expected.
Thanks for explaining. You always manage to teach me something, even (or, especially) about stuff if I think I know all about it
Paul |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
