MSP432 Launchpad at US$4.32...

[Fred27]

The peripherals are also similar to the MSP430 so makes it easier if you're coming from that background.

I got one when they first came out but haven't had time to use it yet. I'm tempted to get a couple more, but I have drawers cluttered up with unused dev boards that seemed like a great idea at the time.

[AlxDroidDev]

There doesn't seem to be anything unique about the 432, as I recall. Is this still true for this particular chip?

At this time, the price is something unique!

I was talking to a friend of mine last night, told him about this, and he asked me to order 2 more for him, so I got 4 units coming in my direction.

[dannyf]

If their goal is to use a low-end ARM, why do they pick a M4F rather than a M0 or M0+?

[FrankBuss]

Nice chip, it has all you need, including floating point support, nice 32 bit timers, good ADC. The only thing missing is an USB module, then it would be perfect, e.g. for firmware update, like the LPC chips from NXP do by emulating an USB mass storage and you just copy the new firmware to it.

[tszaboo]

If their goal is to use a low-end ARM, why do they pick a M4F rather than a M0 or M0+?

Probably because royalties are 1 cent anyway, and sometimes you just need the extra instructions to finish a task fast, and go to sleep to save power. I think it makes sense. I rather start with a more powerful MCU, usually feature creepness would otherwise require a re-design.

[coppice]

If their goal is to use a low-end ARM, why do they pick a M4F rather than a M0 or M0+?

In most typical MSP43x type applications the device would take more energy to do the same work with an M0 core. Overall energy consumption is about more than just the active power of the core.

[Scrts]

If their goal is to use a low-end ARM, why do they pick a M4F rather than a M0 or M0+?

Probably because royalties are 1 cent anyway, and sometimes you just need the extra instructions to finish a task fast, and go to sleep to save power. I think it makes sense. I rather start with a more powerful MCU, usually feature creepness would otherwise require a re-design.

Or they're already selling more M4's, than M0's, so the quantities bring down the price even further.

[Brutte]

There doesn't seem to be anything unique about the 432

they're positioning it as the low-power ARM chip; it has about 1/10th the power consumption of the lm4f120s (~6ma active vs ~50ma active.)

LM4F120H5QR (from Stellaris Launchpad) draws 50mA > 3.0V, 80MHz, all peripherals ON, preliminary.

MSP432P401R (from this launchpad) with built-in DC-DC converter draws 4.6mA > 3.0V, 48MHz all peripherals OFF.

It is not possible to directly compare the technology improvement between both products as there is not enough comparable data. When MSP432 runs from LDO then:

MSP432P401R (from this launchpad) with built-in DC-DC converter draws 7.6mA > 3.0V, 48MHz all peripherals OFF.

After Luminary Micro takeover TI has renamed LM4F120H5QR to TM4C1233H6PM which has more complete "Current consumption" chapter:

TM4C1233H6PM (from Tiva Launchpad) draws 24.7mA >3.3V, 80MHzall peripherals OFF.

It is true a built-in DC-DC is a nice feature but you know, DC-DC in a battery operated device won't ramp up instantly when you need a 1ms burst of processing power.
Concluding, it looks like an improvement but needs some real life measurements to quantify that.

EDIT: Forgot 80MHz

[dannyf]

I asked and the answer I got back is that since they expect those chips to be used primarily in sleep, a faster processor doesn't have to be on as long as a slower processor completing a given task. This minimizes the average current consumption over a given period of time -> aka the processor's on time is reduced, at the expensive of on time current.

Makes sense. But the active mode current consumption quoted by TI is 90ua/Mhz -> 300uw/Mhz, vs. <100uw/Mhz quoted by ARM for M0/M0+ -> granted, not exactly comparable but the M4F has to execute the same tasks 3x as fast to make up for that difference. That can be true for highly numerical applications but hard to imagine it for flipping pins type applications.

I also noted that TI marked the <10us start-up time somewhere in the datasheet.

[suicidaleggroll]

And they've already arrived...I just placed the order two days ago late in the afternoon!
As expected they're still using the beta chips.

[jwm_]

