Initialisieren des Ports + Aushandeln der COM-Rate

[maehne]

Original issue #2 created on 2019-12-04 by @MarkusGafner:

• In der Variable INIT_WURQ_TIMEOUT in MAX14819.h ist die Wartezeit zwischen Power-On und WURQ eingestellt. Nach Standard müssen dies 300 ms sein
• Laut Standard müsste der Master außerdem mehrere WURQS schicken (es gibt einen „Scan for Sensor“ Zustand) Zugehöriger Testcase, nach Abschluss des Master-Stacks ist: SDCI_TC_0161.

[maehne]

@MarkusGafner commented on 2020-12-04:

• Hier stimme ich mehr oder weniger überein. Der WURQ kommt nach dem Einschalten der Speisung zu früh. Bei mir wird eine Zeit von 100 ms abgewartet, die Spezifikation besagt maximal 300 ms für einen Sensor (Stichwort Power-on timing). Es ist jedoch nicht die Konstante INIT_WURQ_TIMEOUT, sondern INIT_BOOTUP_DELAY, welche diese Zeit korrekt einstellt. Ich werde diese im Commit 5e9563d8 von 100 auf 300 erhöhen. INIT_WURQ_TIMEOUT definiert die Zeit, wie lange gewartet werden soll, ehe der zweite Verbindungsversuch gestartet werden soll. Laut der Spezifikation beträgt diese Zeit 30 ms bis 50 ms, ist also mit 80 ms eigentlich bereits zu gross (Spezifikation: "Wake-up procedure and retry characteristics"). Hat sich nur der Name der Konstante vertauscht, oder müsste das Delay grösser sein?
• Das der Master mehrmals versuchen sollte eine Kommunikation zum Sensor aufzubauen ist uns bewusst. Es sollte ja auch der Fall behandelt werden, dass ein Sensor ausgesteckt und wieder eingesteckt wird. Aktuell ist es so, dass auf jedem Port ein Wake-Up gesendet wird, und anschliessend Daten mit dem Sensor ausgetauscht werden. Dies unabhängig davon, ob ein Sensor antwortet. Nun stellt sich natürlich noch eine ganz andere Frage. Um dies zu realisieren müsste wohl ein Multithreading implementiert werden. Auf dem Arduino ist es aber schon schwierig einen Timer zu erstellen, da dieser durch die API gekapselt wird. Folglich stellt sich die Frage: Muss die Software nun aus dem produktiven Betrieb gehen, alle Ports prüfen und gegebenenfalls neu initialisieren? Es wurde aufgrund des Aufwandes darauf verzichtet. Denkbar wäre aber, dass solange ein Wake-Up durchgeführt wird, bis sich ein Sensor meldet. Dies bedeutet aber auch, dass wenn ein Sensor nicht reagiert das System nie in den produktiven Modus wechselt.

[gammeter]

Task @gammeter

• ask if the issues described above persist
• verify compliance of code to the standard (and change it if neccessary)
• check if the issues described above are solved.