Have feedback for TI? Please share here.

[spirilis 1,265]

Shipping in The Netherlands is (only) $7 USD.

 

But I think TI's Euro disti hub is in this country.

Ah ok, so maybe they already have one .... nevermind then

[yyrkoon 250]

Energia: Personally, I do not care for it. I've used the toolchain provided with Energia, coupled with flexible IDE's. That's about it. However, it seems to be an open sourced project, with several libraries and examples. So I do not view it as a bad thing. For others. The example / library source code I think is even interesting to look through now and again too.

 

Documentation: I've been saying this for years. TI might have the best documentation for their parts. Out of any company. Maybe not. But it still needs vast improvement. Attempting to understand a concept in hardware can be tedious enough without having to read through text that has poor choice for wording. Diagrams that have no meaning, or are hard to read through. Or having to span multiple sections in the documentation in order to understand a single concept.

 

Specific to the AM335X( beagleboard community ). Your kernel developers seem to be fighting against the community. They work on their own kernel that has wildly different features enabled when compared to the mainline community kernel. uio_pruss versus remoteproc for the PRU's for instance. uio_pruss has been around since the beaglebone white. It is proven, fast, and works very well for most, if not all situation. So if us developers who have need of power management, which is also only in the TI kernel, we're forced to endure remoteproc which is so far very untested, slower, and very poorly documented.  e.g. It's still highly experimental. This is also just one example. There is more . . .

 

So TI do the Sitara community a favor and quit fighting against us and at least act like you're glad you have us to help further your software. It would be really nice to have multiple config's offered by your devs, or at least documentation as to what is needed to add, or remove features from various TI, or mainline kernels.

[solipso 8]

I do not use TI parts any more, but others who do so would maybe appreciate:

- more eloquent errata, with code snippets. Each erratum should have at least one full page of clear and comprehensive description, dependencies and workarounds.

- a poster for each micro: with pinout, basic characteristics, all peripherals, their registers, HAL library function names and parameters. It is extremely helpful to have a quick reference on one big A0 or A1 page.

[GrumpyOldPizza 15]

Here my 2 cents (after having used a bunch of the parts going back to the Luminary Micro days).

 

- get rid of the MSP432. It's a mess compared to other Cortex-M4 parts (yes, even low power ones). If you want a good low power part, please use the same peripherals as on TM4C, so that code can be reused.

 

- a TM4C129 Launchpad with the dimensions of the TM4C123 launchpad

 

- add CMSIS-DAP to the ARM Cortex based launchpads. Nobody really wants to see yet another vendor specific protocol like the LMICDI (not that gdb remote serial was not a nice idea, it's just it did not pan out).

 

Not sure what else to say. I fundamentally think TI took the wrong turn with MSP432, which it seems to have left to die a lonely death. Perhaps folks coming from MSP430 see that different, but it's a massive turnoff for everybody coming from more grown up microcontroller.

 

 

- Thomas

[L.R.A 78]

Perhaps folks coming from MSP430 see that different, but it's a massive turnoff for everybody coming from more grown up microcontroller.

 

 

- Thomas

 

I think that was the idea.

 

?I'm a fan of ARM-M parts and I like TI parts but with only ARM-M4 on the portfolio I began to use more STM32. I would like to see a bigger range on ARM-M parts, including lower priced and lower power (ARM-M0 and such).

 

?I think the resource explorer should be more explored also, in the TM4C I found a bit hard to find the info.

 

 

?Also in general. I think there should be a guide to the documents of a microcontroller.

The TM4C team makes them one way, the MSP430 another, the Hercules another, etc.

There could be like a little doc, on the main page of the MCU, with a summary of the info available and what to consult for what. This I think it's especially great for new students! And it would not be that hard! The markers that are already inside the datasheets and other documents would be enough.

?Just a document with each file name, each one with the marker titles.

 

I know it would be harder to update it with the rise of new documents, but this being done for the datasheets and general app notes and guides for libraries that are always the same for the family, would be really appreciated by students. The resource explorer would be also great, you can easily see and find various files.

 

 

?About the TI store. I won't buy 1 thing. No matter if got a coupon for 1 free launchpad. I am not paying 30$ (I think it's more) for shipping, period. Too bad because some things I can't find in local distributors. Maybe there could be a discount or free shipping when you get like 60$ - again for students it's great because we usually get together for purchases to get these discounts.

