UART auf Linux

[Robert B. (robertoneu_95)]

Hallo, ich habe mal eine Frage bezüglich UART und Linux.
Habe mich entschieden, mich mehr mit Linux zu beschäftigen. Seid bitte 
gnädig, weil ich noch Anfänger bin was Linux betrifft.

Hab ein STM32-Mikrocontroller und versuchen nun, dass dieser Controller 
mit meinem Rechner (Linux) kommuniziert. Die Kommunikation läuft über 
die UART-Schnittstelle. Um die Ausgabe zu sehen, habe ich mir auf den 
Rechner "Minicom" installiert. Der STM32f091 ist per USB an meinem 
Rechner angeschlossen.

Online findet man eine Menge an Literatur für die Konfiguration des 
Minicoms. Meine Serielle Anschluss läuft über den Port /dev/ttyACM0 und 
Bps sind 115200 8N1. Diese Konfigurationen habe ich vorgenommen, mehr 
nicht.

Leider bekomme ich die Ausgabe 'K' nicht auf meinem Rechner (Terminal) 
angezeigt. Unter Windows mit "Realterm" hat alles geklappt. Kennst sich 
vielleicht jemand mit Linux aus und kann mir helfen.

Bin für jeden Tipp sehr Dankbar.

Grüße
Robert

[MaWin (Gast)]

Robert B. schrieb:
> Minicom

Ich verwende lieber picocom.
Das ist viel kleiner, handlicher und einfacher.
Die Manpage von picocom ist auch recht übersichtlich und verständlich.

[Jemand (Gast)]

Versuche Flow Control in minicom abzustellen. Wenn das aktiv ist, es 
aber nicht unterstützt wird, passiert gerne gar nichts.

[pegel (Gast)]

Benutzer hat richtigen Rechte? Gruppe dialout?

Bin Fan von cutecom, schön graphisch.

[Olaf (Gast)]

Die Rechte wird er schon haben weil Minicom sonst meckern wuerde
das man den Port nicht aufmachen kann. Es wird wirklich daran liegen
das man den Hardwarehandshake abschalten muss.

Olaf

[Robert B. (robertoneu_95)]

Danke für die schnelle Antwort.

Mein Flow Control für die Hardware und Software sind deaktiviert. Ich 
zeige euch mal paar Bilder. Auf Bild 2 (Bildschirmfoto von 2022-07-27 
17-16-58)müsse ja meine Ausgabe erscheine, oder?

[NichtWichtig (Gast)]

Sende mal mehr als nur ein 'K', gerne auch mit CR/LF

[Wendels B. (wendelsberg)]

Robert B. schrieb:
> Die Kommunikation läuft über
> die UART-Schnittstelle.
...
> Meine Serielle Anschluss läuft über den Port /dev/ttyACM0

/dev/ttyACM0 ist keine UART, die heissen /dev/ttyS...

Falls ttyACM0 ein Seriell-USB-Wandler ist, muss dieser korrekt 
unterstuetzt sein, was aber schon lange kein Problem sein sollte.
Zum Test kannst Du das Minicom mit Rootrechten starten, entweder mit 
"su" und Rootpasswort oder mit vorangestelltem "sudo" und Deinem 
Benutzerpasswort.

Wenn es dann klappt, ist die Ursache ein Rechteproblem.

[Robert B. (robertoneu_95)]

> Zum Test kannst Du das Minicom mit Rootrechten starten, entweder mit
> "su" und Rootpasswort oder mit vorangestelltem "sudo" und Deinem
> Benutzerpasswort.

Hab Minicom mit Rootrechten gestartet, habe aber die gleichen Probleme. 
Werde mal mehr ausgeben lassen als nur ein 'K'. Mal gucken, ob das 
funktioniert.

[Olaf (Gast)]

> /dev/ttyACM0 ist keine UART, die heissen /dev/ttyS...

Das kann je nach Linuxversion unterschiedlich sein. Bei mir heisst das
zum Beispiel /dev/ttyUSB0

Am besten mal den USB-RS232 Adapter oder die sonstige Hardware anstecken
und sich unmittelbar darauf das Ende von /var/log/messages anschauen.
Dann sieht man wie der Treiber das Device benennt.

> Werde mal mehr ausgeben lassen als nur ein 'K'. Mal gucken, ob das
> funktioniert.

