Jump to content
Fred

A new MSP430 coming [MSP432 ARM]

Recommended Posts

Out of curiosity, have you looked at the device header file? In there, not only CMSIS but also MSP-style definitions (e.g. #define TACCR0 0xHEX_VALUE) are available. Which one would you rather use for direct hardware access?

Normally I'd say it's an ARM device so I'd use CMSIS structures and the standard PERIPH_REG_FIELD_Tag macros.  But on closer look these structs aren't really standard CMSIS-style definitions.

 

First, there are distinct types for TIMER_A0_Type, TIMER_A1_Type, TIMER_A2_Type, and TIMER_A3_Type, but the definitions are identical.  This means I can't write my code for a common TIMER_A_Type and pass in whichever timer instance I choose to use, because the compiler's been told they're different types.  I'd have to explicitly cast the pointers, which is poor practice.

 

Also, they're using some bizarre Hungarian naming solution on a union to provide bitfields within each register, so instead of just referencing SYSCTL->SYSTEM_STAT I'd have to do SYSCTL->rSYSTEM_STAT.r if I wanted the whole register.

 

So, we either manipulate the register fields as bitfields independently on an MCU that doesn't have the BIC/BIS atomic RMW operations of the MSP430 that make such operations remotely sane, or we have to deal with a metric crap-ton of syntactic sugar smeared all over the native 32-bit mapped registers.

 

Ugh.  Looks like TI still hasn't fully grasped how to do Cortex-M.  I probably won't bother getting one of these.

Share this post


Link to post
Share on other sites

Only other info I've found in that there's a MSP432P401M with half the flash and RAM. both devices will come in 100PZ (LQFP), 80ZXH (BGA) and 64RGC (QFN) packages.

Share this post


Link to post
Share on other sites

I didn't see this posted yet but the porting guide is up: http://www.ti.com/lit/an/slaa656/slaa656.pdfA bit more info about the MSP432 inside.

 

For those to lazy to read this document, here a good overview of the new MSP432 series (from the document linked above).


 

3.2 Peripherals

The initial MSP432 family provides a blend of the ultra-low-power peripherals previously introduced in

MSP430 and a number of new peripherals to provide enhanced performance.

 

The shared peripherals operate in the same manners across MSP430 and MSP432 platforms, with the

only exception being their interrupt signals and handling procedures due to the new Nested Vectored

Interrupt Controller (NVIC) module on MSP432. Refer to Section 4 for more details on porting MSP430

interrupt to NVIC. Register definitions and their descriptions in the header files are therefore identical

across different families, enabling code reuse whether using register-level access or higher abstraction

code such as MSP Driver Library.

 

Some peripherals on MSP432 receive slight modifications and performance improvements over their

MSP430 counterparts. One example is the ADC14, which is an improved version of the ADC12_B. While

their shared features and operations can be leveraged and reused, the new and improved features such

as improved resolution (from 12-bit to 14-bit) or increased sampling rate (from 200 ksps to 1 Msps) require

new design and software considerations.

 

The last group of peripherals on MSP432 that are new to the MSP platform are the peripherals that were

derived or inherited from ARM such as the uDMA, Timer32, or SysTick. These modules add new

functionalities to the device, and require further modification to the existing system and code to realize the

new functions. Particularly with the uDMA module, extensive amount of features and capabilities were

introduced that can be seen as an upgrade from the MSP430 DMA. Further investigation at the system

design level should be paid to leverage these features in an MSP432 application.

Share this post


Link to post
Share on other sites

48MHz at 95uA/MHz... so 4.5mA or so. Just barely more than the G2553 at 16MHz? And you get ARM Cortex-M4F?

 

Sent from my Galaxy Note II with Tapatalk 4

 

And where is the drawback? Is it just the core power consumption? I'm not familiar with the ARM M4 design, but I think that you turn of peripherals if they are not needed to save power. Maybe 95uA is just the core with all/most of the peripherals turned off?

Share this post


Link to post
Share on other sites

And where is the drawback? Is it just the core power consumption? I'm not familiar with the ARM M4 design, but I think that you turn of peripherals if they are not needed to save power. Maybe 95uA is just the core with all/most of the peripherals turned off?

 

I'm sure there will be a lot of caveats to achieve that number. One for a start: The 95uA/MHz applies to the DC/DC regulator, which is recommended when running the MCU at 24MHz+. The integrated LDO has lower efficiency, so the uA/MHz will be higher for lower clock speeds.

 

The training video series has a whole section devoted to power consumption:

http://training.ti.com/msp432%E2%84%A2-low-power-high-performance-mcus-part-3-power-system

 

And there's already an app note on that very topic:

Maximizing MSP432P4xx Voltage Regulator Efficiency: DC-DC and LDO Features and Tradeoffs

http://www.ti.com/lit/an/slaa640/slaa640.pdf

Share this post


Link to post
Share on other sites

Normally I'd say it's an ARM device so I'd use CMSIS structures and the standard PERIPH_REG_FIELD_Tag macros.  But on closer look these structs aren't really standard CMSIS-style definitions.

 

Out of interest, which manufacturer(s) actually get this right?

Share this post


Link to post
Share on other sites

Out of interest, which manufacturer(s) actually get this right?

Silicon Labs (the Energy Micro line) and Nordic (the nRF51 line) are two I have personal experience with. There are "right" ones for Tiva out on github, which I think somebody generated from CMSIS-SVD files using ARM tools, but for some reason TI isn't providing them directly.

 

It's frustrating because TI appears to be doing more work to generate headers that aren't consistent with what other Cortex-M vendors produce. Maybe they think their approach is better somehow.

Share this post


Link to post
Share on other sites

The 4.32$ offer will only be available on May 2nd on the TI store but it won't be honored because it will be out of range of the April[] array and cause a segfault ;-)

Share this post


Link to post
Share on other sites

It's frustrating because TI appears to be doing more work to generate headers that aren't consistent with what other Cortex-M vendors produce. Maybe they think their approach is better somehow.

 

My guess is, that they stick with the broken format for Stellaris/Tiva backward compatibility.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×