Quelles sont les meilleures pratiques pour écrire et tester du code pour les systèmes embarqués ?

There is no single answer to choosing a right programming language for embedded systems. However, C occupies the dominance in this area followed by C++(look for standard Arduino libraries implementation) and extensive work and porting happening on Rust. It looks like C is here to stay since a large part of legacy code is maintained in C. C in this regard has a very open approach in terms of flexibility and doing a lot of deep work. Hence it is often used to write low level drivers and operating systems.However this makes it prone to unnecessary errors. For e.g. pointers could even lead to unintentional writes on wrong memory areas if not handled properly. Python has become a defacto choice for embedded Linux and automated testing.

Ask yourself, what will your code be used for? Visualization? Data analysis? Image post-processing? Physical modeling? Each programming language has its own unique advantages and disadvantages.

The entrepreneurs can't afford to recruit highly literate and educated manpower, when they secure business at cut throat competition. Hence, they routinely manage the work, but, for obtaining some accreditation, they appoint people who are good at documentation.

I have HVAC Diploma And Electrical Technologi and MPE almost 27 Expriance in Saudi Arabia Many place working expriance i have

I am used to programming for large food processes. We spent more time locating sensors, actuators, etc. in order to make sure they were accessible to repair, replace, test. The programming by consultants was typically led by internal and external people experienced in our processes. We always ran a “dry” checkout to test logic and sequencing before putting any product or raw materials in the system. This saved us a tremendous amount of time and trouble and a quicker production start-up. These steps allowed us to move from 2-3 month long start-ups to good product ready to ship in days and prevented huge waste of lost labor and materials.

In my industrial experience, coding standards / guidelines are paramount in development. Internal coding guidelines often are well thought and decided to allow symmetry and uniformity in the software so the code remains intelligible and comprehensible for anyone who reads and decides to fix or add a feature to it. Some other standards such as MISRA C-2012 provides a set of rules. These rules help in eradicating unintended behaviour of the system. Some examples are - Assigning 260 to uint_8t . This would often overflow to 4. And hence MISRA produces an error. -Another is using parentheses for every expression to keep precedence of operators in check. And many more. These are laid out as rules in MISRA C standard.

Mostly, the written documentations and the real practices do not match. The document may say that during pressure testing, the area surrounding the equipment, should be cordoned off, whereas, when they work in a limited space, they will have to stop all other work.

Modularity is your best friend during development and testing. A bigger feature should always be divided into smaller sub functions. And a function should always consist of a single functionality. These are often a part of coding guidelines in the organization to keep the code readable and maintainable. Some metrics like HIS metrics also keep an account of this. It is also a very good practice or I would say a must to create a new function for a feature to be added in the existing software. This helps to keep the maintainability intact of the function which is changed. Keeping code modular also helps to perform unit testing very efficiently as well as debugging the code also becomes a lot easier.

Test your code on the actual target hardware early in the development process. Ensure that it operates reliably under real-world conditions. Use debugging tools like JTAG, SWD, oscilloscopes, and logic analyzers to diagnose hardware-related issues.

Sim concordo plenamente com esta situação mas acho que tudo este sistema deve de ter uma palavra passe para,que não aja alterações feitas por outras entidades patronais.

Documentation is especially important if your code will be used by others. Proper documentation will save everyone time and effort by answering the questions before they are even asked. If your code will be used by a research team, it is best to use a standard set of documentation conventions.

Documenting your code is one of the practices that I appreciate as a researcher and an engineer. This is critical especially if others will use the code, which make future development and enhancements more effective.

In addition to the above view if you have the unit test cases and integration test cases documented well along with the negative test cases then it will help in making the design more robust and will block the bugs disguised as surprises when deployed in the field.

Understand Hardware Limitations. Use Efficient Algorithms and Data Structures. Modular Code Design. Keep Code Simple and Readable. Prioritize Real-Time Constraints. Error Handling and Debugging. Use Hardware Abstraction Layers (HALs). Power Optimization. Unit Testing and Integration Testing. Static Analysis and Code Reviews. Documentation. Version Control. Security Considerations.

Writing and testing code for embedded systems can be challenging due to resource constraints, real-time requirements, and the need for stability and reliability. Here are some best practices: 1.Requirements Gathering 2.Modular Design 3.Code Reviews 4.Use Version Control 5.Static Code Analysis 6.Real-time Operating System (RTOS) 7.Test-driven Development (TDD) 8.Continuous Integration (CI) 9.Simulation and Emulation 10.Hardware Abstraction 11.Error Handling 12.Logging and Debugging 13.Resource Management. 14.Security 15.Power Management 16.End-to-end Testing 17.Field Testing 18.Documentation

If your code is planned to be open sourced, all of the above recommendations become even more important. Code used by the community must be well documented, verified, tested, and maintained in order to create a thriving group of users.

Review your current spec to rigorously reconsider if you really want any "modern" or "flexible" or "powerful" buzzword-associated non-embedded features that take your project away from the sufficient, critical fundamentals and into the false-desirables run-your-whole-PC-on-this-new-SoC world of broken state machines that cannot be successfully validated or tested without changing the spec to something other than an embedded anything. Don't make it impossible to deliver anything actually safe to use. Safety built on Belief and Hope doesn't appear in the Guidances, does it?