Categories: "Software" or "Android" or "Eclipse" or "Linux"

Pages: 1

In December 2016, Google presented its new operating system for the Internet of Things (IoT), called Android Things. As the name implies it’s a derivative of Android, just like Android Auto, Android TV and Android Wear. It’s supposed to run on low-power embedded devices such as emtrion’s SBC-SAMA5D36, which is well suited to be used in devices such as fridges, ovens, microwaves and many more. Unlike Android it can be run with or without a display and runs only one single application, called the home activity, which is launched on boot. Google decided to implement the Java Runtime on Android Things, so that Android App developers are able to write IoT apps in their familiar Android Studio environment. To this day Google has not yet released the source code of Things but a few images for different hardware platforms. In an internal study, we at emtrion have ported Android Things to our single board computer SBC-SAMA5D36. The SBC-SAMA5D36 is well suited for the use in IoT environments with its numerous peripheral connections and the possibility to use a touchscreen.

Android Things on emtrion's SBC-SAMA5D36
Android Things on emtrion's SBC-SAMA5D36

A key part of Android Things is the Peripheral I/O API, which is used to communicate with sensors and actuators via GPIO, PWM and serial protocols such as I2C, SPI and UART. Another central component of Things is the User Driver API, which introduces so called user-space drivers. With this approach developers can embed their peripheral hardware into the Android framework which has one main advantage, namely to abstract the application code from the hardware platform, so that once written, the application code can be ported to different hardware devices. This allows the reuse of code. Using the native PIO API it’s now possible to write Android Things Apps exclusively in C/C++ without the need of Java.

Smartphone operating system market share
Smartphone operating system market share [1]

Looking at the growth of Android market share at embedded devices like smartphones and the rise of IoT in the last few years, a good argument can be made that Android Things will be the next big "thing" in the near future.

[1] https://www.statista.com/chart/4112/smartphone-platform-market-share/


Form is loading...

New mainline-based i.mx6 BSPs

 03. May 2017, by emtrion
Categories: Software, Linux, i.MX6, Android

We recently released our new mainline-Kernel based Debian and Yocto BSPs for our i.mx6 based System on Modules. In this article we'll give you a short overview of the advantages of the new BSP era! Beside the recent Kernel Versions delivered, new userspace APIs have to be used to access peripherals.

Features

The most outstanding feature of the new BSPs is that they both are based on Linux 4.9 LTS with some additional drivers and emtrion's device trees. Beside that they are identical to the upstream Long-Term supported Kernel which allows easy maintenance of security patches and fixes to certain subsystems. Beside that the Kernel does also make use of the Open Source etnaviv GPU driver for OpenGL acceleration. Also included is the Open Source driver for the Video Processing Unit (VPU) contained in the i.mx6. On the other hand, we decided to develop our Yocto Morty (2.2) and Debian Stretch (9) based BSPs in a way that both share key components in the same version allowing developers to change between the BSPs without porting applications. To achieve that we use the same Kernel, mesa (12.04), gstreamer (1.10)  and Qt (5.7) versions on both BSPs.

Etnaviv Graphics Stack

One of the recent changes in the Mainline Kernel is its native support for the Vivante GPU contained in the i.mx6 and several other SoCs. As you might know from desktop Linux systems the nouveau driver is a reverse engineered driver for Nvidia cards, the etnaviv is the one for Vivante SoC's GPUs. As a complete graphics stack requires more than a working Kernel Driver, the userspace components providing OpenGL functionality are delivered by the mesa project like many other Open Source graphic drivers. One of the advantages of the Open Source graphics stack is that it is not only possible to use most Debian packages without recompilation, but it is also possible to upgrade and maintain your system without the lockdown to a specific Kernel or userspace version.

Video4Linux VPU Driver