Samples... well it's a bit sad because it helped me ALOT as a student. I tried lots of ideas, lots of components. Now not really... I was lucky to enjoy it while it lasted. I can understand why they changed it and I would like to just leave my thanks for having that for how long it lasted.

[bluehash 1,581]

Thank you all. This is very good. Please keep the feedback flowing. 

[GrumpyOldPizza 15]

I think that was the idea.

 

?I'm a fan of ARM-M parts and I like TI parts but with only ARM-M4 on the portfolio I began to use more STM32. I would like to see a bigger range on ARM-M parts, including lower priced and lower power (ARM-M0 and such).

 

 

The Cortex-M4 only is not a big grief for me, probably the other way around. I like the FPU over the M3. The M0 is a nightmare, as a lot of the good debugging features that M3/M4 have get deleted on M0. Even fundamental things like the DWT_CYCCNT ... As far as I understand the M4 is also more power-efficient than M0, because it can get work done faster, after which you can put it to sleep longer. The price different, I really don't know. It's my hobby, and a few bucks either way will not hurt me.

 

The MSP430 peripherals, I simply cannot understand. The older Stellaris parts had been designed with HW FIFOs in place, so you could use UART/SPI without DMA. Of course TM4C now has a 32 channel DMA controller, where you can background a lot of the IO handling. And along comes MSP432, which does away with most of the usable HW FIFOs, and just so that the software cannot compensate, reduced the number of DMA channels to 8. If you have one UART (RX DMA), one SPI (RX/TX DMA) and one I2C (RX DMA), and half of your DMA channels are gone ...

 

Just looking at the feature set (not the crummy HW implementation), STM32L0 & STM32L4 seem to be the better choice. Not that I want promote somebody else's product here, it's just that I don't understand where MSP432 fits there (besides the fact that you still cannot buy the chips).

 

So in a nutshell, please TI, focus on TM4C, bring some new parts and launchpads, perhaps a Cortex-M0+ if that saves costs. 

 

- Thomas

 

- Thomas

[yyrkoon 250]

The Cortex-M4 only is not a big grief for me, probably the other way around. I like the FPU over the M3. The M0 is a nightmare, as a lot of the good debugging features that M3/M4 have get deleted on M0. Even fundamental things like the DWT_CYCCNT ... As far as I understand the M4 is also more power-efficient than M0, because it can get work done faster, after which you can put it to sleep longer. The price different, I really don't know. It's my hobby, and a few bucks either way will not hurt me.

 

The MSP430 peripherals, I simply cannot understand. The older Stellaris parts had been designed with HW FIFOs in place, so you could use UART/SPI without DMA. Of course TM4C now has a 32 channel DMA controller, where you can background a lot of the IO handling. And along comes MSP432, which does away with most of the usable HW FIFOs, and just so that the software cannot compensate, reduced the number of DMA channels to 8. If you have one UART (RX DMA), one SPI (RX/TX DMA) and one I2C (RX DMA), and half of your DMA channels are gone ...

 

Just looking at the feature set (not the crummy HW implementation), STM32L0 & STM32L4 seem to be the better choice. Not that I want promote somebody else's product here, it's just that I don't understand where MSP432 fits there (besides the fact that you still cannot buy the chips).

 

So in a nutshell, please TI, focus on TM4C, bring some new parts and launchpads, perhaps a Cortex-M0+ if that saves costs. 

 

- Thomas

 

- Thomas

Sounds like there are some misconceptions as to what the MSP432 *is*. I will say however that being more power efficient does not mean that efficiency translates into using  less power. An MCU that is more efficient, but does more will very likely use more power - Always.

 

But in this context something like the LPC800 would probably make more sense. *If* you need a lower powered 32bit cortex Mx part, that does not need to do very much.

[GrumpyOldPizza 15]

Sounds like there are some misconceptions as to what the MSP432 *is*. I will say however that being more power efficient does not mean that efficiency translates into using  less power. An MCU that is more efficient, but does more will very likely use more power - Always.

 

