Hi guys,
I am using the MPS430F5438A and I want to read a external byte stream (at P6
port) to RAM. The byte stream is clocked externally. I put this CLK to P2.7
pin (DMAE0 this is DMATrigger31 signal). According to the datasheet this
needs 4 MCLK's. The external CLK is asynchronous to MCLK.
The question is: when is the byte at input port P6 read? In which of the 4
MCLK's? I see no timing diagram in the datasheet.
Any ideas how long I have to hold the byte stable at P6?
My assumptions:
1st cycle: synchronise to P2.7
2nd cycle: read P6
3rd cycle: write to RAM
4th cycle: synchronise P2.7 (release)
Is there a better way to get a external clocked byte stream into RAM?
Thx
Matthias
F5438A DMA cycle timing for external port
Started by ●January 11, 2012
Reply by ●January 16, 20122012-01-16
Why you don't use P2.7 as an ordinary interrupt input and read P6 whith
every interrupt occured at P2.7?
In your case, I would keep the byte stable at least the max. DMA cycled time. The cycle time depends on the cpu operation mode. Take a look at table 9-3 in the family users guide.
Stefan
--- In m..., Matthias Weingart wrote:
>
> Hi guys,
>
> I am using the MPS430F5438A and I want to read a external byte stream (at P6
> port) to RAM. The byte stream is clocked externally. I put this CLK to P2.7
> pin (DMAE0 this is DMATrigger31 signal). According to the datasheet this
> needs 4 MCLK's. The external CLK is asynchronous to MCLK.
> The question is: when is the byte at input port P6 read? In which of the 4
> MCLK's? I see no timing diagram in the datasheet.
> Any ideas how long I have to hold the byte stable at P6?
> My assumptions:
> 1st cycle: synchronise to P2.7
> 2nd cycle: read P6
> 3rd cycle: write to RAM
> 4th cycle: synchronise P2.7 (release)
>
> Is there a better way to get a external clocked byte stream into RAM?
>
> Thx
> Matthias
>
In your case, I would keep the byte stable at least the max. DMA cycled time. The cycle time depends on the cpu operation mode. Take a look at table 9-3 in the family users guide.
Stefan
--- In m..., Matthias Weingart wrote:
>
> Hi guys,
>
> I am using the MPS430F5438A and I want to read a external byte stream (at P6
> port) to RAM. The byte stream is clocked externally. I put this CLK to P2.7
> pin (DMAE0 this is DMATrigger31 signal). According to the datasheet this
> needs 4 MCLK's. The external CLK is asynchronous to MCLK.
> The question is: when is the byte at input port P6 read? In which of the 4
> MCLK's? I see no timing diagram in the datasheet.
> Any ideas how long I have to hold the byte stable at P6?
> My assumptions:
> 1st cycle: synchronise to P2.7
> 2nd cycle: read P6
> 3rd cycle: write to RAM
> 4th cycle: synchronise P2.7 (release)
>
> Is there a better way to get a external clocked byte stream into RAM?
>
> Thx
> Matthias
>
Reply by ●January 16, 20122012-01-16
"Stefan Hauenstein" :
> Why you don't use P2.7 as an ordinary interrupt input and read P6 whith
> every interrupt occured at P2.7?
Interrupts are much slower. In BLOCK mode the DMA is needing only 2 MCLK
cycles - in single transfer mode 4 MCLK cycles. The interrupt needs at
least 10 cycles or so - depending on how long I block interrupts in the
code. If hardware multiplier is enabled the compiler is using DINT!
It is amazing - a 25MHz MSP430X can fetch data at a rate of 200Mbit/s with
DMA in BLOCK mode.
> In your case, I would keep the byte stable at least the max. DMA cycled
> time. The cycle time depends on the cpu operation mode. Take a look at
> table 9-3 in the family users guide.
Sure, but this cost me a latch - according to the spec the byte is valid
only at one edge of the external CLK (+- some ns). Would be nice to know
which of the edges of MCLK are used to read the byte.
M.
>
> Stefan
>
> --- In m..., Matthias Weingart wrote:
>>
>> Hi guys,
>>
>> I am using the MPS430F5438A and I want to read a external byte stream
>> (at P6 port) to RAM. The byte stream is clocked externally. I put this
>> CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal). According to the
>> datasheet this needs 4 MCLK's. The external CLK is asynchronous to
>> MCLK. The question is: when is the byte at input port P6 read? In which
>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>> Any ideas how long I have to hold the byte stable at P6?
>> My assumptions:
>> 1st cycle: synchronise to P2.7
>> 2nd cycle: read P6
>> 3rd cycle: write to RAM
>> 4th cycle: synchronise P2.7 (release)
>>
>> Is there a better way to get a external clocked byte stream into RAM?
>>
>> Thx
>> Matthias
>>
>
> Why you don't use P2.7 as an ordinary interrupt input and read P6 whith
> every interrupt occured at P2.7?
Interrupts are much slower. In BLOCK mode the DMA is needing only 2 MCLK
cycles - in single transfer mode 4 MCLK cycles. The interrupt needs at
least 10 cycles or so - depending on how long I block interrupts in the
code. If hardware multiplier is enabled the compiler is using DINT!
It is amazing - a 25MHz MSP430X can fetch data at a rate of 200Mbit/s with
DMA in BLOCK mode.
> In your case, I would keep the byte stable at least the max. DMA cycled
> time. The cycle time depends on the cpu operation mode. Take a look at
> table 9-3 in the family users guide.
Sure, but this cost me a latch - according to the spec the byte is valid
only at one edge of the external CLK (+- some ns). Would be nice to know
which of the edges of MCLK are used to read the byte.
M.
>
> Stefan
>
> --- In m..., Matthias Weingart wrote:
>>
>> Hi guys,
>>
>> I am using the MPS430F5438A and I want to read a external byte stream
>> (at P6 port) to RAM. The byte stream is clocked externally. I put this
>> CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal). According to the
>> datasheet this needs 4 MCLK's. The external CLK is asynchronous to
>> MCLK. The question is: when is the byte at input port P6 read? In which
>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>> Any ideas how long I have to hold the byte stable at P6?
>> My assumptions:
>> 1st cycle: synchronise to P2.7
>> 2nd cycle: read P6
>> 3rd cycle: write to RAM
>> 4th cycle: synchronise P2.7 (release)
>>
>> Is there a better way to get a external clocked byte stream into RAM?
>>
>> Thx
>> Matthias
>>
>
Reply by ●January 16, 20122012-01-16
I agree with Matthias, DMA is generally better than plain interrupts if
handled properly, however the MSP430 doesn't have a traditional DMA,
which is truly independent of the cpu, so many compromises have to be
made, rendering Block mode unsuitable where blocks are long and a rapid
response is needed by other services, ie a fast pulse cannot be measured
or possibly separated if the DMA is hogging the processor for a period
exceeding the interrupt rate. I realise Matthias understands this, but
perhapos newbies won't.
Al
On 16/01/2012 8:27 PM, Matthias Weingart wrote:
> "Stefan Hauenstein":
>
>> Why you don't use P2.7 as an ordinary interrupt input and read P6 whith
>> every interrupt occured at P2.7?
> Interrupts are much slower. In BLOCK mode the DMA is needing only 2 MCLK
> cycles - in single transfer mode 4 MCLK cycles. The interrupt needs at
> least 10 cycles or so - depending on how long I block interrupts in the
> code. If hardware multiplier is enabled the compiler is using DINT!
> It is amazing - a 25MHz MSP430X can fetch data at a rate of 200Mbit/s with
> DMA in BLOCK mode.
>
>> In your case, I would keep the byte stable at least the max. DMA cycled
>> time. The cycle time depends on the cpu operation mode. Take a look at
>> table 9-3 in the family users guide.
> Sure, but this cost me a latch - according to the spec the byte is valid
> only at one edge of the external CLK (+- some ns). Would be nice to know
> which of the edges of MCLK are used to read the byte.
>
> M.
>
>> Stefan
>>
>> --- In m..., Matthias Weingart wrote:
>>> Hi guys,
>>>
>>> I am using the MPS430F5438A and I want to read a external byte stream
>>> (at P6 port) to RAM. The byte stream is clocked externally. I put this
>>> CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal). According to the
>>> datasheet this needs 4 MCLK's. The external CLK is asynchronous to
>>> MCLK. The question is: when is the byte at input port P6 read? In which
>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>> Any ideas how long I have to hold the byte stable at P6?
>>> My assumptions:
>>> 1st cycle: synchronise to P2.7
>>> 2nd cycle: read P6
>>> 3rd cycle: write to RAM
>>> 4th cycle: synchronise P2.7 (release)
>>>
>>> Is there a better way to get a external clocked byte stream into RAM?
>>>
>>> Thx
>>> Matthias
>>>
handled properly, however the MSP430 doesn't have a traditional DMA,
which is truly independent of the cpu, so many compromises have to be
made, rendering Block mode unsuitable where blocks are long and a rapid
response is needed by other services, ie a fast pulse cannot be measured
or possibly separated if the DMA is hogging the processor for a period
exceeding the interrupt rate. I realise Matthias understands this, but
perhapos newbies won't.
Al
On 16/01/2012 8:27 PM, Matthias Weingart wrote:
> "Stefan Hauenstein":
>
>> Why you don't use P2.7 as an ordinary interrupt input and read P6 whith
>> every interrupt occured at P2.7?
> Interrupts are much slower. In BLOCK mode the DMA is needing only 2 MCLK
> cycles - in single transfer mode 4 MCLK cycles. The interrupt needs at
> least 10 cycles or so - depending on how long I block interrupts in the
> code. If hardware multiplier is enabled the compiler is using DINT!
> It is amazing - a 25MHz MSP430X can fetch data at a rate of 200Mbit/s with
> DMA in BLOCK mode.
>
>> In your case, I would keep the byte stable at least the max. DMA cycled
>> time. The cycle time depends on the cpu operation mode. Take a look at
>> table 9-3 in the family users guide.
> Sure, but this cost me a latch - according to the spec the byte is valid
> only at one edge of the external CLK (+- some ns). Would be nice to know
> which of the edges of MCLK are used to read the byte.
>
> M.
>
>> Stefan
>>
>> --- In m..., Matthias Weingart wrote:
>>> Hi guys,
>>>
>>> I am using the MPS430F5438A and I want to read a external byte stream
>>> (at P6 port) to RAM. The byte stream is clocked externally. I put this
>>> CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal). According to the
>>> datasheet this needs 4 MCLK's. The external CLK is asynchronous to
>>> MCLK. The question is: when is the byte at input port P6 read? In which
>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>> Any ideas how long I have to hold the byte stable at P6?
>>> My assumptions:
>>> 1st cycle: synchronise to P2.7
>>> 2nd cycle: read P6
>>> 3rd cycle: write to RAM
>>> 4th cycle: synchronise P2.7 (release)
>>>
>>> Is there a better way to get a external clocked byte stream into RAM?
>>>
>>> Thx
>>> Matthias
>>>
Reply by ●January 16, 20122012-01-16
Al,
You can use burst block mode DMA if you still need the CPU during DMA.
4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However there is only
little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit size will block the
CPU for 0.6ms only :-).
M.
Onestone :
> I agree with Matthias, DMA is generally better than plain interrupts if
> handled properly, however the MSP430 doesn't have a traditional DMA,
> which is truly independent of the cpu, so many compromises have to be
> made, rendering Block mode unsuitable where blocks are long and a rapid
> response is needed by other services, ie a fast pulse cannot be measured
> or possibly separated if the DMA is hogging the processor for a period
> exceeding the interrupt rate. I realise Matthias understands this, but
> perhapos newbies won't.
>
> Al
>
> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
>> "Stefan Hauenstein":
>>
>>> Why you don't use P2.7 as an ordinary interrupt input and read P6 whith
>>> every interrupt occured at P2.7?
>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2 MCLK
>> cycles - in single transfer mode 4 MCLK cycles. The interrupt needs at
>> least 10 cycles or so - depending on how long I block interrupts in the
>> code. If hardware multiplier is enabled the compiler is using DINT!
>> It is amazing - a 25MHz MSP430X can fetch data at a rate of 200Mbit/s
with
>> DMA in BLOCK mode.
>>
>>> In your case, I would keep the byte stable at least the max. DMA cycled
>>> time. The cycle time depends on the cpu operation mode. Take a look at
>>> table 9-3 in the family users guide.
>> Sure, but this cost me a latch - according to the spec the byte is valid
>> only at one edge of the external CLK (+- some ns). Would be nice to know
>> which of the edges of MCLK are used to read the byte.
>>
>> M.
>>
>>> Stefan
>>>
>>>
>>>
>>> --- In m..., Matthias Weingart wrote:
>>>> Hi guys,
>>>>
>>>> I am using the MPS430F5438A and I want to read a external byte stream
>>>> (at P6 port) to RAM. The byte stream is clocked externally. I put this
>>>> CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal). According to the
>>>> datasheet this needs 4 MCLK's. The external CLK is asynchronous to
>>>> MCLK. The question is: when is the byte at input port P6 read? In
which
>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>>> Any ideas how long I have to hold the byte stable at P6?
>>>> My assumptions:
>>>> 1st cycle: synchronise to P2.7
>>>> 2nd cycle: read P6
>>>> 3rd cycle: write to RAM
>>>> 4th cycle: synchronise P2.7 (release)
>>>>
>>>> Is there a better way to get a external clocked byte stream into RAM?
>>>>
>>>> Thx
>>>> Matthias
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
You can use burst block mode DMA if you still need the CPU during DMA.
4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However there is only
little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit size will block the
CPU for 0.6ms only :-).
M.
Onestone :
> I agree with Matthias, DMA is generally better than plain interrupts if
> handled properly, however the MSP430 doesn't have a traditional DMA,
> which is truly independent of the cpu, so many compromises have to be
> made, rendering Block mode unsuitable where blocks are long and a rapid
> response is needed by other services, ie a fast pulse cannot be measured
> or possibly separated if the DMA is hogging the processor for a period
> exceeding the interrupt rate. I realise Matthias understands this, but
> perhapos newbies won't.
>
> Al
>
> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
>> "Stefan Hauenstein":
>>
>>> Why you don't use P2.7 as an ordinary interrupt input and read P6 whith
>>> every interrupt occured at P2.7?
>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2 MCLK
>> cycles - in single transfer mode 4 MCLK cycles. The interrupt needs at
>> least 10 cycles or so - depending on how long I block interrupts in the
>> code. If hardware multiplier is enabled the compiler is using DINT!
>> It is amazing - a 25MHz MSP430X can fetch data at a rate of 200Mbit/s
with
>> DMA in BLOCK mode.
>>
>>> In your case, I would keep the byte stable at least the max. DMA cycled
>>> time. The cycle time depends on the cpu operation mode. Take a look at
>>> table 9-3 in the family users guide.
>> Sure, but this cost me a latch - according to the spec the byte is valid
>> only at one edge of the external CLK (+- some ns). Would be nice to know
>> which of the edges of MCLK are used to read the byte.
>>
>> M.
>>
>>> Stefan
>>>
>>>
>>>
>>> --- In m..., Matthias Weingart wrote:
>>>> Hi guys,
>>>>
>>>> I am using the MPS430F5438A and I want to read a external byte stream
>>>> (at P6 port) to RAM. The byte stream is clocked externally. I put this
>>>> CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal). According to the
>>>> datasheet this needs 4 MCLK's. The external CLK is asynchronous to
>>>> MCLK. The question is: when is the byte at input port P6 read? In
which
>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>>> Any ideas how long I have to hold the byte stable at P6?
>>>> My assumptions:
>>>> 1st cycle: synchronise to P2.7
>>>> 2nd cycle: read P6
>>>> 3rd cycle: write to RAM
>>>> 4th cycle: synchronise P2.7 (release)
>>>>
>>>> Is there a better way to get a external clocked byte stream into RAM?
>>>>
>>>> Thx
>>>> Matthias
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
Reply by ●January 16, 20122012-01-16
0.6ms is an absolute lifetime! I wouldn't allow any single process to
hog that much time! I give clock cycles away sparingly! Seriously I am
reading multiple multi-axis sensors at quite high sample rates and
storing to SD card. I just can't afford to miss a sample. A true DMA
would be great, but since there are only 3 channels, and typically
anything comms might require 2 channels to be truly effective it kind of
limits its usefulness to me. Again another reason why I've been looking
for a better low current solution for a while now.
Al
On 17/01/2012 3:29 AM, Matthias Weingart wrote:
> Al,
>
> You can use burst block mode DMA if you still need the CPU during DMA.
> 4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However there is only
> little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit size will block the
> CPU for 0.6ms only :-).
>
> M.
>
> Onestone:
>
>> I agree with Matthias, DMA is generally better than plain interrupts if
>> handled properly, however the MSP430 doesn't have a traditional DMA,
>> which is truly independent of the cpu, so many compromises have to be
>> made, rendering Block mode unsuitable where blocks are long and a rapid
>> response is needed by other services, ie a fast pulse cannot be measured
>> or possibly separated if the DMA is hogging the processor for a period
>> exceeding the interrupt rate. I realise Matthias understands this, but
>> perhapos newbies won't.
>>
>> Al
>>
>> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
>>> "Stefan Hauenstein":
>>>
>>>> Why you don't use P2.7 as an ordinary interrupt input and read P6 whith
>>>> every interrupt occured at P2.7?
>>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2 MCLK
>>> cycles - in single transfer mode 4 MCLK cycles. The interrupt needs at
>>> least 10 cycles or so - depending on how long I block interrupts in the
>>> code. If hardware multiplier is enabled the compiler is using DINT!
>>> It is amazing - a 25MHz MSP430X can fetch data at a rate of 200Mbit/s
> with
>>> DMA in BLOCK mode.
>>>
>>>> In your case, I would keep the byte stable at least the max. DMA cycled
>>>> time. The cycle time depends on the cpu operation mode. Take a look at
>>>> table 9-3 in the family users guide.
>>> Sure, but this cost me a latch - according to the spec the byte is valid
>>> only at one edge of the external CLK (+- some ns). Would be nice to know
>>> which of the edges of MCLK are used to read the byte.
>>>
>>> M.
>>>
>>>> Stefan
>>>>
>>>>
>>>>
>>>> --- In m..., Matthias Weingart wrote:
>>>>> Hi guys,
>>>>>
>>>>> I am using the MPS430F5438A and I want to read a external byte stream
>>>>> (at P6 port) to RAM. The byte stream is clocked externally. I put this
>>>>> CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal). According to the
>>>>> datasheet this needs 4 MCLK's. The external CLK is asynchronous to
>>>>> MCLK. The question is: when is the byte at input port P6 read? In
> which
>>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>>>> Any ideas how long I have to hold the byte stable at P6?
>>>>> My assumptions:
>>>>> 1st cycle: synchronise to P2.7
>>>>> 2nd cycle: read P6
>>>>> 3rd cycle: write to RAM
>>>>> 4th cycle: synchronise P2.7 (release)
>>>>>
>>>>> Is there a better way to get a external clocked byte stream into RAM?
>>>>>
>>>>> Thx
>>>>> Matthias
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
hog that much time! I give clock cycles away sparingly! Seriously I am
reading multiple multi-axis sensors at quite high sample rates and
storing to SD card. I just can't afford to miss a sample. A true DMA
would be great, but since there are only 3 channels, and typically
anything comms might require 2 channels to be truly effective it kind of
limits its usefulness to me. Again another reason why I've been looking
for a better low current solution for a while now.
Al
On 17/01/2012 3:29 AM, Matthias Weingart wrote:
> Al,
>
> You can use burst block mode DMA if you still need the CPU during DMA.
> 4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However there is only
> little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit size will block the
> CPU for 0.6ms only :-).
>
> M.
>
> Onestone:
>
>> I agree with Matthias, DMA is generally better than plain interrupts if
>> handled properly, however the MSP430 doesn't have a traditional DMA,
>> which is truly independent of the cpu, so many compromises have to be
>> made, rendering Block mode unsuitable where blocks are long and a rapid
>> response is needed by other services, ie a fast pulse cannot be measured
>> or possibly separated if the DMA is hogging the processor for a period
>> exceeding the interrupt rate. I realise Matthias understands this, but
>> perhapos newbies won't.
>>
>> Al
>>
>> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
>>> "Stefan Hauenstein":
>>>
>>>> Why you don't use P2.7 as an ordinary interrupt input and read P6 whith
>>>> every interrupt occured at P2.7?
>>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2 MCLK
>>> cycles - in single transfer mode 4 MCLK cycles. The interrupt needs at
>>> least 10 cycles or so - depending on how long I block interrupts in the
>>> code. If hardware multiplier is enabled the compiler is using DINT!
>>> It is amazing - a 25MHz MSP430X can fetch data at a rate of 200Mbit/s
> with
>>> DMA in BLOCK mode.
>>>
>>>> In your case, I would keep the byte stable at least the max. DMA cycled
>>>> time. The cycle time depends on the cpu operation mode. Take a look at
>>>> table 9-3 in the family users guide.
>>> Sure, but this cost me a latch - according to the spec the byte is valid
>>> only at one edge of the external CLK (+- some ns). Would be nice to know
>>> which of the edges of MCLK are used to read the byte.
>>>
>>> M.
>>>
>>>> Stefan
>>>>
>>>>
>>>>
>>>> --- In m..., Matthias Weingart wrote:
>>>>> Hi guys,
>>>>>
>>>>> I am using the MPS430F5438A and I want to read a external byte stream
>>>>> (at P6 port) to RAM. The byte stream is clocked externally. I put this
>>>>> CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal). According to the
>>>>> datasheet this needs 4 MCLK's. The external CLK is asynchronous to
>>>>> MCLK. The question is: when is the byte at input port P6 read? In
> which
>>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>>>> Any ideas how long I have to hold the byte stable at P6?
>>>>> My assumptions:
>>>>> 1st cycle: synchronise to P2.7
>>>>> 2nd cycle: read P6
>>>>> 3rd cycle: write to RAM
>>>>> 4th cycle: synchronise P2.7 (release)
>>>>>
>>>>> Is there a better way to get a external clocked byte stream into RAM?
>>>>>
>>>>> Thx
>>>>> Matthias
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
Reply by ●January 17, 20122012-01-17
Al,
in case you use burst block DMA - the transfer I mentioned below takes 1.2
ms instead of 0.6ms, but the CPU is still working at half of the clock
rate. If you was working with 8MHz before double the CPU clock to 16MHz and
you have the same response time for interrupts.
Burst Block Mode DMA is the best compromise possible with the simple
architecture of the MSP (single port RAM inside the MSP). If you need CPU
access and DMA at the same time, the solution is dual port RAM - 2 data
busses and synchronisation and more trouble ...
M.
Onestone :
> 0.6ms is an absolute lifetime! I wouldn't allow any single process to
> hog that much time! I give clock cycles away sparingly! Seriously I am
> reading multiple multi-axis sensors at quite high sample rates and
> storing to SD card. I just can't afford to miss a sample. A true DMA
> would be great, but since there are only 3 channels, and typically
> anything comms might require 2 channels to be truly effective it kind of
> limits its usefulness to me. Again another reason why I've been looking
> for a better low current solution for a while now.
>
> Al
>
> On 17/01/2012 3:29 AM, Matthias Weingart wrote:
>> Al,
>>
>> You can use burst block mode DMA if you still need the CPU during DMA.
>> 4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However there is
>> only little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit size will
>> block the CPU for 0.6ms only :-).
>>
>> M.
>>
>> Onestone:
>>
>>> I agree with Matthias, DMA is generally better than plain interrupts
>>> if handled properly, however the MSP430 doesn't have a traditional
>>> DMA, which is truly independent of the cpu, so many compromises have
>>> to be made, rendering Block mode unsuitable where blocks are long and
>>> a rapid response is needed by other services, ie a fast pulse cannot
>>> be measured or possibly separated if the DMA is hogging the processor
>>> for a period exceeding the interrupt rate. I realise Matthias
>>> understands this, but perhapos newbies won't.
>>>
>>> Al
>>>
>>> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
>>>> "Stefan Hauenstein":
>>>>
>>>>> Why you don't use P2.7 as an ordinary interrupt input and read P6
>>>>> whith every interrupt occured at P2.7?
>>>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2
>>>> MCLK cycles - in single transfer mode 4 MCLK cycles. The interrupt
>>>> needs at least 10 cycles or so - depending on how long I block
>>>> interrupts in the code. If hardware multiplier is enabled the
>>>> compiler is using DINT! It is amazing - a 25MHz MSP430X can fetch
>>>> data at a rate of 200Mbit/s
>> with
>>>> DMA in BLOCK mode.
>>>>
>>>>> In your case, I would keep the byte stable at least the max. DMA
>>>>> cycled time. The cycle time depends on the cpu operation mode. Take
>>>>> a look at table 9-3 in the family users guide.
>>>> Sure, but this cost me a latch - according to the spec the byte is
>>>> valid only at one edge of the external CLK (+- some ns). Would be
>>>> nice to know which of the edges of MCLK are used to read the byte.
>>>>
>>>> M.
>>>>
>>>>> Stefan
>>>>>
>>>>>
>>>>>
>>>>> --- In m..., Matthias Weingart wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> I am using the MPS430F5438A and I want to read a external byte
>>>>>> stream (at P6 port) to RAM. The byte stream is clocked externally.
>>>>>> I put this CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal).
>>>>>> According to the datasheet this needs 4 MCLK's. The external CLK is
>>>>>> asynchronous to MCLK. The question is: when is the byte at input
>>>>>> port P6 read? In
>> which
>>>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>>>>> Any ideas how long I have to hold the byte stable at P6?
>>>>>> My assumptions:
>>>>>> 1st cycle: synchronise to P2.7
>>>>>> 2nd cycle: read P6
>>>>>> 3rd cycle: write to RAM
>>>>>> 4th cycle: synchronise P2.7 (release)
>>>>>>
>>>>>> Is there a better way to get a external clocked byte stream into
>>>>>> RAM?
>>>>>>
>>>>>> Thx
>>>>>> Matthias
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
in case you use burst block DMA - the transfer I mentioned below takes 1.2
ms instead of 0.6ms, but the CPU is still working at half of the clock
rate. If you was working with 8MHz before double the CPU clock to 16MHz and
you have the same response time for interrupts.
Burst Block Mode DMA is the best compromise possible with the simple
architecture of the MSP (single port RAM inside the MSP). If you need CPU
access and DMA at the same time, the solution is dual port RAM - 2 data
busses and synchronisation and more trouble ...
M.
Onestone :
> 0.6ms is an absolute lifetime! I wouldn't allow any single process to
> hog that much time! I give clock cycles away sparingly! Seriously I am
> reading multiple multi-axis sensors at quite high sample rates and
> storing to SD card. I just can't afford to miss a sample. A true DMA
> would be great, but since there are only 3 channels, and typically
> anything comms might require 2 channels to be truly effective it kind of
> limits its usefulness to me. Again another reason why I've been looking
> for a better low current solution for a while now.
>
> Al
>
> On 17/01/2012 3:29 AM, Matthias Weingart wrote:
>> Al,
>>
>> You can use burst block mode DMA if you still need the CPU during DMA.
>> 4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However there is
>> only little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit size will
>> block the CPU for 0.6ms only :-).
>>
>> M.
>>
>> Onestone:
>>
>>> I agree with Matthias, DMA is generally better than plain interrupts
>>> if handled properly, however the MSP430 doesn't have a traditional
>>> DMA, which is truly independent of the cpu, so many compromises have
>>> to be made, rendering Block mode unsuitable where blocks are long and
>>> a rapid response is needed by other services, ie a fast pulse cannot
>>> be measured or possibly separated if the DMA is hogging the processor
>>> for a period exceeding the interrupt rate. I realise Matthias
>>> understands this, but perhapos newbies won't.
>>>
>>> Al
>>>
>>> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
>>>> "Stefan Hauenstein":
>>>>
>>>>> Why you don't use P2.7 as an ordinary interrupt input and read P6
>>>>> whith every interrupt occured at P2.7?
>>>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2
>>>> MCLK cycles - in single transfer mode 4 MCLK cycles. The interrupt
>>>> needs at least 10 cycles or so - depending on how long I block
>>>> interrupts in the code. If hardware multiplier is enabled the
>>>> compiler is using DINT! It is amazing - a 25MHz MSP430X can fetch
>>>> data at a rate of 200Mbit/s
>> with
>>>> DMA in BLOCK mode.
>>>>
>>>>> In your case, I would keep the byte stable at least the max. DMA
>>>>> cycled time. The cycle time depends on the cpu operation mode. Take
>>>>> a look at table 9-3 in the family users guide.
>>>> Sure, but this cost me a latch - according to the spec the byte is
>>>> valid only at one edge of the external CLK (+- some ns). Would be
>>>> nice to know which of the edges of MCLK are used to read the byte.
>>>>
>>>> M.
>>>>
>>>>> Stefan
>>>>>
>>>>>
>>>>>
>>>>> --- In m..., Matthias Weingart wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> I am using the MPS430F5438A and I want to read a external byte
>>>>>> stream (at P6 port) to RAM. The byte stream is clocked externally.
>>>>>> I put this CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal).
>>>>>> According to the datasheet this needs 4 MCLK's. The external CLK is
>>>>>> asynchronous to MCLK. The question is: when is the byte at input
>>>>>> port P6 read? In
>> which
>>>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>>>>> Any ideas how long I have to hold the byte stable at P6?
>>>>>> My assumptions:
>>>>>> 1st cycle: synchronise to P2.7
>>>>>> 2nd cycle: read P6
>>>>>> 3rd cycle: write to RAM
>>>>>> 4th cycle: synchronise P2.7 (release)
>>>>>>
>>>>>> Is there a better way to get a external clocked byte stream into
>>>>>> RAM?
>>>>>>
>>>>>> Thx
>>>>>> Matthias
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
Reply by ●January 17, 20122012-01-17
If you need cpu and dma access at the same time having your high "byte"-rate,
the solution is not to use the msp because of the reasons Al mentioned.
Storing data with high bitrate is one thing. The other one is to handle the data in the application. Typically this is done in realtime with low latency, this was case in all of my previous projects.
--- In m..., Matthias Weingart wrote:
>
> Al,
> in case you use burst block DMA - the transfer I mentioned below takes 1.2
> ms instead of 0.6ms, but the CPU is still working at half of the clock
> rate. If you was working with 8MHz before double the CPU clock to 16MHz and
> you have the same response time for interrupts.
> Burst Block Mode DMA is the best compromise possible with the simple
> architecture of the MSP (single port RAM inside the MSP). If you need CPU
> access and DMA at the same time, the solution is dual port RAM - 2 data
> busses and synchronisation and more trouble ...
>
> M.
>
> Onestone :
>
> > 0.6ms is an absolute lifetime! I wouldn't allow any single process to
> > hog that much time! I give clock cycles away sparingly! Seriously I am
> > reading multiple multi-axis sensors at quite high sample rates and
> > storing to SD card. I just can't afford to miss a sample. A true DMA
> > would be great, but since there are only 3 channels, and typically
> > anything comms might require 2 channels to be truly effective it kind of
> > limits its usefulness to me. Again another reason why I've been looking
> > for a better low current solution for a while now.
> >
> > Al
> >
> > On 17/01/2012 3:29 AM, Matthias Weingart wrote:
> >> Al,
> >>
> >> You can use burst block mode DMA if you still need the CPU during DMA.
> >> 4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However there is
> >> only little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit size will
> >> block the CPU for 0.6ms only :-).
> >>
> >> M.
> >>
> >> Onestone:
> >>
> >>> I agree with Matthias, DMA is generally better than plain interrupts
> >>> if handled properly, however the MSP430 doesn't have a traditional
> >>> DMA, which is truly independent of the cpu, so many compromises have
> >>> to be made, rendering Block mode unsuitable where blocks are long and
> >>> a rapid response is needed by other services, ie a fast pulse cannot
> >>> be measured or possibly separated if the DMA is hogging the processor
> >>> for a period exceeding the interrupt rate. I realise Matthias
> >>> understands this, but perhapos newbies won't.
> >>>
> >>> Al
> >>>
> >>> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
> >>>> "Stefan Hauenstein":
> >>>>
> >>>>> Why you don't use P2.7 as an ordinary interrupt input and read P6
> >>>>> whith every interrupt occured at P2.7?
> >>>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2
> >>>> MCLK cycles - in single transfer mode 4 MCLK cycles. The interrupt
> >>>> needs at least 10 cycles or so - depending on how long I block
> >>>> interrupts in the code. If hardware multiplier is enabled the
> >>>> compiler is using DINT! It is amazing - a 25MHz MSP430X can fetch
> >>>> data at a rate of 200Mbit/s
> >> with
> >>>> DMA in BLOCK mode.
> >>>>
> >>>>> In your case, I would keep the byte stable at least the max. DMA
> >>>>> cycled time. The cycle time depends on the cpu operation mode. Take
> >>>>> a look at table 9-3 in the family users guide.
> >>>> Sure, but this cost me a latch - according to the spec the byte is
> >>>> valid only at one edge of the external CLK (+- some ns). Would be
> >>>> nice to know which of the edges of MCLK are used to read the byte.
> >>>>
> >>>> M.
> >>>>
> >>>>> Stefan
> >>>>>
> >>>>>
> >>>>>
> >>>>> --- In m..., Matthias Weingart wrote:
> >>>>>> Hi guys,
> >>>>>>
> >>>>>> I am using the MPS430F5438A and I want to read a external byte
> >>>>>> stream (at P6 port) to RAM. The byte stream is clocked externally.
> >>>>>> I put this CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal).
> >>>>>> According to the datasheet this needs 4 MCLK's. The external CLK is
> >>>>>> asynchronous to MCLK. The question is: when is the byte at input
> >>>>>> port P6 read? In
> >> which
> >>>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
> >>>>>> Any ideas how long I have to hold the byte stable at P6?
> >>>>>> My assumptions:
> >>>>>> 1st cycle: synchronise to P2.7
> >>>>>> 2nd cycle: read P6
> >>>>>> 3rd cycle: write to RAM
> >>>>>> 4th cycle: synchronise P2.7 (release)
> >>>>>>
> >>>>>> Is there a better way to get a external clocked byte stream into
> >>>>>> RAM?
> >>>>>>
> >>>>>> Thx
> >>>>>> Matthias
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
Storing data with high bitrate is one thing. The other one is to handle the data in the application. Typically this is done in realtime with low latency, this was case in all of my previous projects.
--- In m..., Matthias Weingart wrote:
>
> Al,
> in case you use burst block DMA - the transfer I mentioned below takes 1.2
> ms instead of 0.6ms, but the CPU is still working at half of the clock
> rate. If you was working with 8MHz before double the CPU clock to 16MHz and
> you have the same response time for interrupts.
> Burst Block Mode DMA is the best compromise possible with the simple
> architecture of the MSP (single port RAM inside the MSP). If you need CPU
> access and DMA at the same time, the solution is dual port RAM - 2 data
> busses and synchronisation and more trouble ...
>
> M.
>
> Onestone :
>
> > 0.6ms is an absolute lifetime! I wouldn't allow any single process to
> > hog that much time! I give clock cycles away sparingly! Seriously I am
> > reading multiple multi-axis sensors at quite high sample rates and
> > storing to SD card. I just can't afford to miss a sample. A true DMA
> > would be great, but since there are only 3 channels, and typically
> > anything comms might require 2 channels to be truly effective it kind of
> > limits its usefulness to me. Again another reason why I've been looking
> > for a better low current solution for a while now.
> >
> > Al
> >
> > On 17/01/2012 3:29 AM, Matthias Weingart wrote:
> >> Al,
> >>
> >> You can use burst block mode DMA if you still need the CPU during DMA.
> >> 4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However there is
> >> only little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit size will
> >> block the CPU for 0.6ms only :-).
> >>
> >> M.
> >>
> >> Onestone:
> >>
> >>> I agree with Matthias, DMA is generally better than plain interrupts
> >>> if handled properly, however the MSP430 doesn't have a traditional
> >>> DMA, which is truly independent of the cpu, so many compromises have
> >>> to be made, rendering Block mode unsuitable where blocks are long and
> >>> a rapid response is needed by other services, ie a fast pulse cannot
> >>> be measured or possibly separated if the DMA is hogging the processor
> >>> for a period exceeding the interrupt rate. I realise Matthias
> >>> understands this, but perhapos newbies won't.
> >>>
> >>> Al
> >>>
> >>> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
> >>>> "Stefan Hauenstein":
> >>>>
> >>>>> Why you don't use P2.7 as an ordinary interrupt input and read P6
> >>>>> whith every interrupt occured at P2.7?
> >>>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2
> >>>> MCLK cycles - in single transfer mode 4 MCLK cycles. The interrupt
> >>>> needs at least 10 cycles or so - depending on how long I block
> >>>> interrupts in the code. If hardware multiplier is enabled the
> >>>> compiler is using DINT! It is amazing - a 25MHz MSP430X can fetch
> >>>> data at a rate of 200Mbit/s
> >> with
> >>>> DMA in BLOCK mode.
> >>>>
> >>>>> In your case, I would keep the byte stable at least the max. DMA
> >>>>> cycled time. The cycle time depends on the cpu operation mode. Take
> >>>>> a look at table 9-3 in the family users guide.
> >>>> Sure, but this cost me a latch - according to the spec the byte is
> >>>> valid only at one edge of the external CLK (+- some ns). Would be
> >>>> nice to know which of the edges of MCLK are used to read the byte.
> >>>>
> >>>> M.
> >>>>
> >>>>> Stefan
> >>>>>
> >>>>>
> >>>>>
> >>>>> --- In m..., Matthias Weingart wrote:
> >>>>>> Hi guys,
> >>>>>>
> >>>>>> I am using the MPS430F5438A and I want to read a external byte
> >>>>>> stream (at P6 port) to RAM. The byte stream is clocked externally.
> >>>>>> I put this CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal).
> >>>>>> According to the datasheet this needs 4 MCLK's. The external CLK is
> >>>>>> asynchronous to MCLK. The question is: when is the byte at input
> >>>>>> port P6 read? In
> >> which
> >>>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
> >>>>>> Any ideas how long I have to hold the byte stable at P6?
> >>>>>> My assumptions:
> >>>>>> 1st cycle: synchronise to P2.7
> >>>>>> 2nd cycle: read P6
> >>>>>> 3rd cycle: write to RAM
> >>>>>> 4th cycle: synchronise P2.7 (release)
> >>>>>>
> >>>>>> Is there a better way to get a external clocked byte stream into
> >>>>>> RAM?
> >>>>>>
> >>>>>> Thx
> >>>>>> Matthias
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
Reply by ●January 17, 20122012-01-17
iT isn't always easy to simply double the clock speed. Burst Mode and
DMA may work for one function, since 2 channels are needed to implement
effective SPI or full duplex UART, thus, as I pointed out, with multiple
peripherals requiring high speed access DMA can be a hindrance using
long bursts. I don't find any issues using devices with 'true' DMA
capability, for a start many of them typically have up to 8 channels,
far more useful than the 3 on an MSP.
Given the comparatively high price of the MSP430 family, especially the
higher end devices with DMA, compared to, say the EFM32 family, I'm
surprised that Ti couldn't have afforded true DMA capability, as this
would have added to the low power features.
Al
On 17/01/2012 6:45 PM, Matthias Weingart wrote:
> Al,
> in case you use burst block DMA - the transfer I mentioned below takes 1.2
> ms instead of 0.6ms, but the CPU is still working at half of the clock
> rate. If you was working with 8MHz before double the CPU clock to 16MHz and
> you have the same response time for interrupts.
> Burst Block Mode DMA is the best compromise possible with the simple
> architecture of the MSP (single port RAM inside the MSP). If you need CPU
> access and DMA at the same time, the solution is dual port RAM - 2 data
> busses and synchronisation and more trouble ...
>
> M.
>
> Onestone:
>
>> 0.6ms is an absolute lifetime! I wouldn't allow any single process to
>> hog that much time! I give clock cycles away sparingly! Seriously I am
>> reading multiple multi-axis sensors at quite high sample rates and
>> storing to SD card. I just can't afford to miss a sample. A true DMA
>> would be great, but since there are only 3 channels, and typically
>> anything comms might require 2 channels to be truly effective it kind of
>> limits its usefulness to me. Again another reason why I've been looking
>> for a better low current solution for a while now.
>>
>> Al
>>
>> On 17/01/2012 3:29 AM, Matthias Weingart wrote:
>>> Al,
>>>
>>> You can use burst block mode DMA if you still need the CPU during DMA.
>>> 4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However there is
>>> only little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit size will
>>> block the CPU for 0.6ms only :-).
>>>
>>> M.
>>>
>>> Onestone:
>>>
>>>> I agree with Matthias, DMA is generally better than plain interrupts
>>>> if handled properly, however the MSP430 doesn't have a traditional
>>>> DMA, which is truly independent of the cpu, so many compromises have
>>>> to be made, rendering Block mode unsuitable where blocks are long and
>>>> a rapid response is needed by other services, ie a fast pulse cannot
>>>> be measured or possibly separated if the DMA is hogging the processor
>>>> for a period exceeding the interrupt rate. I realise Matthias
>>>> understands this, but perhapos newbies won't.
>>>>
>>>> Al
>>>>
>>>> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
>>>>> "Stefan Hauenstein":
>>>>>
>>>>>> Why you don't use P2.7 as an ordinary interrupt input and read P6
>>>>>> whith every interrupt occured at P2.7?
>>>>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2
>>>>> MCLK cycles - in single transfer mode 4 MCLK cycles. The interrupt
>>>>> needs at least 10 cycles or so - depending on how long I block
>>>>> interrupts in the code. If hardware multiplier is enabled the
>>>>> compiler is using DINT! It is amazing - a 25MHz MSP430X can fetch
>>>>> data at a rate of 200Mbit/s
>>> with
>>>>> DMA in BLOCK mode.
>>>>>
>>>>>> In your case, I would keep the byte stable at least the max. DMA
>>>>>> cycled time. The cycle time depends on the cpu operation mode. Take
>>>>>> a look at table 9-3 in the family users guide.
>>>>> Sure, but this cost me a latch - according to the spec the byte is
>>>>> valid only at one edge of the external CLK (+- some ns). Would be
>>>>> nice to know which of the edges of MCLK are used to read the byte.
>>>>>
>>>>> M.
>>>>>
>>>>>> Stefan
>>>>>>
>>>>>>
>>>>>>
>>>>>> --- In m..., Matthias Weingart wrote:
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> I am using the MPS430F5438A and I want to read a external byte
>>>>>>> stream (at P6 port) to RAM. The byte stream is clocked externally.
>>>>>>> I put this CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal).
>>>>>>> According to the datasheet this needs 4 MCLK's. The external CLK is
>>>>>>> asynchronous to MCLK. The question is: when is the byte at input
>>>>>>> port P6 read? In
>>> which
>>>>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>>>>>> Any ideas how long I have to hold the byte stable at P6?
>>>>>>> My assumptions:
>>>>>>> 1st cycle: synchronise to P2.7
>>>>>>> 2nd cycle: read P6
>>>>>>> 3rd cycle: write to RAM
>>>>>>> 4th cycle: synchronise P2.7 (release)
>>>>>>>
>>>>>>> Is there a better way to get a external clocked byte stream into
>>>>>>> RAM?
>>>>>>>
>>>>>>> Thx
>>>>>>> Matthias
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
DMA may work for one function, since 2 channels are needed to implement
effective SPI or full duplex UART, thus, as I pointed out, with multiple
peripherals requiring high speed access DMA can be a hindrance using
long bursts. I don't find any issues using devices with 'true' DMA
capability, for a start many of them typically have up to 8 channels,
far more useful than the 3 on an MSP.
Given the comparatively high price of the MSP430 family, especially the
higher end devices with DMA, compared to, say the EFM32 family, I'm
surprised that Ti couldn't have afforded true DMA capability, as this
would have added to the low power features.
Al
On 17/01/2012 6:45 PM, Matthias Weingart wrote:
> Al,
> in case you use burst block DMA - the transfer I mentioned below takes 1.2
> ms instead of 0.6ms, but the CPU is still working at half of the clock
> rate. If you was working with 8MHz before double the CPU clock to 16MHz and
> you have the same response time for interrupts.
> Burst Block Mode DMA is the best compromise possible with the simple
> architecture of the MSP (single port RAM inside the MSP). If you need CPU
> access and DMA at the same time, the solution is dual port RAM - 2 data
> busses and synchronisation and more trouble ...
>
> M.
>
> Onestone:
>
>> 0.6ms is an absolute lifetime! I wouldn't allow any single process to
>> hog that much time! I give clock cycles away sparingly! Seriously I am
>> reading multiple multi-axis sensors at quite high sample rates and
>> storing to SD card. I just can't afford to miss a sample. A true DMA
>> would be great, but since there are only 3 channels, and typically
>> anything comms might require 2 channels to be truly effective it kind of
>> limits its usefulness to me. Again another reason why I've been looking
>> for a better low current solution for a while now.
>>
>> Al
>>
>> On 17/01/2012 3:29 AM, Matthias Weingart wrote:
>>> Al,
>>>
>>> You can use burst block mode DMA if you still need the CPU during DMA.
>>> 4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However there is
>>> only little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit size will
>>> block the CPU for 0.6ms only :-).
>>>
>>> M.
>>>
>>> Onestone:
>>>
>>>> I agree with Matthias, DMA is generally better than plain interrupts
>>>> if handled properly, however the MSP430 doesn't have a traditional
>>>> DMA, which is truly independent of the cpu, so many compromises have
>>>> to be made, rendering Block mode unsuitable where blocks are long and
>>>> a rapid response is needed by other services, ie a fast pulse cannot
>>>> be measured or possibly separated if the DMA is hogging the processor
>>>> for a period exceeding the interrupt rate. I realise Matthias
>>>> understands this, but perhapos newbies won't.
>>>>
>>>> Al
>>>>
>>>> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
>>>>> "Stefan Hauenstein":
>>>>>
>>>>>> Why you don't use P2.7 as an ordinary interrupt input and read P6
>>>>>> whith every interrupt occured at P2.7?
>>>>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2
>>>>> MCLK cycles - in single transfer mode 4 MCLK cycles. The interrupt
>>>>> needs at least 10 cycles or so - depending on how long I block
>>>>> interrupts in the code. If hardware multiplier is enabled the
>>>>> compiler is using DINT! It is amazing - a 25MHz MSP430X can fetch
>>>>> data at a rate of 200Mbit/s
>>> with
>>>>> DMA in BLOCK mode.
>>>>>
>>>>>> In your case, I would keep the byte stable at least the max. DMA
>>>>>> cycled time. The cycle time depends on the cpu operation mode. Take
>>>>>> a look at table 9-3 in the family users guide.
>>>>> Sure, but this cost me a latch - according to the spec the byte is
>>>>> valid only at one edge of the external CLK (+- some ns). Would be
>>>>> nice to know which of the edges of MCLK are used to read the byte.
>>>>>
>>>>> M.
>>>>>
>>>>>> Stefan
>>>>>>
>>>>>>
>>>>>>
>>>>>> --- In m..., Matthias Weingart wrote:
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> I am using the MPS430F5438A and I want to read a external byte
>>>>>>> stream (at P6 port) to RAM. The byte stream is clocked externally.
>>>>>>> I put this CLK to P2.7 pin (DMAE0 this is DMATrigger31 signal).
>>>>>>> According to the datasheet this needs 4 MCLK's. The external CLK is
>>>>>>> asynchronous to MCLK. The question is: when is the byte at input
>>>>>>> port P6 read? In
>>> which
>>>>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>>>>>> Any ideas how long I have to hold the byte stable at P6?
>>>>>>> My assumptions:
>>>>>>> 1st cycle: synchronise to P2.7
>>>>>>> 2nd cycle: read P6
>>>>>>> 3rd cycle: write to RAM
>>>>>>> 4th cycle: synchronise P2.7 (release)
>>>>>>>
>>>>>>> Is there a better way to get a external clocked byte stream into
>>>>>>> RAM?
>>>>>>>
>>>>>>> Thx
>>>>>>> Matthias
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
Reply by ●January 17, 20122012-01-17
The EFM32 is available since about 2 years(?). Sure they are now (10 years
after a MSP430 with DMA) a better option to choose - in case you design a
new project. The first thing that comes to mind is the non segmented
address space (compared to the MSP430X). After looking through the
datasheets - I think they have learned from the MSP430 do some things
better, but provide almost the same functionality (apart from the better
CPU). RAM and Flash options available (able to buy!) are not larger than
MSP430F5... Price seems quite similar (at digikey, both 128kFlash 16kRAM
versions go for about $3).
However, how is the availability? I will never use MAXIM again because of
bad availabilities in the past, energy micro is quite small also ....
M.
Onestone :
> iT isn't always easy to simply double the clock speed. Burst Mode and
> DMA may work for one function, since 2 channels are needed to implement
> effective SPI or full duplex UART, thus, as I pointed out, with multiple
> peripherals requiring high speed access DMA can be a hindrance using
> long bursts. I don't find any issues using devices with 'true' DMA
> capability, for a start many of them typically have up to 8 channels,
> far more useful than the 3 on an MSP.
>
> Given the comparatively high price of the MSP430 family, especially the
> higher end devices with DMA, compared to, say the EFM32 family, I'm
> surprised that Ti couldn't have afforded true DMA capability, as this
> would have added to the low power features.
>
> Al
>
> On 17/01/2012 6:45 PM, Matthias Weingart wrote:
>> Al,
>> in case you use burst block DMA - the transfer I mentioned below takes
>> 1.2 ms instead of 0.6ms, but the CPU is still working at half of the
>> clock rate. If you was working with 8MHz before double the CPU clock to
>> 16MHz and you have the same response time for interrupts.
>> Burst Block Mode DMA is the best compromise possible with the simple
>> architecture of the MSP (single port RAM inside the MSP). If you need
>> CPU access and DMA at the same time, the solution is dual port RAM - 2
>> data busses and synchronisation and more trouble ...
>>
>> M.
>>
>> Onestone:
>>
>>> 0.6ms is an absolute lifetime! I wouldn't allow any single process to
>>> hog that much time! I give clock cycles away sparingly! Seriously I am
>>> reading multiple multi-axis sensors at quite high sample rates and
>>> storing to SD card. I just can't afford to miss a sample. A true DMA
>>> would be great, but since there are only 3 channels, and typically
>>> anything comms might require 2 channels to be truly effective it kind
>>> of limits its usefulness to me. Again another reason why I've been
>>> looking for a better low current solution for a while now.
>>>
>>> Al
>>>
>>> On 17/01/2012 3:29 AM, Matthias Weingart wrote:
>>>> Al,
>>>>
>>>> You can use burst block mode DMA if you still need the CPU during
>>>> DMA. 4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However
>>>> there is only little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit
>>>> size will block the CPU for 0.6ms only :-).
>>>>
>>>> M.
>>>>
>>>> Onestone:
>>>>
>>>>> I agree with Matthias, DMA is generally better than plain interrupts
>>>>> if handled properly, however the MSP430 doesn't have a traditional
>>>>> DMA, which is truly independent of the cpu, so many compromises have
>>>>> to be made, rendering Block mode unsuitable where blocks are long
>>>>> and a rapid response is needed by other services, ie a fast pulse
>>>>> cannot be measured or possibly separated if the DMA is hogging the
>>>>> processor for a period exceeding the interrupt rate. I realise
>>>>> Matthias understands this, but perhapos newbies won't.
>>>>>
>>>>> Al
>>>>>
>>>>> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
>>>>>> "Stefan Hauenstein":
>>>>>>
>>>>>>> Why you don't use P2.7 as an ordinary interrupt input and read P6
>>>>>>> whith every interrupt occured at P2.7?
>>>>>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2
>>>>>> MCLK cycles - in single transfer mode 4 MCLK cycles. The interrupt
>>>>>> needs at least 10 cycles or so - depending on how long I block
>>>>>> interrupts in the code. If hardware multiplier is enabled the
>>>>>> compiler is using DINT! It is amazing - a 25MHz MSP430X can fetch
>>>>>> data at a rate of 200Mbit/s
>>>> with
>>>>>> DMA in BLOCK mode.
>>>>>>
>>>>>>> In your case, I would keep the byte stable at least the max. DMA
>>>>>>> cycled time. The cycle time depends on the cpu operation mode.
>>>>>>> Take a look at table 9-3 in the family users guide.
>>>>>> Sure, but this cost me a latch - according to the spec the byte is
>>>>>> valid only at one edge of the external CLK (+- some ns). Would be
>>>>>> nice to know which of the edges of MCLK are used to read the byte.
>>>>>>
>>>>>> M.
>>>>>>
>>>>>>> Stefan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --- In m..., Matthias Weingart
>>>>>>> wrote:
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> I am using the MPS430F5438A and I want to read a external byte
>>>>>>>> stream (at P6 port) to RAM. The byte stream is clocked
>>>>>>>> externally. I put this CLK to P2.7 pin (DMAE0 this is
>>>>>>>> DMATrigger31 signal). According to the datasheet this needs 4
>>>>>>>> MCLK's. The external CLK is asynchronous to MCLK. The question
>>>>>>>> is: when is the byte at input port P6 read? In
>>>> which
>>>>>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>>>>>>> Any ideas how long I have to hold the byte stable at P6?
>>>>>>>> My assumptions:
>>>>>>>> 1st cycle: synchronise to P2.7
>>>>>>>> 2nd cycle: read P6
>>>>>>>> 3rd cycle: write to RAM
>>>>>>>> 4th cycle: synchronise P2.7 (release)
>>>>>>>>
>>>>>>>> Is there a better way to get a external clocked byte stream into
>>>>>>>> RAM?
>>>>>>>>
>>>>>>>> Thx
>>>>>>>> Matthias
>>>>>>>>
after a MSP430 with DMA) a better option to choose - in case you design a
new project. The first thing that comes to mind is the non segmented
address space (compared to the MSP430X). After looking through the
datasheets - I think they have learned from the MSP430 do some things
better, but provide almost the same functionality (apart from the better
CPU). RAM and Flash options available (able to buy!) are not larger than
MSP430F5... Price seems quite similar (at digikey, both 128kFlash 16kRAM
versions go for about $3).
However, how is the availability? I will never use MAXIM again because of
bad availabilities in the past, energy micro is quite small also ....
M.
Onestone :
> iT isn't always easy to simply double the clock speed. Burst Mode and
> DMA may work for one function, since 2 channels are needed to implement
> effective SPI or full duplex UART, thus, as I pointed out, with multiple
> peripherals requiring high speed access DMA can be a hindrance using
> long bursts. I don't find any issues using devices with 'true' DMA
> capability, for a start many of them typically have up to 8 channels,
> far more useful than the 3 on an MSP.
>
> Given the comparatively high price of the MSP430 family, especially the
> higher end devices with DMA, compared to, say the EFM32 family, I'm
> surprised that Ti couldn't have afforded true DMA capability, as this
> would have added to the low power features.
>
> Al
>
> On 17/01/2012 6:45 PM, Matthias Weingart wrote:
>> Al,
>> in case you use burst block DMA - the transfer I mentioned below takes
>> 1.2 ms instead of 0.6ms, but the CPU is still working at half of the
>> clock rate. If you was working with 8MHz before double the CPU clock to
>> 16MHz and you have the same response time for interrupts.
>> Burst Block Mode DMA is the best compromise possible with the simple
>> architecture of the MSP (single port RAM inside the MSP). If you need
>> CPU access and DMA at the same time, the solution is dual port RAM - 2
>> data busses and synchronisation and more trouble ...
>>
>> M.
>>
>> Onestone:
>>
>>> 0.6ms is an absolute lifetime! I wouldn't allow any single process to
>>> hog that much time! I give clock cycles away sparingly! Seriously I am
>>> reading multiple multi-axis sensors at quite high sample rates and
>>> storing to SD card. I just can't afford to miss a sample. A true DMA
>>> would be great, but since there are only 3 channels, and typically
>>> anything comms might require 2 channels to be truly effective it kind
>>> of limits its usefulness to me. Again another reason why I've been
>>> looking for a better low current solution for a while now.
>>>
>>> Al
>>>
>>> On 17/01/2012 3:29 AM, Matthias Weingart wrote:
>>>> Al,
>>>>
>>>> You can use burst block mode DMA if you still need the CPU during
>>>> DMA. 4 MCLK cycles: 2 for one DMA transfer, 2 for the CPU. However
>>>> there is only little RAM - 16kbyte with Block DMA (2MCLK) and 16 bit
>>>> size will block the CPU for 0.6ms only :-).
>>>>
>>>> M.
>>>>
>>>> Onestone:
>>>>
>>>>> I agree with Matthias, DMA is generally better than plain interrupts
>>>>> if handled properly, however the MSP430 doesn't have a traditional
>>>>> DMA, which is truly independent of the cpu, so many compromises have
>>>>> to be made, rendering Block mode unsuitable where blocks are long
>>>>> and a rapid response is needed by other services, ie a fast pulse
>>>>> cannot be measured or possibly separated if the DMA is hogging the
>>>>> processor for a period exceeding the interrupt rate. I realise
>>>>> Matthias understands this, but perhapos newbies won't.
>>>>>
>>>>> Al
>>>>>
>>>>> On 16/01/2012 8:27 PM, Matthias Weingart wrote:
>>>>>> "Stefan Hauenstein":
>>>>>>
>>>>>>> Why you don't use P2.7 as an ordinary interrupt input and read P6
>>>>>>> whith every interrupt occured at P2.7?
>>>>>> Interrupts are much slower. In BLOCK mode the DMA is needing only 2
>>>>>> MCLK cycles - in single transfer mode 4 MCLK cycles. The interrupt
>>>>>> needs at least 10 cycles or so - depending on how long I block
>>>>>> interrupts in the code. If hardware multiplier is enabled the
>>>>>> compiler is using DINT! It is amazing - a 25MHz MSP430X can fetch
>>>>>> data at a rate of 200Mbit/s
>>>> with
>>>>>> DMA in BLOCK mode.
>>>>>>
>>>>>>> In your case, I would keep the byte stable at least the max. DMA
>>>>>>> cycled time. The cycle time depends on the cpu operation mode.
>>>>>>> Take a look at table 9-3 in the family users guide.
>>>>>> Sure, but this cost me a latch - according to the spec the byte is
>>>>>> valid only at one edge of the external CLK (+- some ns). Would be
>>>>>> nice to know which of the edges of MCLK are used to read the byte.
>>>>>>
>>>>>> M.
>>>>>>
>>>>>>> Stefan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --- In m..., Matthias Weingart
>>>>>>> wrote:
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> I am using the MPS430F5438A and I want to read a external byte
>>>>>>>> stream (at P6 port) to RAM. The byte stream is clocked
>>>>>>>> externally. I put this CLK to P2.7 pin (DMAE0 this is
>>>>>>>> DMATrigger31 signal). According to the datasheet this needs 4
>>>>>>>> MCLK's. The external CLK is asynchronous to MCLK. The question
>>>>>>>> is: when is the byte at input port P6 read? In
>>>> which
>>>>>>>> of the 4 MCLK's? I see no timing diagram in the datasheet.
>>>>>>>> Any ideas how long I have to hold the byte stable at P6?
>>>>>>>> My assumptions:
>>>>>>>> 1st cycle: synchronise to P2.7
>>>>>>>> 2nd cycle: read P6
>>>>>>>> 3rd cycle: write to RAM
>>>>>>>> 4th cycle: synchronise P2.7 (release)
>>>>>>>>
>>>>>>>> Is there a better way to get a external clocked byte stream into
>>>>>>>> RAM?
>>>>>>>>
>>>>>>>> Thx
>>>>>>>> Matthias
>>>>>>>>
