M5StackFire und M5Stack

Der Schwarze ist schwarz hat keinen MPU oder MAG und kein PS-RAM, der 
Graue ist grau und hat nen MPU9250 (rangefrickelt) und ebenfalls kein 
PS-RAM und der Fire hat ne LED-Bar mit WS2812b kompatiblen 
adressierbaren LEDs und nen MPU6050 + MAG3110 + PS-RAM

Hallo,

ich bin über M5Stack über deren M5Stack Cam gestolpert.

Bei Pollin hatte ich parallel das entdeckt:
https://www.pollin.de/p/odroid-go-mobile-spielekonsole-kit-810887

Ich schreibe das hier, weil die Ähnlichkeit der M5Stack und der 
Ondroid-Software mich etwas verwirrt hat. Etwas Verwirrung hat für mich 
vor allem ausgelöst, daß z.B. M5Stack Teile der TFT_eSPI Grafiklib 
benutzt und diese in In_eSPI umbenannt hat. Man bekommt die M5Stack 
Arduino Lib relativ problemlos auf dem Odroid Go zu Laufen.

Bei haben ein Tool, um den ESP32 direkt von SD-Card zu flashen, das ist 
interessant und ich werde es mir genauer anschauen.

Unterlagen incl. Schaltpläne sind bei beiden verfügbar, es ging mir aber 
wie dem TO: ich habe Probleme, rauszufinden, was da nun wie unter 
welchem Namen bei M5Stack angeboten wird.

Gruß aus Berlin
Michael

Hallo,

Rainer schrieb:
> Für nur 20€? Wenn ich es richtig sehe, ist das Kamera+ESP32.

Richtig. Wenn Du noch mehr sparen willst:
https://www.ebay.de/itm/M5Stack-ESP32-Kamera-Modul-Entwicklungsboard-OV2640-Camera-Type-C-Grove-Port/153079916406?hash=item23a4462776:g:TTcAAOSw6AlbNjcH

Preisvorschlag kannst Du Dir schenken, es sei denn Du willst ca. 12 cent 
sparen...

Auf dem Modul wohnt auch noch ein Powerbankmodul für Akkuversorgung. 
Nettes Teil, Laderegler, BMS-Funktion und StepUp auf 5V und pass 
through.
Das Datenblatt des IP5306 habe ich mir mal verblüffend gut online aus 
dem chinesischen übersetzen lassen.

Nun die Probleme: es sind natürlich weiter keine Pins des ESP32 
rausgeführt mit einer Ausnahme. Es gibt Lötplätze für BME280, MP6050 und 
ein Mini-Mikrofon vorhanden. Für Leute, die die ICs greifbar haben und 
gern SMD löten... Da kommt man zumindest an 2 Pins des ESP32 ran 
(SDA/SCl der ICs).

Größtes Problem: es gibt vermutlich einen Designfehler: SCCP für das 
Cam-Modul nutzt nur die internen PullUp des ESP32 und die sind offenbar 
viel zu hochohmig. Ob das für einige7viele/alle Module zutrifft, kann 
ich nicht sagen. Abhilfe sind 2x 4,7k als PullUp einzulöten, allerdings 
habe ich außer dem Kamerasteckverbinder mit 0,xmm Raster noch keine 
Anschlußpunkte gefunden...
Im Anhang mal ein Bild meines Moduls, nach relativ kurzer Zeit gibt es 
Bildfehler, der ESP32 wird ziemlich gut ausgelastet und scheinbar sorgt 
seine Erwärmung dann für den Zusammenbruch der SCCP-Steuerung.

Ich muß mal schauen, ob ich am Wochenende eine Lötübung versuche oder ob 
mein Bekannter auf seinem Modul schon Erfolg hatte.

Noch als Nachtrag: der MLX90640 Sensor läuft auch allgemein an den ESPs, 
mir ist das aber irgendwie noch zu teuer...

Gruß aus Berlin
Michael

Hallo,

Rainer schrieb:
> Was mich an dem M5Stack-CAM Softwarebeispiel stört ist, dass es nicht
> für die Arduino IDE gemacht ist.

es hat meinen Bekannten eine Stunde gekostet, es da lauffähig 
reinzuwerfen.
Die ArduinoIDE ist besser als ihr Ruf. :-) Größter Aufwand waren 
Unterschiede der IDF-Versionen, mit denen das Beispiel compiliert wurde 
und der, die in der Boardmanagerversion für ESP32 bei Arduino benutzt 
wird.

Gruß aus Berlin
Michael

Hallo,

