Arduino mit Ethernetshield und Zusi TCP-Server, geht das?

[Stephan/Taschi]

Dafür gibt es aber eigentlich überhaupt keinen Grund. Z.b. ein Saintsmart Arduino Clone (100% kompatibel) kostet ungefähr die Hälfte von einem originalen Uno mit ein paar Portexpander-ICs... Siehe Screenshot von eBay im Anhang.

Es gibt dafür den Grund, dass ein Arduino Uno hier schon rumliegt und ich keine Lust habe, für meine Billigbasteleien (aus denen schon alleine aus Gründen mangelnder handwerklicher Fähigkeiten nie mehr als ein Breadbord-Prototy wird) ernsthaft noch nen zweiten Arduino zu kaufen.

[Bernhard]

Ich habe mich hier in der Vergangenheit mehrfach an Diskussionen beteiligt über die - ich sage das jetzt mal direkt - hirnamputierte Design-Entscheidung, 32-bit-Floats als Universaldatentyp zu verwenden und darüber, dass bei der Entscheidung zugunsten von TCP anstelle von UDP "ausgewachsenen" Systemen der Vorzug über Embedded-Anwendungen gegeben wurde.

Für hochintegrierte embedded systems sind dies zweifellos massive Einschränkungen. Ich würde Deinen zweiten Kritikpunkt noch verallgemeinern und behaupten, daß sich das Protokoll zu sehr am Paradigma einer synchronen Kommunikation orientiert und dadurch paradoxerweise bereits an Overengineering leidet. Wie soll bei immer relevanter werdender asynchroner Kommunikation mit ACK-Befehlen umgegangen werden, wenn keine Korrelation zu den ursprünglichen Befehlen stattfindet? Welchen Zweck hat der berühmt-berüchtigte "letzte Befehl" eines Clients an den Server? Wie soll eine Serverimplementierung sinnvollerweise darauf reagieren? Ist es wirklich notwendig, die "Daten-Anforderungs-Phase" zu beenden, sobald Zusi als Client verbunden ist (hier wird es zwangsläufig zu Änderungen kommen, wenn Zusi selbst die Rolle des Servers übernimmt)? Etwas unsauber ist außerdem die Nicht-Abgeschlossenheit des Protokolls bezüglich der Befehlscodes, da DATA im Gegensatz zu NEEDED_DATA kein abstrakter parametrisierter Befehl ist, sondern genau genommen nur Daten aus dem Befehlsvorrat "Führerstandsinstrumente" überträgt. Das ist zwar in der Praxis irrelevant, da es de facto keine weiteren Befehlsvorräte "in the wild" gibt, muß aber bei der korrekten Implementierung eines Servers als Spezialfall behandelt werden.

Der Vollständigkeit halber sei natürlich erwähnt, daß dies eine äußerst akademische Diskussion ist und ich das Protokoll nichtsdestotrotz für eine der wesentlichsten Weiterentwicklungen von Zusi in den letzten Jahren halte. Angesichts der von Carsten beschriebenen "Entstehungsgeschichte" ist einzusehen. daß es gewisse Design-Schwächen hat, mit denen wir uns aber größtenteils schon längst arrangiert haben. Für die ferne Zukunft würde ich mir ein entschlacktes Protokoll etwa auf Basis eines simplen publish-subscribe patterns wünschen (Beispiel. Die Implementierung eines umfassenden Standards wie XMPP wäre mit Sicherheit Overkill). Eventuell wäre auch ein anderes Payload-Format wie etwa JSON überlegenswert, das in aktuellen Programmiersprachen sehr gute Bibliotheksunterstützung genießt. Darüber dürfte allerdings die Embedded-Fraktion wieder weniger glücklich sein, womit sich der Kreis mit Mühe schließt und ich hoffentlich knapp an der Off-Topic-Grenze vorbeigeschrammt bin.

[Arne aus dem Norden]

Auf die schnelle: ist angekommen, Lieferzeit war nun knapp 8 Tage aus England bei einem Preis -wie schon geschrieben- von 9,29 Euro mit Versand.
Eben das Ding mal auf einen UNO aufgesteckt und die Demoprogramme aus der Arduino-IDE aufgespielt.
Läuft alles binnen weniger Minuten. Nur manche IP in den Demos ist wohl nicht mehr aktuell (z.B. Google).
Das war also der leichte Teil der Übung ;-)

