D1 Mini Shield Support

[Zoltan]

Das wird etwas länger, aber ich möchte damit anderen DAUs helfen.

Das erste Problem ist bereits da.
(Und zwar sitzt es vor dem Rechner )

Man kann den ESP nicht flashen, wenn Putty an ist.
Ich wußte das nicht
Ich beschreibe hier detaillierter meinen Fehler, damit andere Anfänger nicht hineintappen:

Mein Vorgehen:
D1 angeschlossen, Putty angeworfen, ist leer, chip echoes alle Character.
Ich versuche den Flash Command was ich vorhin benutzt habe.
Ich kann die D1 nicht flashen.
Nicht mit meinem Programm
Ich denke, mein Programm ist falsch.
Ich nehme Sven V1.2.2, der ist sicher nicht fehlerhaft.
Ich sage:

Code: Alles auswählen

esptool -vvv -cd nodemcu -cf ./littleyoda-DCC-Decoder.d1_mini_v1.2.2.bin

esptool sagt:

Code: Alles auswählen

esptool v0.4.6 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
	setting board to nodemcu
	espcomm_upload_file
	stat ./littleyoda-DCC-Decoder.d1_mini_v1.2.2.bin success
opening port /dev/ttyUSB0 at 115200
	tcgetattr
	tcsetattr
	serial open
opening bootloader
resetting board
trying to connect
	setting character timeout 0
	done
	setting character timeout 1
	done
	espcomm_send_command: sending command header
	espcomm_send_command: sending command payload
		espcomm_send_command: didn't receive command response
...
trying to connect
	setting character timeout 0
	done
	setting character timeout 1
	done
	espcomm_send_command: sending command header
	espcomm_send_command: sending command payload
	serialport_receive_C0: 20 instead of C0
		espcomm_send_command: didn't receive command response
warning: espcomm_sync failed
error: espcomm_open failed

Das angeschlossene Putty sagt inverse grinsende Krokodile (als ob Baudrate nicht stimmt, oder so).
Chip bleibt auf Putty vorerst taubstumm.
Reset Knopf bringt nichts.
Power cycle bringt wieder default Status: Chip echoes alles (einmal sagte er sogar "ready")

Glühbirne im Kopf geht auf: Putty ist seriell, Flash ist seriell, Putty belegt den Port, esptool kann nicht flashen... Testen?

Genau.

Ohne Putty funktioniert das Flashen.

Ich flashe mein Programm, und komme auf das erste Problem: das ist aber sicher in meinem Code vorerst.

(Bei Interesse kann ich das gerne hier einfügen).

ALso gehe ich erstmal den Zoltancode debuggen.

Bis dann

LG Zoltan

[Zoltan]

Inzwischen sind die PowerShields auch angekommen, und alle "Tausendfüßler" wurden fertiggelötet:

20190523_140642.jpg (450.2 KiB) 13927 mal betrachtet

20190523_140726.jpg (414.55 KiB) 13927 mal betrachtet

Beide MotorShields wurden auch schon geflashed, um sie für Sven's Programm vorzubereiten.
Denn mein Programm will einfach nicht stabil (oder überhaupt vernünftig) funktionieren, ich stehe auf der Leitung irgendwie.
Wenn jemand Masochist wäre, kann er es sich anschauen:

wifi_motor_control_v1.ino.zip

(1.44 KiB) 843-mal heruntergeladen

Ich bin sehr stark in der Annahme, dass ich warten muss, bis Sven das Framework mit PWM für die I2C MotorShield Variante fertig macht. Hardware ist inzwischen komplett fertig und "fahrbereit", MotorPower kommt auch vom Powershield:

20190523_165616.jpg (797.98 KiB) 13924 mal betrachtet

Nur die Funktionalität lässt noch auf sich warten... und vorerst habe ich irgendwie keine Lust, noch mehr Zeit im Arduino IDE zu verbringen. Vielleicht morgen

LG Zoltan

[little.yoda]

Hast du mal die mitgelieferte Beispiele probiert?
https://github.com/wemos/WEMOS_Motor_Sh ... no_Library

Ich würde den nächsten Schritt erst gehen, wenn diese Beispiele funktionieren.

[Bei mir funktionierten sie nämlich nicht]

[Zoltan]

Ich fand einen einfachen Tester irgendwo und baute den um, testete aber noch ohne Motoshield, nur die Webseite. Werde aber jetzt bottom-up neu anfangen. Aber du hast doch nicht aufgegeben? So kenne ich dich nicht. Andere Sachen sind wichtiger, das sehe ich ein, aber der MS muss auch integriert werden

LG Zoltan

[little.yoda]

Wenn du mir sagst, dass das Basisprogramm funktioniert, würde ich es einbauen.

Sonst erst, wenn mein Shield angekommen ist und ich das Basisprogramm erfolgreich getestet habe.

