Category: Yocto

Photoframe Hack

Sometimes you just want to get something done. Something for yourself.

You do not intend it to be reused, or even pretty.

You build a tool.

My tool was a photoframe with some basic overlays. I wanted the family calendar, some weather information (current temperature + forecast), time, and the next bus heading for the train station.

To make this acceptable in a home environment, I built it as a photoframe. You can find the sources in the hassframe-ui repository on my github.

A hidden feature is that if you tap the screen, a home automation control panel slides up. That way you can control all the lights, as well as heat in the garage and an AC in the bedroom. Very convenient.

All this is built using QML. Three somewhat useful models are available:

  • IcalModel, taking a URL and parsing whatever it gets back as ICAL data. It is a very naive parser and does not care about things such as time zones and other details.
  • YrWeatherModel, uses yr.no‘s public APIs to pull out a weather forecast for a given location.
  • ButStopModel, uses the APIs from resrobot to look for departures to the train station from two bus stops close to my home and then merge the results into a model.

I also have a bunch of REST calls to my local home assistant server. Most of these reside in the HassButton class, but I also get the current temperature from there. These are hardcoded for my local network, so needs refactoring to be used outside of my LAN.

All of these interfaces require API keys of one kind or another – be it a proper key, or a secret URL. These are pulled from environment variables in main.cpp and then exposed to QML. That way, you can reuse the components without having to share your secrets.

All in all the code is quite hacky. Especially main.qml. I refactor out parts from there now and then, but the photoframe works, so its not anything that I prioritize.

Currently it runs on a Raspberry Pi on top of Raspbian. I want to build an optimized Yocto image making it less hacky and more pre-packaged. Perhaps there will be a rainy day this summer and I’ll get around to it. Burkhard has prepared the instructions needed over at embedded use.

The Cost of no Architecture

Like many others, I enjoy various reverse engineering and tear-down stories. Personally, I mean things like iFixit tear-downs and Ken Shirriff’s blog, so I started following this tweet thread by foone.

This continues with another tweet sequence about getting software running on the remote control. Having enjoyed these tweets, I started thinking.

The Harmony remotes are quite expensive in my mind. I can’t find any exact numbers for the number of sold devices, but I found this 2018 Q4 earnings report. Looking at the net sales, I guess the remotes are either “Tablets & Other Accessories” or “Smart Home”. They represent sales net sales of ~107 and ~89 MUSD over 12 months. Let’s pick the lower number and just look at magnitudes. The Harmony 900 seems to have retailed for ~350 USD back when it was new. So, if all the Smart Home stuff was harmonies, we’re looking at 250k units over a year. So I’m guessing the magnitude is around 10k – 100k units annually – but the Harmony 900 is from 2013, so I assume that it sold closer to the lower number, if not below. The market was new and so on.

Then we look at the tweets again. What have we got? Let’s put aside security issues, unencrypted communications, and other clear mistakes and just look at how the device is built.

Flash to drive the UI, double web servers on-board, Lua, QNX and what not. A 233 MHz CPU and ~64MB of FLASH – for a remote control. From an engineering perspective, this sounds like a fun system to work on – from an architecture perspective, it looks like a ball of mud.

Back in 2013, QNX might have been a good choice compared to Linux. Today, with Yocto and similar tools for developing embedded Linux systems, it feels like an odd choice to add a license cost to such a device. But no biggie. Back in the day this was not an unreasonable choice (and still isn’t for certain applications).

The Flash stuff. There were alternatives back in 2013, but sure, there were plenty of developers at hand and things like Qt QML was still probably a bit clunky (I can’t recall the state of it back then – it required OpenGL ES, which I guess was a big ask back then).

But the mix of techniques and tools. The on-board web servers. The complexity of a small system and the costs it brings to maintenance and testability. If this is the foundation for Harmony remotes and a platform that has been used for the better past of the past decade, I wonder if the added engineering costs for architecture the platform to be more optimized early on would not have paid off in lower maintenance costs, as well as lower hardware costs.

I know how it is when you’re in a project. The deadline is there in big writing on one of the walls. You can get something working by stringing what you have together with duktape and glue. The question I’m asking myself is more along the lines of how do we run embedded systems engineering projects? Where did we go wrong? Why don’t we prioritize the thinking and refactoring over the just-get-this-thing-out-of-the-door?

The answer is time to market and such, but over a decade of building on a ball of mud, the economical numbers start adding up in favour for the better engineered product. For continuous improvement. For spending time thinking about how to improve the system as a whole.

The Embedded Talks

The foss-north conference strives to have an assortment of various talks. The point is that visitors should see something unexpected and that the conference should attract all types of visitors to ensure that we as a community can meet across various industries and problem spaces.

This time I’ve selected three talks about embedded systems from foss-north 2020. The talks touch on building embedded systems around Linux. If your reader does not show you the embedded videos, make sure to follow the actual page or go to our conf.tube channel to see all the contents.