Rainer schrieb:
> Das klingt super. Könntest Du den Code hier posten?

Im Prinzip ja, ich will im Moment aber noch schauen, daß die Kamera 
stabil läuft.

> Oder noch besser: vielleicht könnte man es in die M5Stack Beispiele
> einpflegen, dann kann es jeder mit der Arduino IDE einfach benutzen.

Ich fürchte, Dir erhoffst Dir da jetzt zuviel.
Den Demo-Code von github nehmen, alle nötigen .c und .h Dateien in einen 
Arduino Sketch-Ordner mit Namen M5Cam werfen.
Dann die main.c in M5Cam.ino umbenannt und die ArduinoIDE starten.
Das geht vom Prinzip erstmal mit allen IDF-Demos so zu machen, in der 
ArduinoIDE ist ist ja alles zu ESP8266 bzw. ESP32 enthalten wenn man die 
Boards hinzugefügt hat. Das Umbenennen der main.c hat nur den Zweck, den 
verblüffend guten Arduino-Preprozessor zu überreden, sich damit zu 
befassen.
setup() und loop() wird nur benötigt, wenn man Arduino-Bibliotheken mit 
benutzen will.
Dann darf man den Compiler losmeckern lassen. Hier werden noch die 
beiden Webserverdateien benötigt, die sind auch bei github.

Dann wird es viele Fehler geben, weil Funktionen nicht gefunden werden, 
die eigentlich da sind. Das liegt daran, daß die ArduinoIDE jetzt von 
C++ ausgeht, die Files aber C sind. Bei den .h-Dateien, wo die 
Funktionen nicht aufgelöst werden, muß den Comiler gesagt werden, daß es 
C ist, also den Inhalt in

1

#ifdef __cplusplus

2

extern "C" {

3

#endif

4

5

inhalt der .h

6

7

#ifdef __cplusplus

8

}

9

#endif

klammern.

Mit etwas Glück läuft der Compiler dann schon durch.
Ich bin dann nur nicht weitergekommen, weil es ein paar Sachen gibt, die 
das Espressif-IDF beim make abfragt. Hier den Camara-Typ, die 
Pinbelegung
des Cam-Moduls, den WiFi-Mode und Zugangsdaten.
Diese Ersetzungen muß man dann noch direkt in die jeweilige .h eingebaut 
werden. Da sich mein Bekannter das IDF zumindest schon mal genauer 
angeschaut hat, habe ich dann aus Bequemlichkeit bei ihm um Hilfe 
gefleht. ;)
Er hat dann gleich noch setup() und loop() eigebaut und die main-Teile 
da reinsortiert.

Einen Teil der Sachen gibt es bereits als Arduino-Bibliotheken bzw. sind 
Bestandteil der Arduino-ESP-HAL. WiFi und den Webserver kann man z.B. 
recht problemlos auf die Aufrufe der IDE umbauen, die Camare gibt es 
wohl auch schon.

Letztlich ist es also eher Vorlage um überhaupt etwas compilierbares und 
lauffähiges zu haben ohne das Espressif-IDF und den ganzen Kram drumraum 
auch noch auf dem Rechner zu installieren und sich dort einarbeiten zu 
müssen...

Ich bin in den Jahren einfach etwas bequem geworden, mag das 
Arduino-Konzept und die preiswerte Hardware für Hobby-Geschichten.
"Arduino" heißt für mich nur selten "Lego nach Vorlage" zu spielen. 
Sachen wie M5Stack und deren Arduino-Software sehe ich da immer 
zwiespältig. Wenn ich mal schnell was fertiges haben will, greife ich 
durchaus darauf zurück. Wenn es ein Spaßprojekt werden soll, baue ich 
den Baukasten lieber selber und erweitere meine Kenntnisse eben wenn 
nötig. Da ist dann of der Weg das Ziel...

Gruß aus berlin
Michael

Michael U. schrieb:
> Bei Pollin hatte ich parallel das entdeckt:
> https://www.pollin.de/p/odroid-go-mobile-spielekonsole-kit-810887
Habe ihn mir mal gekauft. Echt witzig das Ding. Und die Performance ist 
echt erstaunlich. Gamegear, NES und Gameboy + Gameboy color Spiele 
laufen absolut sauber.
Der 10 Port IO ist leider Etwas begrenzt, da IO19 (MOSI), IO18 (SCK) und 
IO12 nur über ein AND-Gatter, also Unidirektional raus geführt sind. 
Somit sind nur IO15 und IO4 echte I/Os

Hallo,

