KiCon 2019 - A brief Trip Report

KiCad, spoken "Key-Cat", is one of numerous Open-Source projects started by the European Organization for Nuclear Research (CERN). KiCad is widley used throughout industry and science to design printed circuit boards, PCBs. To be fair, KiCad is more than just a program. It's a collection of a couple of different programs bundled together to a suite for electronic design automation. Started by JP Charras in 1992, 27 years later Chris Gammel, founder of Contextual Electronics and author of "The Amp Hour"-Podcast, launched the first public KiCad-only event at mHub in Chicago, IL.

Our Trip started on Sunday early morning at our office in Bochum, GER. Me and my coworker Marie started with an awesome train-ride with 300 km/h between Cologne and Frankfurt, catching our plane on time, non-stop to Chicago. After a flight of about 8.5 h, and taxiing for more than 45 min, we finally got to the CBP officer, that had us stuck for almost 2 h in at the immigration office for asking about 10 s of questions. What a bummer. Nevermind. Taking a Lyft to our AirBnB was quiet fast, even thou traffic was aweful.

Looking north from Hancock

Enjoying 22°C at the Lake

All of Monday we spend on checking out Downtown Chicago, which we both had never been before. Clear blue skies and 22°C made it easy to enjoy ourselves at the lakeshore, having lunch at navy pier and wandering around on the magnificent mile and visiting John Hancock Center to enjoy a beautiful bird-view of "the Second City". In the evening we attended the NERP - Meetup at Pumping Station One. WOW! That's what I call a hacker-space. Over 1.200 m² of tools. Woodshop, Hot-Metal Shop with welding and plasma-cutting equipment, all of the electronics-tools, laser-cutters and engravers as well as 3D printers, sewing machines and a full-grown kitchen including a bar. If you ever come to Chi-Town, make sure to visit this place! It's worth it. Thank Joe at this point for giving us the tour through the space.

Beautiful view while working

Getting up early on Tuesday left plenty of time to get work done with an awesome view out of our appartments window. In the afternoon we went downtown again doing almost 30k steps, just like the day before. Visiting Millenium Park to have a look at the giant Jelly-Bean and enjoy the sundown from Hancock-Centers Skybar. Wonderful view and definitly worth having a Revolution-Brewery Beer up there.

Sundowner

At Nutella-Cafe

Giant-Jelly-Bean at Millenium Park

Wednesday same procedure in the morning, getting up early to get work done and spending all afternoon downtown. Now to have a 40 min cruise on Lake Michigan. TBH, not the best investment after all, but whatever ;) Having lunch at Nutella-Cafe was worth it after all. Visiting Ballast-Point Brewery in the evening was okay, but not a recommendation after all. No Service at the table, long ques to get a beer made it kind of a hassle to enjoy the time there.



On Thursday, finally KiCon started for us. First in the moring, meeting with schne1der_, the aisler guys, Greg aka the Twitter-Guy, Taylor and Riyad to have breakfast and look at each others electronic projects. And YES, Gregs projects do look even better than his renderings on twitter. Right after breakfast -> sweatshop. We met with Chris at the venue to help him setting up all of the goodie-bags, sponsored by Digi-Key, OSH-Park, aisler, SnapEDA and Royal Circuits. After work Chris took us on a tour around mHub. What a crazy place to work. Just like PSone this place was equipped with everything that makes a nerds heart, like mine, beat faster. Whether you'd like to use a full-grown CNC-Milling machine or a reflow production-street, it's there. This is where I got my first Take-Away from this KiCon. We need to have more places like this, where especially young people and young companies can engage with each other and learn how to manufacture real products. After a couple of hours well spent, we headed down to Ballast Point once more to celebrate a small pre-event and Hardware-Happy-Hour organized by Drew. Unfortunately for Chicago he is going to move to Berlin, Germany in a few weeks. Lucky Berlin I'd say. Lookin forward to be attending a 3H Berlin Meetup. Since it was Dountstag (from the German word Donnerstag for Thursday) we had a dozen of Dunkin Donuts at the bar, which we sold for a good advice on electronic designs here is Maries and My top five:

5 - Always check design-rules
This seems quiet obvious, but make sure, you always use built in tools to run design-rule checks. If you get messages. Take them seriously!

