[sdiy] STM and TruStudio

sleepy_dog at gmx.de sleepy_dog at gmx.de
Tue Feb 13 14:57:32 CET 2018

Ben Bradley said:
> In a related question, how do people feel about different Arm Cortex M
> development tools? What's your favorite and least favorite?

Never tried IAR.

I used Keil in 2011 or so.
The peripheral register overviews etc were nice compared to some more 
spartan toolchains.
But it felt like from 1990 in usability & non-adherence to UI / Editor 
navigation standards (for windows software) - which is bad if it's not 
just default behavior but is not customizable - which it wasn't, like 
straight outta 1990 ;)
It did, IIRC, stupid stuff like put meta info (like IDE settings) into 
the frickin project file - really cool if > 1 dev is supposed to work 
with that.
And, also IIRC, did not support RTOS-aware debugging features, so 
debugging related to that was cumbersome.
One of the most annoying things probably was this floating license 
server thing . . .
I don't remember whether you had to use their Keil debugging probes, but 
if so, that's another annoyance. I think they (ulink2?) were nothing 
special, but they want 10x the price of similar probes. I mean, Segger 
can ask some $$$ for a probe with on-board GDB server and ethernet 
connection instead USB, increasing the speed for some operations 
greatly, and support for some advanced tracing features e.g. stm32 
suports (forgot the name). But 300 EUR for an oversized stlink like 
probe (jtag-only) seems a bit much.

Rowley Crossworks for ARM. Personal non-commercial License ~ 150 USD.
It supports WIndows, Linux, Mac.
I also tried it when their editor was in the stoneage, and later when 
they somewhat improved it, but it still was buggy and doing some things 
rather weirdly.
It did some nice things like show you code size of modules in a nice 
overview, and how much RAM you were using where, also periph register 
views etc.
Their editor is NOT eclipse based, it's completey their own product. 
With it's own ideosyncrasies - but when I was using it, it never gave 
the Eclipse sluggishness.
I would guess that by now, it could have gotten pretty good, but didn't 
use it in the past 2 years or so.
They offer their own funny HW abstraction lib, and own RTOS. I don't 
know if it's any good, but I wonder why they bother. If it's legally 
connected to their product, it would seem foolish to use it. Then rather 
get a license for ChibiOS or something (if for free for non-commercial).

There are a host of Eclipse based IDEs (often win/linux/mac)). Atollic 
TrueSTUDIO is one of them.
Now, Eclipse is a powerful and versatile thing, but it's also a mess and 
tends to make you wait a little (maybe not on a current machine, IDK).
Much of its default behavior is annoying to a lot of people who may be 
turned off quickly - but you can customize it a lot.
Some makers of Eclipse-based products manage to tame the mess to some 
degree ;-)

TrueSTUDIO pro has a lot of nice features like RTOS-aware debugging, 
named periph register view,  performance profiling, detailed memory 
usage view, real-time data tracing, help with hard faults, code quality 
& other metrics to help decrease the chance of bugs. (for the latter, 
maybe just using eclipse CDT optional plugins would have worked as well, 
but if the whole package is for free now...)
Some very useful features. And that now for free. I do think I will look 
at that, but I don't like it being ST-only now, even though I use ST 
almost always, for their peripherals (and the fact of most familiarity / 
limited time)

VisualGDB plugin for Visual studio (which btw., works on Mac now, not 
windows only anymore)
I tried that for a while. It's inexpensive (if you only get the 
"embedded" option), and students pay 1/2 or so (and there are free to 
use versions of VS).
It seemed nice because I already use VS for high level stuff and 
generally like the feel, usability, and the unmatched debugging features 
esp. for the .NET platform languages.
And although it is not a small software, it's still not as sluggish as 
Eclipse can be, hah! (okay, VS2017 on my 10 y/o laptop can make you wait 
some seconds sometimes)
There is one thing I wondered: VS didn't really care for the C (as 
opposed to C++) language for many years and it shows - what was VGDB to 
do about that?
Well, they use the syntax highlighting & autocomplete / hinting engine 
of clang, instead VS'es own "Intellisense" for that - if you leave it 
This seemed to work well, mostly. But I remember one day where the 
highlighting was off by a few lines, haha. Probably fixed by now.
IIRC VGDB also has named peripheral register views and all that, and as 
the name suggests, lets you debug embeddd targets in VS via GDB, and 
ST-link, Segger and I think some other probes.

EmBitz: (free)
There is the somewhat peculiar Code::Blocks branch called "EmBitz" 
tailored for Cortex M and a few other platforms, with project wizards 
for ARM Cortex M, msp430, PIC, AVR.
It seems quite usable (hey, code::blocks), but it deviates so much code 
wise that new features of Code::Blocks cannot be merged back into it, 
which is a real bummer.
It's, I think, a one-man hobby show, there's always some risk to that in 
some regards.
It has peripheral register views, including all the field/flag names 
within registers etc.
Apparently, current version is OS-aware out of the box. Nice.

