Jump to content

[Java] Exklusiver Zugriff auf Tinkerforge


Recommended Posts

Hallo Zusammen,

 

wir nutzen die Tinkerforge Module zur Testautomatisierung. Dafür müssen wir beim Ablauf der Tests sicherstellen, dass immer nur ein Test gleichzeitig auf den Tinkerforge Stack zugreift.

 

Aktuell lösen wir das darüber, dass wir einen Port eines Relay-Bricklet so lange einschalten wie der Stack besetzt ist und ihn am Ende wieder ausschalten. Nicht schön (und vor allem auch nicht Ressourcen-schonend), aber es geht.

 

Habt ihr vielleicht noch bessere Ideen?

 

Wir greifen von unterschiedlichen VMs auf den gleichen Stack zu. Das halten einer statischen Variable ist also keine Option. Überhaupt würde wir ungern auf "Clientseite" einen Status einführen, sondern lieber irgendein magischen Register auf dem TF stack setzen :-).

 

Wäre für jeden Hinweis dankbar,

 

Thomas E.-E.

 

Link to comment
Share on other sites

Hallo Thomas,

 

anstatt wirklich einen mechanischen Schalter zu betätigen könntet ihr einen anderen "setter" nutzen. Musst mal durch die API gehen ob sich da nicht irgendetwas anderes finden lässt.

 

Problematisch könnte aber allgemein dabei sein, dass das nicht wirklich sicher ist. Nachdem du den Status abgerufen hast kann ein anderer ihn schon wieder gesetzt haben.

 

Grüße

Link to comment
Share on other sites

Man kann ja die CallbackPeriod von irgendwas als Semaphore nutzen :D

 

Aber wie schon von Batti gesagt: Das ist nicht sonderlich Thread-safe.

 

Wie wäre es wenn ihr euren eigenen Brickd schreibt (bzw. den originalen modifiziert).

 

Einfache Variante: Nur eine offene Verbindung, danach keine weitere akzeptieren.

 

Fortgeschritten: der Brickd reagiert auf einer virtuellen UID auf einen Test-And-Set Funktionsruf (dadurch sind echte Semaphoren/Mutexe möglich).

Link to comment
Share on other sites

Hi,

 

Wie wäre es wenn ihr euren eigenen Brickd schreibt (bzw. den originalen modifiziert)

 

das klingt gut, jedoch nutzen wir nicht den brickd sondern erreichen den TF stack über die WiFi Extension. Das würde bedeuten: Firmware schreiben, oder?! Damit wären wir dann aber ganz schön Lowlevel unterwegs ... jedenfalls mehr, als mir das eigentlich lieb wäre ;-).

 

Gruß,

 

Thomas E.-E.

 

Link to comment
Share on other sites

Hmmm... könnte im Rahmen der Unit-Tests egal sein, dass es WiFi ist... (außer organisatorisch).

 

Von eigener Firmware zu diesem Zweck würde ich abraten, das wäre overkill.

 

Ideal wäre es für Unit-Tests eigentlich, wenn jedes Device ein zugehöriges Interface hätte. Dann könnte man die Devices ganz einfach mocken und ihr wärt nicht auf echte Hardware angewiesen. (Wie wollt ihr testen, ob Methode x mit einer TimeoutException klarkommt?)

Link to comment
Share on other sites

Hmmm... könnte im Rahmen der Unit-Tests egal sein, dass es WiFi ist... (außer organisatorisch).

 

hmm, verstehe ich noch nicht so ganz. Im WiFi-Fall nutzen wir doch gar keinen "externen" brickd, können also auch einen Einfluss auf das Connection-Handling nehmen, oder?

 

Ideal wäre es für Unit-Tests eigentlich, wenn jedes Device ein zugehöriges Interface hätte. Dann könnte man die Devices ganz einfach mocken und ihr wärt nicht auf echte Hardware angewiesen. (Wie wollt ihr testen, ob Methode x mit einer TimeoutException klarkommt?)

 

da gebe ich Dir recht ... wäre nett :-)

 

Im Moment lösen wir das organisatorisch. Und zwar so, dass die Tests, denen sicher ein TF stack zur Verfügung steht eine entsprechende Annotation erhalten.

Link to comment
Share on other sites

Ich glaube meine Erklärung zum Einsatz von TF war bisher noch sehr lückenhaft und wir sprechen daher aneinander vorbei.

 

Wir wollen mit den Unit-Tests nicht den TF Stack testen, sonder TF als einen Testtreiber benutzen, um manuelle Interaktion mit externer Hardware zu simulieren und diese im Rahmen von Integrationstests bereitzustellen.

 

Weil wir im Rahmen der Unit-Tests auf die gleiche Hardware von unterschiedlichen VMs zugreifen, brauchen wir eben den exklusiven Zugriff auf den TF stack.

Link to comment
Share on other sites

Am einfachsten ist es wahrscheinlich wenn ihr eine weitere VM aufsetzt die einen Mutex implementiert (einfach über Sockets oder so).

 

Das über einen Setter/Getter bei uns im System zu machen ist definitiv nicht sicher. Es könnte ja folgende Abrufreihenfolge passieren

 

VM A: Get -> Ergebnis: Unlocked

VM B: Get -> Ergebnis: Unlocked

VM A: Set -> Lock

VM B: Set -> Lock (kein Fehler)

 

Um schon greifen beide VMs gleichzeitig drauf zu.

 

D.h. ihr braucht eine TryLock Funktionalität, die einen Fehler zurückgibt wenn das Lock schon gesetzt ist.

 

Es ist möglich das auf dem Master Brick zu implementieren, es gibt aber aktuell keinen Setter oder Getter bei uns im System der sowas leisten könnte.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...