Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Embedded Software Design

4 402 vues

Publié le

Embedded System specific Design aspects

Publié dans : Technologie
  • Soyez le premier à commenter

Embedded Software Design

  1. 1. © 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Embedded Software Design
  2. 2. 2© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. What to Expect? Functionality Design & Programming Design for Fault Tolerance Hardware aware Design & Programming Design & Programming for Performance Design for Maintainability
  3. 3. 3© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Special about Embedded Software Full Featured with Smaller Binary Size Seamless Hardware Interaction with High Fault Tolerance Time Tolerant (Running forever) Good Performance with Limited Processor Power Capable of Remote Testing, Debugging, Fixing In short, it is Optimized, Robust, Continuously Performing, Maintainable
  4. 4. 4© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. W's of Embedded Software Design Do NOT start coding, Design First Design means “Data Structures, Interfaces & Algorithms” If comfortable, put down “C” structs and “C” function prototypes, And Design “C” pseudo code using them How to Proceed? Understand the overall requirements Break them into smaller manageable/thinkable chunks Think & Propose designs for each one of them To meet all the requirements If some requirement(s) are not met Tweak / Modify the designs to meet all of them Because trying to meet them later may turn out to be costly In terms of both time & effort
  5. 5. 5© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Functional Design & Programming
  6. 6. 6© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Functional Design Approach Preferred Design Approach → Top-down Design interfaces to meet the customer requirement Implement interfaces compatible with the OS i/fs, Or So-called system calls in Linux If any interface changes, review the complete path Advantages Reduce trial and error coding Reduce bugs & hence reduce debugging efforts More productive time for better designs
  7. 7. 7© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Functional Programming Tidbits Processes vs Threads Limited Memory vs Synchronization Extras Independent Units vs Event Driven Programs Security vs Inherent Communication Process Usages Multi-processors and Multi-tasking Minimal Process Inter-communication Communication using IPCs Native Implementation
  8. 8. 8© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Functional Programming Tidbits Threads Usages Multi-processors and Parallel Programming Hand-in-hand Blocking & Execution Code & Libraries need to be re-entrant & thread-safe Implementation using pthreads library Model Cases Delegation or Manager-Worker (e.g. Web Server) Pipeline (e.g. Events in a GUI) Peer (e.g. Multiple I/O Processing) Producer-Consumer (e.g. Manufacturing Unit)
  9. 9. 9© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Functional Programming Tidbits Schedulers & Priorities Normal vs Real Time Nice vs Priority Time Slicing vs Starvation Synchronization in Priority based Scheduling Deadlock Avoidance (Banker's Algorithm) Deadlock Prevention (Conditional Variables)) Priority Inversion Resolution Techniques Priority Inheritance, Priority Ceiling, Priority Protect
  10. 10. 10© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Functional Programming Tidbits Signals vs Polling Asynchronous vs Synchronous Racing vs Blocking Timers vs Loops Interrupts vs Signals Kernel Space vs User Space Hardware vs Software
  11. 11. 11© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Functional Programming Tidbits Sockets Inter-system communication Control, Data Interface to Multiple Devices Interface to Multiple Channels / Functionalities On a Device Model case Client-Server (e.g. for debugging, logging, ...)
  12. 12. 12© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Extra Miles for Embedded Software Even after a good functional design, including the functional programming tidbits, there are many other design & programming aspects, which need to be taken care for Embedded Software Can be learnt in two ways The hard way by experiencing yourself, Or By applying from others learnings So, here goes some from my learnings
  13. 13. 13© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Design for Fault Tolerance
  14. 14. 14© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Design for Fault Tolerance Design for Uninterrupted Execution Avoid race conditions w/ proper synchronization Avoid memory leaks w/ memory usage balancing Verify with memory profilers Handle all error cases, extreme conditions default for a switch, else for an if, ... Avoid infinite loops. Rather put timeouts Re-organize code to avoid / prevent deadlocks
  15. 15. 15© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Design for Fault Tolerance Design for Crash Recovery By restarting the crucial flows Example: The Main Task Design for Hang Recovery With watchdogs Design for Power Failures With brown-out detections With power-down saves
  16. 16. 16© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Hardware aware Design & Programming
  17. 17. 17© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Design for Hardware Speed Mismatch Hardware (Faster / Slower) Interact using interrupt-mechanism Time-sensitive Hardware Interaction Specific hardware protocols like I2S, SPI, ... Use precise (busy-wait) delays Non-responsive Hardware Use timeouts rather than unconditional accesses Hardware with Irregular/Incorrect Responses Do proper error handling for the extreme / abnormal / invalid cases Hardware Delays (like Debouncing, Rise Time, ...) Use appropriate Timers &/or Delays to offset them
  18. 18. 18© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Programming for Hardware Passive vs Active Devices (Memory vs Device) Code Optimization vs Change outside Program Use programming specific keywords, like volatile Memory Caching at various levels May need to bypass/disable/flush for addr-mapped devices Using architecture specific instructions / APIs CPU Optimizations (Re-ordering of CPU instructions) May need to be locally disabled for correct device operations Using architecture specific barriers
  19. 19. 19© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Programming for Hardware Virtual Memory Accesses for DMA May need to be translated to Physical Addresses Cache consistency needs to be taken care of Using OS specific lookup APIs Register Specific Programming May need specific programming sequences As per the device datasheet Examples Clear-on-write, Multiple writes Indirect Access, Protected Access
  20. 20. 20© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Design & Programming for Performance
  21. 21. 21© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Design for Performance IPC vs Synchronization Multi-process (Context Switching) vs Multi-threaded (Same Context) Communication vs Synchronization Overheads Schedulers & Priorities Normal vs Real Time Nice vs Priority Yielding vs Busy Wait Latency vs Precision Interrupt / Signal Usage Higher Priority and Asynchronous Attention But too many / missing them may invalidate assumptions
  22. 22. 22© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Design for Performance Swap Space May reduce individual task performance Though, may improve overall performance By letting many more tasks run Provided by swap partition or file Usage could be controlled by adjusting swappiness Physical Memory Minimizing memory allocation / deallocation (Secondary) Storage Usage & Accesses Minimize / Eliminate for best consistent performance Possibly by pre-loading into memory or using mmap
  23. 23. 23© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Design for Real Time Performance Have very few Real Time Processes Keep the RT Applications Short & Efficient Do not do heavy duty operations Like Memory Allocation, ... If essential, move to Initialization Sections Testability for the RT working of the other RT Apps Testability of the performance of the needed OS service If any RT App has priority higher than the OS Service Testability for other needed non-RT Apps' performance
  24. 24. 24© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Programming for Performance System Calls vs Library Functions Direct vs Indirect w/ Internal Overheads Single Buffered vs Multi-buffered Example: File Operations (read / write / ... vs fread / fwrite / ...) Buffer Caching vs Direct Access Repeated Accesses vs One Time Access Possible Thrashing vs Uniform Slow Performance Controlled using O_DIRECT Code Optimization Techniques Compiler Optimizations for Performance, esp by removing redundant code Reduce/Remove Code Bottlenecks detected using Profilers Placing often used variables into registers, but may affect other computations Making functions inline, but may increase code size Using likely / unlikely constructs for code placement to minimize cache misses
  25. 25. 25© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Design for Maintainability
  26. 26. 26© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Design for Maintenance Embedded Systems are Highly Constrained Critically Operating In case of issues, need to be resolved urgently And, most of the times remotely at customer site Demands for an excellent debugging framework For the overall embedded system Be it Kernel Space or User Space And, ways to fix problems remotely
  27. 27. 27© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Debugability & Fixability Provide enough debugging support through logging hooks May keep the minimal light weight support enabled, by default (Remote) Support for further enabling / disabling the logs Multiple log levels depending on the criticality of the situation (Remote) Access to the Log from the Embedded System Logs & Dumps should be from the various parts of the System Kernel, Startup, Applications, … Could be centralized &/or de-centralized depending on the ES At the least, the following Activity Logs should be designed & coded Login, Network, Reboots, Device Access, ... And last but not least, Automatic / Remote mechanisms for Update / Patch should be implemented
  28. 28. 28© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. What all have we learnt? Functionality Design & Programming Design for Fault Tolerance Hardware aware Design & Programming Design & Programming for Performance Design for Maintainability
  29. 29. 29© 2010-15 SysPlay Workshops <workshop@sysplay.in> All Rights Reserved. Any Queries?

×