EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: Sal Ammoniac on January 08, 2016, 11:18:22 pm
-
As a hobbyist, I don't have the budget for high-end ARM development tools like IAR and Keil. We use both of these tools at work, but I just can't justify paying $3-5K for a development tool for hobby use. I'd rather spend the money on a scope or other test equipment.
I'm always on the lookout for a better set of tools for doing development, and occasionally take a look at new tools, or older tools that I haven't looked at in a while. This week, I took time out from coding to look at three tools ranging from free to USD$89.
The first up is VisualGDB. This isn't an IDE in itself, but rather an add-on to Microsoft Visual Studio that supports compiling and debugging code for non-Windows targets. There are several levels available for developing Android, Linux, and embedded applications ranging from $89 to $349. I sprang for the $89 embedded version since I mainly work on embedded code for ARM Cortex-M MCUs. What really makes this an inexpensive proposition is that it works with Visual Studio Community Edition, which is a free download.
Downloading and installing VisualGDB is straightforward. I already had VS Community Edition 2015 installed, which saved some time, but when I first tried to create a project in VS using the VisualGDB plug-in, it needed to download a C++ package from Microsoft, which took about 20 minutes on my DSL connection. Once that was done, I was able to create a project targeting the STM32F407 on one of my development boards. This is where I started to run into issues. I'm not like the majority of hobbyist embedded developers--I don't use vendor peripheral libraries or frameworks, preferring to write my own code from scratch. All I look for in a development environment is a simple startup file that copies initialized data to SRAM, zeros the BSS, and jumps to main(). I do everything myself, including setting up the clocks and PLLs, initializing device drivers (which I write myself), etc. VisualGDB doesn't have the option to create a minimal embedded project via its project creation wizard. It gives you the option to create an LED blink project using a HAL, FreeRTOS, or a legacy peripheral library. I had to let it create one of these, and then go in and manually delete all of the unnecessary crap it pulled into my project.
Once I jumped through these loops, I was able to build my project and try downloading it to my board and running it. I use an ST/Link-v2, and VisualGDB supports this using a third-party tool called Texane/stlink. This tool works well enough, although it's somewhat chatty, informing me that everything is "jolly good" after it downloads an image to the board. I'm still trying to get my code to run under VisualGDB. There are some weird issues that are causing it to generate hard faults when I execute it. I haven't had the time to track this down yet, so I'm still somewhat in the dark about how well debugging an ARM board under Visual Studio works. Since it is Visual Studio, most of the commands will be familiar to anyone who has used VS to write Windows apps. My score for VisualGDB is a C+, but this may improve once I figure out why my code is faulting.
The next tool I tried was Atollic TrueStudio. Sometime late last year Atollic removed the code size limits from the free version and moved to a subscription model for the paid version. In addition, the free edition does not require any kind of registration, which is how it should be and Atollic deserves kudos for this. The paid version offers additional features, such as MISRA checking, interrupt tracing, profiling, and other things that the average hobbyist probably won't miss.
TrueStudio is your basic bog-standard Eclipse IDE, with all of the pluses and minuses that go along with it. Anyone who has used Eclipse in another guise will immediately feel familiar with it and shouldn't have any problems getting up to speed. I installed it and built the same application (home-grown RTOS + peripheral drivers + app code) that I used for the VisualGDB evaluation I described earlier in this post. I had no problems building the code and downloading it to the board via the ST/Link-v2, and the application ran first time with no changes other than one minor change due to the way the header files provided with TrueStudio define one of the GPIO registers.
As soon as I started to try out the debugger by downloading my code and single-stepping it, I was immediately reminded that this product is based on Eclipse. The code download and each step through the code took noticeably longer than my current gold standard for inexpensive IDEs (Rowley CrossWorks). If I was doing only occasional development work, the fact that TrueStudio is free and doesn't require registration would make it nearly ideal. But I don't think I could live with the slow downloads and slow single stepping. It'd drive me nuts very quickly. Overall score: B-, primarily due to the sluggishness of downloading and stepping code.
The last tool I tried was EmBitz. Some of you may be familiar with its predecessor: Em::Blocks. Em::Blocks is no longer available and EmBitz is its replacement. It's completely free and licensed under the GPL. The download is reasonably small (as far as IDEs go) and includes the ubiquitous GCC ARM compiler suite. It supports most of the ARM variants used by hobbyists, including NXP, ST, Atmel, Energy Micro, and Nordic. It also supports 8, 16, and 32-bit PICs and the TI MSP430.
Creating a new project and importing my code went very fast, and I didn't need to jump through any loops to get it to compile like I did on VisualGDB. Once again, I used the same code and same board as before, but this time the download went much, much faster than it did with TrueStudio. EmBitz is written in C++, not Java or .Net, and it shows. Single-stepping code happens as fast as I can click the mouse or mash on the keyboard. No lag at all, which was very refreshing after suffering through TrueStudio's slowness. The IDE itself, however, looks somewhat dated compared to TrueStudio or Visual Studio. For instance, debug windows such as CPU Registers, Breakpoints, and Watch Windows are floating and can't be docked. I haven't seen this in an IDE in over a decade. This may be a matter of taste, but like Han Solo said about the Millennium Falcon, "She may not look like much, but she's got it where it counts, kid." I'll take a fast, robust IDE any day over a gussied up prom queen. After all, you can put lipstick on a pig, but it's still a pig. Overall score: A- for being free and for its performance, with a few demerits for its dated look.
That's it, folks. I was really disappointed with how difficult it was to get my code going with VisualGDB, although I really need to put more time into it. It may yet be a reasonable environment once I work through all its quirks. I wasn't really surprised by TrueStudio's performance--I've used several other Eclipse-based IDEs in the past and they all felt like I was wading through a pool of molasses. EmBitz was the real eye-opener. It was by far the easiest to get my code up and running under and its performance was head and shoulders above the other two. It won't replace my current IDE, Rowley CrossWorks, but it's certainly a viable alternative.
-
If you're rolling your own RTOS and writing your own startup routines, you ought to be able to get by with a completely open source toolchain like GCC ARM Embedded (https://launchpad.net/gcc-arm-embedded).
For debugging, there's SEGGER's J-Link Debugger (https://www.segger.com/j-link-debugger.html). It's a free download, but technically requires a license with one of their debug probes. It does work with the EDU version, however.
-
The JLink GDB Server also works with the vendor-restricted embedded debug probes on dev kits.
I usually just use GDB from the CLI or emacs.
-
keil is free now. afaik they took the code limit off
-
keil is free now. afaik they took the code limit off
Since when? Not showing up on their website - the free version remains 32KiB limited. http://www.keil.com/demo/limits.asp (http://www.keil.com/demo/limits.asp)
-
Got it from a silicon vendor.
http://www.infineon.com/cms/en/product/microcontroller/32-bit-industrial-microcontroller-based-on-arm-registered-cortex-registered-m/xmc-development-tools-software-tools-and-partner/compiler-tool-chains/channel.html?channel=db3a30433784a0400137a308fc043e24 (http://www.infineon.com/cms/en/product/microcontroller/32-bit-industrial-microcontroller-based-on-arm-registered-cortex-registered-m/xmc-development-tools-software-tools-and-partner/compiler-tool-chains/channel.html?channel=db3a30433784a0400137a308fc043e24)
click on the link for the Free Keil MDK5. fill out the form. the website generates a key and gives you the download. Works fine for me.
-edit-. ah the stinkers ...
it throws you on a new page :
http://www2.keil.com/infineon/mdk (http://www2.keil.com/infineon/mdk)
'the toolkit is no longer available ....'
guess i got lucky.
-edit2-
http://www2.keil.com/stmicroelectronics-stm32/mdk (http://www2.keil.com/stmicroelectronics-stm32/mdk)
there is your key. that is a 256k version
-
Got it from a silicon vendor.
http://www.infineon.com/cms/en/product/microcontroller/32-bit-industrial-microcontroller-based-on-arm-registered-cortex-registered-m/xmc-development-tools-software-tools-and-partner/compiler-tool-chains/channel.html?channel=db3a30433784a0400137a308fc043e24 (http://www.infineon.com/cms/en/product/microcontroller/32-bit-industrial-microcontroller-based-on-arm-registered-cortex-registered-m/xmc-development-tools-software-tools-and-partner/compiler-tool-chains/channel.html?channel=db3a30433784a0400137a308fc043e24)
click on the link for the Free Keil MDK5. fill out the form. the website generates a key and gives you the download. Works fine for me.
-edit-. ah the stinkers ...
it throws you on a new page :
http://www2.keil.com/infineon/mdk (http://www2.keil.com/infineon/mdk)
'the toolkit is no longer available ....'
guess i got lucky.
Damn - you had me excited for a minute!
-edit2-
http://www2.keil.com/stmicroelectronics-stm32/mdk (http://www2.keil.com/stmicroelectronics-stm32/mdk)
there is your key. that is a 256k version
Only for STM?
-
If you're rolling your own RTOS and writing your own startup routines, you ought to be able to get by with a completely open source toolchain like GCC ARM Embedded (https://launchpad.net/gcc-arm-embedded).
I use Rowley CrossWorks, and I'm satisfied with it. I occasionally look to see if anything better comes along. I don't want to bother taking the time to put together something from open source. Been there, done that, and once was enough.
-
Only for STM?
And only two families. Basically ST did a promotion cross deal with ARM.
I'm generally only upset when vendors don't ship ld linker files and assumes everyone must use IAR or Keil. The actual IDE in both of those is honestly not competitive, and the compilers are quirky on things gcc and clang are both much better at. I do *use* Keil, but mostly grudgingly because vendors only made one "easy" path.
(Really, building a native AOT compiler on anything but LLVM these days is basically relegating you to obsolescence)
Sent from my iPad using Tapatalk
-
I use Rowley CrossWorks, and I'm satisfied with it. I occasionally look to see if anything better comes along. I don't want to bother taking the time to put together something from open source. Been there, done that, and once was enough.
Me too. For personal, non-commercial use it's just $150, and doesn't get nearly the forum coverage that it should, IMHO.
-
Only for STM?
Not only that, but only F0 and L0..
-
I'm generally only upset when vendors don't ship ld linker files and assumes everyone must use IAR or Keil. The actual IDE in both of those is honestly not competitive, and the compilers are quirky on things gcc and clang are both much better at. I do *use* Keil, but mostly grudgingly because vendors only made one "easy" path.
Is it the silicon vendor's responsibility to produce those? I was thinking that compiler vendors made their own suited for their toolchain?
-
I'm using Eclipse for everything that smells like sourcecode; Eclipse is also very good at helping to keep an overview of a complex project which keeps my productivity high. In case of microcontroller projects: setting up a new project to compile with GCC and the LD files is peanuts once you have done that a couple of times. Every now and then I need specialised LD files too so having that knowledge pays off quickly.
-
That's it, folks. I was really disappointed with how difficult it was to get my code going with VisualGDB, although I really need to put more time into it. It may yet be a reasonable environment once I work through all its quirks. I wasn't really surprised by TrueStudio's performance--I've used several other Eclipse-based IDEs in the past and they all felt like I was wading through a pool of molasses. EmBitz was the real eye-opener. It was by far the easiest to get my code up and running under and its performance was head and shoulders above the other two. It won't replace my current IDE, Rowley CrossWorks, but it's certainly a viable alternative.
Well as mentioned in your previous thread qoute: neat, small and tidy, bare metal with STD lib if you like. Now send Gerhard a coin or two, he needs it! ;)
Embitz is all about being small and productive rather then a big bloathed pool of molass'ed bling!
-
That's it, folks.
As the old saying would have it: we are too poor to buy cheap stuff.
I stay with keil / iar, and occasionally coide, because they just work. Sure, the ides don't make coffee for me, or wow me with fancy features but on the only thing I desire out of them - get the shit done - they are fully capable of doing it, day in and day out.
Until that changes, I will stay with them.
-
Hi..
Why not try atollic.
it used to cost a lot .now it is free
http://timor.atollic.com/ (http://timor.atollic.com/)
Claus
-
Hi..
Why not try atollic.
it used to cost a lot .now it is free
http://timor.atollic.com/ (http://timor.atollic.com/)
Claus
Atollic=Eclipse + GCC
-
Does it?
Or does Atolllic = Eclipse + GCC + a great deal of time consuming, error prone setup and configuration already done?
-
Does it?
Or does Atolllic = Eclipse + GCC + a great deal of time consuming, error prone setup and configuration already done?
I don't see how much error prone configuration needs to be done to get a project going in Eclipse. Select the embedded GCC compiler, set the include path, library path and setup the LD and you are ready to go. Most can be copied from an existing/previous project.
-
Just to clarify, I really like the look and feel of Eclipse. I like its window layout and I like its editor. I like just about everything about it except its performance. That's always the stumbling block for me. It just feels so sluggish and unresponsive after using something like CrossWorks.
For anyone who hasn't tried CrossWorks, I recommend they do. It's just so much faster at downloading and debugging code compared to anything Eclipse-based that it's just rediculous. Sure, it may not have the fancy editor Eclipse has, but it has it where it counts: performance. And I'd also place CrossWorks in that category of tool that "just works".
-
Overall score: B-, primarily due to the sluggishness of downloading and (...)
You can try my SplitCode (http://sourceforge.net/projects/splitcode/).
It replaces a standard makefile and results in a partitioned binary where frequently edited source file output is placed in one part of memory and things you have not edited recently (like OS, libs, peripheral driver etc) sit in the other part of the memory. This way only the tiny memory part (the one that results from recent editing) needs to be uploaded. The tiny upload size and time does not depend on the size of final application - even the 1MB app update takes 3-4 seconds.
The project is not complete, just a proof of concept and of what is possible.
-
Just to clarify, I really like the look and feel of Eclipse. I like its window layout and I like its editor. I like just about everything about it except its performance. That's always the stumbling block for me. It just feels so sluggish and unresponsive after using something like CrossWorks.
On Windows or Linux? Eclipse tends to be rather slow on Windows. When using Eclipse on Linux I get sub-second compile times on my machine for reasonably sized projects including a USB device stack.
-
Just to clarify, I really like the look and feel of Eclipse. I like its window layout and I like its editor. I like just about everything about it except its performance. That's always the stumbling block for me. It just feels so sluggish and unresponsive after using something like CrossWorks.
On Windows or Linux? Eclipse tends to be rather slow on Windows. When using Eclipse on Linux I get sub-second compile times on my machine for reasonably sized projects including a USB device stack.
I've tried it on both Windows and Linux and, while it performs better on Linux than Windows, it's still quite slow compared to CrossWorks or EmBitz. Compile time is not the issue--the issue is downloading code to the micro and debugging it (particularly single-stepping).
-
Just to clarify, I really like the look and feel of Eclipse. I like its window layout and I like its editor. I like just about everything about it except its performance. That's always the stumbling block for me. It just feels so sluggish and unresponsive after using something like CrossWorks.
On Windows or Linux? Eclipse tends to be rather slow on Windows. When using Eclipse on Linux I get sub-second compile times on my machine for reasonably sized projects including a USB device stack.
I've tried it on both Windows and Linux and, while it performs better on Linux than Windows, it's still quite slow compared to CrossWorks or EmBitz. Compile time is not the issue--the issue is downloading code to the micro and debugging it (particularly single-stepping).
If you're using OpenOCD that could be the reason - I prefer using the Segger tools directly.
-
Just to clarify, I really like the look and feel of Eclipse. I like its window layout and I like its editor. I like just about everything about it except its performance. That's always the stumbling block for me. It just feels so sluggish and unresponsive after using something like CrossWorks.
On Windows or Linux? Eclipse tends to be rather slow on Windows. When using Eclipse on Linux I get sub-second compile times on my machine for reasonably sized projects including a USB device stack.
I've tried it on both Windows and Linux and, while it performs better on Linux than Windows, it's still quite slow compared to CrossWorks or EmBitz. Compile time is not the issue--the issue is downloading code to the micro and debugging it (particularly single-stepping).
If you're using OpenOCD that could be the reason - I prefer using the Segger tools directly.
I don't use OpenOCD. I either use a Segger J-Link (a real one, not a counterfeit) for NXP ARMs or an ST/Link-V2 for STM32s.
-
Sal, ImageCraft's (my company) JumpStart for Cortex-M also starts at $99, and if you purchase the JumpStart MicroBox, it even comes with the ST-Nucleo, a shield with "everything but kitchen sink", and even a C e-book. The non-commercial use debugger is $50. No complicated setup. Not based on Eclipse, nor GCC. PM if interested.
-
Sal, ImageCraft's (my company) JumpStart for Cortex-M also starts at $99, and if you purchase the JumpStart MicroBox, it even comes with the ST-Nucleo, a shield with "everything but kitchen sink", and even a C e-book. The non-commercial use debugger is $50. No complicated setup. Not based on Eclipse, nor GCC. PM if interested.
Hmmm... Looks very interesting. Especially that it's not based on either Eclipse or GCC. One thing's a showstopper for me however--your website says the compiler only supports Cortex-M0 and M3 with M4 and M7 support coming. I switched from M3 to M4 a few years ago and don't want to go back. When is M4/M7 support expected to be ready?
Does the demo version only include the compiler, or does it also include CodeBlocks and the debugger?
-
Just to clarify, I really like the look and feel of Eclipse. I like its window layout and I like its editor. I like just about everything about it except its performance. That's always the stumbling block for me. It just feels so sluggish and unresponsive after using something like CrossWorks.
On Windows or Linux? Eclipse tends to be rather slow on Windows. When using Eclipse on Linux I get sub-second compile times on my machine for reasonably sized projects including a USB device stack.
I've tried it on both Windows and Linux and, while it performs better on Linux than Windows, it's still quite slow compared to CrossWorks or EmBitz. Compile time is not the issue--the issue is downloading code to the micro and debugging it (particularly single-stepping).
I never use on-target debugging. I gave up on that decades ago because it is always clumsy and there are faster alternatives.
-
I never use on-target debugging. I gave up on that decades ago because it is always clumsy and there are faster alternatives.
What are these faster alternatives you speak of?
-
Apropos inexpensive ARM development tools, LPCXpresso is free for up to 256KB, runs on all three OSs, a single package install installs the IDE + toolchain, it support hardware debuggers (including a ~$20 link II), has the familiar (at least to me) eclipse UI, generates project makefiles that you can also use from command line, is under active development. It is also supported by mbed which can export an entire project in a single lpcxpresso compatible .zip file.
I have used it for a year or so and it works just great. Most of the time I use it with the the NXP usb/virtual_disk bootloader (a standard USB cable and a file copy command) and use the hardware debugger only in special occasions.
-
I never use on-target debugging. I gave up on that decades ago because it is always clumsy and there are faster alternatives.
What are these faster alternatives you speak of?
Debugging code on a PC first and then use it in the microcontroller. Eclipse + GCC is a good combo because they also support the PC platform + very fancy debugging. It helps a lot if you start an embedded project with code which works because it has been through a series of tests already. Furthermore I have a command line interpreter in all my products which collects status information and allows reading various parameters or just dumps the status every X seconds (which could be based on a logging level).
-
I never use on-target debugging. I gave up on that decades ago because it is always clumsy and there are faster alternatives.
What are these faster alternatives you speak of?
Debugging code on a PC first and then use it in the microcontroller. Eclipse + GCC is a good combo because they also support the PC platform + very fancy debugging. It helps a lot if you start an embedded project with code which works because it has been through a series of tests already. Furthermore I have a command line interpreter in all my products which collects status information and allows reading various parameters or just dumps the status every X seconds (which could be based on a logging level).
I always unit test all my algorithmic and non-driver code on a PC first.
It really helps to have the same compiler on both, and is a huge advantage for automated builds and regression suites as well.
As MCU complexity grows from the few K of code job, adopting practices from large scale software starts paying off.
-
Hmmm... Looks very interesting. Especially that it's not based on either Eclipse or GCC. One thing's a showstopper for me however--your website says the compiler only supports Cortex-M0 and M3 with M4 and M7 support coming. I switched from M3 to M4 a few years ago and don't want to go back. When is M4/M7 support expected to be ready?
Does the demo version only include the compiler, or does it also include CodeBlocks and the debugger?
Hi Sal, we are finishing up the M4 FP instructions support, but you can use it already, as a fast M3. In fact, one reason we are late with the FP instructions is because we are working on a couple M4 based products, which hopefully will be disclosed within 2 weeks. We have our JumpStart API working great for M0 and M4 now. Check out the JumpStart API doc our our site, it's far easier to use than the ST StdPeriphLib or HAL, and will continually be extended (see the abovementioned "new products").
Indeed, we only have a couple M0 Nucleo left. After thay are gone, we will switch to M4 Nucleo as part of the JumpStart MicroBox kit.
The "compiler" includes the IDE and compiler, and the debugger. For purchase, you pay $99 for the non-commercial sue license of the compiler+IDE, and $50 for the debugger license. The debugger is of course optional so $99 will get you going.
The debugger is our own also, and works great with ST-LINK and Segger Jlink.
-
If you're rolling your own RTOS and writing your own startup routines, you ought to be able to get by with a completely open source toolchain like GCC ARM Embedded (https://launchpad.net/gcc-arm-embedded).
There's just something incredibly simple and liberating just using emacs, Makefiles, etags, and M-x gdb. It's so much easier to just type a cast or array index like ((struct _foo*)foo)[bar*7] than try to figure out how to make a GUI IDE do the same. Or make a breakpoint conditional on having been called a certain number of times, or such. VS is a little easier than Eclipse based ones, but in general what should take ten seconds to type becomes along tedious hunt.
-
I haven't tried this yet and not sure if it fully applies to MCUs
But Visual Studio has a GDB Debugger extension
https://www.eevblog.com/forum/microcontrollers/whatever-happened-to-coocox/msg802965/#msg802965 (https://www.eevblog.com/forum/microcontrollers/whatever-happened-to-coocox/msg802965/#msg802965)
Link of the announcement in the post. An excerpt of the announcement states:
Earlier this year I wrote a post on how you could debug C++ code on Linux from Visual Studio. It was a bit cumbersome, but it was doable. Today we are releasing the Visual Studio GDB Debugger extension preview. This will enable debugging remote Linux targets including IoT devices.
Edit: From the comments, just this pass November 19th
Great extension!
Could you please extend this to MCUs such as MSP430, STM32F4 and support for C and you'll have an awesome IDE.
I can't wait to start using VS to debug my microcontroller and .NETMF projects.
Good job.
working on it! :-)
Myself I use Creator but that's specific to Cypress PSoC family.
No code limits and free.
-
There's just something incredibly simple and liberating just using emacs, Makefiles, etags, and M-x gdb.
It's probably simple and liberating to build your own house from scratch too, but that's just not for me either.
-
There's just something incredibly simple and liberating just using emacs, Makefiles, etags, and M-x gdb.
It's probably simple and liberating to build your own house from scratch too, but that's just not for me either.
To be honest, the GNU tool suite is all integrated and just as easy to learn :)
-
Don't forget libc, which is not strictly part of gcc itself, and you probably don't want to do without.
A good, non-bloated, bare-metal friendly, version of libc is pretty rare :-( (a lot of ARM packages ship with "newlib" which is desktop-derived and will do things like pull in a bunch of filesystem code just to support printf() "newlib nano" is better, I think.
the current arm gcc softwarefloating point libraries for M0 are also not optimized, making them much bigger and slower than the M3/M4 SFP libraries.
-
There's just something incredibly simple and liberating just using emacs, Makefiles, etags, and M-x gdb.
It's probably simple and liberating to build your own house from scratch too, but that's just not for me either.
To be honest, the GNU tool suite is all integrated and just as easy to learn :)
GCC + Whatever you're comfortable with, all the way. This way, I have the same development environment for STM32 (F0->F7), Nordic nRF51, TI CCxxxx, Ralink MIPS, ESP8266, etc..
No commercial IDE even comes close to offering something similar.
-
Thanks for this, and interesting conversation. I also use Crossworks, but am open to find anything that's free and comparable.
Debugging/programming speed is pretty crucial to me as a hobbyist. Different development process definitely. I'm not making commercial products; I'm just playing around. Most of my projects I can see the results of immediately, so I simply program run/debug, edit, run/debug, and repeat until I have the results I want. Not coordinating with anyone and no quality process to work with. Most of the debug issues I have is the sensors/lcd's, other modules I'm communicating with don't work the way I expect so edit, run, repeat and put on the scope or logic probe if it's really tricky.
The below project I pieced together this weekend when this LCD just came in. So I plug everything together load up the programmer and start writing code for one piece at a time. Again, program, run, see the results, repeat...
(http://www.higginstribe.com/uc/lpc1xxx/touch-remote/20160111_100331.jpg)
-
Don't forget libc, which is not strictly part of gcc itself, and you probably don't want to do without.
A good, non-bloated, bare-metal friendly, version of libc is pretty rare :-( (a lot of ARM packages ship with "newlib" which is desktop-derived and will do things like pull in a bunch of filesystem code just to support printf() "newlib nano" is better, I think.
There's no filesystem code. I guess you're referring to the _write, etc. stubs. By implementing the _write stub, you can make printf print to UART, display, you name it.
Newlib also has the advantage that it's portable between many MCUs: https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine;h=cd58736e22539f182caa7cd1ad32bceff8f66cf5;hb=HEAD
Regarding the 'building your own house; stuff. It's not a fault of GCC, make or the editor. It's the fault of the manufacturer not to provide a simple non-bloated Makefile-based example project.
-
A good, non-bloated, bare-metal friendly, version of libc is pretty rare
Besides, does it matter how bloated libc is when it is not used in release firmware? Just buy the biggest package, biggest flash size uC, do your development job and then strip everything wasteful for release with cheapest uC on the market.
The newlib-nano is 9k without floats, with full semihosting support. That includes sbrk. If you want something faster than semihosting, you should either redirect write to USB Hi-Speed pipe or wire up ETM pins to a tracing dongle.
-
A good, non-bloated, bare-metal friendly, version of libc is pretty rare
You don't have to use the compiler's provided C library. I have been using the micro C library which came with an ancient version of MSPGCC (MSP430 GCC) for over a decade in my ARM projects. And if printf becomes too large you can always write a micro-printf which is a much better method to save space than trying to re-invent the wheel by having your own string/number output functions.
-
GCC also has good support for full LTO now, which is the ideal for cross translation unit in lining and removal of dead code.
-
GCC is so 1980s. Clang/LLDB is the way to go today.
-
GCC is so 1980s. Clang/LLDB is the way to go today.
I can totally agree with this, except for the CM targets not being up to snuff in LLVM quite yet.
-
GCC is so 1980s. Clang/LLDB is the way to go today.
I can totally agree with this, except for the CM targets not being up to snuff in LLVM quite yet.
Please tell me why as I'm curious and don't know much about Clang.
-
Eclipse Performance...
Are there any Java gurus around here who can explain why Eclipse performs as sluggishly as it does? I'm using the standard Java SE8 download from Oracle--is there another Java VM with better performance that would improve Eclipse performance? My development machine is pretty capable--it's a Core i7 Haswell-E running at 4 GHz with 32 GB of RAM and an SSD as its C: drive, so I doubt that's the cause.
As a point of reference, I also use Microchip's MPLAB X to do PIC32 development. MPLAB X is based on Netbeans, which is also written in Java. I find MPLAB X performance to be much better than Eclipse on the same machine. I wonder why this is?
-
Play a bit with the appearance settings. Some themes are significantly slower than the other.
-
GCC is so 1980s. Clang/LLDB is the way to go today.
I can totally agree with this, except for the CM targets not being up to snuff in LLVM quite yet.
Please tell me why as I'm curious and don't know much about Clang.
For a long time, GCC (and EGCS and back to GCC) was the only serious open source compiler on the block (and even commonly better than the commercial variants, including ICC and MSVC - blows were traded). However, GCC actively fought several key measures such as modularization of the compiler ("plugins") which was seen as a threat to the pure GPL version.
Apple needed a compiler which they could integrate into their developer suite after dragging along with GCC and even Metroworks for years, and found some hope in a project called LLVM. LLVM was a non-GPL, open source compiler-framework of sorts. After pouring years of R&D into it, LLVM and the new Clang matured in new ways that the more conservative GCC never bothered to adopt. Clang had much better programmer ergonomics (compare a clang C++ template error to a GCC one at the time frame, or even C missing close block syntax errors), and more importantly was very modular and pluggable as LLVM had been grown as a framework instead of a monolith. This allowed people to create a very large number of tools re-using parts of the Clang+LLVM pipeline, such as top end semantic analyzers, refactoring tools, source to source translators, and on the backend new and unique optimizer passes.
In short, LLVM had a lot of very smart people on it providing a ton of competition to GCC, and GCC is playing catch-up now. Clang+LLVM+LLDB are projects which are mostly programmer-compatible with GCC+GDB, but provide a "fresh perspective" and are as good or better than GCC, plus substantially easier to integrate into an IDE or generate new tooling around.
-
I notice that ARM now has an LLVM compiler. It differs from their GCC compiler in that the customer must now pay a lot of money for the LLVM compiler while their GCC compiler is free. Must be the non-GPL license loop hole.
-
I notice that ARM now has an LLVM compiler. It differs from their GCC compiler in that the customer must now pay a lot of money for the LLVM compiler while their GCC compiler is free. Must be the non-GPL license loop hole.
I noticed the same! Besides that I'm wondering what the actual code generation improvement is compared to GCC and how long it will take before support for LLVM becomes really mainstream. There is a tendency for some people to declare stuff obsolete because there is something new on the horizon but fail to see the (potential) problems early adopters have to deal with. I don't doubt LLVM looks better under the hood (cleaner sourcecode) but for me as a compiler user I only really care about the output.
-
"Must be the non-GPL license loop hole."
Choices are always good.
-
Just spent another evening messing around with another Eclipse-based IDE. Why do I put myself through this torture? |O
Are there any ARM IDEs based on NetBeans? That would be so much better than Eclipse, based on my experience doing non-embedded development with it and my experience with MPLAB X.
-
GCC + Whatever you're comfortable with, all the way. This way, I have the same development environment for STM32 (F0->F7), Nordic nRF51, TI CCxxxx, Ralink MIPS, ESP8266, etc..
No commercial IDE even comes close to offering something similar.
What IDE do you use?, eclipse?
Do you have any links/startingpoints etc, on how to set up an environment with multiple toolchains?
When installing vendor specific solutions, the computer gets littered with various versions of IDE's, toolchains everywhere and so on, would be nice to have one setup at one place so I can move things around, now, if I move anything, I guess I would break everything..
-
Quote from: Sal Ammoniac on Today at 17:56:00 (https://www.eevblog.com/forum/index.php?topic=61037.msg840955#msg840955)
Just spent another evening messing around with another Eclipse-based IDE. Why do I put myself through this torture? |O
Are there any ARM IDEs based on NetBeans? That would be so much better than Eclipse, based on my experience doing non-embedded development with it and my experience with MPLAB X.
Why not use EmBitz?
-
Or explain what the problem is with Eclipse...
-
"Must be the non-GPL license loop hole."
Choices are always good.
If you have the money.
-
Or explain what the problem is with Eclipse...
It's too bloody sluggish. Opening up a workspace takes a long time. Navigating the UI is sluggish. Downloading code to a board takes too long. Single-stepping code takes 1-2 seconds per step. It all adds up to a poor experience.
And it's not just performance issues. Eclipse has a messed up workspace/project paradigm that's needlessly complicated, poorly designed perspectives, metadata that gets out of sync easily--I could go on and on.
I have used MPLAB X extensively. It's based on NetBeans and it's much faster than Eclipse and without as many of Eclipse's UI quirks. That seems to me to be a better option than Eclipse. Another option is IntelliJ, which is also much nicer than Eclipse and is open source.
What I'm trying to say here is that there are viable alternates to Eclipse (NetBeans and IntelliJ) to base an IDE on (assuming insufficient resources to write an IDE from scratch in a proper language such as C++). Too many companies seem to take the path of least resistance and go with Eclipse, despite its shortcomings. I think the market is ripe for a good alternative.
-
Or explain what the problem is with Eclipse...
It's too bloody sluggish. Opening up a workspace takes a long time. Navigating the UI is sluggish. Downloading code to a board takes too long. Single-stepping code takes 1-2 seconds per step. It all adds up to a poor experience.
As I wrote before: the default theme Eclipse uses can be very slow. Changing the theme made a world of difference to me.
And it's not just performance issues. Eclipse has a messed up workspace/project paradigm that's needlessly complicated, poorly designed perspectives, metadata that gets out of sync easily--I could go on and on.
The workspace/project paradigm is just fine but it is intended to work on very large projects (workspace) consisting of multiple sub-projects (projects) so it may be overkill for a single microcontroller project. In my use of Eclipse I have VHDL code, PC code and microcontroller code in one workspace.
Metadata getting out of sync is a matter of tweaking the file monitoring settings in Eclipse.
OTOH: nothing helps if your PC is extremely slow. Indexing a large project with lots of includes is going to take a while if you have a slow hard drive.
-
I notice that ARM now has an LLVM compiler. It differs from their GCC compiler in that the customer must now pay a lot of money for the LLVM compiler while their GCC compiler is free. Must be the non-GPL license loop hole.
Must? No. Maybe? Perhaps. One can charge an arm and a leg for GPL licensed software and give non-GPL software available for free. So, you should probably consider alternative explanations. There are a few.
-
So what is the industry standard IDE for ARM MCUs today? I mean, what the professionals use for designing products.
-
CodeBlocks IDE, which is written in GCC, is quite fast. Our compiler loads and compiles quite fast as well. We could have gone with Eclipse when we were deciding, but the speed issue weighs heavily.
-
So what is the industry standard IDE for ARM MCUs today? I mean, what the professionals use for designing products.
We are using Keil for all of our products in the company, have been doing so for 12 years.
Using it on ARM mostly, but also 805x in the earlier years.
Same for my own hobby projects, always using Keil
-
So what is the industry standard IDE for ARM MCUs today? I mean, what the professionals use for designing products.
Keil and IAR. Both of these are in the USD$4-5K range, however, so they are not used much by hobbyists unless the code size limitation imposed by the free versions isn't an issue.
-
I notice that ARM now has an LLVM compiler. It differs from their GCC compiler in that the customer must now pay a lot of money for the LLVM compiler while their GCC compiler is free. Must be the non-GPL license loop hole.
Must? No. Maybe? Perhaps. One can charge an arm and a leg for GPL licensed software and give non-GPL software available for free. So, you should probably consider alternative explanations. There are a few.
This is exactly what Microchip does with their PIC16/32 compilers - for an extra $1k you gain back the optimizer settings in GCC. Dubious at best.
-
So what is the industry standard IDE for ARM MCUs today? I mean, what the professionals use for designing products.
Last firmware job I had used a parameterized meta builder (which I overhauled a few times): it kicked out project files for IAR as well as Makefiles, depending on the compiler in use for that product variant. There was a big precedent for code reuse in the same repository line, and we had large scale automated tests to avoid regressions on all those variants. There were only 5 firmware developers.
Used Emacs and SublimeText as editors, and only used IAR for debugger access.
-
This is exactly what Microchip does with their PIC16/32 compilers - for an extra $1k you gain back the optimizer settings in GCC. Dubious at best.
Since their compilers are based on GCC, there's nothing stopping anyone from downloading the source from the Microchip site, removing the licence manager code, and compiling it.
-
OTOH: nothing helps if your PC is extremely slow. Indexing a large project with lots of includes is going to take a while if you have a slow hard drive.
Let's see... My development machine is an 8-core Core i7 Haswell-E box with 32 GB of RAM. The C: drive, where Java and Eclipse reside, is two SSDs in RAID-0. The graphics board is an Nvidia GTX 980Ti.
Do you think this machine is fast enough to run Eclipse? :-DD
-
Nope it's not. All Eclipse aficionados that claim that it's because your computer is not on par, are just experiencing cognitive dissonance.
And I would have recommended CrossWorks, but lots of other already have done here.
Just a few words about their licensing scheme:
- there is now a free license with limited output size
- if you own a named license you are able to run CW on all your own computer and on all the three systems (OS X, Linux and Windows) without restrictions
- they provide both GCC and CLang based compiler
- they provide their own C library (in an open source manner)
- crossword is extensible, you don't have to install all the existing library and can do it on the fly
- no need to Internet access to validate every days that you have the right to use the software
- support is done really quickly and in a really efficient way (I had a really good contact with them)
- and the full price for commercial is only $1500 which compared to all other commercial packages, really cheap. ($150 for a personal non commercial license)
-
Nope it's not. All Eclipse aficionados that claim that it's because your computer is not on par, are just experiencing cognitive dissonance.
I am using eclipse professionally on large software projects. When I say large I mean really large, not measly binaries with just a few tens of MBs, and it works just great. Same goes when I use it for small hobby LPCXpresso M0 hobby projects on a low end 11" Macbook Air.
YMMV.
-
I am using eclipse professionally on large software projects. When I say large I mean really large, not measly binaries with just a few tens of MBs, and it works just great. Same goes when I use it for small hobby LPCXpresso M0 hobby projects on a low end 11" Macbook Air.
Yep. YMMV. I've often found that people who use Eclipse on embedded projects think it works great because they don't have anything to compare it to.
-
I use Eclipse Luna + plug-ins for hobby development on windoze XP. Underclocked CoreDuo 750MHz with 3GB of RAM.
As for stepping speed of Eclipse OP whinges so much about, I have done Hello World project for ARMv7M (STM32L-Discovery) and when I press F6 continuously:
printf("Eclipse Luna stepping on ARMv7M + ST-link/V2\n");
for(int iterate=0; iterate != 100; iterate ++){
volatile int step_count =0;
step_count+=1;
step_count+=2;
step_count+=4;
}it does 16 full loops under 30 seconds (each loop has 4 steps). So that is over two steps per second.
Mind I did not state the are no faster stepping IDEs but OP's 2s sounds impossible (or OP has messed up something badly with setup).
-
How can you compare an "hello world project" with less than 10 lines of code, with a Multi GB project?
I've tryed Eclipse in the different company I have worked to select an IDE, it never has been able to load the full project on each, and on one of these jobs it was nothing more than the Linux kernel...
-
I am using eclipse professionally on large software projects. When I say large I mean really large, not measly binaries with just a few tens of MBs, and it works just great. Same goes when I use it for small hobby LPCXpresso M0 hobby projects on a low end 11" Macbook Air.
Yep. YMMV. I've often found that people who use Eclipse on embedded projects think it works great because they don't have anything to compare it to.
I would not trade Eclipse for Freescale's old Code Warrior, Keil uVision, IAR's Workbench or Visual Studio. Unfortunately there can be several reasons for Eclipse to run slow so you really need to investigate instead of just bashing. Eclipse is (among) the most used IDEs in the world; do you really think that so many people will want to use an IDE which is slow? For example Panda anti-virus made Eclipse take 2 minutes to compile a project which otherwise took 20 seconds.
@Godzil: the Linux kernel does take a while to index and you have to configure Eclipse to use more memory but it can handle the Linux kernel just fine! Been there, done that.
-
it does 16 full loops under 30 seconds (each loop has 4 steps). So that is over two steps per second.
Mind I did not state the are no faster stepping IDEs but OP's 2s sounds impossible (or OP has messed up something badly with setup).
OP here... If something in my setup is messed up, then it's the fault of the IDE vendor because this happens on a default install of the tool with no modifications done to the setup by me.
The stepping speed you quote is nothing to brag about. Two steps per second is still 1/2 second per step, which is crawling. Rowley CrossWorks can easily do >10 steps per second with an ST-Link/V2.
-
Oh no worries I've done that, all the memory stuff, and guess what? All the version of eclipse I've use, the indexer just crashed in a dead loop hogging CPU, I've let it run for hours and even day without it to recover.
Sorry, but on that Netbeans worked better; far from perfect, but better.
As usual, it's not because a product is used by a lot it's mean that it's a good product (or the best).
Can I remind the VHS?
-
Eclipse is (among) the most used IDEs in the world; do you really think that so many people will want to use an IDE which is slow?
See http://www.ihateeclipse.com/ (http://www.ihateeclipse.com/)
In my case, I don't run any anti-virus software or anything else what could have a similar effect on my machine's ability to run Eclipse. In fact, I keep my development machine pretty pure. All I have on it are my IDE, GCC and Clang, another editor (Notepad++), a serial port emulator, the drivers for various USB interfaces (FTDI, etc.), Adobe Reader (to read datasheets), and a browser. My experience with Eclipse lameness isn't just limited to one example. I've tried several (Atollic, LPCXpresso, and another one I forget the name of) and they all perform like dogs. Granted, performance tuning may be necessary to make Eclipse perform at its best, so why don't vendors like Atollic and NXP do this? Why don't they distribute a fully tuned IDE rather than relying on users to have to do this tuning?
-
How can you compare an "hello world project" with less than 10 lines of code, with a Multi GB project?
a Multi GB project
where did OP mention stepping through multi GB project?? Reference please.
I am comparing that / referring to the Cortex-M test project OP stepped through under Eclipse.
-
This is exactly what Microchip does with their PIC16/32 compilers - for an extra $1k you gain back the optimizer settings in GCC. Dubious at best.
Since their compilers are based on GCC, there's nothing stopping anyone from downloading the source from the Microchip site, removing the licence manager code, and compiling it.
I'm not kidding, I tried but I failed with very obscure build erros, like invalid parameters being passed to cc1 during compilation. Spent one or two evenings on it and walked away frustrated. Looking in the build info of the binary, they are building the already ancient GCC using a even more ancient one (4.1 iirc, which is like 10 years old). Their PIC support is sort of 'tacked' on just to make it work, really dodgy. Even if you've managed to build the gcc, it will generate calls to functions from their proprietary libc/libgcc for multiplication, soft float etc. I haven't found anyone being successful with building the PIC gcc from source. Even if you manage to build it, you're still left with an older/inferior compiler than you'll get for AVR, MSP430, RL78 or ARM. For these ones, I can use that latest GCC that I also use for building software on x86.
-
IMHO Microchip really shot themselves in the foot by making a proprietary GCC for their PIC32 microcontrollers because they will always be behind with the mainstream GCC development. GCC for ARM (maintained by ARM!) is much more up to date and the latest upgrade I did resulted in a healthy improvement of code density.
-
I have been trying DS-5 for a while.
-
IMHO Microchip really shot themselves in the foot by making a proprietary GCC for their PIC32 microcontrollers because they will always be behind with the mainstream GCC development. GCC for ARM (maintained by ARM!) is much more up to date and the latest upgrade I did resulted in a healthy improvement of code density.
Personally I can't imagine why anyone would choose a MIPS microcontroller when there is ARM. And having to deal with Microchip's bullshit on top of that? No thanks.
-
IMHO Microchip really shot themselves in the foot by making a proprietary GCC for their PIC32 microcontrollers because they will always be behind with the mainstream GCC development. GCC for ARM (maintained by ARM!) is much more up to date and the latest upgrade I did resulted in a healthy improvement of code density.
Personally I can't imagine why anyone would choose a MIPS microcontroller when there is ARM. And having to deal with Microchip's bullshit on top of that? No thanks.
Agree. The only reason I'd consider Microchip is for an absolute bottom of the range part, where I need a the cheapest possible low pinout MCU.
Even some of their earlier advantages, such as peripherals being available at (nearly) any pin switch matrix are available in other vendors now.
-
Personally I can't imagine why anyone would choose a MIPS microcontroller when there is ARM. And having to deal with Microchip's bullshit on top of that? No thanks.
The PIC32 parts are actually not bad. The PIC32MX series compares favorably with the Cortex-M3 and the PIC32MZ compares favorably with the Cortex-M4/M7. They have a free IDE (MPLAB X; based on NetBeans) and a free C compiler (without optimizations; you can pay for optimizations or build it from source). The IDE works well (e.g. better than your average Eclipse-based ARM IDE) and is updated frequently.
The core is based on MIPS32, which is quite a nice architecture. Simpler in many ways than the Cortex-M architecture, but just as capable and fast. The latest iteration, the PIC32MZ runs at 200 MHz and has hardware floating point and DSP instructions. Microchip released it too early and the initial silicon had nasty errata, but most of them have been fixed now and it's no more buggy than your average Cortex-M part. The peripherals are simpler than some of the "kitchen sink" peripherals seen on some Cortex-M parts, but they get the job done and they're implemented in a consistent manner.
For a hobbyist, the biggest Microchip shortcoming is the lack of good, cheap development hardware. The PICKit 3 is relatively cheap at $48, but it's not good (it's slowwwwwwww). The next step up the line is the ICD-3, which is about as fast as an ST-Link/V2, but it's $200.
Overall I like the Cortex-M parts better, but PIC32 is certainly a viable option, especially for someone coming from the 8-bit or 16-bit PIC worlds.
-
a Multi GB project?
Perhaps we can start by agreeing that just maybe the people writing multi-gigabyte multi-core 64-bit ARM projects might be selecting development tools based on different criteria than the people trying to squeeze code onto one of those Cortex M0 microcontrollers with 16k of program space?
(This is actually a weakness of the ARM target. Since it does span from 4k to 4G (and larger) configurations, it's really easy to find tools that are inappropriate for your particular need. My "newlib" complaints are an example. The currently-poor CM0 libgcc soft floating point routines are another.)
("maybe" is quite accurate, too. I'm pretty much a "legacy editor and CLI tools" kinda person regardless of project size, but I've seen people come into a multi-GB environment and say "where's my Eclipse? I can make it work; just because it'll take 30 minutes to start up is no big deal - I only do that once a day anyway." In fact, one of the things I look for in a set of development tools is portability. I don't want to get stuck loving an environment that only runs on one OS and only produces code for a couple of CPUs...)
-
I am using eclipse professionally on large software projects. When I say large I mean really large, not measly binaries with just a few tens of MBs, and it works just great. Same goes when I use it for small hobby LPCXpresso M0 hobby projects on a low end 11" Macbook Air.
Yep. YMMV. I've often found that people who use Eclipse on embedded projects think it works great because they don't have anything to compare it to.
The old people-that-disagree-with-me-must-be-ignorant.
-
The old people-that-disagree-with-me-must-be-ignorant.
More like "this TV is so old I no longer notice that grass looks orange when I watch football games".
-
IMHO Microchip really shot themselves in the foot by making a proprietary GCC for their PIC32 microcontrollers because they will always be behind with the mainstream GCC development.
And that's why I'm using vanilla MIPS GCC for PIC32. I used also GCC from MPIDE. Both normally usable compilers.
MIPS is well established platform and GCC compiler for it has a long history.
-
I have been trying DS-5 for a while.
How does the royal shiznit compare to the open source militia?
-
IMHO Microchip really shot themselves in the foot by making a proprietary GCC for their PIC32 microcontrollers because they will always be behind with the mainstream GCC development. GCC for ARM (maintained by ARM!) is much more up to date and the latest upgrade I did resulted in a healthy improvement of code density.
...instead of making MIPS32/64 support first-tier in gcc to begin with. :-//
-
For a hobbyist, the biggest Microchip shortcoming is the lack of good, cheap development hardware. The PICKit 3 is relatively cheap at $48, but it's not good (it's slowwwwwwww). The next step up the line is the ICD-3, which is about as fast as an ST-Link/V2, but it's $200.
I have both and don't see any speed difference; for small projects it's all dominated by MPLABX having to run its Java 200MB bloatware helpers.
-
The old people-that-disagree-with-me-must-be-ignorant.
More like "this TV is so old I no longer notice that grass looks orange when I watch football games".
Or too old to have an app for that. (Read: predates TVs with dual-core 1.5GHz Cortex-A's/MIPS64 with gigabytes or RAM and NAND flash, ethernet, wifi, and running embedded Linux systems that take hours to cross-compile. And days if not weeks to get to properly build and DHCP boot with X509 certs and whatnot. With video pipelines capable of 4k scaling and compositing...)
-
It may takes a few hours, but clearly not day or weeks to build an embedded linux with all the thing you cited.
I may even takes less than one hour if it's done correctly.
-
It may takes a few hours, but clearly not day or weeks to build an embedded linux with all the thing you cited.
I may even takes less than one hour if it's done correctly.
Yeah, but figuring out how to do it correctly can take that long. Especially parts where you have to install keys in the chip for the boot loader to be able to boot even an unencrypted image in the first place. I'm under NDA gag so can't name names (and shouldn't really mention this much either), but it's very easy to brick these devices if you're not careful. The reference systems used for development are fairly expensive (five figures per unit) and in very sparse supply and/or long delivery times, so if you brick one it needs to go back to the chip maker. The last time a junior engineer did this and we got it back it looked decidedly reflowed, so my guess is they swap out the main monolithic system SoC BGA. (They also set it up for this engineer's keys while at it to save the risk of having to do it again.)
-
It may takes a few hours, but clearly not day or weeks to build an embedded linux with all the thing you cited.
I may even takes less than one hour if it's done correctly.
Yeah, but figuring out how to do it correctly can take that long. Especially parts where you have to install keys in the chip for the boot loader to be able to boot even an unencrypted image in the first place. I'm under NDA gag so can't name names (and shouldn't really mention this much either), but it's very easy to brick these devices if you're not careful. The reference systems used for development are fairly expensive (five figures per unit) and in very sparse supply and/or long delivery times, so if you brick one it needs to go back to the chip maker. The last time a junior engineer did this and we got it back it looked decidedly reflowed, so my guess is they swap out the main monolithic system SoC BGA. (They also set it up for this engineer's keys while at it to save the risk of having to do it again.)
Oh yes I completely understand that, it's not as critical as it was possible to recover, but on the OMAP3 line for exemple, booting from an SD or eMMC chip, a wrong step on the /boot partition and your device is basically bricked :) (and the OMAP3 bootrom is particularly picky on that partition.)
And yes, even complex ARM chip with encrypted boot sequence, just take any microcontroler with (e)Fuse with some that could lock the chip JTAG, if you burn it mistakely, and still need jtag, you chip is good for the trash.. :D
-
For a hobbyist, the biggest Microchip shortcoming is the lack of good, cheap development hardware. The PICKit 3 is relatively cheap at $48, but it's not good (it's slowwwwwwww). The next step up the line is the ICD-3, which is about as fast as an ST-Link/V2, but it's $200.
I have both and don't see any speed difference; for small projects it's all dominated by MPLABX having to run its Java 200MB bloatware helpers.
Then count yourself as lucky. I see a huge difference speed-wise between the PICkit-3 and the ICD-3. The PICkit-3 is unusable for debugging on a PIC32 while an ICD-3 is reasonably responsive (although not as fast as an ST-LINK/V2 or Segger J-Link on an ARM using CrossWorks).
-
By the way, is there anyone having an experience with the Rowley CrossConnect?
-
By the way, is there anyone having an experience with the Rowley CrossConnect?
I don't have personal experience with it, but as far as I know it's the only debugger currently capable of debugging both cores of an LPC43xx under CrossWorks.
-
I've been using a CrossConnect with STM32 for the last couple of years.
It works fine, but so does an ST-LinkV2. There's really nothing to choose between them, other than about £300.
-
CrossConnect cost only $150 when buying a new license ^^ (Or you can say that by buying the CrossConnect you also get a non commercial licence of CrossWorks ;))
-
By the way, is there anyone having an experience with the Rowley CrossConnect?
Haven't compared for some time, but I found a Cross Connect substantially quicker on largish downloads than a J link using standard JTAG on LPC2k devices.
Not noticed much difference using SWD on STM32.
sca
-
So what is the industry standard IDE for ARM MCUs today? I mean, what the professionals use for designing products.
Keil and IAR. Both of these are in the USD$4-5K range, however, so they are not used much by hobbyists unless the code size limitation imposed by the free versions isn't an issue.
So when I want a free tool to begin learning ARM in order to get into it to work in that field in the future... what is the suitable IDE? what is the route to be taken?
-
Have a look at Atollic True Studio; I believe the code size limit on the free version has been recently removed.
-
Rowley CrossWorks is also an IDE to be evaluated, the "free" version is for non commercial and size limited, but that give a really good view of what the IDE is capable of (it clearly inspired from VisualStudio, and it's done quite correctly) and the non commercial license is really cheap ($150) even the commercial one is cheap ($1500) when you compare with other commercial solutions.
-
But then you want to reuse your code on an MSP430 and will end up paying another $1500.
-
But then you want to reuse your code on an MSP430 and will end up paying another $1500.
For a commercial user $1500 is a pittance. Not even worth discussing.
-
For a commercial user $1500 is a pittance.
It exceeds the limits for discretionary spending, therefore requiring approval (possibly through several layers of management), careful accounting of depreciation, and hopefully prior inclusion in this years budget. True, it is dwarfed by the cost of a programmer, and if it's known ahead of time to be required for a product design, it shouldn't be a significant part of the overall budget, but "pittance" is a bit of an understatement. (I spent about $1200 on a computer for work once. The CFO was NOT HAPPY with me.)
(and this gets even more complicated if you're a moderately large company, and have to start worrying about $1500 per seat instead of just $1500. Or a license complaince scheme that may or may not be compatible with your infrastructure or culture.)
I had this epiphany recently. A professional software or microcontroller developer is essentially indistinguishable from a hobbyist when presented with a brand new chip architecture. This hypothetical time period where your 6-figure-salaried expert gets to order half-a-dozen different "eval boards", each with their own development environment and $1500 price tag, so they spend a couple months figuring out which one is going to "best fit" the project? It doesn't usually exist. Chip selection is more likely to be made based on "prior experience" (corporate or individual.) So a manufacturer needs to get a $30 eval board with free development tools to the people who might use them well before product development starts. So that they can buy it from petty cash, or with their own funds, and when the NEXT product cycle comes along they might think "I was playing with X using the Y IDE and it was pretty neat; add it to the list of "possibles.""
-
I'd go with 'irrelevant' rather than 'pittance'.
When was the last time you ported a project from an ARM CPU to an MSP430?
How, if at all, did the possible future need to port to MSP430 affect your choice of ARM tools?
-
I'd go with 'irrelevant' rather than 'pittance'.
When was the last time you ported a project from an ARM CPU to an MSP430?
How, if at all, did the possible future need to port to MSP430 affect your choice of ARM tools?
Using different IDEs (and compilers) will result in a different context.. like porta.bit0 vs porta_bit0 or anything similar (you get the idea :-+). How is this solved? If I used GCC with Eclipse, it will be the same context so I won't need to do "porting"?
This is one of the reason one is confused about when dealing with ARM-MCUs. However, MPLab X + XC8 is always the standard with PICs except for those who use other compilers (which they need to deal with it).
-
"Using different IDEs (and compilers) will result in a different context"
The compilers (and associated headers) may be the root cause of that.
-
Anything involving 'port A, bit 0' will be completely hardware specific anyway, and would need changing to target a new board with a new CPU regardless of the IDE.
-
Anything involving 'port A, bit 0' will be completely hardware specific anyway, and would need changing to target a new board with a new CPU regardless of the IDE.
First of all that kind of code is 0.01% of the total firmware. Secondly it is a good idea to wrap settings bits in macros (like I do) so porting a piece of code (even if it is bitbanging I2C) is easy because only the macros need to be changed.
-
First of all that kind of code is 0.01% of the total firmware. Secondly it is a good idea to wrap settings bits in macros (like I do) so porting a piece of code (even if it is bitbanging I2C) is easy because only the macros need to be changed.
0.1%? That's strictly depends on your code, and would not assume that for all possible project. And even in C code is generally quite difficult to port from one microcontroller to another, and for various reason, the hardware could behave really differently, does not have the same memory constraint etc..
-
And even in C code is generally quite difficult to port from one microcontroller to another, and for various reason, the hardware could behave really differently, does not have the same memory constraint etc..
Code interacting with peripherals obviously takes serious effort to port. If the rest of your C code is hard you must be doing something wrong. Even when you need to deal with the unpleasantness of something like an 8051 core, and a mass of variables with poorly defined word lengths, it shouldn't be that hard.
-
And even in C code is generally quite difficult to port from one microcontroller to another, and for various reason, the hardware could behave really differently, does not have the same memory constraint etc..
Code interacting with peripherals obviously takes serious effort to port. If the rest of your C code is hard you must be doing something wrong. Even when you need to deal with the unpleasantness of something like an 8051 core, and a mass of variables with poorly defined word lengths, it shouldn't be that hard.
Actually it isn't that hard. I'm still using the UART interrupt routines/buffering/API I developed on the 8051 initially. Since then it has been ported to many other microcontrollers. UARTs, timers, SPI, I2C, etc interfaces all do the same function no matter what microcontroller they are in so porting their control software isn't that hard either.
-
"Using different IDEs (and compilers) will result in a different context"
The compilers (and associated headers) may be the root cause of that.
Well, I meant the exact same microcontroller but with different compiler... like PICC vs XC8 for PIC MCUs. Is that the case for ARM MCUs too?
when you develop a project using an ARM MCU like Renesas or STM32, do you _always_ use a dev board then use the specific MCU with your own board? or do you put the MCU itself on a breadboard (I know you need to put it on a PCB to do that) and start programming it directly? I still find getting started in ARM foggy xD.
Anyway, maybe you missed Mikro C PRO for ARM (http://www.mikroe.com/mikroc/arm/ide/ (http://www.mikroe.com/mikroc/arm/ide/)). It is 300$ and full-featured. Did anyone use it? I really don't aid using a third-party tool for these stuff.. especially that you will be forced to use their own debugger rather than a normal one.
-
I had this epiphany recently. A professional software or microcontroller developer is essentially indistinguishable from a hobbyist when presented with a brand new chip architecture. This hypothetical time period where your 6-figure-salaried expert gets to order half-a-dozen different "eval boards", each with their own development environment and $1500 price tag,
Professional users most likely are already using Keil or IAR and these tools support pretty much all of the ARM variants on the market, so there's no $1500 cost to evaluate each chip vendor's parts. The most expensive ARM development board I've seen is around $300, and that's the exception rather than the rule. Most simple boards are less than $100, sometimes much lower.
When we do evals here before deciding on a particular ARM MCU, we start by reviewing data sheets and can rule out the majority of the contenders on that basis alone. Once we've whittled the list down to the top prospects, we only need to buy 2-3 eval boards to test at that level.
I stand by my opinion that $1500 for a development license is a pittance. I don't know where you live, but in my area the burdened cost of an embedded developer is ~$150/hr. That's $6000 a week, or 4x the cost of a $1500 license. One can easy burn through several times the cost of a license arguing the details in a meeting. If your CFO is making your engineers jump through hoops justifying expenses such as this, then he's penny wise and pound foolish.
-
And yet I have never worked for a company (several with multi-million turnovers) where we (the firmware engineers) used paid compilers. During the past 25 years I have used Keil's uVision, IARs workbench, Analog Devices dev.... yadda yadda, Freescale's Codewarrior, etc only in very rare occassions where an existing project needed some quick hacking. The reason: all those IDEs suck big time and offer no increase in productivity. Notepads with a compile button stuck on them. Nice to get blinky projects going quickly but for real programming work? No thanks! Also: if a manufacturer wants me to use their chips they should provide a good compiler for free. Otherwise I just say NEXT! Some salesmen still hate me and co-workers for that. Take that $1500 figure and divide that by a production run of 1000 pieces. Suddenly the price of the BOM goes up by $1.50. Or that $1500 can also go towards buying a piece of test equipment or pay someone's salary for a week or more. Multiply that $1500 by several seats and suddenly it makes sense to standarise development around a fixed set of tools and look for solutions which fit into that model seamlessly. It is easy to say the $1500 gets dwarfed by other expenses but that still doesn't mean it is money well spend. Usually it isn't when it comes to microcontroller IDEs because they are not the core business of compiler makers.
-
And yet I have never worked for a company (several with multi-million turnovers) where we (the firmware engineers) used paid compilers. During the past 25 years I have used Keil's uVision, IARs workbench, Analog Devices dev.... yadda yadda, Freescale's Codewarrior, etc only in very rare occassions where an existing project needed some quick hacking. The reason: all those IDEs suck big time and offer no increase in productivity. Notepads with a compile button stuck on them. Nice to get blinky projects going quickly but for real programming work? No thanks!
My experience is opposite yours. I've worked in companies that exclusively used tools like Kiel and IAR because these tools come with support and a phone number to call. We've always gotten excellent support from these companies that helps us quickly get past issues that would otherwise take lots of time to solve. What happens if you have an issue with GCC? Who are you going to call? Richard Stallman?
I personally have found IDEs very useful and would never go back to the days of using a compiler with Make, Emacs, and GDB. Sure, all IDEs suck in some way (some more than others), but overall I've found the productivity to be worth it.
-
Using the price of a licence to the BOM cost of a product is silly. You device will not be the only one you'll make using that software.this is clearly not something which is related to the BOM cost of a product...
And even $1.5 unless you make <$10 product is just.. nothing..
I really hate people that don't want to reduce their margin for even a penny just to add an important feature.. Been there in the past where they didn't wanted to add a gas gauge to track battery charge, the result is a device that have an absolutely shitty battery level indicator, because as we all know, voltage is NOT an accurate information.
-
I personally have found IDEs very useful and would never go back to the days of using a compiler with Make, Emacs, and GDB. Sure, all IDEs suck in some way (some more than others), but overall I've found the productivity to be worth it.
so you suggest/recommend any beginner in ARM MCUs to just go with Keil from the start and build his experience using it?
For me, I consider buying an STM32 discovery board to learn ARM MCUs, there is an IDE by ST that is good according to what I read. What to do?
-
You could also go to the TI launchpad, especially the Tiva/Stellaris one, you can either use the Energia environment which is basically the same as the arduino, the IDE provided by TI or any other tools. I do like the LaunchPad board to be honest, and there are a lot of variants like one with Ethernet
And don't be fooled by the arduino environment, as its in fact C/C++ programming
-
I personally have found IDEs very useful and would never go back to the days of using a compiler with Make, Emacs, and GDB. Sure, all IDEs suck in some way (some more than others), but overall I've found the productivity to be worth it.
so you suggest/recommend any beginner in ARM MCUs to just go with Keil from the start and build his experience using it?
For me, I consider buying an STM32 discovery board to learn ARM MCUs, there is an IDE by ST that is good according to what I read. What to do?
Take this free course (https://www.eevblog.com/forum/beginners/free-course-ut-6-03x-embedded-systems-on-edx-starting-now/). If you're an experieinced coder it will start out a little slow but it quickly picks up. It will teach you ARM. It uses the TI Tiva C launchpad and Keil.
-
I personally have found IDEs very useful and would never go back to the days of using a compiler with Make, Emacs, and GDB. Sure, all IDEs suck in some way (some more than others), but overall I've found the productivity to be worth it.
so you suggest/recommend any beginner in ARM MCUs to just go with Keil from the start and build his experience using it?
For me, I consider buying an STM32 discovery board to learn ARM MCUs, there is an IDE by ST that is good according to what I read. What to do?
Take this free course (https://www.eevblog.com/forum/beginners/free-course-ut-6-03x-embedded-systems-on-edx-starting-now/). If you're an experieinced coder it will start out a little slow but it quickly picks up. It will teach you ARM. It uses the TI Tiva C launchpad and Keil.
Oh the MOOC from UT, I enjoyed it a lot, was really fun, even if not really needed in my case.. :)
-
so you suggest/recommend any beginner in ARM MCUs to just go with Keil from the start and build his experience using it?
For me, I consider buying an STM32 discovery board to learn ARM MCUs, there is an IDE by ST that is good according to what I read. What to do?
Yes, if you were developing a commercial product using an STM32 and had the budget I would recommend you go with Keil or IAR. If you're a hobbyist wanting to learn STM32 then of course I would not recommend either (although both do offer free versions restricted to, I think, 32K of code).
I'd recommend something free, and the two free choices that don't impose code size restrictions that come to mind are Atollic TrueStudio and EmBitz.
-
"Well, I meant the exact same microcontroller but with different compiler... like PICC vs XC8 fo"
The use of macros obviously depends on the compilers used. However, there are ways around that so you can write code independent (to a large extend) of compilers used.
-
And yet I have never worked for a company (several with multi-million turnovers) where we (the firmware engineers) used paid compilers. During the past 25 years I have used Keil's uVision, IARs workbench, Analog Devices dev.... yadda yadda, Freescale's Codewarrior, etc only in very rare
My experience is opposite yours. I've worked in companies that exclusively used tools like Kiel and IAR because these tools come with support and a phone number to call. We've always gotten excellent support from these companies that helps us quickly get past issues that would otherwise take lots of time to solve. What happens if you have an issue with GCC? Who are you going to call? Richard Stallman?
I personally have found IDEs very useful and would never go back to the days of using a compiler with Make, Emacs, and GDB. Sure, all IDEs suck in some way (some more than others), but overall I've found the productivity to be worth it.
I never said IDEs are useless in general. It's just that if you want to use an IDE you need to get a serious IDE which is made by a company which has a core business of making IDEs and preferably standarise around that.
BTW: I can't remember asking a question to a support department which lead to an answer on the same day. Usually it takes days to weeks to get answers to the kind of problems I run into.
-
"when you develop a project using an ARM MCU like Renesas or STM32, do you _always_ use a dev board then use the specific MCU with your own board?"
My code is generally not developed on the target it runs on eventually. In most cases, the code is developed with no specific target in mind.
The choice of the target depends on many factors, sourcing decisions, upgradability, client considerations, manufacturing capabilities of the fabrication shops, ....
Generally, you get a development board with the biggest and baddest chip and rebudget once the code has stabilized.
-
For ide choices, you have to ask yourself "who am i"
If you make a living as an embedded engineer, I would say that you are nuts picking anything out of proven vendors like keil or iar. The support is invaluable as every minute you spend waiting for a bug fix is a minute you cannot make money on. Not to mention the "buy IBM" factor.
If you are a hobbyist coding for small projects, it would be crazy for you to buy a commercial license on keil or iar.
Life gets messier if you are somewhere in between.
So end of the day, don't ask what people use, but ask them why they use what they use so you can see if it makes sense for you to follow their decisions.
Hope it helps.
-
I will not approve such a way, at least for software development, that's how computer today for basic stuff needs a CPU 1000x more powerful that 30 years ago, to basically do the same thing.
There are some domain where I may say yes that 's a solution, but for micro controller "generic" code is rarely a good one.
-
so you suggest/recommend any beginner in ARM MCUs to just go with Keil from the start and build his experience using it?
For me, I consider buying an STM32 discovery board to learn ARM MCUs, there is an IDE by ST that is good according to what I read. What to do?
Yes, if you were developing a commercial product using an STM32 and had the budget I would recommend you go with Keil or IAR. If you're a hobbyist wanting to learn STM32 then of course I would not recommend either (although both do offer free versions restricted to, I think, 32K of code).
I'd recommend something free, and the two free choices that don't impose code size restrictions that come to mind are Atollic TrueStudio and EmBitz.
Well, I will follow your advice and use a free tool when learning STM32 that I think ST provide (based on eclipse I guess). However, when companies hire embedded engineers, will they consider someone who hasn't used Keil/IAR and kept using free tools. How about their compilers?
Different compilers leads to different syntax and stuff like people argued above. So I can not use the code I wrote for, say STM23 or one of their disco boards, when making the actual product unless I go in and re-write many parts of it to suite the new compiler or MCU itself. I still wonder about development of products (based on ARM MCUs) if they breadboard the target MCU (after soldering it on a small PCB) on a breadboard and do stuff like us PIC guys do, or they _always_ get a dev board and build everything around it then get the mcu that was on it and download the program.
So, from what I read, most of you recommend starting up with one of the free tools build around eclipse (manufacturer's own IDEs)... then go for Keil when having some experience. I hope I got it right xD.
-
There are some domain where I may say yes that 's a solution, but for micro controller "generic" code is rarely a good one.
That is old school thinking!! Nowadays a product containing a microcontroller needs 5% of time spend on hardware and 95% on the firmware. In other words: the firmware gets more complex and needing to start from scratch for every product is a no go. Software has become a major asset of any company involved in software development so like any asset this needs carefull consideration and 'nursing'.
Over a decade ago I was in a conference call with a company who made DSP solutions. The company I worked for wanted to use their IP. During that conference call it turned out the software was all written in assembly for a DSP which was about to become obsolete and worse: Motorola wasn't going anywhere with their DSPs so the software got kinda stuck between a rock and a hard place needing a massive amount of work to port it. If the software engineers had written the software in a more portable language/way they could have switched DSP suppliers more easely and create cost savings in their products by using cheaper DSPs. Their initial boards would have been more expensive but the development time would have been less and the value of the investment in the software would not have to be written off so quickly because it would be possible to use more powerfull and cheaper DSPs.
-
Over a decade ago I was in a conference call with a company who made DSP solutions. The company I worked for wanted to use their IP. During that conference call it turned out the software was all written in assembly for a DSP which was about to become obsolete and worse: Motorola wasn't going anywhere with their DSPs so the software got kinda stuck between a rock and a hard place needing a massive amount of work to port it. If the software engineers had written the software in a more portable language/way they could have switched DSP suppliers more easely and create cost savings in their products by using cheaper DSPs. Their initial boards would have been more expensive but the development time would have been less and the value of the investment in the software would not have to be written off so quickly because it would be possible to use more powerfull and cheaper DSPs.
Also over a decade ago I was exactly on the same boat: trying to convince several of my customers to shield themselves against obsolescence, while trying to break their resistance to start using real-time kernels. Some moved on, some didn't.
-
My experience is opposite yours. I've worked in companies that exclusively used tools like Kiel and IAR because these tools come with support and a phone number to call. We've always gotten excellent support from these companies that helps us quickly get past issues that would otherwise take lots of time to solve. What happens if you have an issue with GCC? Who are you going to call? Richard Stallman?
If you're getting helpful responses from telephone support for mcu-related technology, you're probably asking very basic questions that an experienced engineer should probably solve on his/her own.
And if the main point of getting on the phone with a vendor is to prove to them (with 'scope traces and/or assembly dumps) that their magic $1k/seat proprietary fairy dust is perhaps seriously broken and not deserving of renewal in a few months, and that you're on the brink of telling management to junk this project and start over with a different mcu/compiler/debug probe, then maybe there isn't so much value in that phone call after all.
-
If you're getting helpful responses from telephone support for mcu-related technology, you're probably asking very basic questions that an experienced engineer should probably solve on his/her own.
Nope. We ask difficult questions and we get helpful responses from the vendors. Maybe it's just because we know who to talk to.
-
Question semi-related to this....
If I'm doing my programming on a Teensy 3.2 (MK20DX256, Cortex M4) using the 'stock' Arduino environment, but incorporating more and more C as I learn the MCU better over time, does that 'count' as an ARM development environment in the same vein as Keil, CooCox,etc.?
-
If you're getting helpful responses from telephone support for mcu-related technology, you're probably asking very basic questions that an experienced engineer should probably solve on his/her own.
Nope. We ask difficult questions and we get helpful responses from the vendors. Maybe it's just because we know who to talk to.
Every question is difficult in the eyes of the person who is seeking for it's answer >:D
-
Well, I will follow your advice and use a free tool when learning STM32 that I think ST provide (based on eclipse I guess). However, when companies hire embedded engineers, will they consider someone who hasn't used Keil/IAR and kept using free tools. How about their compilers?
Not that my company is very "standard", but you'd get extra points for knowing the free tools, as that's what we're using for development and production.
gcc + gdb + openocd are the tools for us, and each developer gets to choose how they (or don't) wrap them with IDEs and whatnot.
SCM/RCS is done in git, since we're living in 2016 these days. :)
And anyone that says that you'll save time by using Keil or IAR are straight up misinformed.
Actual example, shipping product, wearables segment:
Full rebuild time in IAR: 20 minutes
Full rebuild time with GCC in Linux: ~35 seconds
How many times a day are your developers compiling their code? Multiply that with the speedup you'd get by switching to something like gcc in Linux, and you'll come up with some pretty interesting figures...
And, if that doesn't convince you.
We're currently developing products based on the following MCUs:
Nordic nRF51822, STM32F103, TI CC3300
Guess what? We didn't have to change a thing in our environment when developers switch between projects. Same compiler, same debugger, same jtag software+hardware.. The time saved in getting a developer started is staggering.
-
Full rebuild time in IAR: 20 minutes
Full rebuild time with GCC in Linux: ~35 seconds
Are you sure you have IAR configured properly? We use IAR and for an application that nearly fills a Cortex-M4 with 512K of FLASH a full build takes less than a minute. IAR v7.40 is much faster at building than earlier versions were.
-
Question semi-related to this....
If I'm doing my programming on a Teensy 3.2 (MK20DX256, Cortex M4) using the 'stock' Arduino environment, but incorporating more and more C as I learn the MCU better over time, does that 'count' as an ARM development environment in the same vein as Keil, CooCox,etc.?
The main difference is that the Arduino "IDE" doesn't support debugging.
-
I found a cool project called CudaText which could easily replace Eclipse if you are willing to do some minor mods. I am (or plan to soon) be setting this up for Astrobe Oberon, which is an Oberon compiler for the LPCxxx family chips (ARM 3/4/5). Granted, the Oberon compiler is MUCH simpler to deal with as far as compilers go, it appears that rigging up any other compiler would be rather strait forward.
CudaText is amazingly fast. Eclipse takes ages to load on my Win7. Cuda opens at the blink of an eye. Quite impressive. It is just all around awesome. I am very impressed at the quality feel of this opensource project. It is a port of 'SynWrite' from Delphi to Lazarus. In fact, SynWrite is also available and has quite a few more features still not ported over. SynWrite perfoms much better than Eclipse but not blazing fast like Cuda.
Also, compare the download sizes:
SynWrite = 13mb
CudaText = <8mb
Eclipse = 166mb
http://wiki.freepascal.org/CudaText (http://wiki.freepascal.org/CudaText)
http://sourceforge.net/projects/synwrite/ (http://sourceforge.net/projects/synwrite/)
-
There is little use in comparing IDE sizes without looking at how complete the IDE is. Sure Eclipse is large but it has a huge amount of functions and caters to the professional programmers! CudaText OTOH seems to be nothing more than a glorified notepad with a compile button stuck on it so there really is no way to compare it with a package Eclipse.
-
My favorite editor is sublime, bar none.
It, and editors like notepad+, are nothing more than a gui presentation of the cmd line. For some reason, our experts have a grand fear for them as well.
-
My favorite editor is sublime, bar none.
Tried it time ago on a Mac and couldn't figure out how to print. Was this solved since then? I may give it another try.
-
My favorite editor is sublime, bar none.
Tried it time ago on a Mac and couldn't figure out how to print. Was this solved since then? I may give it another try.
Print? On actual paper?
:-DD
-
My favorite editor is sublime, bar none.
Tried it time ago on a Mac and couldn't figure out how to print. Was this solved since then? I may give it another try.
SublimeText does not provide printing that's true
-
Just to clarify, I really like the look and feel of Eclipse. I like its window layout and I like its editor. I like just about everything about it except its performance. That's always the stumbling block for me. It just feels so sluggish and unresponsive after using something like CrossWorks.
On Windows or Linux? Eclipse tends to be rather slow on Windows. When using Eclipse on Linux I get sub-second compile times on my machine for reasonably sized projects including a USB device stack.
Okay, time to regroup and rethink this Eclipse performance issue...
Up to now, I've tried various embedded toolchains based on Eclipse, including LPCXpresso (and CodeRed before that) and Atollic TrueStudio. In every case I was disappointed by the sluggish performance downloading code to boards and especially by the sluggishness when single-stepping code in the debugger.
Today I got a Freescale K64F Freedom board and downloaded Kinetis Design Studio to try it out. Since KDS is based on Eclipse I wasn't expecting much and figured I'd see the same dismal performance I've seen with all other Eclipse-based tools I've tried. I couldn't have been more wrong. KDS downloads code to the board and steps just as fast as my gold standard for performance, Rowley CrossWorks. It's very response and it doesn't get in my way while editing and debugging code.
So now I'm convinced--Eclipse can perform well. What I still don't understand, however, is why TrueStudio and LPCXpresso perform so poorly on the same machine. Is it their configuration, or perhaps their developers didn't bother to optimize anything? :-// The difference is like night and day: stepping code in TrueStudio takes 1-2 seconds per step; in KDS it's instantaneous.
-
So now I'm convinced--Eclipse can perform well. What I still don't understand, however, is why TrueStudio and LPCXpresso perform so poorly on the same machine. Is it their configuration, or perhaps their developers didn't bother to optimize anything? :-// The difference is like night and day: stepping code in TrueStudio takes 1-2 seconds per step; in KDS it's instantaneous.
I've always assumed that the problem is trying to provide an agnostic API to hardware debuggers and programmers which require low level system programming, something that Java simply isn't designed for. Either you use JNI or shell out an external program and use RPC. JNI should be fast as it's synchronous but requires closely coupled platform-specific code, whereas shelling out + RPC is easy but usually asynchronous and therefore sloooow particularly if the RPC API is chatty.
-
So now I'm convinced--Eclipse can perform well. What I still don't understand, however, is why TrueStudio and LPCXpresso perform so poorly on the same machine. Is it their configuration, or perhaps their developers didn't bother to optimize anything? :-// The difference is like night and day: stepping code in TrueStudio takes 1-2 seconds per step; in KDS it's instantaneous.
Eclipse just provides the basic IDE framework, to get C/C++ environment there is an extra set of plugins. Then for embedded, there is another set of plugins, then for vendor specific stuff and debugging, there are more plugins... so the quality depends on how good the plugin writers are.
KDS comes from Somnium who seem to know their stuff.
-
Okay, time to regroup and rethink this Eclipse performance issue...
Up to now, I've tried various embedded toolchains based on Eclipse, including LPCXpresso (and CodeRed before that) and Atollic TrueStudio. In every case I was disappointed by the sluggish performance downloading code to boards and especially by the sluggishness when single-stepping code in the debugger.
Several implementations that use Eclipse as a debugger usually use GDB as a middleware that talks to the low-level JTAG device drivers. The early instances of the combination Eclipse+GDB used to impose a large performance impact, thus making several integrators/vendors to create their own debugger Eclipse plugins. In these cases bottlenecks can be either from the Eclipse/proprietary debugger integration or from the low-level JTAG drivers.
For the ones that still use GDB, what matters is the performance of the JTAG device drivers themselves. This allows me to run GDB from the command line and find out in most cases the issue is independent on the IDE.
All in all, it is entirely due to the integrator/vendor to properly optimize their stuff.
-
For the ones that still use GDB, what matters is the performance of the JTAG device drivers themselves. This allows me to run GDB from the command line and find out in most cases the issue is independent on the IDE.
In my experience, Segger JTAG drivers are the fastest, usually by a wide margin.
-
You could also go to the TI launchpad, especially the Tiva/Stellaris one, you can either use the Energia environment which is basically the same as the arduino, the IDE provided by TI or any other tools. I do like the LaunchPad board to be honest, and there are a lot of variants like one with Ethernet
And don't be fooled by the arduino environment, as its in fact C/C++ programming
+1 for using the Tiva C, I have one and I love it!
-
Nice story!
I have the opposite. I never get used to that ridicules Crosswork layout.
I also use Embitz and the windows are not floating (once you docked them somewhere in your main window). I use Embitz mainly because of all the debugger features, once you are used to have live variables and memory views you can't easily switch back to some IDE without this feature. It saves me a lot of time.
-
it does 16 full loops under 30 seconds (each loop has 4 steps). So that is over two steps per second.
Mind I did not state the are no faster stepping IDEs but OP's 2s sounds impossible (or OP has messed up something badly with setup).
OP here... If something in my setup is messed up, then it's the fault of the IDE vendor because this happens on a default install of the tool with no modifications done to the setup by me.
The stepping speed you quote is nothing to brag about. Two steps per second is still 1/2 second per step, which is crawling. Rowley CrossWorks can easily do >10 steps per second with an ST-Link/V2.
Are you talking about single stepping or running and waiting to hit a breakpoint?
If it's single stepping I'm not sure how you press the step button that fast.
If its running to a breakpoint it should be really fast, I haven't noticed any problematic speed issues with Eclipse while remote debugging. easily >10 steps per second.
-
If its running to a breakpoint it should be really fast
I have tried it with single HLL step (one C line, not one asm op-code), just pressed F6 down firmly.
The st-link v2 has a 1800kHz clock (max) so there should not be a significant difference between Keil or OpenOCD + Eclipse. The difference might be that at each step an IDE and debugger has to interrogate target. The only thing that has to be made is to read PC, then move breakpoint to next position and then continue when doing such fast stepping. All the other stuff like reading IO registers or flash/sram is necessary only when an IDE needs to update ALL views (which is not needed when doing fast stepping).
So perhaps here lies the difference.
10 steps per second sounds really great, my setup does only 2 per second (which is still ok for me).
-
I also use Embitz
I'm their biggest fan since their beta days - still use EmBlocks beta 1.0 today. It is my go-to IDE for PIC24.
For most of playing around ST's ARM offerings, I use CoIDE (1.x). Love how it sets up the project for you effortlessly.
-
I'm leaving Windows and EmBitz is one of the few applications I'm missing very much. No alternatives on Linux. I'm using KDS but it is soo biiigggg.