The question is a little too broad. Usually, you use the toolchain the manufacturer of the chip is supplying. If it uses a compiler which supports a certain standard, you are lucky. If it uses some non-standard optimisations, you are less lucky. If the chip does not work without non-standard-at-all hacks... well, you already feel the frustration :-) . Same goes for larger embedded systems — you stick to the IDE/compiler supplied.
If you are already confident with the IDE, upon which the embedded IDE was built — everything works like a charm (well, mostly). Examples: Visual Studio, Eclipse, Netbeans; you install the IDE, than a plug-in for the toolchain, then you start/check out a project.
Of course, there are open source alternatives. They are of course very nice, but there is that painful problem of support. In the embedded/hardware-related industry, the time-to-market interval has the certain... rigor; hence, there is a real problem: if your open source compiler has a bug, who is going to fix it? If you have an experience with inner workings of that compiler — fine; if not — not fine.
This in turn makes the industry highly fragmented. Thus the problem of scripts/other making-life-easier utilities: they are seldom portable.
And in the world of FPGAs the binding to the tools of the manufacturer is even more evident. And yes, there are some device-independent tools, but the question is, whether they fully exploit the capabilities of the platform you are going to use.
If the picture I painted is gloomy: despair not! There are indeed certain standards: at the very least ANSI C in the world of MCUs (the tools for the 32-bit platforms tend to comply to rather recent standards, the tools for 16-bit and 8-bit MCUs... let's say, it's another story), VHDL and Verilog in the world of FPGAs. But, as example: where else could you use Tcl scripts for Quartus IDE, as the whole compilation process on another tool is rather different?
About the books: I found the books by Jack Ganssle rather helpful. If you use DSPs, there are many good books about Digital Signal Processing. If you adhere to statechart-based technologies, ... does not apply, it is high-level. If you work with RTOS (especially with µC/OS), look at µC/OS-II books. There are also good books about optimised algorithms: Hacker's Delight, Programming Pearls, and many others. Also, a very good (and free available) one: the FXT book.
I hope that I could satisfy your curiosity. Or, at the very least, I provided a starting point for a discussion.
I totally agree with Wincent about tools. Most of the times you need to follow the vendors toolsuite. Which at the end might not be so bad, as it save us some energy to make it work.
But you can always build up your setup (I mean choosing your IDE and integrate the call of the makefile in there...);
My experience goes only in MCU.
Just to complement, the post of Wincent, I would like to add the Verification tools. There I have been using Helix QAC, PC-Lint to ensure coding compliance with MISRA-C and PolySpace for run-time errors check. In few cases gtest was also useful, due to its faster setup and feedback. of course, I am talking about unit tests.
One side note, I am in the automotive market, and there all the people does nowadays are subject to techincal audits, to ensure the quality, with this means not much freedom left for open source tools.
At home, arduino, beaglebone and terminal from ubuntu is enough for me :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The question is a little too broad. Usually, you use the toolchain the manufacturer of the chip is supplying. If it uses a compiler which supports a certain standard, you are lucky. If it uses some non-standard optimisations, you are less lucky. If the chip does not work without non-standard-at-all hacks... well, you already feel the frustration :-) . Same goes for larger embedded systems — you stick to the IDE/compiler supplied.
If you are already confident with the IDE, upon which the embedded IDE was built — everything works like a charm (well, mostly). Examples: Visual Studio, Eclipse, Netbeans; you install the IDE, than a plug-in for the toolchain, then you start/check out a project.
Of course, there are open source alternatives. They are of course very nice, but there is that painful problem of support. In the embedded/hardware-related industry, the time-to-market interval has the certain... rigor; hence, there is a real problem: if your open source compiler has a bug, who is going to fix it? If you have an experience with inner workings of that compiler — fine; if not — not fine.
This in turn makes the industry highly fragmented. Thus the problem of scripts/other making-life-easier utilities: they are seldom portable.
And in the world of FPGAs the binding to the tools of the manufacturer is even more evident. And yes, there are some device-independent tools, but the question is, whether they fully exploit the capabilities of the platform you are going to use.
If the picture I painted is gloomy: despair not! There are indeed certain standards: at the very least ANSI C in the world of MCUs (the tools for the 32-bit platforms tend to comply to rather recent standards, the tools for 16-bit and 8-bit MCUs... let's say, it's another story), VHDL and Verilog in the world of FPGAs. But, as example: where else could you use Tcl scripts for Quartus IDE, as the whole compilation process on another tool is rather different?
About the books: I found the books by Jack Ganssle rather helpful. If you use DSPs, there are many good books about Digital Signal Processing. If you adhere to statechart-based technologies, ... does not apply, it is high-level. If you work with RTOS (especially with µC/OS), look at µC/OS-II books. There are also good books about optimised algorithms: Hacker's Delight, Programming Pearls, and many others. Also, a very good (and free available) one: the FXT book.
I hope that I could satisfy your curiosity. Or, at the very least, I provided a starting point for a discussion.
P.S.: Found this post here about using Docker for ARM-related development: dev.to/dalimay28/using-docker-for-...
P.P.S.: You should tag your posting with #discuss tag.
I totally agree with Wincent about tools. Most of the times you need to follow the vendors toolsuite. Which at the end might not be so bad, as it save us some energy to make it work.
But you can always build up your setup (I mean choosing your IDE and integrate the call of the makefile in there...);
My experience goes only in MCU.
Just to complement, the post of Wincent, I would like to add the Verification tools. There I have been using Helix QAC, PC-Lint to ensure coding compliance with MISRA-C and PolySpace for run-time errors check. In few cases gtest was also useful, due to its faster setup and feedback. of course, I am talking about unit tests.
One side note, I am in the automotive market, and there all the people does nowadays are subject to techincal audits, to ensure the quality, with this means not much freedom left for open source tools.
At home, arduino, beaglebone and terminal from ubuntu is enough for me :)