Matthias EFM is just an example, CPU independetn flash is nothing new,
it's been around longer then the MSP430F, so Ti could well have leaned
on that technology. One great attribute of (most) of these DMA systems
is that they can operate in a background mode when the CPU isturned off,
drawing extremely low current. that would seem to me a far better choice
than a semi-DMA that hogs processor cycles for a so called ultra low
power device..

The EFM micros also have a better range than Ti, going from QFN16 with
4k flash 2k RAM to 1M flash and 128k RAM. Many people in this group have
whined about the lack of RAM on the smaller Ti parts. I've only bought
small volumes and dev kits. Although their service hasn't been quite as
fast as Ti direct there hasn't been any problem.

aL
On 18/01/2012 2:14 AM, Matthias Weingart wrote:
> 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
>>>>>>>>>
> Start a New Thread

Perhaps using one of TI's Stellaris MCUs instead? like EFM micros are based on ARM cortex and corbon copy characteristics...

regards

--- In m..., Onestone wrote:
>
> Matthias EFM is just an example, CPU independetn flash is nothing new,
> it's been around longer then the MSP430F, so Ti could well have leaned
> on that technology. One great attribute of (most) of these DMA systems
> is that they can operate in a background mode when the CPU isturned off,
> drawing extremely low current. that would seem to me a far better choice
> than a semi-DMA that hogs processor cycles for a so called ultra low
> power device..
>
> The EFM micros also have a better range than Ti, going from QFN16 with
> 4k flash 2k RAM to 1M flash and 128k RAM. Many people in this group have
> whined about the lack of RAM on the smaller Ti parts. I've only bought
> small volumes and dev kits. Although their service hasn't been quite as
> fast as Ti direct there hasn't been any problem.
>
> aL
> On 18/01/2012 2:14 AM, Matthias Weingart wrote:
> > 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
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> > Start a New Thread

I haven't seen anything that suggests the Stellaris micros are as low
power as the EFM ones, which have lower sleep modecurrents than the
MSP430. It also runs at 180uA/MHz at 3V, quite a bit better than the
majority of MSPs, and , in addition, has several ultra low power
peripherals that operate without CPU intervention in its low power
modes. It's a pig to set up, and I haven't had much time to familiarise
myself with it as much as I'd like to before using it in anger, but I'm
getting a bit fed up with Ti's inertia regarding low power performance
improvements, in recent years everything has gone the opposite way. Even
the FRAM based parts, which could have been ultra low power, have
serious flaws which mean that in a typical low power design where
run:sleep ratios are very high, it actually draws considerably more
current than a standard part.

Cheers

Al

On 18/01/2012 4:10 AM, carlos wrote:
> Perhaps using one of TI's Stellaris MCUs instead? like EFM micros are based on ARM cortex and corbon copy characteristics...
>
> regards
>
> --- In m..., Onestone wrote:
>> Matthias EFM is just an example, CPU independetn flash is nothing new,
>> it's been around longer then the MSP430F, so Ti could well have leaned
>> on that technology. One great attribute of (most) of these DMA systems
>> is that they can operate in a background mode when the CPU isturned off,
>> drawing extremely low current. that would seem to me a far better choice
>> than a semi-DMA that hogs processor cycles for a so called ultra low
>> power device..
>>
>> The EFM micros also have a better range than Ti, going from QFN16 with
>> 4k flash 2k RAM to 1M flash and 128k RAM. Many people in this group have
>> whined about the lack of RAM on the smaller Ti parts. I've only bought
>> small volumes and dev kits. Although their service hasn't been quite as
>> fast as Ti direct there hasn't been any problem.
>>
>> aL
>> On 18/01/2012 2:14 AM, Matthias Weingart wrote:
>>> 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
>>>>>>>>>>>
>>>
>>>
>>>
>>>
>>>
>>> Start a New Thread

I have already started to use the ST Microelectronics STM32L152 for LCD etc... and low power.  The USB was also an essential functionality.  These cost significantly less than any equivalent MSP.
Graham
 
________________________________
From: Onestone
To: m...
Sent: Tuesday, 17 January 2012, 18:06
Subject: Re: [msp430] Re: Re: Re: F5438A DMA cacle timing for external port
 
I haven't seen anything that suggests the Stellaris micros are as low
power as the EFM ones, which have lower sleep modecurrents than the
MSP430. It also runs at 180uA/MHz at 3V, quite a bit better than the
majority of MSPs, and , in addition, has several ultra low power
peripherals that operate without CPU intervention in its low power
modes. It's a pig to set up, and I haven't had much time to familiarise
myself with it as much as I'd like to before using it in anger, but I'm
getting a bit fed up with Ti's inertia regarding low power performance
improvements, in recent years everything has gone the opposite way. Even
the FRAM based parts, which could have been ultra low power, have
serious flaws which mean that in a typical low power design where
run:sleep ratios are very high, it actually draws considerably more
current than a standard part.

Cheers

Al