Heute Abend werde ich wohl auch noch mal die anderen Boards durchtesten, ob das Shield mit allen kompatibel ist (Mega, Leo, Freeduino Serial).

[Andreas Karg]

Grandiös

[Arne aus dem Norden]

So,

das Shield ist jetzt zu weiteren Versuchen am Zusi-PC auf einem überzähligem Freeduino Serial V2 gesteckt.
Das ist ein Duemilanove-kompatibles Board mit dem Atmel 328P wie in der Uno auch hat. Negativ fällt der enorme Stromverbrauch des Shields auf, ich habe noch nie erlebt das sich der Spannungsregler auf dem Freeduino so stark erwärmt, das man sich die Finger verbrennt beim berühren...

Nachdem ich gestern noch ein bißchen herumexperimentiert habe, scheint ein erstes Anmelden am Zusi-Server jetzt zu klappen.
Das Script ist noch ein bißchen aufgeblähter als nötig weil es über den seriellen Monitor eine Rückmeldung gibt.
Ich werde es in Zukuft hier auch nicht mehr komplett posten um den Thread nicht zu lang werden zu lassen.



Zuerst -wie immer- die nötigen Bibliotheken einbinden, Variablen anlegen und IPs angeben:

Code: Alles auswählen

#include <Ethernet.h>
#include <SPI.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; // Mac Adresse Ethernetshield
byte ip[] = {192, 168, 178, 177 };           // IP Ethernetshield
byte server[] = { 192, 168, 178, 33 };     // IP Windows PC mit ZusiServer
byte hello[27]; // Variable "HELLO" Befehl
char buffer[0]; // Variable zur Formatierung serieller Ausgabe

EthernetClient client;

Dann im Setup die Verbindung starten und den HELLO-Befehl zusammenbasteln

Code: Alles auswählen

void setup()
{
  Ethernet.begin(mac, ip); // Ethernetverbindung starten
  Serial.begin(9600);  // serielle Verbindung zur Statuskontrolle starten
  delay(1000);    // seriellen Port kurz Zeit geben

  // HELLO Befehl zusammenbasteln
  hello[0] = 0x17; // PACKET_LENGTH (4 bytes)
  hello[1] = 0x00;
  hello[2] = 0x00;
  hello[3] = 0x00;
  hello[4] = 0x00; // HELLO (2 bytes)
  hello[5] = 0x01;
  hello[6] = 0x01; // VERSION (1 byte)
  hello[7] = 0x02; // CLIENT_TYPE (1 byte)
  hello[8] = 0x12; // IDENTIFICATION LENGTH
  hello[9] = 0x46; // "F"
  hello[10] = 0x61; // "a"
  hello[11] = 0x68; // "h"
  hello[12] = 0x72; // "r"
  hello[13] = 0x70; // "p"
  hello[14] = 0x75; // "u"
  hello[15] = 0x6C; // "l"
  hello[16] = 0x74; // "t"
  hello[17] = 0x20; // " "
  hello[18] = 0x28; // "("
  hello[19] = 0x41; // "A"
  hello[20] = 0x72; // "r"
  hello[21] = 0x64; // "d"
  hello[22] = 0x75; // "u"
  hello[23] = 0x69; // "i"
  hello[24] = 0x6E; // "n"
  hello[25] = 0x6F; // "o"
  hello[26] = 0x29; // ")"

  Serial.println("-> Server connecting..."); // Status auf den seriellen Monitor ausgeben
  if (client.connect(server, 1435)){ // Server -wenn möglich- am Port 1435 verbinden
    Serial.println("connected");
    Serial.println();
    client.write(hello, 27);
    Serial.println("-> Server: HELLO");
    Serial.print("<- Server: ");  } else {
    Serial.println("connection failed"); }
}

Zu guter letzt eine Abfrage im Loop-Teil ob was vom Server zurück kommt.
Ich formatiere das für den ser. Monitor in die selbe schreibweise wie in der Doku vom Server. Macht es verständlicher.