First out was Ron Munitz talk on understanding and building minimal Linux systems. This talk proved to be a real deep dive into the Linux kernel – including setting up a debugger to the kernel itself.

The next embedded speaker on the program was Chris Simmonds. He discussed if going with Yocto or Debian is best for your embedded Linux project. This an interesting topic – how much is customization worth compared to other aspect such as build-time.

The embedded set of talks ended with Drew Fustini talking about running Linux on the RISC-V. This talk dives deep into the hardware part of embedded systems, but also Linux. By being able to run Linux on RISC-V, which is open hardware, we are very close to an completely open eco-system.

The three talks are already available on conf.tube, and the presentation material can be found by following the links to each speaker. For those of you who prefer YouTube, the talks will be made available shortly on the foss-north channel. Subscribe to get notified when they are.

Five days left

I use to joke that the last week before foss-north is the worst – everything is done, all that is left is the stress.

This year, we have the broadest program yet. 25 speakers talking about everything from community policies, GPU isolation, blockchain, historical KDE software, retro computers, IoT, Android, SailfishOS, bug triaging, crowd funding, software updates, yocto, home automation, design to sub-atomic particles.

You can still get a ticket (and make sure to bring a friend) at foss-north . Welcome!

foss-north 2017: Call for Papers

The Call for Papers for foss-north is open for another week (until the 12th). This gives you an opportunity to speak in front of a great crowd. Looking at the results from last year’s questionnaire, more than 90% are users of open source software and more than 50% are contributors. One thing that surprised me, is that more people actually contribute as a part of their profession than as hobbyists. Looking at the professional vs hobbyist proportions, 45% of the visitors stated that they had their ticket paid by their employer/school, while 42% paid them out of their own pocket.

The topic of the conference is free and open source – so anything related is much welcome.We do not even limit ourselves to software – hardware, patents, community and much more is also appreciated topics. Last year we had speakers talking about timing synchronization over vast networks, patent issues, working as a designer, linguistics and must more.

As always with these things, crowd dynamics means that me as an organizer has to work on my stress management abilities. Almost 30% of the tickets to last year’s event was sold in the last two days before the event. The same goes for Call for Papers – nobody registers a talk in good time before the deadline. So if you want to help an ageing developer keeping the pulse under control – submit your talk proposal now! ;-)

foss-gbg on Wednesday

If you happen to be in Gothenburg on Wednesday you are most welcome to visit foss-gbg. It is a free event (you still have to register so that we can arrange some light food) starting at 17.00.

The topics are Yocto Linux on FPGA-based hardware, risk and license management in open source projects and a product release by the local start-up Zifra (an encryptable SD-card).

More information and free tickets are available at the foss-gbg site.

Welcome!

Vacation 2015

IMG_20150703_172538So, vacation has finally arrived in 2015. To the despair of some, and joy of others, the Swedish standard vacation is 3-5 weeks over the summer. I’ll be having five weeks of this year.

So, what do you do with five weeks? Generally, I start out ambitious and end up in reality after 3-4 weeks and then scramble to get something done. Here is my list for the summer 2015:

  • Hang out with the kids and wife and do fun stuff.
  • Do some work around the house (a shed for our bikes and some general painting are on the wish list).
  • Get the calendar for foss-gbg into place. It does look as if we will have an awesome autumn.
  • Work on a whole bunch of little Yocto projects that I’ve been planning for a while (meta-kf5 being one of the high priority ones, playing with various targets such as the Raspberry Pi 2, Beagle Bone Black and more another).
  • Getting my 3D printer back into shape and do something fun with it (if it rains a lot)

That summarizes my ambition pretty much – but first things first – lets spend a few days hanging out with the kids before they grow tired of me and think that I’m old and boring :-)

meta-kf5 usable

Finally I’ve had the time to work over the final issues in meta-kf5. Right now, I build most tier 1 and tier 2 components. I’ve packaged most functional modules and integration modules from these tiers.

When it comes to integration modules, there might be missing dependencies that need to be added – but that should not be too hard to add.

To be able to create useable cmake files, I had to employ a small hack modifying the cmake-files from KF5 before installing and packaging them. This seems to work (i.e. tier 2 builds), but there might be other sed-expressions that are needed.

Also, the autotests are not built as long at Qt5Test is left out form the build. If you would add Qt5Test, I believe that the unit tests will be included in the same package as the libs. I’ll address this as I integrate the autotests into ptest.

Summing up all of this, I’d say that the meta-kf5 layer now is usable!

That is all for now. As always, contributions are welcome! If you find a use for this, I’d be happy to add your project as a reference to the layer!

meta-kf5 – almost there…

So, as of tonight, all but three tier 1 modules from kf5 are built in meta-kf5. The ones remaining are KApiDox, which does not really apply, and KConfig and Sonnet, which both needs to be part built for the native host environment, and part cross compiled. So, any Yocto hackers out there, please have a look at the issues linked to from the meta-kf5 status page.