This javadoc focuses on devices with
non-volatile and volatile memories (eeprom, flash, ram, ... ). At the
application level, it focuses on applications that have some sort of
initialization phases before entering into a mission phase that exists until
the device is shut down or rebooted. This specification allows to fully
control memory usage and start-up sequences on devices with limited memory
- Controlling the sequence of initialization 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 done in RAM to be
manipulated: they are alive from system's startup.
- Defining immortal read-write objects.
This specification serves as a very robust foundation for implementing
embedded Java software.
This specification aims at providing the
minimal cornerstone for quick construction of advanced, portable and
user-friendly applications for a wide and heterogeneous range of devices
with just-what-is-needed resources. This specification 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.
This specification takes its roots from established patterns such as MVC and
MVP. It allows anyone to use it with minimal learning cost: it is a
straightforward framework to design with. The main asset of this
specification is probably its flexibility to fit customer needs at minimal
cost: rapid design of HMIs without jeopardizing the Bill Of Material of the
This specification is multi display ready and multi touch ready. Other main
- Models, Listeners, Events, Event generators, Event handling, Pumps, Thread
- Screens, Display, Displayable, View, CompositeView, Alphanumeric Display,
LEDs, Audio Tones
- 2D rendering, Image transformation, Tranparency, Flying Image, Fonts
- Command, Button, Keyboard, Pointer, Keypad, State
A device built on this specification must have the following minimum
- 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.
The SNI specification is intended for
implementing native Java methods in C language. It allows to:
- Call a C function from a Java method
- Call a Java method from a C function
- Access an Immortal array (see B-ON specification to learn about immortal
objects) in a C function
- Create an Immortal array in a C function
- Access a C struct in a Java method
This specification provides the segregation
of the processes which can be written either in C or Java. It allows the
certification of each individual part separately.
The data sharing between processes uses the concept of shared memory blocks,
with introspection on those blocks. The provided facilities include:
- Notification when the content changes
- Reinitialization of the block, testing the presence of data in the data
- A mechanism for serialization and de-serialization
The SP specification allows the creation of several data stores. These can
be entirely defined statically, or increased during the execution of a
Reading and writing in the shared memory are operations with predictable