1 / 18

D1.5: Choice of Platform

D1.5: Choice of Platform. Prof. Koen De Bosschere. Platform requirements. Must enable component model Must support (soft) real-time constraints High software productivity Must be well-defined and have stable APIs Support for remote connectivity Support for user interface

virote
Download Presentation

D1.5: Choice of Platform

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. D1.5: Choice of Platform Prof. Koen De Bosschere

  2. Platform requirements • Must enable component model • Must support (soft) real-time constraints • High software productivity • Must be well-defined and have stable APIs • Support for remote connectivity • Support for user interface • Must enable reuse and portability • Must run on off-the-self hardware platform

  3. Our choice: Java • Java is well-defined and has stable APIs • Pure object-oriented language • Many libraries available • Many services are for free (TCP/IP, multithreading, …) • Higher software productivity due to higher abstraction level • Promising technology for embedded systems

  4. Java virtual machine • Shields the underlying hardware architecture • Available for a wide range of hardware platforms: standard edition, enterprise edition, micro edition • Has kernel functionality or can be run on top of a real-time operating system • Allows access to hardware by means of native routines

  5. Design Methodology Goal: evaluate / merge different methodologies suitable for mid-scaled & large-scaled embedded systems • Component Based • Component Reuse • Hardware/Software Co-Design • Co-Evolution • Multi-Site Development

  6. Component Architecture • A component architecture provides • A central component system to glue components • A hardware abstraction layer • A mechanism for integrating existing components through wrappers • Java makes (2) and (3) easier • invoke • native C interfacing • try/catch/throw clauses • Focus can then be on (1)

  7. Debugging • Clear separation between the Java and JVM level • ICE functionality can be implemented in software (instrumented JVM) • Cross compilation on any platform: any JVM can serve as simulator • No pointers, no memory leaks; Java application is “crash free”

  8. User interface • Java has its own GUI-libraries (with adaptable look-and-feel) • Remote user interface (service interface) easy to realize thanks to the internet connectivity

  9. Common prejudices • Java is too slow • Java is not suitable for hard real-time systems • Java requires extra memory • We can do better in C or C++

  10. Java is too slow • Should be ok for our application • Can be improved by • Statically linking the application • Compiling a class file when downloading it • Controlling the garbage collector • Calling low level methods • Calling native C routines where necessary

  11. Not suitable for hard real-time systems • JBED is hard real-time • JVM also runs on top of a standard real-time kernel

  12. Java requires extra memory • Up to 1 MB • But: • There are several alternatives < 200 kB • KVM requires only 40 kB

  13. We can do better in C or C++ • Isn’t this a similar argument to C/ASM debate?

  14. Hardware • Processor Board with Ethernet connectivity, ROM, Flash, RAM Interface to the camera (USB, Video signal?) • 32-bit Processor • Small LCD-display

  15. Reported problem areas • Integration of third party software; JVM yes, class files no problem! • Generation and maintenance of documentation: JavaDoc • Debugging: memory leaks, ISR no pointers, better support for ISR • Lack of multiplatform IDE, tools one platform • Effort estimation techniques (metrics) • Performance estimation techniques (cross development)

  16. Reported problem areas • Hardware problems (easier to trace) • Changing requirements (also: research during development) (OO + CBD) • Lack of qualified personnel (standard language; easier to find) • Serviceability (applets, TCP built-in, security) • Growing complexity of software (OO+CBD) • Low software productivity (higher productivity in Java)

  17. Reported problem areas • Need for rapid prototyping (OO+stubs) • User interface specification is difficult (multi-platform user interfaces) • Testing is time-consuming (white, black box, glass box) • Multi-site development • Versioning of the design • Deadlines

  18. Conclusion • Java will enable us to • Implement our case • Carry out our workplan • Can help the companies in solving some of the reported problems

More Related