CSCI1600: Embedded and
Real Time Software
Lecture 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


Physical memory


Specific regions for specific purposes
Immortal memory


For objects that have a lifetime defined by the scope
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