4 - Never ever route data-traces underneath a switching-PS
EMC is a bitch. Especially when you are running some sort of autoroute, make sure you keep data-traces clear from high frequent noises on your board.

3 - Manufacturers alter your data. All the time.
This is an advice from the aisler guys. With their profession in providing PCBs, they know what they are talking about. Even though you might send the exact same Gerber-Files to different manufacturers, you won't get the exact same board back.

2 - Double-check your footprints - Top-View/Bottom-View
Since some chip-vendors don't provide their footprints in open libraries (well Snap-EDA and Digi-Key try to achieve this) you every once in a while have to draw them yourself. Make sure you are reading the data-sheet correctly, especially whether you are using top or bottom-view footprints! Also please put your parts origin in the middle of symetrical parts and in the middle of pin 1 of asymetrical parts. This makes it way easier to extract pick-and-place data.

1 - Print out your circuitboard on paper
This is my personal top-advice. Even it looks so easy, I never ever did this before. Ask your distibutor for all an example of all of your parts, or 3D print them out and place them on a paper-printed PCB. Thus you can easily check all your footprints before shooting your Gerbers to your manufacturer!

Looking at all the awesome electronics people brought, we were all hungry for KiCon kick-off the morning after!

Bantamtools Milling

Friday morning started with breakfast-burritos at mHub. First in the morning I attended the KiCad-Beginners workshop, trying to learn, how I could improve my own KiCad-teaching-skills. I really had a great time with Shawn Hymel bilding a simple board and talking about how to teach electronics to beginners. Major take-aways out of this workshop: Bantamtools milling machines are a great tool for schools to provide their students with selfmade circuitboards. Those milling machines don't really make sense for production-purposes or real product prototyps, but as a teaching-tool: AWESOME! Take-Away #2: When teaching KiCad, make sure you ran your tutorial with the exact version your students are running. KiCad is a living product, that changes and improves all the time. Make sure to always use the newest release.

Marie took her time to attend a couple of talks. She especially liked 2 of those. First of all: Dmitry Zhgent, CEO of CADLAB.io talking about their tool for visual version controll, based on git. Everyone that has ever worked with git and KiCad knows the issues of merge-confilicts. Dmitry and his team are doing their best to show how to improve solving merging-conflict with a visual representation. Try it!
Second best, maybe not as useful but visionary, was Kerry Scharfglass' talk on alternative user-interfaces for EDA. He designed an additional keyboard-turning-know-system to improve his KiCad work on a surface studio. Even though, he wasn't satisfied with the results, he showed how EDA may improve over the next years. Hindsight is 20/20.


After a couple of sandwiches, the afternoon-sessions started. Best talk of the afternoon was Craig Bishop, showing a brief history of autorouters. He explained when to use them, and when not. Knowing the pitfalls of autorouters after this, makes me think, that we can accelarate our designs with them, without screwing everything up. If it really works, well as Beyonce once sang "If you like it then you should have put a test on it". So this will be my homework, to try using autorouters.

The evening we spend at PSone again, having a great afterparty. Thanks for your homebrew Mate Joe!

Saturday morning started and I have to admit, going to bed at 3.30 am and getting up early was a bad idea. Especially the last 3 games of beerpong were not a good idea after all, but my beerpong-buddy Kevin was even more a train-wreck that morning. Best talk of the morning was Barry Buelow, talking about his retirement hobby: his new Neoden Pick-and-Place machine. After all, it appears like a good idea to NOT do it yourself, but let experts do that for you when you want to have production-ready results. Looks like a fun passtime though.
After a really cool discussion at lunch with Mihir Shah of Royal Circuits, on how we can help manufactures providing us with the boards we need so badly, the talks on main-stage started again. 2 high-quality talks in a row. One about marketing your open-source products by Shawn Hymel (always awesome and worth it, listening to him) and one on how to use SPICE-simulations the right way in KiCad by Stephan Kulov. You should definitly have a look at them as soon as Carl Karsten loads them up to Chris' channel.
After a coffee-break I spend all of the afternoon discussing marketing your products with Matt from Amazon Robotics. Thanks for this discussion and I am really looking forward to meeting you in a couple of days in Germany!
After this super-awesome event was closed by Chris Gammel, we all went to Jefferson Tap Bar, in order to celebrate this event properly with Mike from hackday.io. A great evening of discussions which ended with Jeff Carr and me sitting at a table with more than just a few beers in our heads, discussing the future of open-source tools to manufacture silicon. I am really looking forward to what Wayne Stambough and he will come up with in the next year. Shoutout to Cadence at this point: you should probably search the discussion with Jeff at some point in the close future. I have to say I like his ideas!

