Written by Mohammed Billoo, Embedded Linux Consultant, MAB Labs Embedded Solutions
This blog originally ran on the MAB Labs website. Click here for more content like this.
Recently, MAB Labs has been developing an IoT/Edge device based on the CircuitDojo’s nRF9160 Feather platform. The nRF9160 Feather has a feature-set that makes it appealing to use as the platform for initial prototyping and development. First, it has hardware support for GPS and connection to cellular networks designed for Edge devices; these two features alone are critical for the final product. Second, the inherent form factor of this platform is appealing and any hardware/mechanical changes in the future will be minimal. Finally, and most importantly, the documentation and support provided by Jared Wolff and his team at Circuit Dojo is extraordinary. In this blog post series, we will be documenting some of our experiences in developing our firmware, in hopes that some of the challenges that we faced could help others.
Remote Embedded System Development
MAB Labs’ development environment was not unique in today’s age, where remote work has become the norm, but is challenging when working on an embedded system based product. As is the case with most teams nowadays, we have team members that work remotely. We needed to devise a solution that would streamline their development workflow. We accomplished this by setting up an Ubuntu machine for remote team members, connecting the nRF9160 Feather to the machine, and using a service called remote.it (https://remote.it/) to allow him to VNC into the machine. Of course, we also used Slack for communication, since initially some hard resets were required on the platform to get comfortable with the development process.
Zephyr RTOS with Visual Studio Code
Our plan was to use Visual Studio Code as the IDE for firmware development. Circuit Dojo’s Github page provides excellent instructions on how to get started with their extension. However, when we got to the step to setup the Zephyr toolchain and environment, we ran into the following issue:
Originally, we thought that the tarball being referenced by the command didn’t exist or its permissions weren’t appropriately set. However, we confirmed that the tarball did exist and its permissions were correctly configured. Ultimately, we thought that there may have been an issue with the SDK itself and attempted to rectify the issue by trying an earlier version. This ended up resolving the above issue and we were able to continue development. When we reached out to the community, Circuit Dojo’s own Jared Wolff acknowledged the issue that we observed, and pushed up a fix in the newest version of the SDK. Specifically, we originally tried version 0.1.19 where we discovered this issue and had to go back to version 0.1.16 as a temporary workaround. Ultimately, the fix has been applied to version 0.1.20 of the SDK.
Summary
In this blog post, we discussed some of the challenges and corresponding solutions with remote embedded system development. Additionally, we outlined a specific issue we faced when getting started with Zephyr RTOS on an nRF Feather and developing with Visual Studio.
If you have any questions or comments, please reach out to the Zephyr community on the Zephyr Discord Channel.