Actually if you design your software stack the right way, it does mean exactly that (some caveats apply though). If you need to do some CPU work in response to an external stimulus, then a M4 will do that work faster at the same clock than a M0/M0+. Consequently you can put the CPU to sleep earlier for a longer amount of time. This longer sleep time is what saves you most of the power.  The second main trick to save power is to use DMA for IO transfers, so that you can avoid waking up the CPU from a sleep mode as much as possible (there is a nice application note available from ST, which analyses where clock frequencies are the sweet spot for a given voltage range, assuming that you have to spend a fixed amount of CPU clock cycles; their result was that alway the upper limit for the voltage range was the sweet spot ...).

 

So yes the M4F core in the MSP432 make it more efficient than the MSP430 core, which means in theory it should consume less power (yes, AHB and the efficiency of the sleep modes will affect that as well). But MSP432 is missing or hampering the second cruical part, which is adding peripherals that can offload the CPU to do things like batch acquisition (or sleep-walking as Atmel calls it). 

 

It's also quite telling that the current leader in ULPbench, Ambiq Micro also chose a M4 over a M0 (http://www.extremetech.com/computing/198285-new-microprocessor-claims-10x-energy-improvement-thanks-to-subthreshold-voltage-operation this article contains some of their rationale).

 

Back to MSP432. With it's peripherals, one could argue that this is not the same target market as say a STM32L4 as you need fewer peripherals, less horsepower, and such. But that then raises the question, why upgrade the CPU core from MSP430 at all ? 

 

- Thomas

[yyrkoon 250]

Actually if you design your software stack the right way, it does mean exactly that (some caveats apply though). If you need to do some CPU work in response to an external stimulus, then a M4 will do that work faster at the same clock than a M0/M0+. Consequently you can put the CPU to sleep earlier for a longer amount of time. This longer sleep time is what saves you most of the power.  The second main trick to save power is to use DMA for IO transfers, so that you can avoid waking up the CPU from a sleep mode as much as possible (there is a nice application note available from ST, which analyses where clock frequencies are the sweet spot for a given voltage range, assuming that you have to spend a fixed amount of CPU clock cycles; their result was that alway the upper limit for the voltage range was the sweet spot ...).

 

So yes the M4F core in the MSP432 make it more efficient than the MSP430 core, which means in theory it should consume less power (yes, AHB and the efficiency of the sleep modes will affect that as well). But MSP432 is missing or hampering the second cruical part, which is adding peripherals that can offload the CPU to do things like batch acquisition (or sleep-walking as Atmel calls it). 

 

It's also quite telling that the current leader in ULPbench, Ambiq Micro also chose a M4 over a M0 (http://www.extremetech.com/computing/198285-new-microprocessor-claims-10x-energy-improvement-thanks-to-subthreshold-voltage-operation this article contains some of their rationale).

 

Back to MSP432. With it's peripherals, one could argue that this is not the same target market as say a STM32L4 as you need fewer peripherals, less horsepower, and such. But that then raises the question, why upgrade the CPU core from MSP430 at all ? 

 

- Thomas

I think that actually, it depends on what the wording " more efficient" is actually meant to mean. I've seen all kind of micro's claim that they're so efficient, it *seems* they use less power than another MCU, but it's really just a smokescreen.

 

If you had a msp430g2 do one single thing, and compare it to any cortex part. On paper it can be made to *seem* that the cortex part will use less power. But I bet it wont. Which is of course is much different from comparing an M0/0+ to an M4. Technically though the M0/0+ should use less power.

 

I really do not know the architectures well enough to know one way or another. However, I will say that doing something faster, and then sleeping. Is not an end all be all recipe for lower power usage. It's just one small factor in the mix.

[GrumpyOldPizza 15]

I think that actually, it depends on what the wording " more efficient" is actually meant to mean. I've seen all kind of micro's claim that they're so efficient, it *seems* they use less power than another MCU, but it's really just a smokescreen.

 

If you had a msp430g2 do one single thing, and compare it to any cortex part. On paper it can be made to *seem* that the cortex part will use less power. But I bet it wont. Which is of course is much different from comparing an M0/0+ to an M4. Technically though the M0/0+ should use less power.

 

I really do not know the architectures well enough to know one way or another. However, I will say that doing something faster, and then sleeping. Is not an end all be all recipe for lower power usage. It's just one small factor in the mix.

 

