I wonder how looks integrating code for embdedded systems. Lets suppose there are 5 programmers and everyone is doing something different. Then I am supposed to integrate the code. How do I know if it should be RTOS or not, should I be provided with some kind of API, from the programmers, that refers to theirs code ? Should the code execute sequentially or should I implement multitasking ?

There are so many things to be managed and I got no idea what to start with ? Do you know any books that would introduce me to that subject ?


closed as primarily opinion-based by Keelan, PeterJ, Daniel Grillo, Vladimir Cravero, pjc50 Feb 5 '15 at 10:19

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ "How to manage a software project" is a huge subject. None of this is specific to embedded design, really. Microsoft's "Code Complete" has a chapter on integration that's highly reccomended. \$\endgroup\$ – pjc50 Feb 5 '15 at 10:22

How do 5 construction workers go about building a house? Do they simply build pieces independently and hope that the general contractor can fit the pieces together? Of course not. What really happens is an architect makes a blue print and the workers build to the specifications in the blue print to ensure the pieces fit together. For software, the system architect makes the system design and the developers build their pieces to fit the specifications of the design. The system design should include at least an overview of how the pieces will integrate, such as APIs.

Choosing whether to use a multitasking RTOS is like the construction workers deciding what building materials to use. It doesn't really matter how many workers there are. It depends on what the architect (system designer) specifies. And the architect makes that design decision based upon the product requirements and constraints.


If your task is to stitch all the code together, you are basically building the application. So you should know what is the task the application has to solve. You should gather all the requirements (for example, in what time should a certain task be finished, are there interrupts which need to be executed fast, is communication happening) which have a big influence on how you will solve your problem.

Normally the decision to use a RTOS or not is so fundamental to the system (including additional costs) that you shouldn't have to make that on your own, but the whole team should discuss benefits and drawbacks of using one. It can greatly influence the code your other programmers have to write. This goes hand in hand with the decision to use multitasking, which requires some functions to be safe for a reentrancy, which involves your team to code differently.

And yes, you should get some sort of API documentation to make your life easier.


It depends on the requirements of your boss/client. If he wants you to make something with multitasking, then yes, you should implement multitasking. If not, then don't implement it so that you don't waste time on it.

This kind of things should be clearly stated in the functional design. If it's not, you should ask your boss for more details before proceeding; or you may do things that are unnecessary and you will eventually slow down the design process. (if this is a client, you should have gotten all the details straight before accepting the job).

Also, there are different kinds of code packages. For example, some developers may have written a library which isn't meant to be standalone and you are meant to use it in other applications. In that case, you should neither execute it sequentially or with multitasking, but you should use the library in the other software you have been given, or you should use the library to connect the other codes.

Without further specification of your question the answer is not going to be more than: 'it depends'.

  • \$\begingroup\$ Ok, I understand. What about books, would you recommend any ? \$\endgroup\$ – Al Bundy Jan 31 '15 at 9:25
  • \$\begingroup\$ @user3023499 not really. It's really just knowledge of the language and following the specs. If it's unclear what you should do, ask your boss/client. If you don't know how to do what you're supposed to do (but it's clear what it is), you could get a general programming book or search around on the internet. \$\endgroup\$ – Keelan Jan 31 '15 at 9:27
  • 1
    \$\begingroup\$ I disagree with multitasking is something you do if its in the requirements from the boss. Requirement are different from implementation strategies. If the requirements are properly written, then the customer (your "customer" could be the boss, or a layer or two higher) should be happy with the product if they are met, regardless of how they are met. It is the architect's or chief engineer's job to design the high level strategy to meet the requirements. Lower people make similar decisions over smaller pieces. Often the team discusses important decisions together. \$\endgroup\$ – Olin Lathrop Jan 31 '15 at 20:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.