Well, you're probably right depending on speed. In my experience at 1mbit,
it's tough to get around that pause, but at slower speeds there should be
plenty of time to run the interrupt before any pause is noticeable. I should
of made that distinction.
-Micah
On Wednesday 30 March 2005 01:24 am,
from_yahooMSP430@from... wrote:
> micah,
>
> I don't think there would necessarily be a pause in the clock -
firstly
> I'd, personally, do the TX when the tx buffer reports itself empty.
You
> might need a few flags to tell it when to stop doing so... but if you do
> it that way you will get a regular pulse train.
>
> even if you did do the TX from the receive routine, you may be half a bit
> -time ahead of the end of the char when you get the data, which is quite
> long enough to do the TX and not break the chain....
>
> David
>
>
> .
>
>
>
>
>
>
> click here
>
> .
micah,
I don't think there would necessarily be a pause in the clock - firstly
I'd, personally, do the TX when the tx buffer reports itself empty. You
might need a few flags to tell it when to stop doing so... but if you do
it that way you will get a regular pulse train.
even if you did do the TX from the receive routine, you may be half a bit
-time ahead of the end of the char when you get the data, which is quite
long enough to do the TX and not break the chain....
David
Reply by Micah Stevens●March 28, 20052005-03-28
Actually, just bit banging may make more sense. i.e.
(assumes Pin 3.7 is your DAC Clock line)
UART_RX_VECTOR ( void ) {
/* first get your value from the atmel */
P4OUT = RXBUF0; // send it to port 4.
/* toggle DAC Clock */
P3OUT |= BIT7; // bring clk high
P3OUT ^= ~BIT7; // bring clk low again.
/* get your next value going */
TXBUF0 = 0x0; // kickstart the next receive
}
That would probably do the trick, that's without knowing anything about any
timing issues that the DAC needs, but it sounds like it's just a strobe. If
it needs the Clock high for a period, just toss in a timing loop..
HTH
-Micah
On Monday 28 March 2005 06:51 pm, bigdog16_83 wrote:
> OK - that makes more sense now. The DAC is the TI DAC 908 - we are
> using it to change digital data coming from pins 4.0-4.7 into analog
> data that can be run to an amplifier and then to a speaker. The DAC
> needs the clock to run data into the device. I set up a clk on timer
> A but I am unsure as to how to time the the clock with the data
> coming in on the SPI (RX interrupt). Does this timing matter? I am
> receiveing data in the interrupt and sending it to the P4 ports
> where it is clocked into the DAC based on the timer. I would figure
> that the timing of the DAC clock would have to somewhat be in
> conjunction with the timing of the SPI. Correct?
>
> --- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> > Yes, once you recieve a byte, the interrupt will be called, then
>
> you need to
>
> > get the byte from the buffer, then send another byte to the TX
>
> buffer to kick
>
> > the clock for the next byte to be recieved. (Keep in mind the
>
> first RX
>
> > interrupt will never happen unless you kickstart the whole process
>
> with a
>
> > TXBUF write. )
> >
> > Now, in regards to the external DAC, this clock signal will not be
>
> regular. It
>
> > will have 8 cycles, then a small pause then 8 more, etc.. This is
>
> due to the
>
> > time it takes the processor to service the RX interrupt. What is
>
> the DAC
>
> > clock for? Communication? Is it a parralel connection with a
>
> strobe pin? IF
>
> > this is so, then you should be okay, although you'll be updating
>
> the DAC 8
>
> > times for each update of the Atmel. That may be okay, or it may
>
> not.
>
> > If you need a constant clock signal for the DAC, setup a timer to
>
> output one
>
> > of the timer ports. That would be a better choice IMHO..
> >
> > The SPI setup seemed strange to me at first too, but a constant
>
> clock signal
>
> > would result in framing issues. There's likely other reasons for
>
> it too, but
>
> > it does allow more control over the data stream.
> >
> > -Micah
> >
> > On Monday 28 March 2005 05:27 pm, bigdog16_83 wrote:
> > > Interesting. So your saying for me to continously recieve data
>
> from
>
> > > the atmel, which i should be doing once I send it the
continuous
> > > read command, that I have to keep something in the transfer
>
> buffer
>
> > > to keep that clock running? If I have a receive interrupt set,
>
> does
>
> > > this mean I need to put something in the transfer buffer every
>
> time
>
> > > that the interrupt is called? If this is so does this change
the
> > > rate data is being sent to me?
> > >
> > > With this - if I am taking the data I receive and sending it
out
> > > port 4 to an external DAC, can I use this same clock that
I'm
> > > receiving on to run the DAC or will this cause other issues?
> > >
> > > --- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> > > > <top post>
> > > > Sounds to me like you both are right, the SPI does have
it's
>
> own
>
> > > clock line.
> > >
> > > > This clock 'line' or wire, has a signal that is
generated by
>
> the
>
> > > master SPI
> > >
> > > > interface.
> > > >
> > > > In this case, this would be the MSP, the Atmel, being the
>
> slave
>
> > > device is
> > >
> > > > connected to the clock signal line. When the MSP wants to
read
> > >
> > > data from the
> > >
> > > > Atmel, it needs to place some value in the master TX
register.
> > >
> > > This will
> > >
> > > > trigger clock pulses on the clock line, which the Atmel
will
>
> see
>
> > > and send out
> > >
> > > > data to be stored in the MSP RX register.
> > > >
> > > > Now, not being familiar with the Atmel, I assume
there's some
> > >
> > > method for the
> > >
> > > > MSP to determine when there's data to be read. But
that's
>
> another
>
> > > issue.
> > >
> > > > -Micah
> > > >
> > > > On Saturday 26 March 2005 07:00 am, budfrog99 wrote:
> > > > > "...I thought the SPI had its own clock line
..."
> > > > >
> > > > > Nope. There is a master and slave(s). The master
>
> provides the
>
> > > clock
> > >
> > > > > whenever it wants something to happen on the SPI.
> > > > >
> > > > > Lee
> > > > >
> > > > > --- In msp430@msp4..., "bigdog16_83"
>
> <bigdog16_83@y...>
>
> > > wrote:
> > > > > > Does this not defeat the whole advantage of the
SPI? I
> > >
> > > thought the
> > >
> > > > > > SPI had its own clock line which transfer and
receive
>
> data was
>
> > > > > > attached to each of the edges? This also
defeats my
>
> purpose.
>
> > > I'm
> > >
> > > > > > using this to have the flash (storing a .wav
file) send
>
> the
>
> > > file
> > >
> > > > > > back to the MSP which will direct it out to an
external
>
> DAC.
>
> > > If I
> > >
> > > > > am
> > > > >
> > > > > > misunderstanding the SPI please explain more.
> > > > > >
> > > > > > --- In msp430@msp4..., "Matt Sabino"
>
> <msabino@a...>
>
> > > wrote:
> > > > > > > Since the Atmel dataflash is a SPI slave
device, it
>
> doesn't
>
> > > put
> > >
> > > > > >
> > > > > > any information out on the SPI bus unless you
clock it.
>
> Just
>
> > > stuff
> > >
> > > > > > U0TXBUF with a value like 0x00 (or some other
arbitrary
> > >
> > > value) for
> > >
> > > > > > every time you want to read a byte.
> > > > > >
> > > > > > > HTH,
> > > > > > >
> > > > > > >
> > > > > > > Matt Sabino
> > > > > > > Computer Engineer
> > > > > > > Airtronic Services, Inc.
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: bigdog16_83
> > > > > > > To: msp430@msp4...
> > > > > > > Sent: Friday, March 25, 2005 11:58 AM
> > > > > > > Subject: [msp430] SPI Problems
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I am working to communicate with an
ATMEL AT45DB081B
> > >
> > > dataflash
> > >
> > > > > >
> > > > > > in
> > > > > >
> > > > > > > SPI Mode with a MSP430-149. The opcode
sent to the
>
> flash
>
> > > should
> > >
> > > > > >
> > > > > > make
> > > > > >
> > > > > > > it do a continuous read so I should
continuously be
> > >
> > > receiving
> > >
> > > > > >
> > > > > > data
> > > > > >
> > > > > > > but instead I receive a few bytes and
then it stops.
>
> The
>
> > > flash
> > >
> > > > > >
> > > > > > needs
> > > > > >
> > > > > > > SPI Mode 0 or 3 and needs a high to low
transition
>
> on pin
>
> > > 3.0
> > >
> > > > > >
> > > > > > before
> > > > > >
> > > > > > > a opcode is sent. I believe I have the
>
> initializations
>
> > > right
> > >
> > > > > but
> > > > >
> > > > > > I
> > > > > >
> > > > > > > need some help debugging. I have an 8Mhz
crystal on
> > >
> > > installed
> > >
> > > > > on
> > > > >
> > > > > > the
> > > > > >
> > > > > > > XT2CLK. Any problems found, advice, or
anything
>
> would be
>
> > > of
> > >
> > > > > help
> > > > >
> > > > > > as
> > > > > >
> > > > > > > I need to get this going.
> > > > > > >
> > > > > > > void main(void)
> > > > > > > {
> > > > > > > unsigned int dco_cnt;
> > > > > > > BCSCTL1 &= ~XT2OFF;
// XT2on
> > > > > > > do //
wait for MCLK
>
> from
>
> > > quartz
> > >
> > > > > > > {
> > > > > > > IFG1 &=
~OFIFG; // Clear
>
> OSCFault
>
> > > flag
> > >
> > > > > > > for (dco_cnt = 0xff; dco_cnt
> 0;
>
> dco_cnt--
>
> > > > > >
> > > > > > ); //
> > > > > >
> > > > > > > Time for flag to set
> > > > > > > }
> > > > > > > while ((IFG1 & OFIFG) !=
0); //
>
> OSCFault flag
>
> > > > >
> > > > > still
> > > > >
> > > > > > set?
> > > > > >
> > > > > > > WDTCTL = WDTPW + WDTHOLD; // Stop
watchdog
>
> timer
>
> > > > > > >
> > > > > > > BCSCTL1 = 0x07; //
LFXT1: XT2on: LF
> > >
> > > quartz for
> > >
> > > > > >
> > > > > > MCLK
> > > > > >
> > > > > > > P3SEL |= 0x0E; //
P5.1-3 SPI option
> > >
> > > select
> > >
> > > > > > > P3DIR |= 0x01; //
P5.0 output
>
> direction
>
> > > > > > > P3OUT = 0xff;
> > > > > > > ME1 |= USPIE0; //
Enable USART1 SPI
>
> mode
>
> > > > > > > UTCTL0 = CKPH | SSEL1 | SSEL0 |
STC; //
> > >
> > > SMCLK, 3-
> > >
> > > > > >
> > > > > > pin
> > > > > >
> > > > > > > mode, clock idle low, data valid on
rising edge, UCLK
> > >
> > > delayed
> > >
> > > > > > > UBR00 = 0x02;
// 0x02:
>
> UCLK/2 (4
>
> > > MHz),
> > >
> > > > > > > works also with 3 and 4
> > > > > > > UBR10 = 0x00;
// -"-
> > > > > > > UMCTL0 = 0x00; // no
modulation
> > > > > > > UCTL0 = CHAR | SYNC | MM;
// 8-bit SPI
>
> Master
>
> > > > > >
> > > > > > **SWRST**
> > > > > >
> > > > > > > IE1 |= URXIE0;
> > > > > > > _EINT();
> > > > > > >
> > > > > > > P1DIR |= 0x01;
> > > > > > >
> > > > > > >
continuous_Read(S1_B1,S1_B2,S1_B3);
> > > > > > >
> > > > > > > for(;;)
> > > > > > > {
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > #pragma vector=USART0RX_VECTOR
> > > > > > > __interrupt void SPI0_RX (void)
> > > > > > > {
> > > > > > >
> > > > > > > P1OUT ^= 0x01; //Toggle
light to show
>
> data is
>
> > > > > >
> > > > > > received
> > > > > >
> > > > > > > {
> > > > > > > unsigned int y;
> > > > > > > y =
50000; //
>
> Delay
>
> > > > > > > do (y--);
> > > > > > > while (y != 0);
> > > > > > > y =
50000; //
> > >
> > > Delay
> > >
> > > > > > > do (y--);
> > > > > > > while (y != 0);
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > }
> > > > > > > void continuous_Read(int Byte1, int
Byte2, int Byte3)
> > > > > > > {
> > > > > > > CS_LOW();
> > > > > > > //P3OUT ^=
0x01; //Reset
> > >
> > > Memory to
> > >
> > > > > > > assure proper timing
> > > > > > > i =
50000; // Delay
> > > > > > > do (i--);
> > > > > > > while (i != 0);
> > > > > > >
> > > > > > > //Flash needs opcode
+24 bits of
>
> start
>
> > > address
> > >
> > > > > +
> > > > >
> > > > > > 32
> > > > > >
> > > > > > > don't care bits
> > > > > > > U0TXBUF >
> 0xE8; //opcode for
>
> > > > > > > continous array read
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> Byte1; //First
>
> > > Byte of
> > >
> > > > > >
> > > > > > 24-
> > > > > >
> > > > > > > bit address sequence
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> Byte2; //Second
>
> > > Byte
> > >
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> Byte3; //Third
>
> > > Byte
> > >
> > > > > > >
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF =
0xFF; //First
> > >
> > > byte of
> > >
> > > > > 32-
> > > > >
> > > > > > > don't care bits
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> 0xFF; //Second
>
> > > Byte
> > >
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> 0xFF; //Third Byte
>
> > > > > > > while ((IFG1 & UTXIFG0) ==
0); //
>
> USART0 TX
>
> > > > >
> > > > > buffer
> > > > >
> > > > > > > ready?
> > > > > > > U0TXBUF >
> 0xFF; //Final Byte
>
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > .
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -------------------
>
> -----
>
> > > ------
> > >
> > > > > -
> > > > >
> > > > > > -----------
> > > > > >
> > > > > > > .
Reply by bigdog16_83●March 28, 20052005-03-28
OK - that makes more sense now. The DAC is the TI DAC 908 - we are
using it to change digital data coming from pins 4.0-4.7 into analog
data that can be run to an amplifier and then to a speaker. The DAC
needs the clock to run data into the device. I set up a clk on timer
A but I am unsure as to how to time the the clock with the data
coming in on the SPI (RX interrupt). Does this timing matter? I am
receiveing data in the interrupt and sending it to the P4 ports
where it is clocked into the DAC based on the timer. I would figure
that the timing of the DAC clock would have to somewhat be in
conjunction with the timing of the SPI. Correct?
--- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
>
>
> Yes, once you recieve a byte, the interrupt will be called, then
you need to
> get the byte from the buffer, then send another
byte to the TX
buffer to kick
> the clock for the next byte to be recieved. (Keep
in mind the
first RX
> interrupt will never happen unless you kickstart
the whole process
with a
> TXBUF write. )
>
> Now, in regards to the external DAC, this clock signal will not be
regular. It
> will have 8 cycles, then a small pause then 8
more, etc.. This is
due to the
> time it takes the processor to service the RX
interrupt. What is
the DAC
> clock for? Communication? Is it a parralel
connection with a
strobe pin? IF
> this is so, then you should be okay, although
you'll be updating
the DAC 8
> times for each update of the Atmel. That may be
okay, or it may
not.
>
> If you need a constant clock signal for the DAC, setup a timer to
output one
> of the timer ports. That would be a better choice
IMHO..
>
> The SPI setup seemed strange to me at first too, but a constant
clock signal
> would result in framing issues. There's
likely other reasons for
it too, but
> it does allow more control over the data stream.
>
> -Micah
>
>
> On Monday 28 March 2005 05:27 pm, bigdog16_83 wrote:
> > Interesting. So your saying for me to continously recieve data
from
> > the atmel, which i should be doing once I
send it the continuous
> > read command, that I have to keep something in the transfer
buffer
> > to keep that clock running? If I have a
receive interrupt set,
does
> > this mean I need to put something in the
transfer buffer every
time
> > that the interrupt is called? If this is so
does this change the
> > rate data is being sent to me?
> >
> > With this - if I am taking the data I receive and sending it out
> > port 4 to an external DAC, can I use this same clock that I'm
> > receiving on to run the DAC or will this cause other issues?
> >
> > --- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> > > <top post>
> > > Sounds to me like you both are right, the SPI does have
it's
own
> >
> > clock line.
> >
> > > This clock 'line' or wire, has a signal that is
generated by
the
> >
> > master SPI
> >
> > > interface.
> > >
> > > In this case, this would be the MSP, the Atmel, being the
slave
> >
> > device is
> >
> > > connected to the clock signal line. When the MSP wants to read
> >
> > data from the
> >
> > > Atmel, it needs to place some value in the master TX register.
> >
> > This will
> >
> > > trigger clock pulses on the clock line, which the Atmel will
see
> >
> > and send out
> >
> > > data to be stored in the MSP RX register.
> > >
> > > Now, not being familiar with the Atmel, I assume there's
some
> >
> > method for the
> >
> > > MSP to determine when there's data to be read. But
that's
another
> >
> > issue.
> >
> > > -Micah
> > >
> > > On Saturday 26 March 2005 07:00 am, budfrog99 wrote:
> > > > "...I thought the SPI had its own clock line
..."
> > > >
> > > > Nope. There is a master and slave(s). The master
provides the
> >
> > clock
> >
> > > > whenever it wants something to happen on the SPI.
> > > >
> > > > Lee
> > > >
> > > > --- In msp430@msp4..., "bigdog16_83"
<bigdog16_83@y...>
> >
> > wrote:
> > > > > Does this not defeat the whole advantage of the SPI?
I
> >
> > thought the
> >
> > > > > SPI had its own clock line which transfer and receive
data was
> > > > > attached to each of the
edges? This also defeats my
purpose.
> >
> > I'm
> >
> > > > > using this to have the flash (storing a .wav file)
send
the
> >
> > file
> >
> > > > > back to the MSP which will direct it out to an
external
DAC.
> >
> > If I
> >
> > > > am
> > > >
> > > > > misunderstanding the SPI please explain more.
> > > > >
> > > > > --- In msp430@msp4..., "Matt Sabino"
<msabino@a...>
> >
> > wrote:
> > > > > > Since the Atmel dataflash is a SPI slave device,
it
doesn't
> >
> > put
> >
> > > > >
> > > > > any information out on the SPI bus unless you clock
it.
Just
> >
> > stuff
> >
> > > > > U0TXBUF with a value like 0x00 (or some other
arbitrary
> >
> > value) for
> >
> > > > > every time you want to read a byte.
> > > > >
> > > > > > HTH,
> > > > > >
> > > > > >
> > > > > > Matt Sabino
> > > > > > Computer Engineer
> > > > > > Airtronic Services, Inc.
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: bigdog16_83
> > > > > > To: msp430@msp4...
> > > > > > Sent: Friday, March 25, 2005 11:58 AM
> > > > > > Subject: [msp430] SPI Problems
> > > > > >
> > > > > >
> > > > > >
> > > > > > I am working to communicate with an ATMEL
AT45DB081B
> >
> > dataflash
> >
> > > > >
> > > > > in
> > > > >
> > > > > > SPI Mode with a MSP430-149. The opcode sent to
the
flash
> >
> > should
> >
> > > > >
> > > > > make
> > > > >
> > > > > > it do a continuous read so I should
continuously be
> >
> > receiving
> >
> > > > >
> > > > > data
> > > > >
> > > > > > but instead I receive a few bytes and then it
stops.
The
> >
> > flash
> >
> > > > >
> > > > > needs
> > > > >
> > > > > > SPI Mode 0 or 3 and needs a high to low
transition
on pin
> >
> > 3.0
> >
> > > > >
> > > > > before
> > > > >
> > > > > > a opcode is sent. I believe I have the
initializations
> >
> > right
> >
> > > > but
> > > >
> > > > > I
> > > > >
> > > > > > need some help debugging. I have an 8Mhz
crystal on
> >
> > installed
> >
> > > > on
> > > >
> > > > > the
> > > > >
> > > > > > XT2CLK. Any problems found, advice, or
anything
would be
> >
> > of
> >
> > > > help
> > > >
> > > > > as
> > > > >
> > > > > > I need to get this going.
> > > > > >
> > > > > > void main(void)
> > > > > > {
> > > > > > unsigned int dco_cnt;
> > > > > > BCSCTL1 &= ~XT2OFF; //
XT2on
> > > > > > do // wait for
MCLK
from
> >
> > quartz
> >
> > > > > > {
> > > > > > IFG1 &= ~OFIFG; //
Clear
OSCFault
> >
> > flag
> >
> > > > > > for (dco_cnt = 0xff; dco_cnt >
0;
dco_cnt--
> > > > >
> > > > > ); //
> > > > >
> > > > > > Time for flag to set
> > > > > > }
> > > > > > while ((IFG1 & OFIFG) != 0);
//
OSCFault flag
> > > >
> > > > still
> > > >
> > > > > set?
> > > > >
> > > > > > WDTCTL = WDTPW + WDTHOLD; // Stop
watchdog
timer
> > > > > >
> > > > > > BCSCTL1 = 0x07; // LFXT1:
XT2on: LF
> >
> > quartz for
> >
> > > > >
> > > > > MCLK
> > > > >
> > > > > > P3SEL |= 0x0E; // P5.1-3 SPI
option
> >
> > select
> >
> > > > > > P3DIR |= 0x01; // P5.0
output
direction
> > > > > > P3OUT = 0xff;
> > > > > > ME1 |= USPIE0; // Enable
USART1 SPI
mode
> > > > > > UTCTL0 = CKPH
| SSEL1 | SSEL0 | STC; //
> >
> > SMCLK, 3-
> >
> > > > >
> > > > > pin
> > > > >
> > > > > > mode, clock idle low, data valid on rising
edge, UCLK
> >
> > delayed
> >
> > > > > > UBR00 = 0x02; //
0x02:
UCLK/2 (4
> >
> > MHz),
> >
> > > > > > works also with 3 and 4
> > > > > > UBR10 = 0x00; //
-"-
> > > > > > UMCTL0 = 0x00; // no
modulation
> > > > > > UCTL0 = CHAR | SYNC | MM; //
8-bit SPI
Master
> > > > >
> > > > > **SWRST**
> > > > >
> > > > > > IE1 |= URXIE0;
> > > > > > _EINT();
> > > > > >
> > > > > > P1DIR |= 0x01;
> > > > > >
> > > > > > continuous_Read(S1_B1,S1_B2,S1_B3);
> > > > > >
> > > > > > for(;;)
> > > > > > {
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > #pragma vector=USART0RX_VECTOR
> > > > > > __interrupt void SPI0_RX (void)
> > > > > > {
> > > > > >
> > > > > > P1OUT ^= 0x01; //Toggle light to
show
data is
> > > > >
> > > > > received
> > > > >
> > > > > > {
> > > > > > unsigned int y;
> > > > > > y =
50000; //
Delay
> > > > > > do
(y--);
> > > > > > while (y != 0);
> > > > > > y =
50000; //
> >
> > Delay
> >
> > > > > > do (y--);
> > > > > > while (y != 0);
> > > > > > }
> > > > > >
> > > > > >
> > > > > > }
> > > > > > void continuous_Read(int Byte1, int Byte2, int
Byte3)
> > > > > > {
> > > > > > CS_LOW();
> > > > > > //P3OUT ^= 0x01;
//Reset
> >
> > Memory to
> >
> > > > > > assure proper timing
> > > > > > i = 50000; //
Delay
> > > > > > do (i--);
> > > > > > while (i != 0);
> > > > > >
> > > > > > //Flash needs opcode +24
bits of
start
> >
> > address
> >
> > > > +
> > > >
> > > > > 32
> > > > >
> > > > > > don't care bits
> > > > > > U0TXBUF 0xE8;
//opcode for
> > > > > > continous array read
> > > > > > while ((IFG1 & UTXIFG0) ==
0); //
USART0 TX
> > > >
> > > > buffer
> > > >
> > > > > > ready?
> > > > > > U0TXBUF Byte1;
//First
> >
> > Byte of
> >
> > > > >
> > > > > 24-
> > > > >
> > > > > > bit address sequence
> > > > > > while ((IFG1 & UTXIFG0) ==
0); //
USART0 TX
> > > >
> > > > buffer
> > > >
> > > > > > ready?
> > > > > > U0TXBUF Byte2;
//Second
> >
> > Byte
> >
> > > > > > while ((IFG1 & UTXIFG0) ==
0); //
USART0 TX
> > > >
> > > > buffer
> > > >
> > > > > > ready?
> > > > > > U0TXBUF Byte3;
//Third
> >
> > Byte
> >
> > > > > >
> > > > > > while ((IFG1 & UTXIFG0) ==
0); //
USART0 TX
> > > >
> > > > buffer
> > > >
> > > > > > ready?
> > > > > > U0TXBUF = 0xFF;
//First
> >
> > byte of
> >
> > > > 32-
> > > >
> > > > > > don't care bits
> > > > > > while ((IFG1 & UTXIFG0) ==
0); //
USART0 TX
> > > >
> > > > buffer
> > > >
> > > > > > ready?
> > > > > > U0TXBUF 0xFF;
//Second
> >
> > Byte
> >
> > > > > > while ((IFG1 & UTXIFG0) ==
0); //
USART0 TX
> > > >
> > > > buffer
> > > >
> > > > > > ready?
> > > > > > U0TXBUF 0xFF;
//Third Byte
> > > > > > while ((IFG1 & UTXIFG0) ==
0); //
USART0 TX
> > > >
> > > > buffer
> > > >
> > > > > > ready?
> > > > > > U0TXBUF 0xFF;
//Final Byte
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > .
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -------------------
-----
> >
> > ------
> >
> > > > -
> > > >
> > > > > -----------
> > > > >
> > > > > > Yahoo! Groups Links
> > > > > >
> > > > > > a.. To visit your group on the web, go to:
> > > > > > http://groups.yahoo.com/group/msp430/
> > > > > >
> > > > > > b.. .
> > > > > >
> > > > > > c.. Your use of Yahoo! Groups is subject to
the
Yahoo!
> >
> > Terms
> >
> > > > >
> > > > > of Service.
> > > > >
> > > > > > -------------------
-----
> >
> > ------
> >
> > > > -
> > > >
> > > > > -----------
> > > > >
> > > > > > No virus found in this incoming message.
> > > > > > Checked by AVG Anti-Virus.
> > > > > > Version: 7.0.308 / Virus Database: 266.8.2 -
Release
Date:
> > > > >
> > > > > 3/25/2005
> > > > >
> > > > > > ----------
> > > > > >
> > > > > > No virus found in this outgoing message.
> > > > > > Checked by AVG Anti-Virus.
> > > > > > Version: 7.0.308 / Virus Database: 266.8.2 -
Release
Date:
> > > > >
> > > > > 3/25/2005
> > > > >
> > > > > >
> > > >
> > > > .
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > > To visit your group on the web, go to:
> > > > http://groups.yahoo.com/group/msp430/
> > > >
> > > > .
> > > >
> > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >
> > Service.
> >
> >
> >
> >
> >
> > .
> >
> >
> >
> >
> >
> >
> > click here
> >
> > Yahoo! Groups Links
> >
> > To visit your group on the web, go to:
> > http://groups.yahoo.com/group/msp430/
> >
> > .
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
Reply by Micah Stevens●March 28, 20052005-03-28
Yes, once you recieve a byte, the interrupt will be called, then you need to
get the byte from the buffer, then send another byte to the TX buffer to kick
the clock for the next byte to be recieved. (Keep in mind the first RX
interrupt will never happen unless you kickstart the whole process with a
TXBUF write. )
Now, in regards to the external DAC, this clock signal will not be regular. It
will have 8 cycles, then a small pause then 8 more, etc.. This is due to the
time it takes the processor to service the RX interrupt. What is the DAC
clock for? Communication? Is it a parralel connection with a strobe pin? IF
this is so, then you should be okay, although you'll be updating the DAC 8
times for each update of the Atmel. That may be okay, or it may not.
If you need a constant clock signal for the DAC, setup a timer to output one
of the timer ports. That would be a better choice IMHO..
The SPI setup seemed strange to me at first too, but a constant clock signal
would result in framing issues. There's likely other reasons for it too,
but
it does allow more control over the data stream.
-Micah
On Monday 28 March 2005 05:27 pm, bigdog16_83 wrote:
> Interesting. So your saying for me to continously recieve data from
> the atmel, which i should be doing once I send it the continuous
> read command, that I have to keep something in the transfer buffer
> to keep that clock running? If I have a receive interrupt set, does
> this mean I need to put something in the transfer buffer every time
> that the interrupt is called? If this is so does this change the
> rate data is being sent to me?
>
> With this - if I am taking the data I receive and sending it out
> port 4 to an external DAC, can I use this same clock that I'm
> receiving on to run the DAC or will this cause other issues?
>
> --- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> > <top post>
> > Sounds to me like you both are right, the SPI does have it's own
>
> clock line.
>
> > This clock 'line' or wire, has a signal that is generated
by the
>
> master SPI
>
> > interface.
> >
> > In this case, this would be the MSP, the Atmel, being the slave
>
> device is
>
> > connected to the clock signal line. When the MSP wants to read
>
> data from the
>
> > Atmel, it needs to place some value in the master TX register.
>
> This will
>
> > trigger clock pulses on the clock line, which the Atmel will see
>
> and send out
>
> > data to be stored in the MSP RX register.
> >
> > Now, not being familiar with the Atmel, I assume there's some
>
> method for the
>
> > MSP to determine when there's data to be read. But that's
another
>
> issue.
>
> > -Micah
> >
> > On Saturday 26 March 2005 07:00 am, budfrog99 wrote:
> > > "...I thought the SPI had its own clock line ..."
> > >
> > > Nope. There is a master and slave(s). The master provides the
>
> clock
>
> > > whenever it wants something to happen on the SPI.
> > >
> > > Lee
> > >
> > > --- In msp430@msp4..., "bigdog16_83"
<bigdog16_83@y...>
>
> wrote:
> > > > Does this not defeat the whole advantage of the SPI? I
>
> thought the
>
> > > > SPI had its own clock line which transfer and receive data
was
> > > > attached to each of the edges? This also defeats my
purpose.
>
> I'm
>
> > > > using this to have the flash (storing a .wav file) send
the
>
> file
>
> > > > back to the MSP which will direct it out to an external
DAC.
>
> If I
>
> > > am
> > >
> > > > misunderstanding the SPI please explain more.
> > > >
> > > > --- In msp430@msp4..., "Matt Sabino"
<msabino@a...>
>
> wrote:
> > > > > Since the Atmel dataflash is a SPI slave device, it
doesn't
>
> put
>
> > > >
> > > > any information out on the SPI bus unless you clock it.
Just
>
> stuff
>
> > > > U0TXBUF with a value like 0x00 (or some other arbitrary
>
> value) for
>
> > > > every time you want to read a byte.
> > > >
> > > > > HTH,
> > > > >
> > > > >
> > > > > Matt Sabino
> > > > > Computer Engineer
> > > > > Airtronic Services, Inc.
> > > > >
> > > > > ----- Original Message -----
> > > > > From: bigdog16_83
> > > > > To: msp430@msp4...
> > > > > Sent: Friday, March 25, 2005 11:58 AM
> > > > > Subject: [msp430] SPI Problems
> > > > >
> > > > >
> > > > >
> > > > > I am working to communicate with an ATMEL
AT45DB081B
>
> dataflash
>
> > > >
> > > > in
> > > >
> > > > > SPI Mode with a MSP430-149. The opcode sent to the
flash
>
> should
>
> > > >
> > > > make
> > > >
> > > > > it do a continuous read so I should continuously be
>
> receiving
>
> > > >
> > > > data
> > > >
> > > > > but instead I receive a few bytes and then it
stops. The
>
> flash
>
> > > >
> > > > needs
> > > >
> > > > > SPI Mode 0 or 3 and needs a high to low transition
on pin
>
> 3.0
>
> > > >
> > > > before
> > > >
> > > > > a opcode is sent. I believe I have the
initializations
>
> right
>
> > > but
> > >
> > > > I
> > > >
> > > > > need some help debugging. I have an 8Mhz crystal on
>
> installed
>
> > > on
> > >
> > > > the
> > > >
> > > > > XT2CLK. Any problems found, advice, or anything
would be
>
> of
>
> > > help
> > >
> > > > as
> > > >
> > > > > I need to get this going.
> > > > >
> > > > > void main(void)
> > > > > {
> > > > > unsigned int dco_cnt;
> > > > > BCSCTL1 &= ~XT2OFF; // XT2on
> > > > > do // wait for MCLK
from
>
> quartz
>
> > > > > {
> > > > > IFG1 &= ~OFIFG; // Clear
OSCFault
>
> flag
>
> > > > > for (dco_cnt = 0xff; dco_cnt > 0;
dco_cnt--
> > > >
> > > > ); //
> > > >
> > > > > Time for flag to set
> > > > > }
> > > > > while ((IFG1 & OFIFG) != 0); //
OSCFault flag
> > >
> > > still
> > >
> > > > set?
> > > >
> > > > > WDTCTL = WDTPW + WDTHOLD; // Stop watchdog
timer
> > > > >
> > > > > BCSCTL1 = 0x07; // LFXT1: XT2on:
LF
>
> quartz for
>
> > > >
> > > > MCLK
> > > >
> > > > > P3SEL |= 0x0E; // P5.1-3 SPI
option
>
> select
>
> > > > > P3DIR |= 0x01; // P5.0 output
direction
> > > > > P3OUT = 0xff;
> > > > > ME1 |= USPIE0; // Enable USART1
SPI mode
> > > > > UTCTL0 = CKPH | SSEL1 | SSEL0 | STC;
//
>
> SMCLK, 3-
>
> > > >
> > > > pin
> > > >
> > > > > mode, clock idle low, data valid on rising edge,
UCLK
>
> delayed
>
> > > > > UBR00 = 0x02; // 0x02:
UCLK/2 (4
>
> MHz),
>
> > > > > works also with 3 and 4
> > > > > UBR10 = 0x00; // -"-
> > > > > UMCTL0 = 0x00; // no modulation
> > > > > UCTL0 = CHAR | SYNC | MM; // 8-bit SPI
Master
> > > >
> > > > **SWRST**
> > > >
> > > > > IE1 |= URXIE0;
> > > > > _EINT();
> > > > >
> > > > > P1DIR |= 0x01;
> > > > >
> > > > > continuous_Read(S1_B1,S1_B2,S1_B3);
> > > > >
> > > > > for(;;)
> > > > > {
> > > > > }
> > > > > }
> > > > >
> > > > > #pragma vector=USART0RX_VECTOR
> > > > > __interrupt void SPI0_RX (void)
> > > > > {
> > > > >
> > > > > P1OUT ^= 0x01; //Toggle light to show
data is
> > > >
> > > > received
> > > >
> > > > > {
> > > > > unsigned int y;
> > > > > y = 50000; //
Delay
> > > > > do (y--);
> > > > > while (y != 0);
> > > > > y = 50000;
//
>
> Delay
>
> > > > > do (y--);
> > > > > while (y != 0);
> > > > > }
> > > > >
> > > > >
> > > > > }
> > > > > void continuous_Read(int Byte1, int Byte2, int
Byte3)
> > > > > {
> > > > > CS_LOW();
> > > > > //P3OUT ^= 0x01;
//Reset
>
> Memory to
>
> > > > > assure proper timing
> > > > > i = 50000; //
Delay
> > > > > do (i--);
> > > > > while (i != 0);
> > > > >
> > > > > //Flash needs opcode +24 bits
of start
>
> address
>
> > > +
> > >
> > > > 32
> > > >
> > > > > don't care bits
> > > > > U0TXBUF = 0xE8;
//opcode for
> > > > > continous array read
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = Byte1;
//First
>
> Byte of
>
> > > >
> > > > 24-
> > > >
> > > > > bit address sequence
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = Byte2;
//Second
>
> Byte
>
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = Byte3;
//Third
>
> Byte
>
> > > > >
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = 0xFF;
//First
>
> byte of
>
> > > 32-
> > >
> > > > > don't care bits
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = 0xFF;
//Second
>
> Byte
>
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = 0xFF;
//Third Byte
> > > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> > >
> > > buffer
> > >
> > > > > ready?
> > > > > U0TXBUF = 0xFF;
//Final Byte
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > .
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------------------------
>
> ------
>
> > > -
> > >
> > > > -----------
> > > >
> > > > > .
Reply by bigdog16_83●March 28, 20052005-03-28
Interesting. So your saying for me to continously recieve data from
the atmel, which i should be doing once I send it the continuous
read command, that I have to keep something in the transfer buffer
to keep that clock running? If I have a receive interrupt set, does
this mean I need to put something in the transfer buffer every time
that the interrupt is called? If this is so does this change the
rate data is being sent to me?
With this - if I am taking the data I receive and sending it out
port 4 to an external DAC, can I use this same clock that I'm
receiving on to run the DAC or will this cause other issues?
--- In msp430@msp4..., Micah Stevens <micah@9...> wrote:
> <top post>
> Sounds to me like you both are right, the SPI does have it's own
clock line.
> This clock 'line' or wire, has a signal
that is generated by the
master SPI
> interface.
>
> In this case, this would be the MSP, the Atmel, being the slave
device is
> connected to the clock signal line. When the MSP
wants to read
data from the
> Atmel, it needs to place some value in the master
TX register.
This will
> trigger clock pulses on the clock line, which the
Atmel will see
and send out
> data to be stored in the MSP RX register.
>
> Now, not being familiar with the Atmel, I assume there's some
method for the
> MSP to determine when there's data to be
read. But that's another
issue.
>
> -Micah
>
>
> On Saturday 26 March 2005 07:00 am, budfrog99 wrote:
> > "...I thought the SPI had its own clock line ..."
> >
> > Nope. There is a master and slave(s). The master provides the
clock
> > whenever it wants something to happen on the
SPI.
> >
> > Lee
> >
> > --- In msp430@msp4..., "bigdog16_83"
<bigdog16_83@y...>
wrote:
> > > Does this not defeat the whole advantage of the SPI? I
thought the
> > > SPI had its own clock line which
transfer and receive data was
> > > attached to each of the edges? This also defeats my purpose.
I'm
> > > using this to have the flash (storing a
.wav file) send the
file
> > > back to the MSP which will direct it
out to an external DAC.
If I
> >
> > am
> >
> > > misunderstanding the SPI please explain more.
> > >
> > > --- In msp430@msp4..., "Matt Sabino"
<msabino@a...>
wrote:
> > > > Since the Atmel dataflash is a SPI slave device, it
doesn't
put
> > >
> > > any information out on the SPI bus unless you clock it. Just
stuff
> > > U0TXBUF with a value like 0x00 (or some
other arbitrary
value) for
> > > every time you want to read a byte.
> > >
> > > > HTH,
> > > >
> > > >
> > > > Matt Sabino
> > > > Computer Engineer
> > > > Airtronic Services, Inc.
> > > >
> > > > ----- Original Message -----
> > > > From: bigdog16_83
> > > > To: msp430@msp4...
> > > > Sent: Friday, March 25, 2005 11:58 AM
> > > > Subject: [msp430] SPI Problems
> > > >
> > > >
> > > >
> > > > I am working to communicate with an ATMEL AT45DB081B
dataflash
> > >
> > > in
> > >
> > > > SPI Mode with a MSP430-149. The opcode sent to the flash
should
> > >
> > > make
> > >
> > > > it do a continuous read so I should continuously be
receiving
> > >
> > > data
> > >
> > > > but instead I receive a few bytes and then it stops. The
flash
> > >
> > > needs
> > >
> > > > SPI Mode 0 or 3 and needs a high to low transition on pin
3.0
> > >
> > > before
> > >
> > > > a opcode is sent. I believe I have the initializations
right
> >
> > but
> >
> > > I
> > >
> > > > need some help debugging. I have an 8Mhz crystal on
installed
> >
> > on
> >
> > > the
> > >
> > > > XT2CLK. Any problems found, advice, or anything would be
of
> >
> > help
> >
> > > as
> > >
> > > > I need to get this going.
> > > >
> > > > void main(void)
> > > > {
> > > > unsigned int dco_cnt;
> > > > BCSCTL1 &= ~XT2OFF; // XT2on
> > > > do // wait for MCLK from
quartz
> > > > {
> > > > IFG1 &= ~OFIFG; // Clear
OSCFault
flag
> > > > for (dco_cnt = 0xff;
dco_cnt > 0; dco_cnt--
> > >
> > > ); //
> > >
> > > > Time for flag to set
> > > > }
> > > > while ((IFG1 & OFIFG) != 0); // OSCFault
flag
> >
> > still
> >
> > > set?
> > >
> > > > WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
> > > >
> > > > BCSCTL1 = 0x07; // LFXT1: XT2on: LF
quartz for
> > >
> > > MCLK
> > >
> > > > P3SEL |= 0x0E; // P5.1-3 SPI option
select
> > > > P3DIR |=
0x01; // P5.0 output direction
> > > > P3OUT = 0xff;
> > > > ME1 |= USPIE0; // Enable USART1 SPI mode
> > > > UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; //
SMCLK, 3-
> > >
> > > pin
> > >
> > > > mode, clock idle low, data valid on rising edge, UCLK
delayed
> > > > UBR00 =
0x02; // 0x02: UCLK/2 (4
MHz),
> > > > works also with 3 and 4
> > > > UBR10 = 0x00; // -"-
> > > > UMCTL0 = 0x00; // no modulation
> > > > UCTL0 = CHAR | SYNC | MM; // 8-bit SPI
Master
> > >
> > > **SWRST**
> > >
> > > > IE1 |= URXIE0;
> > > > _EINT();
> > > >
> > > > P1DIR |= 0x01;
> > > >
> > > > continuous_Read(S1_B1,S1_B2,S1_B3);
> > > >
> > > > for(;;)
> > > > {
> > > > }
> > > > }
> > > >
> > > > #pragma vector=USART0RX_VECTOR
> > > > __interrupt void SPI0_RX (void)
> > > > {
> > > >
> > > > P1OUT ^= 0x01; //Toggle light to show data
is
> > >
> > > received
> > >
> > > > {
> > > > unsigned int y;
> > > > y = 50000; // Delay
> > > > do (y--);
> > > > while (y != 0);
> > > > y = 50000; //
Delay
> > > > do (y--);
> > > > while (y != 0);
> > > > }
> > > >
> > > >
> > > > }
> > > > void continuous_Read(int Byte1, int Byte2, int Byte3)
> > > > {
> > > > CS_LOW();
> > > > //P3OUT ^= 0x01; //Reset
Memory to
> > > > assure proper timing
> > > > i = 50000; // Delay
> > > > do (i--);
> > > > while (i != 0);
> > > >
> > > > //Flash needs opcode +24 bits of
start
address
> >
> > +
> >
> > > 32
> > >
> > > > don't care bits
> > > > U0TXBUF = 0xE8; //opcode
for
> > > > continous array read
> > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> >
> > buffer
> >
> > > > ready?
> > > > U0TXBUF = Byte1; //First
Byte of
> > >
> > > 24-
> > >
> > > > bit address sequence
> > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> >
> > buffer
> >
> > > > ready?
> > > > U0TXBUF = Byte2; //Second
Byte
> > > > while ((IFG1 &
UTXIFG0) == 0); // USART0 TX
> >
> > buffer
> >
> > > > ready?
> > > > U0TXBUF = Byte3; //Third
Byte
> > > >
> > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> >
> > buffer
> >
> > > > ready?
> > > > U0TXBUF = 0xFF; //First
byte of
> >
> > 32-
> >
> > > > don't care bits
> > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> >
> > buffer
> >
> > > > ready?
> > > > U0TXBUF = 0xFF; //Second
Byte
> > > > while ((IFG1 &
UTXIFG0) == 0); // USART0 TX
> >
> > buffer
> >
> > > > ready?
> > > > U0TXBUF = 0xFF; //Third
Byte
> > > > while ((IFG1 & UTXIFG0) == 0); //
USART0 TX
> >
> > buffer
> >
> > > > ready?
> > > > U0TXBUF = 0xFF; //Final
Byte
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > .
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ------------------------
------
> >
> > -
> >
> > > -----------
> > >
> > > > Yahoo! Groups Links
> > > >
> > > > a.. To visit your group on the web, go to:
> > > > http://groups.yahoo.com/group/msp430/
> > > >
> > > > b.. .
> > > >
> > > > c.. Your use of Yahoo! Groups is subject to the Yahoo!
Terms
> > >
> > > of Service.
> > >
> > > > ------------------------
------
> >
> > -
> >
> > > -----------
> > >
> > > > No virus found in this incoming message.
> > > > Checked by AVG Anti-Virus.
> > > > Version: 7.0.308 / Virus Database: 266.8.2 - Release
Date:
> > >
> > > 3/25/2005
> > >
> > > > ----------
> > > >
> > > > No virus found in this outgoing message.
> > > > Checked by AVG Anti-Virus.
> > > > Version: 7.0.308 / Virus Database: 266.8.2 - Release Date:
> > >
> > > 3/25/2005
> > >
> > > >
> >
> > .
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> > To visit your group on the web, go to:
> > http://groups.yahoo.com/group/msp430/
> >
> > .
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
Reply by Micah Stevens●March 26, 20052005-03-26
<top post>
Sounds to me like you both are right, the SPI does have it's own clock
line.
This clock 'line' or wire, has a signal that is generated by the
master SPI
interface.
In this case, this would be the MSP, the Atmel, being the slave device is
connected to the clock signal line. When the MSP wants to read data from the
Atmel, it needs to place some value in the master TX register. This will
trigger clock pulses on the clock line, which the Atmel will see and send out
data to be stored in the MSP RX register.
Now, not being familiar with the Atmel, I assume there's some method for
the
MSP to determine when there's data to be read. But that's another
issue.
-Micah
On Saturday 26 March 2005 07:00 am, budfrog99 wrote:
> "...I thought the SPI had its own clock line ..."
>
> Nope. There is a master and slave(s). The master provides the clock
> whenever it wants something to happen on the SPI.
>
> Lee
>
> --- In msp430@msp4..., "bigdog16_83" <bigdog16_83@y...>
wrote:
> > Does this not defeat the whole advantage of the SPI? I thought the
> > SPI had its own clock line which transfer and receive data was
> > attached to each of the edges? This also defeats my purpose. I'm
> > using this to have the flash (storing a .wav file) send the file
> > back to the MSP which will direct it out to an external DAC. If I
>
> am
>
> > misunderstanding the SPI please explain more.
> >
> > --- In msp430@msp4..., "Matt Sabino" <msabino@a...>
wrote:
> > > Since the Atmel dataflash is a SPI slave device, it doesn't
put
> >
> > any information out on the SPI bus unless you clock it. Just stuff
> > U0TXBUF with a value like 0x00 (or some other arbitrary value) for
> > every time you want to read a byte.
> >
> > > HTH,
> > >
> > >
> > > Matt Sabino
> > > Computer Engineer
> > > Airtronic Services, Inc.
> > >
> > > ----- Original Message -----
> > > From: bigdog16_83
> > > To: msp430@msp4...
> > > Sent: Friday, March 25, 2005 11:58 AM
> > > Subject: [msp430] SPI Problems
> > >
> > >
> > >
> > > I am working to communicate with an ATMEL AT45DB081B dataflash
> >
> > in
> >
> > > SPI Mode with a MSP430-149. The opcode sent to the flash
should
> >
> > make
> >
> > > it do a continuous read so I should continuously be receiving
> >
> > data
> >
> > > but instead I receive a few bytes and then it stops. The flash
> >
> > needs
> >
> > > SPI Mode 0 or 3 and needs a high to low transition on pin 3.0
> >
> > before
> >
> > > a opcode is sent. I believe I have the initializations right
>
> but
>
> > I
> >
> > > need some help debugging. I have an 8Mhz crystal on installed
>
> on
>
> > the
> >
> > > XT2CLK. Any problems found, advice, or anything would be of
>
> help
>
> > as
> >
> > > I need to get this going.
> > >
> > > void main(void)
> > > {
> > > unsigned int dco_cnt;
> > > BCSCTL1 &= ~XT2OFF; // XT2on
> > > do // wait for MCLK from quartz
> > > {
> > > IFG1 &= ~OFIFG; // Clear OSCFault
flag
> > > for (dco_cnt = 0xff; dco_cnt > 0; dco_cnt--
> >
> > ); //
> >
> > > Time for flag to set
> > > }
> > > while ((IFG1 & OFIFG) != 0); // OSCFault flag
>
> still
>
> > set?
> >
> > > WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
> > >
> > > BCSCTL1 = 0x07; // LFXT1: XT2on: LF quartz
for
> >
> > MCLK
> >
> > > P3SEL |= 0x0E; // P5.1-3 SPI option select
> > > P3DIR |= 0x01; // P5.0 output direction
> > > P3OUT = 0xff;
> > > ME1 |= USPIE0; // Enable USART1 SPI mode
> > > UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; // SMCLK, 3-
> >
> > pin
> >
> > > mode, clock idle low, data valid on rising edge, UCLK delayed
> > > UBR00 = 0x02; // 0x02: UCLK/2 (4
MHz),
> > > works also with 3 and 4
> > > UBR10 = 0x00; // -"-
> > > UMCTL0 = 0x00; // no modulation
> > > UCTL0 = CHAR | SYNC | MM; // 8-bit SPI Master
> >
> > **SWRST**
> >
> > > IE1 |= URXIE0;
> > > _EINT();
> > >
> > > P1DIR |= 0x01;
> > >
> > > continuous_Read(S1_B1,S1_B2,S1_B3);
> > >
> > > for(;;)
> > > {
> > > }
> > > }
> > >
> > > #pragma vector=USART0RX_VECTOR
> > > __interrupt void SPI0_RX (void)
> > > {
> > >
> > > P1OUT ^= 0x01; //Toggle light to show data is
> >
> > received
> >
> > > {
> > > unsigned int y;
> > > y = 50000; // Delay
> > > do (y--);
> > > while (y != 0);
> > > y = 50000; // Delay
> > > do (y--);
> > > while (y != 0);
> > > }
> > >
> > >
> > > }
> > > void continuous_Read(int Byte1, int Byte2, int Byte3)
> > > {
> > > CS_LOW();
> > > //P3OUT ^= 0x01; //Reset Memory
to
> > > assure proper timing
> > > i = 50000; // Delay
> > > do (i--);
> > > while (i != 0);
> > >
> > > //Flash needs opcode +24 bits of start
address
>
> +
>
> > 32
> >
> > > don't care bits
> > > U0TXBUF = 0xE8; //opcode for
> > > continous array read
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = Byte1; //First Byte of
> >
> > 24-
> >
> > > bit address sequence
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = Byte2; //Second Byte
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = Byte3; //Third Byte
> > >
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = 0xFF; //First byte of
>
> 32-
>
> > > don't care bits
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = 0xFF; //Second Byte
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = 0xFF; //Third Byte
> > > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
>
> buffer
>
> > > ready?
> > > U0TXBUF = 0xFF; //Final Byte
> > > }
> > >
> > >
> > >
> > >
> > >
> > > .
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------
>
> -
>
> > -----------
> >
> > > .
Reply by budfrog99●March 26, 20052005-03-26
"...I thought the SPI had its own clock line ..."
Nope. There is a master and slave(s). The master provides the clock
whenever it wants something to happen on the SPI.
Lee
--- In msp430@msp4..., "bigdog16_83" <bigdog16_83@y...> wrote:
>
> Does this not defeat the whole advantage of the SPI? I thought the
> SPI had its own clock line which transfer and receive data was
> attached to each of the edges? This also defeats my purpose. I'm
> using this to have the flash (storing a .wav file) send the file
> back to the MSP which will direct it out to an external DAC. If I
am
> misunderstanding the SPI please explain more.
>
> --- In msp430@msp4..., "Matt Sabino" <msabino@a...> wrote:
> > Since the Atmel dataflash is a SPI slave device, it doesn't put
> any information out on the SPI bus unless you clock it. Just stuff
> U0TXBUF with a value like 0x00 (or some other arbitrary value) for
> every time you want to read a byte.
> >
> > HTH,
> >
> >
> > Matt Sabino
> > Computer Engineer
> > Airtronic Services, Inc.
> >
> > ----- Original Message -----
> > From: bigdog16_83
> > To: msp430@msp4...
> > Sent: Friday, March 25, 2005 11:58 AM
> > Subject: [msp430] SPI Problems
> >
> >
> >
> > I am working to communicate with an ATMEL AT45DB081B dataflash
> in
> > SPI Mode with a MSP430-149. The opcode sent to the flash should
> make
> > it do a continuous read so I should continuously be receiving
> data
> > but instead I receive a few bytes and then it stops. The flash
> needs
> > SPI Mode 0 or 3 and needs a high to low transition on pin 3.0
> before
> > a opcode is sent. I believe I have the initializations right
but
> I
> > need some help debugging. I have an 8Mhz crystal on installed
on
> the
> > XT2CLK. Any problems found, advice, or anything would be of
help
> as
> > I need to get this going.
> >
> > void main(void)
> > {
> > unsigned int dco_cnt;
> > BCSCTL1 &= ~XT2OFF; // XT2on
> > do // wait for MCLK from quartz
> > {
> > IFG1 &= ~OFIFG; // Clear OSCFault flag
> > for (dco_cnt = 0xff; dco_cnt > 0; dco_cnt--
> ); //
> > Time for flag to set
> > }
> > while ((IFG1 & OFIFG) != 0); // OSCFault flag
still
> set?
> >
> > WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
> >
> > BCSCTL1 = 0x07; // LFXT1: XT2on: LF quartz for
> MCLK
> >
> > P3SEL |= 0x0E; // P5.1-3 SPI option select
> > P3DIR |= 0x01; // P5.0 output direction
> > P3OUT = 0xff;
> > ME1 |= USPIE0; // Enable USART1 SPI mode
> > UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; // SMCLK, 3-
> pin
> > mode, clock idle low, data valid on rising edge, UCLK delayed
> > UBR00 = 0x02; // 0x02: UCLK/2 (4 MHz),
> > works also with 3 and 4
> > UBR10 = 0x00; // -"-
> > UMCTL0 = 0x00; // no modulation
> > UCTL0 = CHAR | SYNC | MM; // 8-bit SPI Master
> **SWRST**
> > IE1 |= URXIE0;
> > _EINT();
> >
> > P1DIR |= 0x01;
> >
> > continuous_Read(S1_B1,S1_B2,S1_B3);
> >
> > for(;;)
> > {
> > }
> > }
> >
> > #pragma vector=USART0RX_VECTOR
> > __interrupt void SPI0_RX (void)
> > {
> >
> > P1OUT ^= 0x01; //Toggle light to show data is
> received
> > {
> > unsigned int y;
> > y = 50000; // Delay
> > do (y--);
> > while (y != 0);
> > y = 50000; // Delay
> > do (y--);
> > while (y != 0);
> > }
> >
> >
> > }
> > void continuous_Read(int Byte1, int Byte2, int Byte3)
> > {
> > CS_LOW();
> > //P3OUT ^= 0x01; //Reset Memory to
> > assure proper timing
> > i = 50000; // Delay
> > do (i--);
> > while (i != 0);
> >
> > //Flash needs opcode +24 bits of start address
+
> 32
> > don't care bits
> > U0TXBUF = 0xE8; //opcode for
> > continous array read
> > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
buffer
> > ready?
> > U0TXBUF = Byte1; //First Byte of
> 24-
> > bit address sequence
> > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
buffer
> > ready?
> > U0TXBUF = Byte2; //Second Byte
> > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
buffer
> > ready?
> > U0TXBUF = Byte3; //Third Byte
> >
> > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
buffer
> > ready?
> > U0TXBUF = 0xFF; //First byte of
32-
> > don't care bits
> > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
buffer
> > ready?
> > U0TXBUF = 0xFF; //Second Byte
> > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
buffer
> > ready?
> > U0TXBUF = 0xFF; //Third Byte
> > while ((IFG1 & UTXIFG0) == 0); // USART0 TX
buffer
> > ready?
> > U0TXBUF = 0xFF; //Final Byte
> > }
> >
> >
> >
> >
> >
> > .
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------
-
> -----------
> > Yahoo! Groups Links
> >
> > a.. To visit your group on the web, go to:
> > http://groups.yahoo.com/group/msp430/
> >
> > b.. .
> >
> > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms
> of Service.
> >
> >
> >
> >
> > ------------------------------
-
> -----------
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.308 / Virus Database: 266.8.2 - Release Date:
> 3/25/2005
> >
> > ----------
> >
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.308 / Virus Database: 266.8.2 - Release Date:
> 3/25/2005
> >
> >
> >
Reply by bigdog16_83●March 26, 20052005-03-26
Does this not defeat the whole advantage of the SPI? I thought the
SPI had its own clock line which transfer and receive data was
attached to each of the edges? This also defeats my purpose. I'm
using this to have the flash (storing a .wav file) send the file
back to the MSP which will direct it out to an external DAC. If I am
misunderstanding the SPI please explain more.
--- In msp430@msp4..., "Matt Sabino" <msabino@a...> wrote:
> Since the Atmel dataflash is a SPI slave device,
it doesn't put
any information out on the SPI bus unless you clock it. Just stuff
U0TXBUF with a value like 0x00 (or some other arbitrary value) for
every time you want to read a byte.
>
> HTH,
>
>
> Matt Sabino
> Computer Engineer
> Airtronic Services, Inc.
>
> ----- Original Message -----
> From: bigdog16_83
> To: msp430@msp4...
> Sent: Friday, March 25, 2005 11:58 AM
> Subject: [msp430] SPI Problems
>
>
>
> I am working to communicate with an ATMEL AT45DB081B dataflash
in
> SPI Mode with a MSP430-149. The opcode sent to
the flash should
make
> it do a continuous read so I should continuously
be receiving
data
> but instead I receive a few bytes and then it
stops. The flash
needs
> SPI Mode 0 or 3 and needs a high to low
transition on pin 3.0
before
> a opcode is sent. I believe I have the
initializations right but
I
> need some help debugging. I have an 8Mhz crystal
on installed on
the
> XT2CLK. Any problems found, advice, or anything
would be of help
as
> I need to get this going.
>
> void main(void)
> {
> unsigned int dco_cnt;
> BCSCTL1 &= ~XT2OFF; // XT2on
> do // wait for MCLK from quartz
> {
> IFG1 &= ~OFIFG; // Clear OSCFault flag
> for (dco_cnt = 0xff; dco_cnt > 0; dco_cnt--
); //
> Time for flag to set
> }
> while ((IFG1 & OFIFG) != 0); // OSCFault flag still
set?
>
> WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
>
> BCSCTL1 = 0x07; // LFXT1: XT2on: LF quartz for
MCLK
>
> P3SEL |= 0x0E; // P5.1-3 SPI option select
> P3DIR |= 0x01; // P5.0 output direction
> P3OUT = 0xff;
> ME1 |= USPIE0; // Enable USART1 SPI mode
> UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; // SMCLK, 3-
pin
> mode, clock idle low, data valid on rising edge,
UCLK delayed
> UBR00 = 0x02; // 0x02: UCLK/2 (4 MHz),
> works also with 3 and 4
> UBR10 = 0x00; // -"-
> UMCTL0 = 0x00; // no modulation
> UCTL0 = CHAR | SYNC | MM; // 8-bit SPI Master
**SWRST**
> IE1 |= URXIE0;
> _EINT();
>
> P1DIR |= 0x01;
>
> continuous_Read(S1_B1,S1_B2,S1_B3);
>
> for(;;)
> {
> }
> }
>
> #pragma vector=USART0RX_VECTOR
> __interrupt void SPI0_RX (void)
> {
>
> P1OUT ^= 0x01; //Toggle light to show data is
received
> {
> unsigned int y;
> y = 50000; // Delay
> do (y--);
> while (y != 0);
> y = 50000; // Delay
> do (y--);
> while (y != 0);
> }
>
>
> }
> void continuous_Read(int Byte1, int Byte2, int Byte3)
> {
> CS_LOW();
> //P3OUT ^= 0x01; //Reset Memory to
> assure proper timing
> i = 50000; // Delay
> do (i--);
> while (i != 0);
>
> //Flash needs opcode +24 bits of start address +
32
> don't care bits
> U0TXBUF = 0xE8; //opcode for
> continous array read
> while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
> ready?
> U0TXBUF = Byte1; //First Byte of
24-
> bit address sequence
> while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
> ready?
> U0TXBUF = Byte2; //Second Byte
> while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
> ready?
> U0TXBUF = Byte3; //Third Byte
>
> while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
> ready?
> U0TXBUF = 0xFF; //First byte of 32-
> don't care bits
> while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
> ready?
> U0TXBUF = 0xFF; //Second Byte
> while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
> ready?
> U0TXBUF = 0xFF; //Third Byte
> while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
> ready?
> U0TXBUF = 0xFF; //Final Byte
> }
>
>
>
>
>
> .
>
>
>
>
>
>
>
>
>
>
> -------------------------------
-----------
> Yahoo! Groups Links
>
> a.. To visit your group on the web, go to:
> http://groups.yahoo.com/group/msp430/
>
> b.. .
>
> c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms
of Service.
>
>
>
>
> -------------------------------
-----------
>
>
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.2 - Release Date:
3/25/2005
>
> ----------
>
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.2 - Release Date:
3/25/2005
>
>
>
Reply by Matt Sabino●March 25, 20052005-03-25
Since the Atmel dataflash is a SPI slave device, it doesn't put any
information out on the SPI bus unless you clock it. Just stuff U0TXBUF with a
value like 0x00 (or some other arbitrary value) for every time you want to read
a byte.
HTH,
Matt Sabino
Computer Engineer
Airtronic Services, Inc.
----- Original Message -----
From: bigdog16_83
To: msp430@msp4...
Sent: Friday, March 25, 2005 11:58 AM
Subject: [msp430] SPI Problems
I am working to communicate with an ATMEL AT45DB081B dataflash in
SPI Mode with a MSP430-149. The opcode sent to the flash should make
it do a continuous read so I should continuously be receiving data
but instead I receive a few bytes and then it stops. The flash needs
SPI Mode 0 or 3 and needs a high to low transition on pin 3.0 before
a opcode is sent. I believe I have the initializations right but I
need some help debugging. I have an 8Mhz crystal on installed on the
XT2CLK. Any problems found, advice, or anything would be of help as
I need to get this going.
void main(void)
{
unsigned int dco_cnt;
BCSCTL1 &= ~XT2OFF; // XT2on
do // wait for MCLK from quartz
{
IFG1 &= ~OFIFG; // Clear OSCFault flag
for (dco_cnt = 0xff; dco_cnt > 0; dco_cnt--); //
Time for flag to set
}
while ((IFG1 & OFIFG) != 0); // OSCFault flag still set?
WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
BCSCTL1 = 0x07; // LFXT1: XT2on: LF quartz for MCLK
P3SEL |= 0x0E; // P5.1-3 SPI option select
P3DIR |= 0x01; // P5.0 output direction
P3OUT = 0xff;
ME1 |= USPIE0; // Enable USART1 SPI mode
UTCTL0 = CKPH | SSEL1 | SSEL0 | STC; // SMCLK, 3-pin
mode, clock idle low, data valid on rising edge, UCLK delayed
UBR00 = 0x02; // 0x02: UCLK/2 (4 MHz),
works also with 3 and 4
UBR10 = 0x00; // -"-
UMCTL0 = 0x00; // no modulation
UCTL0 = CHAR | SYNC | MM; // 8-bit SPI Master **SWRST**
IE1 |= URXIE0;
_EINT();
P1DIR |= 0x01;
continuous_Read(S1_B1,S1_B2,S1_B3);
for(;;)
{
}
}
#pragma vector=USART0RX_VECTOR
__interrupt void SPI0_RX (void)
{
P1OUT ^= 0x01; //Toggle light to show data is received
{
unsigned int y;
y = 50000; // Delay
do (y--);
while (y != 0);
y = 50000; // Delay
do (y--);
while (y != 0);
}
}
void continuous_Read(int Byte1, int Byte2, int Byte3)
{
CS_LOW();
//P3OUT ^= 0x01; //Reset Memory to
assure proper timing
i = 50000; // Delay
do (i--);
while (i != 0);
//Flash needs opcode +24 bits of start address + 32
don't care bits
U0TXBUF = 0xE8; //opcode for
continous array read
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = Byte1; //First Byte of 24-
bit address sequence
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = Byte2; //Second Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = Byte3; //Third Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //First byte of 32-
don't care bits
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //Second Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //Third Byte
while ((IFG1 & UTXIFG0) == 0); // USART0 TX buffer
ready?
U0TXBUF = 0xFF; //Final Byte
}
.
------
.
------
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: 3/25/2005
----------
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.2 - Release Date: 3/25/2005