Wenn ich garnicht mehr weiterweiss dann verbinde ich erstmal TxD und RxD 
vom Port direkt ohne meine eigene Hardware. Danach musst du in Minicom 
sehen koennen was du tipps. Ohne Bruecke siehst du nichts weil locales 
Echo per default aus ist.

Olaf

[Robert B. (robertoneu_95)]

Meine Algorithmus gibt mir folgende Ausgabe in der Console:

-----------------------------------------------------------------------

STMicroelectronics ST-LINK GDB server. Version 7.0.0
Copyright (c) 2022, STMicroelectronics. All rights reserved.

Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 1
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled
        InitWhile                  : Enabled

Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.11.0-RC1
      -------------------------------------------------------------------



Log output file:   /tmp/STM32CubeProgrammer_WeTggc.log
ST-LINK SN  : 066DFF484956827867171711
ST-LINK FW  : V2J40M27
Board       : NUCLEO-F091RC
Voltage     : 3,25V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x442
Revision ID : Rev 1.0
Device name : STM32F09x/F030xC
Flash size  : 256 KBytes
Device type : MCU
Device CPU  : Cortex-M0
BL Version  : --



Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_vFS8ad.srec
  File          : ST-LINK_GDB_server_vFS8ad.srec
  Size          : 5,62 KB
  Address       : 0x08000000


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 2]
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:00.342



Verifying ...




Download verified successfully


Shutting down...
Exit.

------------------------------------------------------------------------ 
----

Das "Exit" weist doch darauf, dass mein Programm beendet wurde, oder?

[PittyJ (Gast)]

Ich verwende seit Jahren nur noch putty. Täglich in Betrieb für die 
Debug-Ausgaben meiner STMs.

Gibts auch über 'apt-get ...'

Das läuft sowohl auf X86-Linux, als auch auf dem Raspi.
Es gehen sowohl natives Uart, als auch die Usb-Serielladapter.

[Ralph S. (jjflash)]

Olaf schrieb:
> Das kann je nach Linuxversion unterschiedlich sein. Bei mir heisst das
> zum Beispiel /dev/ttyUSB0

Das hängt nicht vom Linux ab, sondern von der Art des USB2UART Chips. 
Ein CH340 wird sich beispielsweise als /dev/ttyUSBx anmelden.

Eine mittels CDC realisierte serielle Schnittstelle wird sich mit 
/dev/ttyACMx anmelden (beispielsweise die Verwendung von CDC mittels dem 
USB auf STM32 Controllern oder auch die FTDI Chips).

[NichtWichtig (Gast)]

Also ist unklar ob der STM überhaupt sendet?

Scope dran hängen und messen.

[TomA (Gast)]

Hallo Robert.

Habe da mal etwas über dieses Thema geschrieben. Was dich interessiert 
findest du im Kapitel 6 im Allgemeinen, und 6.1 im speziellen. Den Rest 
am Besten nicht beachten.

Viel Erfolg. Tom

[VollHonk (Gast)]

Das Teil anstecken, dmesg aufrufen und die Serielle erkennen.
Btw. Wenn man z.B. /dev/ttyUSB0 verwendet, aber diese nichtz vorhanden 
ist, kann man die nicht öffnen (bei cutecom wird gleich der Fehler 
angezeigt und auch alle verfügbaren rs232)
Du muss in der Gruppe dialout sein, dann klappt das mit den linken, aehm 
rechten.

[2⁵ (Gast)]

Ich verwende gerne screen. Aufruf z.B. für den CH340 USB/Seriell Wandler
screen /dev/ttyUSB0 115200

[2⁵ (Gast)]

NichtWichtig schrieb:
> Also ist unklar ob der STM überhaupt sendet?

Klingt jetzt nicht so:

Robert B. schrieb:
> Unter Windows mit "Realterm" hat alles geklappt.

[NichtWichtig (Gast)]

2⁵ schrieb:
> NichtWichtig schrieb:
>> Also ist unklar ob der STM überhaupt sendet?
>
> Klingt jetzt nicht so:
>
> Robert B. schrieb:
>> Unter Windows mit "Realterm" hat alles geklappt.

Hatte ich auch so gedacht, aber dann kam sein Beitrag von 18:15

Keine Ahnung was sein µC da ab Spannung ein liefert.

Womöglich stolpert er über was ganz Anderes.

[Zeno (Gast)]

