Forum: Mikrocontroller und Digitale Elektronik Wer nutzt das Nucleo-64 und kann mir


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Harry L. (mysth)


Bewertung
-2 lesenswert
nicht lesenswert

von Alex D. (daum)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Marc Horby (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Marc Horby (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Rene B. (themason) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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!

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marc Horby (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Marc Horby (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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 !

: Bearbeitet durch User
von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marc Horby (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ok, dann verwendest du offensichtlich eine Library, die auf Cube HAL 
aufbaut, welche wiederum Hardware-I²C verwendet.

Ist deine Wire.cpp genau diese?: 
https://github.com/arduino-org/arduino-core-stm32f4/blob/master/cores/arduino/Wire.cpp

Ich frage, weil da schon wieder andere Pins initialisiert werden:
1
else if(twi == I2C1)
2
  {
3
    /* Enable GPIO TX/RX clock */
4
    __HAL_RCC_GPIOB_CLK_ENABLE();
5
6
    /* Enable I2Cx clock */
7
    __HAL_RCC_I2C1_CLK_ENABLE();
8
9
    /* I2C SCL GPIO pin configuration  */
10
    GPIO_InitStruct.Pin       = GPIO_PIN_6;
11
    GPIO_InitStruct.Mode      = GPIO_MODE_AF_OD;
12
    GPIO_InitStruct.Pull      = GPIO_PULLUP;
13
    GPIO_InitStruct.Speed     = GPIO_SPEED_HIGH;
14
    GPIO_InitStruct.Alternate = GPIO_AF4_I2C1;
15
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
16
17
    /* I2C SDA GPIO pin configuration  */
18
    GPIO_InitStruct.Pin       = GPIO_PIN_7;
19
    GPIO_InitStruct.Alternate = GPIO_AF4_I2C1;
20
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
21
22
    HAL_NVIC_SetPriority(I2C1_ER_IRQn, 0, 1);
23
    HAL_NVIC_EnableIRQ(I2C1_ER_IRQn);
24
    HAL_NVIC_SetPriority(I2C1_EV_IRQn, 0, 2);
25
    HAL_NVIC_EnableIRQ(I2C1_EV_IRQn);
26
  }

Also PB6 und PB7, hier hätte ich jedoch PB8 und PB9 erwartet. Haben wir 
hier einen Bug gefunden?

von Marc Horby (Gast)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Also PB6 und PB7, hier hätte ich jedoch PB8 und PB9 erwartet. Haben wir
> hier einen Bug gefunden?

Wenn, hast du ihn gefunden!

Stefanus F. schrieb:
> Ist deine Wire.cpp genau diese?:
> 
https://github.com/arduino-org/arduino-core-stm32f4/blob/master/cores/arduino/Wire.cpp

nein! Bei mir sieht die so aus: (Anhang)
Ist im Ordner 
C:\Users\MHorb\AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.3 
.0\libraries\Wire\src

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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
void TwoWire::beginTransmission(uint8_t address)
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:
1
uint8_t TwoWire::endTransmission(uint8_t sendStop)
2
{
3
  UNUSED(sendStop);
4
  int8_t ret = 4;
5
6
  if (master == true) {
7
    / transmit buffer (blocking)
8
    switch(i2c_master_write(&_i2c, txAddress, txBuffer, txBufferLength))
9
    {
10
    case I2C_OK :
11
      ret = 0;
12
    break;
13
    case I2C_TIMEOUT :
14
      ret = 1;
15
    break;
16
    default:
17
      ret = 4;
18
    break;
19
    }
20
21
    // reset Tx buffer
22
    resetTxBuffer();
23
24
    // reset tx buffer iterator vars
25
    txBufferIndex = 0;
26
    txBufferLength = 0;
27
28
    // indicate that we are done transmitting
29
    transmitting = 0; 
30
  }
31
32
  return ret;
33
}

Master ist immer true. Das Ergebnis kommt also von i2c_master_write(). 
Besorge mal den Quelltext dieser Funktion.

: Bearbeitet durch User
von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Marc Horby (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> i2c_custom_init() und i2c_master_write().

Wo finde ich die? Hab da was in twi.c und .h gefunden.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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
int main() {
2
    I2C  i2c(PB_11, PB_10);     // sda, scl
3
4
    printf("starting i2c scanner...\n");
5
6
    for (int addr=0; addr < 256; addr+=2) {
7
        char dummy[4];
8
9
        int rc = 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.

: Bearbeitet durch User
von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marcus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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?

von Marcus (Gast)


Bewertung
1 lesenswert
nicht lesenswert
BTW: vielleicht geht eine Soft-I2C ?

https://github.com/todbot/SoftI2CMaster

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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
void delay(uint16_t msec)
3
{
4
    for (uint32_t j=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.

: Bearbeitet durch User
von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
jepp, oder für VS code gibt es auch ein plugin, zumindest für 
rudimentäre Sachen. Habe ich aber noch nicht getestet und jetzt ruft der 
Garten.

von Marcus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marcus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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.

von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
das übliche I2C Adressen Problem?
Probiere mal
1
const byte MLX90640_address = (0x33 << 1);

von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :
1
Parameter extraction failed
2
nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,nan,0.00,0.00,0.00,
3
Read rate: 3.48 Hz
4
Read plus print rate: 1.64 Hz


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.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Marcus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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.

von Marcus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Übrigens ist der benötigte I2C Datenbuffer des MLX ziemlich groß:
1
uint16_t eeMLX90640[832];

aus
https://github.com/sparkfun/SparkFun_MLX90640_Arduino_Example/blob/master/Firmware/Example1_BasicReadings/Example1_BasicReadings.ino

von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marcus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Alex W. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
"

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Alex W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Alex W. schrieb:
> 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!

Nicht nötig, gibt es bereits (den Link hatte ich weiter oben schon 
gepostet):

https://github.com/mubase/STM32F4-Arduino-core/blob/master/Libraries/Wire/Wire.h

Man kann das einfach verwenden oder kopieren.

von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!
1
Arduino: 1.8.6 (Windows 7), Board: "Maple (Rev 3), 72Mhz (Normal), Smallest (default)"
2
3
C:\Program Files (x86)\Arduino\arduino-builder -dump-prefs -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\MHorb\AppData\Local\Arduino15\packages -hardware C:\Users\MHorb\Documents\Arduino\hardware -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\MHorb\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\MHorb\Documents\Arduino\libraries -fqbn=Arduino_STM32:STM32F1:maple:cpu_speed=speed_72mhz,opt=osstd -ide-version=10806 -build-path C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120 -warnings=none -prefs=build.warn_data_percentage=75 -verbose C:\Users\MHorb\Documents\Arduino\MLX90640\Qwiic_IR_Array_MLX90640_55\Firmware\Example2_OutputToProcessing\Example2_OutputToProcessing.ino
4
C:\Program Files (x86)\Arduino\arduino-builder -compile -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\MHorb\AppData\Local\Arduino15\packages -hardware C:\Users\MHorb\Documents\Arduino\hardware -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\MHorb\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\MHorb\Documents\Arduino\libraries -fqbn=Arduino_STM32:STM32F1:maple:cpu_speed=speed_72mhz,opt=osstd -ide-version=10806 -build-path C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120 -warnings=none -prefs=build.warn_data_percentage=75 -verbose C:\Users\MHorb\Documents\Arduino\MLX90640\Qwiic_IR_Array_MLX90640_55\Firmware\Example2_OutputToProcessing\Example2_OutputToProcessing.ino
5
Using board 'maple' from platform in folder: C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1
6
Using core 'maple' from platform in folder: C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1
7
Detecting libraries used...
8
"C:\\Users\\MHorb\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10806 -DARDUINO_MAPLE_REV3 -DARDUINO_ARCH_STM32F1 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/stm32f1/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\cores\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\variants\\maple" "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\sketch\\Example2_OutputToProcessing.ino.cpp" -o nul
9
"C:\\Users\\MHorb\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10806 -DARDUINO_MAPLE_REV3 -DARDUINO_ARCH_STM32F1 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/stm32f1/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\cores\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\variants\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire" "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\sketch\\Example2_OutputToProcessing.ino.cpp" -o nul
10
"C:\\Users\\MHorb\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10806 -DARDUINO_MAPLE_REV3 -DARDUINO_ARCH_STM32F1 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/stm32f1/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\cores\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\variants\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire" "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\sketch\\MLX90640_API.cpp" -o nul
11
"C:\\Users\\MHorb\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10806 -DARDUINO_MAPLE_REV3 -DARDUINO_ARCH_STM32F1 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/stm32f1/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\cores\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\variants\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire" "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\sketch\\MLX90640_I2C_Driver.cpp" -o nul
12
"C:\\Users\\MHorb\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10806 -DARDUINO_MAPLE_REV3 -DARDUINO_ARCH_STM32F1 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/stm32f1/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\cores\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\variants\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire\\utility" "C:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire\\SoftWire.cpp" -o nul
13
"C:\\Users\\MHorb\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10806 -DARDUINO_MAPLE_REV3 -DARDUINO_ARCH_STM32F1 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/stm32f1/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\cores\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\variants\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire\\utility" "C:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire\\Wire.cpp" -o nul
14
"C:\\Users\\MHorb\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10806 -DARDUINO_MAPLE_REV3 -DARDUINO_ARCH_STM32F1 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/stm32f1/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\cores\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\variants\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire\\utility" "C:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire\\utility\\WireBase.cpp" -o nul
15
Generating function prototypes...
16
"C:\\Users\\MHorb\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10806 -DARDUINO_MAPLE_REV3 -DARDUINO_ARCH_STM32F1 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/stm32f1/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\cores\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\variants\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire" "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\sketch\\Example2_OutputToProcessing.ino.cpp" -o "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\preproc\\ctags_target_for_gcc_minus_e.cpp"
17
"C:\\Program Files (x86)\\Arduino\\tools-builder\\ctags\\5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\preproc\\ctags_target_for_gcc_minus_e.cpp"
18
Sketch wird kompiliert...
19
"C:\\Users\\MHorb\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -MMD -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10806 -DARDUINO_MAPLE_REV3 -DARDUINO_ARCH_STM32F1 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/stm32f1/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\cores\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\variants\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire" "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\sketch\\MLX90640_I2C_Driver.cpp" -o "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\sketch\\MLX90640_I2C_Driver.cpp.o"
20
"C:\\Users\\MHorb\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -MMD -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10806 -DARDUINO_MAPLE_REV3 -DARDUINO_ARCH_STM32F1 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/stm32f1/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\cores\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\variants\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire" "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\sketch\\MLX90640_API.cpp" -o "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\sketch\\MLX90640_API.cpp.o"
21
"C:\\Users\\MHorb\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -MMD -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10806 -DARDUINO_MAPLE_REV3 -DARDUINO_ARCH_STM32F1 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 -DMCU_STM32F103RB -DSERIAL_USB -mthumb -march=armv7-m -D__STM32F1__ -DARDUINO_ARCH_STM32 "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/stm32f1/include" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\cores\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\variants\\maple" "-IC:\\Users\\MHorb\\Documents\\Arduino\\hardware\\Arduino_STM32\\STM32F1\\libraries\\Wire" "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\sketch\\Example2_OutputToProcessing.ino.cpp" -o "C:\\Users\\MHorb\\AppData\\Local\\Temp\\arduino_build_188120\\sketch\\Example2_OutputToProcessing.ino.cpp.o"
22
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
25
26
     Wire.write(startAddress >> 8); //MSB
27
28
                                 ^
29
30
C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120\sketch\MLX90640_I2C_Driver.cpp:44:33: note: candidates are:
31
32
In file included from C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/Wire.h:42:0,
33
34
                 from C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120\sketch\MLX90640_I2C_Driver.cpp:19:
35
36
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:111:12: note: size_t WireBase::write(uint8)
37
38
     size_t write(uint8);
39
40
            ^
41
42
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:121:12: note: size_t WireBase::write(int)
43
44
     size_t write(int);
45
46
            ^
47
48
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:131:10: note: void WireBase::write(char*) <near match>
49
50
     void write(char*);
51
52
          ^
53
54
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
57
58
     Wire.write(startAddress & 0xFF); //LSB
59
60
                                   ^
61
62
C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120\sketch\MLX90640_I2C_Driver.cpp:45:35: note: candidates are:
63
64
In file included from C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/Wire.h:42:0,
65
66
                 from C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120\sketch\MLX90640_I2C_Driver.cpp:19:
67
68
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:111:12: note: size_t WireBase::write(uint8)
69
70
     size_t write(uint8);
71
72
            ^
73
74
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:121:12: note: size_t WireBase::write(int)
75
76
     size_t write(int);
77
78
            ^
79
80
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:131:10: note: void WireBase::write(char*) <near match>
81
82
     void write(char*);
83
84
          ^
85
86
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
91
92
   Wire.write(writeAddress >> 8); //MSB
93
94
                               ^
95
96
C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120\sketch\MLX90640_I2C_Driver.cpp:88:31: note: candidates are:
97
98
In file included from C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/Wire.h:42:0,
99
100
                 from C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120\sketch\MLX90640_I2C_Driver.cpp:19:
101
102
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:111:12: note: size_t WireBase::write(uint8)
103
104
     size_t write(uint8);
105
106
            ^
107
108
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:121:12: note: size_t WireBase::write(int)
109
110
     size_t write(int);
111
112
            ^
113
114
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:131:10: note: void WireBase::write(char*) <near match>
115
116
     void write(char*);
117
118
          ^
119
120
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
123
124
   Wire.write(writeAddress & 0xFF); //LSB
125
126
                                 ^
127
128
Mehrere Bibliotheken wurden für "Wire.h" gefunden
129
C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120\sketch\MLX90640_I2C_Driver.cpp:89:33: note: candidates are:
130
131
 Benutzt: C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire
132
 Nicht benutzt: C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\WireSlave
133
In file included from C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/Wire.h:42:0,
134
135
                 from C:\Users\MHorb\AppData\Local\Temp\arduino_build_188120\sketch\MLX90640_I2C_Driver.cpp:19:
136
137
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:111:12: note: size_t WireBase::write(uint8)
138
139
     size_t write(uint8);
140
141
            ^
142
143
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:121:12: note: size_t WireBase::write(int)
144
145
     size_t write(int);
146
147
            ^
148
149
C:\Users\MHorb\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\Wire/utility/WireBase.h:131:10: note: void WireBase::write(char*) <near match>
150
151
     void write(char*);
152
153
          ^
154
155
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!

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Man tauscht ja auch nicht einzelne Dateien aus, sondern das gesamte 
Arduino Plugin am Stück.

: Bearbeitet durch User
von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Marc Horby (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Was stört dich an 20k Byte? Das ist doch schon relativ viel, verglichen
> mit anderen Mikrocontrollern.

Ich will den MLX abfragen und für den benötigt man schon mal 20kByte.
Danach würde ich gerne noch ein Display ansteuern und dann wäre er schon 
am Ende

Stefanus F. schrieb:
> Nein, es gibt welche mit viel mehr RAM:
>
> 
https://www.st.com/en/microcontrollers/stm32f103.html?querycriteria=productId=LN1565

Ok, dachte die 103er sind 20kByte

von Johannes S. (jojos)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Marc Horby (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Marc Horby (Gast)


Bewertung
1 lesenswert
nicht lesenswert
OK :(

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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

von Marc Horby (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.
1
const int colormap_grayscale[] = {0, 0, 0, 1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 4, 5, 5, 5, 6, 6, 6, 7, 7, 7, 8, 8, 8, 9, 9, 9, ...};

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.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Manche Sachen kann man mit Excel generieren.

von Marc Horby (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Indem du sie mit einer Formel berechnest.
Wenn du weder Formel noch Zahlen hast: Von nichts kommt nichts.

von Marc (Gast)


Bewertung
1 lesenswert
nicht lesenswert
>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.

von Marc Horby (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Marc Horby (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Christopher J. (christopher_j23)


Bewertung
-1 lesenswert
nicht lesenswert
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
8
# [[0.267004, 0.004874, 0.329415], [0.26851, 0.009605, 0.335427], 
9
# [0.269944, 0.014625, 0.341379]]
10
11
# wer möchte kann das noch umrechnen
12
npa = np.array(color_list) # in numpy-array umwandeln
13
npa = npa*255 # 0-1 auf 0-255 skalieren
14
15
# und noch zu unsigned integer umwandeln
16
int_liste = np.uint8(npa)
17
18
# zugriff erfolgt dann etwa mit
19
# int_liste[0]
20
# array([68,  1, 84], dtype=uint8)
21
# oder spezieller
22
# int_liste[0][2]
23
# 84

Wie du das so formatierst wie es dir in deinen C-Code passt, das lasse 
ich dir mal als Aufgabe.

Beitrag #5580496 wurde vom Autor gelöscht.
von Alex W. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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!

von Marc H. (marchorby)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Alex W. (a20q90)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!!!!!! :)

von Florian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was ist jetzt raus gekommen?

von Marc Horby (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Florian schrieb:
> Was ist jetzt raus gekommen?

Läuft!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.