Have feedback for TI? Please share here.

[Fmilburn 446]

Here is something I hope we continue to see on all LaunchPads....  The MSP432 has nice large mounting holes on corners. It makes it really easy to mount or just to put standoffs in the corners for a stability and to keep it off the desk.  Providing the standoffs like was done on the FR6989 is even better.

 

[Clavier 34]

It seems to me like there must be a reason for all of that effort, and somehow all that work had to be justified.

 

Of all the components in an MCU, only the CPU itself is hidden by the compiler; changing anything else would not be portable.

 

By combining an ARM CPU with the MSP430 peripherals, they allow existing MSP430 program(mer)s to use a faster CPU, without having to do much porting.

The MSP432 is useful for somebody coming from MSP430, not from any other ARM.

[GrumpyOldPizza 15]

Of all the components in an MCU, only the CPU itself is hidden by the compiler; changing anything else would not be portable.

 

By combining an ARM CPU with the MSP430 peripherals, they allow existing MSP430 program(mer)s to use a faster CPU, without having to do much porting.

The MSP432 is useful for somebody coming from MSP430, not from any other ARM.

 

Well, there I have to play devils advocate. Isn't part of the value proposition the driverLib ? With the explicit goal of abstracting the peripherals enough so that it should not matter ?

 

Also the CPU cannot be hidden that well by the compiler (but to a large extend). Things like NVIC are really, really different. So at some level there is a massive delta that one could take advantage of.

[Rickta59 589]

Well, there I have to play devils advocate. Isn't part of the value proposition the driverLib ? With the explicit goal of abstracting the peripherals enough so that it should not matter ?

Maybe the driverlib should look like the Arduino API, then it would be the most efficient implementation available.  Direct support from ROM, so zero wait state and ready to go without any layers on top of what most people are doing with msp430ish chips.

[GrumpyOldPizza 15]

Maybe the driverlib should look like the Arduino API, then it would be the most efficient implementation available.  Direct support from ROM, so zero wait state and ready to go without any layers on top of what most people are doing with msp430ish chips.

 

What you are suggesting is more higher level than driverLib, which IMHO is a macro wrapper layer around the device registers. 

 

The problem with such an approach is that coming up with a good abstraction is very hard. There is no real good one-size-fits-all. A good example is ST's HAL (CubeL4 for example). It assumes some higher level locking that a RTOS could supply. The problem is that if you want to use part of the code in both the ISR and the Task/Threads, this will fall apart, and ... well ... you need something different. The Arduino abstraction is nice, but falls short on asynchronous operations. 

 

The best I have seen up to now (but admittedly not used) is Nordic Semi's SDK for nRF5, which splits up things into a HAL and into a driver layer.

[Rickta59 589]

What you are suggesting is more higher level than driverLib, which IMHO is a macro wrapper layer around the device registers. 

I'm suggesting that they implement the most efficient Arduino API and slam it into ROM.  From what I've seen, I can mostly take any Arduino Library and make it work on most Arduino ports.

 

The problem with the driverlib implementation from my perspective is that it assumes you know a lot about the underlying hardware.  If you know that much about the hardware why would you bother to use the driverlib and worry about how someone else implemented the code or even that the code in ROM is consistent for different parts and revisions.

 

Here is one of the MSP430FR5xxx examples:

#include "driverlib.h"

#define TIMER_A_PERIOD 524
#define DUTY_CYCLE  393

void main(void)
{
    //Stop WDT
    WDT_A_hold(WDT_A_BASE);

    //P1.2 as PWM output
    GPIO_setAsPeripheralModuleFunctionOutputPin(
        GPIO_PORT_P1,
        GPIO_PIN2,
        GPIO_PRIMARY_MODULE_FUNCTION
        );

    /*
     * Disable the GPIO power-on default high-impedance mode to activate
     * previously configured port settings
     */
    PMM_unlockLPM5();

    //Generate PWM - Timer runs in Up-Down mode
    Timer_A_outputPWMParam param = {0};
    param.clockSource = TIMER_A_CLOCKSOURCE_SMCLK;
    param.clockSourceDivider = TIMER_A_CLOCKSOURCE_DIVIDER_1;
    param.timerPeriod = TIMER_A_PERIOD;
    param.compareRegister = TIMER_A_CAPTURECOMPARE_REGISTER_1;
    param.compareOutputMode = TIMER_A_OUTPUTMODE_RESET_SET;
    param.dutyCycle = DUTY_CYCLE;
    Timer_A_outputPWM(TIMER_A1_BASE, &param);

    //Enter LPM0
    __bis_SR_register(LPM0_bits);

    //For debugger
    __no_operation();
}

How is that abstract? If I go and grab the same example for the MSP430F55xx chips or the MSP430I2xx chips that code isn't going to work. Maybe it will compile but not work properly.  If you are a professional developer working on a project you are probably going to access the registers directly so you don't have to worry about what some chunk of ROM might or might not have.

 