Wendels B. schrieb:
> /dev/ttyACM0 ist keine UART
Doch unter RasPi schon.

[Stefan F. (Gast)]

Dass das Device /dev/ttyACM0 heisst ist völlig normal und richtig. Da 
hier keine physikalische serielle Schnittstelle involviert ist, spielen 
Baudrate, und Anzahl der Daten-Bits und Stopp-Bits keine Rolle.

Ein simples "cat /dev/ttyACM0" sollte schon funktionieren.

Wie sieht die Ausgabe von "sudo dmesg" unmittelbar nach den Anstecken 
des USB Kabels aus? Nur die letzten Zeilen, die sich auf das USB Gerät 
beziehen, sind von Interesse.

Windows und Linux verhalten sich insbesondere bei der Initialisierung 
der Schnittstelle unterschiedlich. Eventuell liegt ein Fehler auf dem 
Mikrocontroller verwendeten Bibliothek vor. Welche hast du verwendet?

Bei Linux gibt es die Besonderheit, dass /dev/ttyACM* Device 
standardmäßig eine Login Konsole bekommen (/dev/ttyUSB* jedoch nicht). 
Diese Konsole sendet eine Eingabeaufforderung und jedes empfangene 
Zeichen (als Echo) an den Mikrocontroller.

Dann gibt es da noch den standardmäßig installierten Modemmanager (auch 
Windows hatte so etwas ähnliches) für Plug&Play, der beim Anstecken 
testet ob es sich um ein Modem handelt. In diesem Fall empfängt der 
Mikrocontroller AT-Befehle, auf die Modems antworten würden.

Vielleicht reagiert dein Programm auf dem Mikrocontroller empfindlich 
darauf. Man kann diese Sonderlocken von Linux natürlich weg 
konfigurieren, aber erstmal würde ich analysieren, was die 
Problemursache ist.

Wo kommt denn das vermisste 'K' her? Zeige mal deinen Quelltext.

[Markus W. (dl8mby)]

vor dem Anstecken des USB2RS232 Adapters

journalctl -f (als root) aufrufen, damit man alle Meldungen
sieht, sonst bekommt man nur seine eigenen zu Gesicht.

Sieht dan z.B. so aus:

Jul 28 09:33:00 linux-kwm1 kernel: usb 1-1: new full-speed USB device number 7 using xhci_hcd
Jul 28 09:33:00 linux-kwm1 kernel: usb 1-1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00
Jul 28 09:33:00 linux-kwm1 kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 28 09:33:00 linux-kwm1 kernel: usb 1-1: Product: USB-Serial Controller
Jul 28 09:33:00 linux-kwm1 kernel: usb 1-1: Manufacturer: Prolific Technology Inc.
Jul 28 09:33:00 linux-kwm1 kernel: pl2303 1-1:1.0: pl2303 converter detected
Jul 28 09:33:00 linux-kwm1 kernel: usb 1-1: pl2303 converter now attached to ttyUSB0

die Zeile
New USB device found, idVendor=067b, idProduct=2303
und eventuell schauen ob bereits ein device in dev Verzeichnis
eingebunden wurde.
In diesem Fall  /dev/ttyUSB0
Wenn Du sowas zu sehen bekommst, dann wurde der Treiber eingebunden
und Du kannst loslegen, wenn nicht musst Du eine udev-Regel in
/etc/udev/rules.d z.B. in der Form 99-mein-adapter.rules anlegen.

Dan die erzeugte Regel mit dem u.g. Kommando laden.
udevadm control --reload

Dabei in einem anderen root Fenster mit journalctl -f beobachten,
ob beim Laden Deiner neuen Regel Fehler auftauchen.

Regel-Dateien für udev sehen wie folgt aus:
>cat 99-flashforge.rules
#Flashfrog Dreamer - 3D-Prn
SUBSYSTEM=="usb",SUBSYSTEMS=="usb",DRIVERS=="usb",ATTRS{idVendor}=="0315 
",ATTRS{idProduct}=="0001",MODE="0666"


ATTRS{idVendor} und ATTRS{idProduct} musst Du entsprechend der Ausgabe 
von
journalctl beim Anstecken des USB2RS232 Adaptern entnehmen.

Viel Erfolg
Markus

[Pete K. (pete77)]

Robert B. schrieb:
> Leider bekomme ich die Ausgabe 'K' nicht auf meinem Rechner (Terminal)
> angezeigt.

