Embedded systems:

Embedded systems are different from normal J2SE applications or even J2ME games and applications on phones and PDAs because, in these latter cases, we usually know we are running a program on a sort of computer. An embedded system does not normally look like a computer, but looks like a printer or a camera or whatever the containing device may be.

Embedded systems often have rather specialized and possibly demanding requirements. They may be small in physical size, with limited resources of memory or processing power, as we have seen for J2ME systems. They are often used to monitor and control equipment and so may need to operate as real-time systems.

A real-time system is a computer system that needs to respond within specified time limits in order to function properly. Some real-time systems, known as hard real-time systems, cannot permit any time deadline to be missed - failure to meet a deadline may be regarded as a failure of the system, possibly with serious consequences for the equipment being controlled or for human life. For example, modern road vehicles are often fitted with air bags that should infiate in the case of an accident, or automatic braking systems (ABS) which help drivers to stop quickly and safely. Both these systems are controlled by embedded computers and the timing of their responses is critical - there is no point in the air bag infiating correctly several seconds after a crash. Other systems may have timing requirements, but occasional missed deadlines may be acceptable - these are known as soft real-time systems. Many multimedia systems are of this type - for example, occasional late or missed frames in a video stream are normally acceptable.

We saw in a previous section that small scale systems, with limited resources, are to some extent catered for by J2ME. This does not, however, address the special needs of real-time systems. These include:

• predictable timing behaviour of code;
• threads are useful but must be managed carefully to avoid blocking and deadlock, and to allow prediction of their timing behaviour; 
• Java garbage collection can disrupt time-critical activities;
• systems may be safety-critical or need very high reliability;
• some systems may require high performance from limited resources - standard Java's use of interpreted bytecode may be a problem here.

Because of this, there has been a considerable amount of work over several years on developing specifications for a real-time Java. This has been associated with a fair amount of politics, such as rival working groups from different sets of manufacturers, but these differences have now been settled. The outcome was a standard specification of what is required from a real-time version of Java - the Real-time Specification for Java or RTSJ. There are also a number of products that comply with some or all of the requirements of RTSJ. The products typically involve a special class library, a specialized compiler and other development tools, and special versions of the Java Virtual Machine (JVM) that run the Java programs on the embedded devices.

We have seen that execution of Java code is normally a two-stage process of compilation followed by interpretation, as shown in Figure.

Figure: The standard Java compilation and interpretation process

This two-stage execution process may result in relatively slow execution, which is unacceptable in some real-time systems. Compilers may overcome these performance limitations in one of two ways. Native compilers translate Java source code directly into the native code required by the processor on the embedded device, thus cutting out the bytecode interpretation process, as shown in Figure. This may improve performance and reduce the memory required to run Java program, when compared to the normal process of interpretation by the JVM. However, it does lose the major advantage of Java bytecode being platform independent.

Figure:  The action of a Java native code compiler

Just-in-time (JIT) compilers operate by compiling parts of the Java program through to native code, but each part is compiled only just before it is first required for execution. This can be particularly effective if that part of the program is executed repeatedly, for example, in a loop. Figure 25 illustrates this process. These sort of tools mean that Java can achieve high performance if required in embedded systems.

Figure: The action of a Java JIT compiler

Java Assignment Help - Java Homework Help

Struggling with java programming language? Are you not finding solution for your Embedded systems homework and assignments? Live Embedded systems experts are working for students by solving their doubts & questions during their course studies and training program. We at Expertsmind.com offer Embedded systems homework help, java assignment help and Embedded systems projects help anytime from anywhere for 24x7 hours. Computer science programming assignments help making life easy for students.

Why Expertsmind for assignment help

1. Higher degree holder and experienced experts network
2. Punctuality and responsibility of work
3. Quality solution with 100% plagiarism free answers
4. Time on Delivery
5. Privacy of information and details
6. Excellence in solving java programming language queries in excels and word format.
7. Best tutoring assistance 24x7 hours