If you take a look at this same "timer_a_pwm_mode" sample from the driverlib sample from the MSP432 version it looks completely different:

/* DriverLib Includes */
#include "driverlib.h"

/* Standard Includes */
#include <stdint.h>

#include <stdbool.h>

/* Timer_A PWM Configuration Parameter */
Timer_A_PWMConfig pwmConfig =
{
        TIMER_A_CLOCKSOURCE_SMCLK,
        TIMER_A_CLOCKSOURCE_DIVIDER_1,
        32000,
        TIMER_A_CAPTURECOMPARE_REGISTER_1,
        TIMER_A_OUTPUTMODE_RESET_SET,
        3200
};

int main(void)
{
    /* Halting the watchdog */
    MAP_WDT_A_holdTimer();

    /* Setting MCLK to REFO at 128Khz for LF mode
     * Setting SMCLK to 64Khz */
    MAP_CS_setReferenceOscillatorFrequency(CS_REFO_128KHZ);
    MAP_CS_initClockSignal(CS_MCLK, CS_REFOCLK_SELECT, CS_CLOCK_DIVIDER_1);
    MAP_CS_initClockSignal(CS_SMCLK, CS_REFOCLK_SELECT, CS_CLOCK_DIVIDER_2);
    MAP_PCM_setPowerState(PCM_AM_LF_VCORE0);

    /* Configuring GPIO2.4 as peripheral output for PWM  and P6.7 for button
     * interrupt */
    MAP_GPIO_setAsPeripheralModuleFunctionOutputPin(GPIO_PORT_P2, GPIO_PIN4,
            GPIO_PRIMARY_MODULE_FUNCTION);
    MAP_GPIO_setAsInputPinWithPullUpResistor(GPIO_PORT_P1, GPIO_PIN1);
    MAP_GPIO_clearInterruptFlag(GPIO_PORT_P1, GPIO_PIN1);
    MAP_GPIO_enableInterrupt(GPIO_PORT_P1, GPIO_PIN1);

    /* Configuring Timer_A to have a period of approximately 500ms and
     * an initial duty cycle of 10% of that (3200 ticks)  */
    MAP_Timer_A_generatePWM(TIMER_A0_BASE, &pwmConfig);

    /* Enabling interrupts and starting the watchdog timer */
    MAP_Interrupt_enableInterrupt(INT_PORT1);
    MAP_Interrupt_enableSleepOnIsrExit();
    MAP_Interrupt_enableMaster();

    /* Sleeping when not in use */
    while (1)
    {
        MAP_PCM_gotoLPM0();
    }
}

/* Port1 ISR - This ISR will progressively step up the duty cycle of the PWM
 * on a button press
 */
void PORT1_IRQHandler(void)
{
    uint32_t status = MAP_GPIO_getEnabledInterruptStatus(GPIO_PORT_P1);
    MAP_GPIO_clearInterruptFlag(GPIO_PORT_P1, status);

    if (status & GPIO_PIN1)
    {
        if(pwmConfig.dutyCycle == 28800)
            pwmConfig.dutyCycle = 3200;
        else
            pwmConfig.dutyCycle += 3200;

        MAP_Timer_A_generatePWM(TIMER_A0_BASE, &pwmConfig);
    }
}

I guess I just don't see the point of implementing a driverlib that can't be used with different chips.  Whereas the Arduino API is pretty consistent across different architectures and simple to use.  Personally, I prefer to use the chips as efficiently as possible and access registers directly.  Providing the Arduino API in rom seems more useful than the current driverlib implementation.

 

-rick

[Rickta59 589]

BTW: I think it probably a waste of time to do an Arduino API in ROM.  There is no official API reference and it is subject to the whims of a 3rd party that doesn't seem to have any interest in using TI chips.   I guess I was mainly pointing out what I think is a flawed driverlib strategy.

 

-rick

[Fmilburn 446]

 

BTW: I think it probably a waste of time to do an Arduino API in ROM.  There is no official API reference and it is subject to the whims of a 3rd party that doesn't seem to have any interest in using TI chips.   I guess I was mainly pointing out what I think is a flawed driverlib strategy.

It is an interesting idea.  Maybe some of the more useful non-trivial functions that are otherwise a pain to set up and are frequently used.  Properly documented as to what timers are being used, etc.

[USWaterRockets 57]

The biggest flaw with standardizing on an Arduino Driver lib is precisely because it encourages people to NOT learn about the underlying hardware. As soon as they try to connect up a peripheral with a subtle difference, they get completely frustrated and complain about the lack of support for their particular sensor or application. Not everyone is like this, but it is a generalization of a broad swath of Arduino users.

 

There's nothing wrong with learning how I2C works, or how a PWM works. Once you know how they work on one micro, then you understand the fundamentals enough to code the same thing on totally different hardware.

[Clavier 34]

Isn't part of the value proposition the driverLib ? With the explicit goal of abstracting the peripherals enough so that it should not matter ?

 

