UART und I2C Konflikt mit STM32duino STM32G070

[Paul-Gerhard S. (paul-g)]

Habe ein Problem bei der Verwendung von UART und I2C in Arduino IDE 2 
und STM32duino.
Die angeschlossene Hardware ist ein NUCLEO-G070RB. An das Board ist 
auser einem USB/Seriell-Wandler an PA10/PA9 nichts angeschlossen oder 
zusätzlich beschaltet.

Sketch ist folgender:

#include <Arduino.h>
#include <Wire.h>
#include <HardwareSerial.h>


HardwareSerial MySerial(PA10, PA9); // nucleo -> USB-Seriell-Wandler
//HardwareSerial MySerial(PA3, PA2); // nucleo -> stlink Virtual Com Port


void setup()
{
  MySerial.begin(9600);
  delay(200);

  MySerial.println("Test");

  //Wire.begin(); 
}


void loop()
{
  
}

Ich teste die Seriellen Schnittestellen bisher immer nacheinander. Beide 
Schnittstellen funktionieren. Sobald ich aber das Wire.begin() für I2C 
einkommentiere funktioniert nur die PA3/PA2 UART. Bei PA10/PA9 und 
Wire.begin() bekomme ich im Terminal nur noch ein ▒▒

Kennt sich jemand mit STM32duino aus oder weiß wie man da weiter nach 
einem Fehler sucht? Oder weiß jemand, dass UART an P10/PA9 und I2C nicht 
gleichzeitig verwendet werden darf?

Vielen Dank!

[N. M. (mani)]

Paul-Gerhard S. schrieb:
> Oder weiß jemand, dass UART an P10/PA9 und I2C nicht gleichzeitig
> verwendet werden darf?

Natürlich nicht gleichzeitig an den gleichen Pins.
Das wird vermutlich hier dein Problem sein.

Ich würde also Mal versuchen entweder die UART oder die I2C Pins zu 
wechseln.

Kannst ja Mal die Initialisierung umdrehen.
Also erster Wire, dann UART.
Wenn dann UART funktioniert und I2C nicht klauen die sich gegenseitig 
eine Ressource z.B. die Pins.

Oder Wire dreht am System Takt oder so...
Dann mach Mal nach Wire.begin() nochmal ein MySerial.begin(9600)

[Joachim B. (jar)]

N. M. schrieb:
> Ich würde also Mal versuchen

den Quellcode zu betrachten und auch bedingte Kompilierung einzufügen 
und mehr Textausgaben und ein C-Buch,
also suche welche Ports I2C und UART nutzen und stelle fest wer wann was 
verwendet und wer was verwenden kann!

nur als Anregung zum selberlernen

#if defined(__AVR_ATmega1284P__)

// --------------- serial in ---------------
  if (Serial.available() > 0) 
  { char incomingByte = (char)Serial.read();
    if(incomingByte == 13)  // Wenn das Enter ankommt
    { strcpy(serial_in_command, serial_in_buff);
//      strcpy(serial_in_buff,"");
      memset(&serial_in_buff[0], 0, sizeof(serial_in_buff));
      chr_cnt = 0;
      if(strlen(serial_in_command))
      { Serial.println(F("")); Serial.print(serial_in_command);  Serial.println(F(" -> erkannt!!!!")); 
#if defined(__AVR_ATmega1284P__)
        Serial1.println(serial_in_command);  
#endif
        inSTRauswertung();
      } // if(strlen(serial_in_command))
    }
    else // Falls kein Enter kommt muss der Text gespeichert werden in dem inText Array
    { if(isprint(incomingByte))
        serial_in_buff[chr_cnt++] = incomingByte;
    }
  } // if (Serial.available() > 0)

[Arduino F. (Firma: Gast) (arduinof)]

Joachim B. schrieb:
> nur als Anregung zum selberlernen

Ein STM32 ist kein AVR!
Dein AVR hat keine alternative Portpins.

[N. M. (mani)]

Joachim B. schrieb:
> den Quellcode zu betrachten und auch bedingte Kompilierung einzufügen und mehr 
Textausgaben und ein C-Buch

Ist Aufgabe des TOs. Ich gebe nur Anregungen.

Joachim B. schrieb:
> und mehr Textausgaben

Wenn die serielle Ausgabe nicht geht? Gute Idee! Sein TX macht Müll. Da 
bringt ihm dein Code Schnipsel mit RX einlesen auch nichts.

Apropos, ich würde da an deiner Stelle noch etwas in Out of Bound beim 
hinzufügen in den Puffer serial_in_buffer und in Input validation was 
die Null Terminierung angeht investieren.

Joachim B. schrieb:
> nur als Anregung zum selberlernen

Brauche ich nicht, danke.
Ich würde einfach die Setup mit dem Debugger durchlaufen und die 
Register ansehen ob sie so stehen wie ich es erwarte.

[Joachim B. (jar)]

Arduino F. schrieb:
> Dein AVR hat keine alternative Portpins

Danke, ich weiß das, aber z.B. ein ESP hat alternative Portpins und man 
muß halt beim STM auch mal recherchieren!
Ferner erinnere ich mich auch daran daß es STM gibt die nicht alle Pins 
nutzen können oder Fake waren, war hier

Beitrag "wie Bluepill Board prüfen?"

N. M. schrieb:
> Apropos, ich würde da an deiner Stelle noch etwas in Out of Bound beim
> hinzufügen in den Puffer serial_in_buffer und in Input validation was
> die Null Terminierung angeht investieren.