For quite some time the VPU, which is in fact a CODA DSP included in the i.mx6, is supported by the video4linux subsystem in the Kernel. In contrast to the software delivered by NXP (formerly Freescale) it is only capable of decoding and encoding video streams. However there are outstanding advantages over the closed source drivers like the upstream gstreamer support. With current gstreamer versions, the device class the VPU belongs to, is automatically populated to the gstreamer elements as de-/encoder device and you're no longer restricted to a specific gstreamer release version. Also it's automatically used by many userspace media applications out of the box. In case of our Debian BSP that means, you can use almost every multimedia application, just as you can on your desktop, which uses gstreamer or video4linux without the need of a recompilation.

Limitations

Even if the current support for the i.mx6 is on the right path, there are limitations regarding the supported features. We decided not to include the Open Source camera driver on the i.mx6 in this release as it is under heavy development for now, just as the whole video4linux2 subsystem. However, our engineers are already testing the new drivers and software on our hardware platforms, allowing you to gain support as needed.

Also it is currently not possible to use OpenCL on the GPU due to missing support in the mesa implementation.

 

*NXP, Nvidia, Freescale, Vivante, Coda, OpenCL are registered trademarks of their respective owners.


Form is loading...

Beta Release of SBC-SAMA5D36 RootFS

 03. March 2017, by emtrion
Categories: Software, Linux, SAMA5D3

