Creating OOT Module in GR 4.0

Steps
The process to create a GR 4.0 custom block in an OOT is very simple:


 * Create the OOT
 * Create the Block
 * Edit the .yml file
 * Implement the constructor
 * Implement the  method

Creating the OOT
In place of modtool, there is a script in the  source tree that will perform the same function

python3 $GR_PREFIX/src/gnuradio/utils/modtool/create_mod.py myOOT

This will create a skeleton OOT with the following structure:

gr4-myOOT/ ├── blocklib │   └── myOOT │      ├── include │      │   └── gnuradio │      │       └── myOOT │      │           └── meson.build │      ├── lib │      │   └── meson.build │      ├── python │      │   └── myOOT │      │       └── __init__.py │       └── test │          └── meson.build ├── meson.build └── meson_options.txt

Creating a Block
To create a block, there is a helper scripts in the  source tree: cd gr4-myOOT python3 $GR_PREFIX/src/gnuradio/utils/modtool/create_block.py myblock

This will create the necessary files for compiling a block by placing a minimal set of files in the following structure:

├── blocklib │   └── myOOT │      ├── myblock │      │   ├── myblock_cpu.cc │       │   ├── myblock_cpu.h │       │   └── myblock.yml

All of the files needed to create the block are located in one place, and all of the normal boilerplate will be automatically generated.

From here let's start with the  file

Top level properties
The first section contains the top level properties. Module and block need to match the module/filename.

Label corresponds to how it would be displayed in GRC or other interface.

Blocktype currently can be,  , or   and corresponds to the type of block that will be implemented

Parameters
Next we declare the parameters in the block. These correspond to the constructor of the block, as well as setters and getters if desired. The example parameter that is given is for an itemsize parameter, which is by default set to 0 - this can be used to attach an untyped port to an arbitrarily typed port, in the case of e.g. a head or throttle block that doesn't really consider the type of the incoming/outgoing data

dtype
uses sigmf data type names, and should be from the set (listed as c++, python, and grc type)

id/label
This gives the parameter a name, which will show up in the constructor arguments as well as the  object instantiated to represent this parameter in the base block

settable/gettable
If the  is set   (default false), the parameter can be changed at runtime via an autogenerated callback method also enables a getter method - but settable=false/gettable=true will only provide the getter

default
The value set for default is a hard default in the constructor arguments. All parameters after this must also have a default set. Parameters with a default value are given keyword arguments in the python bindings

grc
The grc section is passed directly to the generated grc bindings as these pertain specifically to grc fields. These include: - category - hide - default (a soft default when a block is placed on the canvas)

Ports
The ports section includes both message and streaming ports, which can be of different types

domain
or

id
The unique (for this block) id for the port

direction
or

type
- This is a sized port where the block knows nothing about the type of the data being consumed. - The sigmf types described above. Field not used for message ports

size
For  ports, this fixes the size of the port so it is checked at flowgraph initialization. If set to 0, that check is bypassed and it is up to the block to infer the size of the data from the incoming buffer.

Implementations
The Implementations section allows multiple implementations for each block. is the default, which would then automatically generate the compile targets for.

If an implementation is python, this needs to be indicated as follows

Templated Blocks
As was commonly, but difficultly implemented in GR 3.x, templated blocks use c++ templating to allow selectable types, and this workflow removes much of the boilerplate code associated with this mechanism.

In the .yml file, a typekeys section is added that specifies a series of supported types for the block implementations. Multiple types can be implemented with different ids

For the above typekeys, blocks will be compiled as myblock_c, myblock_f, etc. corresponding to the suffix that maps to the type option

Implementation Files
The  and   are designed to get the developer as quickly to the   method as possible

The provided  file is very simple and only contains the constructor and work method and derives from an autogenerated base block (lives in the   directory)

Constructor
First, notice that the arguments to the constructor are contained in a  struct - this is to minimize the number of things that need to be changed when adding/removing/changing a parameter. This struct will contain in order and with provided defaults the parameters from the  file and be updated when that file changes.

Class Variables
Two things that are not necessary to implement - Setters/Getters - Local variables that correspond to block parameters

This is because the parameter mechanism handles this in a consistent fashion that we will explore later.

The  file implements the constructor (some boilerplate abstracted from the   macro and the work method