Keine Rechte auf libs

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
Benutzeravatar
elektrofuzzis
Beiträge: 111
Registriert: 25 Jun 2016, 09:40

Keine Rechte auf libs

Beitrag von elektrofuzzis » 23 Dez 2019, 22:50

Hallo,

so-libraies sollen in /opt/knobloch/libs installiert werden. Der Upload geht theoretisch am einfachsten mit dem im TXT integrierten WEB Server.

Leider nur in der Theorie. In der FW 4.6.6 läuft der Upload intern als User ROBOPro. Dieser hat auf /opt/knobloch/libs allerdings keine Schreibrechte.

Ist das nur bei mir so? Mache ich etwas falsch? Bug?

chmod auf das Verzeichnis als root oder filezilla auch als root lösen das Thema auch, aber ist das so gedacht?

Gruss

Stefan

vleeuwen
Beiträge: 1141
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)

Re: Keine Rechte auf libs

Beitrag von vleeuwen » 24 Dez 2019, 11:38

[Attachment = 0] ft-Libs.JPG [/ attachment]
Only intended for SLI libraries and works great.
I just tried it out with firmware 4.7.0. and also under 4.6.6 (Sinsheim 2019).
Working under ROBOPro account, uploading can also be done with FileZilla, also under ROBOPro.
This folder is not part of the search path for shared libraries.
My guess is that the charger for the SLI units uses the dynamic loading mechanism with this folder as the search path.

=====translations with Google translate,, for what it is ====================================================
Is alleen voor SLI-bibliotheken bedoeld en werkt prima.
Ik heb het net voor je uitgeprobeerd met firmware 4.7.0.
Werken onder ROBOPro-account, kan ook worden gedaan met FileZilla, ook onder ROBOPro.
Deze kaart maakt geen deel uit van het zoekpad voor gedeelde bibliotheken.
Mijn gok is dat de lader voor de SLI-eenheden het dynamische laadmechanisme gebruikt met als zoekpad deze map.

Destiné uniquement aux bibliothèques SLI et fonctionne très bien.
Je viens de l'essayer avec le firmware 4.7.0.
En travaillant sous le compte ROBOPro, le téléchargement peut également se faire avec FileZilla, également sous ROBOPro.
Ce dossier ne fait pas partie du chemin de recherche des bibliothèques partagées.
Je suppose que le chargeur pour les unités SLI utilise le mécanisme de chargement dynamique avec ce dossier comme chemin de recherche.

Nur für SLI-Bibliotheken gedacht und funktioniert hervorragend.
Ich habe es gerade mit Firmware 4.7.0 ausprobiert.
Das Hochladen unter ROBOPro kann auch mit FileZilla, ebenfalls unter ROBOPro, erfolgen.
Dieser Ordner ist nicht Teil des Suchpfads für gemeinsam genutzte Bibliotheken.
Ich vermute, dass das Ladegerät für die SLI-Einheiten den dynamischen Lademechanismus mit diesem Ordner als Suchpfad verwendet.
Dateianhänge
ft-Libs.JPG
ft-Libs.JPG (47.53 KiB) 466 mal betrachtet

Benutzeravatar
elektrofuzzis
Beiträge: 111
Registriert: 25 Jun 2016, 09:40

Re: Keine Rechte auf libs

Beitrag von elektrofuzzis » 28 Dez 2019, 08:15

Danke fürs Testen! Die so-lib für den ftPwrDrive ist jetzt online.

Thx for testing! Our so-lib for the ftPwrDrive is online, now.

vleeuwen
Beiträge: 1141
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)

Re: Keine Rechte auf libs

Beitrag von vleeuwen » 28 Dez 2019, 13:46

The TXT SLI library documentation for the ftPwrDrive was not so easy to find.
It can be found here, and the code here.
The SLI mechanisme is a TXT extension for ROBOPro, it isn't part of ROBOPro itself.
The SLI libs are not normal C/C++ shared lib and can not be used directly in the download C programs, you will need to load a SLI dynamically or place it a shared library search path.
SLI's need to be placed in "/opt/Knobloch/libs", in the header file is mention "/opt/Knobloch"


