emIDE for ARM Cortex-M dev - any thoughts? (or free alternatives to ARM Keil) - Page 1
Forum section: electronics / general

author: Saimoun
author_rank: Frequent Contributor
timestamp: October 21, 2021, 12:14:25 pm
content: HiApologies if the subject has been covered - I did search but only found old posts and I am sure this open source IDE has grown a lot for the past few years.I have been using Keil for now but kinda forgot that my license is non commercial, limited to 32kB, and even the cheapest license costs an arm (pun INTENDED).My biggest concern regarding moving to a GCC-based environment are the lack of debugging feature and the compiler's ability to optimize (in particular reduce the image size).But looking at emIDEhttp://www.emide.org/documentation_debugging.htmlit looks like it has all debugging feature that I would need: core registers, peripheral registers, memory. ASM code view is not mentioned though but since it has "next assembly instruction" step I guess it is there.Then I have heard that the ARMclang compiler generates better optimized code than GCC... not sure what that entails?So... emIDE, what are your thoughts?Thank you - this forum is always such a big helpSimonPS: I'm using a GD32E230 ARM Cortex-M23.

author: jeremy
author_rank: Super Contributor
timestamp: October 21, 2021, 01:00:27 pm
content: Not open source, but I write and compile with a text editor, then debug using SEGGER Ozone. It has all of the features you listed and many more, plus it is much more lightweight than full IDEs so it is much faster. For non commercial usage, you just need a JLink EDU which is something like $30 USD?Edit: sorry, I do use GCC. I’ve never really had a problem with “-Os” though, and the GCC compiler is developed by ARM themselves (Linaro I think)

author: Saimoun
author_rank: Frequent Contributor
timestamp: October 21, 2021, 01:10:34 pm
content: That would work great but actually I do need commercial usage. I did check the J-Link base which is still way cheaper than the ARM Keil license.

author: jeremy
author_rank: Super Contributor
timestamp: October 21, 2021, 01:13:16 pm
content: Honestly if you are commercial I think it’s worth investing in a JLink. It stings at first, but particularly SEGGER Ozone and RTT have been in my workflow for many years now and I don’t know what I would do without them.

author: voltsandjolts
author_rank: Unknown
timestamp: October 21, 2021, 01:33:11 pm
content: If you are using an eval board, it might be supported byJ-Link on-boardCaution: this might hook you into buying a J-Link

