Walker Texas Ranter

[newbrain]

Or, rather, not-walking Texas Ranter .

Forewords
I've been stuck in a chair/sofa/bed for most of my vacation after I broke a leg trekking in the Alps (on its way to healing, thanks for asking ), so I tried to pass some time playing with the MSP432 Launchpad I bought months ago (it was too cheap to pass on the offer!) but never really tinkered with.
Of course all the following is in my opinion, possibly due to some grumpiness for my leg.

The Goal
If you read some of my posts, you'll notice I'm quite fond of VisualGDB (which supports the MSP 432 MCU out of the box), but I wanted to have some 'fun'.
In the end, I decided I would set up a development environment based on the Visual Studio Code editor: I like it as it is relatively light-weight, multi-platform (node.js based: Win/Linux/Mac), open-source, offer a decent git integration and the extension landscape seems to be quite active and growing.
I had already done the same with STM32, and it took me not much time to have it running (let's say less than a couple of days).

Preparation
Since I knew I would have a sketchy internet connection where I was headed (Sardinia), I downloaded all I thought I needed on my old laptop (Pentium T4400, 4GB, 128GB SSD, Windows 10) before leaving:

• My usual development environment (Visual Studio Community + VisualGDB) with the relevant MSP packages
• OpenOCD and arm-eabi-gcc (actually the ones provided by VisualGDB, just not to have too many copies around)
• All the up-to-date documentation for the MSP432P401R chip and the Launchpad
• The Eclipse-based Texas Instrument IDE: Code Composer Studio 6.1.3
• The TI libraries for the MSP432 (MSPware)
• Documentation for OpenOCD and gnu make
• VSCode, with my usual extensions: Python, C/C++, Powershell, Hexdump for VSCode, Native Debug (gdb support)

ARMed with these tools and fall-back environments (CCS, VSC+VGDB), I was ready to go.

Setting things up
Setting up VSCode to act as an integrated IDE might be a bit tedious, but it's not overly difficult.
The main steps are:

• Prepare a set of Makefiles and some associated (powershell) scripts: what I did was to have a common Makefile in a shared directory with the basic set up, and a template one (which includes the former and defines project specific stuff) to be copied in the project directories.
• Write a "tasks.json" file to contain the build, clean and other helper tasks, plus the regular expressions to have a nicely formatted and clickable error/warning list
• Write a "launch.json" file describing how to launch gdb(+OpenOCD in my case), for debugging and flashing the target
• Write a "c_cpp_properties.json" file to add the include paths to the almost-but-not-quite-intellisense auto complete feature

The .json files are in theory project specific and live in the .vscode project sub directory, but they are generic enough that, as the Makefile, I just need to copy them from the shared folder.
This kind of setup worked quite well with the STM32: it's possible to build a project, check errors, load the object on the target and debug it without ever leaving VSCode. The integration with gdb is not stellar, but breakpoints, watches, call stack display work with no problems, and it's still possible to use an integrated command line to talk to gdb. If you use git, all the basics are supported.


The Actual Rant
In the end I managed to have it all working, but still feel the need for venting out...
So here are my complaints with Texas, in no particular order (VSCode and most of the extensions are stil quite new, but the only thing I was not able to have working is the clang-format customization).

Code Composer Studio

• Code Composer Studio 'runs', in the same sense that glass 'flows'. As most Eclipse-based IDEs, after all. It takes aeons to install, and ages to start.
  I know that laptop is not a speed demon, but Visual Studio Community starts and load a simple VGDB project in less than 20 seconds, VSCode comes up in about 6-7 seconds (same size project). Seventy-frigging-five seconds are way too much.
  
• Once started, CCS works. Some of the time.
  I wanted to try a feature, Energy Trace, that was more or less the only one to differentiate it from the other environments I have. It starts only if you launch a debug session, but only under an as yet undiscovered set of circumstances (wind direction and moon phase not excluded). It sho uld work theoretically, in a "standalone mode", i.e. out of debug, but I never managed to make it start (no error, just spinning cursor and  nothing happens).
• MSPware in CCS. The code is crap. More below.
  Well, at least there are tons of examples. Not that you can inport them directly in CCS using the integrated browser, I always got this: "Error: Device is either 'null' or is currently not recognized by CCS.", not much help from google.
• Some of them (the labs) import correctly though, unfortunately they are written only for the TI proprietary compiler (I was using GCC), but with some tweaking, they run...
• The update mechanism is broken. It tells me I must update come component, makes agree on the licence then miserably fail to find the repositories. Is it me? Maybe, but the same happens on my fixed PCs

Ok, enough with CCS, it was not my actual goal, in the end...let's move to:

The docs
The quality is not what I expected.
ST documentation is scattered in a number of different manuals, but I don't dislike their style and descriptions and I have rarely found faults.
TI docs are also split in a datasheet, a tech ref and the driverlib manual (doxygen be cursed), this is fine.
The Technical Reference (July 2016 revision) is full of silly errors. I could not read any section without finding something that sounded wrong, imprecise, incomplete or misleading: memory maps, bit banding, number and behaviour of peripheral registers, the description of the clock chains is confusing at best...at least there's a nice link in the doc to report problems.
Of course, those were the problem I could detect but that leaves me wondering whether I'm missing something important!
The Launchpad manual contains only little information (not even a pinout of the extra IO connector...), it's mostly filled up by the pre-loaded demo description. The text in the pdf schematics is only partly searchable.

The startup files
You can find several version of them, each example carries its own, then there are the ones in the gcc package which are the best: at least, the interrupts handlers are __weak declared, and there's no need to alter them to provide your own. I ended up using those, but I wonder why they are not included in the "empty project" example code...
The register definitions changed completely at some point in time to better comply with CMSIS, but that's also ok (I prefer the current CMSIS way rather than the old one).

The driverlib
TI driverlib is the equivalent of ST HAL, or better, ST standard peripheral library.
There are a number of versions (and you have to match them with right CMSIS/startup files).
No, it's not as easy as "grab the latest", as the silicon on my Launchpad is Rev B (errata is quite a longish doc...), and the latest revisions are not compatible with it.
I discovered this seeing that some clock setup lib calls were not actually working.
In the errata there a link to a support page with info on how to live through, until support of Rev B is removed,
Once found the right version, things started to work (nah, that's a lie).
As a test program, I made a simple blinker (what else?), with PWM regulation of the intensity, that cycled through the 8 colors of the onboard RGB LED. Nothing fancy, just reading GPIOs  for buttons and changing compare registers accordingly.
I discovered a functional bug in each and every of the timer driverlib routines I tried to use.
The most common: register are ORed with new values, without cleaning them in advance.
OK, I thought, that's because I have to stay on the old revision...nope. Same bugs in the latest.
If DEBUG is defined, the ASSERT macro fails to compile, as it uses the old register definitions.
Now, I have built a number of projects with STM32s (e.g. PSU control with encoders, DAC/ADC and LCD display, HDMI CEC to USB HID adapter, LCD scope on F7 Disco etc.), and used the HAL quite extensively. Apart from some brain-dead design ideas (UART receive comes to mind), I never found any show-stopper bug (I am pretty sure there's plenty).

The driverlib examples
I already wrote about this some time a go, but shortly:
The code is sloppy, to be very kind. The clock system/systick demo tries to cram a 32bit value in the the 24bit systick register (did they ever try to run it?).
Thr eUSCI UART examples use MSB first, so if you don't notice and try modify the code to something more than an echo, you get garbage (OK, you should be careful, but still...).
The provided Makefiles (in the BSD licensed download) are written for Linux, so they need to be translated to work under Windows (just a minor point).

The Launchpad debugger
As the MSP432 LP sports a standard CMSIS-DAP debugger, I though I was good to go with OpenOCD.
Well, I cannot honestly say I does not work. It only take some 10s of seconds to do any operations.
This is barely tolerable when flashing (150bytes/s speed ), but makes stepping through a program an exercise in patience.
I do not think it's OpenOCD fault, no other debugger exhibits this behaviour (I've tried ST-link and J-Link).
Since the debugger worked from inside CCS, I decided to use the Texas proprietary debug server.
It's now working as expected, but to reach this point I had to make a nice collage of a number different versions/packages, taking the exe from one, the MSP432 flash dll from another one, and some other dll from the third. The needed configuration files were in one of those, can't remember which.
After some fiddling, it now works, flashing is reasonably fast (through gsb) and breakpoints/watch etc. go at a normal speed. There's no documentation I was able to find on the supported gdb commands, and $DEITY forbid that gdb "monitor help" command be provided! Luckily, the symbols in the exe are a giveaway.
I had to provide my own memory map: it does not seem to be able to tell gdb what the target looks like, as opposed to OpenOCD...

Final Words
Maybe it's me. I had the expectations that most of the stuff I tried should have worked out of the box or with just some minor fiddling.
I was not trying to set up a toolchain from scratch, as I had a working base. What I needed was good docs, a consistent and correct set of SW libraries/system files and a reasonable implementation of the CMSIS-DAP standard (or a documented, coherent debug server).
In the end I managed, still, I think Texas should put some more effort in it.
In talking with a friend, he suggested that FAE are paid also for helping this kind of stuff. Of course, as an hobbyist, I do not have this luxury.
But, if I were professionally asked to choose an MCU and decided to try some boards out, I'd be more inclined to select one that does not need much fighting just to blink a LED (OK, with PWM).
As I said, my experience with stuff from ST (or Atmel 8 bitters) was incredibly smoother, I am now curious to try some other vendor (NXP?) to see how it compares.
All that said and done, it was 'fun' in its way, so I'm not too disappointed.
I hope, on the other, that this was not too boring for you!
Comments welcome , if you feel the need to point out that I'm a complete doofus, please do it gently  .

TL,DR:
Lots of  , few  , some meh.

[bobaruni]

Wow, that's a lot of effort.
I always did wonder if there was something better/easier than STM32 cube, still haven't had a chance to look at Freescale Kinetis and NXP even though I have some of their dev boards laying around.
I will be playing with the LPC4370 in the next few days but my needs are very simple, just bare metal GCC.
You have put me off the MSP432 which is fine as I'm pretty happy with STM32 even though the Cube is a bit difficult to get around and datasheets are scattered around but getting used to it as time goes on.
I was spoiled by the ease and simplicity of Atmel AVR for many years and lured away by STM with their cheap and powerful Discovery / Nucleo series but very glad I made the transition, Atmel are just too expensive now although their Cortex M7 can't be beaten for clock speed (so far).

[Sal Ammoniac]

• Code Composer Studio 'runs', in the same sense that glass 'flows'. As most Eclipse-based IDEs, after all. It takes aeons to install, and ages to start.
  I know that laptop is not a speed demon, but Visual Studio Community starts and load a simple VGDB project in less than 20 seconds, VSCode comes up in about 6-7 seconds (same size project). Seventy-frigging-five seconds are way too much.

The reason for this slowness, I think, is because a vendor will take Eclipse and bolt on so many plug-ins and add-ons that it bogs down to a crawl.

I took plain vanilla Eclipse Platform Edition (this is the minimalist version of Eclipse--it doesn't have the Java development stuff and all the plug-ins that normally come with the default version), added CDT and the GNU ARM plug-in and configured it to use GCC. This will startup and load a medium-sized C project (~15000 lines of C code) in 7 seconds on my laptop. On my main development machine it will load the same project in about 2 seconds.

Let me state for the record again -- Eclipse itself is not slow. Eclipse appears to be slow in many cases due to the idiotic choices many vendors make to bundle it with every plug-in and add-on known to man. This is what makes Eclipse run slow. Eliminate all that bullshit and Eclipse runs fast!

[newbrain]

Let me state for the record again -- Eclipse itself is not slow. Eclipse appears to be slow in many cases due to the idiotic choices many vendors make to bundle it with every plug-in and add-on known to man. This is what makes Eclipse run slow. Eliminate all that bullshit and Eclipse runs fast!

Can I haz cheezeburger your machine? 
But, I tend to agree here.
I'm not very fond of Eclipse in general (windows handling, commands, projects and workspace, perspectives), but I notice that some environments are better than other (Atollic TrueStudio is not obnoxiously slow, to say one) and for sure the bare-bone one is bound to be the fastest.
I was struck by the slowness of CCS, a champion in its own category.
Where I work, for a proprietary language, the tools division created one of these Eclipse adaptations.
The common complaints were the general sluggishness and the startup time, apart the proprietary bugs.
With a good round of flensing, it become acceptable, though never snappy.

This is one reason I like VSCode: it has some potential, and at least for the time being , is still lightweight (I thought I'd never say that about something in js, I'm getting softer with age...) and one can select only the extensions that are needed.