We deliver an extensive library to help creating applications for mono, fast and easy.
This page describes how we envision the API for mono. Here we describe the basics and our thoughts on what the API will provide.
The API overview is sketched below. The software stack is build on the mbed framework, and uses this for system initialization and low-level I/O. The mbed framework is a very strong foundation and it has great scalability, making it perfect as the basis of the mono API.
The planned API for Mono, build on the ARM mbed and CMSIS stack.
The Arduino compatibility layer is intended to be placed above the mbed core, but we might move it down to the CMSIS level – just like the official Arduino Due software library.
mbed is an open source embedded application framework created by ARM. It is built upon the low level software interface CMSIS (Cortex Micro-controller Software Interface Standard), also by ARM. The mbed framework creates a uniform and standard programming interface to Cortex-M micro controllers. Much like the Arduino API, mbed includes C++ classes to utilize different communication protocols and provides the convenient
We chose mbed as a foundation for the mono API because it is very well structured and documented. The framework contains very strict abstraction layers and defines a clear interface between target dependent code and independent code, also known as a HAL (Hardware Abstraction Layer).
Where the Arduino API use the
loop() functions, mbed only has the well known
main() function, just like standard C and C++ applications.
See the mbed.org website for more documentation.
Because mono comes with integrated peripherals we can deliver a high-level API utilizing these. You do not have know about SPI or I2C communication protocols, we abstract all this away. You can configure and access the integrated peripherals using C++ classes such as:
Because all mono models comes with integrated touch display, a UI and graphics library is essential to us. We plan to let the display API provide graphics routines at to levels. The first is a low level interaction with drawing routines, to draw custom and basic shapes like rectangles and lines. The second is a high-level class based API to create user interface elements. These UI elements will respond to touch input using callback function or events, just as you would expect from modern UI frameworks.
Some mono models comes with built in Wi-Fi or/and Bluetooth connectivity. Because of the limited flash memory and resources of a Cortex MCU we choose to offload all handling of wireless protocols, TCP/IP, DNS and even HTTP to the co-processors of the wireless modules. The internet and wireless configuration API’s will abstract this communication away, and frees the main CPU from the heavy tasks of decoding TCP packages etc.
Because many internet based services like IFTTT.com and Philips Hue uses HTTP calls we will have a strong emphasis on parsing HTTP requests and JSON objects in the API. The API classes will include powerful methods to decode and encode JSON objects and send different HTTP request such as GET, PUT and POST.
We chose to use the mbed framework as base for mono, and mbed include a subset of the standard libc I/O subsystem. This means we can provide basic libc functionality like file handles,
writef etc. Utilizing these standard I/O functions we provide easy file access to the build-in SD card reader.
Especially for games or other graphics heavy applications this SD storage will prove very handy. Because the MCU flash memory is limited, we will create a resource system, where application resources is placed in the external SD storage, rather than compiled into the flash memory.
The API contains classes to get sensor data from the many integrated sensors in mono. The data can be delivered as a constant flow using events or callback functions, or it can be retreived through polling. The first two methods are particularly useful when you need a fixed sample rate of sensor data. Hardware button inputs is part of this event based API. The mono API for sensors does not include communicating directly to underlying analog pin input, communication or PWM controllers on the CPU. Here you must use either the mbed I/O classes or the Arduino interface.
Because we envision most mono use cases to be battery powered, power control and management is important. We plan to provide you with access to the current battery output voltage. This voltage gives to hints to when the battery is low, but cannot give you precise indications of the remaining capacity of the battery. Calculating the remaining capacity of lithium-ion battery is difficult and requires dedicated hardware and software routines.
The Cortex MCU has several power preserving modes. Our power API will provide you with routines to put mono into standby or sleeping states. Also the API will offer functions to power down peripherals such as sensors, LED backlight or wireless modules. Because there is no on/off button on mono, this API documentation will also encourage you to think about how and when your mono application should go into sleep mode.
Lastly the power API controls display brightness, by managing the PWM duty cycle of the display backlight LEDs.
To ease the learning curve on programing mono, it is compatible with the Arduino API. This means it provides the same I/O as the standard Arduino UNO. If you use the Arduino Shield Adaptor extension board, mono will be pin compatible with Arduino. The plan is that you should be able to run software targeted for the Arduino API, without any modifications in the source code.
For clarity: We cannot be binary compatible with Arduino applications because Arduino uses an Atmel AVR micro-controller, which is a different CPU architecture. This is also true for Arduino Due which is ARM based. Your existing Arduino sketches must be recompiled to target mono’s PSoC5 processor.