1. CSCI1600: Embedded and Real Time Software Lecture 18: Real Time Languages Steven Reiss, Fall 2015

2. Programming Language Wars

3. 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?

4. 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

5. Criteria For Choosing  Low Power consumption  Other factors  Fault tolerance  Writing reliable code (verifiable, testable, understandable)  Writing secure code  Code understandability

6. C versus C++ versus Assembler  Footprint  Performance  Real time features (interrupts, synchronization, scheduling control)  Fault tolerance  Reliability  Security  Understandability

7. Why Not Java  What are the pros and cons?

8. 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

9. 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

10. Using Java  Two efforts under way  Address embedding issues  Address real time issues  Understanding these helps understanding  Embedded and real time programming in general

11. 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?

12. 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)

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. Asynchronous Event Handling  Bind handlers to internal and external events  External events  Signals, timers, interrupts (classes to support these)

23. 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

24. 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