Monday, December 29, 2014
Makers and Professionals
During the last years I've seen many debates between "makers" and "professionals".
Makers proclaim their contribution to innovation. 
They claim that "learning by doing" and not having a lot of formal education on a specific subject may allow them to have a more open minded approach to problems. They are able to create solutions that people used to think in a more "formal" way can't elaborate, because it breaks too many rules.
On the other side professionals state that they design and build (in two separate steps!) solutions that are made to last, can withstand the "real world" and never or almost never fail. 
They show their competence and knowledge and are usually proud of having big companies and successful products in their portfolios.
Why did I decided to write a blog entry about this?
Yesterday I visited the museum of flight at "Volandia" (, close to the Malpensa Airport and also to my hometown. 
It's a nice experience, with lots of airplanes, helicopters and nice playgrounds for kids. Even some space ships!
But this is not the point.
What struck my mind was a plane from the first years of the 20th century.
It was built by mr. Caproni in 1910, a few years after the Wright brothers first flight.
I was talking with a friend discussing how crazy someone should be to try to fly on such an unstable ensemble of wood and cloth powered by a primitive engine.
And, as you can see in the picture, wearing a leather helmet and a nice pair of mustaches doesn't seem to help much in case of a rough landing.
But it's thanks to those people if today we can travel around the world and reach in a few hour places that would had required days or even weeks of travelling using ships or ground vehicles.
Was mr. Caproni a maker or a professional? 
For sure, after he survived his test flight, he built a successful company and designed many reliable and relatively safe airplanes afterwards. So he had a great professional career in airplane making.
But for sure at the beginning he was a "maker". 
Going by trial and error and being forced to test his own planes because no one was trusting their capability of flying and landing safely.
Probably at that time "professionals" were trying to design faster ships and cars. Thinking that the idea of flying was naive and unprofessional. And considering those people risking their life on airplanes just crazy freaks.
But nowadays who would board a plane that proudly claims to be designed by "non-professionals" with no previous experience in designing planes? 
Would you trust that?
Sometimes I wonder if I should consider myself a maker or a professional. Or both. Or none of them...
For sure being a "maker" is in my DNA. 
My father was a maker. 
He had no formal education (being born in 1934 he just attended primary school), but he was able to build and fix almost anything.
Maybe anything but my computers. 
In his job he had to travel around the world mounting textile machinery. I guess that in many places he had to figure out some "creative" ways to make those machine work in places and environments quite different from the industrial building where they were produced.
He was able to work with metal, wood and electricity.
And also at home he never stopped improving many of the different things he built himself.
And proudly refused to call a "professional" when a tap was leaking or some appliance refused to work.
I also like to play with things and I managed to build something, like my own standing desk. 
But, I should admit, without my dad's manual skills and patience.
I also don't have a lot of formal education. I never attended university and started to work as a software developer at 20, after one year spent in the army.
I learnt many of the languages, tools and technologies I use in my work just by experimenting and reading books and, lately, blogs and articles.
I like to experiment and sometimes I waste some time trying solutions that seem to be brilliant only in my mind.
On the other side I've been writing software (mostly for embedded systems) as my main job for more than 20 years now. So should I call myself "professional"?
First of all I think that "professional" is the mostly abused adjective ever.
Here you can see a nice sample of that.
It's "professional toilet paper". I took this picture in an Italian hotel, wondering what would make that toilet paper more "professional" than the one I use at home. Luckily it seemed exactly the same, and I didn't need help from a professional to use it.
On the other side I think that experience (and formal education) may deserve some kind of recognition.
The Wright brothers in their whole career flight for a distance that today may not be even worth a few bonus miles on a frequent flier's plan.
The work of many "boring" professionals engineers lead to the reliable (and sometimes comfortable) planes we use nowadays.
And strict, planned and methodical checks and maintenance is what keeps commercial flights one of the safest means of transportation.
The first airplanes were prototypes that could be used only by their inventors (at least because no one else would like to risk his life fying them!). 
Today the most complex operation required to most of the people travelling by plane is the on-line check-in.
In my idea a "maker" has the creativity to experiment with new ideas and find creative solutions. 
On the other side a "professional" has the experience and knowledge required to avoid some errors (and experience comes from previous mistakes!), evaluate risks and make things more reliable and translate a "prototype" into a real product.
Sometimes adding some additional mistakes in the process, of course.
Nothing prevents you from being both, but you should understand when you are prototyping and when you are building something made to last. 
Technology is getting more complex and more easy to use at the same time. 
This is a wonderful moment for people that want to experiment and then learn and master the complexity that's sitting under something that is so easy to build.
There is space for "makers", assembling technologies and building great prototypes, and for "professionals" that will take care of the details and turn them in object that millions of people can use every day and even trust enough to board them and flight ten thousand meters (or feets) over the ground.
I work in a (great) company that takes complex technologies, build objects made to last (and be produced at a reasonable price!), but also allows other people to use those very complex hardware and software components in an easy way. 
This will allow them to build simple devices or even more complex systems, applying their own skills and creativity.
Most of the things we use every day are too complex to be designed by a single person (and, no, Steve Jobs didn't design the whole iPhone!). 
Integrating different parts, building quick prototypes, being able to access technologies in an easy way and, at the same time, caring about the details, thinking about production and long term maintenance etc. are key skills that are usually split between different people in a team.
Having "makers" and "professionals" working together and not just debating is the best thing for a company.

Posted On Monday, December 29, 2014 3:38 AM | Comments (0)
Tuesday, August 5, 2014
Windows for IoT, continued

I received many interesting feedbacks on my previous blog post and I tried to find some time to do some additional tests.

Bert Kleinschmidt pointed out that pins 2,3 and 10 of the Galileo are connected directly to the SOC, while pin 13, the one used for the sample sketch is controlled via an I2C I/O expander. I changed my code to use pin 2 instead of 13 (just changing the variable assignment at the beginning of the code) and latency was greatly reduced.


Now each pulse lasts for 1.44ms, 44% more than the expected time, but ways better that the result we got using pin 13.

I also used SetThreadPriority to increase the priority of the thread that was running the sketch to THREAD_PRIORITY_HIGHEST but that didn't change the results. When I was using the I2C-controlled pin I tried the same and the timings got ways worse (increasing more than 10 times) and so I did not commented on that part, wanting to investigate the issua a bit more in detail. It seems that increasing the priority of the application thread impacts negatively the I2C communication.

I tried to use also the Linux-based implementation (using a different Galileo board since the one provided by MS seems to use a different firmware) and the results of running the sample blink sketch modified to use pin 2 and blink the led for 1ms are similar to those we got on the same board running Windows.
Here the difference between expected time and measured time is worse, getting around 3.2ms instead of 1 (320% compared to 150% using Windows but far from the 100.1% we got with the 8-bit Arduino).


Both systems were not under load during the test, maybe loading some applications that use part of the CPU time would make those timings even less reliable, but I think that those numbers are enough to draw some conclusions.
It may not be worth running a full OS if what you need is Arduino compatibility.
The Arduino UNO is probably the best Arduino you can find to perform this kind of development.

The Galileo running the Linux-based stack or running Windows for IoT is targeted to be a platform for "Internet of Things" devices, whatever that means.
At the moment I don't see the "I" part of IoT.
We have low level interfaces (SPI, I2C, the GPIO pins) that can be used to connect sensors but the support for connectivity is limited and the amount of work required to deliver some data to the cloud (using a secure HTTP request or a message queuing system like APMQS or MQTT) is still big and the rich OS underneath seems to not provide any help doing that.
Why should I use sockets and can't access all the high level connectivity features we have on "full" Windows?

I know that it's possible to use some third party libraries, try to build them using the Windows For IoT SDK etc. but this means re-inventing the wheel every time and can also lead to some IP concerns if used for products meant to be closed-source.

I hope that MS and Intel (and others) will focus less on the "coolness" of running (some) Arduino sketches and more on providing a better platform to people that really want to design devices that leverage internet connectivity and the cloud processing power to deliver better products and services. Providing a reliable set of connectivity services would be a great start. Providing support for .NET would be even better, leaving native code available for hardware access etc. 

I know that those components may require additional storage and memory etc. So making the OS componentizable (or, at least, provide a way to install additional components) would be a great way to let developers pick the parts of the system they need to develop their solution, knowing that they will integrate well together.

I can understand that the Arduino and Raspberry Pi* success may have attracted the attention of marketing departments worldwide and almost any new development board those days is promoted as "XXX response to Arduino" or "YYYY alternative to Raspberry Pi", but this is misleading and prevents companies from focusing on how to deliver good products and how to integrate "IoT" features with their existing offer to provide, at the end, a better product or service to their customers.
Marketing is important, but can't decide the key features of a product (the OS) that is going to be used to develop full products for end customers integrating it with hardware and application software.
I really like the "hackable" nature of open-source devices and like to see that companies are getting more and more open in releasing information, providing "hackable" devices and supporting developers with documentation, good samples etc.
On the other side being able to run a sketch designed for an 8 bit microcontroller on a full-featured application processor may sound cool and an easy upgrade path for people that just experimented with sensors etc. on Arduino but it's not, in my humble opinion, the main path to follow for people who want to deliver real products.


*Shameless self-promotion: if you are looking for a good book in Italian about the Raspberry Pi , try mine:

Posted On Tuesday, August 5, 2014 1:36 AM | Comments (2)
Sunday, July 27, 2014
Windows for IoT, First Impressions


(the Galileo board with an Arduino UNO and a VF50 module from Toradex)

Last week, as many other MVPs and developers around the world, I received an Intel Galileo board preloaded with WindowsIoT version.

This is a preview (so don't take for granted that what I'm describing matches official releases) but we were encouraged to blog about it, so here's my first impressions.

This version has been announced (as an unexpected surprise I should say) during Build 2014 conference in spring and you can find more information about it on the WindowsOnDevices website here:

The board firmware has been modified to run the Windows kernel, I tried to run it on another unmodified Galileo board I had at home and I was able to boot.
To do that you need to access a serial console using a serial port disguised as an audio jack... how brilliant!

Here you can find an adapter:

But even after accessing the EFI boot menu and selecting SD card as boot media the board doesn't not seem to fully load the OS.

Having a working board I did not spent too much time on this and I inserted the SD image and powered the board up.

But first I checked how big the OS image is.
It's 1GB, quite big compared to other embedded operating system (mostly considering that we have no graphics here since the Galileo is an headless board), but definitely smaller than a standard Windows 8 setup. More or less what you can archieve using the Windows Embedded Standard toolset.

I mentioned that the board is headless, so how are we supposed to access it?

The SDK that you can download from the official website includes a small application named "Galileo Watcher" that shows the board it detects inside your local network.

Here's a screenshot of the tool:


From the main window you can see the board name (I suspect it's the same for all the boards), it's MAC address (useful to distinguish a specific board since it's printed on the network connector) and its status. By right-clicking the board name in the list you can open a telnet prompt (using to perform command-line maintenance), open a very simple web interface (so there is a minimal webserver running on the device, even if I found no documentation about it) and browse its folders (something you can do by just reading the SD card from an SD reader connected to your PC).

If you think that this does not sound exactly exciting, you are right. The most interesting part starts when you launch Visual Studio 2013 and create a new project for the board. You will see that a "Windows for IoT" subcategory appears in the list of templates and, selecting it, you'll be able to create your first IoT application running on top of Windows 8 kernel.


As you can see from the screenshot, the project is referenced as "Galileo Wiring App". Wiring is the programming environment made very popular by the Arduino ( On the Galileo we can use the same functions made popular by this famous (and Italian!) microcontoller board to access features on an x86-based device. This makes sense since the Galileo also has an Arduino compatible pinout.

Be careful to run the wizard when you are connected to the internet! A failure to do this leads to build issues afterward as my friend Paolo Patierno discovered and documented here

The wizard generate sample code that is quite similar to the "blink" sample sketch provided with the Arduino IDE (Arduino programs are called "sketches").

Here's the code:

// Main.cpp : Defines the entry point for the console application.

#include "stdafx.h"
#include "arduino.h"

// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

// Helper function for logging to debug output and the console
void CustomLogging(char* str)
OutputDebugStringA(str); // for VS Output
printf(str); // for commandline output

int _tmain(int argc, _TCHAR* argv[])
return RunArduinoSketch();

void setup()
// TODO: Add your code here

CustomLogging("Hello Blinky!\n");
// initialize the digital pin as an output.
pinMode(led, OUTPUT);


void loop()
// TODO: Add your code here

CustomLogging("LED ON\n");
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
CustomLogging("LED OFF\n");
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second


This is actually a plain Windows 32 console application (you can recognize it from the _tmain entry point). The "RunArduinoSketch()" call just initializes the "Arduino-compatible" behaviour and let to call to setup (once) and loop (continuously) callbacks like it happens in the Arduino. Also the pinMode, delay and digitalWrite functions are part of the Arduino standard library. The Serial class, used for serial communication and usually debug messages has been replaced by the "CustomLogging" function that invokes standard Win32 tracing and console output APIs (no variable arguments, so no fancy formatting of your output with variable dumps etc...), so it's redirected to Visual Studio output window or to the console if you launch your app using telnet.

Our application can be remotely debugged just by selecting "Run", this is an improvement compared to Arduino IDE that, at least on 8-bit versions with no jtag connection, does not provide any kind of remote-debugging capability.

To download and execute our app we need to authenticate ourselves:


User is "Administrator" and the password (for the happyness of sysadmins) is "admin".

Once the app is deployed we can start it, put breakpoints, inspect variables etc. as we are used to do with any regular Windows (or Window CE) application.

If you connect a led between pins 13 and GND you'll see it blinking at one second intervals.

Since I'm a low-level driver BSP and other boring stuff embedded developer I tried to understand the real capabilities of such an implementation. Usually hardware access on Windows is complicated, requiring drivers etc. here we can toggle GPIOs from our main function, looks cool.

I tried to decrease the time of delay to 1ms and to remove debug messages (to prevent any kind of slow-downs) and checked the timing of the resulting square-wave using an oscilloscope.

The results aren't exactly what you may expect and here's a graphical view of the wave (with time for each pulse):


As you see we have positive pulses lasting for around 6.75ms and negative ones around 12ms. This means that the delay function is not reliable? Is not as reliable as it is on a regular Arduino UNO,as you can see from this other graph:


On the arduino pulse times are quite close to 1ms.

This means that the Arduino is more performant than the Quark CPU used on the Galileo? Not at all, the Arduino UNO uses an 8-bit microcontroller, while the Galileo is powered by a 500MHz 32bit CPU.

So why we don't have better times on the Galileo? Because Windows is not a real-time operating system. On the Arduino we write code that runs directly on the processor and, unless we enable interrupts and waste a lot of time inside interrupt handlers, the processor will respect our timing quite strictly. On Windows the operating system schedules multiple threads and does not grant 1ms reliability in delays. As we can see by looking at the arduino.h include file, that contains most of the wiring implemetation, the delay function is implemented using the Sleep API. Sleep grants that a thread sleeps at least for the number of milliseconds passed as parameter. No grant is made about the maximum lenght of the delay. I suspect that we will see a similar behaviour also when we run the wiring implementation on top of Linux that comes with the "standard" Galileo boards, but I didn't had the time to do this test at the moment.

This behaviour may impact some protocols and hardwares that expects exact timings in the signals used to drive them. The wiring implementation on the Galileo also provides SPI and I2C access and those buses, if used through an hardware controller should respect their timings (will check this as soon as possible) but other protocols that on a regular Arduino could be "bit banged" by directly accessing GPIO pins may not work if their timing requirements are under 10ms.

Talking about hardware compatibility, the Galileo can be used with many of the shields designed to be used with the Arduino. The pinout of the original Arduino has become a de-facto standard for maker-hobbyst targeted boards and the Galileo, on the hardware side, allow us to use 5V or 3.3V signals to interface the shield (you have to select the voltage using a jumper). On the other side some shield may require strict timings for their signals or may provide libraries that access directly some hardware features of the AT-Mega microcontroller used on Arduino (for performance reasons or to access hardware capabilities not supported by the wiring API). Those libraries are not compatible with the Galileo and Windows for IoT SDK that, as we have seen, rebuild code to native Win32 code, not providing any kind of emulation of the original microcontroller used on Arduino.

Arduino.h is the hearth of the Wiring implementation and, digging a bit more deeply into it, we can discover that it provides implementation for a good share of the Arduino base library (reference is here:, including GPIO control and configuration, timing (with the limitations described above), analog inputs, PWM outputs, I2C and SPI. We currently have no support for serial port, interrupts and other advanced HW features.

Looking at the code (the SDK full source is available on github: we can see that the Arduino HW access APIs are implemented calling functions defined in embprpusr.h. Those functions define a low-level API that may offer direct access to hardware features without requiring Arduino compatibility and reducing the overhead (for example GPIO access functions in Wiring always test validity of the pin index and translate it from the Arduino pin numbers to Quark's internal indexes, adding some overhead each time you toggle a pin) and allowing you to use them in regular windows console applications, for example to toggle a pin when you receive data on a socket or read characters from a console. A phylosophy not much different from the HW access libraries provided by Toradex: Using this API will broke Arduino compatibility but may give better control of the hardware and better integration with standard Windows features. Those APIs are undocumented at the moment, so they may change in future updates, be careful if you decide to use them!

On the API side is not very clear what's the amount of Win32 APIs supported on this platform. Having an headless device excludes any graphic related feature. On the other side basic networking features like sockets seem to be supported (still haven't tested them in detail) while other more advanced features like HTTP/HTTPS, SSL etc. may have some dependencies on Internet Explorer (like it happened with the wininet library in the past) that may prevent them from running on this low-footprint version. On the other side (and this is a bit disappointing since we are talking about an IoT version), there are no libraries (at least no documented ones) to access cloud-services like the Azure Service Bus, to make HTTP request, to use messaging systems or to manage security certificates. I hope to see those functions in future releases because they can simplify and standardize sharng information with cloud-based services. And this should be the main point of an IoT device compared to traditional embedded devices.

It seems that currently there is no support for .NET/managed code and no support for the new WinRT programming model. This is not such a bad thing for me because I'm used to write native applications (mostly on Windows CE) using the "old" Win32 model but for sure it may be a big limitation for high-level developers used to C#/VB or Javascript that at this moment are not supported on the platform.

What are my tought about Windows for IoT? I think it's interesting to see Windows "shrinking down" to fit small devices. On the other side 1GB of OS quite don't fit the definition of "small" in the embedded space, even if storage/memory size and processing power on devices is increasing quickly. Being limited to headless devices is also quite a strong limitation, preventing the creation of interactive devices, unless they are limited to small LCD/text displays (or use voice, sound or other ways to interact). Currently the system targets makers and technology enthusiasts and for sure can't be used in a product (at least because you can't buy Galileo boards configured to run it...). On the other side having Windows compatibile features on an embedded device clearly has a lot of potential (even if I would love to see more on the "I" side of IoT in-the-box). Currently no announcements have been made about supported hardware etc., the only statement released at build was about licence cost, that will be zero (good news since other MS operating systems for embedded still carry a price tag). In my opinion supporting other kinds of hardware (including those with a graphic controller) and in particular ARM chips will be crucial for the success of this platform. We know that the Windows 8 kernel already runs on ARMs (even if application development is artificially limited to WinRT only) and being able to run it on different kind of processors (including of course those used on Toradex's COMs) would provide a flexible soution in many different scenarios. Being tied to x86 or Quark would limit the applications that can be provided considering the limit of the chip (no graphics, no CAN, power consumption etc.) that may be good for some devices but not for many others.

Posted On Sunday, July 27, 2014 10:24 AM | Comments (2)
Tuesday, October 1, 2013
The Times They Are a-Changin'

As you may know, in the past 3 years I’ve been working as a consultant and collaborating with Adeneo Embedded. 
Today (October 1st) I begun a new experience at Toradex (, in Horw, Switzerland.

Those 3 years have been wonderful, and working with Adeneo was a great opportunity to meet great people (and I’m not talking just about their technical skills) and work on many different projects for a very dynamic company. I would like to thank Yannick and all the other people for the support they provided me. I felt part of the company even if I was working from a different country and I wish them all the great results they deserve. I also had a chance to work as an independent consultant for many different Italian companies, and see how great products are developed in different industrial fields even if people may associate Italy with just good food and cool clothes. I hope to have a chance to collaborate with many of those people in my new role.

Toradex offered me a new and different challenge, and I decided to take it. It’s my first time working for a company that develops hardware and software. I like the idea of being involved directly in a “product” (in many products for many years, I hope!) and to work for a company that, even if the end product is sold as hardware, has a very tight focus on software and to make the end-customer experience as simple as possible by providing a reliable OS, libraries, tools, documentation. Building a system and not just assemble some chips and try to make some code run on top of them.

I like the fact that when they described me the technical organization they made no distinction between the software developers and the hardware designers. So many times I hear people considering hardware and software as distinct things and not as complementary parts of a finished product. I’ll have to learn lots of new things (maybe also a new language), improve my skills and understand how to work in a different environment, but challenges are better than boring routine!

Closing my consulting activity, trying to finish all the open projects, fix all the bugs (at least the know ones!) etc. lead to a totally crazy schedule in the last weeks, now I hope to come back to a just plain crazy schedule and have some time to update this blog with some interesting news about my new job (still related do Windows Embedded and low-level BSP and driver stuff) and my new company.

Posted On Tuesday, October 1, 2013 7:59 AM | Comments (1)
Tuesday, July 30, 2013
Better Embedded 2013


On July 8th and 9th I had a chance to attend and speak at the Better Embedded 2013 conference in Florence.

Visiting Florence is always a pleasure, but having a chance to attend to such an interesting conference and to meet Marco Dal Pino, Paolo Patierno, Mirco Vanini and many other embedded developers made those two days an experience to be remembered.

I did two sessions, one on Windows Embedded Standard and “PCs” usage in the embedded world and another one on Android for Embedded devices, you can find the slides on the better embedded website:
You can also find slides for many other interesting session, ranging from the .NET microframework to Linux Embedded, from QT Quick to software licenses. Packing many different resources about embedded systems in a conference was not easy but the result is a very nice mix of contents ranging from firmware development to cloud-based systems. This is a great way to have an overview of what’s new or interesting in embedded systems and to get great ideas about how to build your new device.
Don’t forget to follow @Better_Embedded on twitter to not miss next year conference!

Thanks to the better embedded team for having allowed me to use some of the official pictures in this blog post. You can find a good selection of those pictures (just to experience the atmosphere of the conference) on its Facebook page:

Posted On Tuesday, July 30, 2013 3:52 AM | Comments (0)
Tuesday, January 29, 2013
Microsoft Embedded Conference, the week after

SAM_0270 - Edited (2)

Ecco il resoconto della splendida giornata trascorsa in quel di Napoli a parlare di sistemi embedded:

Un grazie a Paolo, Michele, Antonio e a tutti i ragazzi di .NET Campania che hanno saputo organizzare perfettamente l’evento e far ricordare a un “nordico” come il sottoscritto che al Sud l’ospite è sempre trattato come un re.

Posted On Tuesday, January 29, 2013 10:30 PM | Comments (0)
Sunday, January 20, 2013
Why should I use an Embedded Operating System on an Embedded Device (updated 10/12/2014 - 12/10/2014 for my American friends)

This is a good question when it comes from people with no experience on embedded devices and a very bad one when you hear it coming from people that work on embedded devices.

“I’m using a PC inside my embedded device, so I can use Windows/XXXX as I use it on my PC” this is usually a statement made by people who actually design bad embedded devices. And those devices are not bad because they use a PC-based hardware (using a PC may be a good solution for some kind of devices where developing a custom board is too expensive and does not provide any real advantage in terms of cost), nor because they use Windows or any other OS.

It’s because they use an OS version designed for PCs, and so they behave like a PC and not like an embedded device!

Or, if they use an OS designed for embedded, they forgot to hide some details or to let the system perform an automatic reboot when something goes wrong.

A PC has always a user taking care of it (or calling for help when something goes wrong beyond his recovery capabilities!), an embedded device must run unattended. Users don’t want or even can’t interact with it. It must be able to solve its own issues and, at least, report errors by itself.

Usually airports and train stations are a good place to spot some PCs “hidden” inside embedded devices. And those PCs sometimes show their nature giving unnecessary information or asking for help to people that just want to receive some information from them (or that are the target for advertising campaigns running on those devices).

Let’s see some samples.

1. Malpensa Airport (Milano, Italy)

Installing updates is a good idea if your device is connected to a network, maybe doing that overnight is smart, so no-one will see the device restarting. But telling to everyone that your “embedded” PC installed its updates overnight doesn’t look like such a smart idea…



The message is in Italian, but I guess that any Windows 7 user can recognize it. “New updates have been installed”. This message will stay on top of the content (information about the security controls) until someone finds a mouse and a way to connect it to a terminal that is suspended 2.5 meters from the ground.

Sorry for the bad quality of the images but the mix of phone camera and horribly early morning hour impacted my photographic capabilities quite hard Smile

2. Paderborn Airport (Paderborn, Germany)

Here we have a nicely designed information totem that is supposed to show interesting contents or, maybe, just advertising.

Instead is showing a wizard from a set-up application (or something like that, my knowledge of German is close to zero…) that I suspect is not very interesting for most of the people passing in front of it and that can’t interact with the device because no mouse or keyboard is available.


You can also notice that the display is mounted in portrait mode but is configured in landscape. I don’t envy the developer that had to debug his application keeping is head turned 90° to the right to read the output Smile

3. Cadorna railway Station – Milan – Italy

Many thanks to Giorgio and Frangino for this great sample.


Do you recognize those icons? It’s a Windows 98 desktop! Running on a monochrome display with very low resolution.
This picture has been taken a few days ago, not in year 2K!

The good news is that this Windows 9X powered PC is still up and running. At least 15 years after its OS release and 7 years after the end of MS support for Windows 98/ME. But let’s see the bad news…

The application has crashed and the display is no longer showing useful information.
Just letting some people know that Windows 9X is still alive and kicking. 13 years after the release of Windows ME! (but Windows ME “my computer” icon was different, so we are looking at Windows 98 or even at Windows 95 here).

How could this device be restored?
Powering on and off the device isn’t a very good way to restore its operations. Do you remember what could happen to a FAT filesystem after an unexpected power outage? Someone will have to shut it down. It may be possible to do this remotely, but the service was interrupted for some time.
Consider also that this is a display that is used to show train timetables, so information must be updated in real time and I suppose that this device is connected to some form of corporate network. It hope it’s a dedicated network because putting a Windows 9X machine with an OS that is no longer patched and supported on an open corporate network is like hiring a wolf to take care of your sheep!

Embedded devices don’t need to follow technology trends and move to the last OS release a few week after it’s available. Devices must be stable and reliable and any change must be tested carefully. But, on the other side, using a 15yrs old unsupported desktop OS to power a connected embedded device may be a bit too conservative.

4. Pisa Airport – Italy

BF5jaxrCUAEoH1P (1)

My friend Marco Dal Pino sent me this image via Twitter, another airport, another useless display. The text is too small to read it, but it seems an error due to a broken or no longer bootable hard drive. In this case the OS can’t do nothing to fix the issue, but hopefully a monitoring system should be in place, detecting that a device is no longer operating.

5. Trash can


This came from a tweet by Kharim Yaghmour and it’s one of the funniest samples I’ve ever seen. The device is still operating, you can put trash inside it… but the system (Linux in this case) has crashed. Maybe emptying the trash will free some disk space and allow it to run? The text is not readable, it seems to be a kernel panic at startup. This may be due to an hardware failure, but showing this on the screen doesn’t help. Maybe showing a company logo during boot may have made it less noticeable.

6. Train – Naples – Italy

2013-04-06 20.40.08

Thank to my friend Paolo Patierno (see his blogs here and here) sent me this picture taken on the subway in Naples.

It’s the well known “Unable to connect” error message from Firefox (can’t see what OS, but it doesn’t matter).
Using a web browser to show advertising or other information in this context may be a good idea, you already have good browsers for many operating systems, you can realize good animations and graphics in HTML5+JS, and you can have a browser reloading the information from the server without the need of building an infrastructure to distribute that content.
You can even change the contents on the server on the fly, and all the terminals will be updated immediately.

This solution worked great. On the developer’s desk.

In the field (and more likely if you are running on a train moving underground…) you can lose network connectivity. Even if the serve is on the train. And, again, there is no way to see this device recovering automatically when the connection is restored.
Browsers can be embedded inside applications on many different operating systems, allowing the “host” application to check network connectivity, show an error message when it’s not available, try to use a backup connection etc.
You may even handle this kind of failures inside your HTML/JS code.

More samples

Since I published this article many people sent me many other good samples.
You can see devices showing a portion of a windows desktop on a huge advertising panel (or this may be some really advanced advertising technique, I don't know).
(Thanks to Renato Marzaro for this one)
It seems also that using PCs turned 90 degrees to have nice portrait displays is quite common. Too bad that blue screens aren't rotaded (P.S. you can avoid to show a blue screen or, at least, automatically reboot your device quite easily!)


Samples from Clemens Vaster's twitter account (Heatrow airport) and sent by Clemente (IIRC, from an Italianrailway station)
But bluescreen remain an all time favorite also in the more traditional portrait mode:

Thanks to Giorgio Cifani, always looking for good samples in airports :)
To close this gallery (at leat until I get some new samples from friends or have a change to take some new pictures myself),  a screenshot I took in the "Garibaldi" underground station in Milano, showing that no only Windows machines can have issues and show something you are not supposed to see.


Those samples proof that showing this kind of error messages to end-user will make device unusable, lead to a waste of resource and even a waste of money (if someone was expecting to have their advertising shown on those nice big screens…).

And those issues sometimes are deadly easy to fix or, at least, to hide (in case of an hardware failure). Just use the right version of Windows (if you are using Windows)! With Windows Embedded Standard or Windows Embedded Industry you can easily remove any notification message, message box and other OS output that is not related to the main task performed by your device. 

It’s easy to do that or to find someone that can configure the OS for you and avoid this kind of issues that could lead to unsatisfied customers (those that pay for the advertising) or to inconveniences to passengers that will not find the information they expect from those monitors or find it partly covered by error message that they already hate on their PCs.

Also if you use a different OS you may experience issues and, also in that case, you may be able to find a way to fix them or, at least, restore device operativity in an automatic way. 

PCs and their operating systems are, most of the times, designed to have a human taking care of them every day, if you decide to use them in an harsh and unfriendly environment, please try to hide their weaknesses.

I'm joking about those issue, but I made many of those mistakes in the past, and tried to learn from them (and maybe also from other people's mistakes, saving myself some bad first-person experiences).

Now, at least, I try to think in advance how to make them less visible, and how to allow a device to restore it's regular operations without needing help from those rude human beings that are just caring about how to reach their fligh gate and not willing to plug a keyboard an mouse in my device or just quickly reset it.

Posted On Sunday, January 20, 2013 2:49 AM | Comments (2)
Sunday, December 30, 2012
Microsoft Embedded Conference

Il 26 Gennaio a Napoli si svolgerà la prima conferenza italiana completamente dedicata alle tematiche Embedded.

Gli organizzatori di .NET Campania e in particolare il mitico Paolo Patierno stanno facendo un lavoro eccellente e hanno messo in cantiere una giornata interessantissima. Potete consultare l’agenda e iscrivervi sul sito:

Come potete vedere dal programma, anche il sottoscritto terrà una sessione. Appuntamento a Napoli quindi!

Posted On Sunday, December 30, 2012 3:01 AM | Comments (0)
Monday, December 24, 2012
Using SYSPREP in Windows Embedded Standard 7


Using Windows Embedded Standard 7 you can quickly build an Operating System configuration that support your hardware and include only the components required to run your application.

Being able to customize the set of packages that are included in your image has multiple advantages:

- reduced footprint (you’ll save storage and memory giving more resources to your application)

- improved security (some services may have bugs that allows remote exploits and can become a security issue, removing them if they are not needed on your device will improve security)

- improved reliability (less code, less bugs Smile ).

In Windows Embedded Standard 7 you can generate a set-up DVD or thumbdrive that can be used to install the operating system and your application on a target machine. Doing a full setup on each device could be a suitable solution, but it has some drawbacks. Setup may take a long time and may require some user interaction, some components may need to be installed or configured after the main OS setup etc. For those scenarios cloning is a more suitable alternative.

But you can’t clone a WES7 hard-drive and just use it to boot another machine. Every device has some local-ids that need to be unique and may prevent your cloned machines to operate when they are connected to a network. You need to remove those IDs from your machine before you clone its OS image. At the first boot the system will re-configure itself and generate new IDs.

To perform the “ID-cleanup” operation you can use the sysprep tool that is installed on every WES7 device inside the Windows\System32\Sysprep folder.

By launching:

sysprep /generalize /oobe /shutdown

This command will remove machine-specific IDs and prepare your system for cloning. It will also shutdown the device, preventing any further configuration operation that may change its “clean” state.

If you restart the device you’ll discover that the system will ask for some of the same information (computer name, user account, time zone etc.) that you may have already configured using the Image Configuration Editor. This may be an issue if you want that all your devices have the same settings.

To prevent this you can take the answer file you used to create the Windows Embedded Standard 7 image currently running and open it inside a text editor. It’s an XML text file that you can edit.

You’ll have to remove the <servicing> node and all the settings nodes that are not involved in the syspref phase (leaving only <settings pass="oobeSystem"> and <settings pass="Specialize">). Then you can use this reduced version of your answer file to automate the post-sysprep phase.

By launching:

sysprep /generalize /oobe /shutdown /unattend:<path to your XML file>

you’ll have a clonable image that will re-configure the device at first startup automatically, with no need of user interaction.

Posted On Monday, December 24, 2012 3:33 AM | Comments (2)
Saturday, September 1, 2012
Support ARMv7 instruction set in Windows Embedded Compact applications

On of the most interesting new features of Windows Embedded Compact 7 is support for the ARMv5, ARMv6 and ARMv7 instruction sets instead of the ARMv4 “generic” support provided by the previous releases. This means that code build for Windows Embedded Compact 7 can leverage features (like the FPU unit for ARMv6 and v7) and instructions of the recent ARM cores and improve their performances. Those improvements are noticeable in graphics, floating point calculation and data processing. The ARMv7 instruction set is supported by the latest Cortex-A8, A9 and A15 processor families. Those processor are currently used in tablets, smartphones, in-car navigation systems and provide a great amount of processing power and a low amount of electric power Smile making them very interesting for portable device but also for any kind of device that requires a rich user interface, processing power, connectivity and has to keep its power consumption low.

The bad news is that the compiler provided with Visual Studio 2008 does not provide support for ARMv7, building native applications using just the ARMv4 instruction set.

Porting a Visual Studio “Smart Device” native C/C++ project to Platform Builder is not easy and you’ll lack many of the features that the VS2008 application development environment provides. You’ll also need access to the BSP and OSDesign configuration for your device to be able to build and debug your application inside Platform Builder and this may prevent independent software vendors from using the new compiler to improve their applications performances.

Adeneo Embedded now provides a whitepaper and a Visual Studio plug-in that allows usage of the new ARMv7 enabled compiler to build applications inside Visual Studio 2008. I worked on the whitepaper and the tools, with the help of my colleagues and now the results can be downloaded from Adeneo Embedded’s website:
(Click on the “WEC7 ARMv7 Whitepaper tab to access the download links, free registration required)

A very basic benchmark showed a very good performance improvement in integer and floating-point operations. Obviously your mileage may vary and we can’t promise the same amount of improvement on any application, but with a small effort on your side (even smaller if you use the plug-in) you can try on your own application.

ARMv7 support is provided using Platform Builder’s compiler and VS2008 application debugger is not able to debut ARMv7 code, so you may need to put in place some workaround like keeping ARMv4 code for debugging etc.

Posted On Saturday, September 1, 2012 1:04 AM | Comments (1)
Toradex logo

Cookies in Use
Tag Cloud