1 / 40

ASU Real-Time Operating System.

ASU Real-Time Operating System. Supervised by: Dr. Mohammed Sobh. Agenda. Overview Background Implementation Demo Conclusion Future Work. Overview. Operating System Based on FreeRTOS. Communication. Processing. Serial Communication. USB Communication. C code. Java code.

garran
Download Presentation

ASU Real-Time Operating System.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ASU Real-Time Operating System. Supervised by: Dr. Mohammed Sobh

  2. Agenda • Overview • Background • Implementation • Demo • Conclusion • Future Work

  3. Overview

  4. Operating System Based on FreeRTOS Communication Processing • Serial Communication. • USB Communication. • C code. • Java code.

  5. Background

  6. Hardware • AT91SAM7S-EK evaluation board from Atmel • AT91SAM7s256 J-Link debugger.

  7. Software FREERTOS. • Support ARM7 architecture. • Scheduling policies. • Memory management. • Technical support.

  8. FREERTOS • Definition • Scheduling • Intertask communication & resource sharing • APIs

  9. Coding phase requirements Complete understanding of : • ARM architecture. • using J-Link debugger. • Keil IDE. • IAP (in application programming). • FREERTOS as operating system. • Using peripherals (like Timers ,UART , USB).

  10. Coding phase • Debug test Projects on the kit(like flashing leds). • Porting FREERTOS to the AT91SAM7S-EK. • Receive data from PC to the board Ram, through UART. • Move data from RAM to ROM using IAP. • Send libraries and function and execute them.

  11. Smart Cards

  12. A virtual Machine A virtual machine (VM) is a software implemented abstraction of the underlying hardware, which is presented to the application layer of the system. Byte code file: it is the file generated after compiling a .java file and the name byte code is given may be because of the structure of the instruction set of Java program. 

  13. Java Virtual Machine • JVM gives Java the flexibility of platform independence. • Java byte code is an input to Java Virtual Machine. • JVM reads this code and interprets it and executes the program.

  14. Why Don’t we use JVM? • Because there are resource-constrained device ;for our kit (1.2K of RAM, 16K of nonvolatile memory (EEPROM or flash) and 32K of ROM). • The only workable option is to implement Java Card technology as a subset of the Java platform.

  15. Java Card Virtual Machine • A Java Card is a smart card that is capable of running Java programs, and complies with the Java Card standard specifications issued by Oracle.

  16. Java Card Features • Platform independence. • it promises the ease of programming in Java to the world of smart cards. • portability and security. • Data encapsulation • Applet Firewall • split virtual machine • Off-card • On-card

  17. Java Card VM Subset‘cap (converted applet) file’ • Each CAP file contains all of the classes and interfaces defined in one Java package. • A CAP file consists of a stream of 8-bit bytes. • A Java Card CAP file consists of a set of components. • Each component describes a set of elements in the Java package defined, or an aspect of the CAP file.

  18. Component Model component { u1 tag u2 size u1 info[] }

  19. Design .applet .java .class .cap .ijc 19

  20. Design Card applet loader Execution engine Native methods support parser Cap file components Virtual Machine

  21. Implementation

  22. Porting ASU_OS RTOS 1- Writing in ROM by EFC. 2- Communication Protocol uses physical medium (Serial Communication) by USART. 3- Mapping flash memory by the File System. 4- IAP updated for sending libraries and Control Tasks. EFC USART File System IAP Update

  23. Sending a Library Multiple function Library ASU_OS Sending a library from Computer to system serially

  24. File System

  25. Allocation o OS

  26. Allocation o OS

  27. Compaction o OS

  28. GUI (User Interface)

  29. Connection

  30. Control Running Tasks

  31. JCVM Implementation • Parsing • Loading API packages • Installing • Processing • Native

  32. Parsing Header_component Directory_component{} ReferenceLocation_component{} Applet_component{} StaticField_component{} Import_component{} ConstantPool_component{} Method_component{} Class_component{} Descriptor_component{} Export_component{}

  33. Loading API packages • Java.Lang • Java.framework • JNI

  34. Installing • Call install() method to: • Create an instance of the applet • Create various objects • Set some initializations • Register this instance

  35. Processing • Call process() method to: • Process the functionality of the applet.

  36. Native • Java Card technology doesn’t support JNI • CAP file format • API

  37. Demo

  38. Conclusion • User can send a Library to the system and add more functions and updates. • Java Run Time environment is ready to receive java code to be executed. • Sending files could be through USB or Serial Communication.

  39. Future Work • Supporting more communication protocols : ex: CAN, Ethernet • Implementing Driver libraries for common devices : Motors • Implementing the HAL for different microcontrollers • Extensive Debugging of the current system. • Support all byte Codes. • Memory & Speed Optimization.

More Related