Hallo, ich bin noch ziemlicher Anfänger im Programmieren und komme gerade nicht weiter. google und ChatGPT bringen auch nichts und hier im Forum habe ich auch nichts passendes gefunden. Ich versuche über UART einen Text von dem einen MC zum Anderen zu senden und diesen dann über ein LCD ausgeben zu lassen. in erster linie dient es mir nur dazu mich mit dem system auseinander zu setzen und mit den Funktionen vertraut zu werden. wenn ich die Daten vom ersten MC über des Serial Monitor vom PC auslese passt alles wenn ich den Zweiten dran hänge RX>TX und TX>RX scheint es so als würden keine daten empfangen werden. Ich schaffe es Leider nicht über den SerialMonitor von PIO Daten zum zweiten Mc zu senden um zu überprüfen ob bei der Programmierung alles passt. über einen "kleinen" Tipp wo mein Fehler liegen könnte wäre ich euch sehr Dankbar mfg Pascal
Funktioniert das LCD am zweiten Controller denn ohne die Eingabe über den seriellen Port? Teste das mal (durch Codeänderung) indem du dort direkt Zeichen ausgibst, die dann später von der seriellen Schnittstelle kommen. Also das klassische Vorgehen bei der systhematischen Fehlersuche: auftrennen in Blöcke und damit herausfinden, auf welcher Seite sich das Problem befindet.
Pascal G. schrieb: > über einen "kleinen" Tipp wo mein Fehler liegen könnte wäre ich euch > sehr Dankbar Deine Shift-Taste funktioniert nur sehr erratisch und die ','-Taste hakt. > wenn ich die Daten vom ersten MC über des Serial Monitor vom PC auslese > passt alles > wenn ich den Zweiten dran hänge RX>TX und TX>RX scheint es so als würden > keine daten empfangen werden. Besitzt du einen Logikanalysator oder ein Oszi, um festzustellen, was dabei auf den Datenleitungen oder anderen GPIOs passiert? Dann könntest du bspw. in der ISR mit einem Pin wackeln, um zu verifizieren, ob der Empfangsinterrupt ausgelöst wird. Ein Break Point verrät dir natürlich auch, ob die ISR angesprungen wird. Hast du dir im Debugger die Flags für die Freigabe des Interrupts angesehen? Oder woran machst du das "scheint" fest? Programmieren ist keine Kernkompetenz vom ChatGPT.
:
Bearbeitet durch User
Pascal G. schrieb: > Ich versuche über UART einen Text von dem einen MC zum Anderen zu senden MC --> Music Casette? Zitat: Die Abkürzung MC hat je nach Kontext verschiedene Bedeutungen. Die geläufigsten sind: Musik & Entertainment: Steht für Master of Ceremonies (Zeremonienmeister). Im Hip-Hop bezeichnet es den Rapper, Entertainer oder die Person, die durch ein Event führt. Motorrad-Szene: Steht für Motorcycle Club (Motorradclub), oft verwendet von klassischen, organisierten Motorrad-Banden. Gastronomie & Handel: Steht umgangssprachlich oft für die Fast-Food-Kette McDonald’s. Namen: Ist in schottischen und irischen Nachnamen (wie Mac) die Kurzform für Son of (Sohn von). Medizin: Kann für Morbus Crohn (eine chronisch-entzündliche Darmerkrankung) stehen.
Wenn es mit Interrupt nicht klappt würde ich einen Gegentest ohne Interrupt (Polling der Statusregister in einer Loop) versuchen. Dann weisst du, ob das Interrupt-Handling fehlerhaft war, oder es woanders scheitert.
Beitrag #8052609 wurde vom Autor gelöscht.
Das Display funktioniert, ich habe eine if Abfrage ob die Datenübertragung beendet ist, danach wird eine variable auf true gesetzt und in der while schleife auf ihre Richtigkeit geprüft. Ist das der Fall soll der String in der 1. Zeile ausgegeben werden. Ansonsten wird ein Standard Text ausgegeben der auch angezeigt wird.
Hans W. schrieb: > Wenn es mit Interrupt nicht klappt würde ich einen Gegentest ohne > Interrupt (Polling der Statusregister in einer Loop) versuchen. Dann > weisst du, ob das Interrupt-Handling fehlerhaft war, oder es woanders > scheitert. Gute Idee, werde das später gleich ausprobieren.
Wastl schrieb: > Die Abkürzung MC hat je nach Kontext verschiedene Bedeutungen. Und dieser Kontext fehlt in in diesem MännerClub / MüllContainer völlig.
Pascal G. schrieb: > wenn ich den Zweiten dran hänge RX>TX und TX>RX scheint es so als würden > keine daten empfangen werden. Nur zur Vollständigkeit: Hast du denn auch Gnd <---> Gnd verbunden? Add: Ansonsten zur Fehlersuche ohne Geräte Test1: LED ein wenn ISR angesprungen wird. Test2: Wenn der µC PWM auf die LED kann, Helligkeit (PWM duty) inkrementieren mit steigendem ›index‹
:
Bearbeitet durch User
Ich kann mich auch nur anschließen und Dir empfehlen, einen 10€ Logic Analyzer zu kaufen. Auch wenn Du momentan noch nicht den Sinn erkennen magst, es wird für derlei Aufgaben dein Lieblingsinstrument werden. Dazu ist es wirklich leicht zu bedienen, bei den heutigen einfachen USB-LA bedarf es keiner großen Einarbeitung. Schau mal ein paar enstprechende Tutorials. Du wirst dann wunderbar beobachten können, was tatsächlich zwischen den beiden Seiten passiert. So etwas wie das hier (nur Beispiel) reicht für den Anfang völlig: https://www.amazon.de/Analyzer-Binghe-Unterst%C3%BCtzung-Sprungdraht-kompatibel/dp/B0D868ST5C
Pascal G. schrieb: > wenn ich die Daten vom ersten MC über des Serial Monitor vom PC auslese > passt alles > wenn ich den Zweiten dran hänge RX>TX und TX>RX scheint es so als würden > keine daten empfangen werden. Jeder Controller hat eine serielle Schnittstelle und du klemmst alle zwei plus PC direkt zusammen ? Wieso brauchst du beim zweiten Controller die Verbindung bidirektional ? Vielleicht verstehe ich es auch nicht wirklich....
Thomas W. schrieb: > Jeder Controller hat eine serielle Schnittstelle und du klemmst alle > zwei plus PC direkt zusammen ? > Wieso brauchst du beim zweiten Controller die Verbindung bidirektional ? > Vielleicht verstehe ich es auch nicht wirklich.... Nein, ich verbinde beide Controller über RX + TX miteinander und nutze eine Externe Spannungsquelle, dementsprechend sollten die meiden Controller ja miteinander kommunizieren. Die Verbindung über USB war nur um zu prüfen ob der erste etwas sendet. oder Funktioniert die Kommunikation da dann anders? Konkret sende ich vom einen Controller eine Zahl die am anderen über das LCD ausgegeben werden soll. PS. das ist nur zum Testen, später sollen da mehrere werte und infos übertragen und ausgewertet werden ;)
Norbert schrieb: > Nur zur Vollständigkeit: > Hast du denn auch Gnd <---> Gnd verbunden? Jap, beide Controller sind über die gleiche Spannungsquelle verbunden, > Add: Ansonsten zur Fehlersuche ohne Geräte > Test1: LED ein wenn ISR angesprungen wird. > Test2: Wenn der µC PWM auf die LED kann, Helligkeit (PWM duty) > inkrementieren mit steigendem ›index‹ werde ich auch mal noch versuchen, danke :) Meine Vermutung ist ja das ich im Code nen Bock geschossen hab(würde mich wundern wenn nicht)
Beitrag #8052705 wurde vom Autor gelöscht.
Das Problem hat sich ja erledigt. Trotzdem ein Nachsatz: Wenn es nicht um sehr schnelle Übertragung oder große Datenmengen geht, nutze ich immer "Soft Serial". Das hat den Vorteil, dann man (fast) alle anderen GPIOs zu RX und TX machen kann, die dann entsprechend mit ihrem Gegenpart verbunden werden. Die wichtigsten Methoden dieser Klasse sind identisch mit denen von (Hard-) Serial. Das hat den Vorteil, dass die UART, die mit dem USB-Wandler verbunden ist, für das Debugging bzw. neu Flashen frei bleibt. Es gibt auch "Single Wire UART"-Libraries, die nur eine einzige Leitung für beide Richtungen benötigen, falls keine echte Duplex-Übertragung benötigt wird ...
:
Bearbeitet durch User
Frank E. schrieb: > Das Problem hat sich ja erledigt. Trotzdem ein Nachsatz: > > Wenn es nicht um sehr schnelle Übertragung oder große Datenmengen geht, > nutze ich immer "Soft Serial". Das hat den Vorteil, dann man (fast) alle > anderen GPIOs zu RX und TX machen kann, die dann entsprechend mit ihrem > Gegenpart verbunden werden. Die wichtigsten Methoden dieser Klasse sind > identisch mit denen von (Hard-) Serial. > > Das hat den Vorteil, dass die UART, die mit dem USB-Wandler verbunden > ist, für das Debugging bzw. neu Flashen frei bleibt. > > Es gibt auch "Single Wire UART"-Libraries, die nur eine einzige Leitung > für beide Richtungen benötigen, falls keine echte Duplex-Übertragung > benötigt wird ... OK cool, werd ich mir mal anschauen, Eine Frage hätte ich aber noch, Es soll doch eine Möglichkeit geben über den SerialMonitor in PIO Werte oder Zeichen an dem Microcontroller zu senden. muss ich da noch irgendwas einstellen? hab das Programm compiliert und den SerialMonitor gestartet, aber wo kann ich da eine Eingabe machen? der Cursor blinkt aber es zeigt mir nichts an. Auch mit dem Arduino Sketch der den Text zurücksenden soll den man Schickt kommt nichts zurück wenn ich Text eingebe und Enter drücke.
Pascal G. schrieb: > Es soll doch eine Möglichkeit geben über den SerialMonitor in PIO > Werte oder Zeichen an dem Microcontroller zu senden. Die Serielle ist kein Bus! Warum verbindest du nicht deine 2 µC über I2C? Dann bleibt die Serielle frei für die Kommunikation mit dem PC.
:
Bearbeitet durch User
Pascal G. schrieb: > Es soll doch eine Möglichkeit geben ... Es soll auch die Möglichkeit geben, die Shift-Taste dort zu benutzen, wo es sich entsprechend den Gepflogenheiten der Rechtschreibung anbietet ... scnr
:
Bearbeitet durch User
Arduino F. schrieb: > Pascal G. schrieb: >> Es soll doch eine Möglichkeit geben über den SerialMonitor in PIO >> Werte oder Zeichen an dem Microcontroller zu senden. > > Die Serielle ist kein Bus! > > Warum verbindest du nicht deine 2 µC über I2C? > Dann bleibt die Serielle frei für die Kommunikation mit dem PC. Weil es erstmal um die Kommunikation über UART geht. Die Frage bezüglich pio war eher allgemein. Wie kann ich unabhängig vom ersten Projekt Daten/Werte vom PC an den Controller senden. Das sollte doch mittels Serierlem Monitor funktionieren oder?
Rainer W. schrieb: > Pascal G. schrieb: >> Es soll doch eine Möglichkeit geben ... > > Es soll auch die Möglichkeit geben, die Shift-Taste dort zu benutzen, wo > es sich entsprechend den Gepflogenheiten der Rechtschreibung anbietet > ... > scnr Und was hilft mir diese Aussage bei meinem Problem? Hättest du mir die Frage beantwortet wenn ich jedes Wort richtig groß oder klein geschrieben hätte?
Ich hab Soft Serial empfohlen, weil man damit am Einfachsten und ziemlich sicher zu einem Resultat kommt. Natürlich kann ein Arduino auch I2C senden und es gibt Libs, um einen Client zu simulieren, oder SPI oder OneWire oder Ethernet ... geht alles, ist nur nicht so trivial.
Frank E. schrieb: > Ich hab Soft Serial empfohlen, weil man damit am Einfachsten und > ziemlich sicher zu einem Resultat kommt. > > Natürlich kann ein Arduino auch I2C senden und es gibt Libs, um einen > Client zu simulieren, oder SPI oder OneWire oder Ethernet ... geht > alles, ist nur nicht so trivial. Ok, das Problem mit dem Resultat hat sich ja erledigt, der Fehler lag ja am falsch gesetzten interrupt. Allerdings bleibt aktuell noch das Problem mit der nicht funktionierenden Übertragung vom pc zum Controller. Das brauche ich für nichts spezielles aber zum testen ob ein Controller etwas empfängt und verarbeiten kann, wäre es doch ein gutes Instrument. Oder gibt es da andere Möglichkeiten?
Frank E. schrieb: > es gibt Libs, um einen Client zu simulieren, [] ... geht alles, ist nur nicht so trivial. Anscheinend schon, zumindest einen I2C Slave kann man mit der normalen Lib machen. Einfach die Adresse bei wire.begin angeben. Habe das grad heute in kürzester Zeit das erste Mal umgesetzt. Gruss Chregu
Christian M. schrieb: > Habe das grad > heute in kürzester Zeit das erste Mal umgesetzt. Es ist wirklich ganz einfach! Bis auf, dass die Slave Callbacks im ISR Kontext laufen. Da muss man schon in paar Kleinigkeiten beachten.
Pascal G. schrieb: > Und was hilft mir diese Aussage bei meinem Problem? Dass ich beim Lesen nicht darüber gestolpert, sondern eher zu einer konstruktiven Antwort motiviert gewesen wäre. Aber inzwischen ist ja eh klar, dass du nicht zwei Push-Pull-Ausgänge direkt miteinander verbinden darfst. Aktuell finde ich nicht einmal den Schaltplan deiner uCs, um dir genauere Hinweise geben zu können.
Pascal G. schrieb: > Allerdings bleibt aktuell noch das Problem mit der nicht > funktionierenden Übertragung vom pc zum Controller. > Das brauche ich für nichts spezielles aber zum testen ob ein Controller > etwas empfängt und verarbeiten kann, wäre es doch ein gutes Instrument. > Oder gibt es da andere Möglichkeiten? Hm, scheinbar les ich nicht richtig (ob der Kopf beim Motorradunfall doch etwas abbekommen hat?). Sehe ich das richtig und du möchtest vom PC zum Controller über UART etwas senden? Hierfür kannst du zwar den Serialmonitor von Arduino verwenden, dieser schickt allerdings komplette Strings und schickt seinen Text erst nach Betätigung der Return-Taste ab. Vielleicht solltest du hierfür dann ein externes Terminalprogramm verwenden, dass die Zeichen eben Zeichenweise schickt und liest. Das Programm puTTY wäre hier ein sehr geeigneter Kandidat. Und (da ich immer noch im Krankenhaus bin) passe ich vllt. das Progamm aus: Beitrag "Re: "Intelligenter" Textdisplayadapter mit Padauk PFS154" für AVR und Arduino an (wenn ich mich derzeit sowieso etwas mit Arduino beschäftige). Neben Nachteilen hat das hier den Vorteil, dass UART nicht belegt wird und das Textdisplay Steuerkommandos eines Terminals (CR, LF, TAB, BS) verarbeiten kann.
Ralph S. schrieb: > Das > Programm puTTY wäre hier ein sehr geeigneter Kandidat. Teraterm ist hier auch zu empfehlen. Man sollte allerdings den standardmäßig verwendeten Pixelfont auf was sinnvolles umstellen und dann die Einstellungen abspeichern, sonst wird man ... missmutig.
Pascal G. schrieb: > Allerdings bleibt aktuell noch das Problem mit der nicht > funktionierenden Übertragung vom pc zum Controller. > Das brauche ich für nichts spezielles aber zum testen ob ein Controller > etwas empfängt und verarbeiten kann, wäre es doch ein gutes Instrument. Zu einem Controller klappt problemlos nur alle drei zusammen nicht so ohne weiteres. Zumal der Pc dann nur mit einen sprechen könnte. Wie ich das verstanden haben soll der Pc nur zu Testzwecken dran hängen? Dann wäre es das einfachste die Controller zu trennen und beide an den Pc zu hängen. Dann kann der sehen was die einzelnen mitteilen und das selbe gleich zu dem anderen senden um dann dessen Antwort zu erkennen und auch weiter zu geben.
.... hochinteressant ist, dass es in der letzten Zeit (zumindest mir auffällig) immer häufiger "langjährige User (hier 26.06.2020)" einen Thread eröffnen. In diesem Falle hier genau 10 Posts! in den 6 Jahren (inklusive diesem hier) machen und im besten Fall einen oder 2 Anworten gibt. Hmm, ich bin immer noch in der Reha und habe "einiges an Zeit" und habe für die Kommunikation zwischen 2 Controllern etwas älteres von mir (original für einen PFS154) an Arduino angepasst (weil ich damit im Moment für andere Projekte das etwas genauer betrachte und mich darin übe, wie mit Arduino im Gegensatz zu C oder auch C++ (ja ich weiß, Arduino IST C++) gemacht wird). Die Portierung hat funktioniert (Kopplung von zwei UNO-Arduinos, an einem hängt ein Textdisplay), aber weil der Thread hier scheinbar tot ist, rentiert es sich wohl nicht, das gesamte auch zu dokumentieren. Schade, dass ich auf solche Threads immer wieder reinfalle !
Ralph S. schrieb: > .... hochinteressant ist, dass es in der letzten Zeit (zumindest mir > auffällig) immer häufiger "langjährige User (hier 26.06.2020)" einen > Thread eröffnen. In diesem Falle hier genau 10 Posts! in den 6 Jahren > (inklusive diesem hier) machen und im besten Fall einen oder 2 Anworten > gibt. > > Hmm, ich bin immer noch in der Reha und habe "einiges an Zeit" und habe > für die Kommunikation zwischen 2 Controllern etwas älteres von mir > (original für einen PFS154) an Arduino angepasst (weil ich damit im > Moment für andere Projekte das etwas genauer betrachte und mich darin > übe, wie mit Arduino im Gegensatz zu C oder auch C++ (ja ich weiß, > Arduino IST C++) gemacht wird). > > Die Portierung hat funktioniert (Kopplung von zwei UNO-Arduinos, an > einem hängt ein Textdisplay), aber weil der Thread hier scheinbar tot > ist, rentiert es sich wohl nicht, das gesamte auch zu dokumentieren. > > Schade, dass ich auf solche Threads immer wieder reinfalle ! Hallo Ralph, Erstmal gute Besserung. Zu dem Thema das ich oberhalb von 6 Jahren nur 10 Post gemacht habe, ja das stimmt. Ich kenne mich allerdings nur mäßig mit dem Thema aus und will nicht überall unnötig meinen Senf dazu geben. Außerdem war ich die letzten Jahre mit dem Hausbau beschäftigt und danach habe ich in Fernlehre meinen Techniker gemacht, was mich leider sehr viel Zeit gekostet hat. Da ich jetzt hoffentlich wieder mehr Zeit habe möchte ich mich wieder mehr mit dem Thema programmieren beschäftigen. Mir ist außerdem aufgefallen das ich auf deinen Thread nicht geantwortet habe, das tut mir leid und war absolut keine Absicht. Wie ich aber der Antwort auf deinen Beitrag geantwortet habe, dass ich mir die Programme zur Kommunikation zwischen PC und Controller anschaue, war das für mich inbegriffen. Mit freundlichen Grüßen
:
Bearbeitet durch User
.... okay: Was, warum und zu welchem Zweck möchtest du 2 µC miteinander koppeln. Bestimmte Wege wurden dir hier ja schon aufgezeigt, wobei I2C außerhalb von Arduino schon etwas "sportlich" ist, wenn man sich da nicht wirklich gut auskennt (hier meine ich ganz gezielt einen I2c-slave, ein I2C-master ist relativ trivial). Dann die Frage nach UART. Das ist ja normalerweise ein sehr einfacher Weg und, wie ich hieraus schließe: (Auszug aus deinem Listing)
1 | #include <LiquidCrystal.h> |
2 | |
3 | using namespace std; |
4 | |
5 | LiquidCrystal lcd(12, 11, 5, 4, 3, 2); // Pin-Belegung für das LCD |
hast du da Arduino am Start, verwendest aber dennoch eine "main" und gehst nicht über das setup/loop. Stellt sich hier die Frage: Warum? Um einen Controller mit Daten vom PC zu füttern reicht ein Serial.begin(baudrate) ... und dann eben Serial.read / readln (um im Arduino Kontext zu bleiben). Stellt sich also explizit die Frage, was du machen willst. Wenn es darum geht, tatsächlich "nur" ein Display an einen Controller zu hängen und diesen Controller von einem anderen anzufahren: viele Wege führen nach Rom (und hierfür hab ich ja eine Lösung gemacht). Grundsätzlich, auch wenn das die Arduianer nicht gerne hören (und auch wenn ich einige Vorbehalte von mir Arduino gegenüber sehr beiseite geschoben habe): den seriellen Monitor der Arduino-IDE sollte man getrost übergehen. Oben wurde genannt puTTY (funktioniert unter Linux und Windows) und Teraterm (nur Windows) und damit bist du glaube ich wirklich besser bedient als mit dem seriellen Monitor von Arduino. Also, schreib mal, was du explizit machen möchtest! (noch habe ich einiges an Zeit, wobei es zum Thema Arduino ganz sicher einige hier gibt, die die Arduino-Philosophie besser vertreten und dann in Ihren Programmen auch deutlich mehr Arduino und weniger Bare-Metall haben).
Moin, Das einbinden von arduino ist lediglich für die Ansteuerung des Displays. Grundsätzlich geht es mir erstmal nur darum mich mit der Materie auseinanderzusetzen. Während meines Technikers haben wir ein klein bisschen das Thema microcontroller programmieren gehabt, also so richtig mit den Registern und co, und da möchte ich mich jetzt einfach weiter damit beschäftigen. Es waren noch einige Fragen offen und die will ich nun eben angehen. I2c werde ich später sicherlich auch mal noch behandeln. Die arduino IDE nutze ich nicht sondern VSCode mit PIO, Da bekomme ich zwar die Seriellen Daten vom Controller aber er empfängt irgendwie nichts. Mein Versuch war,rein zu Übungszwecken für eventuelle spätere Projekte, Eine Kommunikation zwischen 2 Controllern ODER zwischen Controller und PC, Die Ausgabe via LCD war gedacht um besser kontrollieren zu können obs geht.
Pascal G. schrieb: > Das einbinden von arduino ist lediglich für die Ansteuerung des > Displays. Ist nicht nötig, es gibt dafür reichlich C Codes. Einen der ziemlich Low-Level ist habe ich als Beispiel angehängt.
:
Bearbeitet durch User
Rainer W. schrieb: > Dass ich beim Lesen nicht darüber gestolpert, sondern eher zu einer > konstruktiven Antwort motiviert gewesen wäre. Man Rainer, dann halt doch einfach Deine Finger still, wenn Dir die Form, die Person oder die Wortwahl nicht passt. Es würde dem Forum sehr gut tun, wenn sich alle zurückhalten, die nix zum Thema beitragen wollen. Deshalb von mir noch was: Pascal G. schrieb: > Ich versuche über UART einen Text von dem einen MC zum Anderen zu senden > und diesen dann über ein LCD ausgeben zu lassen. Ein Foto vom Aufbau und die Erwähnung der verwendeten Plattform bzw, Controller und IDE helfen potentiellen Helfern das Problem einzukreisen. Ich weiß, man steckt in 'seinem' Projekt drin, aber das Forum guckt einem ja nicht über die Schulter. Ich hätte jetzt nur anhand der Dateiendung (cpp) geraten, daß es sich evtl. um Arduinos handelt... Arduino F. schrieb: > Die Serielle ist kein Bus! Ab wann ist des denn ein Bus? Wenn es einen Fahrplan gibt?!? > Warum verbindest du nicht deine 2 µC über I2C? Warum sollte er? Da fehlt ihm die Möglichkeit den PC als Gegenstelle zum Test (senden/empfangen) zu verwenden.
Rick schrieb: > Ab wann ist des denn ein Bus? Das solltest du selber in Erfahrung bringen können. Rick schrieb: > Da fehlt ihm die Möglichkeit den PC als Gegenstelle zum > Test (senden/empfangen) zu verwenden. "Ihm" vielleicht. Aber "Du" scheinst nicht zu wissen, wie das geht.
Rick schrieb: > Arduino F. schrieb: >> Die Serielle ist kein Bus! > Ab wann ist des denn ein Bus? Wenn es einen Fahrplan gibt?!? Ein Bus ist dann ein "Bus", wenn an einer pyhsikalischen Leitung mehr als ein Device angesteuert wird / werden kann. Und so gesehen ist dann (und so hatte ich das auch mal in der Technikerschule) konkret gesehen USB an der USB-Buchse auch kein Bus, weil nur ein Gerät angeschlossen kann und die Bezeichnung "Universal Serial Bus" ist technologisch gesehen falsch! I2C ist ein Bussystem, das singlewire (bspw. für DS18B20) ist ein Bussystem. UART ist es nicht. Pascal G. schrieb: > I2c werde ich später sicherlich auch mal noch behandeln. > Die arduino IDE nutze ich nicht sondern VSCode mit PIO, > Da bekomme ich zwar die Seriellen Daten vom Controller aber er empfängt > irgendwie nichts. Aber du verwendest anscheinend Arduino-Code, denn das hier: #include <LiquidCrystal.h> using namespace std; LiquidCrystal lcd(12, 11, 5, 4, 3, 2); // Pin-Belegung für das LCD habe ich außerhalb von Arduino noch nie gesehen! .... hier wäre es dann mal höchstinteressant, deine LiquidCrystal.h zu sehen! .... Wenn du das außerhalb von Arduino machen möchtest, auf Registerebene, dann empfielt sich eine der vielen SoftUart Sourcen. Außerdem stellt sich die Frage: soll das eine "Einbahnstraße" sein, oder sollen die beiden Controller die du koppeln magst bidirektional sein. Schade, ich habe mein Arduino Sender- und Empfängersketch für Text-LCD als Miniterminalausgabe gerade fertig gemacht, die Klasse halt..... dann erübrigt sich das Erstellen einer Library hierfür. Vllt. sollte ich das dann als Projekt einstellen, das hat jetzt in der Reha mich doch den ganzen Abend gestern und seit heute Morgen beschäftigt
Danke Ralph für deine Mühe, Das Missverständnis mit dem eingebunden Arduino Code tut mir leid. Ich bin leider auch nicht perfekt aber das nächste Mal versuche ich mein Projekt besser zu beschreiben um sowas zu umgehen. Ich meine aber öfter darauf hingewiesen zu haben das es um den UART und die Kommunikation zwischen Controllern bzw. dem PC geht. Ich finde es klasse das du dir solch eine Mühe gemacht hast. Die genannten Programme für den serialmonitor konnte ich mir leider noch nicht anschauen, aber bisher habe ich auch noch keine Antwort erhalten ob ich in VSCode was ändern muss das der integrierte SerialMonitor funktioniert oder ob er generell nur zum empfangen gedacht ist… Euch allen noch ein schönes Wochenende
Arduino F. schrieb: > Aber "Du" scheinst nicht zu wissen, wie das geht. Wenn Du wüßtest, was ich weiß und welche Messmöglichkeiten mir momentan zur Verfügung stehen... Ralph S. schrieb: > UART ist es nicht. Ich kann an UART auch mehrere Devices anschließen und per Protokoll bestimmen, wer wann senden darf. Entweder realisiert man TX mit OC (open collector) oder man verknüpft die TX per NAND. BTDT. Pascal G. schrieb: > ob ich in VSCode was ändern muss das der integrierte SerialMonitor > funktioniert oder ob er generell nur zum empfangen gedacht ist Da kann ich nicht weiterhelfen. Aber Du könntest alternativ HTerm probieren...
Rick schrieb: > Wenn Du wüßtest, was ich weiß und welche Messmöglichkeiten mir momentan > zur Verfügung stehen... Ich sehe, dass du mir überheblich und aggressiv gegenübertritst. Kannst du natürlich machen... Tipp: Konstruktive Unterhaltungen, gehen anders.
Tegtmeier klärt auf: Zu wissen, was alles die KI mehr weiß als man selbst, verleitet schon sehr überheblich zu werden (Wenn Ihr wüßtet, was ich weiß...).
Ralph S. schrieb: > Vllt. sollte ich das dann als Projekt einstellen Vielleicht solltest Du Dir ein eigenes Projekt suchen. Pascal hat nicht darum gebeten. Er schrieb eindeutig dass er das selbst machen will. Er will lernen.
Alexander schrieb: > Vielleicht solltest Du Dir ein eigenes Projekt suchen. Pascal hat nicht > darum gebeten. Er schrieb eindeutig dass er das selbst machen will. Er > will lernen. sag mal, kannst du irgendetwas anderes hier, als Leute anstänkern? Es soll ja Menschen geben, die da echten und wirklichen Gefallen daran haben, anderen bei jedweder Möglichkeit ans Bein zu pinkeln. Deinen Nick habe ich schon öfters gelesen aber mir ist kein einziger positiver / konstruktiver Beitrag von dir in Erinnerung, geschweige denn ein Programm oder Projekt. Aber nichts desottrotz: Ich wünsche dir weiterhin viel Spaß beim Stänkern! -------------------------------------------- Zu Pascal (auch wenn ich irgendwie den Post von dir noch etwas "unglaubwürdig" finde. Pascal G. schrieb: > Eine Frage hätte ich aber noch, > Es soll doch eine Möglichkeit geben über den SerialMonitor in PIO > Werte oder Zeichen an dem Microcontroller zu senden. > muss ich da noch irgendwas einstellen? > hab das Programm compiliert und den SerialMonitor gestartet, aber wo > kann ich da eine Eingabe machen? > der Cursor blinkt aber es zeigt mir nichts an. > Auch mit dem Arduino Sketch der den Text zurücksenden soll den man > Schickt kommt nichts zurück wenn ich Text eingebe und Enter drücke. Ich werde jetzt einfach nicht schlau daraus, ob du nun innerhalb von Arduino etwas schreibst, oder VScode als Editor verwendest und welchen SerialMonitor du meinst. VScode hat imho keinen seriellen Monitor. Der von Arduino schickt nur einen kompletten String über UART, was heißt, der Text muß erst eingegeben werden, einzelne Buchstaben erscheinen erst mit Abschicken des Strings. Von daher ist der serielle Monitor von Arduino im besten Falle für Debug-Ausgaben geeignet. So, um eine serielle Kommunikation von PC zu Controller (ich nehme hier aus dem Chatverlauf ATmegaxx8 an) aufzuzeigen, habe ich eine Demodatei erstellt, ganz bewußt aus einer einzigen Datei, die keine weiteren Abhängigkeiten zu weiteren Dateien besitzt, die den UART initialisiert und ein Textdisplay ansteuert. Sämtliche Funktionen für den UART und das Display sind in der Datei einhalten. Um dieses Programm testen zu können und reinschauen zu können was es macht, benötigtst du auf PC-Seite ein serielles Terminalprogramm wie - oben genannt - puTTY, teraterm oder ähnliches. Das Programm hier im Anhang erwartet auf der seriellen Schnittstelle ein Zeichen, trifft dieses ein, wird es auf der zweiten Zeile des Displays ausgegeben. Gibst du im seriellen Terminal ein '#' Zeichen ein, interpretiert das das Programm als "Pseudo-CR-LF" und generiert im seriellen Terminal einen CR-LF, auf dem Display das löschen der 2. Zeile und ein Springen an den Zeilenanfang.
Ralph S. schrieb: > VScode hat imho keinen seriellen Monitor. Doch hat es, ich habe ihn benutzt. https://deepwiki.com/microsoft/vscode-arduino/4.1-serial-monitor-and-communication Für erste Versuche ist der serielle Monitor mit seiner Zeilen-basierten Kommunikation durchaus Sinnvoll. Sie wird ja auch vom Framework unterstützt. Für den hier diskutierten Anwendungsfall jedoch eher nicht, da stimme ich dir zu. Ich benutze gerne das von Rick empfohlene Hammer Terminal.
:
Bearbeitet durch User
Hans W. schrieb: > Doch hat es, ich habe ihn benutzt. Das ist dann eine Erweiterung von vscode. Vscode selbst hat sowas nicht und weiß auch nicht, was ein Arduino ist.
Harald K. schrieb: > Das ist dann eine Erweiterung von vscode. Ja. Vscode benutzt man praktisch immer mit Erweiterungen, ganz besonders im Fall von Arduino.
:
Bearbeitet durch User
Hans W. schrieb: > Vscode benutzt man praktisch immer mit Erweiterungen Eben. Aber dann hängt es eben ganz gewaltig davon ab, welche man verwendet. Wenn der Horizont nur aus Arduino besteht, dann natürlich nicht.
Harald K. schrieb: > Wenn der Horizont nur aus Arduino besteht, dann natürlich > nicht. Der Pascal benutzt für sein Projekt den seriellen Monitor von Arduino (bzw. die entsprechenden vscode Erweiterung). Mir war das klar. Dein Horizont beschränkter erlaubte dir offenbar nicht, das zu erkennen. Merkst du was? Man sollte ihn deswegen nicht beleidigen. So funktionieren Ratschläge nicht, die werden vom Gehirn direkt blockiert.
:
Bearbeitet durch User
Hans W. schrieb: > Merkst du was? Man sollte ihn deswegen nicht beleidigen. Um Pascal ging es mir nicht, sondern um Deine Anmerkungen. Du hast die vereinfachende und daher falsche Darstellung aufgebracht.
Angehängte Dateien:
-
screenshot378.png
14 KB
Ralph S. schrieb: > UART ist es nicht. UART ist da erstmal unabhängig. Packt man dort einen RS485-Baustein dran, wird ein Bus draus. Wie bei jedem Bus erfordert dies eine koordinierte Kommunikation. Es kann nicht einfach zu jedem Zeitpunkt gesendet werden, wie bei bidirektionalen Verbindungen. Daher wird es mit einem Terminal auch schwierig hier händisch Informationen einzufügen. Also ist ein Bus für den TO sowieso unpassend. Die Problematik hier ist nicht die Schnittstelle, sondern wie man Daten aus zwei Quellen die potentiell gleichzeitig senden können, zusammenführt. Und das ist eigentlich schon fortgeschritten und kein Projekt für einen Anfänger. Wenn man sicherstellen kann, dass immer nur einer sendet, dann kommt man mit UND-Gattern weiter (Bild) Gruß Jobst
Ralph S. schrieb: > sag mal, kannst du irgendetwas anderes hier, als Leute anstänkern? Keine Ahnung was Du meinst. Vielleicht ist eher andersherum. Ralph S. schrieb: > Deinen Nick > habe ich schon öfters gelesen aber mir ist kein einziger positiver / > konstruktiver Beitrag von dir in Erinnerung, geschweige denn ein > Programm oder Projekt. Vielleicht weil Du zu faul bist zum lesen.
:-) ... ich glaube Pascal interessiert sich nicht mehr für diesen Thread!
Rick schrieb: > Deshalb von mir noch was: > Pascal G. schrieb: Rick, wenn du zitierst, lass doch einfach die Finger von der automatisch erstellten Quellenangabe, damit der Link nicht bis zur Nichtfunktionalität zerstört wird und man dem Thread besser folgen kann.
Rainer W. schrieb: > damit der Link nicht bis zur > Nichtfunktionalität zerstört wird Ist er hier nicht, der Link funktioniert. Ist Dein Browser kaputt oder benutzt Du die "Mobilansicht"? Hattest Du nicht neulich schon genau das gleiche Problem?
Harald K. schrieb: > Um Pascal ging es mir nicht, sondern um Deine Anmerkungen. > Du hast die vereinfachende und daher falsche Darstellung aufgebracht Ach so, ja dann hatte ich dich missverstanden. Deine Annahme zum Horizont trifft allerdings nicht zu. Ich benutze zahlreiche Entwicklungsumgebungen je nach Projekt. Arduino ist nur eine davon, und nicht die bevorzugte.
Falls sich irgendwer noch für Pascal und sein letztes verbliebendes Problem interessiert: Pascal G. schrieb: > Die arduino IDE nutze ich nicht sondern VSCode mit PIO, > Da bekomme ich zwar die Seriellen Daten vom Controller aber er empfängt > irgendwie nichts. Pascal G. schrieb: > bisher habe ich auch noch keine Antwort erhalten > ob ich in VSCode was ändern muss das der integrierte SerialMonitor > funktioniert oder ob er generell nur zum empfangen gedacht ist… Mit "PIO" meint er vermutlich die Erweiterung "Platform IO" für VSCode, die auch Unterstützung für Arduino enthält, und darüber hinaus auch einen seriellen Monitor. Siehe hier: https://docs.platformio.org/en/latest/core/userguide/device/cmd_monitor.html Ich habe das bisher nicht benutzt. Sieht aber ganz nett aus, da es durch Nutzung gängiger Tools des jeweiligen OS offenbar einige Features hat und für das jeweilige Projekt entsprechend konfiguriert werden kann, aber dadurch leider für Einsteiger offenbar auch schwieriger in Gang zu bekommen ist. Ich habe gerade nicht auf dem Schirm, ob Pascal schon verraten hat, ob er mit Windows oder Linux unterwegs ist.
Also, Erstmal vielen Dank an alle die sich hier KONSTRUKTIV Beteiligt haben, an alle Anderen, habt ihr denn nichts Besseres zu tun??? Wer mein Projektaufbau nicht verstanden hat darf sich gerne Melden, wie es schon erwähnt wurde habe ich es in der tat nicht richtig beschrieben und habe mich dafür auch schon Entschuldigt. ich versuche es nun nochmal neu: Mein Projekt (nur zum Üben) sieht vor Via UART einen Text/Zahl ect. von einem Controller zum anderen zu Senden. Ziel ist es den Umgang und die Initialisierung des UART zum Senden und Empfangen zu Lernen. Als Kontrollmöglichkeit war geplant das gesendete auf einem LCD anzuzeigen. Der Einfachheit halber (Da ich mich nicht noch zusätzlich mit dem LCD auseinander setzen wollte - kommt wahrscheinlich zu nem späteren Zeitpunkt auch noch) habe ich dieses kurzerhand mit Arduino eingebunden(es sei mir verziehen). Den Code habe ich in VSCode mit PIO geschrieben. Dort gibt es einen Serial Monitor. Mittlerweile habe ich auch erfahren das er zum Senden von Daten nicht zielführend ist und werde mir die anderen Programme die genannt wurden gerne mal anschauen. GRUND für die versuchte Verwendung des SerialMonitors von PIO war das die 2. Controller keine Daten Empfangen hat was sich aber mittlerweile auch geklärt hat(falsche Initialisierung vom Interrupt). Es war zu Keinem Zeitpunkt angedacht alle 3 Geräte gleichzeitig miteinander Kommunizieren zu lassen. Ich komme aus Privaten Gründen gerade nur langsam durch die ganzen angehängten Code Beispiele durch werde sie mir aber auf alle fälle noch Anschauen.
Jobst M. schrieb: > UART ist da erstmal unabhängig. Packt man dort einen RS485-Baustein > dran, wird ein Bus draus. Ist UART nicht ersteinmal ein Übertragungsprotokoll mit Start-, Stop- und ggf. Paritätbits unabhängig von einer Topologie, bspw. RS485, die man dann daran hängt? Von daher wäre es dann doch korrekt weder von einem Bus noch von einem Nicht-Bus zu sprechen oder ? Nur eben UART!
Chris V. schrieb: > Falls sich irgendwer noch für Pascal und sein letztes verbliebendes > Problem interessiert: DANKE ;) > Ich habe gerade nicht auf dem Schirm, ob Pascal schon verraten hat, ob > er mit Windows oder Linux unterwegs ist. Ich habe ein Linux System, macht dies ein unterschied in der Verwendung?
Horst schrieb: > Ist UART nicht ersteinmal ein Übertragungsprotokoll mit Start-, Stop- > und ggf. Paritätbits unabhängig von einer Topologie, bspw. RS485, die > man dann daran hängt? UART* ist Hardware, die dieses Protokoll erzeugt und verarbeitet, und die, sofern man nicht mit zusätzlichen Treiberbausteinen nachhilft, eine bestimmte "Topologie" für die Übertragung herstellt - nämlich eine Punkt-zu-Punkt-Übertragung mit Logikpegeln (d.h. Versorgungsspannung der UART). Das liegt daran, daß der Datenausgang der UART (TxD) eine Push-Pull-Treiberstufe verwendet; werden mehrere davon verbunden, gibt es einen Kurzschluss. Um irgendwas anderes zu erreichen, braucht es Treiberbausteine, die diese Logikpegel in etwas anderes übersetzen und die dann auch, weitere Hard- oder Softwareunterstützung vorausgesetzt, auch eine Punkt-zu-Mehrpunkt-Übertragung ermöglichen. Diese weitere Hard- oder Softwareunterstützung besteht in der zeitlich korrekten Ansteuerung einer Sender-/Empfänger-Umschaltung, die z.B. ein RS485-Treiber benötigt. Es gibt UARTs, die das in Hardware erledigen, und dafür eine Steuerleitung anbieten (z.B. ist das bei den in den USB-Seriell-Bridges von FTDI verwendeten UARTs der Fall), aber es gibt auch sehr, sehr viele, die genau das nicht tun, wo also mit Software und einem I/O-Pin nachgeholfen werden muss. Aber ohne irgendeinen dieser Zusätze ist eine UART nur für eine Punkt-zu-Punkt-Verbindung nutzbar. *) früher von einigen Hardwareherstellern auch mit anderen Akronymen wie z.B. ACIA oder SIO benannt
Ich habe mal das Programm Beitrag "Re: Kommunikation zwischen 2 MC" von Ralph getestet. Wenn man das auf einem Controller laufen läßt und auf einem zweiten Controller dasselbe Programm, nur das was er setup und loop genannt hat, durch folgendes ersetzt:
1 | void setup() |
2 | {
|
3 | uart_init(115200); |
4 | } |
5 | |
6 | void loop() |
7 | {
|
8 | static int counter = 0; |
9 | char puffer[20]; |
10 | |
11 | itoa(counter, puffer, 10); |
12 | uart_puts(puffer); |
13 | uart_putchar('#');
|
14 | counter ++; |
15 | _delay_ms(500); |
16 | } |
und zusätzlich die Geschwindigkeit bei der Übertragung etwas einbremst
1 | void uart_puts(const char *str) |
2 | {
|
3 | while (*str) |
4 | uart_putchar(*str++); |
5 | // dem Empfänger Zeit zur Verarbeitung geben bevor das nächste Zeichen gesendet wird |
6 | _delay_ms(10); |
7 | } |
und im Programm noch ein #include <stdlib.h> für das itoa hinzufügt, dann überträgt der zweite Controller den Wert in Counter an den ersten und zeigt diese Zahl auf dem Display an. Ich finde das realtiv cool und werde mir das so merken. Wichtig hier ist, dass die Anschlußpins der ATmegas für RxD und TxD über kreuz angeschlossen werden müssen: Pin2 (RxD) <=> Pin3 (TxD) und Pin3 (TxD) <=> Pin2 (RxD)
Harald K. schrieb: > UART* ist Hardware, die dieses Protokoll erzeugt und verarbeitet, und > die, sofern man nicht mit zusätzlichen Treiberbausteinen nachhilft, eine > bestimmte "Topologie" für die Übertragung herstellt - nämlich eine > Punkt-zu-Punkt-Übertragung mit Logikpegeln (d.h. Versorgungsspannung der > UART). > Das liegt daran, daß der Datenausgang der UART (TxD) eine > Push-Pull-Treiberstufe verwendet; werden mehrere davon verbunden, gibt > es einen Kurzschluss. und somit ist es eben doch kein BUS. Danke für die ausführliche Klarstellung.
Harald K.Harald K. schrieb: > Rainer W. schrieb: >> damit der Link nicht bis zur >> Nichtfunktionalität zerstört wird > > Ist er hier nicht, der Link funktioniert. Dann guck es dir selbst z.B. mit Chrome unter Android an. > Ist Dein Browser kaputt oder benutzt Du die "Mobilansicht"? Nein, ja Die Langversion: Der Link funktioniert nicht (bei Aufruf über Chrome unter Android), wenn der Autor des Beitrags die von der Forensoftware automatisch erzeuge Leerzeile vor der Quellenangabe wegeditiert, z.B. weil er dort rein schreibt "Deshalb von mir noch was:". Chrome unter Win (funktionierte unter Win): Rick schrieb: > Deshalb von mir noch was: > Pascal G. schrieb: Chrome unter Android (funktioniert nicht, aber unter Win): Rick schrieb: > Deshalb von mir noch was: > Pascal G. schrieb: (jeweils Zitat der selben Stelle)
:
Bearbeitet durch User
Pascal G. schrieb: > Ich habe ein Linux System, macht dies ein unterschied in der Verwendung? :-) das macht nicht wirklich einen Unterschied, aber in ein paar Dingen vllt. einfacher?!? Im Anhang habe ich mal ein wirklich sehr sehr schmales Terminalprogramm für Linux auf Konsolenebene angefügt und ist in der Linuxwelt eigentlich sehr bekannt: picocom Ich habe das nur für die Textfarbe und die Überschrift beim Start (Farbe) des Terminals modifiziert. Archiv auspacken in beliebiges Verzeichnis. - make clean - make Du hast eine neue Datei namens: "picomon" Das kannst du starten mit (wenn du bspw. einen Arduino-Clone ansprechen willst, der sich als USB0 anmeldet) ./picomon -b 115200 /dev/ttyUSB0 Damit hast du dann ein serielles Terminal, das auf jedes einzelne Zeichen das du eingibst reagiert und über dieses Terminal versendet. Der Vorteil von picomon ist: es muß nichts installiert werden, hat keine "Abhängigkeiten" die auf einem Linuxsystem nicht vorhanden sind und wenn du das Programm wieder löscht, hat es keine Spuren hinterlassen. Beendet wird das Programm mit einer etwas "unbekannten" Tastenkombination: STRG-A-X Viel Spaß und Erfolg
Horst schrieb: > und zusätzlich die Geschwindigkeit bei der Übertragung etwas einbremst > void uart_puts(const char *str) > { > while (*str) > uart_putchar(*str++); > // dem Empfänger Zeit zur Verarbeitung geben bevor das nächste Zeichen > gesendet wird > _delay_ms(10); > } Das macht nicht, was Du glaubst. Das wartet nicht nach jedem Zeichen, sondern nur einmal, nach dem kompletten Absenden des Strings "str". Um nach jedem Zeichen zu warten, müsste es so aussehen:
1 | void uart_puts(const char *str) |
2 | {
|
3 | while (*str) |
4 | {
|
5 | uart_putchar(*str++); |
6 | // dem Empfänger Zeit zur Verarbeitung geben bevor das nächste Zeichen gesendet wird
|
7 | _delay_ms(10); |
8 | }
|
9 | }
|
Harald K. schrieb: > UART* ist Hardware, die dieses Protokoll erzeugt und verarbeitet, und > die, sofern man nicht mit zusätzlichen Treiberbausteinen nachhilft, eine > bestimmte "Topologie" für die Übertragung herstellt - nämlich eine > Punkt-zu-Punkt-Übertragung mit Logikpegeln (d.h. Versorgungsspannung der > UART). > Das liegt daran, daß der Datenausgang der UART (TxD) eine > Push-Pull-Treiberstufe verwendet; werden mehrere davon verbunden, gibt > es einen Kurzschluss. Zumindest bei einem Controller kann man, sobald die Übertragung abgeschlossen ist, die Push-Pull-Treiberstufe abschalten. Damit könnte man im Prinzip einfach alle RxD und TxD miteinander verbinden. Zum Schutz könnte man noch einen Widerstand an jeden TxD in Reihe setzen. Bei einem 8051 muss man weder Treiberstufe abschalten, noch einen Widerstand einbauen, da er keine Push-Pull Ausgänge hat. Allerdings wird der PC hierbei zum Spielverderber. Gruß Jobst
Jobst M. schrieb: > Zumindest bei einem Controller kann man, sobald die Übertragung > abgeschlossen ist, die Push-Pull-Treiberstufe abschalten. Das ist dann aber eines der von mir erwähnten Hilfsmittel, in diesem Fall Software. Die UART macht das von sich aus nicht. Jobst M. schrieb: > Bei einem 8051 muss man weder Treiberstufe abschalten, noch einen > Widerstand einbauen, da er keine Push-Pull Ausgänge hat. Die hat er an Port 0 nicht; liegt aber die UART nicht auf Port 3? Man kann natürlich als primitivstes Hilfsmittel mit 'ner Diode und einem Pullup-Widerstand so eine Art "Open-Collector"-Ausgang nachbilden, aber -- auch das ist ein Hilfsmittel.
Harald K. schrieb: > Das macht nicht, was Du glaubst. Das wartet nicht nach jedem Zeichen, > sondern nur einmal, nach dem kompletten Absenden des Strings "str". > > Um nach jedem Zeichen zu warten, müsste es so aussehen:void > uart_puts(const char *str) > { > while (*str) > { > uart_putchar(*str++); > // dem Empfänger Zeit zur Verarbeitung geben bevor das nächste > Zeichen gesendet wird > _delay_ms(10); > } > } Du hast recht und das war ein Kopierfehler hier ins Eingabefenster, ich meinte diese Funktion hier (Wartezeit nach jedem gesendeten Zeichen):
1 | void uart_putchar(char ch) |
2 | {
|
3 | while (!( UCSR0A & (1<<UDRE0))); // warten bis Transmitterpuffer leer ist |
4 | UDR0 = ch; // Zeichen senden |
5 | _delay_ms(10); |
6 | } |
Die Wartezeit beim Stringsenden habe ich wieder entfernt.
Harald K. schrieb: > Die UART macht das von sich aus nicht. Das macht nichts. Auch ein RS485-Baustein macht das nicht von sich aus in Hardware. Dann ist RS485 nach Deiner Definition also auch kein Bus. Harald K. schrieb: > Die hat er an Port 0 nicht; liegt aber die UART nicht auf Port 3? Jo. Aber auch Port 3 ist kein Push-Pull. Der 8051 hat auch KEINE Datenrichtungsregister. An Port 0 hat der 8051 keine Pull-Ups, nur Open-Drain. Gruß Jobst
Jobst M. schrieb: > Auch ein RS485-Baustein macht das nicht von sich aus in Hardware. > Dann ist RS485 nach Deiner Definition also auch kein Bus. Irgendwo bist Du falsch abgebogen.
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.