Es ist einfach hier rumzumotzen, wenn man sich hinter einem Gast-Account verstecktZitat von Unregistriert
jaaa, früher....
Wir reden hier aber von Arduinos mit mindestens 16MHz Takt und UART pots, die auf allen Arduinos mindestens bis zu 115200 baud unterstützen, und bei scheller Ausgabe von Daten mit nur 9600 - da verstopft schnell die Datenleitung. Auch bei UART Kommunikation mit anderen seriellen Geräten ist 9600 viel zu lnagsam.
Die Frage war nach dem WIESO. Und meine Antwort ist WEIL es die Default-Einstellung ist!
Ob Default-Werte sinnvoll sind, wurde nicht gefragt, aber irgendein Wert muss nach der Initialisierung in den Registern stehen.
Ich weiss auch nicht wieso die meisten Leute mit Daten-, Parity- und Stop-Bits und der Baudrate überfordert sind?
Ich bin jetzt seit 1976 beruflich mit der Entwicklung beschäftigt und die serielle Schnittstelle war immer für die meisten ein Horror, auch für Techniker und Ings.
Vermutlich weil man auf beiden Seiten 4 Parameter gleich einstellen muss, damit die Verbindung funktioniert. Nur mit kindlichem Rumspielen bekommt man es eben meist nicht hin.
Hinzu kommt noch, dass es oft mehr als nur 3 Drähte benötigt, da sind noch ein paar Statusleitungen, welche man im einfachsten Fall brücken muss, damit der Sender überhaupt etwas sendet.
Achja, erschwerend ist noch, dass es zwei unterschiedliche Steckerbelegungen gibt, DTE und DCE. Je nach dem sind die Leitungen Pin zu Pin oder man muss sie richtig kreuzen.
Für mich war das nie ein Problem, auch wenn die Verbindung auch bei mir nicht immer beim ersten Versuch funktioniert hat.
Und wo liegt der Unterschied?super, aber wenn Processing der Flachenhals ist, wäre es besser, den Datenstrom am Arduino runterzuregeln durch delays oder millis, und nicht dem Bus am Arduino mit Gewalt (Serial.begin(2400) ) den Hahn zuzuquetschen bis nichts gar mehr reingeht
Mit beiden varianten wird die nutzbare Bandbreite begrenzt. Nur kommt die Herabsetzung der Baudrate ohne zusätzlichen Code aus und lässt sich auch einfach wieder aufheben. Bei Geräten, bei welchen man keinen Einfluss auf den Code hat, ist das Herabsetzen der Baudrate die einzige Möglichkeit, wenn ein Empfänger "überfahren" wird. Wobei es eigentlich noch die genormten Handshakes gäbe!
Und wo ist der Vorteil, wenn man mit delays die Rechenleistung verbrät?
Das ist auch ein Vorteil von Interrupts, so lange der Puffer nicht voll ist, muss man keine Rechenleistung verbraten.
MfG Peter(TOO)
- - - Aktualisiert - - -
Hallo Inka,
Das ist jetzt eher etwas für eine Psychologie-Forum
WAS hast du noch nicht richtig verstanden? Furcht hat man eigentlich nur vor etwas unbekanntem.
Eine Interrupt ruft eigentlich nur ein Unterprogramm auf. Der Aufruf erfolgt halt nur nicht an einer festgelegten Stelle im Programm, sondern wenn ein Ereignis (Signal an Pin, Timer abgelaufen) eintritt.
Kommt jetzt noch darauf an, auf welcher Ebene man das Programmiert und welche CPU verwendet wird. Auf Assemblerebene muss man selber die Register retten und wieder richtig herstellen, sowie den Interrupt quittieren. Reines C nimmt einem die Arbeit mit den Registern schon mal ab. Mit passenden Bibliotheken oder meist auch in BASIC, hat da schon wer die passenden Routinen geschrieben.
So ein Interrupt ist auch nicht anders wie ein Telefonanruf bei der Arbeit. Man muss die aktuelle Arbeit bei Seite legen und den Anruf entgegen nehmen. Nach dem Telefon nimmt man die Arbeit wieder auf. OK, die CPU hat es da einfacher, die vergisst nichts und macht genau beim unterbrochenen Befehl wieder weiter.
MfG Peter(TOO)
Zitieren
Lesezeichen