Later this must be generic so other apps
can use the same script

This could be overrided to the desired BPM instance

Later this must be generic so other apps
can use the same script

Later this must be generic so other apps
can use the same script

Now, when adding a new application (e.g., Photon BPM)
we just need to add a new folder inside src/apps and
adjust the src/apps/<app_name>/<app_name>.mk Makefile

Now, almost all (with the exception of the dev_io.c which
will be fixed soon) specific code to a board is
located inside include/board/<board_name> and
src/board/<board_name>

Hotfix: building with clang
Hotfix: unused variable on some compilation options

Version v0.2.1

Clang does not understand the -T option.

As this is used only by the linker, use
-Wl option to pass options directly to the
linker in use.

The client_cfg variable was unused in some cases
(e.g., not AFCv3 board or not with DEVIO_CFG).
This caused an error on compilation for legacy
boards.

Version v0.2

We need to wait a little after creating DEVIO
CFG. Without that, malamute does not seem to
transmit the liblcient messages after the DEVIO
CFg is created. To be investigated, but this
simple fix works.

RFFE DEVIO already has the correct slot number
from the regular DEVIO. As such, it does not need
to spawn a libclient instance to get ther board
number from DEVIO CFG.

This simplifies the creataion/destruction of DEVIO
CFG, as we don`t need to wait for anything to destroy
it. The regular DEVIO just kills it after getting the
board number.

This fixes #94 github issue.

As a safety measure, it`s good to use a different
DEVIO CFG name, as the same service could be spawned
by the regular DEVIO, creating 2 workers for the same
task. This is bad for MAILBOX clients as there can only
be one client per name . This is not an inssue with
Malamute STREAM or QUEUES.

This function is useful to omit false positives
when detecting non consecutives samples, such
as the wraparound from 32767 to -32768, which
are consecutive samples to the binary point of view.

Not sure why, but anything less than that
causes segmentation fault on accessing
the structure.

This should be related to alignment issues.

This is good to ensure correct boundaries
on 64-bit systems.

We were using the linker table label
as a pointer, which was wrong. The
correct type for it is just an address
on which can be dereferenced later.

A clear way to do that is to just
declare it as the type on which you
wish to deference later.

This was supposed to be Malamute,
but it was CZMQ. Clearly a typo.

Now, we need to export our bootstrap structure
using the macro SMIO_MOD_DECLARE.

Instead of using a custom bogus object as the
EOF for the vector, we rely on the end references
declared in the linker.

Now, the correct name is _smio_mod_dispatach_table.

This will enable us to not use a static
global table like the one in sm_io_mod_dispatch.c.
We will be able to remove this file completely.

This is due to the following range of commits
on repo bpm-gw:

lnls-dig/bpm-gw@680f462966
..
lnls-dig/bpm-gw@719a91bc3a