Woher weisst Du, dass K gesendet wurde? Mir fehlen hier Debug-Ausgaben 
und auch das STM-Programmlisting. Werden evtl. Fehlerrückgaben der 
aufgerufenen Funktionen ausgewertet?

[Martin H. (horo)]

Bitte auch den relevanten Ausschnitt (STMicroelectronics Virtual COM 
Port) aus "lsusb -v" zeigen (Aufruf als User möglich), mein NanoVNA-H 
auf ttyACM0 ergibt dies:

...
Bus 002 Device 028: ID 0483:5740 STMicroelectronics Virtual COM Port
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0483 STMicroelectronics
  idProduct          0x5740 Virtual COM Port
  bcdDevice            2.00
  iManufacturer           1 STMicroelectronics
  iProduct                2 ChibiOS/RT Virtual COM Port
  iSerial                 3 400
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0043
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      0 
      iInterface              0 
...

Hierbei sind die bInterface...-Zeilen interessant, manche 
Implementierungen verwenden andere Werte für bInterfaceProtocol (=1: ich 
bin ein Modem mit AT-Kommandos), dann greift zunächst der ModemManager 
zu und verschluckt eventuell Zeichen - siehe 
https://github.com/DiSlord/NanoVNA-D/issues/11

Vielleicht kommt dann auch minicom durcheinander, das auch eine Menge 
von Modem-Handling automatisch abhandeln kann. Daher ist der Vorschlag 
oben hilfreich, es mit einem anderen Terminal-Programm, z.B. putty zu 
probieren.

[Robert B. (robertoneu_95)]

Hallo liebe Forum-Mitglieder,

ich musste leider heute länger arbeiten und hatte deswegen kaum Zeit 
mich zu melden bzw. eure Antworten in Ruhe zu lesen.

Erstmal vielen lieben Dank für eure zahlreichen Hilfestellungen.

Also ich habe den Befehl "sudo dmesg" unmittelbar nachdem ich das STM32 
Board mit dem PC verbunden hab ausgeführt. Das Bild 
(Bildschirmfoto_von_2022-07-28_19-41-12.png ) habe ich hochgeladen. 
Außerdem habe ich mein Code, wie erwünscht mit hochgeladen.

Und ja, ich habe es auf Windows getestet und es hat geklappt, aber der 
Code ist nicht der selbe, weil ich den neu geschrieben habe. Es ist 
nicht ausgeschlossen, dass ich dort ein Fehler habe. Muss mal mit dem 
Oszi ran.

Die Ausgabe für "lsusb -v" ist folgende:

    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
------------------------------------------------------------------------ 
-----

Wirklich erstaunlich, was für tolle Tipps ich hier bekommen habe. Muss 
die mal jetzt nach und nach Abarbeiten.

Vielen lieben Dank.

Grüße
Robert

[TomA (Gast)]

Hallo Robert B.

Entschuldige bitte die Unterstellung. Jetzt habe ich gelernt nicht zu 
verallgemeinern.

Nichts für ungut. Tom

[Martin H. (horo)]

Robert B. schrieb:
> Die Ausgabe für "lsusb -v" ist folgende:
>
>        bInterfaceClass         9 Hub
>        bInterfaceSubClass      0
>        bInterfaceProtocol      0 Full speed (or root) hub
>        iInterface              0

Das ist aber nicht die Info zur gesuchten Schnittstelle, sondern ein 
Hub, vermutlich intern - lsusb listet alle (internen wie externen) 
USB-Geräte auf, eingrenzen könntest Du es mit

lsusb -v -d 0483:

Das liefert nur die relevanten Informationen zum Hersteller STM, die 
Meldung "Couldn't open device, some information will be missing" ist ok.
Interessant sind die ersten ca. 30 Zeile mit Angaben zum Interface 
Descriptor des Modems.

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      0
      iInterface              0

[Thomas W. (Gast)]

Robert B. schrieb:

> Leider bekomme ich die Ausgabe 'K' nicht auf meinem Rechner (Terminal)
> angezeigt. Unter Windows mit "Realterm" hat alles geklappt. Kennst sich
> vielleicht jemand mit Linux aus und kann mir helfen.

Wenn Dein Programm jenes aus 
Beitrag "Re: UART auf Linux" ist, dann ist es 
nicht ungewoehnlich, dass kein "K" ausgegeben wird:

int main(void)
{
  uar2_tx_init();
  while(1)
  {
    uart2_write('Y');
  }
}

Die Y's, bis zum bitteren Ende erwarte ich. Ich sehe keine K.

Gruesse

Th.

[Robert B. (robertoneu_95)]

Ja, dann eben ein 'Y' hatte das auf Windows mit 'K' gehabt. Deswegen...

[Thomas W. (Gast)]

Ein X fuer ein U vormachen ... Roemische Zahlen...

Pruefe bitte erstmal, ob Deine "Windows"-Version die Initialisierung des 
USARTs anders macht als Deine "Linux"-Version. Denn bei der Komplexitaet 
dieses Programmes sollte es keine Probleme geben. Es sieht eher wie ein 
red Hering aus.

Unabhaengig von allem empfehle ich Dir die Software STM32CubeMX 
(verfuegbar fuer Windows, linux und Apple) von ST. Damit kannst Du den 
Setup des Prozessors wirklich einfach machen (z.B. bei Dir fehlt glaube 
ich die Frequenzeinstellung, ob das Konsequenzen hat: kA).

STM32CubeIDE ist eine IDE die auf Eclipse basiert: It grows on you. Ist 
vom Hersteller unterstuetzt und ist nicht so schlecht (wenn man sich 
dran gewoehnt hat). Und wenn Du ein NUCLEO-F091RC Board hast kannst Du 
wirklich sofort debuggen (Breakpoints et al)

Gruesse

Th.

[Robert B. (robertoneu_95)]

Hi Thomas,

ich verwende den STM32CubeIDE, nur nutze ich halt die HAL-Bib. nicht.

Werde aber wie du schon sagst, mein Code nochmal durchgehen. Kann sein, 
dass ich irgendwo ein blöden Fehler gemacht habe. Außerdem habe ich hier 
zahlreiche Hilfestellungen, an die ich mich auch nochmal ran machen 
werden.

Die Frequenzeinstellung habe ich mit 16MHz.

Gruß
Robert

[Stefan F. (Gast)]

Robert B. schrieb:
> Also ich habe den Befehl "sudo dmesg" unmittelbar nachdem ich das STM32
> Board mit dem PC verbunden hab ausgeführt.
> Das Bild habe ich hochgeladen.

Sieht soweit gut aus.

> Die Ausgabe für "lsusb -v" ist folgende: ...
>     bInterfaceClass         9 Hub
>     bInterfaceSubClass      0
>     bInterfaceProtocol      0 Full speed (or root) hub

Das ist aber nicht dein Mikrocontroller. Ist das alles, wurde nur dieser 
Hub angezeigt, obwohl dmesg zuvor bestätigt hat, dass dein 
Mikrocontroller erkannt wurde?

Vielleicht wurde dein Mikrocontroller wieder abgemeldet, vielleicht weil 
er sich aufgehängt hat. Führe nochmal den dmesg Befehl aus und suche 
nach Fehlermeldungen (nach dem erfolgreichen Anstecken und dem 
Verschwinden) die sich auf USB beziehen.

[Harry L. (mysth)]

Robert B. schrieb:
> ich verwende den STM32CubeIDE, nur nutze ich halt die HAL-Bib. nicht.

Was ist eine "HAL-Bib"?
Klingt wie der Titel eines Kinderbuch.

1. ist HAL keine Bibliothek sondern ein Wrapper-Framework.
2. typisch "super-schlauer Anfänger", der sowieso alles besser kann als 
die ST-Ingenieure...
3. es liegt garantiert nicht am USB

Wenn dir HAL zu kompliziert erscheint, bist du mit STM32 einfach falsch 
aufgestellt.

Das Problem liegt mit an Sicherheit grenzender Wahrscheinlichkeit an 
deinem Code.

Ich hab dir einen funktionierenden Code für die serielle Schnittstelle 
angehängt.

[Robert B. (robertoneu_95)]

Der Port PA2 soll bei mir als UART_TX fungieren. Und das tut er auch, 
weil ich an dem Port ein Motor dran hab und der läuft jetzt durchgehend. 
Somit kann ich ausschließen, dass mein Code Fehler hat.

[Harry L. (mysth)]

Robert B. schrieb:
> Somit kann ich ausschließen, dass mein Code Fehler hat.

