martinpi
06.11.2008, 19:12
Hallo Leute,
jetzt habe ich auch einen Asuro.
Dass Elektronik selten auf Anhieb klappt weiß ich, aber der Asuro hat bei der Inbetriebnahme doch mehr Macken gezeigt als erwartet.
-----------------
Für die die es interessiert, hier meine Abenteuer im einzelnen:
Bestückung OK, Beschreibung gut.
Welche Codierscheibe auf dem Zahnrad verwenden? Es liegen solche mit 4 und mit 6 Strichen bei. Auf allen Photos sind 4 zu sehen, ich entscheide mich für 4.
HW-Test: Einer der Linenfolgesensoren funktioniert nicht --> "kaltes Ende" von R15 hat keinen Massekontakt. Lötung in Ordnung, es muss ein Print-Fehler sein --> Drahtbrücke zu nächstem Massepunkt (Taster-Gehäuse) --> OK
SW-Installation auf dem laptop unter Windows von der CD, USB-Transceiver.
Schreibe mein erstes Programm --> Funktion Go nicht vorhanden
Schreibe ein Progrämmchen die die Taster-Zustände auf der seriellen Schnittstelle ausgibt.
--> Flashen extrem unzuverlässig, jede Menge checksum- und timeout-Fehler, brauche mehrere Versuche um ein Programm zu flashen.
Keine Leuchtstoffröhren im Raum, auch sonst keine starken Lichtquellen.
IR-Transceiver direkt über Asuro, ca. 30cm Abstand.
Serielle Verbindung auch in Hyperterm extrem unzuverlässig. Immerhin zeigt es funktionierende switches an.
Die Funktion SerRead ist ein Beispiel wie man nicht programmieren sollte. Statt das Ergebnis der Übertragung (Timeout) in den Nutzdaten und noch dazu mit einem sonst gültigen Code ("T") zu codieren sollte der Rückgabewert der Funktion genutzt werden. Statt "void" könnte die Funktion die die Anzahl der empfangenen Zeichen zurückliefern. 0 hieße dann "keine Zeichen empfangen".
Bei den Beispielprogrammen fällt mir auf dass sehr wenig Gebrauch von der seriellen Schnittstelle gemacht wird. Wenn ich etwa mit verschiedenen Geschwindigkeits-Werten oder später mit Reglerparametern experimentieren will, muss ich jedesmal neu flashen - was fehleranfällig und zeitraubend ist. Statt dessen könnte ich ja einen einfachen Dialog programmieren, mit dem man Werte zur Laufzeit verändern kann. Allerdings, so schlecht wie die serielle Schnittstelle funktioniert, könnte das auch mühsam werden.
Ein nichtflüchtiger Speicher (EEPROM) für Reglerparameter etc. wäre auch nicht schlecht. Den kann man ja per I2C nachrüsten. Schade dass er nicht standardmäßig dabei ist.
Dass man keine eigene timer-Interrupt-Routine einfügen kann überrascht mich.
Installiere auf dem desktop PC unter Windows, diesmal Software aus dem Internet.
Aktuelle asurolib (2.8), jetzt habe ich die Funktion "Go".
Flash-tool 1.5.1 mit neuem USB-Treiber.
Stecke das USB-Kabel an, installiere den neuen Treiber.
Versuche zu flashen, kann nicht einmal eine Verbindung zum Transceiver (COM12?) herstellen.
Nehme Flash-tool 1.4 mit dem neuen Treiber, dieses findet eine Schnittstelle "USB" und funktioniert immerhin, aber genauso schlecht wie auf dem anderen PC mit dem alten Treiber.
Eine Verbindung mit Hyperterminal geht mit dem neuen Treiber gar nicht.
Wie werde ich den Treiber wieder los? Das mitgelieferte uninstall-tool geht nicht, weil es behauptet dass das Kabel immer noch angesteckt sei.
Mein Programm sollte mit Go(500,100) ein Stückchen geradeaus fahren, ich habe ca. einen halben Meter erwartet. Tatsächlich fährt er endlos im Kreis.
EncoderInit() ist aufgerufen.
Ich nehme wieder den alten PC und flashe das HW-Testprogramm, um zu sehen ob die Odometriesensoren in Ordnung sind.
Ich kann es flashen, aber es läuft nicht. Bleibt im LED-Test hängen.
Noch einmal flashen. Läuft, Odo in Ordnung, Switches gehen nicht.
Ich lade mein switch-Testprogramm, wieder Flash-Probleme.
Statt meiner Ausgabe sehe ich nur gallische Schimpfwörter am Schirm. Noch einmal flashen, jetzt läuft es halbwegs (aber immer noch falsche Zeichen zwischendurch), die switches gehen wirklich nicht mehr.
Aus dem HW-Testrogramm kopiere ich die Rechteck-Demo in mein Programm und probiere es erneut.
Ich hatte es mit speed 100 probiert, im HW-Testprogramm wird mit 200 gefahren.
Siehe da, er bewegt sich! Gerade, allerdings stimmen die Winkel nicht. Kann an den Encoder-Scheiben liegen.
Gut, ich probiere es vorerst mit 60° statt 90°.
Flashen - ich traue meinen Augen nicht, nur ein einziger checksum-error!
Rechtkurve - ca. 90°, annehmbares Rechteck.
Ein Binärzähler der die BackLEDS ansteuern soll bringt das Programm zum Absturz, der Asuro fährt gerade weiter.
BackLED (i&1,(i&2)>>1);
Das sollte doch nur gültige Werte liefern???
Uff, soweit geschafft.....
jetzt habe ich auch einen Asuro.
Dass Elektronik selten auf Anhieb klappt weiß ich, aber der Asuro hat bei der Inbetriebnahme doch mehr Macken gezeigt als erwartet.
-----------------
Für die die es interessiert, hier meine Abenteuer im einzelnen:
Bestückung OK, Beschreibung gut.
Welche Codierscheibe auf dem Zahnrad verwenden? Es liegen solche mit 4 und mit 6 Strichen bei. Auf allen Photos sind 4 zu sehen, ich entscheide mich für 4.
HW-Test: Einer der Linenfolgesensoren funktioniert nicht --> "kaltes Ende" von R15 hat keinen Massekontakt. Lötung in Ordnung, es muss ein Print-Fehler sein --> Drahtbrücke zu nächstem Massepunkt (Taster-Gehäuse) --> OK
SW-Installation auf dem laptop unter Windows von der CD, USB-Transceiver.
Schreibe mein erstes Programm --> Funktion Go nicht vorhanden
Schreibe ein Progrämmchen die die Taster-Zustände auf der seriellen Schnittstelle ausgibt.
--> Flashen extrem unzuverlässig, jede Menge checksum- und timeout-Fehler, brauche mehrere Versuche um ein Programm zu flashen.
Keine Leuchtstoffröhren im Raum, auch sonst keine starken Lichtquellen.
IR-Transceiver direkt über Asuro, ca. 30cm Abstand.
Serielle Verbindung auch in Hyperterm extrem unzuverlässig. Immerhin zeigt es funktionierende switches an.
Die Funktion SerRead ist ein Beispiel wie man nicht programmieren sollte. Statt das Ergebnis der Übertragung (Timeout) in den Nutzdaten und noch dazu mit einem sonst gültigen Code ("T") zu codieren sollte der Rückgabewert der Funktion genutzt werden. Statt "void" könnte die Funktion die die Anzahl der empfangenen Zeichen zurückliefern. 0 hieße dann "keine Zeichen empfangen".
Bei den Beispielprogrammen fällt mir auf dass sehr wenig Gebrauch von der seriellen Schnittstelle gemacht wird. Wenn ich etwa mit verschiedenen Geschwindigkeits-Werten oder später mit Reglerparametern experimentieren will, muss ich jedesmal neu flashen - was fehleranfällig und zeitraubend ist. Statt dessen könnte ich ja einen einfachen Dialog programmieren, mit dem man Werte zur Laufzeit verändern kann. Allerdings, so schlecht wie die serielle Schnittstelle funktioniert, könnte das auch mühsam werden.
Ein nichtflüchtiger Speicher (EEPROM) für Reglerparameter etc. wäre auch nicht schlecht. Den kann man ja per I2C nachrüsten. Schade dass er nicht standardmäßig dabei ist.
Dass man keine eigene timer-Interrupt-Routine einfügen kann überrascht mich.
Installiere auf dem desktop PC unter Windows, diesmal Software aus dem Internet.
Aktuelle asurolib (2.8), jetzt habe ich die Funktion "Go".
Flash-tool 1.5.1 mit neuem USB-Treiber.
Stecke das USB-Kabel an, installiere den neuen Treiber.
Versuche zu flashen, kann nicht einmal eine Verbindung zum Transceiver (COM12?) herstellen.
Nehme Flash-tool 1.4 mit dem neuen Treiber, dieses findet eine Schnittstelle "USB" und funktioniert immerhin, aber genauso schlecht wie auf dem anderen PC mit dem alten Treiber.
Eine Verbindung mit Hyperterminal geht mit dem neuen Treiber gar nicht.
Wie werde ich den Treiber wieder los? Das mitgelieferte uninstall-tool geht nicht, weil es behauptet dass das Kabel immer noch angesteckt sei.
Mein Programm sollte mit Go(500,100) ein Stückchen geradeaus fahren, ich habe ca. einen halben Meter erwartet. Tatsächlich fährt er endlos im Kreis.
EncoderInit() ist aufgerufen.
Ich nehme wieder den alten PC und flashe das HW-Testprogramm, um zu sehen ob die Odometriesensoren in Ordnung sind.
Ich kann es flashen, aber es läuft nicht. Bleibt im LED-Test hängen.
Noch einmal flashen. Läuft, Odo in Ordnung, Switches gehen nicht.
Ich lade mein switch-Testprogramm, wieder Flash-Probleme.
Statt meiner Ausgabe sehe ich nur gallische Schimpfwörter am Schirm. Noch einmal flashen, jetzt läuft es halbwegs (aber immer noch falsche Zeichen zwischendurch), die switches gehen wirklich nicht mehr.
Aus dem HW-Testrogramm kopiere ich die Rechteck-Demo in mein Programm und probiere es erneut.
Ich hatte es mit speed 100 probiert, im HW-Testprogramm wird mit 200 gefahren.
Siehe da, er bewegt sich! Gerade, allerdings stimmen die Winkel nicht. Kann an den Encoder-Scheiben liegen.
Gut, ich probiere es vorerst mit 60° statt 90°.
Flashen - ich traue meinen Augen nicht, nur ein einziger checksum-error!
Rechtkurve - ca. 90°, annehmbares Rechteck.
Ein Binärzähler der die BackLEDS ansteuern soll bringt das Programm zum Absturz, der Asuro fährt gerade weiter.
BackLED (i&1,(i&2)>>1);
Das sollte doch nur gültige Werte liefern???
Uff, soweit geschafft.....