All of sunday we spend at PSone again, having great discussions with all of the people from the local hackerspaces in Chicago. It was really inspiring, to see the differences in hacker-space organisation between Germany and the US. Thank you all for participating. In the evening Carl gave me a brief intro into using Voctomix. Thanks for that, I appreciate it! After a, kind of genuine, German Street-Food experience at Dmon Bar with Döner and Currywurst, we spend the evening trying Andrews robots cocktails!

Cocktail-machine by Andrew

By the way, the reason we were at PSone once again was its 10 years anniversary. Unfortunately those guys are searching for a new location somewhat close by, since their current building will be sold in a few month :( too bad.

Now sitting at a local donut-place, waiting for our plane flying in and taking us back, we realize HOW intense this week was. We learned a lot and made a couple of cool people we only knew from the internet. All of them were as cool as we would have expected it. Thanks to everyone that made this event so great for us:

Thanks Riyad, Greg, Taylor, Matt, Alvaro (btw you should listen to his Podcast "Unnamed Reverse Engineering"), Wayne, Kevin, Weston, Joe, Stephan, Stefan, Felix, Patrick, Shawn, Jeff, George, Andrew, Carl and all of the others I forgot. It was a pleasure to meet you all. And of course: thank you Chris for organizing all of this.
It almost looks like we will be organizing some sort of event like this in Germany to spread the word in Europe. If you are interested, please let me know!

Best,
Marie & Stephan

Leaving on a Jetplane 

Crosscompile Boost 1.69.0 für ARM Linux in Windows

Boost ist eine Sammlung interessanter und hilfreicher Bibliotheken für C++. Alle in Boost enthaltenen Libs sind gut getestet und erweitern den Umfang der Standard-Bibliotheken erheblich. So benutze ich Beispielsweise häufig boost/asio um Sockets für Netzwerkkommunikation zu erstellen. Viele der Boost-Libs kommen als Header-Only Library, andere müssen zunächst kompiliert werden. Wichtig zu wissen hierbei, gerade für Anfänger in C++ ist es, dass solche Bibliotheken immer für die entsprechende Soft- und Hardwarearchitektur des Systems kompiliert werden müssen, auf welchem die Bibliotheken später genutzt werden sollen. In diesem Beispiel für ein BeagleBone Black (im folgenden BBB abgekürzt).

Ziel soll es später sein, ein boost/asio Programm auf dem BBB kompilieren und ausführen zu können.

Voraussetzungen:
* Grundlegendes Verständnis der Programmiersprache C++
* Windows 10 PC
* BeagleBone Black (oder ähnliches)
* Erfahrung der Bedienung von ssh
* Windows Host und BBB im gleichen Netzwerk und Möglichkeit BBB über ssh zu erreichen

1) Vorbereiten der Buildumgebung
Zum builden der Bibliotheken benötigen wir in diesem Beispiel einen Windows 10 Rechner. Hierauf wird das WSL mit Ubuntu oder einer anderen Linuxdistro eurer Wahl installiert. Wie das gemacht wird findet ihr hier [link einfügen]

2) Herunterladen von Boost
Nach Start der WSL befindet sich die Shell in der Regel nicht im Home-Verzeichnis, dieses erreicht man dur den Befehl cd ~. Mittels wget https://dl.bintray.com/boostorg/release/1.69.0/source/boost_1_69_0.tar.gz lässt sich der tar-ball von boost 1.69.0 herunterladen. Mit tar -xzf boost_1_69_0.tar.gz lässt sich nun Boost entpacken.

3) Herunterladen und installieren der ARM g++ Toolchain
Mit Hilfe von apt, lässt sich in der WSL schnell die cross-compile Toolchain für g++ installieren.
apt install binutils-arm-linux-gnueabihf g++-arm-linux-gnueabihf -y

3.1) Crosscompilen eines einfachen Programms
Um zu überprüfen ob der Crosscompiler korrekt funktioniert, kompilieren wir zunächst ein einfaches Programm. Dazu öffnen wir einen Editor und speichern folgende Zeilen als helloBBB.cpp ab:

