List of released and in-progress ESRs
||Lastest Released Version
||Current Working Version
||APIs Java doc
This B-ON specification
focus on devices that have non-volatile memories and volatile ones (eeprom, flash, ram,...).
At the application level, it focuses on applications that have some sort of initialization phase before
entering into a mission phase that then exists forever until the device gets shutdown or reboots.
B-ON allows to fully control both memory usage and start-up sequences on devices with limited memory resources:
B-ON serves as a very robust foundation for implementing embedded Java software.
- controlling the initialization sequence in a deterministic way,
- defining persistent immutable read-only objects that may be placed into non-volatile memory areas,
and do not require copies to be made in ram to be manipulated: they are alive at system startup.
- defining immortal read-write objects that are always alive.
Embedded Device Configuration
Embedded Device Configuration defines the “lowest
common denominator” standard APIs for a wide range of embedded devices, and is transversal accross many markets and provide APIs that are generic.
User Interface for embedded systems
MicroUI, Micro User Interface, aims at providing the minimal cornerstone for the quick construction of advanced, portable and user-friendly applications for a wide and heterogeneous range of cost effective devices with just-what-is-needed resources.
MicroUI has many notable characteristics that makes it a very attractive solution for embedded software development. MicroUI serves as a very robust foundation for implementing complex widget and/or windowing systems.
Typical devices have some form of display, some input sensors and potentially some sound rendering capabilities. This specification spans a potentially wide set of devices.
MicroUI takes its roots from established patterns such as MVC and MVP.
It allows anyone to use MicroUI with minimal learning cost: MicroUI is a straightforward framework to design with.
The main asset of MicroUI is probably its flexibility to fit customer needs at minimal cost: rapid design of HMIs without jeopardizing the Bill Of Material of the device.
MicroUI is multi-displays ready and multi-touch ready. Other main features are:
A MicroUI device must have the following minimum characteristics:
- Models, Listeners, Events, Event generators, Event handling, Pumps, Thread safe
- Screens, Display, Displayable, View, CompositeView, Alphanumeric Display, LEDs, Audio Tones
- 2D rendering, Image transformation, Tranparency, Flying Image, Fonts
- Command, Button, Keyboard, Pointer, Keypad, State
- Display: optional (several displays are permitted); size: any, type: graphic or alpha-numeric,
depth: 1-bit or more, pixel aspect ratio: approximately 1:1, alpha numeric: at least one line with one character
- Input: optional; Any user-input mechanisms: buttons, rotary switches, keyboards, multi touch screens, mouse-like-pointers, etc ...
- Output: optional; Any sound mechanisms that provide the ability to play tones: buzzer, PWM, etc ..., Any kind of LEDs.
- Memory: about 30 kilobytes of non-volatile memory if the whole MicroUI implementation is
required by an application.
For graphical screens, at least one display size of volatile memory for each graphical screen. For a 128x128 monochrome display, this is 2 kilobytes of ram; for a 320x240 16bit color display, this is 150 kilobytes.
Hard Real Time Java
Deterministic Java for safety critical systems.
- [HRTJ] is about hard real-time, not soft real-time.
A hard real-time system (i.e. software & hardware), is a system that guaranties that expected
behaviors will occur at the right time. The distinction between hard and soft real-time is between
guaranteeing and best-effort.
- Determinism. Although hard timing constraints may be specified using any usefulness functions or probabilistic
constraints, the HRTJ specification uses deterministic hard real time constraints: hard real-time means
- Certification. [HRTJ] is designed with one goal in mind: to make it possible to have Java software certified at the
highest possible certification levels, like DO178 level A or IEC61508 SIL3 for example.
Therefore [HRTJ] targets
libraries that “due-to-their-sizes” can be certified at a reasonable cost.
- [HRTJ] relies on deterministic GC.
A Java system with no Garbage Collection (GC) is NOT ANYMORE a Java system, while the GC
contributes to building reliable valuable software at low costs, by freeing the programmer from the complex and
error prone explicit memory management.
Need to Log in
OSGi-ED : OSGi for Embedded Devices
The OSGi ED profile proposal (RFP126) for a wide range of electronic devices, addressing cost and robustness concerns.
The “embedded world” has two characteristics that makes it appealing and challenging for software engineers: (1) resources may be scarce, (2) software cannot fail. OSGi-ED intends to address these two characteristics by making it easier to design software with these two constraints in mind.
Embedded software is not just "software on electronic machines". Embedded applications usually involve optimizations that strive to create software for specific hardware. System integration is one of the most important aspects, heavily impacting testing and debugging. This is one big difference between a PC-based system and an embedded device. For PC-based systems, the development machine is the machine that will execute the application (or a machine really similar). For embedded systems, there are actually two systems: one used to design the application (usually a PC-like desktop) and one to run the application (the embedded device).
If OSGi-R4 brings benefits in terms of software architecture for PC-like systems, OSGi-ED intents to bring the same benefits to the embedded world, perhaps even greater benefits given its focus on strong robustness. The OSGi-ED robustness philosophy may be summarized as: A faulty bundle cannot cause the failure of the entire platform.
The OSGi-ED profile specification introduces high robust semantic:
- a thread-safe framework.
- true bundle context from which private classes cannot escape.
- no stale reference, introducing a notion of object ownership.
- transactionnal bundles life cycle.
- a controlled initialization sequence upon each reboot/restart.
- DSDO, DSD1 and DSD2 that characterize how software is loaded into devices.
OSGi-ED is related to the RFP 126 of the OSGi Alliance:"RFP 126 : An OSGi Profile for Embedded Devices".
Micro Widget Toolkit
defines a graphical environment that avoids portability problems so that an application
running on a constrained device would run on other hardware devices such as cellphones-PDA or
PC. The aim of this library is to be sufficient to create complex applications with a minimal framework.
|MWT is a widget toolkit designed for wide range of devices, including
embedded devices with limited processing power. Although this specification defines minimal requirements,
devices with more resources may also benefit from MWT's special care in employing resources to
their best advantage.
MWT defines three distinct roles: Widget Designers, Look and Feel Designers and Application
The same binary HMI application works the same on all devices that provide a compliant MWT framework (embedded devices, cellphones, Android-based devices, setopbox-TV, PC, etc...) allowing for true ubiquity of applications accros product lines.
- Widget Designers : Widget Designers create new widgets by specifying widget contents and behavior. They defined
listeners that the application rely on in opposition to internal events that are not exposed
to application designers, create new animations, etc.
Look and Feel Designers : Look and Feel Designers create consistent sets
of rendering systems in order to define the way the
widgets are displayed on screens.
Application Designers: Application Designers create the HMI and the functional parts of the application. Their role is
similar to the role for other toolkits: they use widgets defined by Widget Designers and should not
consider widget look and feel.
Simple Native Interface
SNI is intended for implementing native Java methods in
C language. It is declined in two specifications: full-featured SNI, and a lighter edition SNI-GT.
SNI allows to:
- SNI allows to call a C function from a Java method using base types arguments and arrays of base types arguments.
- SNI allows to call a Java method from a C function using base types arguments and arrays of base types arguments.
- SNI allows to access a Java Immortal array in a C function.
- SNI allows to create an Immortal array in a C function.
- SNI allows to access a C struct in a Java method.
SNI-GT, Simple Native Interface for GreenThread Context, is a dedicated specification for greenthread vm architecture.
- SNI-GT allows to call a C function from a Java method using base types arguments and arrays of base types arguments.
- SNI-GT allows to access a Java Immortal array in a C function.
- SNI-GT allows to manage in C the life cycle of the Java world (aka the vm) from the RTOS.
SNI (rev G)
SNI-GT (rev G)
eClasspath takes roots in GNU-CLASSPATH v0.98, but tuned for the embedded world.
Compiling against eClasspath allows binary Java applications to be fully portable
across all the existing different Java Runtime execution environment (J2ME-CLDC, J2ME-CDC, Foundation, J2SE
J2EE, OSGi Minimum Environment, ...).
eClasspath provides APIs for concepts such as File System, Sockets,
Collections, Time Zone, ... . Eclasspath fills the gap between embedded
devices and PC-like devices.
eClasspath is split in separated sub-profiles to limit the use of the whole library when only depending on sub-profiles
(core, fs, net, collections, format, locale, math, nio, properties, sql, streams, timezone,
timer, url, zip).
Need to Log in