Mach dich nicht lächerlich!
Das schliest garnichts aus!

[Robert B. (robertoneu_95)]

Harry L. schrieb:

> 2. typisch "super-schlauer Anfänger", der sowieso alles besser kann als
> die ST-Ingenieure...
> Wenn dir HAL zu kompliziert erscheint, bist du mit STM32 einfach falsch
> aufgestellt.

Ich nutze die HAL-Library nicht, weil ich finde das sie zu viel Arbeit 
abnimmt. Und da ich gerne verstehen möchte was ich mache, habe ich 
beschlossen Bare-Metal zu programmieren. In dem ich viel mit dem 
Datenblatt mich auseinander setzen muss.

>
> Ich hab dir einen funktionierenden Code für die serielle Schnittstelle
> angehängt.

Ok, danke. Ich werde es mir mal angucken.

[Harry L. (mysth)]

Robert B. schrieb:
> Ich nutze die HAL-Library nicht, weil ich finde das sie zu viel Arbeit
> abnimmt.

Das hier ist ein Elektronik- und kein Masochisten-Forum.

[Robert B. (robertoneu_95)]

Harry L. wie gesagt, vielen Danke für deine Hilfestellung.

[Jobst M. (jobstens-de)]

minicom funktioniert sowohl mit hardware-UARTS (ttySx (8250 kompatibel) 
oder ttyAMAx (UART in ARM Controllern - z.B. RasPi)) als auch mit 
USB-UARTs (ttyUSBx oder ttyACMx)

Zur ersten Konfiguration am besten minicom -s versuchen.

Und vielleicht auch erstmal als root versuchen. Sollte es daran liegen, 
ist es ein Rechteproblem.

Gruß
Jobst

[mIstA (Gast)]

Robert B. schrieb:
> Der Port PA2 soll bei mir als UART_TX fungieren. Und das tut
> er auch,
> weil ich an dem Port ein Motor dran hab und der läuft jetzt
> durchgehend.
> Somit kann ich ausschließen, dass mein Code Fehler hat.

Nachdem Dein Code aber keinerlei Anstalten macht einen Motor 
anzusteuern, sagt ein laufender Motor im Besten Fall nichts über Deinen 
Code und seine Probleme aus.

[Robert B. (robertoneu_95)]

Ja, das stimmt. Ich meinte damit, ob mein Port PA2 überhaupt aktiviert 
wird und das wird er. Aber ich habe mein Code gerade auf Windows nochmal 
getestet und er funktioniert leider nicht. Bin aber am durchdrehen, weil 
ich es mir nicht erklären kann, wo der Fehler liegen soll.

Ein Möglichkeit wäre, dass die "alternate function" falsch definiert 
ist.
Ich war der Meinung, dass AFR[0] => Low register und AFR[1] => High 
register ist. Laut Datenblatt ist es mit (GPIOx_AFRL) definiert, das 
wird aber vom Compiler nicht erkannt. Im File "stm32f0xx.h" wird es 
AFR[2] => Low register definiert.

Leider funktioniert es immer noch nicht.

Will es jetzt erst Mal auf Windows zum laufen bringen und dann teste ich 
es auf Linux.

Wird eine lange Nacht.

Grüße
Robert

[Andreas B. (bitverdreher)]

Robert B. schrieb:
> Will es jetzt erst Mal auf Windows zum laufen bringen und dann teste ich
> es auf Linux.

Jetzt hast Du (halt auf die harte Tour) gelernt, dass man niemals 
mehrere Dinge gleichzeitig aendert.

[Robert B. (robertoneu_95)]

Das stimmt.

[Hobby (Gast)]

Um Dein UART unter Linux zu testen, baust Du einfach eine Brücke 
zwischen RX und TX ein. Im Terminal drauf achten, dass der Echo 
abgeschaltet ist. Wenn Du auf jeden Tastendruck eine Antwort bekommst, 
funktioniert auf Linuxseite alles.

[Stefan F. (Gast)]

Hobby schrieb:
> Um Dein UART unter Linux zu testen, baust Du einfach eine Brücke
> zwischen RX und TX ein.

Das geht nicht, denn er hat keine physische UART Schnittstelle. Es ist 
nur eine virtuelle über USB, und die endet im STM32 Mikrocontroller.

[NichtWichtig (Gast)]

