Forum: Mikrocontroller und Digitale Elektronik Kommunikation AVR <> PC über RS232


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 ein Gast (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe ein allgemeines Problem mit der Kommunikation zwischen einem AVR 
und dem dem PC. Ich möchte mir ein System aufbauen womit ich Daten von 
einem ATMega mittels PC verarbeiten kann. Habe mir dazu das neue Visual 
Basic (Studio) angesehen und festgestellt, dass mir dies gegenüber dem 
alten vor ca. 20 Jahren zu aufgebläht ist. Man braucht schon etwas 
Fachwissen um überhaupt eine Verbindung zu stande zu bringen. Also 
zurück zu Mathlab bzw. jetzt SciLab. Funktioniert aber der weitere 
Einstieg ist mühsam. Da ich mich jetzt über 10 Jahre nicht damit 
beschäftigt habe, habe ich mal so eine Kommunikation mit einer S7-1500 
aufgebaut (was auch mein Beruf ist) und die Daten in DBs gespeichert. 
Aber die Weiterverarbeitung in Tabellen oder ähnlich ist nur mit dem 
alten Prodave möglich.

Meine Frage ist eigentlich: Wie macht ihr es? Ist ein System mit VBA 
(Excel) sinnvoll? Das System soll möglichst plattformübergreifend 
angewandt werden (außer vielleicht MAC).
Bin gespannt auf eure Vorschläge. Eilt aber absolut nicht, denn jetzt 
ist WE

Viele Grüße aus dem Norden
Jo

von Baendiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mir ist nicht ganz klar was du vorhast aber ich versuche Mal:

Problem 1: wie wird der AVR an den Computer angeschlossen? Da würde USB 
(haben nur wenige AVRs) oder R232 (ob dann über einen USB Adapter wie 
von FTDI und TTL Pegel sei mal dahingestellt) üblich sein. Ich 
persönlich würde dir zu RS232 bzw UART raten weil du auf der AVR Seite 
so nur ein UART ansprechen musst.

Problem 2: Daten auf PC Seite empfangen. Für sämtliche serielle 
Verbindungen (USB Adapter brauchen separate Treiber) kannst du quasi 
alles nehmen. Ich nehme gerne Python.

Willst du die Daten live verarbeiten? Wenn nicht könnte deine Software 
die Daten bspw. als CSV speichern und die kannst du dann in Excel 
importieren.

von Baendiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Oh tut mir leid im Titel stand ja RS232...

von ein Gast (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hallo Baendiger,
du liegst schon ganz richtig. An Python habe ich auch schon gedacht. Ein 
Einsteigerbuch liegt vor mir. Die objektorientierten Sprachen wie C++, 
Visual Studio oder Delphi driften mir langsam ab. Und ständig die 
Probleme mit Windows und den Treibern für die RS232. Die Dll's im Netz 
funktionieren sehr selten. Und ich hoffe dass mein PC mit 2 echten 
COM-Ports mir noch lange erhalten bleibt. Wie schön war doch das alte 
Turbo-Pascal unter DOS!
Danke
Jo

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ein Gast schrieb:
> Und ständig die Probleme mit Windows und den Treibern für die RS232. Die
> Dll's im Netz funktionieren sehr selten.

Was für DLLs? Wenn Du den passenden Treiber installierst, kannst Du 
einen USB-UART-Chip exakt so ansprechen wie einen "normalen" COM-Port.

Die FTDI-Treiber waren bei mir bisher immer stressfrei.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Baendiger schrieb:
> Willst du die Daten live verarbeiten? Wenn nicht könnte deine Software
> die Daten bspw. als CSV speichern und die kannst du dann in Excel
> importieren.
Warum so umständlich. Excel kann doch auch direkt über die serielle 
Schnittstelle kommunizieren.
Beitrag "Serielle Schnittstelle mit VB auslesen und in Excel Darstellem"

von Holger Z. (boomboommagic)


Bewertung
0 lesenswert
nicht lesenswert
ein Gast schrieb:
> Habe mir dazu das neue Visual
> Basic (Studio) angesehen und festgestellt, dass mir dies gegenüber dem
> alten vor ca. 20 Jahren zu aufgebläht ist

Interessant das den "alten Sachen " immer nachgeweint wird , aber es 
schnell festgestellt wird das die "Neuen" noch weniger taugen  ..
Warum nicht beim alt bewehrtem bleiben?

Das ging vor 20 Jahren genauso gut wie heute - einfach , simpel , 
schnell :-)

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Da nimmst du am besten die Programmiersprache, die du schon am besten 
kennst.

Bei mir wäre das Java, aber Java bringt man nur mit Verrenkungen bei, 
serielle Ports anzusteuern. Deswegen ist meine zweite Wahl dann C oder 
C++ mit der Qt Creator IDE. Die kann rechts schlank sein oder ultra fett 
- kommt ganz drauf an, wie viele optionale Komponenten du mit 
installierst.

Im Absatz "15 Minuten Programmier-Beispiel" der folgenden Seite findest 
du eine Anregung für den Start: 
http://stefanfrings.de/serial_io/index.html

: Bearbeitet durch User
von ein Gast (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Anregungen. Wolfgang und Stefan kenne ich ja schon länger 
in diesem Forum. Demnächst werde ich wohl auch meinen alten Account 
wieder beleben. Und nein! ich weine der alten Technik nicht nach sondern 
nutze sie noch. Kann sogar mit einem selbstgebauten EPROMMER noch U555 
brennen unter DOS mit TPascal. Aber wer möchte noch den Umgang mit U555?
Mein Ziel ist es meine Modellbahn mit dem PC über AVR zu steuern. Aber 
nur die Verriegelungen. Gefahren wird mit DDC per Handregler. Meine 
Enkeln wollen schalten! Aber gerade macht mich die LEGO-Bahn nervös. 
Weniger ist manchmal mehr.
Danke und schönes WE
Jo

von Mal einwerfen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was du brauchst is ein Protokoll. Das ist der Inhalt der Kommunikation 
zusaetzlich zu deinen Daten. Ohne Protokoll machen Daten keinen Sinn.

von Alexander K. (pucki)


Bewertung
-1 lesenswert
nicht lesenswert
Was ist an 10 Zeilen PRG.-Code aufgebläht.

Der unten angezeigter Code ging an einen Arduino der via USB an den PC 
angeschlossen ist. Der Text (Inhalt von "hp_e_text_senden.Text") wurde 
dort empfangen und via 433 Mhz Modul an einen 2 Arduino gefunkt und dort 
auf einen LED-Display angezeigt.

Ist einer meiner Text-Codes um bestimmte Funktionen  (hier die 
Funkstrecke PC-Arudino) zu testen und zu verstehen. JA auch ich muss 
üben ;)

Mehr Code hat das ganze Programm nicht.


** code ***
** in den Text-Objekt hp_e_text_senden.Text steht der Text der zu senden 
ist
*** hp_l_com_port ist ein Pull-down wo die Com-Ports aufgelistet sind.
***
*** Kann man alles eleganter lösen, aber das ist ein Test-Projekt nix 
ernstes.


Public Class hp
  Dim S_Port As New IO.Ports.SerialPort

  Private Sub hp_Load(sender As System.Object, e As System.EventArgs) 
Handles MyBase.Load
    hp_l_com_port.SelectedIndex = 10
  End Sub

  Private Sub hp_b_senden_Click(sender As System.Object, e As 
System.EventArgs) Handles hp_b_senden.Click

    If S_Port.IsOpen Then
      S_Port.Close()
    End If
    S_Port.PortName = "COM10"
    S_Port.BaudRate = 9600
    S_Port.Open()
    tx$ = hp_e_text_senden.Text + Chr(13)
    S_Port.Write(tx$)
    S_Port.Close()
  End Sub
End Class


*** end Code ***
Gruß

   Pucki

von ein Gast (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Denke mein Protokoll habe ich. Ich sende immer ein word über die COM1.
Alle verschiedenen Objekte wie Weichen, Signale oder Häuser sind auf 30 
begrenzt. MSB-Byte ist die Adrese und LSB sind die Nutzdaten. Ein word 
kann man auch im Atmel schön aufteilen.
Übrigens: Python gefällt mir!
Seht euch mal die Ansteuerung der seriellen Schnittstelle an.
Jo

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ein Gast schrieb:
> Denke mein Protokoll habe ich. Ich sende immer ein word über die COM1.
> Alle verschiedenen Objekte wie Weichen, Signale oder Häuser sind auf 30
> begrenzt. MSB-Byte ist die Adrese und LSB sind die Nutzdaten. Ein word
> kann man auch im Atmel schön aufteilen.
Genau da hast du dein Problem. Du brauchst irgend einen Mechanismus, um 
Sender und Empfänger zu synchronisieren. Der Empfänger muss erkennen 
können, ob er das MSB oder das LSB erhalten hat. Sonst gibt es Chaos, 
wenn mal ein Störimpuls als Start eines zusätzlichen Bytes interpretiert 
wird, weil der Empfänger danach MSB und LSB falsch zuordnet.

von oldmax (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi
Nun,was hast du gegen VB? Ich hab ein (kleines) Buch geschrieben. Teil 1 
"Programmieren in VB" mit einer kleinen  Datenbankanwendung und Teil 2 
Programmieren in Assembler eines AtMega. Ich glaub, das wär was für 
dich. Kannst du kostenlos bei Makerconnect.de runterladen. Dahinter 
steckt eine Programmentwicklung, die dir Einblick in den Controller zur 
Laufzeit bietet. Ist kein trockener Stoff, sondern trotz der rund 800 
Seiten leicht verständlich,soweit ich es als Autor beurteilen kann. 
Leider habe ich nicht das erhoffte Feedback erhalten, welches mir 
darüber Auskunft hätte geben können. Aber es gab auch nix negatives und 
so gehe ich Mal davon aus, das mein Ziel erreicht wurde. Egal, solltest 
du dich damit befassen, ich würde mich auf jeden Fall über eine Antwort 
freuen.
Gruß oldmax

von oldmax (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi
Sorry,, hab den Link vergessen
[[https://www.makerconnect.de/media/u...ocontroller Teil 1 und 2 Stand 
26.07.2019.pdf]]
Und ja, das ist frei verfügbar, die Rechte liegen bei mir.
Gruß  oldmax

von Wühlhase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> ein Gast schrieb:
>> Denke mein Protokoll habe ich. Ich sende immer ein word über die COM1.
>> Alle verschiedenen Objekte wie Weichen, Signale oder Häuser sind auf 30
>> begrenzt. MSB-Byte ist die Adrese und LSB sind die Nutzdaten. Ein word
>> kann man auch im Atmel schön aufteilen.
> Genau da hast du dein Problem. Du brauchst irgend einen Mechanismus, um
> Sender und Empfänger zu synchronisieren. Der Empfänger muss erkennen
> können, ob er das MSB oder das LSB erhalten hat. Sonst gibt es Chaos,
> wenn mal ein Störimpuls als Start eines zusätzlichen Bytes interpretiert
> wird, weil der Empfänger danach MSB und LSB falsch zuordnet.

Und genau deswegen wäre es besser, einen USB-UART-Wandler wie z.B. einen 
FTDI-Käfer zu benutzen.
Da kann man das ganze Fehlerkorrekturgeraffel der darunterliegenden 
Hardware überlassen, das USB-Protokoll bringt eine DRC-Prüfung schon von 
Haus aus mit. Da muß man nichts mehr händisch herumfrickeln.

Um das kurze Stück zwischen AVR und Wandler-IC muß man sich noch 
kümmern, aber das kann man noch relativ leicht beherschen.

Ach ja...und er ist nicht mehr auf seine 20 Jahre alte Möhre mit echten 
COM-Ports angewiesen.

von Mario M. (thelonging)


Bewertung
0 lesenswert
nicht lesenswert

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
oldmax schrieb:
> Ist kein trockener Stoff, sondern trotz der rund 800
> Seiten leicht verständlich,soweit ich es als Autor beurteilen kann.
> Leider habe ich nicht das erhoffte Feedback erhalten, welches mir
> darüber Auskunft hätte geben können.

Geht mir genau so. Die Leser trauen sich wohl allgemein nicht, den Autor 
zu kontaktieren - warum auch immer-

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wühlhase schrieb:
> Und genau deswegen wäre es besser, einen USB-UART-Wandler wie z.B. einen
> FTDI-Käfer zu benutzen.

Die Störung kann genauso gut zwischen USB-UART-Wandler und µC auftreten. 
Da bringen die Fehlerschutzmaßnahmen des USB-Protokolls prinzipiell zwar 
eine Verringerung der Fehlerwahrscheinlichkeit aber keinen echten 
Schutz. Und wenn das Kind einmal in den Brunnen gefallen ist, bietet die 
genannte Art der Übertragung keine Möglichkeit zur Resynchronisation.
Ein Fehler kann auch auftreten, wenn der µC nach einem Reset zwischen 
den beiden Bytes anfängt, den Datenstrom zu verarbeiten.

von Alexander K. (pucki)


Bewertung
-1 lesenswert
nicht lesenswert
oldmax schrieb:
> Hi
> Nun,was hast du gegen VB? Ich hab ein *(kleines)* Buch geschrieben.

.....

> Ist kein trockener Stoff, sondern trotz der rund *800*
> Seiten leicht verständlich,soweit ich es als Autor beurteilen kann.

Was ist bei dir eigentlich ein großes Buch. ???


Aber der Thread-Ersteller will ja kein VB sonst würde er mein kleinen 
Code nehmen, und etwas erweitern.

Gruß

   Pucki

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Alexander K. schrieb:
> Was ist bei dir eigentlich ein großes Buch. ???
Lass dich nicht von der Seitenanzahl täuschen. Eigentlich sind das /zwei 
kleine/ Bücher. In zwei getrennten Dateien wäre das schon viel 
handlicher ;-)

von oldmax (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi
Danke für die Korrektur vom Link. Nun ja, zwei "Bücher" wären eine 
Alternative, aber das Thema "VB" hat mich herausgefordert. Eigentlich 
bin ich eher Delphi zugeneigt, hatte aber Probleme  mit der (teuren) 
Orginalsoftware und die Alternative "Lazarus" war nicht mein Ding. VB 
hingegen hat mir ziemlich schell zum Erfolg verholfen und so ist 
eigentlich die Dokumentation, wie ich zu meinem Programm kam, in diesem 
Buch zusammengefaßt. Da sich VB  mit der Datenbank bestens für mein 
Vorhaben eignete, eine Zeit- und Rundenerfassung für Slotcarbahnen, 
Mitgliederverwaltung und noch ein paar Zutaten, dachte ich mir, es 
könnte für Modellbahner, oder -bauer ebenfalls ein interressanter 
Einstieg in die Welt der kleinen Controller werden. Daher auch die 
Veröffentlichung. Das ich mit Assembler arbeite, sollte niemanden 
schrecken. Assembler ist mitnichten "out" und wenn man es genau 
betrachtet, einfacher wie die Hochsprachen. Kommt natürlich auf den 
Anwendungsfall an. Komplizierte mathematische Aufgaben würd ich auch 
nicht mit Assembler lösen, aber einfache Steuerungsaufgaben schon. Egal, 
im Buch steht's, wie's gemacht wird. Viel Spaß.
Gruß oldmax

von ein Gast (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,
die Kommunikation mit python läuft schon. Übrigens beginnt das MSB bei 
mir immer mit einer 1 und das LSB immer mit einer 0! Und ich sende das 
word 2 mal und frage danach das LSB auf Gleichheit ab. Bisher ist noch 
kein fehler aufgetreten.
Natürlich sehe ich mir auch mal das Buch von Oldmax an. Denke es steckt 
auch viel Mühe dahinter und man sollte so etwas respektieren.
Schönen Sonntag
Jo

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.

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