Code: Alles auswählen

void loop()
{
  if (client.available()) {
    char c = client.read();
    sprintf(buffer, "%02d ", c);
    Serial.print(buffer);   }

  if (!client.connected()) {
    Serial.println();
    Serial.println("disconnecting.");
    client.stop();
    for(;;)
      ;
  } }

Die reine Anmeldung wird also akzeptiert, der Server liefert 03 00 00 00 00 02 00 zurück.
Wenn ich das richtig interpretiere sind die ersten vier Bytes 03 00 00 00 die länge des nachfolgenden Pakets (3 Bytes), 00 02 ist das Server ACK_HELLO und 00 das ACK 0x00 -> Client wurde akzeptiert.

Für das weitere Vorgehen der Abfrage müßte man das ganze wohl im Sinne einer State Machine strukturieren nehme ich an...

[Arne aus dem Norden]

Inzwischen hab ich die ganze Anmeldeprozedur mal mit switch case in verschiedene Blöcke aufgeteilt, so das die Anmeldung vollständig durchlaufen wird. Abgesehen mal davon, das die Hälfte des Scriptes zur -später völlig unnötigen- Ausgabe auf den seriellen Monitor ist und die andere Hälfte nur Stur eine Anmeldung nach vorgegebenen Schema vornimmt (ohne Rücksicht auf besondere Fälle wie Ablehnung duch den Server), so hilft es mir doch schonmal den Ablauf etwas zu verstehen.

Ich habe mal exemplarisch an Zusi eine Anforderung gestellt, nur den Wert 36 (Leuchtmelder Sifa).
Das serielle Protokoll in der Arduino-IDE sieht dann nach Anmelden am Server und starten von Zusi verkürzt wie folgt aus:

Code: Alles auswählen

-> Server connecting...
connected

-> Server: HELLO
<- Server: 03 00 00 00 00 02 00 (ACK_HELLO)

-> Server: NEEDED DATA (Start)
<- Server: 03 00 00 00 00 04 00 (ACK_NEEDED_DATA)

-> Server: NEEDED DATA (End)
<- Server: 03 00 00 00 00 04 00 (ACK_NEEDED_DATA)

// Ab hier verbinden und starten einer Fahrt mit Zusi 

03 00 00 00 // im ersten Block scheint es nur eine Bestätigung der
00 10 36      // angeforderten Daten-IDs zu geben
 
07 00 00 00
00 10 36 00 00 00 00 // LM Sifa aus

02 00 00 00
00 10  // keine neuen Daten

02 00 00 00
00 10  // keine neuen Daten

02 00 00 00
00 10  // keine neuen Daten

07 00 00 00
00 10 36 00 00 -128 63 // LM Sifa an

02 00 00 00
00 10  // keine neuen Daten

Jetzt kommt der stressige Teil: umrechnen der Werte (nach IEEE754?) - hab ich noch nie im Leben gemacht...
Ansonsten: bis dahin 12kb von 32kb an Speicher im Freeudino mit dem Programm belegt.
Die extreme Temperatur des Spannungsregler scheint übrigens mit Verwendung eines andere Netzteils mit 7,5 statt 12V durchaus zu sinken. Man kann die Platine jetzt noch anfassen beim Stecker ziehen...

[ImmoBirnbaum]

Da ist eigentlich nix stressiges dran - einfach die Floating Point Emulation Bibilothek an den Linker verfüttern und anschließend im C-Code von float auf integer casten, fertig ist die Laube...

[Andreas Karg]

Umrechnen der Werte geht folgendermaßen:

Code: Alles auswählen

uint8_t buffer[4];

/* Hier Puffer mit Daten füllen... */

float *myFakeFloat = (float*)buffer; /* (1) */

float value = *myFakeFloat; /* (2) */

Was da passiert, ist folgendes:

buffer ist ein Zeiger auf das erste Byte des Arrays, das da eigentlich dahintersteckt. Nun kannst du in C einfach behaupten, dass ein Zeiger nicht auf Daten vom eigentlichen Typ uint8_t zeigt, sondern auf irgendeinen anderen. In diesem Fall sagst du einfach, das is'n Float (1). Die Zuweisung darunter macht dann nichts anderes als eine "echte" Float-Variable anzulegen und 4 Byte (= Größe eines Floats) von dem angezeigten Speicherbereich rauszukopieren (2).

