helfen die I2C zum laufen zu bringen?
Hallo Forum,
ich verwende zur Zeit das STM32 Nucleo-64 mit einem F446RE.
Die Pins D14/D15 für SDA und SCL habe ich versucht mit PullUp hoch zu
ziehen, jedoch schaffe ich es nichteinmal mit dem I2C-Scanner ein OLED
abzufragen.
Als IDE nutze ich Arduino mit dem passenden Boardverwalter.
Gegentest mit einem ESP32 hingegen läuft.
Gibt es beim STM etwas zu beachten? Ich weis auch leider nicht mit
welcher Geschwindigkeit der I2C läuft. Der STM selbst ist auf 180MHz
getaktet.
Als Lib verwende ich die "Wire.h" (Arduino eigene). Als I2C-Scanner den
hier:
https://gist.github.com/tfeldmann/5411375
Wie gesagt, beim ESP32 (auch UNO) läuft der Scanner. Nicht jedoch beim
STM.
Was überrsehe ich da?
Grüße
Hast du die Pull Ups extern angehängt oder die Internen verwendet?
Du kannst auch mal probieren niedrigere Pull Ups zu verwenden, wenn die
Frequenz recht hoch ist geht es mit zu großen nicht mehr.
Hast du auch evtl. einen Logic Analyser oder Oszilloskop damit du
nachsehen könntest wie hoch die Frequenz ist? Wäre auch gut um zu sehen
ob überhaupt was raus kommt.
Hi Alex,
ich habe verschiedene größen an R versucht! Momentan nutze ich vom OLED
den internen 4k7 und am Melexis habe ich 1k.
Mein momentanes Problem ist, das ich z.B. das OLED mit dem 1306 per
I2C-Scanner nicht abfragen kann, aber beschreiben (egal ob an 3V3 oder
5V / hat einen Regler onboard). Also das Display lässt sich ansteuern.
Am selben BUS hingegen hängt ein Melexis MLX90640. Den kann ich gar
nicht abfragen.
Bei I2C-Scanner kommt das er von 128 ca 60 Adressen findet. Mal mehr mal
weniger. Am ESP funktioniert das ganze (beide) einwandfrei.
Beispiel:
1
Scanning...
2
I2C device found at address 0x03 !
3
I2C device found at address 0x05 !
4
I2C device found at address 0x09 !
5
I2C device found at address 0x0A !
6
I2C device found at address 0x10 !
7
I2C device found at address 0x11 !
8
I2C device found at address 0x14 !
9
I2C device found at address 0x16 !
10
I2C device found at address 0x1F !
11
I2C device found at address 0x21 !
12
I2C device found at address 0x22 !
13
I2C device found at address 0x23 !
14
I2C device found at address 0x25 !
15
I2C device found at address 0x28 !
16
... (gekürzt)
17
done
Interne PullUps habe ich nicht aktiv. Eventuell macht das die Lib vom
Display.
Verwende Adafruit_SSD1306, Adafruit_GFX, SPI, Wire(.h) zum Test des
OLEDs
Alex D. schrieb:> Hast du auch evtl. einen Logic Analyser oder Oszilloskop damit du> nachsehen könntest wie hoch die Frequenz ist? Wäre auch gut um zu sehen> ob überhaupt was raus kommt.
Sorry übersehen!
Ja, das habe ich schon gemacht. Momentan fahre ich 400kHz. Auch die
Flanken sehen sauber aus am Scope. Ich habe den verdacht dass die Module
bei Low die Spannung nicht tief genug ziehen und so der I2C-Eingang ein
High erkennt.
leider bin ich beim STM32 ein netter Frischling und mir fehlt die
Vorstellungskraft hinter den Fehler zu kommen. Beim AVR kenn ich das
Problem nicht. Ok, der ist mit 20MHz auch 8 mal langsamer.
Marc ..
versuch es mal mit 100kHz.
Ich hab einen SSD1306 per DMA zyklisch befüllt. Bei 400kHz hat sich der
SSD recht schnell weggehängt. Mit 350kHz läuft es soweit stabil. 400kHz
scheinen ziemlich an der Grenze zu sein. Zumindest mit den paar Modulen
mit denen ich es probiert habe.
Marc Horby schrieb:> Ich habe den verdacht dass die Module> bei Low die Spannung nicht tief genug ziehen und so der I2C-Eingang ein> High erkennt.
Wie sieht denn das Oszilloskopbild dazu aus? Zeige mal!
Rene B. schrieb:> Mit 350kHz läuft es soweit stabil. 400kHz> scheinen ziemlich an der Grenze zu sein. Zumindest mit den paar Modulen> mit denen ich es probiert habe.
Bei meinen auch.
Rene B. schrieb:> 400kHz> scheinen ziemlich an der Grenze zu sein. Zumindest mit den paar Modulen> mit denen ich es probiert habe.
kann ich nicht bestätigen, an meinen LPC824 laufen die SSD1306
problemlos mit 1 MHz. PullUp ist 2k2.
Rene B. schrieb:> versuch es mal mit 100kHz.> Ich hab einen SSD1306 per DMA zyklisch befüllt. Bei 400kHz hat sich der> SSD recht schnell weggehängt.
Also um es nochmal zu sagen:
Ein OLED kann ich vom STM32 ansteuern!
Aber nicht per I2C_Scanner erkennen.
Ich kann es mit 1MHz ansteuern. Lesen mit 100kHz schlägt fehl. Beim AVR
und ESP klappt es.
Stefanus F. schrieb:> Wie sieht denn das Oszilloskopbild dazu aus? Zeige mal!
Siehe BMP. Die Spikes kommen vom falsch justierten Tastkopf. Die Habe
ich auch am Signalgenerator am Scope.
da das Nucleo-Board ja bei anderen funktioniert, denke ich dass es am
Code liegt. Muss ich noch irgendetwas zusätzlich initatialisieren?
Signalform und Pegel sehen fast perfekt aus, daran kann es schonmal
nicht liegen.
> Ein OLED kann ich vom STM32 ansteuern!> Aber nicht per I2C_Scanner erkennen.
Dann taugt wohl der Scanner nichts, würde ich mal sagen.
Stefanus F. schrieb:> Dann taugt wohl der Scanner nichts, würde ich mal sagen.
Ich habe mehrere durchprobiert! Auch das Programm für den MLX erkennt
den Sensor nicht. Nur beim AVR und ESP klappt es.
Zudem ist am Scanner nicht viel drann was nicht klappen könnte.
Im Anhang die .ino
Villeicht kannst du/ihr bitte mal auf euren Nucelo testen und berichten
was ich falsch mache.
An welche Pins hast du das Display angeschlossen? Ist es noch D14/D15
(=PB9/PB8, =I2C1_SDA/I2C1_SCL)?
Hast du dich vergewissert, dass diese mit der Standardvorgabe deiner
Wire Klasse überein stimmen? Schau im Zweifelsfall in dessen Quelltext.
Welches Arduino Plugin nutzt du denn für deinen Mikrocontroller? Bitte
mit Link zur Github-Seite. Ich frage, weil es nicht die Arduino eigene
Wire.h sein kann, denn die ist nur für AVR Mikrocontroller. Und für
STM32F4 gibt es mindestens zwei unterschiedliche Plugins.
Bei der hier:
https://github.com/mubase/STM32F4-Arduino-core/blob/master/Libraries/Wire/Wire.h
Sind es standardmäßig die Pins 25/22 !
Stefanus F. schrieb:> Ist es noch D14/D15> (=PB9/PB8, =I2C1_SDA/I2C1_SCL)?
Ja. Wenn ich den Scanner laufen lasse, wackeln die Pins.
Stefanus F. schrieb:> Hast du dich vergewissert, dass diese mit der Standardvorgabe deiner> Wire Klasse überein stimmen?
Ich habe mal reingeschaut und für mich sah es so aus als würde es
passen!
Stefanus F. schrieb:> Welches Arduino Plugin nutzt du denn für deinen Mikrocontroller? Bitte> mit Link zur Github-Seite.
Habe das benutzt:
https://github.com/stm32duino/wiki/wiki/Getting-Started
Und dabei "STM32 Cores by ST-Microelectronics Version 1.3.0"
installiert.
Rene B. schrieb:> Marc ..>> versuch es mal mit 100kHz.> Ich hab einen SSD1306 per DMA zyklisch befüllt. Bei 400kHz hat sich der> SSD recht schnell weggehängt. Mit 350kHz läuft es soweit stabil. 400kHz> scheinen ziemlich an der Grenze zu sein. Zumindest mit den paar Modulen> mit denen ich es probiert habe.
Kann ich so nicht bestätigen.
Ich hab das letztens mit 1 MHz getestet, und das lief weiter stabil.
(auch mit DMA)
Das Maximum hab ich nicht getestet, aber da scheint noch mehr möglich zu
sein.
Ich vermute, daß die max.-Frequenz mit der des SPI-Mode identisch ist.
Wobei ich korrigieren muss: im der Wire.h steht nicht 25/22 sondern
nichts. daher gehe ich davon aus dass die D14/D15 verwendet werden. ich
kann die auch so direkt anschreiben und togglen.
Besorge mal den Quelltext von der Funktion i2c_custom_init().
Und finde heraus, welche Zahlenwerte die Konstanten SDA und SCL haben.
Am einfachsten geht das mit einer anständigen IDE, da kannst mit
Strg-Klick auf die gesuchten Wörter klicken.
Ich habe hier eine Anleitung, wie man Netbeans oder QT Creator für
Arduino ESP8266 verwendet. Das kannst du mit deinem STM32 prinzipiell
genau so machen. Die Pfade sind dann natürlich anders:
http://stefanfrings.de/esp8266/index.html#otheride
Ich glaube ich habe des Rätsels Lösung: Deine ino ist nicht zu dieser
Library kompatibel. Versuche es mal mit der von mubase
(https://github.com/mubase/STM32F4-Arduino-core/)
In der deiner ino werden diese beiden Befehle für jede Adresse
wiederholt:
1
Wire.beginTransmission(address);
2
error=Wire.endTransmission();
Und jetzt schauen wir mal in die Quelltexte der Methoden:
1
voidTwoWire::beginTransmission(uint8_taddress)
2
{
3
// indicate that we are transmitting
4
transmitting=1;
5
// set address of targeted slave
6
txAddress=address<<1;
7
// reset tx buffer iterator vars
8
txBufferIndex=0;
9
txBufferLength=0;
10
}
Da werden nur ein paar Variablen gesetzt. Hier findet noch keine I²C
Kommunikation statt. Weiter geht's:
Stefanus F. schrieb:> Demnach müsste dein Scanner immer einen Fehler melden. Warum er sich> anders verhält, sehe ich gerade nicht.
Moment!
Beim STM32 macht er ja irgendwas! Ich bekomme über 100 Adressen wenn ich
scanne. Nur beim AVR und ESP funktioniert es. Bedeutet durch den Switch
auf STM32 nimmt er eine .h die gar nicht (richtig) funktioniert.
Zumindest lesetechnisch. beim Schreiben scheint es zu klappen, da ich
das OLED ja anschreiben kann. Ob die Lib auch das OLED liest, weis ich
nicht.
Ich kann auch nicht sehen ob die Sensoren richtig initialisiert werden.
Es scheint so, weil wenn ich das Scope an SCL oder SDA hänge klappert es
ja. Nur das Lesen vom BUS scheint nicht zu gehen. Wenn die Lib da
natürlich schrott macht, wundert es mich nicht.
Marc Horby schrieb:>> Demnach müsste dein Scanner immer einen Fehler melden. Warum er sich>> anders verhält, sehe ich gerade nicht.
Das war ein Trugschluss, habe ich inzwischen korrigiert.
Besorge mal die Quelltexte von i2c_custom_init() und i2c_master_write().
Ist Dir aufgefallen, dass deine Library zuletzt im Jahr 2012 geändert
wurde?
Stefanus F. schrieb:> Ist Dir aufgefallen, dass deine Library zuletzt im Jahr 2012 geändert> wurde?
der Kampf der cores... Das ist der 'offizielle' STM core der alt ist vs.
libMaple core der besser gepflegt aber weniger boards unterstützt.
Der return code von i2c_master_write() ist etwas anders für Fehler, aber
0 = OK und nur die werden in dem o.g. scanner gezählt. Das wäre ok wenn
die Funktion richtig arbeitet.
Ok, damit sind wir einen Schritt weiter. Die Initialisierung sieht auf
den ersten Blick ok aus.
Beim Senden wird die Funktion HAL_I2C_Master_Transmit_IT() aufgerufen.
Die tut scheinbar nicht das, was sie soll.
Hier ist die Doku dazu:
https://www.st.com/content/ccc/resource/technical/document/user_manual/2f/71/ba/b8/75/54/47/cf/DM00105879.pdf/files/DM00105879.pdf/jcr:content/translations/en.DM00105879.pdf
Die Beschreibung dazu auf Seite 452 ist nicht sehr aussagekräftig. Mich
würde interessieren, wie sie darauf reagiert, dass 0 Bytes gesendet
werden sollen und wie das Errorhandling funktioniert, was bei dem
Scanner ja ganz besonders wichtig ist.
Anstatt jetzt noch weiter in die HAL einzusteigen, würde ich Dir lieber
dazu raten, die Library von mubase zu versuchen. Die macht das I²C
Protokoll per Software (Bit-Banging), was für so einen Scanner auf jeden
Fall zuverlässiger funktionieren dürfte.
Wenn ich mir die Errata
(https://www.st.com/content/ccc/resource/technical/document/errata_sheet/c3/6b/f8/32/fc/01/48/6e/DM00155929.pdf/files/DM00155929.pdf/jcr:content/translations/en.DM00155929.pdf)
zu I²C auf diesem Chip anschaue, wird mir Angst und Bange. Da stehen
einige Probleme drin, aber ob die nun deinen Scanner stören kann ich
nicht einschätzen.
Dazu müsste ich auch noch den Quelltext der HAL lesen. Das mache ich
nicht. Ich finde die Idee, das Arduino Framework auf das HAL Framework
auszusetzen ohnehin bescheuert. Da kann man gleich alles selbst
programmieren, auf Basis des Referenzhandbuches. Dann funktioniert es
auch so wie man es will. Und wenn nicht, hat man wenigstens einen Plan
von den Abläufen.
Ach Scheiße, ich sehe gerade, dass die von mir empfohlene Arduino
Erweiterung nur den STM32F407 unterstützt. Dumm gelaufen. Jetzt bin ich
mit meinem Latein am Ende.
habe gerade mal ein i2c scan in mein aktuelles mbed Projekt mit einem
STM32F407VE reingepappt, läuft auf Anhieb, SSD1306 wird an 0x78
gefunden.
1
intmain(){
2
I2Ci2c(PB_11,PB_10);// sda, scl
3
4
printf("starting i2c scanner...\n");
5
6
for(intaddr=0;addr<256;addr+=2){
7
chardummy[4];
8
9
intrc=i2c.read(addr,&dummy[0],0);
10
if(rc==0){
11
printf("device found at %x\n",addr);
12
}
13
}
14
15
printf("i2c scanner finished.\n");
16
}
Das Nucleo ist mbed-enabled, also geht das sehr einfach:
https://github.com/ARMmbed/mbed-os-example-blinky
kompilieren für das Nucleo mit 'mbed compile -m NUCLEO_F446RE -t
gcc_arm'
dann das .bin aus dem Build Verzeichnis auf das Board kopieren.
Guten Abend und danke Stefanus,
ich habe "versucht" das DB von ST durchzulesen, aber bei über 1800
Seiten habe ich ganz zu Anfang schon den Mut verlohren.
Frage zu mbed:
Wie lade ich die benötigten libs? Kann ich die einfach 1:1 kopieren und
in ein passendes Verzeichniss legen, oder muss ich bei denen was
beachten?
Zudem habe ich nach der mbed-IDE gesucht. Bei der Bildersuche sehe ich
zwar eine IDE, aber ich finde die nicht den installer. Zugegeben, ich
bin gerade von Arduino verwöhnt. Eine .json wäre natürlich nett.
kannst du deine wire.h und .c mal bitte hochladen? eventuell die
abhängigkeiten? Ich vermute eine twi muss auch noch sein.
Marc Horby schrieb:> Frage zu mbed:> Wie lade ich die benötigten libs?
I2C und die ganzen HW Basisklassen sind im mbed-os enthalten, dafür
braucht man keine libs.
> Bei der Bildersuche sehe ich> zwar eine IDE, aber ich finde die nicht den installer.
Eine eigene IDE gibt es (noch) nicht. mbed-cli ist erstmal eine
Kommandozeilenversion, die mbed tools sind Python Programme die
vereinfacht mit 'mbed ...' aufgerufen werden.
Um eine 'Lib' hinzuzufügen wird einfach das Quellcodeverzeichnis in das
Projekt kopiert, man kann einen Ordner 'Lib' anlegen und darunter
weitere. 'mbed compile' durchsucht die Verzeichnisse im Projekt nach
Quellcodes und kompiliert dann alles. Um Includepfade braucht man sich
nicht zu kümmern, die werden auch automatisch übergeben.
Also eigentlich auch sehr einfach, nur Kommandozeile und eigener
Lieblingseditor. Alternativ kann man Projekte für eine IDE exportieren.
Für STM ist bisher nur Eclipse mit dem gnuarmeclipse Plugin brauchbar.
Es rufen aber immer mehr User nach Atollic weil das jetzt ja auch STM
ist.
Was mittlerweile noch geht ist plattformio, das ist eine IDE die sich
den Arduino oder mbed Code krallt und auch irgendwie funktioniert.
Wenn das o.g. example-blinky aus dem git geholt wird sind das erstmal
nur ein paar Bytes. mbed-os ist als Link drin und mbed compile sieht das
es noch nicht im Projekt vorhanden ist und lädt es dann. Da das für alle
Targets ist sind das einige MB und es dauert etwas.
Also das mit mbed war mir jetzt zu kompliziert! Ich habs nicht zum
laufen bekommen und auch sonst swierigkeiten gehabt das Ding auf die
Platte zu bekommen. ein compile hat nicht funktioniert. Ich denke, um
die Umgebung zu nutzen, bedarf es bei mir grundlegende Kenntnisse. Ich
war schon froh wenn ich die Aruino-Umgebung auf dem STM32 zum laufen
bekam. Daher würde ich gerne diese weiter nutzen!
nun zum I2C:
wer kann mir tipps geben welche Dateien ich herunterladen muss (dessen
I2C-Routinen funktionieren) um die Schnittstelle zum laurfen zu
bekommen?
Kann doch nicht sein, dass ich wegen einer Schnittstelle eine neue
Umgebung einrichten muss? Ich werde mich zusätzlich bei stm32duino
registrieren, aber da die blöde frage nach der LED ich nicht beantworten
kann, bekomme ich keine freischaltung (habe kein UNO bei dem ich die LED
nachsehen könnte).
Marc Horby schrieb:> Also das mit mbed war mir jetzt zu kompliziert! Ich habs nicht zum> laufen bekommen
Schade, so kompliziert ist das nicht. Hat die mbed-cli Installation
geklappt? Welche Fehlermeldung gab es beim kompilieren?
Marc Horby schrieb:> aber da die blöde frage nach der LED ich nicht beantworten kann
Hmm, du hast doch Arduino installiert? Vielleicht einfach mal das Blinky
für den Uno ansehen?
Wenn das alles schon kompliziert ist wird die F4 Programmierung aber ein
ziemlich dickes Brett zu bohren.
>Ich werde mich zusätzlich bei stm32duino>registrieren, aber da die blöde frage nach der LED ich nicht beantworten>kann, bekomme ich keine freischaltung (habe kein UNO bei dem ich die LED>nachsehen könnte).
Was für eine Frage nach der LED? Meinst Du den Pin? Der ist
üblicherweise 13 am UNO.
BTW: welchen Arduino Core nutzt Du denn jetzt letztendlich?
Wenn du Dich mit den Registern und dem Reference Manual
auseinandersetzen würdest, könntest du die I²C Schnittstelle völlig
unabhängig vom Framework programmieren.
Dann könntest du auch munter zwischen SPL, HAL, Arduino und Mbed hin und
her wechseln, ohne deinen Code großartig ändern zu müssen.
Ich kann Dir dazu leider kein konkretes Beispiel geben, weil ich die I²C
Schnittstelle dieses Controllers auch noch nicht selbst "zu Fuß"
programmiert habe. Bin da selbst noch im Anfänger-Stadium.
Ich habe allerdings einiges an Erfahrung mit I²C auf diversen 8bit
Mikrocontrollern. Und die sind eher durchwachsen. Letztendlich habe ich
häufig auf reine Software-Routinen mit Bit-Banging gesetzt, wenn ich
ungeduldig wurde, denn das funktioniert immer problemlos.
(Hat Lego übrigens auch so gemacht).
Du kannst gerne von meinem bewährten Code abgucken. Unter
http://stefanfrings.de/esp8266/WIFI-Kit-8-Test2.zip findest du ein
Arduino Programm, welches auf dem OLED Display des Wifi-Kit 8 Boardes
(http://stefanfrings.de/esp8266/index.html#wifikit8) eine kleine
Text+Grafik Demo ablaufen lässt.
Der I²C Code in diesem Beispielprogramm ist leicht zu extrahieren und an
andere Umgebungen anpassbar. Das ist zwar nicht das, wonach Du gesucht
hast, aber immerhin funktioniert es ganz sicher. Als Plan B wäre das
vielleicht doch eine akzeptable Option für Dich.
Nachtrag: Wie ich sehe, hat Markus inzwischen auch in diese Richtung
gedacht.
Marcus schrieb:> BTW: vielleicht geht eine Soft-I2C ?>> https://github.com/todbot/SoftI2CMaster
Da fehlt die util/delay.h
die bekomme ich so nicht zum laufen! keine Ahnung welche lib ich da
nehmen muss.
Stefanus F. schrieb:> Du kannst gerne von meinem bewährten Code abgucken. Unter> http://stefanfrings.de/esp8266/WIFI-Kit-8-Test2.zip findest du ein> Arduino Programm, welches auf dem OLED Display des Wifi-Kit 8 Boardes> (http://stefanfrings.de/esp8266/index.html#wifikit8) eine kleine> Text+Grafik Demo ablaufen lässt.
Das kann ich mal versuchen! Danke! Bedenke bitte, das die Adafruit-Lib
zum scheiben auf das Display auch funktioniert. nur das lesen nicht.
Irgendwetwas extrahieren und anderweitig aus den libs zu verwenden tue
ich mir extrem schwer. ich versteh meistens gar nicht was da drinn
passiert.
Marc Horby schrieb:> Bedenke bitte, das die Adafruit-Lib zum scheiben auf das Display auch> funktioniert. nur das lesen nicht.
Das geht nicht weil das Display das in den seriellen Modi nicht
unterstützt.
Johannes S. schrieb:> Das geht nicht weil das Display das in den seriellen Modi nicht> unterstützt.
Wieso sehe ich dann bei einem z.B. Mega2560 das Display mit (ich glaube)
0x78 und den Sensor mit 0x33?
Das hat nichts mit lesen zu tun, dann war das falsch beschrieben.
Beim I2C Scan wird eine Adresse auf den Bus geschickt und geprüft ob ein
Ack oder Nack zurück kommt. Da scheint deine Lib/Core was falsch zu
machen.
Johannes S. schrieb:> Das hat nichts mit lesen zu tun, dann war das falsch beschrieben.> Beim I2C Scan wird eine Adresse auf den Bus geschickt und geprüft ob ein> Ack oder Nack zurück kommt. Da scheint deine Lib/Core was falsch zu> machen.
Soweit war Stefanus schon! Ich werde mal sein beispiel ansehen und
versuchen es zurecht zu basteln
Marc Horby schrieb:> Da fehlt die util/delay.h die bekomme ich so nicht zum laufen!
Die gibt es beim arm-gcc auch nicht. Arduino hat aber schon eine delay
Funktion, die du stattdessen verwenden kannst. Oder so:
1
// delay loop for 8Mhz CPU clock
2
voiddelay(uint16_tmsec)
3
{
4
for(uint32_tj=0;j<2000*msec;j++)
5
{
6
__NOP();
7
}
8
}
Musst du eventuell an deine Taktfrequenz anpassen.
Ich habe übrigens doch schon einen einfaches Code-Beispiel für I²C,
allerdings ist das für den STM32F1.
http://stefanfrings.de/stm32/index.html#i2c
Ob das bei Dir so 1:1 übernommen werden kann, weiß ich nicht. Du kannst
ja mal die Registerzugriffe mit deinem Reference Manual vergleichen.
Wenn meine Beschreibungen mit deinem µC übereinstimmen, dann wird es
wahrscheinlich funktionieren.
> Irgendwetwas extrahieren und anderweitig aus den libs zu> verwenden tue ich mir extrem schwer. ich versteh meistens> gar nicht was da drin passiert.
Ok, dann brauchst du wohl noch etwas mehr Erfahrung. Das wird mit der
Zeit kommen. Ich schlage vor, dass du deinen STM boliden erstmal ein
wenig zur Seite legst und mit den kleineren AVR Mikrocontrollern die
Grundlagen der Programmiersprache C und den Umgang mit dem gcc Compiler
lernst lernst.
Anleitung dazu: http://stefanfrings.de/mikrocontroller_buch/index.html
Danach schaust du Dir die STM32F1 an, die sind noch leichter
überschaubar, als deiner. Entsprechende Module kosten nur 2€ und das
damit gelernte kannst du später auf die größeren STM32 Modelle
übertragen, so dass dies eine gute Investition und keine
Zeitverschwendung wäre.
Boards:
https://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20180928223049&SearchText=STM32F103C8T6+board
Anleitung dazu: http://stefanfrings.de/mikrocontroller_buch2/index.html
Nachdem du diese Anleitungen durchgearbeitet hast, wirst du sehr
wahrscheinlich imstande sein, fremde Codes zu zerlegen. Sollte sich
herausstellen, dass der Stoff für Dich zu komplex ist (dafür muss sich
niemand schämen), wäre für dich immer noch das Arduino Framework als
Rückzugsoption verfügbar.
Damit ist die Softwareentwicklung einfacher, man kann damit aber nicht
alle Features der µC nutzen. Was STM32 angeht, ist in Arduino die
Unterstützung der STM32F1 Serie am weitesten fortgeschritten. Deswegen
würde ich Dir empfehlen, Arduino nur mit STM32F1 zu verwenden. Von
Deinem Nucleo-64 könntest du den ST-Link Adapter abtrennen und mit
billigeren Boards aus Asien weiter verwenden. So wäre auch das kein
rausgeschmissenes Geld.
Du hast ja schon ein bisschen mit Arduino und vermutlich auch mit
anderen IDE's herum gespielt. Der Kern von Arduino ist eigentlich nicht
dessen lächerliche IDE, sondern dessen Hardware-Abstraktions-Layer
(Libraries). Wenn die auf Anhieb das tun, was du brauchst, wirst du mit
Arduino Spaß haben. Wenn sie aber nicht funktionieren, ist der typische
Arduino User völlig überfordert, es zu korrigieren oder selbst seine
eigene Library neu zu programmieren.
Das meine ich nicht bösartig. Ich fahre zu Beispiel ein Auto obwohl ich
nur rudimentär die Grundlagen davon verstehe. Wenn mein Auto nicht
funktioniert oder für eine Aufgabe ungeeignet ist, kann ich es auch
nicht selbst ändern. Entweder lasse ich das von einem bezahlten Fachmann
erledigen oder kaufe ein anderes fertiges Auto, das meinen Anforderungen
entspricht.
Die Grundidee von Arduino besteht darin, fertige Hardware- und
Softwarebausteine bereit zu stellen, die der Anwender nur zusammen
stöpselt, um daraus etwas tolles zu basteln.
Wer hingegen tiefer in die Materie einsteigen will (z.B. Libraries
selbst entwickeln), der ist mit einer klassischen IDE (wie die beiden
auf Eclipse basierten SW4STM32 und Atollic TrueStudio) besser bedient.
Dann sollte man aber auch nicht vor 1800 Seiten Doku zurück schrecken.
Wer eigene Libraries für Hardware schreibt, kommt nicht umhin, sich mit
Registern Flags und inneren Strukturen der verwenden Mikrochips zu
beschäftigen.
Und das (zumindest für den Anfang) die kleineren AVR deutlich zahmer.
Das Datenblatt des ATtiny13A umfasst zum Beispiel nur 180 Seiten.
Versuche mal, das anhand meiner oben genannten Anleitungen zu erlernen.
Ich denke dann merkst du relativ schnell, ob das was für Dich ist, oder
ob du doch lieber den Arduino Baukasten verwendest.
Man kann mbed auch erstmal mit der Online-IDE testen. Die ist definitiv
nicht schlechter als die Arduino-IDE für den Desktop. Das kompilierte
Binary schiebt man dann zum programmieren einfach per drag'n'drop auf
das Nucleo.
Hallo Marc,
jetzt musst Du noch die Auflösung des Rätsels liefern.
Wenn ich es richtig sehe, ist es ein Fehler in der im Core von STM
selbst ( ich nehme stark an, Du verwendest diesen ).
Dafür gibt es wohl einen Patch im nächsten Release von STM.
Marcus schrieb:> Wenn ich es richtig sehe, ist es ein Fehler in der im Core von STM
Der Arduino Core sah soweit gut aus. Ich vermute eher einen Bug in der
darunter liegenden HAL. Das Problem scheint dadurch ausgelöst zu werden,
dass sein Sketch nach der Slave Adresse keine weiteren Daten senden
will.
Stefanus F. schrieb:> Marcus schrieb:>> Wenn ich es richtig sehe, ist es ein Fehler in der im Core von STM>> Der Arduino Core sah soweit gut aus. Ich vermute eher einen Bug in der> darunter liegenden HAL. Das Problem scheint dadurch ausgelöst zu werden,> dass sein Sketch nach der Slave Adresse keine weiteren Daten senden> will.
Hallo Stefanus,
du hattest tatsächlich Recht mit dem Bug! Ich habe mich auf stm32duino
regisriert und dank deier Info das es D13 sei, auch gleich eine
Freischaltung bekommen.
Hier wurde man mich weitergeleitet:
https://www.stm32duino.com/viewtopic.php?f=29&t=4175
Und ja, es ist ein Bug.
https://github.com/stm32duino/Arduino_Core_STM32/pull/301
Dieser Bug verhindert aber auch das ich den MLX auslesen kann. Ist also
nicht auf den Scanner begrenzt.
Jetzt muss ich nur erfahren wie ich den umgehen kann. Also ob es ein
Workarround gibt! Ich möchte unbeding den Sensor auf einem STM32 zum
laufen bekommen, weil dieser schneller ist und die Berechnungen
schneller durchführt.
>Und ja, es ist ein Bug.>https://github.com/stm32duino/Arduino_Core_STM32/pull/301
Also aus den Kommentaren werde ich nicht ganz schlau. Das "issue" ist ja
"closed" also sollte der Fehler gefixed sein.
Das Problem könnte darin bestehen, dass die ganzen Korrekturen erst ins
nächste Release gehen.
Dann gibt es also zwei Möglichkeiten: Entweder auf das Release warten
oder das aktuelle Github-Repo selbst auf die Platte kopieren.
Marcus schrieb:> Also aus den Kommentaren werde ich nicht ganz schlau. Das "issue" ist ja> "closed" also sollte der Fehler gefixed sein.> Das Problem könnte darin bestehen, dass die ganzen Korrekturen erst ins> nächste Release gehen.> Dann gibt es also zwei Möglichkeiten: Entweder auf das Release warten> oder das aktuelle Github-Repo selbst auf die Platte kopieren.
Genau,
das nächste Release soll den Fix enthalten!
Ich habe mir das Repo geladen und getestet! Jetzt finde ich den Sensor
und das Display. Sehr gut. Nur leider kann ich den Sensor noch immer
nicht lesen.
Also mit I2C-Scanner finde ich den Sensor mit 0x33 (das ist richtig) und
das Display mit 0x3C (das ist ein anderes Chinateil, adresse passt
aber).
Versuche ich den Sensor aber mit dem Code zu lesen:
https://github.com/sparkfun/SparkFun_MLX90640_Arduino_Example
klappt das nicht! Genau aber den Code verwende ich beim ESP8266 und
ESP32.
Für den Mega2560 ist der RAM zu klein, da kann ich nur den I2C_Scanner
testen.
Nun muss ich zusehen wie ich den Sensor dennoch zum Laufen bekomme.
Johannes S. schrieb:> das übliche I2C Adressen Problem?> Probiere malconst byte MLX90640_address = (0x33 << 1);
Das klappt leider nicht! Da erkennt er den Sensor gar nicht!
Was bedeutet das << 1? Was bewirkt es?
Ich bekomme vom Sensor/Code die Meldung :
Im Source steht noch die Meldung das er die Parameter nicht lesen kann.
Also:
status = MLX90640_DumpEE(MLX90640_address, eeMLX90640);
Da die Meldung nicht kommt, vermute ich dass dies klappt. Erst der
Versuch:
status = MLX90640_ExtractParameters(eeMLX90640, &mlx90640);
bringt bei:
if (status != 0)
Serial.println("Parameter extraction failed");
Also vermute ich, dass die erste Routine funktioniert, die zweite aber
probleme macht.
Marc Horby schrieb:> Jetzt muss ich nur erfahren wie ich den umgehen kann. Also ob es ein> Workarround gibt!
Niemand zwingt dich dazu, die Arduino Library oder die HAL zu benutzen.
Du kannst den I²C Anschluss durchaus auch "zu Fuß" programmieren,
entsprechend meinem Code-Beispiel.
> das übliche I2C Adressen Problem?
Sicher nicht. Zitat aus der Doku der Wire Klasse:
"The Wire library uses 7 bit addresses throughout. If you have a
datasheet or sample code that uses 8 bit address, you'll want to drop
the low bit (i.e. shift the value one bit to the right), yielding an
address between 0 and 127." (https://www.arduino.cc/en/Reference/Wire)
> Was bedeutet das << 1? Was bewirkt es?
Alle Bits werden um eine Position nach links geschoben.
Aus 33 (00110011) wird 66 (01100110). Man könnte auch sagen: Die Zahl
wird verdoppelt. Dadurch wird die Adresse verschoben um rechts Platz für
das R/W Bit zu schaffen. Siehe
https://www.totalphase.com/support/articles/200349176-7-bit-8-bit-and-10-bit-I2C-Slave-Addressing
>Also vermute ich, dass die erste Routine funktioniert, die zweite aber>probleme macht.
Das muss nicht so sein. Im ersten Kommando werden die Daten vom MLX
gelesen, im zweiten interpretiert.
Wenn schon Müll gelesen wird, kann dieser auch nicht interpretiert
werden.
Mach mal ein Print der Rohdaten und Vergleiche sie mit dem ESP.
Marcus schrieb:> Übrigens ist der benötigte I2C Datenbuffer des MLX ziemlich groß:> uint16_t eeMLX90640[832];> aus> https://github.com/sparkfun/SparkFun_MLX90640_Ardu...
Bedeutet also dass ich den I2C-Puffer von 32 auf 832 ändern müsste?
Stefanus F. schrieb:> Du kannst den I²C Anschluss durchaus auch "zu Fuß" programmieren,> entsprechend meinem Code-Beispiel.
Ja, das hab ich schon geschafft! Ich musste nur die if (error == 0) zu
(error !=0) ändern, damit die Rückgabe funktionierte. Auch sehe ich mein
Sensor auf Adresse 0x33 :-)
1
for(address = 1; address < 127; address++ )
2
{
3
// The i2c_scanner uses the return value of
4
// the Write.endTransmisstion to see if
5
// a device did acknowledge to the address.
6
//Wire.beginTransmission(address);
7
8
i2c_start;
9
//Wire.beginTransmission(address);
10
// error = Wire.endTransmission();
11
error = i2c_send(address);
12
error = i2c_send(0x00); // command
13
i2c_stop();
14
if (error != 0)
15
{
16
Serial.print("I2C device found at address 0x");
17
if (address<16)
18
Serial.print("0");
19
Serial.print(address,HEX);
20
Serial.println(" !");
21
22
nDevices++;
23
}
Bei den Sparkfun-Beispielen ist es jedoch etwas aufwändiger aus dem
Wire.xy das i2c_xy zu machen (und zwar so dass es geht).
Das habe ich bisher noch nicht wirklich verstanden.
>Bedeutet also dass ich den I2C-Puffer von 32 auf 832 ändern müsste?
Nein, wenn Du genau hinschaust siehst Du uint16_t was 2 Bytes sind.
Du brauchst also mindestens 2x832.
Nimm mal 2048.
Marc Horby schrieb:>> Du kannst den I²C Anschluss durchaus auch "zu Fuß" programmieren,>> entsprechend meinem Code-Beispiel.> Ja, das hab ich schon geschafft!
Ich meinte eigentlich das Beispiel von
http://stefanfrings.de/stm32/index.html#i2c
nicht das Bit-Banging. Aber egal, Hauptsache es funktioniert.
Schaut euch mal die Errata an auf Seite 15!
"2.4 I2C peripheral limitations"
"
2.4.1 SMBus standard not fully supported
Description
The I2C peripheral is not fully compliant with the SMBus v2.0 standard
since It does not
support the capability to NACK an invalid byte/command.
Workarounds
A higher-level mechanism should be used to verify that a write operation
is being performed
correctly at the target device, such as:
1. Using the SMBAL pin if supported by the host
2. the alert response address (ARA) protocol
3. the Host notify protocol
"
"
2.4.2 Start cannot be generated after a misplaced Stop
Description
If a master generates a misplaced Stop on the bus (bus error) while the
microcontroller I2C
peripheral attempts to switch to Master mode by setting the START bit,
the Start condition is
not properly generated.
Workaround
In the I²C standard, it is allowed to send a Stop only at the end of the
full byte (8 bits +
acknowledge), so this scenario is not allowed. Other derived protocols
like CBUS allow it,
but they are not supported by the I²C peripheral.STM32F446xx silicon
limitations STM32F446xC/xE
16/30 DocID027362 Rev 2
A software workaround consists in asserting the software reset using the
SWRST bit in the
I2C_CR1 control register
"
Die Schnittstelle ist schon by Design gruselig, und dann kommt noch das
Errata dazu. Ich würde es niemandem Übel nehmen, wenn er Bit-Banging
bevorzugt.
Leider kann man dann aber auch nicht die I²C spezifische analoge
Filterung an den Pins nutzen. Für den Master ist sie nicht so wichtig,
aber für Slaves schon, damit sie Start, Stop und Takt sauber erkennen.
Interessannt wäre die Umschreibung der Wire.h, so dass man einfach diese
durch eine mit Soft-I2C (Bit-Banging) ersetzt, aber dennoch die Befehle
beibehält! Ich kann mir vorstellen daß nicht jeder seine Projekte von
Arduino-AVR auf STM quasi neu schreiben möchte! Eventuell könnte das
helfen die Problematik zu lösen?
Stefanus F. schrieb:> Nicht nötig, gibt es bereits (den Link hatte ich weiter oben schon> gepostet):>> https://github.com/mubase/STM32F4-Arduino-core/blo...>> Man kann das einfach verwenden oder kopieren.
Hallo Stefanus,
leider bekomme ich die Lib nicht zum laufen.
Ich habe sie ausgetauscht von
AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.3.0
zu:
AppData\Local\Arduino15\packages\STM32\hardware\stm32\STM32F4-Arduino-co
re-master
zuerst nur die Wire, dann kam die fehlermeldung mit "wirish.h" fehlt etc
Jetzt kommen nur noch Fehlermeldungen!
C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120\sketch\MLX90640_I2C_Driver.cpp: In function 'int MLX90640_I2CRead(uint8_t, unsigned int, unsigned int, uint16_t*)':
23
24
MLX90640_I2C_Driver.cpp:44:33: error: call of overloaded 'write(unsigned int)' is ambiguous
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:131:10: note: no known conversion for argument 1 from 'unsigned int' to 'char*'
55
56
MLX90640_I2C_Driver.cpp:45:35: error: call of overloaded 'write(unsigned int)' is ambiguous
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:131:10: note: no known conversion for argument 1 from 'unsigned int' to 'char*'
87
88
C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120\sketch\MLX90640_I2C_Driver.cpp: In function 'int MLX90640_I2CWrite(uint8_t, unsigned int, uint16_t)':
89
90
MLX90640_I2C_Driver.cpp:88:31: error: call of overloaded 'write(unsigned int)' is ambiguous
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:131:10: note: no known conversion for argument 1 from 'unsigned int' to 'char*'
121
122
MLX90640_I2C_Driver.cpp:89:33: error: call of overloaded 'write(unsigned int)' is ambiguous
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:131:10: note: no known conversion for argument 1 from 'unsigned int' to 'char*'
156
157
Bibliothek Wire in Version 1.0 im Ordner: C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire wird verwendet
158
exit status 1
159
call of overloaded 'write(unsigned int)' is ambiguous
Endschuldigung wenn ich mich für euch dumm anstelle, aber ich kann es
nicht besser wissen!
Stefanus F. schrieb:> Man tauscht ja auch nicht einzelne Dateien aus, sondern das> gesamte> Arduino Plugin am Stück.
Das habe ich auch gemacht, aber dann sind meine Nucleo-Boards weg.
Oder was müsste ich stattdessen nehmen?
Marc Horby schrieb:> Stefanus F. schrieb:>> Man tauscht ja auch nicht einzelne Dateien aus, sondern das>> gesamte>> Arduino Plugin am Stück.>> Das habe ich auch gemacht, aber dann sind meine Nucleo-Boards weg.> Oder was müsste ich stattdessen nehmen?
Dann musst du halt ein kompatibles Board aus der Liste der verfügbaren
wählen oder die Boards.txt in dem Plugin erweitern (was leider wiederum
voraussetzt, sich mit Datenblatt und Referenzhandbuch auseinander zu
setzen).
Lass es einfach, und wechsle auf ein anderes Board mit STM32F103. Damit
bist du im Arduino Umfeld sehr viel besser unterwegs.
Stefanus F. schrieb:> Lass es einfach, und wechsle auf ein anderes Board mit STM32F103. Damit> bist du im Arduino Umfeld sehr viel besser unterwegs.
Das habe ich mir auch schon überlegt, aber der STM32F103 hat laut DB nur
20kByte SRAM
Marc Horby schrieb:> Das habe ich mir auch schon überlegt, aber der STM32F103> hat laut DB nur 20kByte SRAM
Nein, es gibt welche mit viel mehr RAM:
https://www.st.com/en/microcontrollers/stm32f103.html?querycriteria=productId=LN1565
Aber pass vor dem kauf auf, dass das Arduino Plugin das Modell deiner
Wahl auch unterstützt.
Was stört dich an 20k Byte? Das ist doch schon relativ viel, verglichen
mit anderen Mikrocontrollern.
Oh je. Der Compiler sagt doch was ihm nicht passt: es gibt das I2C Write
mit 3 verschiedenen Signaturen und keine passt so richtig. Also muss man
sich den Aufruf im MLX Treiber ansehen und den Aufruf von Write zB mit
einem typecast passend machen.
Stefanus F. schrieb:> Dann musst du halt ein kompatibles Board aus der Liste der verfügbaren> wählen oder die Boards.txt in dem Plugin erweitern (was leider wiederum> voraussetzt, sich mit Datenblatt und Referenzhandbuch auseinander zu> setzen).
Könntest du mir bitte helfen? Ich weis nicht mal wo ich anfangen soll.
Marc Horby schrieb:> Könntest du mir bitte helfen?
Das möchte ich nicht, weil ich befürchte, dass dieses Thema eine
never-ending Story wird.
Suche einfach eine Kombination aus Hard- und Software, die funktioniert
oder programmiere es komplett selbst.
Arduino ist halt Plug and Pray by Design.
Zwei Vorschläge hätte ich noch:
1) wie Stefan schrieb ein anderes Board. Da kann ich das hier empfehlen:
https://de.aliexpress.com/item/Free-shipping-STM32F407VET6-development-board-Cortex-M4-STM32-minimum-system-learning-board-ARM-core-board/32618222721.html
Kostet zusammen mit Display <25€, das Display braucht nur aufgesteckt zu
werden und wird über FSMC sehr schnell angesteuert und du bekommst
mehrere Updates pro Sekunde in Farbe hin. Wird von dem Arduino libmaple
core unterstütz und der ist deutlich besser gepflegt als der STM32
generic. Das Board gibt es noch in Variante wo die Stiftleisten nicht
eingelötet sind, da kann man die Stifte nach unten zeigen lassen und
dann ist das besser für Gehäuseeinbau geeignet.
Einziger Nachteil: dauert 2-4 Wochen bis das Board aus China da ist.
Und während du auf das Board wartest probierst du schonmal
Variante 2: bei mbed.com registrieren und den Online Compiler nutzen. Es
gibt ein Stück Code für den MLX:
https://os.mbed.com/teams/STM-mbedorg-OSRAM-team/code/eye_r_eye-mlx90640_32x24-v_0_0-ticker/
Rechts oben kann man das in Online Compiler importieren. Dann im Online
Compiler ganz rechts oben die Platform auswählen, da kann man sein Board
hinzufügen. Dann kompilieren und du bekommst ein .bin file das auf das
Board kopiert wird. Das Programm gibt die Daten über die virtuelle
serielle Schnittstelle mit 230400 Baud aus und versteht ein paar
Kommandos.
Der Sensor ist jedenfalls interessant, wo hast du den bestellt?
das Board im STM32duino wiki:
http://wiki.stm32duino.com/index.php?title=STM32F407
Das mit dem F407VET6-Board wäre auch mein Vorschlag, wenn es denn
unbedingt Arduino sein muss. Das hat Ressourcen ohne Ende und ist nicht
wirklich teuer. Selbst aus DE ist es in der Bucht für ~15€ zu bekommen.
Die Unterstützung von Arduino durch den libmaple-Core ist wohl ganz
ordentlich (bei diesem Chip und dem F103). Genaueres erfährst du im
stm32duino-Forum
ich habe dann eine weitere Frage. Für mein Projekt oben möchte ich für
mein Display eine Parbpalette mit verscheidenen Falschfarben anlegen.
Momentan habe ich eine RGB-Palette für Graustufen.
Das funktioniert auch soweit. Ich würde aber gerne noch andere
Parbpaletten hernehmen, wie z.B. die bei Wärmebildkameras. Kann mir
jemand einen Tip geben, wie man an solch eine Palette kommt? Ich würde
nur ungern alle 256 Farben per Hand machen.
Stefanus F. schrieb:> Manche Sachen kann man mit Excel generieren.
Wie kann ich in Excel eine Farbpallette generieren? Zudem habe ich die
Palette noch gar nicht! Also wie soll ich das machen?
>ich habe dann eine weitere Frage.
Wie weit bist Du denn mit dem MLX90640 gekommen? Läuft der jetzt am
Nucleo?
Ich habe mir einen bestellt und versucht am M5StackFire zu benutzten,
weil es dort eine fertige Applikation gibt.
Aber der Chip scheint, was die I2C Übertragung angeht, ziemlich
empfindlich. Die Signale waren auf dem Oszi ziemlich rund und er hat
nicht richtig geantwortet.
Marc schrieb:> Wie weit bist Du denn mit dem MLX90640 gekommen? Läuft der jetzt am> Nucleo?
Nein, ich habe den ESP genommen und bastel da gerade an einem Display.
Das Bild in Grayscale kann ich bereits sauber anzeigen, hätte aber gerne
ein paar Falschfarbenpaletten wie sie die von z.B.: FLIR haben.
Marc schrieb:> Aber der Chip scheint, was die I2C Übertragung angeht, ziemlich> empfindlich. Die Signale waren auf dem Oszi ziemlich rund und er hat> nicht richtig geantwortet.
Aha, also ich nutze momentan 1k PullUp. Allerdings habe ich keine
Probleme mit dem Ansteuern, sondern mit dem Lesen! Ich bekomme nicht
einmal ein OLED über I2C gelesen. Ignoriere ich die Antworten und baller
stur die Kommandos, kann ich alles darstellen. Benutze ich hingegen eine
selbstgebastelte Lib, kann ich das Display und den Sensor lesen. Da ich
aber zu wenig Ahnung habe die Wire.h so umzuschreiben dass es geht, habe
ich einfach einen ESP genommen bei dem es klappt.
Marc Horby schrieb:> Kann mir> jemand einen Tip geben, wie man an solch eine Palette kommt? Ich würde> nur ungern alle 256 Farben per Hand machen.
Nimm doch z.B. Python. Bei Matplotlib hast du auch schon Farbpaletten
inklusive, siehe etwa hier:
https://matplotlib.org/tutorials/colors/colormaps.html
1
import numpy as np
2
import matplotlib as mpl
3
4
# Farbpalette von "viridis" als Liste von Listen
5
color_list = mpl.cm.get_cmap("viridis").colors
6
7
# color_list[0:3] # gibt die ersten drei RGB-Kombinationen aus
Alex W. schrieb:> Wenn du dich hier anmeldest, kann ich dir eine PN schreiben mit ein paar> Tips, wie man den MLX z.B. am Teensy 3.6 oder Nucleo zum Laufen bekommt!
So?
Marc H. schrieb:> Alex W. schrieb:>> Wenn du dich hier anmeldest, kann ich dir eine PN schreiben mit ein paar>> Tips, wie man den MLX z.B. am Teensy 3.6 oder Nucleo zum Laufen bekommt!>> So?
Hast PN!
Alex W. schrieb:> Marc H. schrieb:>> Alex W. schrieb:>>> Wenn du dich hier anmeldest, kann ich dir eine PN schreiben mit ein paar>>> Tips, wie man den MLX z.B. am Teensy 3.6 oder Nucleo zum Laufen bekommt!>>>> So?>> Hast PN!
DAAAAAAANKE!!!!!! :)
Thread beobachten
Seitenaufteilung abschalten
