Hallo, Ist das richtig, dass es mit dem internen Oszillator des Attiny 85 öfters zu Problemen kommt, und man lieber einen extern verwenden sollte? Grüße
Luis schrieb: > Ist das richtig, dass es mit dem internen Oszillator des Attiny 85 > öfters zu Problemen kommt, und man lieber einen extern verwenden sollte? nein.
Luis schrieb: > Ist das richtig, dass es mit dem internen Oszillator des Attiny 85 > öfters zu Problemen kommt, und man lieber einen extern verwenden sollte? Der interne Oszillator macht Null Probleme. Probleme machen höchstens unsachgemäße Anwendungen.
Der interne RC Oszillator ist nur selten genau auf 8Mhz, aber das ist auch sein einziges Problem. Er treibt im Allgemeinen den MC gut an und braucht nur wenig Nahrung.
Beitrag #5068799 wurde von einem Moderator gelöscht.
Also Mal ganz ehrlich, ich habe auch schon so einige Projekte mit Tinys und Megas gemacht. Die "Angst" das die UART z.b. nicht läuft kann ich beim besten Willen nicht nachvollziehen. Ich nutze in meinen Projekten eigentlich immer die UART und wenn es nur für die Debugausgabe ist. Einen externen Quarz kam da noch nie wirklich ins Spiel. Nur wenn der MC einen wirklich definierten Pegel (Uhrenquarz etc...) braucht nutze ich diesen auch. Selbst zwei USBASP Programmer lasse ich ohne Quarz laufen und es gab noch nie Probleme damit. Für Produktivsysteme verbaue ich allerdings immer einen Externen. Da man die Wald- und Wiesen-Gegebenheiten nicht kennt.
Rene K. schrieb: > Die "Angst" das die UART z.b. nicht läuft kann ich > beim besten Willen nicht nachvollziehen. Das geht mir übrigens genauso, allerdings verwende ich, weil ichs nicht so eilig habe, auch meistens gemächliche Baudraten wie 9600 oder 19200. Dabei klappts immer mit dem internen RC Oszillator - noch nie was gegenteiliges festgestellt.
Ich verwende den Attiny für einen TV bei gone, falls euch das was sagt. Also um bestimme Frequenzen mit der Infrarotdioden zu erzeugen.
Und muss ich wenn ich den Internen benutze meine Ausgänge für den Externen brücken oder lass ich diese offen ?
Luis schrieb: > Und muss ich wenn ich den Internen benutze meine Ausgänge für den > Externen brücken oder lass ich diese offen ? Nö, du kannst bei Benutzung des internen Oszillator die Pins als ganz normale Portpins benutzen. PB3 und PB4 sind dann verfügbar. Kannst du freilassen oder als Eingang oder Ausgang benutzen.
Matthias S. schrieb: > Das geht mir übrigens genauso, allerdings verwende ich, weil ichs nicht > so eilig habe, auch meistens gemächliche Baudraten wie 9600 oder 19200. > Dabei klappts immer mit dem internen RC Oszillator... Ein relativer Fehler bleibt doch immer gleich, egal ob 9600 oder 115200 Bd.
Beitrag #5068920 wurde vom Autor gelöscht.
Matthias S. schrieb: > Das geht mir übrigens genauso, allerdings verwende ich, weil ichs nicht > so eilig habe, auch meistens gemächliche Baudraten wie 9600 oder 19200. > Dabei klappts immer mit dem internen RC Oszillator - noch nie was > gegenteiliges festgestellt. Mit geringen Baudraten kannst du allenfalls den systematischen Fehler gering halten, aber rein garnix gegen den absoluten Taktfehler unternehmen. Das "Geringhalten" des systematischen Fehlers wirkt sich aber natürlich insofern positiv aus, als dass dadurch die Spanne des zulässigen absoluten Taktfehlers entsprechend erweitert wird. Aber: spätestens, wenn der absolute Taktfehler in Richtung 2% geht, wird die Kommunikation ziemlich sicher scheitern (hängt natürlich auch vom Peer ab, wann genau das passiert). Und 2% sind beim internen RC-Oszillator schnell erreicht. Mit ein bisschen Pech ist er schon bei der Auslieferung bei Zimmertemperatur 2% daneben (garantiert sind bei sehr vielen AVRs sogar nur 10%, bei einigen neueren etwas weniger). Aber selbst, wenn's bei Zimmertemperatur mehr oder weniger zufällig noch gut passt: Spätestens: bei 50°C Umgebungtemperatur oder -15°C Umgebungstemperatur ist dann Schicht im Schacht... Wenn du das nicht begreifst, bist du einfach nur blöd! Zu bescheuert zum verstehenden Lesen von Datenblättern. Da gibt es wunderschöne Diagramme zum Thema ambient temperature vs. clock frequency...
c-hater schrieb: > Zu bescheuert zum > verstehenden Lesen von Datenblättern. Aha. Wenn du das gemacht hättest, wüsstest du allerdings, das der Tiny85, um den es ja hier geht, gar kein UART hat. Wenn man also ein Soft-UART implementiert, synchronisiert sich das aufs Startbit und damit ist der Fehler innerhalb eines Zeichens von 2% oder meinetwegen 5% überhaupt nicht relevant - es reicht immer, um bis zum Stopbit fehlerfrei zu lesen. Bei Hardware UARTs ist es genau das gleiche. Der Empfänger synchronisiert auf die fallende Flanke des Startbits. Übrigens wieder mal schön, das du erst auftauchst um rumzupöbeln, wenn alle Fragen des TE schon beantwortet sind. Du hast also erheblich zum Thread beigetragen.
c-hater schrieb: > Wenn du das nicht begreifst, bist du einfach nur blöd! Zu bescheuert zum > verstehenden Lesen von Datenblättern. Du hast Dich einfach nicht im Geringsten im Griff. Kein Beitrag von Dir, in dem Du Dich nicht in die Tastatur erbrichst! Die Beiträge von Matthias sind die, die ich hier am meisten schätze. Deine dagegen sind nur Dreck-um-sich-werfen. -Feldkurat- So, sperrt mich, löscht mich, spielt schach mit mir... Ist mir Wumpe. Was gesagt werden muß, muß gesagt werden!
c-hater schrieb: > Zu bescheuert zum > verstehenden Lesen von Datenblättern. Na ja, du offensichtlich auch. Du kannst den selbst kalibrieren und dann hat er, "garantiert", 1% (oder besser). Mach dir doch mal den Spaß und miss das mal mit nem Oszi nach. Ich habe das im Anfang getan. Die (ich nehme aber meistens den Tiny10) sind alle nie +/- 10% gewesen, sondern waren sehr exakt. Die prozentuale Abweichung habe ich nicht geprüft, weil alle die ich geprüft hatte, wirklich ein sehr genauen Takt hatten.
:
Bearbeitet durch User
F. F. schrieb: > Du kannst den selbst kalibrieren und dann > hat er, "garantiert", 1% (oder besser). Für eine gegebene Temperatur, ja. F. F. schrieb: > Ich habe das im Anfang getan. Die (ich nehme > aber meistens den Tiny10) sind alle nie +/- 10% gewesen. Das wäre dann der Unterschied zwischen "typical" und "min/max". Da gabs letztens auch ne schöne Diskussion zu. Zum Basteln reicht der RC aus.
S. R. schrieb: > Zum Basteln reicht der RC aus. 1000 Mal sogar. Gerade bei diese kleinen µC. Was macht man da schon groß mit!
Hallo Trotzdem: Nicht vergessen das auch der Attiny und andere kleine µC eben nicht für den Hobbyisten und dessen typischen Anwendungen produziert werden. Professionelle Schaltungen müssen auch wenn man nicht "groß damit" was macht zuverlässig funktionieren - also ist ein Quarz durchaus auch bei Anwendungen sinnvoll oder sogar notwendig die bei dir und mir in der Hobbyeerkstatt mit den internen Oszillator einwandfrei arbeiten. Aber in einer Industriellen Umgebung, im Auto, in Schaltschränken die Draußen stehen... muss die professionelle Schaltung mit den µC auch zuverlässig funktionieren. Daher ist ein Quarz auch bei Schaltungen wo nichts "groß damit gemacht" wird sehr sinnvoll und trägt letztendlich, im professionellen Umfeld, sogar zur Kostensenkung bei - selbst nur eine Reklamation vom Kunden kommt da teurer als der Preis für einige hundert Quarze. Ich bin reiner Hobbist, verwende aber wenn immer möglich Quarze in µC Schaltungen - deren einziger, leider aber auch wesentlicher Nachteil, ihrer mechanische Größe ist - selbst in SMD Ausführung sind die immer "Riesig" zumindest im Vergleich zu allen anderen typischen Bauteilen in einer "typischen" µC Schaltung Jemand
Jemand schrieb: > Aber in einer Industriellen Umgebung, im Auto, in Schaltschränken die > Draußen stehen... muss die professionelle Schaltung mit den µC auch > zuverlässig funktionieren. > Daher ist ein Quarz auch bei Schaltungen wo nichts "groß damit gemacht" > wird sehr sinnvoll und trägt letztendlich, im professionellen Umfeld, > sogar zur Kostensenkung bei - selbst nur eine Reklamation vom Kunden > kommt da teurer als der Preis für einige hundert Quarze. Der interne RC-Oszillator ist das gegenüber einem Quarz weitaus zuverlässigere Bauteil. Erst wenn es um exaktes Timing oder höhere Geschindigkeit geht, kommt der Quarz ins Spiel. Wobei sich die höhere Taktrate auch mit einem Keramikresonator erreichen lässt. Die hohe Genauigkeit geht nur mit Quarz. Die ist aber bei sehr vielen Anwendungen schlichtweg egal.
:
Bearbeitet durch User
Matthias S. schrieb: > Wenn man also ein > Soft-UART implementiert, synchronisiert sich das aufs Startbit und damit > ist der Fehler innerhalb eines Zeichens von 2% oder meinetwegen 5% > überhaupt nicht relevant - es reicht immer, um bis zum Stopbit > fehlerfrei zu lesen. mit 5% bist du nach dem 2. Bit mit dem Abtastzeitpunkt 10% einer Bitbreite daneben, beim 3.Bit 15% und beim 9.Bit 45%, das ist mehr als relevant! Vor ein paar Tagen hatte hier jemand genau dieses Problem mit einem Soft-UART
Thomas E. schrieb: > Jemand schrieb: >> Aber in einer Industriellen Umgebung, im Auto, in Schaltschränken die >> Draußen stehen... muss die professionelle Schaltung mit den µC auch >> zuverlässig funktionieren. > Der interne RC-Oszillator ist das gegenüber einem Quarz weitaus > zuverlässigere Bauteil. Die Kombination aus Industrie mit industrietypischen Vibrationen und "Quarz" ist eine Garantie für häufige Reklamationen. Wenn ein Quarz vermeidbar ist, dann sollte man ihn tunlichst vermeiden. Wenn nicht, dann sollte man sich überlegen, ob man eine redundante Takterzeugung verwendet: Im Normalbetrieb ein Quarz und bei dessen Ausfall einen RC-Oszillator nebst entsprechender Fehlermeldung. Oder man verwendet den internen RC-Oszillator und kalibriert diesen mit der externen Takquelle regelmäßig nach. Geht auch, automatisch versteht sich...
Walter S. schrieb: > mit 5% bist du nach dem 2. Bit mit dem Abtastzeitpunkt 10% einer > Bitbreite daneben, > beim 3.Bit 15% > und beim 9.Bit 45%, das ist mehr als relevant! Abhängig vom Empfänger... Manche können das (per Software) kompensieren.
Walter S. schrieb: > mit 5% bist du nach dem 2. Bit mit dem Abtastzeitpunkt 10% einer > Bitbreite daneben, > beim 3.Bit 15% > und beim 9.Bit 45%, das ist mehr als relevant! Er meint wohl eher dass die 5% sich auf das "Bruttobyte" beziehen: Startbit+datenbyte+Parität+Stopbit. > Vor ein paar Tagen hatte hier jemand genau dieses Problem mit einem > Soft-UART Kommt drauf an was man unter UART versteht: Vollduplex, Halbduplex.... das wird mit einem Softwareuart nat. ab einer gewissen Baudrate kritisch. Nutzt man Timer ist das ziemlich unkritisch. Anfänger fummeln sowas mit delays und üblen if-else-Zeitscheibenkonstrukten zusammen wo sie schnell nicht mehr durchblicken was überhaupt passiert, das klappt dann auch nicht. UART ist wirklich extrem tolerant wenn man niedrige Datenraten fährt. Sync ist ja jedesmal neu nach einem Byte, die 5% oben treffen absolut zu. Wer da irgendwelche Probleme hat, hat sie woanders und nicht wegen des "ungenauen" internen RC. Vollduplex Software-UART mit 115200 wird nat. problematisch aber Halbduplex geht problemlos. Bei so Trivialzeugs wie Tiny + externem UART-Modul gehts doch meist eh nur darum ein paar Kommandos abzusetzen und danach vielleicht noch in eine Richtung Daten runterzuladen/senden also Halbduplexbetrieb. Das schafft hier jeder mickrige Furz-MC, zuletzt wieder selber zusammengefummelt auf einem 8052-Clon, senden mit 230400 Baud, in Software, interner RC, kein Problem.
Steht ein Frequenzmesser zur Verfügung, kann man per Fuse temporär den internen Takt auf einen Ausgangspin geben und ggf. das OSCCAL-Register in der Init-Routine um einige Punkte korrigieren, bis die 8MHz maximal angenähert sind. Eine andere Möglichkeit ist, bei der Initialisierung der seriellen Funktionen die Baudrate entsprechend der Abweichung der gemessenen Taktfrequenz "krumm" anzugeben und somit den Offset des RC über den Compiler rechnerisch kompensieren zu lassen. Mit beiden Methoden kommt man relativ genau an die standardisierten Baudraten heran, womit auch bei int. RC z.B. 128kBit kein Problem darstellen. Gegen größere Temp.-Drift kann bei Bedarf noch der interne Temp.Sensor (sofern vorhanden) mit einbezogen werden, um den OSSCAL-Wert auch diesbezüglich während der Runtime nachzuführen.
Simpel schrieb: > Gegen größere Temp.-Drift kann bei Bedarf noch der interne Temp.Sensor > (sofern vorhanden) mit einbezogen werden, um den OSSCAL-Wert auch > diesbezüglich während der Runtime nachzuführen. Noch besser: Einen externen Takt (mt guter Temperatur-/Langzeitstabilität) zuführen, den internen mit dem externen vergleichen und den internen nachführen. Erfordert etwas Software, funktioniert aber problemlos. Als externe Taktquelle kann man so zimlich alles von Quarzoszillatoren, externe RTC-Bausteine, Funkuhrmodule, Frequenz des Stromnetzes... nutzen.
8MHz => 125µs Bitdauer 9600Baud => 104µs Bitdauer Und da diskutiert ihr über externe Kalibrierung (hat er überhaupt die Pins und Speicher dafür)? Der schafft 4800baud, selbst mit groben Abweichungen macht das erfahrungsgemäss keine Probleme. Spätestens nach einem Byte wird neu gesynced, das ist doch gerade der Gag bei asynchroner serieller Übertragung, da reicht ne Schaukel als Taktquelle, nach spätestens 10 Bits wird sie neu angeschubbst und das Ding ist wieder im Takt. Kalibrieren mit externer genauer Taktquelle, äh ja klar. Ich messe auch die Ziegel mit dem Messschieber wenn ich ein Haus baue.
Matthias S. schrieb: > Aha. Wenn du das gemacht hättest, wüsstest du allerdings, das der > Tiny85, um den es ja hier geht, gar kein UART hat. Das weiß ich. Natürlich. > Wenn man also ein > Soft-UART implementiert, synchronisiert sich das aufs Startbit Was glaubst denn du, was die Hardware-UART tuen würde (wenn es denn eine gäbe)? Natürlich: ganz genau dasselbe. Deren state-machine reagiert natürlich auch auf die Flanke des Startbits und alles nachfolgende passiert relativ dazu, was denn sonst? Deren Entwickler sind doch nicht blöd und so schlau wie du sind sie sowieso allemal, das waren sie schon vor Jahrzehnten... > und damit > ist der Fehler innerhalb eines Zeichens von 2% oder meinetwegen 5% > überhaupt nicht relevant - es reicht immer, um bis zum Stopbit > fehlerfrei zu lesen. Nö. Zu doof zum Rechnen bist du also auch noch. Nehmen wir mal deine (-)5% Fehler: Dann dauern Startbit + 8 Datenbits 9 * 5% = 45% einer Bitzeit zu kurz. D.h.: wenn der Peer ein Stopbit sehen will, sieht er schon fast die Hälfte der Zeit, in der dessen Pegel anliegen sollte, statt dessen ein Startbit, nämlich das des nächsten Bytes. Nun hat aber weder der Peer noch du die Resourcen, um instantan auf den Pegelwechsel beim Startbit zu reagieren. Diese Latenz kommt als zusätzlicher Fehler in's Spiel. Des weiteren die Taktabweichung des Peer, der ja nach deiner hirnverbrannten Logik genau so groß sein dürfte und natürlich entsprechend der Gesetze der Statistik auch durchaus genau entgegengesetzt zu deiner eigenen Taktabweichung ausfallen kann... Erkennst du jetzt, wie blöd du eigentlich bist?
> 8MHz => 125µs Bitdauer
Damit erübrigt sich auch ein Kommentar zum Rest des Beitrages, William
B.
Eine Uhr sollte man mit dem internen RC-Takt nicht bauen. Spätestens bei ungeregeltem Batteriebetrieb kann man den auch als Baud-Taktgeber vergessen. Es sei denn man will diesen mit interner Spannungs- und Temperaturmessung kompensieren, die man jeweils selbst vorher kalibrieren muß. Selbst bei 5V/20°C schaffte bei mir nicht jeder unkalibrierte AVR die 9600 Baud vom PC.
S. Landolt schrieb: >> 8MHz => 125µs Bitdauer > Damit erübrigt sich auch ein Kommentar zum Rest des Beitrages, William > B. Nicht ganz. Der Systemtakt geht schon irgendwie ein, nämlich als Latenz bezüglich der "Wahrnehmung" der Flanke des Startbits. Bei Verwendung einer Hardware-UART ist das simpel, die tastet entweder mit 1/16 oder 1/8 des Systemtaktes ab, je nach Einstellung des U2X-Bits. Dementsprechend liegt die diesbezügliche Latenz beim 8- oder 16-fachen einer Periode der Taktfrequenz. Bei einer Soft-UART wird es komplizierter. Hier kommt der ganze Scheiss der variablen Interruptlatenzen zum Zuge und die konstante Latenz der tatsächlich zuständigen ISR noch oben drauf...
c-hater schrieb: > Erkennst du jetzt, wie blöd du eigentlich bist? Erkennst du eigentlich irgendwann mal selbst, daß du nur zum Kotzen bist?
c-hater schrieb: > S. Landolt schrieb: > >>> 8MHz => 125µs Bitdauer > >> Damit erübrigt sich auch ein Kommentar zum Rest des Beitrages, William >> B. > > Nicht ganz. c-hater schrieb: > Erkennst du jetzt, wie blöd du eigentlich bist? Wie blöd muss man denn sein, das man das nicht erkennt? Kleine Testfrage: Welche Periodendauer ists denn nun wirklich bei 8MHz, c-hater? Kleine Hilfestellung - 1Mhz wäre 1µs. Damit erübrigt sich alles weitere.
Meine Güte schrieb: > Erkennst du eigentlich irgendwann mal selbst, daß du nur zum Kotzen > bist? Nun, ich präsentiere nur Fakten. Wenn die dich zum Kotzen bringen, dann hast du wohl irgendwie ein Problem mit der Akzeptanz der physischen Realität. Irgendwie ist das aber wohl nicht mein Problem, sondern deins...
Matthias S. schrieb: > Wie blöd muss man denn sein, das man das nicht erkennt? Kleine > Testfrage: Welche Periodendauer ists denn nun wirklich bei 8MHz, > c-hater? > Kleine Hilfestellung - 1Mhz wäre 1µs. Du bist ein solch unwissender Vollidiot, dass es eigentlich keinen Sinn macht, zu antworten. Aber wegen des allgemeinen Interesses dann doch noch: Na klar dauert bei 8MHz Takt jede Taktperiode 125ns (nicht µs!). Das ist aber überhaupt nicht der Punkt. Und jeder, der des verstehenden Lesens mächtig ist, hat auch erkannt, worum es mir ging. Nämlich karzustellen, warum es eine idiotische Idee ist, sich bei beabsichtigter UART-Kommunikation auf den RC-Oszillator zu verlassen. Nur grenzdebile Vollidioten machen das (ohne weitere Massnahmen). Mögliche Massnahmen wurden im Thread bereits alle genannt, von der Kalibrierung bis zur Temperaturkompensation, alles, was möglich und nützlich ist. Die einfachste aller Maßnahmen ist aber nach wie vor ein Quarz für 2x Cent zu verbauen. Und wenn nicht gerade Anforderungen wie extreme Vibrationsfestigkeit dagegen sprechen, ist das das ultimative Mittel.
c-hater schrieb: > Irgendwie ist das aber wohl nicht mein Problem, sondern deins... Ach, wenn es weiter nichts ist. Nur, wer sowas nötig hat: c-hater schrieb: > Zu doof zum Rechnen bist du also auch noch. c-hater schrieb: > der ja nach deiner hirnverbrannten Logik c-hater schrieb: > Erkennst du jetzt, wie blöd du eigentlich bist? c-hater schrieb: > Du bist ein solch unwissender Vollidiot c-hater schrieb: > Nur grenzdebile Vollidioten machen das der hat aber richtige Probleme. Und das sind ganz allein deine. Viel Spaß damit und kotz dich ruhig weiter aus.
Meine Güte schrieb: > der hat aber richtige Probleme. Und das sind ganz allein deine. Viel > Spaß damit und kotz dich ruhig weiter aus. Der kann nicht anders. Der ist im Tiefflug durch die Kinderstube geflogen und hat schon sein Kindermädchen verprügelt, weil sie "zu doof" war, ihn zu windeln...
William Bodie schrieb: > Kalibrieren mit externer genauer Taktquelle, äh ja klar. Ich messe auch > die Ziegel mit dem Messschieber wenn ich ein Haus baue. doch, wirklich. Wenn es genau werden muss und auch ohne Quarz laufen muss. Quarz und Vibrationen vertragen sich nicht besonders gut, hier ist es wirklich eleganter/zuverlässiger eine andere Taktquelle (Netzfrequenz, Funkuhr...) zu nutzen.
c-hater schrieb: > Die einfachste aller Maßnahmen ist aber nach wie vor ein Quarz für 2x > Cent zu verbauen. Und wenn nicht gerade Anforderungen wie extreme > Vibrationsfestigkeit dagegen sprechen, ist das das ultimative Mittel. stimmt definitiv.
Kolja schrieb: > Der ist im Tiefflug durch die Kinderstube geflogen und hat schon sein > Kindermädchen verprügelt, weil sie "zu doof" war, ihn zu windeln... Glaube ich nicht. Der hat ne Olle zuhause, die ständig auf Knien vor ihm liegt. "Komm unter dem Bett raus, du Feigling!"
Beitrag #5070356 wurde von einem Moderator gelöscht.
William Bodie schrieb: > Spätestens nach einem Byte wird neu gesynced, das ist doch gerade der > Gag bei asynchroner serieller Übertragung, da reicht ne Schaukel als > Taktquelle, nach spätestens 10 Bits wird sie neu angeschubbst und das > Ding ist wieder im Takt. Das setzt voraus, dass zwischen den Bytes auch mal Pause ist. Kommt dein System einmal aus dem Takt, hast du sonst verloren.
Schreiber schrieb: > c-hater schrieb: >> Die einfachste aller Maßnahmen ist aber nach wie vor ein Quarz für 2x >> Cent zu verbauen. Und wenn nicht gerade Anforderungen wie extreme >> Vibrationsfestigkeit dagegen sprechen, ist das das ultimative Mittel. > > stimmt definitiv. Ist aber in dem Haufen Erbrochenem, in dem es lag, kaum zu erkennen.
c-hater schrieb: > Du bist ein solch unwissender Vollidiot, dass es eigentlich keinen Sinn > macht, zu antworten. Du hingegen bist erst hier aufgetaucht, als die Fragen des TE bereits längst beantwortet waren und hast nullkommanix zum Thema beigetragen. Dir blieb also nichts anderes, als mit unangemessenen Kraftausdrücken wieder mal deinen Hass auf die Welt hinauszutröten. Das sind natürlich zugkräftige Argumente und deiner würdig.
Matthias, der kann dir doch nicht das Wasser reichen. Nicht mal ein leeres Glas.
Matthias S. schrieb: > Du hingegen bist erst hier aufgetaucht, als die Fragen des TE bereits > längst beantwortet waren und hast nullkommanix zum Thema beigetragen. > Dir blieb also nichts anderes, als mit unangemessenen Kraftausdrücken > wieder mal deinen Hass auf die Welt hinauszutröten. Das sind natürlich > zugkräftige Argumente und deiner würdig. Warum antwortest du ihm überhaupt? Den muss man links liegen lassen und ausgrenzen.
batman schrieb: > Das Stoppbit IST die Pause zwischen den Bytes. Nur, wenn man das richtige Startbit korrekt erkannt hat.
Hallo Luis, merkwürdig, dass sich manche Teilnehmer IMMER WIEDER um RS232 / Baudrate und Quarz, oder internen RC-Oszillator streiten. Passt hier aber nicht - du hast doch TV Be Gone erwähnt: Bei den üblichen IR-Empfängern ist die Toleranz für die Pulsfrequenz (z.B. 36 kHz) im Bereich von 2...5% Auch die üblichen IR-Codes werden bei ähnlicher Variation der Puls-/Pausenzeiten noch gut erkannt. Wenn der RC-Oszillator halbwegs bei Raumtemperatur abgeglichen ist, wird er im Klimabereich von TV-Empfängern (0...50 °C) gut funktionieren. Frequenzvariation ist etwa +/-1%.
Bitte 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.