Migration
Last updated
Last updated
Custom signals are now integrated into plug-ins since Skydel version 24.12. This step-by-step guide will help you migrate your legacy custom signal code to the plug-in SDK.
Before you begin, ensure you have completed the following:
You have a copy of the legacy skydel-custom-signal GitHub repository.
You have installed the development environment. If not, please refer to Development Environment.
You have checked out and compiled the latest version of the skydel-example-plugins GitHub repository. If not, please refer to Compilation.
The interfaces required for custom signals remain largely the same but are now integrated into the plug-in SDK. In this guide, we'll use the custom signal GPS CA as an example. The steps outlined here are applicable to any custom signal. The GPS CA example is located in example_gps_ca of the legacy project, and source / custom_signals / example_gps_ca in the new project. A few differences can be observed if we compare both project, here are the outlines.
Here is a compressed archive containing the code before and after the migration. You can use a "diff " tool like WinMerge to better visualize the differences between the legacy and the new approach.
Changes were required in the CMake configuration file to compile a custom signal example as a plug-in.
Root Element - The mandatory root element CustomSignals
has been added to the XML file format, enabling a single XML file to define multiple custom signals.
Mandatory Fields - The CustomSignal
element now includes the mandatory field Name
, which corresponds to the legacy custom signal name from the Skydel command used to add a custom signal.
Removed Field - The DLLPath
element is no longer required, as custom signals are now imported as plug-ins in Skydel.
File Naming - For Skydel to properly detect the custom signal plug-in, the XML file must have the same name as the PLUGIN_IID
name specified in the CMakeLists.txt file.
The changes to the custom signal implementation are primarily naming-related. The following interfaces and structures have been renamed:
ICustomSignal
→ SkydelCustomSignalInterface
ICustomSignalCode
→ SkydelCustomSignalCode
ICustomSignalNavMsg
→ SkydelCustomSignalNavMsg
CSInitData
→ Sdx::CS::InitData
The macro DEFINE_CUSTOM_SIGNAL
is no longer required. Plug-in registration is now handled directly in the custom_ca_plugin.h file using the macro REGISTER_SKYDEL_PLUGIN
.
This new file contains the boilerplate code required for a library to function as a Skydel plug-in.
Main Class - The main plug-in class must inherit from SkydelCustomSignalFactoryInterface
.
Key Function - Implement the createCustomSignal
function to return the custom signal implementation.
Data Sharing - Skydel shares InitData
with the custom signal plug-in, allowing it to initialize it's custom signal implementation.
Return Type - The returned object is of type SkydelCustomSignalInterface
, equivalent to ICustomSignal
in the legacy implementation.
Here is the custom_ca_plugin.h file annotated with comments to clarify its content.
Only the constructor is implemented in the source file to ensure that the source code is properly detected by CMake and successfully compiled.
Every Skydel plug-in requires a metadata file to specify its generic name, description, and version. Refer to any plug-in example for more details.
To use your newly compiled custom signal, ensure you move the dynamic library, downlink file, and XML file to the Skydel-SDX / Plug-ins folder. If you are compiling directly from the example project, you can run the cmake --install .
command from the build folder.
In Skydel, navigate to Help / Plug-ins..., and enable the custom signal plug-in you are interested in. Once enabled, you will have access to the custom signals defined in the XML file in Skydel, just like before.
The key difference is that your custom signal’s availability will now be persistent, unlike previously, where it was bound to the active configuration file.
Here are a few key points to ensure a successful migration to the Skydel plug-in SDK:
Interface Changes - No functional changes were made to the custom signal interfaces, only the names have changed.
Boilerplate Plug-in Class - Implement the base plug-in class to ensure your library is recognized as a Skydel plug-in.
XML File Name - The XML file name must match the custom signal PLUGIN_IID
name defined in CMakeLists.txt.
XML File Format Changes - Assign a unique name to each custom signal in the XML file to avoid conflicts and ensure proper functionality.
File Placement - For custom signals to be properly imported into Skydel, ensure the following files are placed in the Skydel-SDX / Plug-ins directory: dynamic library, downlink file and XML file.