Disclaimer: This tool was a one-night project, so, it is not foolproof and may be flawed in many ways, unknown ways. Also, I am really not aware of any (and all) shortcomings that
cppclean has. All of these also apply to this tool. Use it at your own discretion :)
I have really mixed feelings in regards to documentation.
I really enjoy documenting. I enjoy (to some extent) writing. I enjoy making diagrams…
TL,DR: AGL Rocks hard. Install VSCode and C/C++ extensions pack, grab a debug enabled AGL SDK, get a copy of a template project I brewed, follow instructions on the README.md: build, deploy, debug and profit.
Debugging capabilities is a crucial part of the development process. Most debugging in Linux systems happens using either gdb or lldb. In this article, I will introduce you to the process I use to remote debug an Embedded Linux application, using a few key tools:
The purpose of this article is to describe the process I use to cross-compile and deploy a simple program to a Raspberry Pi 4 target, under the umbrella of Automotive Grade Linux (AGL). You will get a step-by-step to generate a more development grade ecosystem, use it to cross-compile a sample application, deploy it to your Raspberry Pi 4 target running the image you will build, and run it directly from you target, through a
ssh remote shell.
Cross-compiling, on its own, is not a trivial task to new-comers, so, if anything doesn’t make sense to you, please, drop me…
The purpose of this post is to describe how I managed to build the Automotive Grade Linux demo application for a Raspberry Pi4 target. I will do so by introducing AGL, describing the issues found, and how I surpassed them.
TL, DR: AGL Rocks. Install docker, run a container, run your build and grab the resulting system image. If you are in doubt on how to do it, scroll down to the Building AGL for RPi4 using Docker section. If you have time, read through :)
Not long ago, I started studying Linux applications and projects targeting the automotive industry…