Hello @tsandrini ,

first of all, we appreciate your effort which confirms us the open-source approach is the best way :-).

To your question:

Yes, you have to apply the appropriate overlay(s) to the "base" device-tree in order to tell the unipi kernel modules what kind of hardware (I/O boards) is present. Every model of the PLC (e.g. S103, L523, ...) has a separate overlay located in the package unipi-os-configurator-data. In a standard OS Image, this stuff is invoked automatically by unipi-os-configurator based on the identification stored in the internal EEPROM (and accessible via unipi-id module - see /run/unipi-plc/unipi-id, this module should be preset on all our units). Typically, this process needs two reboots - after the first of them only unipi-id is loaded in order to get the PLC model and apply the right overlay. After the next reboot, the previously selected overlay is loaded and all of the peripherals (inc. /dev/unipichannel*) should be available.

Anwer is in the previous text - appropriate driver(s) for Unipi-specific hardware are loaded automatically based on the devicetree (devicetree overlay) nodes.

Yes, the /dev/unipichannel* represents the main communication channel between the Linux and I/O boards (the second one is sysfs). This kind of device is created dynamically by the Unipi kernel modules based on values given in devicetree overlays. It is used by unipitcp as well as by the firmware upgrade tool.

Has this answer got you forward?

@HarishKumar
The evok itself is not designed to handle the logic of your application. That's why we call it API.

It is using Tornado which means the server itself runs in one loop so you need to have all the program behavior ready before it is called mainLoop.start(). So if you run an infinite loop anywhere in evok, you stop everything else (reading, setting, all APIs, ...).

So I suggest using that APIs, it is much more easier to implement and you have the same functionality. But if you would REALLY want to do it in evok, you would have to prepare your program in a function, all tasks that would take more time would have to be decorated as coroutines and the call has to be yielded in order not to stop the main loop. The logic behind this is a little bit complicated to describe in one post :)

@HarishKumar It's ok. That's why the forum is here. If you visit the web interface of evok, you will see the numbers of IO of the Neuron you are using.

In general it is numbered as X_Y where X is the number of group (1-3 depending on S/M/L model) and Y is the number of the Di/Ro/...

So for example you would address DI1.4 as a string 1_4 with device type di.