When I started in this new project, the developers on the project desired to use a container 'solution' to test and develop their code, because "developing new application and testing it in Yocto was really difficult". I was triggered by this statement because it was completely false. Since the beginning Yocto offers recipetool and nowadays devtool to make the development of new applications easy to have a cross-compilation application that just works in the MACHINE that you set.

I remember when I made my training on Bootlin that the trainer said "Yocto is one of those tools that allow you do anything, even the wrong thing". At that time and I just laughed, but now I understand better what they meant. For all newbies in Yocto I highly recommend reading the documentation, because it is really well written and it explains a lot of the things that you could do with Yocto without reinventing the wheel.

One of those things is the creation of recipes based on git repositories 'automatically' and test your code. The Yocto developers created devtool a python script that allows us to use the bitbake context to create, modify, upgrade and deploy a specific recipe. This tool ease the development of new application on Yocto environments and present the opportunity to deploy your custom solution on a already-running machine.

The --help of the devtool already give us an idea what else can be do with the tool. As you can see, there are plenty options to choose. However, I personally thing the most valuable are: add, modify, build and deploy-target.

devtool --help
NOTE: Starting bitbake server...
usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] 
       [-d] [-q] [--color COLOR] [-h] <subcommand> ...

OpenEmbedded development tool

options:
  --basepath BASEPATH   Base directory of SDK / build directory
  --bbpath BBPATH       Explicitly specify the BBPATH
  -d, --debug           Enable debug output
  -q, --quiet           Print only errors
  --color COLOR         Colorize output (where COLOR is auto, always, never)
  -h, --help            show this help message and exit

subcommands:
  Beginning work on a recipe:
    add                   Add a new recipe
    modify                Modify the source for an existing recipe
    upgrade               Upgrade an existing recipe
  Getting information:
    status                Show workspace status
    search                Search available recipes
    latest-version        Report the latest version of an existing recipe
    check-upgrade-status  Report upgradability for multiple (or all) recipes
  Working on a recipe in the workspace:
    build                 Build a recipe
    ide-sdk               Setup the SDK and configure the IDE
    rename                Rename a recipe file in the workspace
    edit-recipe           Edit a recipe file
    find-recipe           Find a recipe file
    configure-help        Get help on configure script options
    update-recipe         Apply changes from external source tree to recipe
    reset                 Remove a recipe from your workspace
    finish                Finish working on a recipe in your workspace
  Advanced:
    create-workspace      Set up workspace in an alternative location
    extract               Extract the source for an existing recipe
    sync                  Synchronize the source tree for an existing recipe
    export                Export workspace into a tar archive
    menuconfig            Alter build-time configuration for a recipe
    import                Import exported tar archive into workspace
Use devtool <subcommand> --help to get help on a specific command

In the blog How to use devtool to create and test applications on Yocto, I will explain the benefits of working directly with yocto for creating custom libraries and how you can test your code on the machine by using the approach used on the Yocto community to test their images. See you there 👋🏻

When you started with Yocto for the first time. It could be overwhelm to not know what to expect. I remember when I started working with Yocto my first thought was: "This is very cool, but also extremely complex". I spent a good amount of time with my developer leader and myself until I grasp a good amount of knowledge about this tool. In this blog, I want to summarize five things that you need to know before working with Yocto.

Makefile and Yocto​

I think this help me a lot to understand what Yocto does and how:

This for me is the golden concept to understand. With yocto you have syntax divide into different sub-topics that we are going to discuss later, but in general is a series of steps to build and create a custom Linux distribution to play on a Embedded device, exactly as Makefile is a series of task that could depend one of another that creates at the end an ELF file.

Recipes and Bitbake​

When you get the naming of Yocto, you start going into the direction of understand everything quicker. What is a recipe? is just a set of instructions to prepare a dish. A recipe in yocto is exactly that, it is a set of instructions, but instead of preparing a dish, we prepare packages. Bitbake is the tool that we used to bake the recipes, hence the name! 🍳

