Porting Guide - Infineon/radar-bgt60 GitHub Wiki

Porting the library to a new software development framework and hardware platform entails the implementation of the corresponding GPIO and Timer PAL classes. In the following sections, some additional explanations and hints are provided:

Framework PAL Implementation

Implement the abstract PAL interface for your framework. The GPIO class and Timer class are mandatory.

The Doxygen comments on the "src/pal/gpio.hpp" and "src/pal/timer.hpp" describe the required behavior of each function of the PAL Interface.

Consider the existing framework implementations as reference examples for your design: "src/framework/sample_framework/pal". Some of the functions are optional depending on your framework and intended usage of the library.

That is the case of init() and deinit(), which take care of the hardware peripherals ini- and de-initialization. If this is done in your main application (or somewhere else outside the library), there is no need of delegating such initialization to the BGT60 library. The definition of the these functions can just be a return with the success return code.

Framework API Wrapper

The framework API wrapper implementation is optional, it is meant to ease the usage. Mostly the main help is to avoid the creation of the GPIO and Timer instances for the developer.

To illustrate this approach, it is easier to evaluate a concrete implementation of the Arduino wrapper. For example the constructor of the BGT60 class, which can be found in the files "src/framework/arduino/wrapper/bgt60-ino.hpp/cpp". More information can be found here.

Adapt the constructor arguments to those used for the platform class creation (GPIO, Timer) in the new framework, using the native data types and structures. Hide what can be already defined for that platform and provide as much abstraction and simplicity as possible.

For example, the core library of the base constructor is defined like this:
```
Bgt60(GPIO *tDet, GPIO *pDet);
```
is wrapped for Arduino like this:
```
Bgt60Ino(uint8_t targetDet, uint8_t phaseDet)
```
While it does not seem to simplify much in number of arguments, an Arduino developer can simply pass the pin number as argument and does not need to deal with the (probably unknown) GPIO classes, neither specify further GPIO configuration as the mode (input, output, pull-up, ...), positive/negative logic, ect.

As for the constructor, the same philosophy can be applied to other functions of the public API. In case of Arduino, as a hobbyist and makers environment, clarity and simplicity might prevail over configurability and functionality. Therefore, the wrapper API further hides, group or eliminate certain functionalities.

For each ecosystem and framework, any other criteria can be chosen, hopefully matching as well its code conventions, implementation principles and paradigms.

The following part does not apply to the BGT60 library as it is not used here but the framework concept allows such definitions. So this part is only here for completeness. Please refer to other Infineon framework libraries like the Hall Switch or the High-Side-Switch which are using this concept.

It is also recommended to create predefined standard pinout for different platforms. This will avoid wrong pin assignments on the user side and will reduce the amount of time the user needs to configure the library new for a different platform he wants to use.

In this library this is done with simple #ifdef and #elif statements which configure the two pins TD and PD depending on the chose platform:
```
#ifdef ARDUINO_SAMD_MKR1000

#define TD 16
#define PD 17

#elif defined(ARDUINO_SAMD_MKRWIFI1010)

#define TD 16
#define PD 17

#elif ...


#else
#warning "You did not define a supported platform! \
Please make sure you're using a platform that is officially \
supported by the library. Have a look in the Wiki for more information."
```
The user also gets a warning if a undefined platform is used.