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
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.
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
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.
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"
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
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
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
Was du brauchst is ein Protokoll. Das ist der Inhalt der Kommunikation zusaetzlich zu deinen Daten. Ohne Protokoll machen Daten keinen Sinn.
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
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
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.
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
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
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.
oldmax schrieb: > Sorry,, hab den Link vergessen https://www.makerconnect.de/media/user/oldmax/PC%20und%20Mikrocontroller%20Teil%201%20und%202%20Stand%2026.07.2019.pdf
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-
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.
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
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 ;-)
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
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
Ein interessantes Thema. Die Kommunikation mit einem Mikrokontroller wird wohl stiefmütterlich behandelt. Sehr viele Beiträge dazu im Netz aber fast alle unbrauchbar. Ich habe es vor Jahren über Excel2010 und der rapi.dll gelöst. Jetzt nehme ich SciLab dazu. Sendet aber auch nur ein Byte und Zeichen!
Hi auch Oldi schrieb: > Sehr viele Beiträge dazu im Netz > aber fast alle unbrauchbar. Wieso unbrauchbar? Und auf welche Beiträge bezieht sich deine Meinung? Nur um es mal anzusprechen, einen paßgenauen Beitrag auf irgendeinen Nutzer, Bastler oder was auch immer wirst du nicht finden und kann auch keiner leisten. Bestenfalls gibt es Anregungen und Anregungen. Letztlich muß jeder für sich entscheiden, was er mit der Information macht und wie er sie für seine Zwecke nutzen kann. Das Buch, welches ich geschrieben habe, kann da auch nicht gezielt auf irgendeine Anwendung eingehen, aber die Beschreibung, wie ein Proggramm aus dem Nichts entsteht, wie es schrittweise in eine gewünschte Zielrichtung gebracht wird, wie Programmelemente erweitert und mit Funktionalität ausgestattet werden, das sind Beispiele, die ein interessierter Hobbyist durchaus für Grundlage eigener Anwendungen nutzen kann. Ich sage nicht, das es immer leicht ist, etwas neu oder für sich zu erfinden, denn genau das ist eine persönliche Programmentwicklung. Dazu ein Beispiel: Eine Gruppe von 20 Personen haben sich in einer Scheune eine Slotcarbahn gebaut. (Carrera oder Eigenbau ist erst mal egal.) Nun möchten sie nicht nur Runden, sondern auch Zeiten erfassen und diese den Teilnehmern zuordnen. Aber das ist noch nicht alles. Da wäre noch eine Startsequenz zu generieren, ein Frühstart zu erkennen, die schnellste Runde im aktuellen Rennen sowie die Tagesbestzeit zu erfassen usw. Es soll ein komplettes Rennen gemanagt werden, ob mit 10 oder 100 Teilnehmern. Das alles in einem leicht bedienbaren PC-Programm. Nun, das alles könnte ich liefern, aber es wäre nur diese eine Interessengruppe. Wie sieht es mit Modellbahnern aus, die mit richtigen Fahrplänen liebäugeln? Oder jemand, der seine Wohnung oder Haus mit Sensoren ausstatten möchte, um Temperaturen und offene Fenster oder Türen zu erfassen? Da sind die gleichen Grundlagen, aber völlig unterschiedliche Programme erforderlich. Aus genau diesem Grunde haben u. A. Stefan und meine Wenigkeit versucht, dem Laien, der kein entsprechendes IT- Studium absolviert hat und trotzdem mit dieser Materie arbeiten will, eine Grundlage zu liefern. Also verurteile nichts als nicht nützlich, wenn du es nicht verstehst oder anwenden kannst, sondern frage beim Urheber nach. Der kann dann seine Gedankengänge erläutern oder auch erkennen, das er Blödsinn geschrieben hat und es korrigieren. Gruß oldmax PS: und ja, "auch Oldi", ich bin schon etwas betagt....
oldmax schrieb: > und die Alternative "Lazarus" war nicht mein Ding. Was heisst "war", ist das schon laenger her? Lazarus ist ziemlich gut und gerade fuer so eine Anwendung bestens geeignet. Die nicht-zusammenheangenden Fenster der Lazarus-IDE sind gewoehnungsbeduerftig, es laesst sich damit aber sehr gut arbeiten und man kann das auch einstellen, dass alles in einem Fenster vereinigt ist.
Hi Sorry, ich wollte Lazarus nicht abwerten, aber ich hatte damals zu viele Schwierigkeiten, mit dieser Entwicklungsumgebung klarzukommen. Das heißt, es lag nicht nur an Lazarus, lag auch an mir und meiner vorgefertigten inneren Routinen, die ich schwer ablegen konnte. Auch fehlte mir die Lust, Lazarus etwas abzugewinnen. Deswegen ist aber Lazarus nicht schlecht. Aber bitte, nicht wieder die Diskussion ber spezielle Programmiersprachen und Entwicklungsumgebungen. ich hab zu VB halt schneller einen Draht gehabt und schneller umsetzen können, was ich wollte. Das ist alles. Deswegen lob ich VB nicht in den Himmel, oder Delphi oder was auch immer. Jeder sollte das nutzen, was ihm liegt oder der Beruf vorschreibt. Letzteres ist ein hartes Brot.... Gruß oldmax
Hi Sorry, ich wollte Lazarus nicht abwerten, aber ich hatte damals zu viele Schwierigkeiten, mit dieser Entwicklungsumgebung klarzukommen. Das heißt, es lag nicht nur an Lazarus, lag auch an mir und meiner vorgefertigten inneren Routinen, die ich schwer ablegen konnte. Auch fehlte mir die Lust, Lazarus etwas abzugewinnen. Deswegen ist aber Lazarus nicht schlecht. Aber bitte, nicht wieder die Diskussion über spezielle Programmiersprachen und Entwicklungsumgebungen. ich hab zu VB halt schneller einen Draht gehabt und schneller umsetzen können, was ich wollte. Das ist alles. Deswegen lob ich VB nicht in den Himmel, oder Delphi oder was auch immer. Jeder sollte das nutzen, was ihm liegt oder der Beruf vorschreibt. Letzteres ist ein hartes Brot.... Gruß oldmax
Die Kommunikation zwischen eines PC und mehrere Arduino ist kinderleicht. Das habe ich mal auf einer Test-Anordnung in weniger wie einer Stunde hin bekommen. (ok. mit etwas Hilfe aus eine Blog). Ich habe dafür 3 Arduino's genommen. Gruß Pucki
Ja pucki, wenn die Kommunikation so Kinderleicht ist, dann verrate uns doch mal den Code. Bisher habe ich in diesem Beitrag noch keine Lösung gefunden.
VB-MD schrieb: > Ja pucki, > wenn die Kommunikation so Kinderleicht ist, dann verrate uns doch mal > den Code. Bisher habe ich in diesem Beitrag noch keine Lösung gefunden. Alexander K. schrieb: > 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. WER LESEN KANN IST KLAR IM VORTEIL Für mich ist das Kommunikation wenn einer was "sagt" und der andere es versteht und das tut was man ihm sagt. Bei meinen Arduino's funktioniert das Prima. Hier im Forum leider NICHT Gruß Pucki
Wühlhase schrieb: > Wolfgang schrieb: >> 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. Das nützt bezüglich dieses Problems überhaupt nix. > Da kann man das ganze Fehlerkorrekturgeraffel Ein Fehler ist nur eine Möglichkeit, asynchron zu werden. Viel häufiger (nämlich mit ca. 50% Wahrscheinlichkeit) passiert das bereits zu Beginn der Kommunikation. Nämlich immer dann, wenn der Empfänger zu einem "ungünstigen" Zeitpunkt mit dem Empfang beginnt und das erste vollständig und fehlerfrei empfangene eben nicht das erste des aus zwei Bytes bestehenden Datenpaketes ist. Man kann zwar die Wahrscheinlichkeit für den günstigen Fall dadurch verbessern, dass man zwischen den Datenpaketen längere Pausen lässt, aber das war's auch schon, was möglich ist, die Fehlersituation kann immer noch auftreten, sie ist nur weniger wahrscheinlich.
c-hater schrieb: > Man kann zwar die Wahrscheinlichkeit für den günstigen Fall dadurch > verbessern, dass man zwischen den Datenpaketen längere Pausen lässt, > ... ... und dann beim Empfänger ein Time-Out einbauen, der den nicht vollendeten Empfang abbricht.
ein Gast schrieb: > Ist ein System mit VBA (Excel) sinnvoll? Ähm, nein. Aber selbst VBA kann mit der seriellen Schnittstelle reden. Pro Schnittstelle halt nur mit 1 Mikrocontroller, RS232 ist ja kein Bus-System. Modernerweise würde man USB nutzen, das erspart die MAX232 Pegelwandler und kann softwaretechnisch wie eine serielle Schnittstelle bedient werden. Der Mikrocontroller braucht dazu halt einen externen FT232RL, oder internes USB. Als portable Software wohl eher National Instruments LabView, wenn man sich die Steuerung zusammenklicken will.
Hi VB-MD schrieb: > Bisher habe ich in diesem Beitrag noch keine Lösung gefunden. Nun, deutlicher gehts nicht. Mario M. schrieb: > oldmax schrieb: >> Sorry,, hab den Link vergessen > > https://www.makerconnect.de/media/user/oldmax/PC%20und%20Mikrocontroller%20Teil%201%20und%202%20Stand%2026.07.2019.pdf Wem das Buch zuviel ist, kann sich aus dem Inhaltsverzeichnis die Stelle raussuchen, die für ihn interessant ist, z. B. die Beschreibung und den Aufbau einer Kommunikation AVR mit eiinem PC. Aber wer natürliInformation ignoriert und eine gezielte fertige Programmierung erwartet, dem kann auch kostenlos nicht mehr geholfen werden. Da sollten wir uns dann mal über einen preis einigen. Auch wenn der letzte Satz überflüssig war, es ist mir unverständlich, wie ein Angebot einer solch umfangreichen und kostenlosen Hilfe einfach ignoriert wird. So ein bischen lesen solltet ihr doch noch können. Und die Beispieldateien lassen sich dann sogar noch mit C&P übernehmen. Gruß oldmax
Hi Sorry, aber ab und zu verschluckt meine Tastatur Zeichen oldmax schrieb: > z.B. die Beschreibung und den > Aufbau einer Kommunikation AVR mit eiinem PC. Aber wer > natürliInformation ignoriert und eine gezielte fertige Programmierung > erwartet, dem kann auch kostenlos nicht mehr geholfen werden. Da sollten > wir uns dann mal über einen preis einigen. Sollte heißen: z.B. die Beschreibung und den Aufbau einer Kommunikation AVR mit einem PC. Aber wer natürlich diese Information ignoriert und eine gezielte fertige Programmierung erwartet, dem kann auch kostenlos nicht mehr geholfen werden. Da sollten wir uns dann mal über einen Preis einigen. Ich glaub, ich muß mich mal wieder anmelden, um solche Fehler korrigieren zu können. Gruß oldmax
Hallo oldmax, Richtig: „Egal, im Buch steht's, wie's gemacht wird. Viel Spaß.“ Und wer AVR Controller mit Bascom programmiert erkennt die Gemeinsamkeiten. Hier mal mein Beispiel. https://www.makerconnect.de/index.php?threads/ds3231-mit-systemzeit-von-pc-aktualisieren.4291/post-45327 P.S. Lebe schon 67 Jahre in Deutschland und hab mir dies alles nur als Hobby angeeignet und da sind solche praxisbezogene Bücher schon lesenswert. Gruß fredylich
Visual Studio (ob Basic oder C#) hätte den Vorteil, dass es wirklich überall läuft. Mit Mono läuft die exe sogar auf einem RaspiZero. Es kostet nichts und schwierig ist das Thema serial.port wirklich nicht. Außerdem gibt es viele fertige Vorlagen. => Ich würde es so machen!
Michael D. schrieb: > => Ich würde es so machen! Genau. ;) Und deshalb habe ich es so gemacht. Der Code oben funktioniert 100 % . Da ist NIX weggelassen. Zu ergänzen kann man eine Port-Erkennung, was mir grundsätzlich zu lästig ist, da in den Port einfach in eine INI-Datei abspeichere. Und selbstverständlich was er senden soll. Ich schicke immer eine einfach Prüfung mit, damit ich sicher bin das alles angekommen ist. (Ist in den billigen Test-Code nicht drin). Und selbstverständlich die NR. des Arduino der auf den Sende-"Text" reagieren soll. Auf den Arduino läuft dann so was wie : Ist Sendekennung = "meine" then 'Reagiere else ' lass es sein und warte bis du dran bist ;) End if Gruß Pucki
Hier der Code auf den Arduino. Es handelt sich dabei um einen Code aus den Internet den ich zur Testzwecken modifiziert habe. Bitte nicht über die seltsame SUB wundern. Irgendwie funktioniert es anders nicht richtig. Nebenbei auch ein Grund warum ich zu B4X gewechselt bin. Da funktioniert die Ansteuerung sauber. Gruß Pucki
Was aus dem Beitrag geworden ist, ist schon seltsam. Es wird irgendwie
am eigentlichen Thema vorbeidiskutiert. Was wollte denn der TO
eigentlich???
Und das Buch von Oldmax habe ich mir mal angesehen. Ab Seite 302 die
Beschreibung der Komm. aber mit Open Eye. Warum? Ich setze dann mal
einen minimalen Code in VB2010 hier rein. Abgespeckt! Das Empfangen ist
schon vorbereitet. Senden funktioniert problemlos. In der form1 nur 3
Buttons einfügen und 3 Textboxen. Aber als Erleichterung auch die
gezippte Variante des Projektes. Und Mann kann Zahlen von 0 bis 65535 (2
Byte) eingeben und diese kommen auf der anderen Seite (ATMega32) sauber
an!
Die DtrEnable-Eigenschaft des SerialPort-Controls habe ich noch auf
False belassen.
Gruß vom Jo
'Imports System.IO.Ports
Public Class Form1
Shared ZSend As Short
Shared MyArray() As Byte
'SerialPort1.Read(EmpfU555, 0, 2)
'U555Wert = BitConverter.ToUInt16(EmpfU555, 0)
'Private Sub com_DataReceived(ByVal sender As Object, ByVal e As
SerialDataReceivedEventArgs)
'Dim data As Byte = CByte(SerialPort1.ReadByte())
'Dim data As Byte = CByte(com.ReadByte())
'Debug.Print(data)
'End Sub
Private Sub TextBox1_TextChanged(sender As System.Object, e As
System.EventArgs)
End Sub
Private Sub TextBox2_TextChanged(sender As System.Object, e As
System.EventArgs)
End Sub
Private Sub Button1_Click(sender As System.Object, e As
System.EventArgs) Handles Button1.Click 'Connect-Button
Try
SerialPort1.PortName = TextBox1.Text
SerialPort1.BaudRate = TextBox2.Text
SerialPort1.Open()
Button1.Enabled = False
Button2.Enabled = True
Button4.Enabled = True
Catch ex As Exception
MsgBox("Verbindung konnte nicht hergestellt werden!")
SerialPort1.PortName = "COM1"
SerialPort1.BaudRate = "9600"
End Try
End Sub
Private Sub Button2_Click(sender As System.Object, e As
System.EventArgs) Handles Button2.Click 'Senden-Button
TextBox3.Focus()
'Fokus wird auf TextBox3 gesetzt
Try
ZSend = CInt(TextBox3.Text)
'Text in Integer umwandeln (CStr-Interger in Text)
If ZSend > -1 And ZSend < 65535 Then
MyArray = BitConverter.GetBytes(ZSend)
End If
Catch ex As Exception
MsgBox("Falsche Eingabe!")
End Try
'System.Threading.Thread.Sleep(50)
'Warten 50ms
SerialPort1.Write(MyArray, 0, 2)
End Sub
Private Sub Button4_Click(sender As System.Object, e As
System.EventArgs) Handles Button4.Click 'Disconnect-Button
SerialPort1.Close()
Button1.Enabled = True
Button2.Enabled = False
Button4.Enabled = False
End Sub
Private Sub Form1_FormClosing(sender As Object, e As
System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
If SerialPort1.IsOpen = True Then
SerialPort1.Close()
End If
End Sub
End Class
Danke VB-MD, den Code kopiert und ins VB eingefügt. Und bin sehr überrascht! Ging auf anhieb. So sollte es eigentlich sein. Mit so etwas kann man echt was anfangen!!! Leider fehlt der Empfang noch. Denke die anderen werden auch dazu nichts beitragen können. Eigentlich schade dass in diesem Forum die Unsachlichkeit überwiegt. Also VB-MD >> weiter so! Gruß von der Küste Volker
Hi VB-MD schrieb: > Und das Buch von Oldmax habe ich mir mal angesehen. Ab Seite 302 die > Beschreibung der Komm. aber mit Open Eye. Warum? Nun, das Buch war, bzw. ist für Anfänger gedacht, die in die Programmierung einsteigen möchten. VB war eigentlich nur ein kostenloser Einstieg in die Welt der Computerprogramme. Und "OpenEye" ist ein Programm, welches Schritt für Schritt von der Idee bis zur nutzbaren Anwendung beschrieben wird. Im Ergebnis eine nützliche Software zur Arbeit mit µC. Und die Schnittstelle ist eben ein Bestandteil dieses Programmes. Erst wenn VB verlassen und die Arbeit mit einem Controller begonnen wird, werden Kosten fällig. Aber das habe ich auch im Buch ausführlich erwähnt. Wem das Lesen eines ganzen Buches zuviel ist, der kann sich natürlich Abschnitte heraussuchen und diese selbst für seine Zwecke ändern, egal, ob er den Bereich VB verläßt und in die Programmierung von Controllern einsteigt. Ich weiß, das die Zeit solcher Bücher vorbei ist. Das Internet leistet hier mit den Mitgliedern der Foren sehr gute Hilfe. Aber, bei Anfängern ist halt oft nicht das grundlegende Verständnis vorhanden und die Beiträge laufen auch schon mal aus dem Ruder. Da ich auch nicht jedesmal Lust habe, ausführlich über Zahlensysteme oder ereignisgesteuerte Programmbearbeitung zu schreiben, habe ich mir die kleine Mühe mit dem Buch gemacht, nicht für Fortgeschrittene, sondern für Einsteiger oder Schüler, die diese Welt entdecken und begreifen wollen. Hier kann nachgelesen und wenn dann noch Fragen sind, diese gezielter gestellt werden. Ich hätte mir allerdings gewünscht, von eben diesen Anfängern mal ein Feedback zu bekommen. gruß oldmax
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.