Thanks for the awesome answers here Phillip, and I especially appreciate the tip about CLion vs VSC -- I will definitely trial both IDEs now and see which one is working best for me.
Happy trails, Zac On Tue, Nov 24, 2020, at 3:36 PM, Philipp Blum wrote: > > > 1. Can I develop RIOT-based C applications using my existing > > CLion/GCC/CMake/Mac "stack"? Or does RIOT have its own IDE that I > > should be using on Mac? Is my "stack" a typical dev setup or does it > > send up any red flags in anyone's mind? > > > You can use it with you CLion/GCC/CMake stack. I just did exactly that > until some weeks ago. Unfortantly my CLion subscription expired and I > had to switch to visual studio code ^^ > Even though I really like CLion, the RIOT OS extension > (https://marketplace.visualstudio.com/items?itemName=attdona.riot) for > Visual Studio Code helps in development. It generates the necessary > C/C++ Plugin configuration, so that autocomplete works out of the box. > The configuration in CLion is a bit more complext though. You have to do > this all by hand. I never did that and just looked into the API doc. > > > > 2. My understanding is that my compiler/linker will compile RIOT and my > > app TOGETHER into the same executable that can be deployed to my MCU -- > > is this true? What are typical hobbyist deployment pipelines/pathways > > to get the final executable deployed/installed to the target MCU? > > Yep, this is the normal process for firmware development. I mean you > maybe could implement dynamic linking on Microcontroller, but the > overhead is probably not resonable. It just doesn't make sense, if you > work directly on the metal. But just take a look into the bin directory > after compiling your source code. You will see that there are a lot of > different binaries in there. So, you are also able to ship your > application as binary. The LGPLv2.1 license allows you to do that. So, > you can ship your app logic as binary, while the RIOT OS core has to be > open under LGPLv2.1 license. > > My hobbyist development pipeline: I barely think about a pipeline. Even > though I write tests. I just have my MCUs here, write some apps, compile > them and flash them. There is no big pipeline involved, since I only > need one, maybe two devices with the application. For commercial > applications this looks probably different and you can make use of the > CD/CI pipeline of RIOT OS itself. Just take a look into the Github > repos. > The tools are quite advanced. Sometimes not well documented, but an > amazing set of tools. > > > > 3. How are RIOT apps typically tested? Do I just have to deploy it to > > the MCU and take the whole system up for a test spin, or are there ways > > of simulating/virtualizing the test phase? > > For the kernel: Write some tests in the test directory. Flash them and > check the results. You can, of course, automate this as well. As I > mentioned, there are a couple of tools for that. But for the start, I > would say just executing them manually is good enough. For your own > application: Just take a look into tests and copy the way of doing it to > your own application. You are free in what structure you want to use. A > bit Makefile magic makes it happen. > (https://github.com/RIOT-OS/Tutorials/blob/master/task-01/Makefile) > > > > 4. In your introductory examples (wiki) I see vagrant being used. Is > > this just to simplify the compilation of the source code, or is > > vagrant/Docker a typical part of the RIOT developer's dev/test flow? > > The toolchain for Linux is very simple to install and to use. Windows > with WSLv2 also works very well, since it give you a Linux kernel. MacOS > on the other hand can make trouble in my experience. Vagrant gives you a > simple starting point without worrying too much about the whole > toolchain situation. Of course, if you want to, you can use your own > toolchain. > _______________________________________________ users mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/users