Der Puffer kann übrigens beliebig groß sein. Du kannst den Zeiger auch auf einen konstanten Wert bei Hintertupfing setzen. Beim Dereferenzieren (= Fachwort für (2)) holt er sich seine 4 Byte, wurscht, woher die kommen. Umgekehrt geht übrigens auch eine Zuweisung:

Code: Alles auswählen

*myFakeFloat = 3.14f;

Oder irgendeine beliebige Stelle mitten im Puffer:

Code: Alles auswählen

uint8_t myBuffer[24] /* Enthält irgendwo ein Float */

float ReadFloatFromBuffer(uint8_t offset)
{
  uint8_t *baseAddress = myBuffer + offset; /* Zeigt auf das offset'te uint8_t-Element von myBuffer (3) */
  float *floatPtr = (float*)baseAddress;
  
  return *floatPtr;

  /* GANZ wichtig: Erst das Byte-Offset, dann der Typecast auf den Float-Zeiger.
      So kommt Mist raus:
  float* floatBuffer = (float*)myBuffer;
  float* actualPtr = floatBuffer + offset; <-- Das wäre die offset'te Float im Array. Also vier mal so weit weg wie gemeint! (4)
  */
}

In (3) gibt's ein bisschen Zeigerarithmetik. Wir addieren einen Offset auf unseren Pufferzeiger. -> baseAddress zeigt auf die gewählte Stelle mitten im Puffer. (oder auf eine irgendwo dahinter - s. Zugriffsverletzung unten)
Wichtig hier ist, dass dabei die Größe des zugrundeliegenden Datentyps berücksichtig wird: uint8_t ist 1 Byte groß, also zeigt myBuffer+5 auf das fünfte Byte nach dem Arrayanfang. Wenn man's verkehrt macht, wie in (4), landet man woanders: Weil floatBuffer per Deklaration auf ein Array von Floats zeigt, zeigt floatBuffer+5 auf die fünfte Fließkommazahl nach Arrayanfang. Also auf das zwanzigste Byte in unserem Array - vermutlich nicht das, was gemeint war.

Mit kaputten Zeigern kannst du übrigens viel Mist bauen. Auf dem PC überwacht das Betriebssystem, ob der Zeiger auf einen Speicherbereich zeigt, der auch deinem Programm gehört. Tut er das nicht, und du versuchst trotzdem, drauf zuzugreifen, kommt die berühmt-berüchtigte Zugriffsverletzung. Schlimmer isses aber, wenn du zufällig einen Bereich triffst, der doch dir gehört. Das Betriebssystem kann nicht feststellen, ob das sinnvoll ist, was du da tust. Ergo schreibst du dir unter Umständen irgendwas kaputt. Und erst Stunden später wird der kaputtgeschriebene Bereich doch mal wieder gebraucht, und alles bricht auseinander. Solche Fehler sind immer besonders spaßig.

Das gleiche kannst du auf deinem µC übrigens auch machen - nur, dass es dort nicht mal ein Betriebssystem gibt, das das Gröbste verhindern kann.

Ich hoffe, das bringt dir was und ich hab dich mit meinem Gequatsche nicht unterschätzt.

[Arne aus dem Norden]

Umrechnen der Werte geht folgendermaßen: (..)

Das sieht gut aus. Ich habe nochmal das Script etwas geändert, das die serielle Ausgabe nun auch in HEX erfolgt und nicht mehr DEZ:

Code: Alles auswählen

-> Server: 17 00 00 00 00 01 01 02 12 46 61 68 72 70 75 6C 74 20 28 41 72 64 75 69 6E 6F 29 (HELLO)
<- Server: 03 00 00 00 00 02 00 (ACK_HELLO)

-> Server: 05 00 00 00 00 03 00 0A 24 (NEEDED DATA (Start))
<- Server: 03 00 00 00 00 04 00 (ACK_NEEDED_DATA)

-> Server: 04 00 00 00 00 03 00 00 (NEEDED DATA (End))
<- Server: 03 00 00 00 00 04 00 (ACK_NEEDED_DATA)

