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  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