image/svg+xml Zidarics Zoltánzamek@vili.pmmf.hu 2020 EmbeddedProgramming 2. Git Evaluation & grading Software lifecycle Planning Analysis Programming Evaluation Spiral Technológy Practicability Minimum times required by technology Output / input signal levels, power Number of inputs / outputs Real-time processing? Number of events System analysis Which data communication? Which extending will be in the future? Logging Security? Emergency mode? Which human communication? Software design How many independent tasks? Priority of tasks Communication between tasks Data structures Serving hardware architecture Communication interfaces Human communication Test mode GPIO allocation mcuconf.h Flowcharts datastruct.h halconf.h chconf.h Planning Practicability Platform Hardware planning Software plannining Platform choice 8,16,32,64 bits architecture? arithmetic needed? expected speed? asynchronous event processing? data storage? communication? human interface? support? existing expertise? Hardware design Power supply GPIO voltage and power levels Number / resolution of A / D, D / A converters,sampling rate kommunication interfaces, RS-233, RS-485,SPI, I2C, CAN stb. diagnostics, JTAG interface Programming Expectations programming testing code review documentation merge/cherry pick task scheduling Expectations always be a codebase for the customers every programmers need a local "garbage heap" we can restore all of the previous version fix an error only once create modules, and all modules have a responsible person a module is finished when it is fully tested and documented distinguish the programming a supporting compile must works in a command line Task scheduling Senior programmer defines the tasks "dummy" modules communication in the group and between groups define deadlines test environment co-working groups In case of fire 1. git commit 2. git push 3. leave building Programming use of design patterns diagnostic mode hierarchia the shift is over when git status is commanded"nothing to commit, working tree clean" is the answer. coding rules, naming conventions you can push only flawless code into a remote repository! (it must be compiled) comment poisoning document you job C coding standard Testing the module is not ready until the tests don't run successfully when a function is ready, test it immediately each test function displays when it is started and when it runs it is forbidden to comment on the test case CUnitDemo Code review code review is not against you tests have to run after code review "no flawless program, only less tested" (Murphy) don't debate, prove it Documentation there must document every input and output arguments of a function indicate if your function is null safe (have all your functions) indicate if your function allocates memory for the return value indicate if a value outside of the expected content causes an error if the function is not trivial, explain how it works there must be a brief and a full documentation for every function there must be a documentation for a modul Merge/Cherry pick Before making an M / CP check that there is no change in the remote repository if you are unsure of the success of M / CP, clone the project into / tmp and check Before M / CP, think about which local branch you want to save to which remote repository always read the git messages Evaluation does the software deliver the expected functionality? Is there remaining reserve? reworking modules Is customer satisfied? new features Group development system designers programmer UI programmer tester deployment manager support manager The software is an asset should be protected from unauthorized use opportunity for continuous improvement bug fixes flexible configuration Software for software development IDE (Integrated Development Environment) GCC (GNU C compiler) Git make doxygen IDE (Integrated Development Environment) editing source files compiling debugging administrative tasks (import / export / refactoring) TODO lists Code::Blocks, Eclipse, vi etc. GCC (GNU C compiler) 2 steps compiling multiplatform (x86, arm, MinGW,stb.) ISO C standard, c++11, c++14, c++17 cross-compiling library, static, dynamic https://gcc.gnu.org/ Git version manager distributed version manager Linus Torvalds 2005 nonlinear development full-fledged local and remote repository svn, cvs handling import / export Concepts DevOps CI/CD (Continuous Integration/Deployment) QA (Quality Assurance) Automated test systems Automated deployment systems a team of developers and operators in an organizationcloser cooperation than usual(Development és Operations) the development team from the beginning of the cycle has tools to support it operation (deploy scripts, automatic diagnostic tools,load and performance testing tools)provides useful feedback during and after everyone focuses primarily on the end user experience andhow it affects business needs. DevOps is not a new toolkit, but rather a new process- if you like, a new culture The number of stressful situations decreases. We'll receive far fewer callsget in the middle of the night that something urgently needs to be corrected with a sharp,productive system. This is mainly because of these situations alreadyeveryone is proactively prepared, well before they become catastrophicthe situation would become. DevOps The code is visible to the developer all the way. The old model is the developerfinished with the code, "tossed it on the wall" to the QA, who later also tossed oneon a new wall for the production team.Thus, it may even be the code released by the developer at the end of the roadwas no longer quite like the baseline.Under the DevOps model, developers can keep an eye on their own codethrough testing to arming. More relevant work. For most people, including developers, it's biggerthey enjoy work that has some relevance to the real worldlooking at it. In the traditional model, software developers are quite isolatedthey work in space, mainly in fictional scenarios, which are then used only sharplyit turns out that they were really rough and bad approaches.In the DevOps model, all scenarios are realistic. CI/CD Continuous integration   DESCRIPTION SOFTWARE NAME SOFTWARE VERSION COMPANY INFO Sensing & measurement Business logic & outputs User interface (UI) Git repository QA (Quality Assurance) Deployment Software in box git push origin measurement git push origin bl_o git push origin ui Project managergit merge ... Feedback Feedback Feedback Feedback git pull origin ... code review code review code review git pull origin master assemble Unit tesztek Integrációs tesztek Kódolási szabványok betartása Modulok helyes működésének tesztjei A teljes software működés tesztje Quality Assurance Ensuring code quality Unit tests Integration tests Compliance with coding standards Tests for proper functioning of modules Test of full software operation Automated deployment systems git commit triggers (master branch) running on a virtual machine (Digital Ocean) Reporting (ISO) Automated test systems git commit triggers running on a virtual machine (Digital Ocean) Reporting (ISO) feedback to the programmer Gitlab, Bitbucket provides this service Mark 5 4 3 2 1 In percent 89-100% 77-88% 66-76% 55-65% 0-54% Grading weight Homeworks Project work 50% 50% prerequisite: completion of all homework on time Task presentation Code review Plagiarism The student must upload the assignment to the git repository specified by the instructor The student can only share this repository with the instructor If the repository is not private or can be accessed by others, the task will not be accepted. The instructor may optionally request a code review to clarify the problems or possible suspicion of plagiarism The instructor can check the uploaded code three times. During an examination, the instructor can make objections in the commit comment, request changes to the code, and set a new deadline for it. If the student does not correct the alleged errors after the third examination, or does not fulfill the change requests by the specified deadline, the instructor may decide not to accept the assignment. in case of plagiarism, the task is invalid and the student is assigned a new task by the instructor, if plagiarism is the first case. In the case of a second plagiarism, there is no way to assign a new task, that task will be invalid. After the deadline for submission of the task, it is not possible to submit the task, it will be invalid. A personal or committee code checking that helps the instructor make sure that the code is the student’s intellectual product or is aware of how the code works, understands its structure, and can change it as needed. During the code review, the instructor or committee may ask the student to explain how the code works, the libraries used, variables, and functions. The instructor or the committee may also ask the student to change the code, for which he or she may set a new deadline. Plagiarism is when someone uses the work of another person (the original author) in their own work without reference, citation, and / or copyright permission, pretending to be their own, and thereby violating the rights of the original author. The instructor or committee evaluating the task is authorized to diagnose plagiarism. Plagiarism may be suspected in the following cases: the student does not know what variables and functions he/she is using that particular piece of code - which he theoretically wrote - works. the student must be aware of the structure of the libraries he/she uses, the parameterization of the function used in the given code and the processing of the return value. the student is not able to find out in the code or in the development environment used, for example in the case of “please show that…” type questions
1
  1. Main
  2. Evaluation & grading
  3. Task presentation I.
  4. Task presentation II.
  5. Task presentation III.
  6. Software lifecycle
  7. System analysis
  8. Planning
  9. Practicability
  10. Platform choice
  11. Hardware design
  12. Software design
  13. Programming
  14. Expectations
  15. Task scheduling
  16. Programming
  17. In case of fire
  18. Testing
  19. Code review
  20. Documentation
  21. Merge/Cherry pick
  22. Evaluation
  23. Team development
  24. The software is an asset
  25. Concepts
  26. DevOps I.
  27. DevOps II.
  28. CI/CD I
  29. CI/CD II
  30. Quality assurance
  31. Automated test systems
  32. AUtomated deployment systems
  33. Software for software development
  34. IDE
  35. gcc
  36. Git
  37. next