Shouldn't you check every time, in case you get a BUSY status?
Meaning you should wait and retry?
Not that is has ever happened, but I do provide for it, am I wasting effort and
time?
From: m... [mailto:m...] On Behalf Of Onestone
Sent: Thursday, October 04, 2012 1:32 PM
To: m...
Subject: Re: [msp430] Re: MSP430F2619 DMA block transfer
A status check is always a good thing, but check your memory data sheet,
I believe that some memories, in fact the 4 I've just looked at, return
status on the byte after the command byte, and every byte thereafter
when writing the memory, so it is a simple case of enabling the SPI
receive and checking the returned data.
My typical SPI sequence looks something like:-
set transaction length
enable ISR
send command byte to start things going.
in ISR, on first call enable RX isr
load next byte in to buffer
the Rx isr then collects stsua.
OR you can run only on the RX isr and get status every transmit, so the
isr does:-
get rxbuffer
send next byte
packet length checks
and you can decide when you want to actually test the status.
Al
On 5/10/2012 2:01 AM, Hugo Brunert wrote:
> I may be wrong, but I thought you needed STATUS in
between CMD & ADDRs & data.
>
> At least I use it. Am I wasting time by using status en between each Xfer?
>
>
>
> From: m... [mailto:ms...
] On Behalf Of favero.santos
> Sent: Thursday, October 04, 2012 12:27 PM
> To: m...
> Subject: [msp430] Re: MSP430F2619 DMA block transfer
>
>
>
>
>
> Hello, Felipe.
>
> Nice to find another brazilian in this forum.
>
> DMA0SA = (int)&endereco+1;
> this means DMA should use as source address the next byte of the int
endereco.
>
> Example:
> int endereco 0x2010.
> In memory, it will be stored as:
> 0x10 0x20.
> Writing the cmd as i did, 0x20 will be pointed firstly (if DMA0SA =
(int)&endereco, 0x10 will be pointed firstly).
>
> Anyway, i found another solution:
>
> I'll make a block of CMD (1byte) + ADDS (2 bytes) + data (1k byte) and
send as an unique block (the way first way was sending with DMA separated
blocks!)
>
> Cheers!
>
> --- In m...
, Luis Rossi wrote:
>> But what is the problem? Wrong data at SPI port, or no data at all? Still
>> you are going to have a problem with your trigger as it wont wait untill
>> the SPI TX buffer is empty to send the new data.
>>
>> And what is the meaning of this cast?
>>
>> DMA0SA = (int)&endereco+1;
>>
>> Regards,
>>
>> --
>> Lu Filipe Rossi
>> Electrical Engineer
>> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
>> Escola Politnica
>> Universidade de S Paulo
>> Cel. +55 (11) 7662-9234
>>
>>
>
>
>
>
>
MSP430F2619 DMA block transfer
Started by ●October 4, 2012
Reply by ●October 4, 20122012-10-04
Reply by ●October 4, 20122012-10-04
Hello, Onestone
Finally, got it working :)
Check it out:
/* These guys are my data i'm kicking off SPI with DMA */
ALS[1] = 0x00; // ADDR, MSByte
ALS[2] = 0x00; // ADDR, LSByte
ALS[3] = 0x55; // From here to AL[6], just some values i added */
ALS[4] = 0x55;
ALS[5] = 0x66;
ALS[6] = 0x77;
DMACTL0 = 0;
// Cleans DMA0 register
DMACTL0 |= DMA0TSEL_13;
// Trigger source as UCB0TX Interrupt flag
DMA0CTL |= DMASRCINCR_3 + DMADSTINCR_0 + DMADT_0 + DMASBDB;
// DMASRCINCR_3 -> Source add increment
// DMADSTINCR_0 -> Destination add without increment/decrement
// DMADT_0 -> Single transfer
// DMASBDB -> Byte to Byte transfer
DMA0SA = (unsigned short)&ALS + 1;
// Source addrs: I'm pointing to ALS[1] instead of ALS[0]
DMA0DA = (unsigned short)&UCB0TXBUF;
// Destination addrs: Pointing to transfer buffer
DMA0SZ = 6;
// Transfer size, in bytes
CS_LOW();
// A chip select in my device (RAM 23k256)
DMA0CTL |= DMAEN + DMAREQ;
// An enable for DMA
ram_send_byte(0x02);
// Kickoff firts byte (CMD byte) to start block transfer
while(DMA0SZ == 0){};
// Do DMA transfer while there's data to be sent
CS_HIGH();
// Deassert CS
Scope shows me a perfect and smooth data transmission.
Reading the address from RAM returns me data sent to be stored.
Cheers
On Thu, Oct 4, 2012 at 2:32 PM, Onestone wrote:
> **
> A status check is always a good thing, but check your memory data sheet,
> I believe that some memories, in fact the 4 I've just looked at, return
> status on the byte after the command byte, and every byte thereafter
> when writing the memory, so it is a simple case of enabling the SPI
> receive and checking the returned data.
>
> My typical SPI sequence looks something like:-
>
> set transaction length
> enable ISR
> send command byte to start things going.
>
> in ISR, on first call enable RX isr
> load next byte in to buffer
>
> the Rx isr then collects stsua.
>
> OR you can run only on the RX isr and get status every transmit, so the
> isr does:-
>
> get rxbuffer
> send next byte
> packet length checks
>
> and you can decide when you want to actually test the status.
>
> Al
> On 5/10/2012 2:01 AM, Hugo Brunert wrote:
> > I may be wrong, but I thought you needed STATUS in between CMD & ADDRs &
> data.
> >
> > At least I use it. Am I wasting time by using status en between each
> Xfer?
> >
> >
> >
> > From: m... [mailto:m...] On Behalf
> Of favero.santos
> > Sent: Thursday, October 04, 2012 12:27 PM
> > To: m...
> > Subject: [msp430] Re: MSP430F2619 DMA block transfer
> >
> >
> >
> >
> >
> > Hello, Felipe.
> >
> > Nice to find another brazilian in this forum.
> >
> > DMA0SA = (int)&endereco+1;
> > this means DMA should use as source address the next byte of the int
> endereco.
> >
> > Example:
> > int endereco 0x2010.
> > In memory, it will be stored as:
> > 0x10 0x20.
> > Writing the cmd as i did, 0x20 will be pointed firstly (if DMA0SA =
> (int)&endereco, 0x10 will be pointed firstly).
> >
> > Anyway, i found another solution:
> >
> > I'll make a block of CMD (1byte) + ADDS (2 bytes) + data (1k byte) and
> send as an unique block (the way first way was sending with DMA separated
> blocks!)
> >
> > Cheers!
> >
> > --- In m... , Luis
> Rossi wrote:
> >> But what is the problem? Wrong data at SPI port, or no data at all?
> Still
> >> you are going to have a problem with your trigger as it wont wait untill
> >> the SPI TX buffer is empty to send the new data.
> >>
> >> And what is the meaning of this cast?
> >>
> >> DMA0SA = (int)&endereco+1;
> >>
> >> Regards,
> >>
> >> --
> >> Lu Filipe Rossi
> >> Electrical Engineer
> >> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
> >> Escola Politnica
> >> Universidade de S Paulo
> >> Cel. +55 (11) 7662-9234
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> >
> >
> >
> >
Finally, got it working :)
Check it out:
/* These guys are my data i'm kicking off SPI with DMA */
ALS[1] = 0x00; // ADDR, MSByte
ALS[2] = 0x00; // ADDR, LSByte
ALS[3] = 0x55; // From here to AL[6], just some values i added */
ALS[4] = 0x55;
ALS[5] = 0x66;
ALS[6] = 0x77;
DMACTL0 = 0;
// Cleans DMA0 register
DMACTL0 |= DMA0TSEL_13;
// Trigger source as UCB0TX Interrupt flag
DMA0CTL |= DMASRCINCR_3 + DMADSTINCR_0 + DMADT_0 + DMASBDB;
// DMASRCINCR_3 -> Source add increment
// DMADSTINCR_0 -> Destination add without increment/decrement
// DMADT_0 -> Single transfer
// DMASBDB -> Byte to Byte transfer
DMA0SA = (unsigned short)&ALS + 1;
// Source addrs: I'm pointing to ALS[1] instead of ALS[0]
DMA0DA = (unsigned short)&UCB0TXBUF;
// Destination addrs: Pointing to transfer buffer
DMA0SZ = 6;
// Transfer size, in bytes
CS_LOW();
// A chip select in my device (RAM 23k256)
DMA0CTL |= DMAEN + DMAREQ;
// An enable for DMA
ram_send_byte(0x02);
// Kickoff firts byte (CMD byte) to start block transfer
while(DMA0SZ == 0){};
// Do DMA transfer while there's data to be sent
CS_HIGH();
// Deassert CS
Scope shows me a perfect and smooth data transmission.
Reading the address from RAM returns me data sent to be stored.
Cheers
On Thu, Oct 4, 2012 at 2:32 PM, Onestone wrote:
> **
> A status check is always a good thing, but check your memory data sheet,
> I believe that some memories, in fact the 4 I've just looked at, return
> status on the byte after the command byte, and every byte thereafter
> when writing the memory, so it is a simple case of enabling the SPI
> receive and checking the returned data.
>
> My typical SPI sequence looks something like:-
>
> set transaction length
> enable ISR
> send command byte to start things going.
>
> in ISR, on first call enable RX isr
> load next byte in to buffer
>
> the Rx isr then collects stsua.
>
> OR you can run only on the RX isr and get status every transmit, so the
> isr does:-
>
> get rxbuffer
> send next byte
> packet length checks
>
> and you can decide when you want to actually test the status.
>
> Al
> On 5/10/2012 2:01 AM, Hugo Brunert wrote:
> > I may be wrong, but I thought you needed STATUS in between CMD & ADDRs &
> data.
> >
> > At least I use it. Am I wasting time by using status en between each
> Xfer?
> >
> >
> >
> > From: m... [mailto:m...] On Behalf
> Of favero.santos
> > Sent: Thursday, October 04, 2012 12:27 PM
> > To: m...
> > Subject: [msp430] Re: MSP430F2619 DMA block transfer
> >
> >
> >
> >
> >
> > Hello, Felipe.
> >
> > Nice to find another brazilian in this forum.
> >
> > DMA0SA = (int)&endereco+1;
> > this means DMA should use as source address the next byte of the int
> endereco.
> >
> > Example:
> > int endereco 0x2010.
> > In memory, it will be stored as:
> > 0x10 0x20.
> > Writing the cmd as i did, 0x20 will be pointed firstly (if DMA0SA =
> (int)&endereco, 0x10 will be pointed firstly).
> >
> > Anyway, i found another solution:
> >
> > I'll make a block of CMD (1byte) + ADDS (2 bytes) + data (1k byte) and
> send as an unique block (the way first way was sending with DMA separated
> blocks!)
> >
> > Cheers!
> >
> > --- In m... , Luis
> Rossi wrote:
> >> But what is the problem? Wrong data at SPI port, or no data at all?
> Still
> >> you are going to have a problem with your trigger as it wont wait untill
> >> the SPI TX buffer is empty to send the new data.
> >>
> >> And what is the meaning of this cast?
> >>
> >> DMA0SA = (int)&endereco+1;
> >>
> >> Regards,
> >>
> >> --
> >> Lu Filipe Rossi
> >> Electrical Engineer
> >> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
> >> Escola Politnica
> >> Universidade de S Paulo
> >> Cel. +55 (11) 7662-9234
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> >
> >
> >
> >
Reply by ●October 4, 20122012-10-04
In my opinion yes. Check after the command has completed, ie data
transferred, you are crippling the SPI by checking status every byte
transfer.
Al
On 5/10/2012 3:45 AM, Hugo Brunert wrote:
> Shouldn't you check every time, in case you get a BUSY status?
>
> Meaning you should wait and retry?
>
> Not that is has ever happened, but I do provide for it, am I wasting effort and time?
>
>
>
> From: m... [mailto:m...] On Behalf Of Onestone
> Sent: Thursday, October 04, 2012 1:32 PM
> To: m...
> Subject: Re: [msp430] Re: MSP430F2619 DMA block transfer
>
>
>
>
>
> A status check is always a good thing, but check your memory data sheet,
> I believe that some memories, in fact the 4 I've just looked at, return
> status on the byte after the command byte, and every byte thereafter
> when writing the memory, so it is a simple case of enabling the SPI
> receive and checking the returned data.
>
> My typical SPI sequence looks something like:-
>
> set transaction length
> enable ISR
> send command byte to start things going.
>
> in ISR, on first call enable RX isr
> load next byte in to buffer
>
> the Rx isr then collects stsua.
>
> OR you can run only on the RX isr and get status every transmit, so the
> isr does:-
>
> get rxbuffer
> send next byte
> packet length checks
>
> and you can decide when you want to actually test the status.
>
> Al
>
> On 5/10/2012 2:01 AM, Hugo Brunert wrote:
>> I may be wrong, but I thought you needed STATUS in between CMD & ADDRs & data.
>>
>> At least I use it. Am I wasting time by using status en between each Xfer?
>>
>> From: m... [mailto:m... ] On Behalf Of favero.santos
>> Sent: Thursday, October 04, 2012 12:27 PM
>> To: m...
>> Subject: [msp430] Re: MSP430F2619 DMA block transfer
>>
>> Hello, Felipe.
>>
>> Nice to find another brazilian in this forum.
>>
>> DMA0SA = (int)&endereco+1;
>> this means DMA should use as source address the next byte of the int endereco.
>>
>> Example:
>> int endereco 0x2010.
>> In memory, it will be stored as:
>> 0x10 0x20.
>> Writing the cmd as i did, 0x20 will be pointed firstly (if DMA0SA = (int)&endereco, 0x10 will be pointed firstly).
>>
>> Anyway, i found another solution:
>>
>> I'll make a block of CMD (1byte) + ADDS (2 bytes) + data (1k byte) and send as an unique block (the way first way was sending with DMA separated blocks!)
>>
>> Cheers!
>>
>> --- In m... , Luis Rossi wrote:
>>> But what is the problem? Wrong data at SPI port, or no data at all? Still
>>> you are going to have a problem with your trigger as it wont wait untill
>>> the SPI TX buffer is empty to send the new data.
>>>
>>> And what is the meaning of this cast?
>>>
>>> DMA0SA = (int)&endereco+1;
>>>
>>> Regards,
>>>
>>> --
>>> Lu Filipe Rossi
>>> Electrical Engineer
>>> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
>>> Escola Politnica
>>> Universidade de S Paulo
>>> Cel. +55 (11) 7662-9234
>>>
>>>
>>>
>>>
>>
>>
>>
>>
transferred, you are crippling the SPI by checking status every byte
transfer.
Al
On 5/10/2012 3:45 AM, Hugo Brunert wrote:
> Shouldn't you check every time, in case you get a BUSY status?
>
> Meaning you should wait and retry?
>
> Not that is has ever happened, but I do provide for it, am I wasting effort and time?
>
>
>
> From: m... [mailto:m...] On Behalf Of Onestone
> Sent: Thursday, October 04, 2012 1:32 PM
> To: m...
> Subject: Re: [msp430] Re: MSP430F2619 DMA block transfer
>
>
>
>
>
> A status check is always a good thing, but check your memory data sheet,
> I believe that some memories, in fact the 4 I've just looked at, return
> status on the byte after the command byte, and every byte thereafter
> when writing the memory, so it is a simple case of enabling the SPI
> receive and checking the returned data.
>
> My typical SPI sequence looks something like:-
>
> set transaction length
> enable ISR
> send command byte to start things going.
>
> in ISR, on first call enable RX isr
> load next byte in to buffer
>
> the Rx isr then collects stsua.
>
> OR you can run only on the RX isr and get status every transmit, so the
> isr does:-
>
> get rxbuffer
> send next byte
> packet length checks
>
> and you can decide when you want to actually test the status.
>
> Al
>
> On 5/10/2012 2:01 AM, Hugo Brunert wrote:
>> I may be wrong, but I thought you needed STATUS in between CMD & ADDRs & data.
>>
>> At least I use it. Am I wasting time by using status en between each Xfer?
>>
>> From: m... [mailto:m... ] On Behalf Of favero.santos
>> Sent: Thursday, October 04, 2012 12:27 PM
>> To: m...
>> Subject: [msp430] Re: MSP430F2619 DMA block transfer
>>
>> Hello, Felipe.
>>
>> Nice to find another brazilian in this forum.
>>
>> DMA0SA = (int)&endereco+1;
>> this means DMA should use as source address the next byte of the int endereco.
>>
>> Example:
>> int endereco 0x2010.
>> In memory, it will be stored as:
>> 0x10 0x20.
>> Writing the cmd as i did, 0x20 will be pointed firstly (if DMA0SA = (int)&endereco, 0x10 will be pointed firstly).
>>
>> Anyway, i found another solution:
>>
>> I'll make a block of CMD (1byte) + ADDS (2 bytes) + data (1k byte) and send as an unique block (the way first way was sending with DMA separated blocks!)
>>
>> Cheers!
>>
>> --- In m... , Luis Rossi wrote:
>>> But what is the problem? Wrong data at SPI port, or no data at all? Still
>>> you are going to have a problem with your trigger as it wont wait untill
>>> the SPI TX buffer is empty to send the new data.
>>>
>>> And what is the meaning of this cast?
>>>
>>> DMA0SA = (int)&endereco+1;
>>>
>>> Regards,
>>>
>>> --
>>> Lu Filipe Rossi
>>> Electrical Engineer
>>> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
>>> Escola Politnica
>>> Universidade de S Paulo
>>> Cel. +55 (11) 7662-9234
>>>
>>>
>>>
>>>
>>
>>
>>
>>
Reply by ●October 4, 20122012-10-04
Good, glad you managed to solve your problems.
Al
On 5/10/2012 3:49 AM, Fero Santos wrote:
> Hello, Onestone
>
> Finally, got it working :)
>
> Check it out:
> /* These guys are my data i'm kicking off SPI with DMA */
>
> ALS[1] = 0x00; // ADDR, MSByte
> ALS[2] = 0x00; // ADDR, LSByte
> ALS[3] = 0x55; // From here to AL[6], just some values i added */
> ALS[4] = 0x55;
> ALS[5] = 0x66;
> ALS[6] = 0x77;
>
> DMACTL0 = 0;
> // Cleans DMA0 register
> DMACTL0 |= DMA0TSEL_13;
> // Trigger source as UCB0TX Interrupt flag
> DMA0CTL |= DMASRCINCR_3 + DMADSTINCR_0 + DMADT_0 + DMASBDB;
> // DMASRCINCR_3 -> Source add increment
> // DMADSTINCR_0 -> Destination add without increment/decrement
> // DMADT_0 -> Single transfer
> // DMASBDB -> Byte to Byte transfer
>
> DMA0SA = (unsigned short)&ALS + 1;
> // Source addrs: I'm pointing to ALS[1] instead of ALS[0]
>
> DMA0DA = (unsigned short)&UCB0TXBUF;
> // Destination addrs: Pointing to transfer buffer
>
> DMA0SZ = 6;
> // Transfer size, in bytes
>
> CS_LOW();
> // A chip select in my device (RAM 23k256)
>
> DMA0CTL |= DMAEN + DMAREQ;
> // An enable for DMA
>
> ram_send_byte(0x02);
> // Kickoff firts byte (CMD byte) to start block transfer
>
> while(DMA0SZ == 0){};
> // Do DMA transfer while there's data to be sent
>
> CS_HIGH();
> // Deassert CS
>
> Scope shows me a perfect and smooth data transmission.
> Reading the address from RAM returns me data sent to be stored.
>
> Cheers
> On Thu, Oct 4, 2012 at 2:32 PM, Onestone wrote:
>
>> **
>> A status check is always a good thing, but check your memory data sheet,
>> I believe that some memories, in fact the 4 I've just looked at, return
>> status on the byte after the command byte, and every byte thereafter
>> when writing the memory, so it is a simple case of enabling the SPI
>> receive and checking the returned data.
>>
>> My typical SPI sequence looks something like:-
>>
>> set transaction length
>> enable ISR
>> send command byte to start things going.
>>
>> in ISR, on first call enable RX isr
>> load next byte in to buffer
>>
>> the Rx isr then collects stsua.
>>
>> OR you can run only on the RX isr and get status every transmit, so the
>> isr does:-
>>
>> get rxbuffer
>> send next byte
>> packet length checks
>>
>> and you can decide when you want to actually test the status.
>>
>> Al
>> On 5/10/2012 2:01 AM, Hugo Brunert wrote:
>>> I may be wrong, but I thought you needed STATUS in between CMD & ADDRs &
>> data.
>>> At least I use it. Am I wasting time by using status en between each
>> Xfer?
>>>
>>>
>>> From: m... [mailto:m...] On Behalf
>> Of favero.santos
>>> Sent: Thursday, October 04, 2012 12:27 PM
>>> To: m...
>>> Subject: [msp430] Re: MSP430F2619 DMA block transfer
>>>
>>>
>>>
>>>
>>>
>>> Hello, Felipe.
>>>
>>> Nice to find another brazilian in this forum.
>>>
>>> DMA0SA = (int)&endereco+1;
>>> this means DMA should use as source address the next byte of the int
>> endereco.
>>> Example:
>>> int endereco 0x2010.
>>> In memory, it will be stored as:
>>> 0x10 0x20.
>>> Writing the cmd as i did, 0x20 will be pointed firstly (if DMA0SA >> (int)&endereco, 0x10 will be pointed firstly).
>>> Anyway, i found another solution:
>>>
>>> I'll make a block of CMD (1byte) + ADDS (2 bytes) + data (1k byte) and
>> send as an unique block (the way first way was sending with DMA separated
>> blocks!)
>>> Cheers!
>>>
>>> --- In m... , Luis
>> Rossi wrote:
>>>> But what is the problem? Wrong data at SPI port, or no data at all?
>> Still
>>>> you are going to have a problem with your trigger as it wont wait untill
>>>> the SPI TX buffer is empty to send the new data.
>>>>
>>>> And what is the meaning of this cast?
>>>>
>>>> DMA0SA = (int)&endereco+1;
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Lu Filipe Rossi
>>>> Electrical Engineer
>>>> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
>>>> Escola Politnica
>>>> Universidade de S Paulo
>>>> Cel. +55 (11) 7662-9234
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
Al
On 5/10/2012 3:49 AM, Fero Santos wrote:
> Hello, Onestone
>
> Finally, got it working :)
>
> Check it out:
> /* These guys are my data i'm kicking off SPI with DMA */
>
> ALS[1] = 0x00; // ADDR, MSByte
> ALS[2] = 0x00; // ADDR, LSByte
> ALS[3] = 0x55; // From here to AL[6], just some values i added */
> ALS[4] = 0x55;
> ALS[5] = 0x66;
> ALS[6] = 0x77;
>
> DMACTL0 = 0;
> // Cleans DMA0 register
> DMACTL0 |= DMA0TSEL_13;
> // Trigger source as UCB0TX Interrupt flag
> DMA0CTL |= DMASRCINCR_3 + DMADSTINCR_0 + DMADT_0 + DMASBDB;
> // DMASRCINCR_3 -> Source add increment
> // DMADSTINCR_0 -> Destination add without increment/decrement
> // DMADT_0 -> Single transfer
> // DMASBDB -> Byte to Byte transfer
>
> DMA0SA = (unsigned short)&ALS + 1;
> // Source addrs: I'm pointing to ALS[1] instead of ALS[0]
>
> DMA0DA = (unsigned short)&UCB0TXBUF;
> // Destination addrs: Pointing to transfer buffer
>
> DMA0SZ = 6;
> // Transfer size, in bytes
>
> CS_LOW();
> // A chip select in my device (RAM 23k256)
>
> DMA0CTL |= DMAEN + DMAREQ;
> // An enable for DMA
>
> ram_send_byte(0x02);
> // Kickoff firts byte (CMD byte) to start block transfer
>
> while(DMA0SZ == 0){};
> // Do DMA transfer while there's data to be sent
>
> CS_HIGH();
> // Deassert CS
>
> Scope shows me a perfect and smooth data transmission.
> Reading the address from RAM returns me data sent to be stored.
>
> Cheers
> On Thu, Oct 4, 2012 at 2:32 PM, Onestone wrote:
>
>> **
>> A status check is always a good thing, but check your memory data sheet,
>> I believe that some memories, in fact the 4 I've just looked at, return
>> status on the byte after the command byte, and every byte thereafter
>> when writing the memory, so it is a simple case of enabling the SPI
>> receive and checking the returned data.
>>
>> My typical SPI sequence looks something like:-
>>
>> set transaction length
>> enable ISR
>> send command byte to start things going.
>>
>> in ISR, on first call enable RX isr
>> load next byte in to buffer
>>
>> the Rx isr then collects stsua.
>>
>> OR you can run only on the RX isr and get status every transmit, so the
>> isr does:-
>>
>> get rxbuffer
>> send next byte
>> packet length checks
>>
>> and you can decide when you want to actually test the status.
>>
>> Al
>> On 5/10/2012 2:01 AM, Hugo Brunert wrote:
>>> I may be wrong, but I thought you needed STATUS in between CMD & ADDRs &
>> data.
>>> At least I use it. Am I wasting time by using status en between each
>> Xfer?
>>>
>>>
>>> From: m... [mailto:m...] On Behalf
>> Of favero.santos
>>> Sent: Thursday, October 04, 2012 12:27 PM
>>> To: m...
>>> Subject: [msp430] Re: MSP430F2619 DMA block transfer
>>>
>>>
>>>
>>>
>>>
>>> Hello, Felipe.
>>>
>>> Nice to find another brazilian in this forum.
>>>
>>> DMA0SA = (int)&endereco+1;
>>> this means DMA should use as source address the next byte of the int
>> endereco.
>>> Example:
>>> int endereco 0x2010.
>>> In memory, it will be stored as:
>>> 0x10 0x20.
>>> Writing the cmd as i did, 0x20 will be pointed firstly (if DMA0SA >> (int)&endereco, 0x10 will be pointed firstly).
>>> Anyway, i found another solution:
>>>
>>> I'll make a block of CMD (1byte) + ADDS (2 bytes) + data (1k byte) and
>> send as an unique block (the way first way was sending with DMA separated
>> blocks!)
>>> Cheers!
>>>
>>> --- In m... , Luis
>> Rossi wrote:
>>>> But what is the problem? Wrong data at SPI port, or no data at all?
>> Still
>>>> you are going to have a problem with your trigger as it wont wait untill
>>>> the SPI TX buffer is empty to send the new data.
>>>>
>>>> And what is the meaning of this cast?
>>>>
>>>> DMA0SA = (int)&endereco+1;
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Lu Filipe Rossi
>>>> Electrical Engineer
>>>> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
>>>> Escola Politnica
>>>> Universidade de S Paulo
>>>> Cel. +55 (11) 7662-9234
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
Reply by ●October 4, 20122012-10-04
Ok!
I think i'll add an interruption to take that nasty "while" off the code.
Thx
On Thu, Oct 4, 2012 at 3:41 PM, Onestone wrote:
> **
> In my opinion yes. Check after the command has completed, ie data
> transferred, you are crippling the SPI by checking status every byte
> transfer.
>
> Al
> On 5/10/2012 3:45 AM, Hugo Brunert wrote:
> > Shouldn't you check every time, in case you get a BUSY status?
> >
> > Meaning you should wait and retry?
> >
> > Not that is has ever happened, but I do provide for it, am I wasting
> effort and time?
> >
> >
> >
> > From: m... [mailto:m...] On Behalf
> Of Onestone
> > Sent: Thursday, October 04, 2012 1:32 PM
> > To: m...
> > Subject: Re: [msp430] Re: MSP430F2619 DMA block transfer
> >
> >
> >
> >
> >
> > A status check is always a good thing, but check your memory data sheet,
> > I believe that some memories, in fact the 4 I've just looked at, return
> > status on the byte after the command byte, and every byte thereafter
> > when writing the memory, so it is a simple case of enabling the SPI
> > receive and checking the returned data.
> >
> > My typical SPI sequence looks something like:-
> >
> > set transaction length
> > enable ISR
> > send command byte to start things going.
> >
> > in ISR, on first call enable RX isr
> > load next byte in to buffer
> >
> > the Rx isr then collects stsua.
> >
> > OR you can run only on the RX isr and get status every transmit, so the
> > isr does:-
> >
> > get rxbuffer
> > send next byte
> > packet length checks
> >
> > and you can decide when you want to actually test the status.
> >
> > Al
> >
> > On 5/10/2012 2:01 AM, Hugo Brunert wrote:
> >> I may be wrong, but I thought you needed STATUS in between CMD & ADDRs
> & data.
> >>
> >> At least I use it. Am I wasting time by using status en between each
> Xfer?
> >>
> >>
> >>
> >> From: m... [mailto:
> m... ] On Behalf Of
> favero.santos
> >> Sent: Thursday, October 04, 2012 12:27 PM
> >> To: m...
> >> Subject: [msp430] Re: MSP430F2619 DMA block transfer
> >>
> >>
> >>
> >>
> >>
> >> Hello, Felipe.
> >>
> >> Nice to find another brazilian in this forum.
> >>
> >> DMA0SA = (int)&endereco+1;
> >> this means DMA should use as source address the next byte of the int
> endereco.
> >>
> >> Example:
> >> int endereco 0x2010.
> >> In memory, it will be stored as:
> >> 0x10 0x20.
> >> Writing the cmd as i did, 0x20 will be pointed firstly (if DMA0SA =
> (int)&endereco, 0x10 will be pointed firstly).
> >>
> >> Anyway, i found another solution:
> >>
> >> I'll make a block of CMD (1byte) + ADDS (2 bytes) + data (1k byte) and
> send as an unique block (the way first way was sending with DMA separated
> blocks!)
> >>
> >> Cheers!
> >>
> >> --- In m...
> , Luis Rossi wrote:
> >>> But what is the problem? Wrong data at SPI port, or no data at all?
> Still
> >>> you are going to have a problem with your trigger as it wont wait
> untill
> >>> the SPI TX buffer is empty to send the new data.
> >>>
> >>> And what is the meaning of this cast?
> >>>
> >>> DMA0SA = (int)&endereco+1;
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Lu Filipe Rossi
> >>> Electrical Engineer
> >>> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
> >>> Escola Politnica
> >>> Universidade de S Paulo
> >>> Cel. +55 (11) 7662-9234
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> > >
> >>
> >>
I think i'll add an interruption to take that nasty "while" off the code.
Thx
On Thu, Oct 4, 2012 at 3:41 PM, Onestone wrote:
> **
> In my opinion yes. Check after the command has completed, ie data
> transferred, you are crippling the SPI by checking status every byte
> transfer.
>
> Al
> On 5/10/2012 3:45 AM, Hugo Brunert wrote:
> > Shouldn't you check every time, in case you get a BUSY status?
> >
> > Meaning you should wait and retry?
> >
> > Not that is has ever happened, but I do provide for it, am I wasting
> effort and time?
> >
> >
> >
> > From: m... [mailto:m...] On Behalf
> Of Onestone
> > Sent: Thursday, October 04, 2012 1:32 PM
> > To: m...
> > Subject: Re: [msp430] Re: MSP430F2619 DMA block transfer
> >
> >
> >
> >
> >
> > A status check is always a good thing, but check your memory data sheet,
> > I believe that some memories, in fact the 4 I've just looked at, return
> > status on the byte after the command byte, and every byte thereafter
> > when writing the memory, so it is a simple case of enabling the SPI
> > receive and checking the returned data.
> >
> > My typical SPI sequence looks something like:-
> >
> > set transaction length
> > enable ISR
> > send command byte to start things going.
> >
> > in ISR, on first call enable RX isr
> > load next byte in to buffer
> >
> > the Rx isr then collects stsua.
> >
> > OR you can run only on the RX isr and get status every transmit, so the
> > isr does:-
> >
> > get rxbuffer
> > send next byte
> > packet length checks
> >
> > and you can decide when you want to actually test the status.
> >
> > Al
> >
> > On 5/10/2012 2:01 AM, Hugo Brunert wrote:
> >> I may be wrong, but I thought you needed STATUS in between CMD & ADDRs
> & data.
> >>
> >> At least I use it. Am I wasting time by using status en between each
> Xfer?
> >>
> >>
> >>
> >> From: m... [mailto:
> m... ] On Behalf Of
> favero.santos
> >> Sent: Thursday, October 04, 2012 12:27 PM
> >> To: m...
> >> Subject: [msp430] Re: MSP430F2619 DMA block transfer
> >>
> >>
> >>
> >>
> >>
> >> Hello, Felipe.
> >>
> >> Nice to find another brazilian in this forum.
> >>
> >> DMA0SA = (int)&endereco+1;
> >> this means DMA should use as source address the next byte of the int
> endereco.
> >>
> >> Example:
> >> int endereco 0x2010.
> >> In memory, it will be stored as:
> >> 0x10 0x20.
> >> Writing the cmd as i did, 0x20 will be pointed firstly (if DMA0SA =
> (int)&endereco, 0x10 will be pointed firstly).
> >>
> >> Anyway, i found another solution:
> >>
> >> I'll make a block of CMD (1byte) + ADDS (2 bytes) + data (1k byte) and
> send as an unique block (the way first way was sending with DMA separated
> blocks!)
> >>
> >> Cheers!
> >>
> >> --- In m...
> , Luis Rossi wrote:
> >>> But what is the problem? Wrong data at SPI port, or no data at all?
> Still
> >>> you are going to have a problem with your trigger as it wont wait
> untill
> >>> the SPI TX buffer is empty to send the new data.
> >>>
> >>> And what is the meaning of this cast?
> >>>
> >>> DMA0SA = (int)&endereco+1;
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Lu Filipe Rossi
> >>> Electrical Engineer
> >>> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
> >>> Escola Politnica
> >>> Universidade de S Paulo
> >>> Cel. +55 (11) 7662-9234
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> > >
> >>
> >>
Reply by ●October 4, 20122012-10-04
Thank you Al for the tip
From: m... [mailto:m...] On Behalf Of Onestone
Sent: Thursday, October 04, 2012 2:41 PM
To: m...
Subject: Re: [msp430] Re: MSP430F2619 DMA block transfer
In my opinion yes. Check after the command has completed, ie data
transferred, you are crippling the SPI by checking status every byte
transfer.
Al
On 5/10/2012 3:45 AM, Hugo Brunert wrote:
> Shouldn't you check every time, in case you get a BUSY status?
>
> Meaning you should wait and retry?
>
> Not that is has ever happened, but I do provide for it, am I wasting effort and time?
>
>
>
> From: m... [mailto:ms... ] On Behalf Of Onestone
> Sent: Thursday, October 04, 2012 1:32 PM
> To: m...
> Subject: Re: [msp430] Re: MSP430F2619 DMA block transfer
>
>
>
>
>
> A status check is always a good thing, but check your memory data sheet,
> I believe that some memories, in fact the 4 I've just looked at, return
> status on the byte after the command byte, and every byte thereafter
> when writing the memory, so it is a simple case of enabling the SPI
> receive and checking the returned data.
>
> My typical SPI sequence looks something like:-
>
> set transaction length
> enable ISR
> send command byte to start things going.
>
> in ISR, on first call enable RX isr
> load next byte in to buffer
>
> the Rx isr then collects stsua.
>
> OR you can run only on the RX isr and get status every transmit, so the
> isr does:-
>
> get rxbuffer
> send next byte
> packet length checks
>
> and you can decide when you want to actually test the status.
>
> Al
>
> On 5/10/2012 2:01 AM, Hugo Brunert wrote:
>> I may be wrong, but I thought you needed STATUS in between CMD & ADDRs & data.
>>
>> At least I use it. Am I wasting time by using status en between each Xfer?
>>
>> From: m... [mailto:m... ] On Behalf Of favero.santos
>> Sent: Thursday, October 04, 2012 12:27 PM
>> To: m...
>> Subject: [msp430] Re: MSP430F2619 DMA block transfer
>>
>> Hello, Felipe.
>>
>> Nice to find another brazilian in this forum.
>>
>> DMA0SA = (int)&endereco+1;
>> this means DMA should use as source address the next byte of the int endereco.
>>
>> Example:
>> int endereco 0x2010.
>> In memory, it will be stored as:
>> 0x10 0x20.
>> Writing the cmd as i did, 0x20 will be pointed firstly (if DMA0SA = (int)&endereco, 0x10 will be pointed firstly).
>>
>> Anyway, i found another solution:
>>
>> I'll make a block of CMD (1byte) + ADDS (2 bytes) + data (1k byte) and send as an unique block (the way first way was sending with DMA separated blocks!)
>>
>> Cheers!
>>
>> --- In m... , Luis Rossi wrote:
>>> But what is the problem? Wrong data at SPI port, or no data at all? Still
>>> you are going to have a problem with your trigger as it wont wait untill
>>> the SPI TX buffer is empty to send the new data.
>>>
>>> And what is the meaning of this cast?
>>>
>>> DMA0SA = (int)&endereco+1;
>>>
>>> Regards,
>>>
>>> --
>>> Lu Filipe Rossi
>>> Electrical Engineer
>>> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
>>> Escola Politnica
>>> Universidade de S Paulo
>>> Cel. +55 (11) 7662-9234
>>>
>>>
>>>
>>>
>>
>>
>>
>>
From: m... [mailto:m...] On Behalf Of Onestone
Sent: Thursday, October 04, 2012 2:41 PM
To: m...
Subject: Re: [msp430] Re: MSP430F2619 DMA block transfer
In my opinion yes. Check after the command has completed, ie data
transferred, you are crippling the SPI by checking status every byte
transfer.
Al
On 5/10/2012 3:45 AM, Hugo Brunert wrote:
> Shouldn't you check every time, in case you get a BUSY status?
>
> Meaning you should wait and retry?
>
> Not that is has ever happened, but I do provide for it, am I wasting effort and time?
>
>
>
> From: m... [mailto:ms... ] On Behalf Of Onestone
> Sent: Thursday, October 04, 2012 1:32 PM
> To: m...
> Subject: Re: [msp430] Re: MSP430F2619 DMA block transfer
>
>
>
>
>
> A status check is always a good thing, but check your memory data sheet,
> I believe that some memories, in fact the 4 I've just looked at, return
> status on the byte after the command byte, and every byte thereafter
> when writing the memory, so it is a simple case of enabling the SPI
> receive and checking the returned data.
>
> My typical SPI sequence looks something like:-
>
> set transaction length
> enable ISR
> send command byte to start things going.
>
> in ISR, on first call enable RX isr
> load next byte in to buffer
>
> the Rx isr then collects stsua.
>
> OR you can run only on the RX isr and get status every transmit, so the
> isr does:-
>
> get rxbuffer
> send next byte
> packet length checks
>
> and you can decide when you want to actually test the status.
>
> Al
>
> On 5/10/2012 2:01 AM, Hugo Brunert wrote:
>> I may be wrong, but I thought you needed STATUS in between CMD & ADDRs & data.
>>
>> At least I use it. Am I wasting time by using status en between each Xfer?
>>
>> From: m... [mailto:m... ] On Behalf Of favero.santos
>> Sent: Thursday, October 04, 2012 12:27 PM
>> To: m...
>> Subject: [msp430] Re: MSP430F2619 DMA block transfer
>>
>> Hello, Felipe.
>>
>> Nice to find another brazilian in this forum.
>>
>> DMA0SA = (int)&endereco+1;
>> this means DMA should use as source address the next byte of the int endereco.
>>
>> Example:
>> int endereco 0x2010.
>> In memory, it will be stored as:
>> 0x10 0x20.
>> Writing the cmd as i did, 0x20 will be pointed firstly (if DMA0SA = (int)&endereco, 0x10 will be pointed firstly).
>>
>> Anyway, i found another solution:
>>
>> I'll make a block of CMD (1byte) + ADDS (2 bytes) + data (1k byte) and send as an unique block (the way first way was sending with DMA separated blocks!)
>>
>> Cheers!
>>
>> --- In m... , Luis Rossi wrote:
>>> But what is the problem? Wrong data at SPI port, or no data at all? Still
>>> you are going to have a problem with your trigger as it wont wait untill
>>> the SPI TX buffer is empty to send the new data.
>>>
>>> And what is the meaning of this cast?
>>>
>>> DMA0SA = (int)&endereco+1;
>>>
>>> Regards,
>>>
>>> --
>>> Lu Filipe Rossi
>>> Electrical Engineer
>>> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
>>> Escola Politnica
>>> Universidade de S Paulo
>>> Cel. +55 (11) 7662-9234
>>>
>>>
>>>
>>>
>>
>>
>>
>>
