my issue maybe looks so general but i really need your help .I am a newbie embedded software engineer and I have done some small projects with TI DSC and STM microcontroller with C and C++ programming languages. but now I am going to start writing firmware for a big project and I am looking for a way to model my firmware before implementing it.actually I have two questions :
1.I want to know what does professional embedded software engineer do before starting to write the firmware ?(for modeling the firmware ,is using from rational rose or enterprise architecture suitable for firmware,i think these two, are suitable for IT and software applications not firmware)
2.what important rules I must observe during writing the firmware? for example I have considered about :
a.Never ever put a lot of code into an interrupt service routine
b. Never do busy waiting with wile loops What other thing should I have considered?
These kind of questions are off-topic on SO, but I'll answer anyway since there's not really a forum anywhere for these very important considerations. Typically it goes like this:
Write the spec and requirements. Spend some time at this and focus on the product, not on technical details. UML "use-cases" can be handy but common sense works just as fine too. Make sure that the spec is a living document which can be revised when necessary.
Then do the program design with an OO model (call it classes/code modules/translation units or what you will). Write down which code modules that the program need, make sure these correspond to the spec - ideally each requirement leads to specific code (which later on leads to a specific test of that code). Then focus on dependencies between different modules: this should be a "top-to-bottom" dependency tree where drivers don't depend on HALs, that don't depend on callers and so on. Draw up this tree with pen and paper. Fancy UML is ok but not necessary.
You need to consider portability early on. Should the code be ported between projects? (very common) Between compilers? (fairly common) Between platforms? Depending on what level of portability that is needed, you can cheat with the design and skip some HALs. It is almost always a good idea to separate the drivers from the application, however.
Regarding "important rules" these have nothing to do with the program design stage. Rather, these should be in your coding standard document. Preferably a company standard that is used for every project. It should focus on banning all manner of bad practices and in addition contain a style guide. For embedded systems I would strongly recommend to base this document on MISRA-C, then add custom rules if you wish (such as "keep ISR code minimal") and then add a style guide on top of that. Please note that writing this coding standard is a project of its own.