How do you choose the best embedded software development tool for your project?

Yes, before selecting the tools for the job, it is paramount to have the project/product requirements defined e.g. Functional safety (IEC 61508) etc. It is also important to consider the teams abilities and past experience. Selecting a tool that you have no experience with will inevitably increase development time and cost. Again, consider your project requirements!

It?is?determined?by?the?kind?and?type?of?the?project. First,?determine?how?many?resources?or?components?are?needed?for?the?project,?as?well?as?its?feasibility,?such?as?if?it?will?function?with?bare?metal?code?or?whether?it?will?require?an?operating?system,?or?whether?it?will?execute?crucial?activities?that?require?a?real-time?operating?system.

Before selecting the tool one should consider knowing about the target system, the kind of the controllers and testing methods are to be taken into consideration along with the standards being followed, such as MISRA C, Functional safety for automotive etc. which changes according to the domain of the product. This also includes alot of aspects from the management team for the costing and depends on the project requirements from the client as well, which keeps on changing after discussions and after bringing a clarity from the devlopment and testing team until it is fixed. So, basically list of these background researches will bring you down to the requirements of the tools on basis of these you would be choosing the tools for the project.

I partially agree with this section. In few words: - Take time to know your product well - Take time to know your team well - Take time to know your time and money well It might look simple, but it's not, and I know several projects start with a few of those requirements defined.

When selecting software tool sets for your project, consider the skillset of your team. Opt for proven, reliable solutions that match their expertise. Experimentation provides clarity on suitability. Also, assess the tool developer’s customer base to gauge their track record and industry fit. Involve team members and management, especially for costly tools, to gauge adoption potential and engage with the support and sales teams for insights on long-term support and enhancements.

This is a general fundamental that before selecting any tool we need to compare pros and cons of that. While we should focus on different areas and use cases according to we can have a list of tools then we can compare and use it. E.g. Editor for development: Command line editor as vim GUI editor as visual studio code, sublime or notepad++ IDE as eclipse for complete development and debugging To build/compile the source code: Need native/cross-compile/other tool chain support Server for source code: Local machine, Gerrit, GitHub, bitbucket Tracking the development: Jira, trello Build system: Yocto, Build root, AOSP

I have a different approach for this, I don't think - for embedded systems - we need to compare the tools. There are many cases that you can't really choose. When you use a hardware (sometimes it's a hard requirement), you will be wise to use the BSP provided by the vendor or provided by some other company you really trust. But I want to bring a different approach, as I said. Instead of comparing different tools you don't know. Think about comparing partners you can work with. Working with embedded systems can be really complex, and knowing from different areas sometimes is not something you want for your team (do they really need to spend time learning yocto if they are supposed to be working with the wifi driver? or the product's GUI?).

I'm pretty sure the person who wrote this article, discussion is pretty much unaware that it's the compiler that's essential in embedded work to begin with. Basically nothing else. About the only thing you need (and it's just to save time) is a auto generator for the code of the chipset and selection of the various modules that you want for wiring purposes. (Unless you feel like crawling through a 700 page datasheet for hours). When it comes to organizing your project - the IDE is pretty irrelevant in my experience. It's folder and organization of the project that makes the tool 'work well' to begin with. This is why Linux (even though I work in windows myself - tends to be the preferred option in this type of work).

I think that before trying to distinguish between the different tools and comparing them, we should consider if we're doing a personal project or a commercial/customer bound project. In the latter case we're pretty much stuck with industry standards, customer requirements and many other constraints, so this leaves very little room for choosing the best tool, if any! On the other hand, if we're doing a personal project, I think we should strive to do the best we can to get a good product, especially if we're going to monetize the product and plan on scaling up in the future. We should also consider the team size (if there's one) and choose the appropriate tool.

Here we can consider two types of tool/application. For development and then second for customer use cases. For development we need to consider a complete software development life cycle and as a stage of SDLC select appropriate tools. To create a BSP for embedded systems we can use a build system like Yocto which provides almost all the required applications to run on the target machine/device. The main advantage of Yocto is we can have a customised and select application/tool as per requirement on the device.

Software development life cycle is the best under the process of development and then on each stage selection of tools. For all stages we can find open-source freeware tools, demo tools and then licensed tools. Once we are familiar with usage and advantage of tools then we can select the best tool for our system.

List out all the stages of development specially for embedded systems. Along with software we need to consider some hardware tools also, as in embedded system sometimes due to some missing part in hardware will misbehave during software development. List down all the tools for each stage along with usage, pros and cons. Select which fits best in your requirement and budget.

I've seen in so many companies that they always use DOORs for requirements trackability and traceability, and a very old version of it as well, which is not very convenient, if anything it slows down the process more than it benefits it. this proves the point that companies most of the time use industry standards with giving little concern to how costly this'll be for them. On the other hand I also see companies going all in on automation and abstraction (like using Bazel or any equivalent advanced build tool) to the point where the developer will only execute some tool to get the work done.

If you want to learn how to start with embedded systems, I prefer to begin bottom-up (instead of top-down, as the article says). I would start learning the Linux kernel. If you are a company working with a commercial product, I prefer to recommend a design house. They will help you to understand the requirements, help you choose the hardware, and mainly, help you with the software base. Not your software but the environment you need to have your software working on top of it. There are several great design houses all over the world. Pay attention to the Linux kernel mailing list to know them.

Some companies select expensive tool suites that include things like unit testing, static analysis, etc. all rolled up in one product. This unified solution sounds good in practice but reduces development flexibility and locks you down to dated tools if the project survives years or decades, which is actually pretty common. I recommend treating the development tools as modular blocks that make up your software development process. Define these blocks generically: -IDE -build tool(s) -Unit test tool -Static analysis too -build-automation/CI/CD tool -etc. Then select specific tools for these generic tools, for example Ctest for unit testing. When the tools selected no longer meet your needs-Swap it out!