On 18/01/2012 4:10 AM, carlos wrote:
> Perhaps using one of TI's Stellaris MCUs instead? like EFM micros are based on ARM cortex and corbon copy characteristics...
>
> regards
>
> --- In m..., Onestone wrote:
>> Matthias EFM is just an example, CPU independetn flash is nothing new,
>> it's been around longer then the MSP430F, so Ti could well have leaned
>> on that technology. One great attribute of (most) of these DMA systems
>> is that they can operate in a background mode when the CPU isturned off,
>> drawing extremely low current. that would seem to me a far better choice
>> than a semi-DMA that hogs processor cycles for a so called ultra low
>> power device..
>>
>> The EFM micros also have a better range than Ti, going from QFN16 with
>> 4k flash 2k RAM to 1M flash and 128k RAM. Many people in this group have
>> whined about the lack of RAM on the smaller Ti parts. I've only bought
>> small volumes and dev kits. Although their service hasn't been quite as
>> fast as Ti direct there hasn't been any problem.
>>
>> aL
>> On 18/01/2012 2:14 AM, Matthias Weingart wrote:
>>> 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
>>>>>>>>>>>
>>>
>>>
>>>
>>>
>>>
>>> Start a New Thread

It is nice to see, that ARM based controllers are now going to low power
now. The last time a did a look at ARM controllers (with integrated Flash
and RAM) they had 50mA in idle mode!

M.

Graham :

> I have already started to use the ST Microelectronics STM32L152 for LCD
> etc... and low power.  The USB was also an essential functionality. 
> These cost significantly less than any equivalent MSP. Graham
>  
> ________________________________
> From: Onestone
> To: m...
> Sent: Tuesday, 17 January 2012, 18:06
> Subject: Re: [msp430] Re: Re: Re: F5438A DMA cacle timing for external
> port
>  
> I haven't seen anything that suggests the Stellaris micros are as low
> power as the EFM ones, which have lower sleep modecurrents than the
> MSP430. It also runs at 180uA/MHz at 3V, quite a bit better than the
> majority of MSPs, and , in addition, has several ultra low power
> peripherals that operate without CPU intervention in its low power
> modes. It's a pig to set up, and I haven't had much time to familiarise
> myself with it as much as I'd like to before using it in anger, but I'm
> getting a bit fed up with Ti's inertia regarding low power performance
> improvements, in recent years everything has gone the opposite way. Even
> the FRAM based parts, which could have been ultra low power, have
> serious flaws which mean that in a typical low power design where
> run:sleep ratios are very high, it actually draws considerably more
> current than a standard part.
>
> Cheers
>
> Al
>
> On 18/01/2012 4:10 AM, carlos wrote:
>> Perhaps using one of TI's Stellaris MCUs instead? like EFM micros are
>> bas
> ed on ARM cortex and corbon copy characteristics...
>>
>> regards
>>
>> --- In m..., Onestone wrote:
>>> Matthias EFM is just an example, CPU independetn flash is nothing new,
>>> it's been around longer then the MSP430F, so Ti could well have leaned
>>> on that technology. One great attribute of (most) of these DMA systems
>>> is that they can operate in a background mode when the CPU isturned
>>> off, drawing extremely low current. that would seem to me a far better
>>> choice than a semi-DMA that hogs processor cycles for a so called
>>> ultra low power device..
>>>
>>> The EFM micros also have a better range than Ti, going from QFN16 with
>>> 4k flash 2k RAM to 1M flash and 128k RAM. Many people in this group
>>> have whined about the lack of RAM on the smaller Ti parts. I've only
>>> bought small volumes and dev kits. Although their service hasn't been
>>> quite as fast as Ti direct there hasn't been any problem.
>>>
>>> aL
>>>
>>>
>>> On 18/01/2012 2:14 AM, Matthias Weingart wrote:
>>>> The EFM32 is available since about 2 years(?). Sure they are now (10
>>>> ye
> ars
>>>> 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
>>>> bette
> r
>>>> CPU). RAM and Flash options available (able to buy!) are not larger
>>>> tha
> n
>>>> MSP430F5... Price seems quite similar (at digikey, both 128kFlash
>>>> 16kRA
> M
>>>> 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
>>>>> implemen
> t
>>>>> effective SPI or full duplex UART, thus, as I pointed out, with
>>>>> multip
> le
>>>>> 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
>>>>> th
> e
>>>>> 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
>>>>>> take
> s
>>>>>> 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
>>>>>>> t
> o
>>>>>>> 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 kin
> d
>>>>>>> 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 bi
> t
>>>>>>>> size will block the CPU for 0.6ms only :-).
>>>>>>>>
>>>>>>>> M.
>>>>>>>>
>>>>>>>> Onestone:
>>>>>>>>
>>>>>>>>> I agree with Matthias, DMA is generally better than plain
>>>>>>>>> interrup
> ts
>>>>>>>>> if handled properly, however the MSP430 doesn't have a
>>>>>>>>> traditional DMA, which is truly independent of the cpu, so many
>>>>>>>>> compromises ha
> ve
>>>>>>>>> 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
>>>>>>>>>>> P
> 6
>>>>>>>>>>> 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
>>>>>>>>>> interrup
> t
>>>>>>>>>> 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
>>>>>>>>>> i
> s
>>>>>>>>>> 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
>>>>>>>>>>>> int
> o
>>>>>>>>>>>> RAM?
>>>>>>>>>>>>
>>>>>>>>>>>> Thx
>>>>>>>>>>>> Matthias
>>>>>>>>>>>>

Start a New Thread