You are mixing up my statements. I said that a M4 is more efficient than a M0. Somebody asked about M4 vs. M0, and I tried to give an answer to that. It has nothing to do with a 430 CPU. That one is different, uses a different internal bus (not AHB/APB and crossbar), does not have nested interrupt vector and so on. It's a different class. It has substantial less CPU horsepower, but if you get away with it, it might consume less power.

 

And yes, with sleeping you are right. It's one piece of the puzzle, but it's in a lot of cases the 75% piece. DMA is another one, clock gating ...

 

- Thomas

[chicken 630]

And along comes MSP432, which does away with most of the usable HW FIFOs, and just so that the software cannot compensate, reduced the number of DMA channels to 8. If you have one UART (RX DMA), one SPI (RX/TX DMA) and one I2C (RX DMA), and half of your DMA channels are gone ...

 

Great discussion! I never used DMA much, so I wonder what the problem is with using half the DMA channels in this scenario. How often do you actually need more than 8 channels?

[GrumpyOldPizza 15]

Great discussion! I never used DMA much, so I wonder what the problem is with using half the DMA channels in this scenario. How often do you actually need more than 8 channels?

 

Good question. For hobby projects it's probably a non-issue. But if you want to be aggressive with power savings it is an issue. Typically i'd always attach a DMA channel to any I2C RX, and any UART RX/TX, as well as SPI RX/TX (for sensor reading up to 4MHz). For my hobby use (Autonomous Rovers), that would be 5 to 7. So, still within 8 channels, but not a lot of spares for software triggered DMA. Perhaps it's just that 16 feels like a more appropriate number (32 definitively too much).

 

Couple of use cases to illustrate:

 

(1) UART, GPS input. I'd use a ping-pong buffer scheme on RX with a receive timeout. Each of the buffers 16 bytes. This way I get an interrupt only every 16 bytes, or when a sequence of reports is done. At 115200 baud this brings the interrupt rate from about 10000 down to less than 800.

 

(2) I2C sensor reading. DMA on RX (with TI also on TX). That means I take 2 interrupts for a typical "send an index, and then read n bytes of data from a sensor". If this is 16 bytes of sensor data, then without DMA you take 19 interrupts.

 

(3) TFT on SPI. Here a double buffer scheme is nice. In one buffer you generate data for the new scanline you are working on, while using DMA on the other buffer to send over data/commands for the previous scanline that had been already generate. One can nicely overlap CPU and SPI. Of course that is not beneficial for all operations.

 

(4) SD on SPI. If you send more than one 512 byte block and want to use CRC16, then you can let the CPU compute this CRC16 on the next block you are about to send, while DMA takes care of sending the current block without CPU interaction ...

 

 

So a lot of uses, at least for me, mainly centered around communication.

[USWaterRockets 57]

It seems like an awful lot of work went into designing the MSP432 and integrating it into the MSP430-centric ecosystem. Migration documentation and tools and all of that take a lot of effort to produce. It seems to me like there must be a reason for all of that effort, and somehow all that work had to be justified. So, perhaps there is a method to their madness, and ultimately it will all make perfect sense when the scope of the plan has been revealed?

[curtis63 5]

Please oh please unify Energia with Code Composer Studio...  The issues below are both related to the MSP430G2553 chip, but probably apply to many others.

 

I have noticed a couple issues with using Code Composer Studio with Energia.

 

Issue 1:

I have noticed a discrepancy in the way libraries work between using Energia within Code Composer Studio and using Energia as a stand alone.

 

For example, if I have a class called SomeTool.h and SomeTool.cpp I have problems getting it to work seamlessly in both environments.

 

For Energia, I need to create a folder called 'SomeTool', put the above 2 files in it, and then put that folder in a folder called Library that exists as a sibling folder to my project folder.

 

For Energia running inside Code Composer Studio, I need to copy the 2 files above into the same project folder that my .ino file lives in.

 

 

Issue 2:

 

There doesn't seem to be an easy way to select which board you are using when you use Code Composer Studio.  Seems like the only way to do it is to change your Include path to replace 'LaunchPad' with 'lauchpad_28pins_16' in the variants folder.  It would be nice to be able to do this via a dropdown and then have it apply to future projects that are created.