#include <iostream>
int main(){
    std::cout << "Hello BBB" << std::endl;
}

Mit dem Befehl:
arm-linux-gnueabihf-g++ test.cpp -o test
erstellen wir die Executable "test". Versuchen wir diese auf unserem Host-Rechner mit ./test auszuführen sollte folgende Fehlermeldung werfen:
-bash: ./test: cannot execute binary file: Exec format error
Dies liegt selbstverständlich daran, dass unsere Datei für eine andere Systemarchitektur kompiliert wurde. Mit Hilfe von scp kopieren wir die Datei auf unseren BBB, in meinem Fall wie folgt:
scp test user@134.122.141.040:~/test

Via ssh loggen wir uns nun in den BBB ein und finden die Datei "test" auch in unserem Home-Verzeichnis. Hier können wir nun unsere Exec ausführen.

4) Bootstrapping
Das Bootstrapping erstellt eine bjam/b2 Konfiguration für boost. Hierbei handelt es sich um das boost eigene Buildsystem. Für das kompilieren für ARM kann man zusätzlich folgende Optionen übergeben:

./bootstrap.sh --without-libraries=python--without-libraries=context--without-libraries=fiber--without-libraries=coroutine--without-icu

5) Anpassen des Build-Projektes
Das bootstrapping-Skript hat nun im boost-Verzeichnis zusätzlich die project-config.jam erstellt. Diese muss noch mittels Texteditor eigener Wahl angepasst werden. In meinem Fall vim:

vim project-config.jam

etwa in Zeile 12 sollte using gcc; stehen. Dieses Statement spezifiziert, welche Toolchain genau verwendet werden soll. Im Falle der cross-compilation muss hier die entsprechende Toolchain eingetragen werden. In meinem Fall:

using gcc : arm : arm-linux-gnueabihf-g++ ;

Speichern und Beenden.

6) Das eigentliche kompilieren
Der Kompilationsprozess wird mittels ./b2 gestartet. Dabei ist darauf zu achten, dass viele ARM Prozessoren nicht über alle in boost enthaltenen Operationen verfügen. Daher werden einige Libs nicht mitkompiliert. Wird dies beim starten von b2 als Parameter übergeben, stellt es aber kein Problem dar. Hier mein Kompilationsaufruf:

./b2 --prefix=~/boostForBBB/ \
    --without-context \
    --without-coroutine \
    --without-fiber \
    --without-python \
    --address-model=32 \
    --stagedir=~/boostForBBBstage-arm-gnueabihf-g++/ \
    -j3 \
    -toolset=arm-linux-gnueabihf-g++ \
    -threading=multi \

An Stelle j3 sollte die Anzahl an Kernen stehen mit denen kompiliert werden soll.
Je nach Rechenleistung der Maschine, kann der Buildprozess einige Zeit in Anspruch nehmen. Gerade 1.69.0 wirft während der Kompilation einige deprecated Warnungen. Diese stellen aber kein weiteres Problem dar, lediglich wurde auto_ptr im C++ Standard mit neueren Smart-Pointern ersetzt https://stackoverflow.com/questions/2404115/is-auto-ptr-deprecated

7) Crosscompilen eines Programmes mit boost für BBB
Boost allein belegt etwa 1GB an Speicherplatz. Damit ist Boost denkbar ungeeignet um komplett auf einen BBB, einen Raspi oder ähnliches kopiert zu werden. Auch benötigte der Zielrechner auf Grund seiner Rechenleistung wesentlich mehr Zeit um ein Programm zu kompilieren als unsere Windows-Workstation. Daher ergibt es Sinn, alle Programme auf dem Windowsrechner zu schreiben und zu kompilieren und im Anschluss auf den Zielrechner zu kopieren (wie bereits in 3.1 gezeigt).
Um unsere Boost-Bibliotheken zu testen öffnen wir eine neue Textdatei namens "timer.cpp". Wir fügen folgenden Code ein:

#include <iostream>
#include <boost/asio.hpp>

int main(){
        boost::asio::io_context io;

        boost::asio::steady_timer t(io, boost::asio::chrono::seconds(5));
        t.wait();

        std::cout << "Hello Timer" << std::endl;
}

Beenden und abspeichern. Der Aufruf des Compilers benötigt nun noch ein paar Zusatzinformationen über die Thread-Architektur und den Ort an dem sich unsere crosskompilierten Boost-Libs befinden. Ein Aufruf könnte in etwa wie folgt aussehen:

