csci1600: embedded and real time software lecture 18: real time languages steven reiss, fall 2015

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