author: fchk
author_rank: Frequent Contributor
timestamp: October 21, 2021, 02:36:18 pm
content: Suggestion:0. Any amd64 Linux system1. VSCode (https://code.visualstudio.com/download)2. Cortex-M Addin (https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug)3. C/C++ Addin (https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools)4. OpenOCD (most likely included in your distribution)5. gcc for armv7 (most likely included in your distribution)Any JTAG adapter suitable for OpenOCD. (https://openocd.org/doc/html/Debug-Adapter-Configuration.html#Debug-Adapter-Configuration)FTDI ft2232 based adapters tend to be quite cheap.The whole package gives you zero licensing costs and maximal freedom.GCC for ARM is very good and mature - no need to worry. There is even a version officially provided by ARM itself:https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloadsA cheap JTAG probe is here:https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/plus the adapter for the now-standard 10 pin connector:https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-20-10/No problems with OpenOCD. OpenOCD even has a config file for this.fchk

author: lucazader
author_rank: Regular Contributor
timestamp: October 21, 2021, 07:54:14 pm
content: I Second the setup by fchk.We use a similar setup at work and have done for quite a few years now.We use:Official arm-none-eabi-gcc (currently 10).Makefiles or CMake for build system.VSCode (or any other good editor of choice since the build system is not coupled to the editor)Cortex-debug extension + openocd for debuggingSTLink v3's for debug (we use STM chips, so swap this for the debugger of your choice)As a side note:A lot of modern editors will automatically give you nice code browsing if you provide a compile_commands.json file.CMake and some other build systems auto generate these, however good old make does not.I have been using the tool `compiledb` for some time now and it works great to generate a compile_commands.json file for your makefile projects.Install with `pip install compiledb`, and run with `compiledb make <target>`

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 21, 2021, 08:31:34 pm
content: Regarding the GCC-produced code size - a correctly tweaked fresh GCC 10 (from ARM’s site mentioned above) produces a more compact code than armclang in my case. Just don’t use the ancient Linaro GCC 4 (included in some IDEs and Linux distros by default), use -Os -flto switches, drop all WEAK symbols from vendor-provided startup (WEAK hinders LTO for some reason) and gcc will do a great job.

author: newbrain
author_rank: Super Contributor
timestamp: October 21, 2021, 08:58:38 pm
content: Another vote for VS Code plus the mentioned extensions.If you are really paranoid or a Microsoft hater, the completely MIT licensed build of VS Code (VS Codium) is a possibility - keep in mind that some extension might not be avaialble (but there are ways around it).Cmake and ninja make for ultra fast builds (compared to makefiles), and the Cmake VS Code extension is quite helpful.Instead of OpenOCD, you might also trypyocd(sponsored by ARM) - it works with minimal setup (just pass the target MCU name) for a very large number of MCUs, while I always find OpenOCD configuration a bit daunting.All the usual debuggers are supported: J-Link, ST-Link, CMSIS-DAP/DAPlink and others (e.g. picoprobe that I contributed).There's support for some common RTOS, too.For hobbyists I sometimes suggest to try Visual Studio (non code) plusVisualGDB, but the cost for a VS licence in a professional environment can be quite high, unless one develops open source code and can use the free community version.An alternative compiler is LLVM/clang (the base for armclang), it produces very good code and comes with an outstanding static code analysis tool (plus formatting, but VSC already includes a clang-format binary).

author: westfw
author_rank: Super Contributor
timestamp: October 22, 2021, 01:41:19 am
content: Quotegcc produces lots of debugging info, readable by many IDE-based debuggers other than gdb. And gdb has some advantages, too.QuoteWhile there are persistent rumors that ARM gcc produces "worse code" then full-priced commercial compilers (like Keil), it's still quite good. Good enough that most of the time you can look at the object code and not see a way to make it better. (well, for ARMv7m (CM3, CM4), anyway. There might be some more obvious issues with ARMv6m (CM0, CM0+))

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 22, 2021, 01:47:57 am
content: Quote from: westfw on October 22, 2021, 01:41:19 amYep. Agreed. Never seen an incentive to use anything else than GCC for ARM Cortex dev here. But you're right, CM0/+ generated code seems consistently suboptimal. I've been working with RISC-V quite a bit for the past few months, and I was surprised to notice that GCC's produced code for RISC-V was on average significantly better than for Cortex M0/+. Of course the ISAs are different and that's part of why, but still. But with that said, GCC is still perfectly usable on those.

author: westfw
author_rank: Super Contributor
timestamp: October 22, 2021, 04:43:23 am
content: QuoteFor one thing, there doesn't seem to be an optimized collection of floating point functions for m0, which means that the compiler falls back to using the "generic" floating point code written in C, which is rather bloaty and slow.And then I just came across this:Code:for(int i=0; i<9000000; i++){} //Run a few cycles doing nothing2: 3b01 subs r3, #14: 2b00 cmp r3, #06: d1fc bne.n 2 <main+0x2>Notwithstanding "why didn't it eliminate the loop entirely, like it usually does", there is also "why does it think that CMP instruction is needed? (it doesn't include it for CM3/4)

author: nctnico
author_rank: Super Contributor
timestamp: October 22, 2021, 08:11:29 am
content: Quote from: westfw on October 22, 2021, 01:41:19 amLast time I checked Keil's compiler was way worse compared to GCC. The problem is that if you buy a compiler you are not allowed to publish a comparison against other compilers. It is more likely the difference isn't in the compiler but in the C libraries. The C libraries that come with GCC aren't really minimalistic. A long time ago I have ported the minimalistic C libraries that come with MSP430 GCC to ARM and used those ever since. The difference is over 4kB less compared to using Nano-libc that comes with standard GCC for a relatively simple project.

author: cgroen
author_rank: Unknown
timestamp: October 22, 2021, 08:56:04 am
content: Quote from: nctnico on October 22, 2021, 08:11:29 amWhen was "last time" ?

author: Saimoun
author_rank: Frequent Contributor
timestamp: October 22, 2021, 10:08:31 am
content: Thank you so much everybody - this is really great info!!!I have been using VSCode for a while, but only to write code (before I used Notepad++). So I actually really like the idea of integrating everything in there with make and gcc.And I have no idea you could even run a whole debugger in there - this thing is powerfulRegarding the GCC vs ARMclang stuff, I am actually using an M-23 (ARMv8-M), which has the same instructions as an M0+ and a divider instruction.But I guess it is ok I like to go through the compiled assembly and optimizing anyways, it has become an OCD nowAnd also I have been struggling to get decent ASM listings from ARMclang and found out I cannot do without the full paid version anyways.My last concern is finding a suitable hardware to debug the MCU (GD32). The MCU does not have JTAG so I need an SWD one. I was thinking using STLink but I am not sure if it works with GDB or OpenOCD?And changing the STLink into a J-Link is also not possible for commercial applications.@fchk: I'll check the ones you sent.Any ideas of an SWD debugger "link" hardware that works with GDB or OpenOCD? J-Link is definitely an option, just a bit pricey

author: jeremy
author_rank: Super Contributor
timestamp: October 22, 2021, 10:13:50 am
content: I haven’t used one, but I’ve been keeping this one in mind:https://github.com/blacksphere/blackmagic/wiki#supported-targetsUnsure about gigadevice support. What do they use on their dev kits?

author: HwAoRrDk
author_rank: Super Contributor
timestamp: October 22, 2021, 10:22:11 am
content: I've got nothing to add regarding ARM development, but I thought I might say that emIDE looks an awful lot like a fork of theCode::BlocksIDE, which supports all sorts of compilers, platforms and frameworks.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 22, 2021, 11:02:29 am
content: Quote from: simonlasnier on October 21, 2021, 12:14:25 pmARMCC does compile C slightly more compact and faster code in some situations. C++ i do not know.However, this shouldn't be a real concern. You basically only care about this when you need to match specific certifications that some compilers have.If speed it the main concert when picking compilers your chip is too slow or your project abstractions too big.ARM isn't that challenging to do assembler for as older architectures....The thing that is much better is armlink, the linker. But you can make do with the gnu linker if you put some effort in it and do some things externally.Also, Keil's debugger is the main selling point, that just is much easier in use than gdb. Probably also faster overall since it doesn't rely on many separate program.I evaluated emIDE a long while ago and found it really simplistic. Which can be an advantage for some users!If it integrates as well with jlinks for debugging as keil, I would definitely use it for smaller projects.But today you can easily whip up a toolchain with various free tools and build systems, vscode is one of them already mentioned above.STM32CubeIDE is an example of an eclipse based one that is acceptable for ST chipsif you can allow yourself to work with the eclipse build system.

author: fchk
author_rank: Frequent Contributor
timestamp: October 22, 2021, 11:22:03 am
content: Quote from: simonlasnier on October 22, 2021, 10:08:31 amEvery probe from an MCU manufacturer only supports the manufacturer's own controllers. This is true for the TI XDS..., the STLinks, the Atmel ICE, and others. So just don't buy anything manufacturer-specific. Even no STLink, since your GD chip is not one of the almost 100% STM32F103 clones.OpenOCD does support SWD with FT2232. You need to connect GND, VCC/VTarget, and Reset. Connect FTDI TCK to SWCLK. Connect FTDI TDO to target SWDIO. Connect TDI TDI to target SWDIO via 470R resistor.Look here:https://www.allaboutcircuits.com/technical-articles/getting-started-with-openocd-using-ft2232h-adapter-for-swd-debugging/The Olimex probe can be used with this adapterhttps://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-SWD/which has a more advanced version of the simple hack shown above using gates.fchkPS: This would also work for you:https://www.adafruit.com/product/2764CMSIS-DAP is a standard for USB ARM Debug probes. OpenOCD also supports DAP.

author: DavidAlfa
author_rank: Super Contributor
timestamp: October 22, 2021, 12:45:46 pm
content: Coding on notepad? Omg... Once you get used to Eclipse realtime syntax formatting and error detection, the auto complete functions, and other useful shortcuts like go to declaration... It makes life so much easier!That's why I'm sticking do stm32cubeide.It's a resource hog, but it's getting better every day.Btw, is there something like that to develop ex. a C program in Linux, where you can also visually debug it, that also outputs the errors where you can simply click to go to the file and line, instead manually running make, checking the errors, search them using gedit... It's so extremely unefficient!

author: langwadt
author_rank: Super Contributor
timestamp: October 22, 2021, 01:14:04 pm
content: Quote from: DavidAlfa on October 22, 2021, 12:45:46 pmcube also runs on linux and since it is eclipse you can also use it for "regular" C programs

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 22, 2021, 02:01:43 pm
content: Quote from: fchk on October 22, 2021, 11:22:03 amST-Link works i.e. with Nordic nRFs happily when used from OpenOCD.

author: nctnico
author_rank: Super Contributor
timestamp: October 22, 2021, 02:43:50 pm
content: Quote from: cgroen on October 22, 2021, 08:56:04 amOver a decade ago. Keil used to have a page on their website touting their own ARM compiler is better compared to GCC. This was true when all optimisations in GCC where turned off. After some complaints and realising engineers don't fall for marketing wank, Keil took that page down. AFAIK Keil is owned by ARM nowadays so likely the Keil development tools come with ARM's own compiler.

author: Harjit
author_rank: Regular Contributor
timestamp: October 23, 2021, 06:51:46 pm
content: Arm switched to using CLANG with their own customization.For non-commercial development Segger's Embedded Studio is a great development environment. I've used it for years. This requires the use of a JLINK device.It is based on Crossworks for Arm. I have a personal license to it. This one works with many different debuggers.

author: cstratton
author_rank: Regular Contributor
timestamp: October 24, 2021, 04:20:17 pm
content: Quote from: fchk on October 22, 2021, 11:22:03 amThat's not entirely true. While not an advertised feature, a lot actually works cross-brand.STLink is a "high level adapter" that builds a bit more assumption about how things should work into the adapter, so for example, it probably won't work with a PSoC. But it will work with a GD32, and it's a very popular solution Nordic's nRF series. More recent STLink implementations also have an alternate CMSIS-DAP low level mode (or a mode that was already there became recently known?)CMSIS-DAP does have an issue that it makes very inefficient use of USB. As such a CMSIS-DAP built with a USB full speed MCU is a bit slow for projects of moderate to large size. Atmel's version used the AVR32 processor to do it at USB high speed, giving much better performance. Interesting I had a project with both a SAMD and an STM32F4 in it (don't ask, I inherited it, the intent was to use an AT command firmware on the STM32F4 but that turned out to be broken) and found that the Atmel-ICE could program the STM32 fine. But it didn't work for folks at a different worksite. Finally on a visit I tried theirs with my laptop, and indeed, it could not program STM32's even though mine could. I think it had a different firmware version.Blackmagic is supposed to be pretty good, and can be reflashed onto a lot of STLink hardware

author: cstratton
author_rank: Regular Contributor
timestamp: October 24, 2021, 04:28:38 pm
content: Quote from: westfw on October 22, 2021, 01:41:19 amTraditionally what a lot were actually doing was being a GUI front end for a gdb process they were running behind the scenes, which then talked to a gdbserver that back ended to the debuger.Maybe some now implement it themselves?I find I need to do breakpoint debugging relatively infrequently, and have just gotten to the point where I do it from the gdb command line. One thing that's handy about that is that it works fine with a double ssh connection to a pi that's babysitting an embedded board used for extended testing of sensor node firmware. In theory I could tunnel the gdbserver protocol back and run gdb with a GUI front end on the machine I'm sitting at, typically for my code it's the serial output log that's more interesting, and if I a really need gdb it's more to go in on a rare occasion and figure out where exactly something's getting stuck between the expected output messages.The gdb command line also has some interesting automation possibilities, with the ability to run commands when hitting a breakpoint then resume. I was able to use that to build a sort of pre-watchdog to catch a buggy embedded network situation on the way to failure, before it had eaten its state to the point where there was nothing left to analyze.

author: Saimoun
author_rank: Frequent Contributor
timestamp: October 25, 2021, 05:04:36 pm
content: So I got the board this morning. I soldered it, and upload a test firmware with Keil: boom everything works - it's so easy. To debug, I press "debug" and I have everything I need.Then I spent many, many, many hours wrapping my head around the gcc/make/openocd nightmare...I am quite frustrated to spend so much time getting my environment running while I should be spending on writing the codeI guess that explains the price of Keil - you pay for simplicity.Anyways - sorry for the rant - I do want to give gcc a go. On the plus side:* I've got a Makefile and an LD script that compiles and links without error* I managed to get very good ASM listings from GCC (which I could not get with the free version of Keil)* I can see in the listings and the ELF that everything is how and where it should beMy biggest problem is still the debugging/uploading - I have a blue pill that I can convert to a Black Magic Probe.How do you use the BMP with OpenOCD and Visual Code afterwards?Nevermind the BMP is 128k and the blue pill is 64k - so no go.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 25, 2021, 05:48:25 pm
content: Quote from: simonlasnier on October 25, 2021, 05:04:36 pmPeople are also always trying to cheap out on buying programmers."No way I'm paying $$$ for that genuine brand programmer, I can get a clone for $!"And then proceed to waste hours on troubleshooting their clone programmer not working right....

author: westfw
author_rank: Super Contributor
timestamp: October 26, 2021, 05:54:33 am
content: QuoteReally? What's better about the Keil "armlink"? It had pretty much never occurred to me that there was much room for "better" in a linker...

author: Jeroen3
author_rank: Super Contributor
timestamp: October 29, 2021, 07:13:50 pm
content: Quote from: westfw on October 26, 2021, 05:54:33 amGNU link is really simple. It does, first-fit or give up, on the wildcards eg: *(.data). armlink is a bit smarter with this. Which means you don't have to go around manually linking your objects into parts of memory if you have more than one region.

author: cstratton
author_rank: Regular Contributor
timestamp: November 02, 2021, 02:14:14 am
content: Quote from: Jeroen3 on October 25, 2021, 05:48:25 pmI find the opposite.It's the rare paid for tools that don't work, and can't be fixed.And then I'm really ticked.With open stuff, it's just a matter of understanding the actual issue, and then dealing with it once, and then it's fixed for everyone in the team (and our little build server, and pi-based test rigs, too).

author: fchk
author_rank: Frequent Contributor
timestamp: November 02, 2021, 12:20:02 pm
content: Quote from: simonlasnier on October 25, 2021, 05:04:36 pmAn FT2232 breakout board with OpenOCD and the resistor SWD hack doesn't work?fchk

author: jeremy0
author_rank: Contributor
timestamp: November 06, 2021, 12:25:26 pm
content: Like others, I'm using VSCode and the Cortex-Debug plugin with a Segger EDU probe, and building via a makefile with the Makefile Tools extension. (Running on Windows 10.)It works well, although the VSCode debugging functionality sometimes leaves a bit to be desired - at which point I jump into Segger Ozone, which has a more comprehensive UI, especially with regard to assembler-level debugging and memory inspection. As well as this specific shortcoming, VSCode in general has some weird quirks (including the way some things are done asynchronously under the hood) but both it and the specific extensions are continually improving.I started out using GCC (GNU ARM Embedded Toolchain), and while the generated code seems quite reasonable I found that the DWARF debug output can sometimes be ridiculously limited - entire function bodies where you can't place source-level breakpoints because of the way the DWARF info is structured.So I've recently switched to using Clang /LLVM. As well as producing better debug output than GCC, the compiler seems to produce slightly more compact code for the same settings. I haven't done any in-depth performance comparison.Note that while LLVM supports Arm/Cortex, it doesn't come with target libs & headers, so I continue to use those that come with GCC (with zero problems).Clang tends to be more rigorous with regard to warnings and undefined behaviour (UB) - which is a double-edged sword, because it's less forgiving with code that worked fine with GCC (even at full optimisation). Two specific examples: inline assembler needs to be _very_ precise with constraint declarations (especially clobbers); and code that relies on unsigned integer wrapping and signed/unsigned conversion needs to be carefully written to avoid UB. As I say, GCC is more forgiving (i.e. generates code that does what I want, even if it's straying near UB), but that Clang identified these risky areas and forced me to think more clearly about avoiding UB can only be a good thing.

author: Saimoun
author_rank: Frequent Contributor
timestamp: January 03, 2022, 12:17:43 pm
content: Hi all - Happy New YearApologies for digging an old thread, I just thought I would give an update.I actually just got motivated by my brother to move (from Windows) to Mac, and ironically that forced by to buy a J-Link probe. They are pricey but GOSH it's so much better!Until now I was using a CMSIS-DAP from a blue pill I had, and debugging with uVision. And compiling with a makefile and gcc.Well Visual Studio Code made the transfer to Mac very easy since I could just keep using it, so thank you Microsoft for discovering there were other platforms than Windows (it did take like 50 years but well at least we're here!).And all the gcc tools & like just run much better and faster on a Unix system than a Windows one (i have nothing against Windows, been using it for years, but GCC literally has GNU in the name, so clearly it was made for Unix/Linux at the start). Same for the git tools which I also use directly in Visual Studio Code.BUT the biggest takeaway is the Segger Tools! I'm happy I did not decide to go for a full license on uVision, which:* cost a lot more than a J-Link probe* only runs on Windows* IMO not very good, it bugged quite regularly, the interface is confusing (there are literally some Cortex-M Core registers I could not find), and quite often when I pressed "next" instruction in the debugger it decided to do "continue" - no idea whyIn any case, using now Ozone from Segger which is amazing!!* Soooo much faster* Runs super smoothly* And on Linux/Mac/Windows* Has not bugged so far* Everything is super clear, you can even just "unroll" a C instruction to see the disassembly* And I can now see all the Core registers! Yay* And unlimited breakpoints - I did not think that would matter but I remember how often uVision told me "oh there are no more breakpoints" (I think the limit is 4 or 5), then you need to remove the old ones and falala it's just more faffing aboutJust one small hic on the way: I only have a 3 pin SWDIO, SWCLK, GND connector, and with the J-Link you also need to connect their "VTref" pin to the VDD of your MCU otherwise the probe will not connect.So the moral of the story is: if your MCU manufacturer has tools (like STM32 f.x.), then great lucky you. Otherwise if like me you're using a manufacturer that does not really provide tools or software (I am using a GD32), then my advice is do not faff about it's just waste of time, just buy a J-Link right away.And sorry for all the people that told me that in this precise thread already - for my defense I was just really not impressed with uVision and did not expect the Segger tools to be better. Anyways - well done Segger. Rant over. Simon out.

author: emece67
author_rank: Frequent Contributor
timestamp: January 05, 2022, 10:49:14 am
content: .