[Zoltan]

Ich mache mich dran.
Die nächste Versuchsanordnung ist fertig:

20190524_094258.jpg (457.43 KiB) 13913 mal betrachtet

Ich fange an zu kämpfen und werde berichten. HW ist wirklich testbaufreudig und praktisch... nur ich bin (noch) nicht fähig (genug). Aber ich gehe es von unten an und "schaumamal..."

Aber warte nicht auf mich, denn ich habe sehr viel an der großen Lok zu tun und bis ich hier eine Motorenumdrehung endlich schaffe, kommen bei dir ein Dutzend Schields an und du steuerst schon eine Drohne mit deinem Programm bis ich berichten kann...

LG Zoltan

[Zoltan]

Nun bin ich "geschossen".

Ich habe die Konfig zusammengesteckt:

20190524_120055.jpg (406.65 KiB) 13908 mal betrachtet

(Der gelbe Jumper hängt in der Luft, den habe ich mal zum Flashen nur temporär zwischen RTS und 3V gesteckt gehabt)

Ich habe 2 D1 Minis und 2 Motorshields.

Ich nahm das erste Example Programm (motor_base) und habe es etwas vereinfacht (nur 1 Motor):

Code: Alles auswählen

#include "WEMOS_Motor.h"

int pwm;

//Motor shield I2C Address: 0x30
//PWM frequency: 1000Hz(1kHz)
Motor M1(0x30,_MOTOR_A, 1000);//Motor A
//Motor M2(0x30,_MOTOR_B, 1000);//Motor B


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

void loop() {

  for (pwm = 0; pwm <= 100; pwm++)
  {
    M1.setmotor( _CW, pwm);
  //M2.setmotor(_CW, 100-pwm);
    Serial.printf("A:%d%, DIR:CW\r\n", pwm);
  }
  
  M1.setmotor(_STOP);
  //M2.setmotor( _STOP);
  Serial.println("Motor A STOP");
  delay(200);
  
  for (pwm = 0; pwm <=100; pwm++)
  {
    M1.setmotor(_CCW, pwm);
    //M2.setmotor(_CCW, 100-pwm);
    Serial.printf("A:%d%, DIR:CCW\r\n", pwm);

  }
  
  M1.setmotor(_STOP);
  //M2.setmotor( _STOP);
  delay(200);
  Serial.println("Motor A STOP");

  M1.setmotor(_SHORT_BRAKE);
  //M2.setmotor( _SHORT_BRAKE);
  Serial.println("Motor A SHORT BRAKE");  
  delay(1000);
  
  M1.setmotor(_STANDBY);
  //M2.setmotor( _STANDBY);
  Serial.println("Motor A STANDBY");  
  delay(1000);
  
}

Mit serial 250000 sah ich Garbage im Serial Monitor (auch im Putty garbage):

20190524_120102.jpg (278.15 KiB) 13908 mal betrachtet

20190524_120100.jpg (608.49 KiB) 13908 mal betrachtet

Der Motor tat nichts.

Ich habe mit beiden D1 und beiden MS probiert (also vier Varianten).
Keines drehte den Motor.

Ich habe dann BaudRate beim serial.begin auf 115200 geändert.
Hier sah ich dann den gewünschten Output im Serial, aber der Motor tat nichts.

Also bin ich wohl dort angelangt, Sven, wo du warst: das Shield tut scheinbar nicht was er soll (?).
(ob der geflashte geänderte Firmware damit zu tun hat? EIne jungfräuliche MS habe ich nicht mehr. Gibt es das originale FW irgendwo noch?)

Zunächst einmal habe ich die Spannung am MS messen: ist OK, 9 V liegen am MS an.
Dann habe ich die Frequenz auf 100 Hz gesetzt.
Nix hat sich geändert, Motor dreht nicht.

Nun grübelte ich, ob die Shield Adresse sich mit dem neuen FW geändert hat? Es gibt ja 5 Varianten des FW, eine ohne Adresse, und vier mit jeweils 2D, 2E, 2F, 30... das konnte ich noch schauen... ob die MS FW mit _30 geflasht und mit diesem Programmierten 30 läuft - läuft auch so nicht.

Es muss etwas generelles blödes sein. Jetzt werde ich googeln gehen und parallel dazu beten, dass Sven es findet, was faul ist.


Bis dann!

LG Zoltan

[Zoltan]

Ich habe weiter gekämpft, einiges gelesen und überlegt, aber keine Ahnung, ob das für uns Sinn hat.
Anyway, hier sind meine Gedanken, als Kaleidoskop, vielleicht gibt eines oder der Andere mal einen Denkanstoß jemandem, der sich besser damit auskennt:

*

Dass die originale Arduino Ide Wemos Examples für andere auch nicht gehen, habe ich vielerorts gelesen.
Angeblich gehen sie aber mit D1 mini Pro und Lite (?). Checken konnte ich das nicht.

