Integrated Development Environments, that is.
Not a fan.
I'm still trying to evaluate such things for a client project and for future use. Main requirement, really, is a working debugger; all else could be handled just fine with the GNU toolchain and a Makefile. I'm not about to use straight-up arm-whatever-gdb, on account of that having an exceedingly steep learning curve for a tool that I'll be using infrequently (and thus having to re-learn every time I need it).
I've tried Eclipse-based things a few times over the past many years, and never gotten anywhere. With most of the not-totally-proprietary IDEs (and, in particular, Freescale's Kinetis Design Studio) being based on Eclipse nowadays, I guess I need to learn it now.
Well... the latest Eclipse, from the official source, won't even think about running on current Debian-stable, so I'd installed it in a Linux Mint VM, and not gotten very far with it.
Now there's this Armstrap project, which has its own Eclipse + ARM toolchain bundle, which does run on my workstation, and comes with... maybe?... most? of what one needs. (It's for 64-bit Linux host systems, though, so it won't run on my lab machine, but neither will the 32-bit down-rev Eclipse in Debian-stable, which bombs almost immediately with an out-of-cheese error.)
So I try to set up one of the sample projects... and there's a huge amount of per-configuration-per-project stuff that needs to be filled in manually (well, cut & pasted from an example somebody else has already done and posted on line). This basically means that the approach to using it will be to create a project that's configured for one target, and then copy and modify it for subsequent projects. The whole project-creation process is wildly cumbersome, and importation doesn't appear to work the way one would expect.
Seems to be another case of a grandly general-purpose does-everything tool that's epically inconvenient for actually doing any one specific thing... and that, while the learning curve for any given aspect may be nominally easy (because GUI!), the overall learning path for being able to useful stuff with it is very long indeed.
Oh, and I seem to have missed something-or-other in setting up the example project. The compiler can't find a definition for some #define symbols from a header file. The header file is definitely #included, and there's no error for a missing include file, but several symbols from that file are coming up undefined. (Yeah, I have seen much earlier versions of GCC fail to complain about missing files, but I don't know if that's what's going on here.) Maybe I need to put a syntax error in the header file and see what happens.*
Playing around with (better-integrated) KDS for a while first might make more sense, except that the Kinetis stuff is for pet projects later on, while the ARM-Eclipse-in-general (well, for an STM32 target) is needed kind of now-ish.
* Update: Did that. Adding a #foobar directive right after the #define for one of the "could not be resolved" symbols gets an error message for the invalid directive... and then the same error messages about undefined symbols (or symbols that cannot be resolved, which I assume means not-defined). So... um...?
Update 2: Ah. For STM32xxx parts, at least, the trick is to install this Eclipse goodie. That (a) seems to fix the build for that laboriously configured sample project, and (b) adds nice new options for creating a project preconfigured for one of the STM32 parts. Also, (c) it adds nice options within the project settings for configuring the processor type and so on. So maybe this will be useful after all. Still have to demonstrate debugging some code via ST-LINK/V2, and figure out how to import a project from a proprietary IDE. And then figure out how to shift the code base address, because the final application will involve a bootloader and won't be running at nominal zero (fiddly detail).
Recent Comments