All those IDEs and plugins come with wizards to help you set up things 
quickly for a certain MCU.
That can save quite some time compared to dig for all the info yourself 
& write all the scripts for it.
Some people like to have that control, but if the tools do it well 
enough, I personally am glad to offload such busywork to spend my time 
on the actual stuff.
(well, some of the IDEs let you control everything and use makefiles & 
give access to linker script etc. I think that's the nicest variant - 
have the IDE take care when you don't care, and be able to alter the 
details when you do)

Of course, you could always go the more spartan route, using an editor* 
of your liking, GCC ARM toolchain, GDB, openocd (or texane?) and some 
scripts (maybe that the editor can run with some key combo) to compile & 
flash, and use GDB manually to debug.
But from what it sounded like, this would not be your cup of tea I 
guess. It's not really mine either. I don't particularly enjoy visually 
combing through ASCII-barf all day compared to having views of constant, 
reliable layout with reliable visual cues, for instantly knowing what's 
going on (vs. poking & asking), utilizing some evolutionary 
optimizations of our visual system for tracking and instant-zero-in on 
stuff. That's not to say that having a look under the hood wasn't a good 
idea. Knowing what's going on is good.
Ok ok, enough digression ;)

* or somewhat less spartan: Eclipse CDT or Code::Blocks (which runs a 
lot more smoothly than Eclipse)
Some setup work required compared to the ready-to-eat solutions. There 
is at leats one Eclipse CDT plugin making setup of the debugger stuff 
easier, I forgot the exact name, but when you search for "eclipse cdt 
arm embedded plugin" you'll probably find it.

As to "my favorite": ( your actual question ;) )
I don't have a strong favorite, but I won't use Keil again, but it does 
work pretty reliably from what I remember - although your experience 
seems to differ.
I guess for my small hobby projects EmBitz and VisualGDB+VS2013 have 
been working well enough.
The Atollic TrueStudio now being free could change what I'll be using 
because of things like built-in source level performance profiling. If 
there's nothing that will put me off big time anyway. I'm slightly 
afraid there may be ;)

> years ago I was using Keil's free 32k-code-limited version for the
> STM32 boards, but I was often frustrated due to something 'breaking'
> and getting an error message that I didn't understand where it was
> coming from. I sometimes found help and fixes from online forums, but
> it was time consuming and sure felt unproductive.
What kind of errors, when? Stuff like gone bad debugger connections?

- Steve

> On Mon, Feb 12, 2018 at 11:23 PM, Ben Bradley <ben.pi.bradley at gmail.com> wrote:
>> Renesas has recently (a few years ago) started selling Arm Cortex M
>> chips, and as I heard at a recent seminar on these, you can download a
>> free, fully functioning IAR dev system that's solely for the  Renesas
>> chips.
>> I suppose you could redo a bunch of the support code for another
>> maker's ARM Cortex M chips, but 1. that would be a lot of work, and 2.
>> it goes totally against the license for these things.
>> I've written a series of equates for various registers and I/O ports
>> for smaller parts (68HC11) before writing much of the "real" code
>> because I saw where I had a need for it, but that was almost 30 years
>> ago when software (assembler!) vendors didn't always include such
>> things. These Cortex M things are one or two orders of magnitude
>> bigger as far as the number of peripherals and number of I/O registers
>> per peripheral.
>> https://www.electronicsweekly.com/news/renesas-offers-cortex-m4-mcus-with-synergy-rtos-and-stacks-2015-10/
>> On Mon, Feb 12, 2018 at 8:00 PM,  <sleepy_dog at gmx.de> wrote:
>>> Ha! Interesting move.
>>> https://atollic.com/truestudio/
>>> Indeed, ST logo everywhere.
>>> i wonder whether they'll be fiddling with it so it will be harder to use
>>> other implementors' Cortex M chips. Why would they provide a well polished
>>> tool chain to enable you to use the competition's products...
>>> That would make a lot of people rather unhappy.
>>> - Steve
>>> Am 13.02.2018 um 00:02 schrieb Neil Johnson:
>>>> Hi all,
>>>> Not sure if this is widely known, but late last year STM finally
>>>> bought out Atollic, and now the previously paid-for Pro version of
>>>> their Eclipse-based software development system is now FREE for the
>>>> STM32 platform.
>>>> This is actually quite awesome news if you have any interest in
>>>> programming embedded micros.
>>>> Neil
>>> _______________________________________________
>>> Synth-diy mailing list
>>> Synth-diy at synth-diy.org
>>> http://synth-diy.org/mailman/listinfo/synth-diy
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy

More information about the Synth-diy mailing list