*

Man vermutet schon mal kalte Lötstellen und/oder Wackelkontakte - das hielt ich für Unsinn, da mehrere Module das gleiche (Fehl)Verhalten zeigen und es bei Sven auch nicht ging.

*

Es gibt mehrere Ausführungen vom D1 Mini. Ob die wirklich gleich sind? Meine sehen zB. anders aus als dieses hier:

https://cdn.instructables.com/FWA/VFOH/ ... .LARGE.jpg

Kann sein, dass die ganze Problematik nicht am MS sondern am D1 liegt?

*

Der MS bekommt seine Power auf dem 3,3V Pin (und NICHT auf dem 5V-Pin, er hat keinen StepDown).

Die D1 kann vom USB oder auf dem 5V-Pin gepowert werden. Die VCC 3,3 V kommt also vom D1 (weil er einen Stepdown dafür hat) und so versogt dieser Stepdown vom D1 das ganze 3,3V-Bus über alle Shields.

Also allzu viele 3,3V Verbraucher dürften nicht zusammengesteckt sein (ich weiß nicht wie viel dieser Stepdown verträgt).

Aber wenn D1 und MS zusammengesteckt sind, und D1 seine 5 V über USB (oder vom PowerShield über das 5 V-Pin) bekommt, bekommt auch das MS seine 3,3 V.

*

MS MotorPower kann bis 15 V betragen, Motorstrom 1,2 A average, 3,2 V peak. Ob pro Motor oder für beide zusammen, weiß ich nicht, aber ein Motor mit ~500 mA müsste gehen. Frage: Was macht er bei Kurzschluss/Überlast am Motorenausgang: Schutzabschaltung oder flöten gehen? Mein Testmotor frisst <500 mA.

*

I2C wird im factory Zustand des MS angeblich nach max 10 s resettet.
Abhilfe:
- I2C in mind. 9s-Perioden ansprechen (Ticker?) oder noch besser:
- FW neu flashen
Diese Issue ist seit >2 Jahren bekannt und das haben wir mit dem Reflash erledigt angeblich.
Trotzdem funzt es nicht. Frage: Hätte es mit einem ungeflashten MS funktioniert? Ich habe keins zur Hand.

*

Ob das hier funktioniert:

Code: Alles auswählen

You can control the Motorshield by remote http commands send from any device that can send http get requests. 

 http://<ESP IP address>/control?cmd=WemosMotorShieldCMD,<Motornumber>,<Forward/Backward/Stop>,<Speed>
zB:
 http://<ESP IP address>/control?cmd=WemosMotorShieldCMD,0,Forward,99
 http://<ESP IP address>/control?cmd=WemosMotorShieldCMD,0,Stop

habe ich noch nicht testen können.

*

Irgendwo habe ich auch etwas gelesen über Frequenzen (10 k geht nicht vs 100 k geht), aber das betraf etwas mit MicroPython und da sehe ich erstmal gar nicht durch.

*

Auf dem Wemos Forum ist angeblich etwas darüber, dass "it is possible for the controller to lock up if an incorrect formatted I2C command is sent to the shield" aber "WEMOS Forum is currently undergoing maintenance. Please come back another time."

*

Irgendwie scheint es mit der Kommunikation uf der I2C Bus zu hapern.
Wie könnte man den I2C Bus monitoren, ob da alles okay ist? Adressen usw...

*

Ob die Probleme in den Headerfiles liegen? Wir inkludieren sie ja, und die Funktionen, die von dort gerufen werden, funktionieren bei uns scheinbar nicht - ob diese Funktionen in den Headerfiles auch wirklich korrekt sind? Aber dafür bin ich zu Anfänger...

*

Für den MS V2 schreiben sie übrigens:
If the number of bytes sent to it isn't a multiple of 4 bytes, then it will lock the I2C bus. (???)
Aber wir haben es nicht mit V2 sondern mit V1 zu tun.

Mehr fällt mir vorerst nicht ein, ich kämpfe erstmal weiter.

LG Zoltan

[little.yoda]

Ich würde erst mal einen Schritt zurück machen:

- Prüfen, ob die i2c Adresse richtig ist:
https://gist.github.com/tfeldmann/5411375

[Zoltan]

Das scheint zu passen.

Ohne MS nix gefunden, mit MS:

Code: Alles auswählen

18:08:57.780 -> 
18:09:02.782 -> Scanning...
18:09:02.782 -> I2C device found at address 0x30  !
18:09:02.815 -> done
18:09:02.815 -> 

Beide D1 und beide MS.

Also das scheint erstmal in Ordnung zu sein.

DLG Zoltan

PS.: jetzt ist aber etwas dazwischengekommen, ich muss erstmal Pause machen...