Cargando…
Software engineering for embedded systems : methods, practical techniques, and applications /
And conclusions -- Introduction to debugging tools -- GDB debugging -- Configure the GDB debugger -- Starting GDB -- Compiling the application -- Debugging the application -- Examining data -- Using breakpoints -- Stepping -- Changing the program -- Analyzing core dumps -- Debug agent design -- Use...
| Clasificación: | Libro Electrónico |
|---|---|
| Otros Autores: | , |
| Formato: | Electrónico eBook |
| Idioma: | Inglés |
| Publicado: |
Amsterdam :
Newnes,
2013.
|
| Edición: | First edition. |
| Colección: | Expert guide
|
| Temas: | |
| Acceso en línea: | Texto completo |
Tabla de Contenidos:
- Machine generated contents note: Software engineering
- Embedded systems
- Embedded systems are reactive systems
- Real-time systems
- Types of real-time systems
- soft and hard
- Examples of hard real-time
- Real-time event characteristics
- Efficient execution and the execution environment
- Challenges in real-time system design
- Response time
- Recovering from failures
- The embedded system software build process
- Distributed and multi-processor architectures
- Software for embedded systems
- Super loop architecture
- Hardware abstraction layers (HAL) for embedded systems
- Summary
- Today's embedded systems
- an example
- HW/SW prototyping users
- HW/SW prototyping options
- Prototyping decision criteria
- Choosing the right prototype
- Industry design chain
- The need to change the design flow
- Different types of virtual prototypes
- A brief history of virtual prototypes
- The limits of proprietary offerings
- What makes virtual prototypes fast
- Standardization: the era of SystemC TLM-2.0
- SystemC TLM-2 abstraction levels
- Architecture virtual prototypes
- Software virtual prototypes
- Summary
- the growing importance of virtualization
- When and why should you model your embedded system?
- Modeling
- What is a modeling language?
- Examples of modeling languages
- The V diagram promise
- So, why would you want to model your embedded system?
- When should you model your embedded system?
- Mission- and safety-critical applications
- Highly complex applications and systems
- Operational complexity
- Cost of defect versus when detected
- Large development teams require modeling
- Modeling is often the only choice
- So
- modeling is great, but aren't all models wrong?
- You have your prototype
- now what?
- Conclusion
- Next steps
- try it!
- Closed-loop control with a DC motor
- Learn more about prototyping with a downloadable kit
- Designing applications with the NI Statechart Module
- Design and simulate a brushed dc motor h-bridge circuit
- Multi-domain physical modeling with open-source Modelica models
- References
- Overview of architecture and design
- Architecture is about system-wide optimization
- Three levels of design
- What are design patterns?
- Must I use object-oriented techniques to use design patterns?
- An architectural example
- Using patterns
- Making trade-off decisions
- Software architecture categories and views
- Primary architectural views
- Secondary viewpoints
- Summary
- References
- Events and triggers
- Room temperature unit
- Event system
- Event handle
- Event methods
- Event data structure
- Reentrancy
- Disable and enable interrupts
- EnterCritical and ExitCritical
- Semaphores
- Implementation with Enter/ExitCritical
- Event processing
- Integration
- Triggers
- Blinking LED
- Design idea
- Tick timer
- Trigger interface
- Trigger descriptor
- Data allocation
- SetTrigger
- IncTicks
- Making it reentrant
- Initialization
- Blink!
- Beep!
- Real-time aspects
- Summary and source code
- Introduction
- Collaborate with the hardware team
- Proactive collaboration
- Ambassadors
- Register design tools
- Co-development activities
- System integration
- Useful hardware design aspects
- Notification of hardware events
- Launching tasks in hardware
- Bit field alignment
- Fixed bit positions
- Block version number
- Debug hooks
- Supporting multiple versions of hardware
- Compile-time switches
- Build-time switches
- Run-time switches
- Self-adapting switches
- Difficult hardware interactions
- Atomic register access
- Mixed bit types in the same register
- Edge vs. level interrupts
- Testing and troubleshooting
- Temporary hooks
- Permanent hooks
- Conclusion
- Best practices
- Introduction
- Principles of high-quality programming
- What sets embedded apart from general programming
- Starting the embedded software project
- Hardware platform input
- Project files/organization
- Team programming guidelines
- Syntax standard
- Safety requirements in source code
- Variable structure
- Variable declarations
- Data types
- Definitions
- Foreground/background systems
- Real-time kernels
- RTOS (real-time operating system)
- Critical sections
- Task management
- Assigning task priorities
- Determining the size of a stack
- The idle task
- Priority levels
- The ready list
- Preemptive scheduling
- Scheduling points
- Round-robin scheduling
- Context switching
- Interrupt management
- Handling CPU interrupts
- Non-kernel-aware interrupt service routine (ISR)
- Processors with multiple interrupt priorities
- All interrupts vector to a common location
- Every interrupt vectors to a unique location
- The clock tick (or system tick)
- Wait lists
- Time management
- Resource management
- Resource management, disable/enable interrupts
- Resource management, semaphores
- Resource management, priority inversions
- Resource management, mutual-exclusion semaphores (mutex)
- Resource management, deadlocks (or deadly embrace)
- Synchronization
- Synchronization, semaphores
- Synchronization, credit tracking
- Bilateral rendez-vous
- Message passing
- Messages
- Message queues
- Flow control
- Clients and servers
- Memory management
- Summary
- Why does software reuse matter?
- What limits software reuse?
- Kinds of software reuse
- Implementing reuse by layers
- Going to the next level
- Introducing the component factory
- Factory hardware configuration
- Factory software configuration
- How the factory aids reusability
- RTOS agnosticism
- Arbitrary extensibility
- Conclusion
- References
- Example: latency vs. throughput in an eNodeB application
- Performance patterns and anti-patterns
- References
- The code optimization process
- Using the development tools
- Compiler optimization
- Basic compiler configuration
- Enabling optimizations
- Additional optimization configurations
- Using the profiler
- Background
- understanding the embedded architecture
- Resources
- Basic C optimization techniques
- Choosing the right data types
- Functions calling conventions
- Pointers and memory access
- Restrict and pointer aliasing
- Loops
- Additional tips and tricks
- General loop transformations
- Loop unrolling
- Multisampling
- Partial summation
- Software pipelining
- Example application of optimization techniques: cross-correlation
- Setup
- Original implementation
- Step 1: use intrinsics for fractional operations and specify loop counts
- Step 2: specify data alignment and modify for multisampling algorithm
- Step 3: assembly-language optimization
- Introduction
- Code size optimizations
- Compiler flags and flag mining
- Target ISA for size and performance tradeoffs
- Tuning the ABI for code size
- Caveat emptor: compiler optimization orthogonal to code size!
- Memory layout optimization
- Overview of memory optimization
- Focusing optimization efforts
- Vectorization and the dynamic code: compute ratio
- Pointer aliasing in C
- Data structures, arrays of data structures, and adding it all up!
- Loop optimizations for memory performance
- Data alignment's rippling effects
- Selecting data types for big payoffs
- Introduction
- Understanding power consumption
- Basics of power consumption
- Static vs. dynamic power consumption
- Maximum, average, worst-case, and typical power
- Measuring power consumption
- Measuring power using an ammeter
- Measuring power using a hall sensor type IC
- VRMs (voltage regulator module power supply ICs)
- Static power measurement
- Dynamic power measurement
- Profiling your application's power consumption
- Minimizing power consumption
- Hardware support
- Clock and voltage control
- Low-power example
- Optimizing data flow
- Reducing power consumption for memory accesses
- DDR overview
- DDR data flow optimization for power
- Optimizing power by timing
- Optimizing with interleaving
- Optimizing memory software data organization
- Optimizing general DDR configuration
- Optimizing DDR burst accesses
- SRAM and cache data flow optimization for power
- SRAM (all memory) and code size
- SRAM power consumption and parallelization
- Data transitions and power consumption
- Cache utilization and SoC memory layout
- Explanation of locality
- Explanation of set-associativity
- Memory layout for cache
- Write-back vs.
- write-through caches
- Cache coherency functions
- Compiler cache optimizations
- Peripheral/communication utilization
- DMA of data vs. CPU
- Coprocessors
- System bus configuration
- Peripheral speed grades and bus width
- Peripheral to core communication
- Algorithmic
- Compiler optimization levels
- Instruction packing
- Loop unrolling revisited
- Software pipelining
- Eliminating recursion
- Reducing accuracy
- Low-power code sequences and data patterns
- Summary and closing remarks
- Analysis phase of user interface design
- First design iteration
- Develop a second prototype (high-fidelity tool-drawn mockup)
- Essential use cases
- Scenarios for user analysis
- Hierarchal task analysis
- Design approaches to overcome user limitations of cognition, perception, and learning
- Error messages
- Virtual windows
- Data models using entity relationship diagrams (ERD)
- Analysis of virtual windows using a CREDO matrix
- Hueristic evaluation
- Gestalts
- Designing user interfaces with Model View Controller (MVC) architecture
- Context of the MVC software architecture
- Problems and forces for the MVC software architecture
- Solution using the MVC
- Safety-critical user interfaces
- Process for designing a safer HMI
- Guidelines for safe human-machine interface design
- References
- Bibliography
- What is software test?
- Why should we test software?
- How much testing is enough?
- When should testing take place?
- Who makes the decisions?
- Note continued: Available techniques
- Static and dynamic analysis
- Requirements traceability
- Static analysis-adherence to a coding standard
- Essential knots & essential cyclomatic complexity
- case study
- Understanding dynamic analysis
- The legacy from high-integrity systems
- Defining unit, module and integration tests
- Defining structural coverage analysis
- Achieving code coverage with unit test and system test in tandem
- Retaining the functionality through regression test
- Unit test and test-driven development
- Automatically generating test cases
- Setting the standard
- The terminology of standards
- The evolution of a recognized process standard
- Freedom to choose adequate standards
- Dealing with the unusual
- Working with auto-generated code
- Working with legacy code
- Tracing requirements through to object code verification (OCV)
- Implementing a test solution environment
- Pragmatic considerations
- Considering the alternatives
- Summary and conclusions
- Introduction to debugging tools
- GDB debugging
- Configure the GDB debugger
- Starting GDB
- Compiling the application
- Debugging the application
- Examining data
- Using breakpoints
- Stepping
- Changing the program
- Analyzing core dumps
- Debug agent design
- Use cases
- Debug agent overview
- Starting the application
- Context switch
- Position-independent executables
- Debug event from the application
- Multicore
- Starting the debug agent
- Debugging using JTAG
- Benefits of using JTAG
- Board bring-up using JTAG
- Comparison with the debug agent
- GDB and JTAG
- Debugging tools using Eclipse and GDB
- Linux application debug with GDB
- Linux kernel debug with KGDB
- Instrumented code
- Practical example
- Analysis tools
- Strace
- Mtrace
- Vaigrind
- Hardware capabilities
- Hardware breakpoints
- Hardware watchpoints
- Debugging tips and tricks
- Part 1: Analysis and high-level design
- Analysis
- Improving serial performance
- Understand the application
- High-level design
- Parallel decomposition
- Data dependencies
- Communication and synchronization
- Load balancing
- Choice of algorithm
- Decomposition approaches
- Summary of Part 1
- Part 2: Implementation and low-level design
- Thread-based implementations
- Kernel scheduling
- Pthreads
- Using PPthreads
- Dealing with thread safety
- Implementing synchronizations and mutual exclusion
- Mutexes, locks, nested locks
- Mutex
- Condition variables
- Granularity
- Fine-grained
- Coarse-grained
- Approach
- Implementing task parallelism
- Creation and join
- Parallel-pipeline computation
- Divide-and-conquer scheme
- Task scheduling considerations
- Thread pooling
- Affinity scheduling
- Event-based parallel programs
- Implementing loop parallelism
- Aligning computation and locality
- Message-passing implementations
- MCAPI
- MRAPI
- MCAPI and MRAPI in multicore systems
- Playing-card recognition and sorting example
- Using a hybrid approach
- References
- Introduction
- Which safety requirements?
- Certification killers
- Project planning strategies
- Strategy 1: determine the project certification scope early
- Strategy 2: determine feasibility of certification
- Strategy 3: select an independent assessor (if used)
- Strategy 4: understand your assessor's role (if used)
- Strategy 5: assessment communication is key
- Strategy 6: establish a basis of certification
- Strategy 7: establish a "fit and purpose" for your product
- Strategy 8: establish a certification block diagram
- Strategy 9: establish communication integrity objectives
- Strategy 10: identify all interfaces along the certification boundary
- Strategy 11: identify the key safety defensive strategies
- Strategy 12: define built in test (BIT) capability
- Strategy 13: define fault annunciation coverage
- Strategy 14: define reliance and expectation of the operator/user
- Strategy 15: define plan for developing software to appropriate integrity level
- Strategy 16: define artifacts to be used as evidence of compliance
- Strategy 17: plan for labor-intensive analyses
- Strategy 18: create user-level documentation
- Strategy 19: plan on residual activity
- Strategy 20: publish a well-defined certification plan
- Faults, failures, hazards, and risk analysis
- Faults, errors, and failures
- Availability and reliability
- Fault handling
- Hazard analysis
- Risk analysis
- Safety-critical architectures
- "Do-er"/"Check-er"
- Two processors
- "Voter"
- Software implementation strategies
- Strategy 1: have a well-defined, repeatable peer-review process
- Strategy 2: consider using existing safety coding standards
- Strategy 3: handle all combinations of input data
- Strategy 4: specific variable value checking
- Strategy 5: mark safety-critical code sections
- Strategy 6: timing execution checking
- Strategy 7: stale data
- Strategy 8: comparison of outputs
- Strategy 9: initialize data to least permissive state
- Strategy 10: order of execution
- Strategy 11: volatile data checking
- Strategy 12: non-volatile data checking
- Strategy 13: make sure the entire system can run
- Strategy 14: remove "dead" code
- Strategy 15: fill unused memory
- Strategy 16: static code analysis
- Background
- Is that software yours?
- Obtaining software
- Copyright protection
- Getting copyright
- Patents
- What is a patent?
- Why do patents exist?
- Deciding what to patent
- Applying for a patent
- What's in a patent?
- Licensing patents
- Problems
- Open-source software
- Licensing and selling software
- Getting acquired
- Discovering infringement
- Avoiding copyright infringement
- Avoiding patent infringement
- Capability maturity model integration
- The OSI model
- Software development
- V-model
- Waterfall model
- Agile model
- Organization
- Program charter
- Stakeholders and the core team
- Product life-cycle management
- Portfolio management
- Project management life-cycle
- Project life-cycle
- Problem-solving
- Communications
- Abbreviations, symbols, acronyms
- Copyright acknowledgments
- References
- Introduction
- What's special about embedded systems?
- Fits into a system whose requirements are allocated to different engineering disciplines of which software is only one
- Uses specialized hardware
- Is often co-developed with the hardware
- Constrains the selection of programming languages and tools
- Has a more challenging testing environment
- Must often be highly predictable
- Is often subject to tight timeliness constraints
- Often has severe resource constraints (such as memory)
- Must often be very highly reliable and safety-critical
- Is often subject to rigorous external regulation
- Is delivered in a shipped, stand-alone product
- Is often subject to fixed-price bids
- Agile project planning for embedded software
- Project vision
- Initial safety/reliability risk assessment
- Initial project risk assessment
- Estimating
- Scheduling
- Project governance for embedded software
- Stand up! (meetings)
- Performance metrics
- Iteration retrospective (party phase)
- Agile development practices for embedded
- Incremental development
- High-fidelity modeling
- Executable requirements
- Test-driven development (TDD)
- Continuous integration
- Change management
- Dynamic planning
- Risk management
- Scaling factors for agile
- Can agile methods help you adhere to standards?
- Summary
- References
- Bibliography
- A bit of history to set the scene
- Auto electronics: 1911-2000
- Electronic content growth drivers
- The resultant embedded SW growth
- Automotive programming languages
- Summary of implications
- Automotive segments and how they differ
- Body
- Chassis and safety
- Driver assistance
- Powertrain and transmission
- Infotainment and telematics
- Automotive subsegment summary
- Automotive quality
- Planning for Murphy's law
- Fault-tolerant communications
- Fault-tolerant software
- Zero-defect software
- Risk management and failure modes
- Failure modes and effects analysis
- Development and test
- Subsystem interoperability
- Software specifications
- Software architecture
- Modeling
- Autocoding and drivers
- Bench testing
- Trace and debug
- Final-phase testing
- Calibration
- Maintenance/product lifetime support
- Automotive diagnostics
- MIL
- Data logger
- OBD II
- Automotive standards
- MISRA
- AUTOSAR
- AEC
- Automotive safety
- ISO 26262
- ASIL
- Automotive security
- What it used to mean: car alarms etc
- What it means today: hacking
- What it will mean tomorrow: counterfeiting
- The near future of the automotive market
- Performance
- The emergence of multicore
- The connected vehicle
- The automated vehicle
- Conclusion
- I/O device and I/O controller
- Category of I/O devices
- I/O controller
- Memory-mapped 1/0 and DMA
- Flash, SD/SDHC and disk drive
- Network-attached storage
- I/O programming
- I/O software goals
- I/O software layer
- Case study: device driver in Linux
- Storage programming
- I/O for block devices
- Flash device programming
- SATA device driver
- Performance improvement of storage systems
- Case study 1: performance optimization on SDHC
- Case study 2: performance optimization on NAS
- Summary
- Bibliography
- Introduction
- System architecture of network devices
- Data, control, service and management planes
- Multicore SoCs for networking
- Cores
- Packet engine hardware (PEH) block
- Network programming models
- Pipeline programming model
- Run-to-completion programming
- Structure of packet-processing software
- Data-plane infrastructure (DP-Infra)
- Structure of the forwarding engine
- Packet-processing application requirements
- Network application programming techniques
- Multicore performance techniques for network application programmers.
- Note continued: Avoid locks while looking for flow context
- Avoid reference counting
- Safe reference mechanism
- Flow parallelization
- Reducing cache thrashing associated with updating statistics
- Statistics acceleration
- General performance techniques for network application programmers
- Use cache effectively
- Software-directed prefetching
- Use likely/unlikely compiler built-ins
- Locking critical piece of code in caches
- General coding guidelines
- Linux operating system for embedded network devices
- Translation lookaside huller (TLB) misses associated with user-space programming
- Access to hardware peripherals and hardware accelerators
- Deterministic performance
- Summary
- Introduction
- Why Linux for embedded?
- Linux distributions
- Embedded platforms suitable for Linux
- Licensing
- Getting started with Embedded Linux
- Memory management unit
- Bootstrapper
- Bootloader
- Kernel
- Applications
- Running Linux on a reference board
- Reference platforms
- Starting with BeagleBone.