Verständnisfrage zu getWifiBufferInfo()

[remotecontrol]

Hallo zusammen,

 

ich habe mal refreshWifiStatus() und getWifiBufferInfo() aufgerufen und war überrascht, dass die lowWatermark nach einem Connect und getStackVoltage() noch bei 1500 steht und nach einigen Servo und Status-Befehlen bei 1493. Nur wenn ich sehr viel IO erzeuge geht es mal auf 1450 zurück.

 

Werden die Commands inzwischen so schnell aus dem Puffer geholt oder interpretiere ich die Zahl falsch: 1500 würde ja bedeuten, dass nie wirklich was im Puffer steht. 1493 sind mal gerade 7 Bytes und die meisten Befehle nutzen 8 oder mehr Bytes.

[borg]

Um den internen WIFI Buffer zu füllen, musst du viele Callbacks aktivieren (damit der Sendebuffer immer voll ist) und gleichzeitig viele Setter oder Getter aufrufen (damit es passieren kann, dass der Empfangsbuffer voll ist während ich etwas senden möchte).

 

Die Kommunikation von dem WIFI Modul ist so gebaut, dass ich immer gleichzeitig Daten empfange wenn ich welche sende. Dadurch kann es sein, dass ich Daten bekomme während mein Eingangsbuffer voll ist (weil ich gerade einen Callback sende). Dazu brauche ich den zusätzlichen Buffer wofür du dir die

lowWatermark

holen kannst.

 

Eigentlich hat das WIFI Modul selbst intern genug Buffer. Wenn die das Kommunikationsprotokoll ein wenig cleverer gebaut hätten, hätte ich den zusätzlichen Buffer gar nicht gebraucht...

[remotecontrol]

Den Satz verstehe ich nicht so recht:

Die Kommunikation von dem WIFI Modul ist so gebaut, dass ich immer gleichzeitig Daten empfange wenn ich welche sende

Der Master bekommt Daten vom WIFI Modul, wenn der Master welche rausschickt? Das hat nichts zu tun mit API-Befehlen ohne Response - oder? Da wird ja nichts mehr zurück geschickt, dachte ich zumindest.

[borg]

Das hat nichts mit API Anfragen und Antworten zu tun. Wir kommunizieren mit dem WIFI Modul über SPI und bei SPI ist es so, dass bei jeder Flanke auf der Clock ein Bit von Slave zum Master und ein Bit vom Master zum Slave übertragen wird. Dadurch kann es passieren, dass ich Daten empfange während ich Daten sende. Dadurch brauchen wir den zusätzlichen Buffer. Ist ein reines Implementierungsdetail.