| View previous topic :: View next topic |
| Author |
Message |
SvenBraun
Joined: 19 Mar 2016
Posts: 29
|
|
 Posted: Sun Apr 10, 2016 12:03 pm |
 |
|
| asmboy wrote: | | The data sheet issue i refer to is the single or double command possibility. |
Are you referring to the Double SPI mode for SRAM?
Here is my program right now:
(the 32-bit writing was originally two 16-bit spi_xfer commands, both performed during the CS low section.)
| Code: | #device PIC18F4455
#include <18F4455.h>
#use delay(osc=48000000)
#use rs232(baud=115200, xmit=PIN_C6, rcv=PIN_C7, stream=UART)
#use SPI(MASTER, MODE=0, BAUD=200000, CLK=PIN_E0, DI=PIN_E1, DO=PIN_E2, BITS=32)
#define RESET PIN_C4
#define CS PIN_D3
#define TRIGGER PIN_D2
void main(void)
{
int size = 14;
unsigned int16 addr[14];
unsigned int16 val[14];
int i = 0;
setup_ccp1(CCP_OFF);
setup_ccp2(CCP_OFF);
setup_psp(PSP_DISABLED);
setup_comparator(NC_NC_NC_NC);
setup_adc(ADC_OFF);
setup_adc_ports(NO_ANALOGS);
output_high(CS);
output_high(Trigger); // Trigger
output_high(Reset); // Reset
// SPICONFIG
addr[0] = 0x0000;
val[0] = 0x0000;
// POWERCONFIG
addr[1] = 0x0001;
val[1] = 0x0000;
// CLOCKCONFIG
addr[2] = 0x0002;
val[2] = 0x0000;
// DDS_TW32
addr[3] = 0x003E;
val[3] = 0x0000;//(500>>8);
// DDS_TW1
addr[4] = 0x003F;
val[4] = 0xFF00;//(500 & 0xFF)<<8;
// DAC_DGAIN
addr[5] = 0x0035;
val[5] = 0x0400;
// DACDOF
addr[6] = 0x0025;
val[6] = 0x0000;
// DAC_CST
addr[7] = 0x0031;
val[7] = 0xFF00;
// DACRSET
addr[8] = 0x000C;
val[8] = 0x801A;
// WAV_CONFIG
addr[9] = 0x0027;
val[9] = 0x0001; //0x0031;
// PAT_TYPE
addr[10] = 0x001F;
val[10] = 0x0000;
// RAMUPDATE
addr[11] = 0x001D;
val[11] = 0x0001;
// PAT_STATUS
addr[12] = 0x001E;
val[12] = 0x0001;
// RAMUPDATE
addr[13] = 0x001D;
val[13] = 0x0001;
while(TRUE)
{
for(i=0; i< 14; i++)
{
output_low(CS);
spi_xfer((addr[i] << 16) && val[i]);
output_high(CS);
}
output_low(Trigger);
while(TRUE)
{
}
}
} |
|
|
 |
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Sun Apr 10, 2016 12:44 pm |
|
|
before i go further
this
| Code: |
spi_xfer((addr[i] << 16) && val[i]); |
does not MAKE SENSE ON SEVERAL COUNTS
1- YOU ARE NOT ASSIGNING THE OUTPUT OF SPI_xfer anywhere
in spite of the masking.
2- only certain parts of the command structure "clock out" the bits you want to receive. and the code you have wont get them...
3- you are stuck sending 16 bits of data in a 32 bit variable transmission situation. between your low-to-high CS time- you are sending just the 16 bits of the var passed as the argument -
Your code STILL does NOT do what i think you want it to do
check the ccs manual before going further
Recall that the part returns data at different times
and you need 32 bits of transfer not 16 typically
look carefully at the heading SPI on page 18 of the data sheet CLOSELY and see the 32 clocks ??
PAGE 18 of the data sheet is an area you need to understand better.
it is tricky !!
i think you are having DEEP trouble comprehending the Analog devices data sheet for the part too. it is an unusually badly written data sheet IMHO. |
|
|
SvenBraun
Joined: 19 Mar 2016
Posts: 29
|
|
| Posted: Sun Apr 10, 2016 1:05 pm |
|
|
| asmboy wrote: | before i go further
this
| Code: |
spi_xfer((addr[i] << 16) && val[i]); |
does not MAKE SENSE ON SEVERAL COUNTS
1- YOU ARE NOT ASSIGNING THE OUTPUT OF SPI_xfer anywhere
in spite of the masking.
2- only certain parts of the command structure "clock out" the bits you want to receive. and the code you have wont get them...
3- you are stuck sending 16 bits of data in a 32 bit variable transmission situation. between your low-to-high CS time- you are sending just the 16 bits of the var passed as the argument -
Your code STILL does NOT do what i think you want it to do
check the ccs manual before going further
Recall that the part returns data at different times
and you need 32 bits of transfer not 16 typically
look carefully at the heading SPI on page 18 of the data sheet CLOSELY and see the 32 clocks ??
PAGE 18 of the data sheet is an area you need to understand better.
it is tricky !!
i think you are having DEEP trouble comprehending the Analog devices data sheet for the part too. it is an unusually badly written data sheet IMHO. |
That is reassuring if other people think it's not very clear; as someone who has never worked with programming a peripheral like this, but seeing some examples from previous projects, I thought I was going insane.
I will be heading back to my lab area in a little bit. I will mull over what you said, but to get some clarification:
1 - Are you saying the information needs to be stored in a 32-bit variable?
2 - I'm not comprehending. Can you rephrase your statement?
3 - (see 1) |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Sun Apr 10, 2016 1:43 pm |
|
|
as simple as i can say it
SPI_xfer will not work as YOU ARE USING it in part
depending on how you are connected re pins 1 and 7
since for some commands on combined SDIO you need to
switch TRIS after SPI CLOCK 16 ( R/W+15 address SEND is complete )
on 4 wire SPIO which i hope you are using it is simpler
please look at data sheet p18 table 12
LOWER /CS
send ONE 32 bit command which has 16 bits of address MSB first
followed
16 bits of DATA
a key problem is that the only argument you send is the 16 bit address in your code which is just the first 16 bits
consider transferring a MAKE32() of your address AND data
and assign the output of your spi_xfer to a 32bit value and
shift/isolate/grab the part you want FROM the AD sig gen chip after your transmission to it.
more like
| Code: | | your_recv_int32=xfer_spi(make32(your_addr16,your_command16)); |
and don't forget to mask the appropriate R/W bit onto the address before sending |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Sun Apr 10, 2016 1:46 pm |
|
|
WHAT is the goal of this project?
the AD9102 is at it's best as an arbitrary function generator - but no great prize even at that.
If i knew what your intended USE for the signals you want to generate -
i could be much more specific.......
what is the GOAL of the full design ?? |
|
|
SvenBraun
Joined: 19 Mar 2016
Posts: 29
|
|
| Posted: Sun Apr 10, 2016 2:39 pm |
|
|
| asmboy wrote: | as simple as i can say it
SPI_xfer will not work as YOU ARE USING it in part
depending on how you are connected re pins 1 and 7
since for some commands on combined SDIO you need to
switch TRIS after SPI CLOCK 16 ( R/W+15 address SEND is complete )
on 4 wire SPIO which i hope you are using it is simpler
please look at data sheet p18 table 12
LOWER /CS
send ONE 32 bit command which has 16 bits of address MSB first
followed
16 bits of DATA
a key problem is that the only argument you send is the 16 bit address in your code which is just the first 16 bits
consider transferring a MAKE32() of your address AND data
and assign the output of your spi_xfer to a 32bit value and
shift/isolate/grab the part you want FROM the AD sig gen chip after your transmission to it.
more like
| Code: | | your_recv_int32=xfer_spi(make32(your_addr16,your_command16)); |
and don't forget to mask the appropriate R/W bit onto the address before sending |
Alright. I've made the changes you described: I now send the data as a single 32-bit transfer, using a method that returns a 32-bit integer.
I verified that it is sending 32 clock cycles, and that the data from my PIC's SDO is correct - the first 16 bits are the address, and the last 16 bits are the data. (I would attach some screenshots of the oscilloscope, but I can't find a flash drive.)
However, I still do not see meaningful output.
The goal is to generate a sinusoidal wave through the differential current outputs, at any frequency.
Unfortunately, I am not at liberty to discuss the purpose of the design beyond that I need to generate a sinusoidal wave through the differential output of the AD9102. |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Sun Apr 10, 2016 6:21 pm |
|
|
sine wave ? depending on frequency span -parts like the AD9833 do that with a simple driver - and very low cost too. BTW: your Fmax ?
and the code that is still not working is ?????? |
|
|
SvenBraun
Joined: 19 Mar 2016
Posts: 29
|
|
| Posted: Mon Apr 11, 2016 11:32 am |
|
|
The AD9102 is required for this project.
I'm using a 20 MHz clock (single-ended), being sent to CLKP, with CLKN grounded via .1uF capacitor.
Last edited by SvenBraun on Mon Apr 11, 2016 12:37 pm; edited 1 time in total |
|
|
SvenBraun
Joined: 19 Mar 2016
Posts: 29
|
|
| Posted: Mon Apr 11, 2016 11:48 am |
|
|
I just noticed in Figure 33 that in 4-wire (which it defaults to), the reads are performed on the SDIO line, while the writes have the address on SDIO, and the data on SDO/SDI2/DOUT.
Is spi_xfer a 3-wire operation? Or can it be used in 4-wire?
| CCS Manual wrote: | | the spi_xfer() function can be used to both transfer and receive data on the SPI bus. |
leads me to believe that it uses a single line for data transfer. |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Mon Apr 11, 2016 1:21 pm |
|
|
| Quote: |
When the first bit of this command byte is a logic low (R/W bit
= 0), the SPI command is a write operation. In this case, SDIO
remains an input; see Figure 30.
When the first bit of this command byte is a logic high (R/W bit
= 1), the SPI command is a read operation. In this case, data is
driven out of the SPI port as shown in Figure 31 and Figure 33.
|
that's the true behavior of the AD9102
so i would not say
It default's
since it is determined by YOUR command structure
and that governs I/O.
With no app notes , the unusually poor ( BY AD standards) data sheet and a raft of useless features ( for sine generation) it IS going to be a misery to program and debug - no matter who does it.
and i have no appetite for guessing what the problem really is - as you post so little code as to be essentially meaningless for a complete and serious analysis of where the fault lies..
you seem to believe all you need do to get answers is post the minimum code related to your problem- but is increasingly clear that this problem may be a bit beyond your present skill set.
Consider this point: even IF your register read/write code is working - the ORDER of those operations might very much matter too. A whole other area where even if register ops are working -the order they are done in - may not satisfy you.
I would never let myself be forced to use that part without awfully good compensation for the development time. [/quote] |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Apr 11, 2016 1:24 pm |
|
|
| SvenBraun wrote: |
Is spi_xfer a 3-wire operation? Or can it be used in 4-wire?
CCS Manual wrote:
the spi_xfer() function can be used to both transfer and receive data on the SPI bus.
leads me to believe that it uses a single line for data transfer.
|
It does not.
Look in the 18F4455 data sheet, at this diagram in the SPI section:
| Quote: | | FIGURE 19-2: SPI™ MASTER/SLAVE CONNECTION |
It shows what the clock and data lines do in 4-wire SPI. (\CS not shown)
The spi_xfer() function does this too.
18F4455 data sheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/39632e.pdf |
|
|
SvenBraun
Joined: 19 Mar 2016
Posts: 29
|
|
| Posted: Mon Apr 11, 2016 6:49 pm |
|
|
asmboy: I appreciate the attempts to help resolve my issue.
I went through AD's application notes yesterday, and likewise didn't see any help.
PCM programmer: Thanks for pointing that out. |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Tue Apr 12, 2016 10:37 am |
|
|
i've worked with DDS parts from AD a lot -
and not kidding when i say
i would never use that part just for sine output, lacking HUGE financial incentive. If you really have no choice, your work may be cut out for you.
a n d
Since you aren't able to be forthcoming about even your Fmax
( a pretty secret detail huh ??)
as a parting word- since this is obviously design stage -
why not consider
for Fmax =<12 mhz 1 hz resolution AD9833 -
http://www.ccsinfo.com/forum/viewtopic.php?t=53564
For Fmax 60mhz 2 hz resolution AD9850
http://www.ccsinfo.com/forum/viewtopic.php?t=47110&highlight=ad9850 |
|
|
SvenBraun
Joined: 19 Mar 2016
Posts: 29
|
|
| Posted: Tue Apr 12, 2016 2:40 pm |
|
|
Just noticed that there was a new response. I do have a new update:
I noticed that the registers are saving correctly. I verified all of the registers listed in my previous code post, and they are all matching what I expect.
I modified my input by just saving my values as 32-bit originally (ignoring the Make32 function for now). I also added a read command next to each write command. From there, I did a sequence of one write, followed by one read.
I saved my scopes, but do not know if and where I should upload them. (If it's any relevance to you, I can post them.)
My sequence is as follows from a post over at ez.analog.com (here)
I am double-checking my connections, so we'll see if it's really a wiring issue, or missing a step in the pattern generation. |
|
|
SvenBraun
Joined: 19 Mar 2016
Posts: 29
|
|
| Posted: Tue Apr 12, 2016 5:47 pm |
|
|
| asmboy wrote: | i've worked with DDS parts from AD a lot -
and not kidding when i say
i would never use that part just for sine output, lacking HUGE financial incentive. If you really have no choice, your work may be cut out for you.
a n d
Since you aren't able to be forthcoming about even your Fmax
( a pretty secret detail huh ??)
as a parting word- since this is obviously design stage -
why not consider
for Fmax =<12 mhz 1 hz resolution AD9833 -
http://www.ccsinfo.com/forum/viewtopic.php?t=53564
For Fmax 60mhz 2 hz resolution AD9850
http://www.ccsinfo.com/forum/viewtopic.php?t=47110&highlight=ad9850 |
Is there an issue with my DDS model, excluding lack of documentation/support? |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