I bit. I was always a fan of the MSP430 family, It is a very clean architecture, it always struck me as exactly what one would come up with if presented with the task of creating a 16 bit cpu as a senior project. (and that's a good thing.)

I wonder if they will do an ARM based FRAM chip. that would be pretty neat.

[mtdoc]

Mine arrived today as well. Curiously, it appears to have been packaged and shipped by Digikey.

[Monkeh]

Mine arrived today as well. Curiously, it appears to have been packaged and shipped by Digikey.

Digikey stock and supply their samples and store products in the US.

[mtdoc]

Mine arrived today as well. Curiously, it appears to have been packaged and shipped by Digikey.

Digikey stock and supply their samples and store products in the US.

Makes sense. I've ordered dev boards and a few samples from them before but didn't recall that.

[trevwhite]

Real bargain board to evaluate the MSP432. Do people think this chip range will expand to smaller and larger package sizes? I currently use xmega and like that they offer several memory and peripheral vatiantfor same pinout but I have an eye on changing but not decided what to go with. I like TI but I have no clue how good their development setup is.

Very tempted to buy this.for evaluation

[dannyf]

I like TI but I have no clue how good their development setup is.

Very good, in my experience with them. And the board is so cheap so you have nothing to lose.

However, those chips seem to be meant to provide a 32-bit upward path for the msp430 users. It is uncertain that they will take off and future chips are forthcoming.

If you don't have a lot software invested in msp430, and just want to move to ARM chips, I would take a look at TI's offering there and by-pass this one.

BTW, anything is a big step up from xmega -> it died before it was introduced.

[trevwhite]

Well I have gotten used to Xmega and they have done the job fine for me for a few years now. I am actually quite happy with them. But I keep feeling I need to start looking for a new arch.

I did get a bit fedup with Atmel tools and workshops. Every time I went to one I came back feeling a bit disappointed. Documentation has not been up to standard quickly enough and the framework actually made life very difficult in my opinion - which is not supposed to be the case!

So what would be the TI offering you would recommend I look at if its not the MSP432, Xmega with occasionally more RAM is my requirements I would say.
 

[dannyf]

TI bought Luminary a few years back and extended their products under the LM4F/TM4C portfolio: those are M4F cores with loads of peripherals. A unique thing about those chips, started by Luminary, is that they have a rom library on chip, which can greatly reduce flash utilization. Lots of ram space if that's what you are going after.

A word of caution: earlier versions suffer from poorly designed analog sections: the wrong ADC sequences on those chips can lock them up.

[Brutte]

A unique thing about those chips, started by Luminary, is that they have a rom library on chip

Provided libraries also offer a convenient way of switching in between ROMed and FLASHed libraries. Some LPC cortexes (like LPC11C32 and USB series) also come with ROMed libraries.

[neslekkim]

How do you mean convenient?, Remove/add the ROM_ on all functionnames?, or is there better ways? so far I have used GPIOPinWrite or ROM_GPIOPinWrite..

Is the rom fixed?, not updateable?, ie, if the driverlib is bugfixed, you can risk bumping the codesize a lot..

[newbrain]

How do you mean convenient?, Remove/add the ROM_ on all functionnames?, or is there better ways? so far I have used GPIOPinWrite or ROM_GPIOPinWrite..

Is the rom fixed?, not updateable?, ie, if the driverlib is bugfixed, you can risk bumping the codesize a lot..

There is actually an automatic way of selecting ROM vs. Flash libraries: using a MAP_ prefix, rather than ROM_:

While the majority of DriverLib APIs are available in ROM, due to architectural limitations some
APIs are omitted from being included in ROM. In addition, if any bug fixes were added to the API
after the device ROM was programmed, it is desirable to use the flash version of the API. An
"intelligence" has been created to account for this problem. If the user includes the rom_map.h
header file and uses the MAP_ prefix in front of the API, the header file will automatically use
preprocessor macros to decide whether to use a ROM or flash version of the API.

Of course, this does not solve the issue of some code size unpredictability you pointed out.

Note that this is from the manual, I did not try it (waiting for the boards...).

[Brutte]

How do you mean convenient?

already replied above.

Is the rom fixed?, not updateable?, ie, if the driverlib is bugfixed, you can risk bumping the codesize a lot..

The advantage of ROM against flash is that it is of order of magnitude cheaper. There would be no point providing updateable libraries.

If there is a bug then most likely only in one location. Besides usage of ROM libs is not mandatory, you can always provide your own implementation of some function if you want to.

Another option would be to use FPB unit (the "FP" stands for "Flash Patch" ).

[dannyf]

How do you mean convenient?

Each chip's header defines which function is rom implemented. So the MAP_ macro can be referrenced to either the driverlib or its rom version at compile time.

From my good old LM3S days.

[jwm_]

Interesting, apparently the xds110 hardware debugger on the dev kit can be used with othet ARM cpus by jumping over the jtag connection. So this is a pretty cheap hardware arm debugger too.

[dannyf]

I still have trouble accessing the reference manual and the board related documents. Based solely on the skimpy data sheet, I have to ask why so many people seem to be so excited about this chip. Honestly, there doesn't seem to be anything that sets apart this chip. If there is, ti has done a terrible job articulating them.