Embedded World - First impressions

Once again, it's the time of the Embedded World in Nuremberg Germany, the biggest and most important event of it's kind in Europe. Here are some of my first findings from the fair.

Internet of Things (IoT) is the big theme of the event this year, and in the embedded industry in general. Wireless connectivity is very important part of the IoT scheme. There are some clear changes ongoing. Rising technologies are Wifi, Bluetooth Smart (the new official name of Bluetooth Low Energy), and Sub-GHz RF solutions. Other 2.4GHz radios, including Zigbee and classic Bluetooth are loosing market share.

ARM, Linux and Qt seems to be the winning combo. In the past, x86 architecture dominated the embedded market. Now clearly all new design are based on ARM architecture. x86 products only exists because they we're designed in the past and are still in production, not yet dumped altogether. In an earlier posting, I discussed about "Intel - the walking dead". Intel had big presence at the trade fair, but only place where I found any mention about the new Quark CPU was at Intel's own booth. No one else seems to be interested in it. Very few companies planning anything new with Atom either.

The same case in with operating systems. Embedded Windows seems to disappeared from the map altogether. All the demos I familiarized myself where either based on Linux or QNX, or in some occasions some other RTOSs as well. But not a single Windows case, except perhaps at Microsoft department, but I didn't even bothered to visit there.

Enea Linux and distributed database demonstrated with RaspberryPi and BeagleBoneBlack.

As an example, software technology company Enea originating from Sweden, just recently released an open Enea Linux distribution, based on the Yocto project. Enea has been known for it's OSE and OSEck operating system widely used in network processors and DSPs in communication network elements, and clear market leader on that segment.

On graphics side, the game is not that clear. Qt provided by Digia has strong presence on the market, but there is still space for other solutions as well. Especially in 3D graphics for gaming and demanding visualization. Qt does offer solutions for that as well, but it is still most known for it's 2D user interface designs. HTML5 is growing as a challenger in local embedded UI displays as well, as the computational power of embedded solutions is increasing, thus Qt will have challenges to keep it's market share. I had long conversation with Digia people, and there a quite a lot of interesting things to come in 5.3 and 5.4 releases, not yet available.

I'm happy to see the choices made by my company a decade ago were the right ones: engage to ARM and Linux technologies. At that time, Qt was not widely available, but already before it was published as an open source, we started to co-operate with Trolltech, the company which originally created the technology. ARM, Linux and Qt, here we come!

More findings from Embedded World to come in next postings, stay tuned.

Imp - perfect?

Easy add-on IoT and WSN from Electric Imp.

When I first heard of Imp, it was almost too good to be true; MCU module with Wifi in small form factor of SD card, readily available cloud connectivity and easy mean for configuration of wireless interface. Immediately I ordered some samples and here are my first experiences. There are great hookup instructions at Sparkfun pages, thus I don't need to copy that here.

The concept is great especially for products were IoT connectivity is intended as an add-on option. The BOM price of the base product can be kept as low as possible. Only SD-card holder and an identification chip from Atmel is needed, which increases costs by ~1€. The form of SD-card makes it very easy to retrofit the module in to the product, even by the end-user if necessary.

Imp concept illustration (From ElectricImp web site).

Imp module communicates via local WiFi and internet infrastructure with Imp cloud. The cloud acts as a proxy in between end device like mobile terminal and the Imp'd product. When developing a product, one must make software to three places: into the Imp module itself, into to the cloud to define what to do with the data, and to the end device to describe how to present the data (HTML page). Even if developer can put some code to the cloud, hosting web pages for end device is not supported, according to my understanding. Thus an external web server is needed, or web page must be stored locally in the end device.

The company has invented a clever way to configure Wifi network with help of mobile phone. With an App available for iOS and Android, user can transmit Wifi network configuration optically to the Imp module. In practice, the App does blink the screen of the mobile phone, which is then recognized by the optical sensor of the Imp module. Sort of modern Morse coding. The mobile phone in the left bottom corner of the picture illustrates that function. It does not mean there is possibility to have direct local connectivity in between the phone and Imp node without cloud.

Imp module opened, and breakout card holder from Sparkfun.