arm-linux-gnueabihf-g++ timer.cpp \
   -I ~/crossBoost/boost_1_69_0/ \
   -L ~/crossBoost/boost_1_69_0/boostForBBBstage-arm-gnueabihf-g++/lib/
   -lpthread

Ist die Kompilation erfolgreich, kann auch der Output dieses Prozesses auf den BBB kopiert und getestet werden (siehe 3.1)

Building boost 1.69.0 for ARM on Linux using WSL

So here is the situation:
While working on some smaller part of a particle detector at FAIR in the panda-Experiment. I wanted to use boost.asio in order to build my TCP/IP communication on this. First I just used "apt install libboost-dev-all" and it worked pretty straight from the beginning. Anyways, one day I wanted to try something different and got some lines of code from a friend. Trying to compile this I got all errors. GCC told me that I was using undefined references and thats when I first realized that I was still using boost 1.62 on debian stretch.

Boost 1.62.0

If you are interested in all of the Boost history please follow this link -> https://www.boost.org/users/history/

Boost 1.62.0 was released on September 28th in 2016. Which is now almost two-and-a-half years old. Since then there have been a few changes. Especially regarding asio. 

Asio was updated in 1.69.0 as well as in .67, .66 and .65. For me the most problematic part was the use of now io.context instead of io.service. Actually this wasn't that much of a problem at most points, but since I was building a new application I wanted to make sure to use the newest library of Boost available. But since building Boost on my Surface in WSL-Ubuntu wasn't that trivial, here is a little walk-through of how to build Boost for a linux-machine running on ARM.

My first fail 

Long story short, I ssh-ed onto my Beaglebone Black which was already running Debian Stretch. I wget-ed the tarball, -xzf-ed it into my home-directory and tried bootstrapping and building it. It of did not work, basically because of to few resources on the machine. So quite fast I came to the conclusion that I had to build it on my laptop and scp it when it is done.

Using WSL to compile Boost

WSL is one of the coolest features of newer Windows releases. I basically gives you most of the functionalities of a full-blown Linux, but running on a day-to-day Windows-Machine. I love it. I assume, that you already installed WSL and are familiar with using it. 

First of all I used "apt update" and "apt upgrade" to make sure I am using updated tools. If you haven't installed a handy text-editor at this point. Try installing vim. That's what I am using for this walk-through. Further more you need to apt install gcc g++-arm-linux-gnueabihf to install gcc and the g++ cross-compiler for ARM-Linux targets.

cd into your ~ directory and wget the newest version of Boost from the boost.org-page. At the date of writing this is 1.69.0.

tar -xzf boost_1_69_0.tar.gz to extract the tarball. mv boost_1_69_0/ boost_1_69_0.ARM to get rid of confusion later on.

Run ./boost_1_69_0.ARM/bootstrap.sh to prepare the compilation environment.

No we are coming to the tricky part. Building the boost-libraries themselves. First modify the project-config.jam adding " : arm : arm-linux-gnueabihf-g++" between "using gcc" and ";".

<esc>, :wq to write the file and close vim.

vim buildmyboost.sh makes a new file and opens it. Add the following lines:

./b2    --prefix=~/boostForARM/ \

        --without-atomic \
        --without-chrono \
        --without-container \
        --without-context \
        --without-contract \
        --without-coroutine \
        --without-date_time \
        --without-fiber \
        --without-graph \
        --without-graph_parallel \
        --without-iostreams \
        --without-locale \
        --without-log \
        --without-math \
        --without-mpi \
        --without-python \
        --without-random \
        --without-serialization \
        --without-stacktrace \
        --without-test \
        --without-thread \
        --without-timer \
        --without-type_erasure \
        --without-wave \
        --address-model=32 \
        --stagedir=~/boostForARMstage-arm-gnueabihf-g++/ \
        -j4 \
        -toolset=arm-linux-gnueabihf-g++ \
        -threading=multi

This script configures and runs the build of your Boost for ARM-Linux. <esc>, :wq to write and close the file and make this script executable by using chmod +x. Now run ./buildmyboost.sh. After this, works. You may think about which libs you actually need and delete them from your build-script. In my case, I've got all I need. Hope this helps you! 

Cheers

Stephan