One day one of my kids asked me what was my job.

"I write programs for computers," I said
"computers like this one" I added showing him one of the Toradex's modules on my desk
"It doesn't look like a computer!" he replied "You must be joking, dad. What's your real job?"

For the last 20 years (or since the end of the previous millennium, if you prefer), I've been developing software mostly on embedded devices. Things that don't look like a computer, as my son brilliantly defined them.

I started writing this kind of software when the "Internet of Things" was not even in marketing people's dreams and when to connect to the internet at high speed you had to use a 56K modem (I had a 14.4k modem at that time).

I started writing software in 1993, during my service in the Italian army (it was mandatory to spend one year in the army at that time).
I wrote management software, used to keep track of documents and people's role inside the organization and, like most of life in the army, it was deadly boring.

At that time I didn't know if writing software was what I wanted to do for the rest of my life.
But then I found a much better job and started writing file-transfer middleware under MS-DOS.
I know that this doesn't sound more exciting than management applications for the army, but it actually was.
The company was very dynamic and funny (a foosball table was one of the first pieces of furniture we got in the office) and writing that code was quite challenging.
I helped to port it to Windows 3.1 and then Windows 95 and Windows NT.
I had to deal with obscure stuff like NetBIOS, SNA, Trumpet Winsock, and I could probably still do a handshake with a modem by just whistling, after too many hours spent testing dial-up modems and fancy AT commands used to make them call from exotic places (dialling a phone number is much less trivial than it seems) or connect over very bad phone lines.

But the most challenging part was that the software had to run overnight, transferring the data generated during the day, and doing that reliably with almost no assistance from humans.
It had to be reliable and able to recover from many different error conditions, keeping data flowing between remote places like shops or warehouses and the head offices of many different companies.
It's probably still running on a good number of PCs nowadays and doing its job, mostly without any interaction with human beings.

When the file transfer application had all the features customers were asking and Microsoft decided that Win32 was a stable API not needing any major revision in the coming years, I started focusing on custom projects. And most of those projects had the same requirements as the file-transfer system: run reliably without much help from humans. And, most of the times, with also no PCs involved.
It's not that I don't like PCs or human beings. I just don't want too much interaction...
Thinking about a system able to survive without much external help and recovering from failures or errors without someone pushing the "retry" button was challenging and interesting. It still is challenging and interesting.

I started working mostly on Windows CE, beginning from version 2.12. I wrote applications talking with washing machines, ovens, heating systems and radiator valves. I tested my applications on the back seat of a scooter of the famous Monza racing track, inside factories and warehouses or on garbage trucks.

And every time I was trying to explain to people that I was not writing software running on PCs, phones or tablets I kept getting the same comment "You must be joking..." and most of the time "now please fix my printer".

I also become a Microsoft MVP in 2009 and started working as a trainer on different embedded/related topics. I also like to do sessions at events (if you think that some of the topics on this blog are interesting enough for your audience, just let me know).

In 2010, just a few weeks after my first son was born, I started working as a freelance for many different companies in Italy and around Europe.

Since October 2013 I joined Toradex, in Switzerland, developing mostly drivers and BSPs for Windows Embedded Compact.

I didn't go to university and I like to learn by doing. This is how I learnt to use an oscilloscope, to write applications in many different programming languages (including a short and painful experience with Java applets on Netscape around 1996), to write drivers for different operating systems and to not touch any wire coming from a power supply (this is better learnt by not doing).

I consider myself a maker. I bought some of the first Arduino released from production line (duemilanove or diecimila?) and even managed to write a book about the Raspberry Pi (it's in Italian and probably a bit outdated now, but if you want to check it, it's still available on Amazon).

In this blog, I'll just write about my experiences "playing" with different technologies, using them on different kind of hardware (working for a hardware manufacturer has some good benefits for people who like to play with devices), and trying to learn something in the process.

All the ideas and opinions you'll read here are mine.
I plan to publish all the code and things I develop during my experiments as open source, together with as much information as I can to allow you to reproduce them, but I can't promise that those experiments are good or safe to try at home :)

CUPS server as a container

As you may have noticed, Toradex (my employer) has released a preview of a new Linux-based operating system named Torizon: https://labs.toradex.com/projects/torizon I also contributed to developing a Visual Studio extension that allows you to develop native Linux applications from a Windows PC: https://labs.toradex.com/projects/torizon-microsoft-environment (more on this in a future blog...

I got an Azure Sphere kit a few weeks ago and I had a chance to experiment using it during my free time. The kits are now available and the software is in public beta and, even if it’s still lacking many features, it’s a great way to start experimenting...

Any connected device should provide or consume some data, otherwise being connected to the internet would be quite pointless, isn’t it? My clock is connected to wi-fi (that’s why I choose ESP-32 as my platform), but a connection to a local network is not enough. The clock has to collect...