No; the driverlib does not abstract away the differences between the peripherals. For example, you don't have a single SPI API, you have functions for USCI_A_SPI, USCI_B_SPI, EUSCI_A_SPI, and EUSCI_B_SPI. Similarly for Timer_A, Timer_B.

 

The TI documentation says that the drivers "provide a mechanism that makes it easy to use the device

[Rickta59 589]

No; the driverlib does not abstract away the differences between the peripherals. For example, you don't have a single SPI API, you have functions for USCI_A_SPI, USCI_B_SPI, EUSCI_A_SPI, and EUSCI_B_SPI. Similarly for Timer_A, Timer_B.

 

The TI documentation says that the drivers "provide a mechanism that makes it easy to use the device

[GrumpyOldPizza 15]

The biggest flaw with standardizing on an Arduino Driver lib is precisely because it encourages people to NOT learn about the underlying hardware. As soon as they try to connect up a peripheral with a subtle difference, they get completely frustrated and complain about the lack of support for their particular sensor or application. Not everyone is like this, but it is a generalization of a broad swath of Arduino users.

 

 

The goal of the Arduino API is precisely to be usable for the dumbest possible user so that they can get simple things going quickly and then tinker around with the more complex stuff. While it is trivially possible to do more complex stuff (like a flight controller), it is not the goal of the Arduino/Wiring mindset.

 

Not learning about the underlying hardware is often what I want. There is no good reason to know about all the details of an I2C peripheral on the 23rd different ARM controller. All I really want is to transmit/receive bytes. 

[GrumpyOldPizza 15]

No; the driverlib does not abstract away the differences between the peripherals. For example, you don't have a single SPI API, you have functions for USCI_A_SPI, USCI_B_SPI, EUSCI_A_SPI, and EUSCI_B_SPI. Similarly for Timer_A, Timer_B.

 

The TI documentation says that the drivers "provide a mechanism that makes it easy to use the device

[USWaterRockets 57]

This is very interesting. We were discussing the rationale for the MSP432, and this interesting video came out from Mike Szczys, the senior editor of Hackaday. He discusses the feud between the 8-bit and 32-bit camps and after watching the video, I can get an appreciation for why TI has created the MSP432.

 

https://youtu.be/kz0yCrikZBE

 

The feeling I get is that the MSP432 fills the gap or bridges between an 8-bit device, with their simple and easy to learn peripherals, and a 32-bit design with their complex peripherals that are intimidating and confusing to a person just starting out.

 

You get the speed and benefits of a 32-bit CPU core, but easy to program peripherals that also likely keep the die size lower and the chip costs down.

 

Think of it more like taking a MSP430 and making the clock speed faster, adding an FPU, and giving it a 32-bit BUS. The rest remains simple and easy to learn, or migrate to.

[GrumpyOldPizza 15]

This is very interesting. We were discussing the rationale for the MSP432, and this interesting video came out from Mike Szczys, the senior editor of Hackaday. He discusses the feud between the 8-bit and 32-bit camps and after watching the video, I can get an appreciation for why TI has created the MSP432.

 

https://youtu.be/kz0yCrikZBE

 

The feeling I get is that the MSP432 fills the gap or bridges between an 8-bit device, with their simple and easy to learn peripherals, and a 32-bit design with their complex peripherals that are intimidating and confusing to a person just starting out.

 

You get the speed and benefits of a 32-bit CPU core, but easy to program peripherals that also likely keep the die size lower and the chip costs down.

 

Think of it more like taking a MSP430 and making the clock speed faster, adding an FPU, and giving it a 32-bit BUS. The rest remains simple and easy to learn, or migrate to.

 

Thanx  for sharing.Interesting presentation.

 

Though I don't buy your analysis. The peripherals on MSP432 are not any simpler than say on STM32L4 or NXP1549.

 

Actually, what's funny is that the talk brings up one of the key weaknesses of MSP432 (and the idea of simply taking crufty MSP430 peripherals). ANY other Cortex-M3/M4 controller I know has a way that I can set a group of GPIO pins on a port atomically without affecting other pins. TM4C uses some address bits to generate an update mask. STM32 has a separate SET/RESET mask, LPC chips have a set of masks that can be used (3 on LPC1549). MSP432 has only a "PxOUT". So no atomic updates  unless you get creative with bit-band addressing or use LDREX/STREX/CLREX type atomic primitives. If you are at that level, complexity would not be something that concerns you at all.

 

I do get the argument, that if you come from MSP430 it's a step up. But it's a massive step down from any other ARM Cortex-M3/M4 controller other than the very first ones from Luminary Micro in 2005, like LM3S811.

 

EDIT: It seems it's now possible to actually order the XMS432P401RIPZR variant for $6.781 (256k flash, 64k ram, no USB). The XMS means it's still not a production part. Don't know how that compares to the similar ST part (STM32L433RC), which is just hitting the distributors as well.