Stefan ⛄ F. schrieb:
> Hobby schrieb:
>> Um Dein UART unter Linux zu testen, baust Du einfach eine Brücke
>> zwischen RX und TX ein.
>
> Das geht nicht, denn er hat keine physische UART Schnittstelle. Es ist
> nur eine virtuelle über USB, und die endet im STM32 Mikrocontroller.

Sicher? Ich denke nicht.

Siehe posting #1

Hab ein STM32-Mikrocontroller und versuchen nun, dass dieser Controller
mit meinem Rechner (Linux) kommuniziert. Die Kommunikation läuft über
die UART-Schnittstelle. Um die Ausgabe zu sehen, habe ich mir auf den
Rechner "Minicom" installiert. Der STM32f091 ist per USB an meinem
Rechner angeschlossen.

[Stefan F. (Gast)]

NichtWichtig schrieb:
> Siehe posting #1

ist nicht eindeutig, aber der Screenshot in 
Beitrag "Re: UART auf Linux" ist es.

[Harry L. (mysth)]

Stefan ⛄ F. schrieb:
> NichtWichtig schrieb:
>> Siehe posting #1
>
> ist nicht eindeutig, aber der Screenshot in
> Beitrag "Re: UART auf Linux" ist es.

Er nutzt offenbar enen ST-Link V2.1 auf einem ST-Board, und der hat 
extra Pins um RX/TX zu brücken.

Bei der vollkommen planlosen Vorgehensweise des TO kann man aber sowieso 
nicht helfen...

[NichtWichtig (Gast)]

Stefan ⛄ F. schrieb:
> NichtWichtig schrieb:
>> Siehe posting #1
>
> ist nicht eindeutig, aber der Screenshot in
> Beitrag "Re: UART auf Linux" ist es.

Eindeutig für was?

Da sind devices aufgelistet, nicht mehr und nicht weniger.

Wer da mit wem verbunden ist wird daraus nicht deutlich.

Das er neben der seriellen Verbindung zeitgleich noch per STLink zur 
Laufzeit seine selbst gedengelte Software in den µC läd macht es nicht 
einfacher.

Sooo schlecht ist CubeMX/HAL garnicht, da wäre schon längst was am 
Laufen gewesen und böte Stoff zum Studieren.

[Stefan F. (Gast)]

Harry L. schrieb:
> Er nutzt offenbar enen ST-Link V2.1 auf einem ST-Board, und der hat
> extra Pins um RX/TX zu brücken.

Du hast mich überzeugt.

ttyACM0 gehört zu seinem ST-Link Adapter. Also hat er den wohl 
(hoffentlich) mit Rx und Tx seines Mikrocontrollers verbunden.

Unklar ist mir dann aber
> Der STM32f091 ist per USB an meinem Rechner angeschlossen.

Welche Rolle spielt denn nun dessen USB Schnittstelle?

[Harry L. (mysth)]

Stefan ⛄ F. schrieb:
> Unklar ist mir dann aber
>> Der STM32f091 ist per USB an meinem Rechner angeschlossen.
>
> Welche Rolle spielt denn nun dessen USB Schnittstelle?

Gar keine - der TO kennt den Unterschied nicht.

[Robert B. (robertoneu_95)]

Nur zu Info.

Hab mir ein neues Board gekauft und es funktioniert nun alles.

Vielen Dank, für sie zahlreichen Hilfestellungen.

VG
Robert

[Keks F. (keksliebhaber)]

Hallo,

hat das Board evtl. einen anderen Chipsatz, oder ist der Kernel 
inzwischen geupdated worden?

Es gab einen Bug im Linux-Kernel, der manche Chipsätze betraf. Ich 
dachte zuerst meine Arduino-Klone wären kaputt, oder es lag an Arduino 
IDE. Unter Windows funktionierte es.
Es lag tatsächlich am Kernel, der einen Patch brauchte. Ich kann nachher 
mal gucken, ob ich den Kernel Bugreport noch finden kann. Die Situation 
ist ein Jahr her.

[Robert B. (robertoneu_95)]

Hallo Keks F.,

bitte entschuldige die späte Rückmeldung, aber ich war beruflich 
unterwegs.
Also, es nach einem Update hat sich viel an meinem Betriebssystem 
(Linux) getan. Werde es mal die Tage nochmal versuchen und gebe dir 
Bescheid.

Vielen Dank erstmal.