Hardware specifications of the module are impressive.In the tiny form factor there are both ARM Cortex-M3 MCU and Wifi embedded.  The SoC controller is STM32F205RG6 from ST Microelectronics with 128KB RAM and 1024 KB Flash, running at 120 MHz. The Wifi chip is Broadcom BCM43362 SiP, supporting 2.4 GHz 802.11b/g/n.

Actually, the hardware configuration looks pretty similar to Murata SN8200. I could imagine they are both derived from the same reference design. Imp is available also as a solder down module, which reminds even more Murata's one.

Electrical interface of the SD card provides very limited number of signals. On the other hand one can configure them freely, which makes the module suitable for many purposes. Among the 6 I/O lines available, one can have up to 3x UART, 2x I2C, 2xSPI, 6x ADC, 6x PWM, and of course 6x GPIO. Each pin can source up to 4mA current. For further details, take a look at the Imp pin mux table.

Unlike Murata, the Imp module has closed firmware. Only supported mean of programming is the Imp Cloud IDE, with somewhat unfamiliar scripting language called Squirrel. The open source project defines itself as follows: "Squirrel is a high level imperative, object-oriented programming language, designed to be a light-weight scripting language that fits in the size, memory bandwidth, and real-time requirements of applications like video games." The language itself looks like mixture of C, C++, Javaa, Python, Lua, etc. People familiar with those languages should learn it quickly.

To summarize some features:

 Pros:
+ Easy to set up
+ Cloud connectivity provided
+ Easy programming environment and target deployment

Cons:
- Only cloud connectivity provided, no support for local connectivity
- Closed firmware, only cloud IDE and Squirrel language supported
- Limited electrical connectivity
- Specific ID chip from Atmel is required


Due to the Cloud-only approach, the module is risky choice for any commercial use. It's hard to rely on third party service on which you have no control over at all. System provided by you is only usable as long as the company stays in business and is willing to provide the cloud proxy free of charge.

I do not quite understand why the company has selected this closed approach. Perhaps they are planning to start charging for connections some day, once the critical mass has been exceeded. There is no technical reason for the choice, as the reference design of the module provides extensive software support, including Wifi drivers, TCP/IP stack, HTTP/DHCP/DNS servers, DHCP client, and more.

I hope the company would open up the firmware to the community, so that people can bring in the features they need for projects or products. I'm confident they would get better acceptance and ecosystem that way, and eventually more sales. Or perhaps perhaps people will manage to create an alternative firmware for the Imp by themselves... It's a fine product, and I don't wish a bad software strategy will destroy it.

HIL toolchain integration strategy

How to select an integration strategy for a HIL testbench?

In the context of embedded systems, there are two major domains: software design and electronics design. In both domains there already exists extensive set of tools and toolchains to meet every purpose within that domain. Integration of these two domains have been covered in my previous postings. Now the question is, how to select which tools to integrate and how, what is the strategy?

In electronics design and testing, most tools are graphical; schematic editors, layout editors, circuit simulators, test cases and sequencing, etc. Whereas in software development all tools are more or less text based, even inside graphical IDE: code editors, compilers, debuggers, unit test tools, integration test tools, etc. It's all about defining in textual format what is supposed to happen.

Graphical expressions are often intuitive and easy to understand. With simple tasks the productivity tends to be good. However, the expressive power of graphical presentations is more limited compared to textual expressions. With graphical tools one can only do such things where graphical elements exists. Combination, recurrence, abstraction, etc. are far more difficult with graphical presentations.

Graphical tools tends to be vendor specific, cross-combining graphical presentations from different vendors is next to impossible. I do not mean for example schematic editors exchanging schematic diagrams, but more like test tool automatically understanding your schematics diagrams.  In software development domain, mix and match different tools is business as usual and daily habit as such.

Due to that, I claim that in cross-domain HIL toolchain, it's better to select most of the tools from software side, and only use hardware specific tools where it is absolutely necessary, in interface to hardware instrumentation. Product specific test cases, test sequences, simulation models, etc. are all better to be done with tools from software domain.

Block diagram of possible development and testing toolchain.

Also the abstraction level of integration needs to be decided. Alternatives vary from very low-level primitives like measure instrument X channel Y to very high level commands like perform sweep-test function for the power supply under development. Clearly this selection affects the communication between tools, and the place where majority of test case logic is implemented.

My intuition says you should put in hardware side routines which are generic and not specific to any certain product. All product dependent test executions would be better to be collected in one place, for easy of maintenance, manageability and understandability.