 |
 |
| View previous topic :: View next topic |
| Author |
Message |
picj1984
Joined: 01 Mar 2010
Posts: 73
|
| [SOLVED] Trouble interfacing PIC16F1509 with AD5263 |
 Posted: Mon May 24, 2021 1:17 pm |
 |
|
Hi all. Well, it's happened again. I've spent a full week trying to get something simple to happen and I can't seem to figure it out so I'm here. I'm using compiler V4.140. I'm trying to get my PIC16F1509 to change the AD5263 digipot value but I can't get anything to happen.
From what I can tell, the PIC is doing everything I've told it to do. Here's how I'm configuring the SPI:
| Code: |
#include <16f1509.h>
#fuses HS, NOWDT, NOLVP, PROTECT
#device ICD=TRUE
#device ADC=10
#use delay(clock=16000000, int)
#use rs232(UART1, baud=31250,parity=N,stop=1,bits=8, ERRORS)
#use spi(MASTER, IDLE=0, SAMPLE_RISE, SPI1, FORCE_HW, ENABLE=PIN_C6, STREAM=STREAM1, BAUD=400000)
|
This is how it looks on my scope. This looks good and normal to me but what is throwing me off a little bit is how the CS pin is low waaaay before the CLK starts getting generated which seems at odds with the timing diagram in the AD5263. see that here:
It seems from the datasheet that CLK isn't supposed to go low until the CLK is already doing it's thing? I don't know, I'm probably grasping at straws here but I'm at a point where I've read the datasheets many times and this seems to be the only thing I can find where there could be an issue. Anyway, just wanted to see if anyone knows or has any advice as to how to move forward. I also have a support email in with Analog Devices.
Last edited by picj1984 on Wed May 26, 2021 1:08 pm; edited 2 times in total |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon May 24, 2021 1:53 pm |
|
|
Show us your code that is doing the spi_xfer() to the AD chip.
Show us the whole loop code. |
|
|
picj1984
Joined: 01 Mar 2010
Posts: 73
|
|
| Posted: Mon May 24, 2021 2:07 pm |
|
|
the stuff commented out is just random things I've been trying to try and get something to happen.
From what I can tell, it's impossible to get spi_xfer to do anything besides a multiple of 8 bits (even though it lets you put in, say 10 bits, which is what the AD5263 wants).
Anyway, all that shouldn't be an issue because according to the AD5263 datasheet if you send 16 bits it'll just ignore the first 6 bits after CS comes back high (or at least that's how I'm interpreting it).
| Code: |
while(1)
{
//spi_xfer(STREAM1,0b0011111111,10);
//spi_xfer(STREAM1,0b0000000010101010,16);
//spi_xfer(STREAM1,0b0000001111111111,16);
//spi_xfer(STREAM1,0b000000000000000000000011,24);
spi_xfer(STREAM1,0,10);
delay_ms(1000);
}
}
|
I'm just sending a "zero" as my data because I'm trying to get something to happen at address 0, but I can never get it to change to anything besides the midpoint it boots up at (~25k... half of the 50k pot i'm using). |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon May 24, 2021 2:54 pm |
|
|
Try doing it like this, with the changes shown in bold below:
| Quote: | #use spi(MASTER, BITS=10, FORCE_SW, IDLE=0, SAMPLE_RISE, SPI1, ENABLE=PIN_C6, STREAM=STREAM1, BAUD=400000)
//=====================================
void main()
{
while(TRUE)
{
spi_xfer(STREAM1, 0b0010101010, 10);
delay_ms(1000);
}
}
|
Make sure the FORCE_HW is removed. |
|
|
picj1984
Joined: 01 Mar 2010
Posts: 73
|
|
| Posted: Mon May 24, 2021 3:38 pm |
|
|
| OK I just tried that I am indeed seeing 10 bit transfers on the scope now. Very cool. Still, the resistance on the 0 address of AD5263 is just staying the same. I think I need to take another look at the hardware / connections but if you have anything else you think I should try on the PIC end of things let me know. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon May 24, 2021 6:03 pm |
|
|
Can you post a schematic ?
What are your connections to all the pins on the AD5263 ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Mon May 24, 2021 11:43 pm |
|
|
spi_xfer can send any number of bits you want. _Provided you use software
SPI_. The point is the PIC hardware SPI port can only send multiples
of eight bits.
Now honestly the easiest way to get 10 bits then is to use software SPI.
I'd also operate CS myself rather than using the ENABLE setting.
This also then means that the PIC SDI pin becomes available to do
something else.
So:
| Code: |
#include <16f1509.h>
#fuses HS, NOWDT, NOLVP, PROTECT
#device ICD=TRUE
#device ADC=10
#use delay(clock=16000000, int)
#use rs232(UART1, baud=31250,parity=N,stop=1,bits=8, ERRORS)
#define CLOCK PIN_B6
#define DATA_OUT PIN_C7
#define SELECT PIN_C6
#use spi(MASTER, DO=DATA_OUT, CLK=CLOCK, BITS=10, FORCE_SW, MODE=0, STREAM=STREAM1, BAUD=400000)
//=====================================
void main()
{
output_high(SELECT);
delay_ms(10);
while(TRUE)
{
output_low(SELECT); //select the chip
spi_xfer(STREAM1, 0b0010101010, 10);
output_high(SELECT);
delay_ms(1000);
}
}
|
Now this is to address channel 0, and assumes that DIS pin is pulled low.
To use the hardware SPI, has the disadvantage of wasting the SDI pin on
the PIC, and then means you would have to do 16bit transfers with the
required data as the last ten bits sent for the transfer. |
|
|
picj1984
Joined: 01 Mar 2010
Posts: 73
|
|
| Posted: Wed May 26, 2021 1:10 pm |
|
|
| It was a very, very dumb hardware thing. There's a reset pin on the AD5263 that I thought had a pull-up on it but it needed to be tied high. I *really* appreciate y'all helping me and am pleased with how much I've learned about SPI (specifically the software options) through this frustration. Thank you so so much. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Wed May 26, 2021 11:11 pm |
|
|
Good. At least you got there once PCM pointed out how to get 10bit operation.
It sounded like a hardware problem. Lesson is to never 'assume' pins will
pull up/down.... |
|
|
picj1984
Joined: 01 Mar 2010
Posts: 73
|
|
| Posted: Thu May 27, 2021 1:00 pm |
|
|
| Ttelmah wrote: | Good. At least you got there once PCM pointed out how to get 10bit operation.
It sounded like a hardware problem. Lesson is to never 'assume' pins will
pull up/down.... |
yes, and a very good lesson indeed. |
|
|
picj1984
Joined: 01 Mar 2010
Posts: 73
|
|
| Posted: Tue Jun 22, 2021 3:02 pm |
|
|
| Ttelmah wrote: | Good. At least you got there once PCM pointed out how to get 10bit operation.
It sounded like a hardware problem. Lesson is to never 'assume' pins will
pull up/down.... |
I've got one more question on this... I guess I just assumed that it was pretty much always preferable to use these types of things in "hardware" mode (thinking it makes things easier on the PIC somehow with performance)... what (if any) are the downsides to using it in "software" mode... apologies in advance if this is documented elsewhere I just thought I'd ask. Thx!! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9232
Location: Greensville,Ontario
|
|
| Posted: Tue Jun 22, 2021 4:11 pm |
|
|
'bit banging' aka 'software mode' will usually not allow you interrupt capability, unless you play 'tricks' and even then, you're tying up the PIC to do 100% of the 'timing' needed for bits and bytes....
Depending on the hardware peripheral there may be other features you can't access.. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Thu Jun 24, 2021 12:14 am |
|
|
However (as is seen here), the software modes will often give extra
features (for example the ability to generate 'open collector' drives on
RS232, on chips that don't offer this), and in many cases the costs will
be tiny.
However the problems/costs are much more significant on asynchronous
communications than on synchronous. So I2C, and SPI, do not 'mind'
a momentary break in things on the master. However RS232 does. Then
the receive operations for these, are almost impossible to handle without
the hardware. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9232
Location: Greensville,Ontario
|
|
| Posted: Thu Jun 24, 2021 4:46 am |
|
|
hmm, reminds me of an early Microchip apnote using a small PIC in a 'mouse'. No HW UART in the small PIC, so 'bitbanging' was the only way.
What was clever, was the use of the 'dead time' between the rising edge and falling edge of a 'bit', to check the status of the left and right buttons, embed the result into the byte going to the PC.
Normally you'd set the pin high, run a delay loop, then set the pin low. The programmer found a way to do 'other stuff' instead of just wasting time.
It does requires knowledge of instruction set timings, it does show that sometimes 'bit banging' can be more useful than using an internal peripheral depending on the application. |
|
|
|
|
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