I foresee some problems when the function are used at the same moment in different processes.
A SlI is not re-entrance.
The SLI is loaded 1 time and the 4 variable
uint8_t buffer[MAXBUFFER];
uint8_t bufferPtr = -1;
uint16_t i2cAddress = 0x20;
uint16_t i2cSpeed = I2C_SPEED_400_KHZ;
are global. When there is an overlap in the execution of two or more ROBO-processes, the chance exist that the address and buffer used during the execution of I2C transfer is not the right one. At least the use of "lock interface" in the ROBOPro elements will be needed.
But in for example the ROBOPro subroutine setRelDistance the use of "lock interface" is not possible.


Coding for SLI's different a little bit from normal C/C++ coding
It is advisable to keep the device address, and the data local in the functions and avoid the use of too many global variable.
If a function is programmed well, it could be re-entrance.
The nice thing is that the SLI makes it possible to hide a lot of low-level stuff for the end-user.
For example: I2C device initialisation, functional parts. With SLI functions you can avoid complex ROBOPro program constructions.
The Bosch BNO055 driver (I2C chip) shows a nice base for a SLI.
The libftI2C.cpp is only a very simple and general I2C-bus driver but the I2C functions are already available as ROBOPro-elements.

Benutzeravatar
elektrofuzzis
Beiträge: 111
Registriert: 25 Jun 2016, 09:40

Re: Keine Rechte auf libs

Beitrag von elektrofuzzis » 28 Dez 2019, 15:51

Hi,

the idea of the lib was to send long values via i2c. Longs are not supported in ROBOPro at all, so we use floats in ROBOPro.

A float could not be send via i2c, so we needed a typecast from float to long. Since the ROBOPro commands for so-libs are very restricted, we used the solution with a global buffer.

We don't have a good idea to handle this more smoothly.

Any fully reenteant solution is welcome.

By the way: we use the buffer just for a very short time, just 3-4 ROBOPro commands. So the risk of buffer confusion is very limited.

Best,

Stefan

vleeuwen
Beiträge: 1141
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)

Re: Keine Rechte auf libs

Beitrag von vleeuwen » 28 Dez 2019, 18:28

ex1.JPG
ex1.JPG (43.97 KiB) 290 mal betrachtet
At least the "lock interface" could be used. (on the red SLI elements)
This is an example of a dedicate read operation on a very complex I2C device.
This is dedicate read action on a I2C device.
The Read function (blue) split up an long int into several short.

The I2C address, I2C read operations and calculations has been hide in a function in the underlying C++ class.
The "lock interface" in the first three ROBOpro SLI elements bind this operation to one.

However ROBOPro can only work with integers and float (RoboPro format).
Long values inside RoboPro make no sense because they can not be used in calculations.
You probably need to choose between lost of precision or lost of range.
The range +32767..-32767 could be converted at C/C++ level into 65534..0

Benutzeravatar
elektrofuzzis
Beiträge: 111
Registriert: 25 Jun 2016, 09:40

Re: Keine Rechte auf libs

Beitrag von elektrofuzzis » 28 Dez 2019, 20:27

Hi,

we will change this the next days.

Thanks for your advise about "lock interface" and reenteant coding.

Best Stefan

----------------------

Und jetzt noch die Zusammenfassung der Diskussion auf Deutsch:

Eine .so-Library wird nur einmal initanziert. Das bedeutet, dass globale Variablen auch nur einmal existieren.

Erzeugt man in ROBOPro mehrere Threads - mehrere grüne Ampelmännchen - und ruft in den Threads die so-Lib auf, so können sich die Threads gegenseitig in die globalen Variablen schreiben und Unsinn erzeugen.

Also sollte man den C Code möglichst ohne globale Variablen schreiben. Das war schon immer richtig, nur kann man mit den C-Kommandos in ROBOPro nur einen Parameter übergeben. Damit lässt sich von ROBOPro aus kein Kontext (1. Thread, 2.Thread) mitgeben.

Will man sicherstellen, dass mehrere ROBOPro Kommandos direkt hintereinander ausgeführt werden und nicht durch einen zweiten Thread unterbrochen werden können, so muss an den C-Kommandos die Check Box "Lock Interface" gesetzt werden. Das erste Kommando mit Lock startet dies, mit dem ersten Kommando ohne Lock hebt das wieder auf.

Solange man das nur für wenige ROBOPro Kommandos macht, merkt man den Lock nicht. Mit vielen Kommandos / langer Ausführungszeit wird es d**f, weil der zweite Thread wartet.

Gruss

Stefan

Antworten