Download specifications
B-ON - Memory usage control & sequences start-up
Specification number: ESR001 More details| Version: | 1.2-F |
| File description: | This specification 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
resources: - 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. |
MICROUI - User Interface for embedded Java systems
Specification number: ESR002 More details| Version: | 2.0-B |
| File description: | 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 device. This specification is multi display ready and multi touch ready. Other main features are: - 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 A device built on this specification must have the following minimum characteristics: - 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. |
SNI-GT - Safe Native Interface for GreenThread Context
Specification number: ESR012 More details| Version: | 1.2-H |
| File description: | The SNI-GT specification is dedicated to
green threads virtual machine architectures. the SNI-GT specification allows
to: - Call a C function from a Java method - Access Java Immortal arrays (See the B-ON specification to learn more about immortal objects) in a C function - Manage in C the life cycle of the Java world (aka the vm) from the RTOS |
SP - Shielded Plug Profile Specification
Specification number: ESR014 More details| Version: | 2.0-A |
| File description: | 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 block - 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 program. Reading and writing in the shared memory are operations with predictable performance characteristics. |
KF - Trusted Execution Environment
Specification number: ESR020 More details| Version: | 1.4-F |
| File description: | This specification defines a Trusted
Execution Environment (TEE) for
software modules, called Features. Each module runs in an isolated
execution environment, which provides a sandbox for module's resources
such as RAM control, CPU bandwidth control, integrity of applications,
code execution control, along with confidentiality of module's assets.
Kernel & Features semantic (KF) allows an application to be split
between multiple modules: (1) the Kernel, (2) zero or more modules. A
module is fully controlled by the Kernel: it can be installed
(dynamically or statically per-installed), started, stopped and
uninstalled at any time independently of the system state. In
particular, a module can always be killed at any time and all its owned
resources (RAM, flash, ...) be removed without compromising the rest of
the system. This specification serves as one of the most secure foundation for implementing embedded software in MCU/MPU based electronic devices. |
Home-EZ - Language specification
Specification number: ESR023 More details| Version: | 1.0 |
| File description: | The HomeEZ language allows one to write
scenario for smart markets, such as Smart Home, so its name. It is designed
to be simple so that no particular notion about software programming is
needed to achieve fluency in the language. Its purpose is to handle and to
describe automation applications. It has two levels of descriptive power:
the first one deals with straight forward objects (naming, linking, binding
actions on events), while the second one provides a more expert semantic
with classes that organize manipulated concepts. HomeEZ is not typed, has an XML based syntax. The concepts provided by HomeEZ are : -automatic pool of devices management -construction and manipulation of direct acyclic graphs of devices (name space) -events triggering (time, asynchronous (hardware) events, ...) and action invocation -atomic states of devices management and variables manipulation -scenario instance and scenario classes -expressions computation model |
LWM2M-MQTT - LWM2M over MQTT
Specification number: ESR030 More details| Version: | 1.0-A |
| File description: | The LWM2M protocol is becoming the standard
for remotely managing a device through a set of
normalized operations. However, although its semantics can be implemented on
any kind of
protocols, the LWM2M specification is written in a way that it is tightly
coupled to the CoAP
protocol, compliant with a lossy network such as UDP or SMS transport. The goal of this specification is to propose an alternative composition of LWM2M semantics with CoAP message format based on MQTT publish/subscribe paradigm on top of a TCP transport. |
Comments are closed.