Anyone had any real experience with the MSP430 TI libraries?

[trevwhite]

I have been considering the MSP430 series and have actually purchased some dev boards in preparation to spend some time getting to know them better. Does anyone have any real experience using the MSP430 TI libraries and able to offer any information on how good/bad they are?

Do they work okay? Any problems ? Any gotchas ? Are they actually useful?

Just a note, this thread is specifically about the TI libraries and not about comparing them to other MCUs or libraries. I am just looking for information on TI stuff thanks.

Trev

[Molenaar]

I have experience with MSP430 code generated by GRACE and it was very nice. Much more readable and simple code compared to the dribble CubeMX produces.

Just make sure you understand the way low power modes are configured, that's slightly different from the usual.

[trevwhite]

Thanks for the info. I am working through tutorials and the support from TI seems really good so far.

[nickds1]

Late to the party on this - a few years ago, the driverlib libraries in MSPware were a bit rough for various reasons...

Recently (a few months ago) I got back into the MSP world with the newer FRAM Launchpads and also the MSP432 (32-bit) offering.

Driverlib has improved a lot, as has CCS - support via the e2e forums is excellent and I really quite like the driverlib code now - its pretty lightweight, they've rationalised the API naming scheme, it's very functional - I much prefer it over using register-based coding with magic bitfields etc. Also makes it easier when switching devices as a lot of the changes take place "under the hood" so less for you to worry about.

Go for it!

[^_^]

Driverlib has improved a lot, as has CCS - support via the e2e forums is excellent and I really quite like the driverlib code now - its pretty lightweight, they've rationalised the API naming scheme, it's very functional - I much prefer it over using register-based coding with magic bitfields etc. Also makes it easier when switching devices as a lot of the changes take place "under the hood" so less for you to worry about.

Last time i checked @MSP430 all the code had those defines for registers and it just looked  horrible.
STM was the first i know that had put the proper effort for the HAL library and proper API.
Anyway I'd still go for registers if you need to do something fancy and be sure what is done in the code ;-)

[suicidaleggroll]

Anyway I'd still go for registers if you need to do something fancy and be sure what is done in the code ;-)

I agree, and is what I do with my MSP43x designs.  However, driverlib is open source, so even if you don't use it directly it can still be used as a nice reference for how to configure the necessary registers to get a job done (proper order, etc).

[timb]

Anyway I'd still go for registers if you need to do something fancy and be sure what is done in the code ;-)

I agree, and is what I do with my MSP43x designs.  However, driverlib is open source, so even if you don't use it directly it can still be used as a nice reference for how to configure the necessary registers to get a job done (proper order, etc).

The DriverLib code is all pretty sane (as of a year ago, at least). I haven't had any big issues with it and it's worked better than most other manufacturer's HAL code!

The other huge advantage is that for a lot of parts, DriverLib is actually in ROM, which can be a significant space saver! (They even have it so you can easily override the ROM version of a particular function with a newer local version if needed, which is nice. It all happens at compile time and "just works" in my experience.)