I can't know how my reply go here.....
>Jeff:
>Thanks very much for your reply!
>The first question: “If the ADCs and DACs are connected to EMIF, then why
do you need additional GPIO signals? To what pins are the GPIO signals
connected?”
> The ADC we used is MAXIM1317. Its reference pdf is:
>http://datasheets.maxim-ic.com/en/ds/MAX1316-MAX1326.pdf
>The DAC we used is AD5344. Its reference pdf is:
>http://www.analog.com/static/imported-files/data_sheets/AD5334_5335_5336_5344.pdf
>From that we know that the ADC needs control signals such as /CS /Convst /RD
/EOLC, so we configure Mcbsp as GPIO to send these signals. For example, FSX0
and CLKX0 are configured as /RD and /CS of ADC respectively, FSR0 and CLKR1 are
configured as DAC’s /WR and /LDAC respectively. According to ADC timing,
DSP can be programmed to send these control signals one by one. Then ADC can
work. We searched TMS320C6000 DSP EMIF Reference Guide and found that EMIF
couldn’t send these control signals. We only used EMIF’s data line
ED[0:13]. Above this is the initial thinking, is it right? But now when we use
EMIF, I find /CEn should be connected to ADC/DAC’s /CS to select DSP
memory space. I can’t connect CLKX0 pin and /CEn pin both to the same /CS
of ADC. That’s my puzzle.
>The second question: “Well, you have to both read and write the
ADCs/DACs, correct? Normally either /AWE or /ARE is connected (usually just one
is needed).”
>Yes, ADC and DAC are all both read/ written. Why only connect /AWE or /ARE?
According to my understanding, /AWE is active-low write strobe for asynchronous
memory interface, /ARE is Active-low read strobe for asynchronous memory
interface. I think we should use /ARE after ADC has finished sampling and use
/AWE after DSP has got a result, so we should make use of both. Is it correct?
If only connect /ARE, how to write to DAC?
>“How do you plan to control the WR and RD signals on the ADC and DAC
chips? Using the GPIO pins? That could work, but it's going to make your
code very slow.”
>Yes, using GPIO to control them. How to avoid making code slowly?
>The last question: “Are you saying you left the /AWE and /ARE pins
NC?”
>Yes, on designed ADC/DAC board /AWE and /ARE pins are both NC. If connect /AWE
to /WR of DAC, the original FSR0 (GPIO pin) should be disconnected? /CEn pin of
EMIF should be connected also? When DSP is powered, /CE0 /CE1 /CE2 /CE3 pins in
EMIF are all about 3.3V high level. Is it right? In fact, I tried to connect
/AWE to /WR of DAC without disconnecting FSR0 yesterday, the low level of /WR
was 2.81V and the result was wrong.
>
>> Hi everyone! I'm a newcomer on using TI DSP. Now I'm working on a
project
>> that uses Tms320c6713 as argrithom computing unit, one ADC for acquiring
>> signals, two DAC for outputing DSP's results. The ADC and DACs are on
one
>> piece of circuit we designed. Tms320c6713 collets data from ADC and sends
>> data to DAC all through EMIF interface. EMIF is mapped into CE2 space and
it
>> is configued 16-bit asynchronous interface.
>>
>> We 've configured two Mcbsps as GPIOs to send out ADC and DAC's
control
>> signals, the control signals meet our demands. They can be high or low
level
>> where we need.
>>
>> Because I am not familiar with DSP, when we designed our circuit board,
>> EMIF's CEn. AWE.ARE pins are all not conneted. So my first quesiton is:
can
>> our design work? These EMIF's three pins MUST be conneted? I'm not
sure
>> about it.
>>
>> Today when I debug DAC ( 12 bit), I use this method:
>>
>> Firstly, write 0x100 16-bit data( each value is 0x0FFF) in program. These
>> data are in L2 RAM.
>>
>> Secondly, send these data to DAC through EMIF in CE2 space, the first
>> address is 0xA0000000. Because DAC is 12-bit, the LSB 12 bit is only
needed.
>> If DAC is disconneted to DSP, I can observe 12 high leves about 3V using
>> scope.
>>
>> Thirdly, running program to send out signlas to control DAC. Unfornately,
>> when control signals and data are sent out, I watch memory in address
>> 0xA0000000, the values are all 0x06600660. It's so strange!! The
right
>> values should be 0x0FFF0FFF. So the second question is : where does the
>> wrong value come from? Is it related to EMIF's /AWE and /CEn pin?
>>
>> I hope anyone can shed some light on this or point me in the right
direction
>> todebug this problem.
>>
>> With kind regards,
>
>_____________________________________
_____________________________________
