teichsta Posted February 18, 2013 at 11:49 AM Share Posted February 18, 2013 at 11:49 AM 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. Quote Link to comment Share on other sites More sharing options...
batti Posted February 18, 2013 at 12:01 PM Share Posted February 18, 2013 at 12:01 PM 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 Quote Link to comment Share on other sites More sharing options...
AuronX Posted February 18, 2013 at 07:33 PM Share Posted February 18, 2013 at 07:33 PM Man kann ja die CallbackPeriod von irgendwas als Semaphore nutzen 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). Quote Link to comment Share on other sites More sharing options...
teichsta Posted February 18, 2013 at 07:38 PM Author Share Posted February 18, 2013 at 07:38 PM 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. Quote Link to comment Share on other sites More sharing options...
AuronX Posted February 18, 2013 at 07:44 PM Share Posted February 18, 2013 at 07:44 PM 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?) Quote Link to comment Share on other sites More sharing options...
teichsta Posted February 18, 2013 at 07:55 PM Author Share Posted February 18, 2013 at 07:55 PM 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. Quote Link to comment Share on other sites More sharing options...
AuronX Posted February 18, 2013 at 08:02 PM Share Posted February 18, 2013 at 08:02 PM Will sagen man könnte den Stack per USB anschließen und hoffen, dass es sich per WLAN gleich verhalten würde. Was ihr damit natürlich nicht aufdeckt sind Fehler im TF-Protokoll, aber das ist auch nciht die Aufgabe von Unit-Tests. Quote Link to comment Share on other sites More sharing options...
teichsta Posted February 19, 2013 at 09:04 AM Author Share Posted February 19, 2013 at 09:04 AM 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. Quote Link to comment Share on other sites More sharing options...
borg Posted February 19, 2013 at 10:05 AM Share Posted February 19, 2013 at 10:05 AM 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.