csci1600: embedded and real time software lecture 18: real time languages steven reiss, fall 2015
TRANSCRIPT
CSCI1600: Embedded and Real Time SoftwareLecture 18: Real Time Languages
Steven Reiss, Fall 2015
Programming Language Wars
Programming Languages
For real-time and embedded programming
Choices Assembler
C/C++ (low-level language)
Java/C# (high-level language)
Data flow languages (FPGA)
Other
How should we choose?
Criteria for Choosing Small footprint for embedded systems
Ability to write small code
Ability to make efficient use of memory
High performance
Predictable performance
Real time features Interrupts
Scheduling tasks or threads
Synchronization
Criteria For Choosing
Low Power consumption
Other factors Fault tolerance
Writing reliable code (verifiable, testable, understandable)
Writing secure code
Code understandability
C versus C++ versus Assembler Footprint
Performance
Real time features (interrupts, synchronization, scheduling control)
Fault tolerance
Reliability
Security
Understandability
Why Not Java
What are the pros and cons?
What about Java
Not what Java was designed for
Potential problems Java has the reputation of being slow & unpredictable
Java programs are large
Garbage collection and run time checks seem a bad idea
Interpreted languages are too slow
Reasons to Use Java
Don’t want to give up a language we are used to
Java programs are more reliable Many errors caught at source/run time level
More secure
Safety is critical
Easier to verify
Exceptions, threads, synchronization built in
Data structures that are thread safe
Using Java
Two efforts under way Address embedding issues
Address real time issues
Understanding these helps understanding Embedded and real time programming in general
Embedded Java
Basic Problems VM, JIT compiler, libraries are big (64M, 256M)
Scheduling abstraction used for threads is not fixed priority
Java emphasizes device independence
No access to physical memory (IO)
How can these problems be addressed?
Java ME and pJava Attempts to address size & independence issues
Organized in terms of configurations Configuration = broad range of similar devices
Determines what libraries to include
Determines JVM features to include
Scalable OS Select the features needed for the application
Can run in 64k in smallest configuration
No verification, finalization, class loader, thread groups, reflection
Limited I/O, error handling
Limited data types (no 64 bit, no multidimensional arrays)
J2ME Configurations
Connected Devise Configuration Limited set of library classes
32 bit, 4MB memory required
Most code sits in ROM
Connected Limited Device Configuration Even more limited
512K memory required
J2ME Profiles Support sets of similar devices
Mobile Information Device Profile
Touch screen or keypad, 96x54 or larger display
Wireless networking
Runs with 32k ram, 8k eeprom, 128k flash
Used in PDAs, mobile phones, pagers
Optional packages
Mobile Media API support multimedia applications
Other Embedded Javas
Java Card – applet on a smart card
Java TV – for set top boxes
Java Real Time
Embedding is easy Just pare down the language and libraries
Real time requirements are more difficult Affect the execution model of the language
Nothing in Java spec makes wall-clock guarantees
Garbage collection pauses do not affect the semantics
Thread priorities exist but aren’t well defined
Compiled Approach
Fiji VM
Precompile Java to C OS includes the garbage collector
Overhead about 30% over straight C code
Max time of about 10% long
But this is experimental, not a guarantee
JSR1: Real Time Java Specification
Thread scheduling and dispatch (tasks)
Memory management
Synchronization and resource sharing
Asynchronous event handling
Asynchronous transfer of control
Asynchronous thread termination
Physical memory access
Thread Scheduling Basic real-time scheduler is included
Priority based and preemptive
At least 28 priority level
Can define your own schedulers
Schedulable Objects
RealtimeThread :: uses real time scheduler
NoHeapRealtimeThread :: may not allocate or reference normal heap
Can run in preference to GC
GC can be preempted
Memory Management
Garbage collection is a problem Not that it exists, but that it makes response time
unpredictable
Why not just interrupt the garbage collector
Needs to lock all of memory?
Actually needs to lock all of garbage collected memory
Hence create memory areas that are separate
Memory Management Memory Areas
Regions of memory outside of traditional Java heap
Don’t have to e garbage collected
Scoped Memory
For objects that have a lifetime defined by the scope
Physical memory
Specific regions for specific purposes
Immortal memory
Never collected
Budgeted allocation
Limit allocation for a schedulable objet
Can be preallocated
Synchronization Problems
Synchronized data structures
Interactions with scheduling
Blocking times as part of max response time
Wait Queues as a primitive class
Dealing with priority problems
Priority inheritance supported
Priority ceiling emulation supported
Wait-free classes for non-blocking shared access
Fixed upper bound on entering an unlocked synchronized block
Asynchronous Event Handling
Bind handlers to internal and external events
External events Signals, timers, interrupts (classes to support these)
Asynchronous Transfer of Control
Can you interrupt or stop a thread in Java? What do Thread.interrupt() and Thread.stop() do?
Schedulable objects Can declare throws AsynchronouslyInterruptedException
These can be safely interrupted
When interrupted, interruptAction() is invoked
Can stop a thread through implicit exceptions
Homework
For next week (10/26) Present you project to the class
Plans, progress to date
Project model
Tasks and model(s) for each task
Hand this in
Can be part of presentation