// Ab hier verbinden und starten einer Fahrt mit Zusi 

03 00 00 00 00 0A 24 // Bestätigung angefragter Werte; hier nur LM Sifa
07 00 00 00 00 0A 24 00 00 00 00 // LM Sifa aus
07 00 00 00 00 0A 24 00 00 FF80 3F // LM Sifa an

Den ausgegebenen Wert für 'LM Sifa an' mal mit Andis Script in einem kleinen Extra-Programm auf dem UNO getestet:

Code: Alles auswählen

void setup() { Serial.begin(9600); }

void loop() {
uint8_t buffer[4] = { 0x00, 0x00, 0xFF80, 0x3F };
float *myFakeFloat = (float*)buffer;
float value = *myFakeFloat;
Serial.print(value);
while(1); }

Gibt den Wert 1.00 seriell aus.
Die meisten hier werden inzwischen sicher eingeschlafen sein, aber ab hier ginge es ohne Unterstützung durchs Forum für mich kaum noch weiter...

[Andreas Karg]

Sehr gut! Auf geht's zum Blinkiblinki machen!

[Arne aus dem Norden]

Sehr gut! Auf geht's zum Blinkiblinki machen!

Noch nicht ganz Blinkiblinki, aber kurz davor
Hier das Ergebnis der seriellen Monitorausgabe vom Wochenende (ohne die Anmeldeprozedur).
Erste Ausgabe: Bestätigung der angefragten IDs

Code: Alles auswählen

Paketlaenge: 03 00 00 00 (ergibt 3 Bytes)
Paketinhalt: 00 0A 24 
Befehlssatz: 00 0A Befehl: 24

Erster Datensatz mit Wert der ID (LM Sifa aus)

Code: Alles auswählen

Paketlaenge: 07 00 00 00 (ergibt 7 Bytes)
Paketinhalt: 00 0A 24 00 00 00 00 
Befehlssatz: 00 0A Befehl: 24 
Wert: 00 00 00 00  (ergibt 0.00)

Dann kommt ca. 500x das:

Code: Alles auswählen

Paketlaenge: 02 00 00 00 (ergibt 2 Bytes)
Paketinhalt: 00 0A Befehlssatz: 00 0A

...bis der LM Sifa angeht

Code: Alles auswählen

Paketlaenge: 07 00 00 00 (ergibt 7 Bytes)
Paketinhalt: 00 0A 24 00 00 FF80 3F 
Befehlssatz: 00 0A Befehl: 24 
Wert: 00 00 FF80 3F  (ergibt 1.00)

Die Frage, ob die Ausgabe mit dem Shield direkt am Zusi-Server funktioniert, ist damit wohl definitiv beantwortet
Wobei die Frage für mich wohl auch eher war, ob es für MICH schaffbar ist. Das es gehen müßte haben ja viele hier richtigerweise geschrieben. Der weitere Plan

kurzfristig:
- Auslesen von mehrerer IDs (zuerst mal PZB)
- Ausgabe auf die PINs vom Arduino
- Fräsen eines weiteren Zauberwürfels http://forum.zusi.de/viewtopic.php?f=25&t=11183 als Hardware-Testobjekt für die Ausgabe. Soll ja auch Spaß machen

mittelfristig:
- das Script vorzeigbar machen (unter angebotener Hilfe von Profis hier)
- komplett Dokumentieren
- zum Download hier einstellen

langfristig:
- Ein- und Ausgabe für Zusi3

[Andreas Karg]

[Arne aus dem Norden]

Sehr gut! Auf geht's zum Blinkiblinki machen!

Zuerst der (zer)spanende Teil: noch letzte Teile zusammengesucht und einiges nachgefräst für einen weiteren Testzauberwürfel.


Die Platine ist allerdings diesmal etwas sparsamer ausgeführt als die letzten damals von nonesense
Dafür gleich mit LEDs mit großem Abstrahlwinkel, man lernt ja dazu...


Dann der spannende Teil. IDs für alle LM der PZB abgefragt und Ausgabe über Pin 2 bis 7 des Freeduinos:
https://vimeo.com/71993509