Today we released a beta version of a new root file system for the SBC-SAMA5D36. The main changes are a new Kernel Version and the use of systemd as init system. The Kernel version is 4.9 and is a longterm maintained kernel (see https://www.kernel.org/category/releases.html for more information). Systemd has some advantages over sysv like parallel start of services (if possible), delaying of the start until a service or device is really needed, and it is compatible to the old sysv init scripts. Systemd also has some other advantages like builtin monitoring of running services and restart of them if they crash or stop working and also better dependency handling of services.

Use this beta release at your own risk. There are some known issues and mabye also some unknown ones. We will stabilize this release during the next weeks and bring out a stable release. Please find the release under following link:

Link to Beta RootFS


Hint:

To get the debug-console of the SBC-SAMA5D36 you can use one of the cheap USB to serial converter that are offered on ebay, amazon, aliexpress and other sites. There are some modules that have exactly the same pinout as the SBC and can directly connect to it. So no extra wiring is needed, expect for an USB-cable, but they are much cheaper than the original FTDI USB-serial converters. But be careful to choose converters which are capable to handle 3.3V levels.

Cheap USB-serial converter example

 


Form is loading...

Renesas Synergy, a complete IoT ecosystem.

 15. December 2016, by emtrion
Categories: Software, Eclipse, embedded

Renesas Synergy is a complete and qualified platform with fully integrated software, a scalable family of microcontrollers, and unified development tools to speed embedded system developers’ time to market as they innovate new products.

At the heart of the Synergy Platform is the Synergy Software Package (SSP), which is qualified, supported, warranted, and maintained by Renesas. The SSP consists of a proven real-time operating system (RTOS), stacks for USB and Ethernet, file systems, a graphic users interface (GUI), and more – all accessible through a robust Application Programming Interface (API) to free designers from struggling with lower-level details.

Based on the very popular and customisable Eclipse IDE, the Synergy IDE is very simple to understand and to get the graps of it.

“Hello World” using the UART Application Framework

We will explore the Renesas Synergy UART Application Framework and walk through the necessary steps to get it up and running on a PE-HMI1 starter kit and say “Hello World!”.

Starting from a new project configured by the Synergy wizard to be a Blinky project, a developer can open the Synergy configuration file and navigate to the threads tab. After selecting the blinky thread, a thread stack can be added by selecting add Framework -> Connectivity -> UART Driver.

 

 

Once the developer has added the UART Application Framework to the project, there are a few configuration items that need to be handled. First, within the SCI module properties, the Asynchronous Mode (r_sci_uart) needs to be enabled.The g_uart0 UART Driver on r_sci_uart module will still be colored red, indicating that further configuration is required. Clicking on the module, the four interrupts associated with SCI RXI, TXI, TEI and ERI all need to have their priorities set.

Saving the changes results in the configuration being accepted (the red coloring now becomes black) and our development environment will look similar to the image below.

By default, the UART Driver on r_sci_uart module is configured for 9600 bps, 8 bits, 1 stop bit which is pretty standard. Developers can change these defaults from the properties tab if necessary. Once the desired settings have been set, save all changes and then press the “Generate Project Content” button before rebuilding the project. The header for the UART Application Framework will now be added to the application.

At this point, the UART Application Framework is configured and ready to be utilized in the project. If a developer has never used the Synergy Software Package (SSP) before, they may be wondering how they can now use the framework that is included in the project. The trick for getting the API’s associated with the framework is to use the framework name instance, in this case g_uart0, and then examine its p_api member which in the IDE will reveal all available API calls. So in English, or computer code more accurately, typing g_uart0.p_api-> in the IDE will reveal the function available.

Writing the “Hello World” application using the UART Application Framework requires only four lines of code in the hal_entry.c, like below:

The execution of this example will now reveals the following output on the UART0:

The UART Application Framework is now properly configured on the development kit and communicating with the external world. Not only was this simple to achieve but scaling into far more complex applications is just as straightforward.


Form is loading...

emtrion goes virtual

 12. April 2016, by emtrion
Categories: Software, Linux, embedded, Android

In the past few months emtrion has broaden its knowledge base towards the open source virtualization platform Jailhouse [1]. The eventual goal is to provide customers a virtualization solution that is real-time capable, lightweight, secure, certifiable and operable on emtrion hardware. The main advantage to customers will be the reduction of costs through the combination of multiple hardware units into one single unit that handles multiple tasks.

Full story »


Form is loading...

Introduction

In general most of emtrion’s hardware comes with interfaces like Ethernet, RS232, CAN, GPIOs, I2C, SPI. In addition, the used CPU modules are supported by a powerful microprocessor.

Such preconditions are predestinated in controlling industrial systems. In many cases, programming in this environment is based on the widely-known NORM IEC 61131-3.

If you consider these items, the question to ask is, are there any reason why you are not using emtrion's hardware as PLC. Not really. On the one hand it's dependent on the use case and its requirements such as real-time, certification etc. and the other hand on the effort needed to transform it to a PLC.

Full story »


Form is loading...

Introduction

Products for consumer market, industrial control systems and other embedded devices often require a touch screen display to offer both, visual feedback to the user, as well as an input method to interact with the system. In order to achieve a nicely designed and responsive user interface, developers can write their own graphical library providing widgets like drop-down menus, list-views, check-boxes or simple buttons. However, this can be a very tedious and error-prone task. It is best to use one of the available graphic libraries like Qt[1], Cairo[2], EFL[3] or also emWin[4], not to forget to mention nCurses for console-style block-oriented graphics.

Now which library should one select, especially in terms of limited hardware resources on embedded systems but also with a look forward to the look&feel as well as the usability on a touch screen? Besides, hardware restrictions, like the used CPU and its computing power, available RAM-size, free space in ROM, availability of a GPU with 2D/3D hardware accelerated graphics and the used operating system, should be taken into consideration. emWin for example, runs on bare-metal systems either with or without a RTOS whereas Qt or EFL need at least a running Linux (but not said that it is impossible to run them on bare-metal). Other decision affecting parameters are the availability of the library as open- or closed-source, as well as the costs for non-commercial and commercial products. In the following article we will take a brief look at the Enlightenment Foundation Libraries (EFL) of a small Cortex-A5 based single board computer from emtrion running a Debian Jessie based Linux: the SBC-SAMA5D36 [5].

Full story »


Form is loading...

1

Search

Contact

emtrion GmbH
Kreativpark - Alter Schlachthof 45
D-76131 Karlsruhe
Germany

Tel: +49 (0)721-62725-0
Fax: +49 (0)721-62725-19
sales@emtrion.com