Beginer questions: Setting up the Linux development environment for the DragonBoard


#21

Hi Daniel,
I think it is clear now how to setup PATH, I think. If .bashrc is not present in $HOME I should create it and fill in the settings I need, right?

One other thing I missed to mention is that in my case this is an embedded application running a fix program that will communicate through ad-hoc ethernet channel with a remote client program, so, there is only one instance of the program running and only one remote client app monitoring and controlling this program.
For development and test I can start the program on the shell but later I need it to start as a service at boot time. Before I ask how to do it, I’ll try to figure it myself when the time comes.

Next trouble, over the weekend I tried to install libmraa to gain access to GPIO and UARTs, unfortunately
I ran into troubles with apt-get upgrade and apt-get dist-update. The net result after a very long list of downloads and install was a dead board, no HDMI, no Ethernet communication, no activity other the blinking LED as far as I can see. I had to reload the image a couple of times. I did only the updates and that let me load the mraa library. I’ve seen a few posts about this problem here. It seems that the current latest image is no longer good for production.

Question, it is clear that GPIO access needs to be customized, but why do I need to use libmraa to gain access to UARTs?, one would expect UARTs to be a device readily available from the OS.


#22

Good plan… but let me offer a hint. As your application becomes ready for production the first step is usually to package it (wrap the build system so it can be installed using apt/dpkg). Packaging allows the app to be installed in /usr/bin, /usr/lib, etc. whilst taking care of things like uninstall, upgrade, etc . To be honest, the dominance of the packaging model in GNU/Linux is what allows everything to be installed on the same directory and why changing the system-wide PATH is so rare.

There are several ways to workaround this but the recommended workaround for this (and the one that will be adopted automatically in the next release) is to run: sudo apt-mark hold linux-image-4.14.0-qcomlt-arm64 before doing an apt upgrade.

libmraa is very much a matter of personal taste. It can be good for people who are used to writing arduino-style code or want to power (some) RPi examples to the 96Boards family. However personally I would never use it (not even for GPIO access) and it is certainly not required for UART access.