[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
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
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
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
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
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 /
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.
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
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?
> 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
>> 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.
>> On Mon, Feb 12, 2018 at 8:00 PM, <sleepy_dog at gmx.de> wrote:
>>> Ha! Interesting move.
>>> 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.
>>> Synth-diy mailing list
>>> Synth-diy at synth-diy.org
> Synth-diy mailing list
> Synth-diy at synth-diy.org
More information about the Synth-diy