Timmo H. schrieb:
> Der 10 Port IO ist leider Etwas begrenzt, da IO19 (MOSI), IO18 (SCK) und
> IO12 nur über ein AND-Gatter, also Unidirektional raus geführt sind.
> Somit sind nur IO15 und IO4 echte I/Os

ja, schränkt die Geschichte etwas ein, ich überlege noch nach 
"sinnlosen" Anwendungen... WLAN-Scanner, GPS-Handheld  ???

Die Schwuppdizität
https://de.quickipedia.org/Schwuppdizit%C3%A4t
bei den Spielen ist sehr gut.

Ich hatte ja nicht ohne Grund 2 Stück bestellt. Test mit dem 
Arduino-Kram erstmal keine Probleme, dann due Original-Firmware mit den 
Flasher wieder auf, startet problemlos wieder. Emulator ausgewählt, 
Speil geladen und gestartet und... hängt fest, nur Ausschalten hilft 
noch.
Flashen von SD-Card getestet: sehr schön. Auswahlmenü eine FW 
ausgewählt, flasgen gestartet. Block 2 erase ok, flashen ok. Block 2 
erase, flashen ok, Block 3 erase error...
Bei jeder FW läßt sich ein anderer Block angeblich nicht löschen.
bin-Files mit dem Flasher wieder auf, meldet sich, Spiel gestartet, 
hängt.

Das muß ich mir jetzt alles mal anschauen, prinzipiell ist ja im WiKi 
alles verfügbar, manchmal etwas chaotisch mit den Erklärungen dazu.

Ist für mich auch weiter eine schöne Spielwiese, muß mich mal durch die 
SD-Flash Sourcen wühlen, ist ja eine Espressif-geschichte:
https://github.com/espressif/arduino-esp32/blob/master/libraries/Update/examples/SD_Update/SD_Update.ino

Gruß aus Berlin
Michael

Hallo,

Marc schrieb:
> Ist für das hervorragende Arduino Framework die I2C-Schnittstelle nach
> außen verfügbar?
Was hast Du gegen das Framework?

> Gibt es Pins nach außen, an denen man einen zusätzlichen I2C-Port
> anschließen kann?

I2C ist beim ESP32 Software, die kannst Du auf alle Pins mappen, auch 
auf die verfügbareb.
Du kannst Dich sogar am I2C-LCD 16x2 Demo aus den ODroid-Beispielen 
orientieren...
Wenn ich da nur mehr normale I/O haben wollte, würde ich vermutlich 
einen MCP20S17 an I2C oder eher einen MCP23S17 per SPI ranhängen.

Gruß aus Berlin
Michael

Hallo,

ich kenne diesen Sensor nicht, hängt ja davon ab, was da schon drumrum 
ist, breakout-board?

Der MLX90640 ist doch ohnehin ein 3,3V IC, wäre doch höchstens ein 
5V-3,3V Spannungsregler nötig. Warum sollte ein I2C-Chip eigene PullUps 
brauchen?
PullUps müssen an SDA/SCL dran sein, das ist doch ein Bus zu allen 
Komponenten.

Gruß aus Berlin
Michael

Michael U. schrieb:
> I2C ist beim ESP32 Software

Laut Datenblatt hat er aber I2C in HW. Sogar 2x. Da er auch eine 
GPIO-Matrix hat, kann man die I2C-Signale auf unterschiedliche Pins 
mappen. Aber dass die I2C in SW gemacht wird, ist wohl ein Irrtum.

Hallo,

900ss D. schrieb:
> Laut Datenblatt hat er aber I2C in HW. Sogar 2x. Da er auch eine
> GPIO-Matrix hat, kann man die I2C-Signale auf unterschiedliche Pins
> mappen. Aber dass die I2C in SW gemacht wird, ist wohl ein Irrtum.

soweit es den ESP32 und das IDF betrifft, alles richtig.
Ob es die Arduino HAL inzwischen komplett macht, müßte ich nachschauen.

Nicht alles, was die Hardware kann, ist dort bereits komplett eingebaut, 
außerdem ändert sich das IDF noch sehr häufig. BT und I2S wurde in 
letzter Zeit noch ziemlich viel umgenaut, deshalb ist auch BT in der 
ArduinoIDE noch relativ spartanisch.

Mach mal aus dem ESP32 in der ArduinoIDE einen BT-Lautsprecher ohne 
direkt die IDF-Funktionen zu bemühen...

Gruß aus Berlin
Michael

Michael U. schrieb:
> Nicht alles, was die Hardware kann, ist dort bereits komplett eingebaut