Ausser das der Würfel noch etwas lichtundurchlässig gemacht werden muß ist mir allerdings auch eine sehr ungleichmäßige Blinkfrequenz aufgefallen. Das war auch früher schon so an der USB/.NET-Clientvariante zu beobachten (und zu hören wegen Relaisausgängen am Pult). Inzwischen kann ich aber sehen, das die Ausgabe vom Server da schon Unregelmäßigkeiten vorgibt; die Anzahl der leeren Befehle zwischen dem Aufleuchten von "M" und "O" ist unterschiedlich.

[Sebastian N.]

Sieht doch gut aus! Die leichten Unregelmäßigkeiten würden mich nicht stören.

[Arne aus dem Norden]

Sieht doch gut aus! Die leichten Unregelmäßigkeiten würden mich nicht stören.

Find ich eigentlich auch noch hinnehmbar so.
Ich hoffe aber, das die Perfomance nicht noch mehr einknickt bei mehr Abfragen...
Andererseits ist jetzt auch noch viel Ballast im Script zum protokollieren, das kommt ja auch noch wieder raus.

[Andreas Karg]

Mich überrascht ein wenig, dass es überhaupt leere Befehle gibt. Das war mir bisher nicht bekannt... Schätze, die sind bei meinem eigenen Werk einfach implizit ignoriert worden. Wobei mir andererseits bisher auch kein unregelmäßiges Geblinke aufgefallen ist. Hm.

Nachtrag:
Eben mal ein Video von meiner eigenen Hardware aus dem Archiv gekramt. Dort blinkt es ziemlich regelmäßig; teilweise sogar subjektiv mit ein bisschen Voreilung gegenüber dem Führerstandsbild.

[Arne aus dem Norden]

Mich überrascht ein wenig, dass es überhaupt leere Befehle gibt. Das war mir bisher nicht bekannt... Schätze, die sind bei meinem eigenen Werk einfach implizit ignoriert worden. Wobei mir andererseits bisher auch kein unregelmäßiges Geblinke aufgefallen ist. Hm.

Ich hab das auch recht früh in meinem Script so eingefügt, das er alles was kleiner oder gleich 2 ist in der Paketlänge garnicht weiter anguckt bzw. im Protokoll ausgibt. Wozu auch.
Aber der Debugging-Modus des TCP Server zeigt es in den Protokollen recht gut. Links nur Leerbefehle nach Anmeldung vor Beginn der Fahrt, rechts wenn wir uns in Bewegung gesetzt haben und die PZB im restriktiven Modus blinkt. Man erkennt auch die Unregelmäßigkeiten, mal drei, mal vier Leerbefehle zwischen "M" und "O"...



PS: war mir in dem Script für den Arduino an USB ("Thread Ausgänge") damals auch wirklich überhaupt nur aufgefallen, weil es klang als wenn eins der Relais im Pult "klebt"...

[Andreas Karg]

Frage in die Runde: Hat sonst noch jemand dieses Verhalten beobachten können?

[SgtMcExodus]

Bei mir blinkt alles wie es soll vor sich hin. Allerdings bleibt mein Tacho stehen, wenn der 500er angeht. Da LM und Tacho an unterschiedlichen Geräten hängen, liegt das Problem wohl auf Softwareseite. Aber ich werde es schon noch finden ,hoffentlich.


Gruß,
Jakob

[Arne aus dem Norden]

Also mein Rechner ist Win XP, irgendwas mit X64 5000+ Prozessor, Zusi ist in der allerletzten Version 2474 und der TCP-Server auch (1.4a). Da der Rechner normal nicht ins Internet geht ist auch nix groß mit Antiviren, Firewall oder so von mir aus installiert.
Kann das den trotzdem sein, das irgendwelche Windowseinstellungen für die Ports die Ausgabe verzögern?

Das eBula lief bei mir ja auch seit ich den Rechner hab noch nicht wirklich fehlerfrei.
Die Ortung vertut sich regelmäßig um minimal 0,5km, eher mehr.
Lediglich die völlig wirren Ausgaben der LM wurden besser, nachdem ich den Server 1.4a installiert habe (mit der geänderten Commandset...)