ist drin und wird auf Überlauf geprüft, das war ein Beispiel auf die 
Schnelle, ich kann nicht dem TO alle Arbeit zm selberlernen abnehmen.
Hilfe zur Selbsthilfe war meine Idee.

[Paul-Gerhard S. (paul-g)]

Habs herausgefunden.
Ich brauche noch

Wire.setSCL(PB6);
Wire.setSDA(PB7);

sonst verwendet er wahrscheinlich aus einer variant_generic.h die 
gleichen Pins wie die UART.

Vielen Dank für die Anregungen

[N. M. (mani)]

Joachim B. schrieb:
> das war ein Beispiel auf die Schnelle

Klar, ein Beispiel auf die Schnelle. Mit sämtlichen defines, Registern 
und so weiter. Aber ohne eine vernünftige Prüfung. Was man halt so macht 
😉

Joachim B. schrieb:
> Hilfe zur Selbsthilfe war meine Idee.

Mit einem Beispiel was ihm für sein Problem garnichts bringt? Top!

Paul-Gerhard S. schrieb:
> Habs herausgefunden.
> Ich brauche noch
>
> Wire.setSCL(PB6);
>
> Wire.setSDA(PB7);

Huch, es waren also doch einfach die Pins. Verrückt!

Joachim B. schrieb:
> N. M. schrieb:
>> Ich würde also Mal versuchen entweder die UART oder die I2C Pins zu wechseln.
>
> den Quellcode zu betrachten und auch bedingte Kompilierung einzufügen
> und mehr Textausgaben und ein C-Buch

Aber erst Mal schön die Leute von der Seite anblöken.

[Marc N. (Gast)]

Im STM32G070 Datenblatt

https://www.st.com/resource/en/datasheet/stm32g070cb.pdf

Auf Seite 36 bei PA9 und PA10 bei alternativen Funktionen:
- I2C1_SCL
- I2C1_SDA

[Nemopuk (nemopuk)]

Wenn mann die Datenblätter liest, braucht man kein Arduino mehr.

[Joachim B. (jar)]

N. M. schrieb:
> Aber erst Mal schön die Leute von der Seite anblöken.

ach und das überliest du?

Joachim B. schrieb:
> Danke, ich weiß das, aber z.B. ein ESP hat alternative Portpins und man
> muß halt beim STM auch mal recherchieren!
> Ferner erinnere ich mich auch daran daß es STM gibt die nicht alle Pins
> nutzen können oder Fake waren, war hier
>
> Beitrag "wie Bluepill Board prüfen?"
Beitrag "wie Bluepill Board prüfen?"

N. M. schrieb:
> Ist Aufgabe des TOs. Ich gebe nur Anregungen.

ich tat nichts anderes und blökte niemanden wie Andere von der Seite an 
😜

[Rahul D. (rahul)]

Nemopuk schrieb:
> Wenn mann die Datenblätter liest, braucht man kein Arduino mehr.

Wie viel hat der Spruch mit der Frage des OP zutun?
Ein Verweis auf die STMduino-Doku wäre angebracht, aber "Arduino ist 
sowieso nur doof für Doofe!" ist keine Antwort auf die Frage.

[Arduino F. (Firma: Gast) (arduinof)]

Rahul D. schrieb:
> ist keine Antwort auf die Frage

Unser Stefanus ist im tiefen Herzen ein Arduino Basher!
Die letzten Jahre ist er damit deutlich ruhiger geworden. Aber es blitzt 
immer wieder mal durch die Fascade.

[Rahul D. (rahul)]

Arduino F. schrieb:
> ein Arduino Basher!

Nicht nur das. Er hat auch noch andere Benimm-Probleme.

[Karl B. (gustav)]

Dass sich Routinen in die Quere kommen können, habe ich letztens noch 
erfahren müssen. Man erinnere sich an die verrückte Idee, ein OLED mit 
einem ATtiny4313 zu verbinden. Die USI-Routine kollidiert mit anderen 
Routinen.
Eine Lösungsmöglichkeit bestand darin, vor der Ausgaberoutine das 
Statusregister zu sichern. Allerdings diesen String in die 
Ausgaberoutine selbst einzubinden, klappt auch nicht immer, besser war 
es, vor dem Sprung in die Ausgaberoutine, also Sicherung der 
Rücksprungadresse auf dem Stack, erst das Statusregister zu sichern, 
dann erst den Sprung auf das Label "Ausgabe" durchzuführen.
Die Flags müssen gesichert werden.
Und so verhält es sich auch mit den Include und Macros. Und Libraries 
bei Arduino, die sich durchaus in die Quere kommen können.
Die Wire.h darf bei U8lib nicht includiert werden.
Bei dem Sketch für GPS ist das OLED in I2C ansprechbar, das GPS Modul 
u-blox NEO-6M Chip mit serial 9k6 8N1.
Also hier sind die Serielle Schnittstelle und I2C drin und beißen sich 
nicht.
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>
#include <TinyGPSPlus.h>
#include <SoftwareSerial.h>

Der TO hat hardware.serial. Man nehme einmal testweise softwareserial. 
Vielleicht ist das die Lösung für sein Problem.

ciao
gustav

P.S.: Interessant noch, dass TinyGPS++ also plus plus angegeben wird, 
der Compiler nimmt aber nur einmal plus.