Mag sein dass nichtmal I2C in HW genutzt wird.  BT habe ich schon 
mitbekommen. Die Arduino-Jungs kommen mit der Entwicklung der HW nicht 
hinterher ;)

Doch die i2c HW wird von Arduino schon genutzt

Hallo,

na dann viel Spaß damit...
Steht im Moment auf AP-Mode.
Für STA-Mode in Zeile 50 EXAMPLE_ESP_WIFI_MODE_AP TRUE auf FALSE setzen,
in Zeile 51 und 52 müssen dann die Zugangsdaten Deines WLAN rein.
Die IP mußt Du in diesem Fall in Deinem Router oder mit einem 
Netzwerkscanner rausfinden oder in den Debug-Kram die Ausgabe der IP 
einbauen und wifi-Debug auf INFO setzen (Zeile 88).

In Zeile 121 ist zur Zeit .xclk_freq_hz = 8000000, gesetzt, Original 
sind es 20MHz. Damit laufen aber meine M5Stack Cam und auch das 
OV2640-Modul am ESP32 nicht wirklich stabil, auch mit passenden PullUp 
am SCCB. Damit laufen zwar die 20MHz ohne Absturz, es gibt aber immer 
wieder mal Schrottbilder.

Passiert genauso mit der Original_Software zumindest bei meinen M5Stack 
Cam Modulen. Beim OV2640-Modul am ESP32 liegt es den zu langen 
Verbindungsleitungen.

Den Viewer hatte ich hier schonmal auf den Odroid Go geworfen, aber da 
ich da garkeine stabil laufende Cam hatt, nicht weitergemacht. Mal 
schauen, wann ich dazu Lust und Zeit habe.

Gruß aus Berlin
Michael

Hallo,

Marc schrieb:
> Ich hab's grad mal ausprobiert, leider tut es nicht viel. Ich hab nur
> die SSID und das Passwort konfiguriert und angenommen, es startet als
> Access-Point.

ich mußte das mal mangels Sachkkenntnis an meinen Bekannten weiter 
delegieren. Er hatte den AP nicht mehr getestet weil ich ja sowieso 
unbedingt den STA Mode haben wollte um sie in mein WLAN zu bekommen.
Ein Fehler ist, das true und false nur in Kleinschreibung akzeptiert 
werden..

ok, ich wußte ja, das er schell ist...
Die reparierte .ino hängt dran, die Version IDF aus dem 
Arduino-ESP32-Paket passt nicht zum cam-Demo.

Marc schrieb:
> Die M5Stacks sind ja relativ teuer. Vielleicht könnte man ein kleines
> Open-Source-Projekt starten, bei dem man einfach ein ESP32 Modul mit
> einem Display, 3 Tasten und Batterie in ein 3D-Druck Gehäuse baut.

Ich habe sowieso keinen M5Stack, ich habe gestern noch die Viewer-Source 
auf meinen ESP32 mit 4" Diplay geworfen, seine Zeigerberechung hat mir 
Rätsel aufgegen, habe ich lieber zum Testen erstmal selber gemacht, es 
gehen z.Z. nur jpg-Einzelbilder.
Ich werde es mal auf den Odroid Go werfen. Hauptproblem für mich ist im 
Moment, daß meine JPEG-Decoder/TFT-Treiber Kombi nicht scaliert, auf dem 
4" 480x320 werden die 640x480 der Kamera eben einfach beschnitten.
Die Kamera habe ich gestern noch nicht zuverlässig auf 320x240 bekommen.
Sketch hänge ich mal an und ein Bild damit.
Das Bild ist nur ein schnelles Foto aus der Bastelecke vom Display, die 
Kamera hängt nur rum und schaut irgendwohin...

Gruß aus Berlin
Michael

Hallo,

Marc schrieb:
> Erst ging die Kamera immer in den Reset, bis ich schließlich
> herausgefunden habe, dass sie das bei weniger als 8 Zeichen Passwort
> macht.

Ist irgendwo eine Beschränkung im IDF. Leeres Passwort oder mindestens 8 
Zeichen geht.

Wenn Du den echten M5Stack hast, sollte ja eigentlich die Source aus dem 
Link
https://github.com/moononournation/M5Stack-Cam-Viewer
direkt laufen.

Ich habe es ja auf einem ESP32-Modul mit Display dran benutze die 
TFT_eSPI-Lib dazu. Sollte auch mit dem M5Stack selbst laufen, er hat in 
der seiner User_Setup.h zumindest einen Eintrag für die Belegung beim 
M5Stack Modul.

Kann ich hier aber mangels M5Stack nicht testen.

Gruß aus Berlin
Michael