The recipe will create the main package named after the recipe name with all elements the application needs to work (configuration files, ELF file, systemd/SysV file, etc), but also creates dev or doc packages and this can be also added to the image if necessary.

Dev packages for example are used when this particular recipe is require as dependency for another one. Imagine in this case a shared library. For that matter, the dev packages has all the include files *.h/*.hpp that are only needed it on build time. The main package in this case will have the *.so files that will be required while running the image.

The layer model​

One of the big advantages of working with Yocto and also the root of a lot of bugs on misuse are the layer concept. This concept was designed for collaboration and customization. A layer is nothing else as a container of recipes. The layer has to has an specific format to be recognize as layer for Bitbake engine, but in general is just a set of recipes.

Why collaboration?​

As industry standard for custom linux distribution, there are many companies working together to create those layers. A layer could be a core element of the project like openembedded-core, which contains all important metadata to make a minimal build. Or specific layers like meta-virtualization which is recipes to support building Xen, LVM associated packages.

All of the above-mentioned layers and way more are open-source license and you use it as a base to create your own custom distribution. If you don't need virtualization on your Embedded device, you just don't add it. There are many well-maintained layers on the community.

Why customization?​

One of the design decisions on the layer model is that every layer has a priority. As you may anticipate, the lower priority layers are the community-layers that you are using and on top of it, your layers. In your layer you develop your own applications or you customize something from the community recipe of an open source project.

As an example, when I was working on a NTP server/client for our Embedded device, I decided to go with chrony. However, the default package configuration of chrony in the community layer was not enough for me, so I create an append of the recipe and change the package configuration.

Because of structure of layering includes our customize layer, the append recipe is merge with the original one and I got a package that has the configuration that I desired. This is why the customization is one of the biggest gains on working with Yocto. If in the future we need to add an extra configuration package to chrony or even de-feature a particular configuration, we can easily do it by changing the append recipe without ever changing the original community-layer recipe that we based upon.

The environment of Bitbake and gcc​

For those who were already involved on cross-compilation before, it is easier to grasp the concept of the bitbake environment. We basically cannot use th compiler of our computer (normally a x86 architecture) to create ELF files for a Embedded device that are normally RISC architectures, like ARM processors.

For this particular reason the reality is that Yocto creates a environment where everything is set to build an image for that specific machine with an architecture type. The sourcing of the environment is essential, it is the first thing that you need to do to have all variables require by bitbake to work properly.

Once you source the environment you get the bitbake command line and all their helpers (devtool, oe-*, etc). One of the first things that we will be building with Yocto is actually the right compiler depending on the MACHINE variable that you set. The community core layer already provides machines so that you could based upon them to create your own.

# QEMU ARM 64 bits machine
MACHINE=qemu-arm64 bitbake image-core
# Real custom hardware of ARM 64 bits machine
MACHINE=awesome-arm64 bitbake image-core

Final tips on Yocto​

Start your recipe image simple​

The biggest advantage of creating your own custom GNU/Linux image is of course you control what goes inside and the size of it. Start as small as possible and add the things that you will actually need. Use the built-in variables to control the size of the rootfs as much as possible.

As any other package made with Yocto, the final image is also a recipe. You basically starts with the following file:

# Build a simple, minimal root filesystem.
# This recipe is a simplified form of core-image-minimal.

SUMMARY = "A simple, minimal image"

inherit core-image

IMAGE_INSTALL = "packagegroup-core-boot dropbear"

Once you have this starting image you start adding what you actually need inside of it. This image uses dropbear for SSH because it is smaller than openssh, but this is also available in the community-layers.

Use QEMU machine as much as possible​

Everything what you can do in software without intervening in hardware is a gain. However, as always, there are trade-offs. I spent a hard-time trying to convince the Product Owner of the new product that I was developing that having a container-software testing for a particular part of our embedded project was causing more harm than good. But, don't get me wrong, test in software as much as possible and leave the hardware testing (more expensive, more time-consuming) for future stage of your project.

For that particular reason, QEMU machines for ARM 32 and 64 bits are available from the beginning in Yocto. You just need to start with the image recipe that I put you above and start building your project stone by stone.

Using QEMU brings another big win, which is the possibility to create a CI-CD pipeline on purely software elements to verify how well or bad behaves your system. This is a complex topic and I will maybe create a tutorial in the future for it.

My Dos and Don'ts Lemmas​

This is the list of things that I wish to know before going on a full-time job working with Yocto as building tool. This tips aims to reduce the burden of maintaining a Yocto project and making your life easier as developer and any newcomer to the project.

Okay this was longer that I expected to be honest, but I just wish to have such ideas before starting with Yocto. Starting on Embedded devices with Yocto as a building tool is a really cool experience and I wish this give you an idea why this tool may seem so complex at the beginning, but afterwards it will just make sense. Thank you for your time, if you want to add something, I would love to see you in the comments!

Let's start with an example of a library foo. This library is a C++ code that wants to be used in several places. This will not only handle internal process communication throughout zmq, but also it used a custom-logging library foo-log and another common library called foo-common. This maybe a huge library, but it is perfect as an example. If we make a search in the ELF file, we find out what we talked about, we have some standard library dependencies (not an issue) and our custom libraries.

readelf -d libfoo.so | grep NEEDED
 0x0000000000000001 (NEEDED)      Shared library: [libzmq.so.5]
 0x0000000000000001 (NEEDED)      Shared library: [libsystemd.so.0]
 0x0000000000000001 (NEEDED)      Shared library: [libfoo-common.so.1]
 0x0000000000000001 (NEEDED)      Shared library: [libfoo-log.so.1]
 0x0000000000000001 (NEEDED)      Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)      Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)      Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)      Shared library: [ld-linux-aarch64.so.1]

Now let's image that we have several C++ applications where we would use that library. This may not happen in several software projects, but in Embedded Development, you are very likely to use not only one binary that solves all, but rather several processes that are acting as daemon in user-space. In all my projects, there has been always at least a custom-library that looks like that. For our example, if we want to call the foo library, our CMakeLists.txt could look something like this:

add_executable(app-foo ${MY_SOURCES})
target_link_libraries(app-foo foo foo-common foo-log)

Since our custom foo library uses the other two libraries, every time that we want to create an application, we need to add those extra library flags. The problem arises when we upgrade the foo library. Maybe, we found out that we need to secure some user input and we require some encryption algorithms. So now the library requires also libcrypto.so. This will immediately breaks all build scripts. Our project will no longer build and we have to do maintaining work on those build scripts. To avoid this technical debt (at least one, right?), we use a very old but reliable tool pkgconfig.

The whole idea behind pkgconfig is that the maintainer of the library is in charged of updating the require compiler and linker flags to avoid this situation that I mentioned before. Using pkgconfig in this case, we now just ask for the package of the custom-library and it is the same library that tell us, which libraries we required to build our application without problem.

find_package(PkgConfig REQUIRED)
pkg_check_modules(FOO REQUIRED IMPORTED_TARGET foo>=1.0.0)

# same lines as before
add_executable(app-foo ${MY_SOURCES})
target_link_libraries(app-foo PkgConfig::FOO)

With this new approach we decrease substantially the technical debt of our build scripts. We no longer need to worry whether the shared library will add or remove compiler or linker flags because we handle everything inside of the pkgconfig file, which is part of the source code of the custom-library. Even if the library is install in a non-default path for a library, using the information in the pkgconfig file, our build script will able to give the right information to the compiler and the linker.

Now hat you understand why this is necessary, let's deep into the implementation of a pkgconfig for your custom-library. See you there 👋🏻

In this blog, I will discuss some of the amazing open-source tools that I used on my daily basis while developing Embedded systems on Linux. I will mention why I find it useful and how you can install it and test it by yourself.

Faster editors over fancy IDEs​

I know that this may be controversy, but I am not a fan of IDEs. I understand the value, I see some advantages but most of the time an Editor with some good capabilities works as good as a super powerful (and very expensive) IDE. For my personal projects and my work I used VS Code and NVIM. You may considered both normal editors but with the right amount of extensions/plugins, you will have the speed and performance of a text editor with some of the most important features of an IDE.

I considered myself as a primary developer on VS Code, but having a terminal text editor came with a lot of advantages and overall you could use it in almost everywhere. Besides, being a superset of vi is the best. I was in the past always a nano user, I find it more friendly. I think until this date, the most voted question of StackOverflow is how to exit vi 🤣. However, you cannot denied vi is everywhere and I love that, so I made the switch from Nano. I love how fast it is and how easily you could search for hundred of items without seeing any lag whatsoever.

VSCode extensions​

The VSCode extensions depends a lot what you developed and there are an enormous amount of blogs telling you the best extensions. I always said, you should use what it works better for you. Some of the less known extensions that I used are:

• autoDocstring and Doxygen Documentation generator to create documentation with sphinx and doxygen
• Shellcheck to integrate the amazing terminal tool shellcheck for bash static analysis into VS Code
• Advance-new-file to create files and directories easily anywhere in the workspace
• Better Jinja and Better YAML Formatter when working with Jinja templates and YAML files

The rest of my extensions are really well-known and I don't see the value to put it all here. I have C/C++, Python, PHP, Javascript and Web-development extensions to make my life easier when dealing with the different parts of my projects.

Kickstart.nvim​

I was a happy vim user, I had a few plugins, a basic theme and I thought that was enough. Until I came across to a YouTube video that change everything, the first two minutes of that video are epic, I will not spoiled, you have to go to see by yourself: The Only Video You Need to Get Started with Neovim. Since then I am up-to-date to the last version of nvim and loving everything new what come with the change. The Kickstart.nvim is exactly that, a starting place to create your experience with nvim. I personally recommend to play with it, because the developers of the configuration file really put some effort to make nvim amazing from the beginning and explain everything really well.

A Theme to rule them all​

When I like something I keep using it until I find something better, I have used a lot of different themes for my NVIM and VS Code. However there was one for me that it is just perfect and that's Tokyo Night. This theme is well known when you search for themes, it is very popular and it exists in a range of different editors and IDEs and that's make it perfect for me, because there is a version for VSCode and NVIM. I came across with it and since then I never look back. I love how it looks. I forked the original extension in VSCode to make it more perfect for C++ and some changes for YANG. If you are interested, let me know 😎.

I don't use icons on NVIM, I like to maintain it as clean as possible, but for VSCode I have tested a lot and I just love my last finding Bearded Icons.

Terminal essentials​

Most on my work is on terminal, the building process of Yocto projects is quite heavy, so I rely a lot on the building server of the company for the builds. That's why I have been searching for tools that make my life easier, I will explain briefly all of them and tell you why I used it.

zsh​

I have to say, I have not find any reason to use bash over zsh in your desktop, if you want to debate please leave a comment. But, there are so many advantages in zsh and a lot of people working to make it even better. My setup is easy: zsh with Oh-My-Zsh as based and PowerLevel10K. The last one is sadly no longer actively maintained, but the customization is crazy and I love how my shell looks like. I even added it to the build server 😅

tmux​

If you work on terminal and you don't use tmux, you need to learn it ASAP. It is a life changer for me. If you learn the basic shortcuts of tmux, you will feel like having a mouse is optional. It is crazy how my productivity has changed since I started using tmux. I used tmux a long time ago, but it was in my last job where I took my time to customize it to my needs. I used tpm as tmux plugin manager and also recommend tmuxp. The last one is a terminal tool that allow you to create complex tmux sessions saved on a YAML file. Pressing a command that generates automatically all my windows and panes, it is just amazing. The best part is that is able to detect if the project exists by their name in the tmux server.

Terminal Gems​

I came across another YouTube video looking for tools that you need in your setup. Most of the videos are always the same, they talked about the same tools that any developer have at least heard once. However, I saw this video 7 Amazing CLI Tools You Need To Try from Josean, and it was really the first time that almost all tools were new to me and really useful. He explained really well the setup in his website, I will just mention why is that useful and let go check his tutorial.

bat​

This is an improvement over cat. It did not replace cat from my point of view, but when you want to see a file quickly but want a syntax highlight, bat is your friend. They even have a Tokyo Night theme 👀

eza​

This is the same as ls but with icons and more useful colors. This is maybe the less useful gem, but I always like a better look 😅

zoxide​

This is an improvement of cd. I don't like the name and I am really used to use cd, so I make an alias in my .zshrc. The idea is that it remembers the paths that you were using and jump into the directory.

fd​

This is a better version of find. This tools allow different new features that are useful for the last and most cool of the gems. Something that I really like is that it can ignore the folders and files in your .gitignore. This is specially useful in my setup, where the whole build process of yocto is enormous and most of the time, I don't need to search there.

delta​

This tool is a pager used by git to display the diff in a project. Their setup is a little complicated but is well explained in the README of the project.

fzf​

This is basically a fuzzy finder for your terminal. The best parts is that all the above mentioned tools works together with this one to create really cool stuff. It changes for good how you look for things. My selling point for this one was the fuzzy search on processes, I was speechless. Basically you put in you terminal kill ** and press Tab and you will went in fuzzy search mode for all processes in your computer 🤩. You can use it with a lot of useful tools like cd and find. It makes your search for files and directories way more easy and fast. I was really impressed that this cool interfaces do not came with a performance cost (at least noticeable). I am never coming back to the old ways.

That's it, I hope you find this useful and try to use this new cool terminal tools that I found it improves my way of work. See you the next time 🤟

Yet Another Opinion about Yocto vs Buildroot... If you ever come across to work with YANG, I hope you understand the reference. If you don't have a clue what I am talking about, don't worry, I have no clue of YANG and SNMP until a few months ago 😅. As you may get for the title, I will just write why I think Yocto and OpenEmbedded is the right tool for building your custom Linux Embedded systems, even for personal projects. Let's go into it 🤓

When you deep into building custom Linux systems, there is almost certain that you will get across the question: Should I use Buildroot or Yocto-OE?. You start digging into some forums and blogs like this one 😛 to see what other people with maybe more experience thinks of the topic. I certainly asked this same question during my training on Yocto to Luca Ceresoli, our very prepared trainer, which works as contributor to both projects.

He mentioned at that time something that surprise me. I commented that one of the reasons why I went to learn more in deep Yocto was because I saw a lot of job application in my field requiring to have some knowledge in the topic. I saw this as a sign that companies uses Yocto over Buildroot. I may fall into a confirmation bias, because he mentioned that on Bootlin, they advice Yocto and Buildroot projects almost equally and the reason why I may not see more mentions on Buildroot is because of his simplicity.

This is exactly the selling point of Buildroot. If you have ever compile a C code in your life, you will feel close at home with Buildroot. This tool uses a series of Makefiles to create the whole image of the product. This is really incredible because it makes a building custom linux OS more easy to grasp, it gives you the things that you may need and everything with a .config. Easy to understand and easy to modify.

Although I see a lot of value on simplify this process that could be really complicated, it does not give you a lot of room to play with. If you want to have different machines, you have to create a config for everyone of them, you cannot simply re-use things. You may not need to change the basic applications of your custom linux for all of it, so why don't we use the same? Because Buildroot creates an root filesystem as an image, you are unable to change or adapt the things, you have to modify the config, but they do not share configurations, even if you need the same thing.

On the other hand, yocto sells itself as a distribution building tool. It creates a sort of complex binary package system to create an image. Everything in yocto starting from the kernel is a package and the final process is to bring all those packages together and create the final root filesystem that you want. As you can see, it looks more complex and you will have a steep learning curve to understand how yocto works. But now, you are working by packages, should that means that you could interchange packages from one machine to the other if they based on the same processor? Well that's exactly the advantage.

Yocto works with layers and every layer has a priority. I will not going into details here, but it allows us to create an abstraction between those layers. This is perfect for projects with a lot of teams because you can divide the different parts of the project. This abstraction plays an important role because you could even abstract the whole hardware from the software part. Yocto will re-use everything what it could use to create new machines. This is exactly what I felt is really valuable of Yocto.

I think the complexity of Yocto pays off. They successfully creates abstractions using their layer concept, therefore vendor chips companies have been working closely with Yocto developers to create their own layer that implements their chips. Every single one of the big manufacture companies has their own layer where they create the machine configuration that you need to run your custom Linux OS.

I think at the end the support of vendors and Open Source Foundation is what it plays a big role for me to choose Yocto. When you are developing Embedded systems you have to think what is going to be available for the next 10 or 15 years. Once you sell a piece of hardware, depending on the sector, they will not upgrade for a long time, but they will ask for security updates, new software features and a long etc. So from a product perspective, you have to be prepared.

Another reason why I choose Yocto over Buildroot is because of their documentation. Let's be honest, we all hate to write documentation, I do not know the first developer who tells me: "The part that I love from coding is to write the documentation". No, it did not happen and if it happens, you may check if coding is really what you like 🫢. Joke asides, the documentation of Yocto is amazing, I really do not have another word for that. It is the open source project with the best documentation that I have ever used and I have been a Linux and open source enthusiast for more than 10 years. They even have a section called What I wish to know before working with Yocto and it really helps 🤯. They have poky an example distribution just that you understand how to build up your project. The documentation of Yocto has been on my bookmarks for around two years and every time that I visited the website I just find it incredible useful.

And that's it, you will find in this website some tutorials about my findings developing with Yocto. Things that I found useful to know and I will try to make it as understandable as possible because I know how hard it could be. So let's keep in touch, go check the tutorials section, I hope you find it interesting.

Building Linux systems is still tough, but Yocto and Buildroot simplify it a lot. In this blog, you will see the problems of building a Linux embedded device from scratch and why these tools changes the game for better.

When I was looking my first embedded development lecture at the university in Colombia, I remember the overwhelming amount of things that you have to take into consideration just to compile a small hello-world C code in a soft-core processor for the FPGA that we had. So many information, even when it is useful, is really complicated to grasp and it scares a lot of people (a lot of my colleagues gave up on the subject). I considered myself a fast learner and there were things in that class that I understood until I have a similar lecture on my master.

Nowadays there are closed and open solutions to solve this kind of problems. If you want to play with a SoC FPGA kit now, Xilinx explains really well what you have to do to have a soft-core. Even the TU Dresden and some other German universities (like mine) use an open-source solution made by TU Dresden called SpartanMC project to reduce the complexity of this type of knowledge and give you a simple ready-to-use processor with the one you can play with.

Building a Linux system for an embedded device is also really complex. You can try (I certainly want to try) to build a Linux system for a different architecture as x86 from scratch. You not only have to think how are you going to compile everything (it is a different architecture 🤯), but you also need to think in the bootloader, the Linux kernel (networking, filesystem, task/memory management, etc), the C library that you want to use (there is more than one 🤯x2) and then finally you are in userspace. I love diagrams and this one explains really well the point.

Now that we are on userspace, are you sure that make it easier? Being users of a SO and almost everything (I talk to you Linux Bluetooth) works out of the box, we tend to forget how complex userspace really is. How do you know the C library version you are using is compatible with the latest version of tar? Do you want to work with systemd or are you old fashion and want init.d files?

Are you still with me? Even if you are an experienced Linux user, this is a lot of information and you could make it wrong easily. It would not be your fault, also not Linus Torvalds' or open-source community's fault. Complex problems means complex solution, even when we tried our best to avoid it.

That's why a lot of good developers with good intentions had created different building tools that makes this process less painful. Please do not get me wrong, it is still complex and you have to understand what is the role of almost everything, but now, you don't have to do it everything from scratch every time. You can create configuration files to define your machines and the best part, the chip vendors supports this open-source projects because it really decreases the difficulty to create new embedded devices. You don't have to worry about mismatch on versioning tools, because this building tools will throw you an early error if the versions are not compatible.

Sound better right? As you may understand for the title, there are two main projects working on this topic, both of them open-source projects, but they work fairly different. The Yocto Project which is founded directly by The Linux Foundation and Buildroot. You can find a lot (really a lot) discussions about why is one better over the other one. I will be giving my opinion is another blog too, but what you need to know now is that both tools solve a lot of problems:

• I want to support different devices with different hardware peripherals, but same kernel ☑️
• I don't care about kernel space or hardware, I want to focus on userspace ☑️
• My hardware design is really complex, I need to make a kernel almost from scratch, but then userspace is very basic ☑️
• I don't want to deal with bootloader, I just want that works for my device ☑️

As you see, I could give you a lot of examples why these tools solve a lot of problems. They allow you to go as customize as you want in certain area and leave the other ones as basic as possible to make you focus in what really matters for your development. You save a lot of time and money with it. I would not recommend nowadays to anyone a Linux embedded development from scratch, only for learning purposes.

Embedded development has come a long way. What used to be a mountain of complexity is now more like a manageable hill, thanks to both closed and open-source solutions. Sure, building a Linux system for an embedded device is still no walk in the park, but projects like Yocto and Buildroot have made it a lot more doable. These tools help streamline the process, ensure compatibility, and reduce errors, so you can focus more on creating cool stuff rather than fixing endless issues.

I am Embedded Software Engineer and am almost thirty years old 👴🏼. I did my bachelor in Electronic Engineer in the biggest public university of Colombia in Bogota, where I found a fascination for embedded development. When I was doing my internship in National Instruments Dresden, I found out that there were a sort gap of knowledge in embedded systems development.

From one side, people who knows a lot of hardware that knows a little how software works, and in the other side, people who knows a lot about software but no so much of hardware. This complicates at the end the deliver of good embedded products in several ways, like unrealistic business plans (my daily basis at work), not an effortless communication between the hardware and software team and so on. Having a knowledge of both worlds helps you understand several problems before they even happen.

I remember once a colleague telling me that he insisted the HW team leader to choose another WLAN module for the new devices. The module the HW team were testing, wouldn't fulfill the software requirements in their fullest and it will make the development a nightmare, because the module was well known in Linux community to be not very developer-friendly. They did not give my colleagues' opinion the weight it deserved, they keep developing everything for the WLAN module that SW team did not want. At the end the integration of that module was the most complicated and expensive of all modules for that hardware variant.

This kind of wrong decisions happen more often when non-technical people in management decided for something without hearing well (or understood) the technical teams, but as I show you in that story, it also happens when very technical people focus only in what it works for their team. That's also why I think the Product Owner (PO) must have technical background, but that's a story from another time.

My opinion in the knowledge gap may not be that far from a general perspective, because a similar explanation is in the website of my master in the Technische Univeristät Darmstadt, Germany where I defended my Master Thesis Implementation of a Configurable HW Cache for Embedded Accelerators on 2023. I focus my master degree on embedded and FPGA development.

Since then, I have been working on Embedded Development in my free time and also at work. In this small place of the Internet, you will find things that I found interesting about coding for embedded systems, personal opinions in topics regarding embedded development and also tutorials about things that were not easy to find while working (and debugging) on devices.

So thank you for reading me and I hope you are there for the next to come. Cheers! 🥂