Ich sende per UART an einen Tiny25 einige Bytes und lasse diese zurücksenden. Ich habe einen 100nF Kondensator (Farnell 1414664) zwischen GND und VCC geschaltet. Mit diesem kommen manche Bytes mit falschem Wert zurück, wenn ich den Kondensator entferne funktioniert es wunderbar. K Kennt jemand dieses Problem?
>Kennt jemand dieses Problem?
Ja, schliess den Kondensator an den richtigen Pins an;)
Ist an PIN4 (VCC) und PIN8 (GND) angeschlossen. Es ist ein Tiny25 mit SOIC Gehäuse, wäre doch richtig?
Dem ATtiny25 mal nen Quarz spendieren, dann klappts auch mit der Baudrate. Peter
>habe einen 100nF Kondensator (Farnell 1414664) zwischen GND und VCC >geschaltet.
Mit diesem kommen manche Bytes mit falschem Wert zurück, >wenn ich den Kondensator
entferne funktioniert es wunderbar.
Also, an der Betriebspannungsentkopplung liegt es garantiert nicht!
Sitzt der Cap mit kürzesten Anschlüssen zwischen den VCC- und GND-Pins
des µC?
Ich stimme dem Peter zu, Quarz verwenden. Im Datenblatt sieht man die Abhängigkeit der Frequenz des internen Oszillators von der Betriebsspannung (und der Temperatur). Man kann, z.B. indem man bei einer "3"(x30) oder einem Blank (0x20) die Highzeiten mißt eine Art "Autobaud-Funktion" erzeugen, und sich der "Sendeseite" anpassen. Hilft oft, aber ein Quarz ist halt die sauberere Lösung. Autobaurate funktioniert gut, die Grundidee stammt aus einer Intel-App-Note zu Intels Basic-Chip 8052-Basic.
Die PINS für einen externen Takt habe ich nicht zur Verfügung. Ich habe im Datenblatt gelesen, dass die genauikeit bis auf 3% gebracht werden kann. Die Spannung halte ich konstant auf 5V. Bei der Temperatur gehe ich von Zimmertemperatur aus, werde ich noch austesten was so 10Grad unterschied ausmacht. Ich habe die Controller gestern gelötet und getestet. Mit meinem Hobbylötverfahren (Kochtop) wurden die Tinys etwas warm. Heute hat die Kommunikation ziemlich gut funktioniert. Kallibrieren des Taktes werde ich machen und die automatische Variante scheint recht interesant zu sein. Zudem habe ich auch die Möglichkeit zu prüfen ob ein Telegramm angekommen ist. Mein Projekt: Ich schalte RGB Module mit einem Tiny in Serie (UART), ein Steuergerät schickt ein Befehl(Telegram) auf den ersten und gibt die Farbe für das RGB vor, dieses Telegram wird weitergeschickt bis es wieder beim Steuergerät ankommmt. So weis das Steuergerät welche Befehle korrekt angekommen sind, und kann allenfalls das Telegram wiederholen. Also so bei 80-90% korrekten Telegrammen bin ich schon zufrieden :-)
Heleon schrieb: > Mein Projekt Klingt irgendwie komisch, dafür eine Punkt-zu-Punkt-Verbindung zu mißbrauchen. Wäre I2C für sowas nicht besser? Bräuchte erstens keinen genauen Takt, zweitens ist es ein Bus. :-)
Heleon schrieb: > Also so bei 80-90% korrekten Telegrammen bin ich schon zufrieden :-) Falsche Einstellung. Wenn es sich um Störungen handelt, die ich nicht beeinflussen kann, dann kann ich nichts machen und muss sehen, wie ich damit zu recht komme. Wenn ich es allerdings selbst in der Hand habe eine 100% sichere Kommunikation aufzubauen, dann ist alles unter 100% nicht akzeptabel. Es ist immer einfacher, Fehler gar nicht erst enstehen zu lassen als Fehler hinterher aufwändig auszubügeln. Und es ist nicht nur einfacher, es ist auch zuverlässiger.
Hmm, zu Deinem C Problem kann ich nichts sagen (Außer, daß meine ATmegas ohne Quarz und 9600 Baud recht gut + temperaturstabil laufen (Glück?)). Allerdings halte ich die Tote Ring Simulation überdenkenswert. Warum nicht parallel und mit Dioden und Pull-Up entkoppeln. So kann man Broadcasten, Gruppen und einzeln adressieren. Ein Ausfall eines Teenies hat da auch weniger Konsequenzen und die Fehlersuche ist da evtl. leichter. Wenn es einen Master gibt, dann ist das Protokoll auch relativ einfach zu bauen. MfG, Andreas
Ja da hast du recht, ich möchte die Übertragung natürlich möglichst zuverlässig haben. Darum werde ich jetzt mal die Idee mit der automatischen kallibrierung prüfen. Ich habe auch eine I2C Version programmiert, nachteil ist die maximale Leitungslänge.
Schon mal über ein Master/Slave System über RS485 nachgedacht?
Heleon schrieb: > Ich habe auch eine I2C Version programmiert, > nachteil ist die maximale Leitungslänge. Hast du da mal Zahlen? Wenn du "nur" TTL-Pegel verwendest: was soll an der I²C Leitungslänge anders sein als an der RS232 Leitungslänge? Und wie üblich: lies einfach mal deine Fragestellung so durch, wie wenn du von deinem Problem nichts wüsstest (so gehts nämlich allen anderen). Wenn dann alles Nötige gesagt, beschrieben und damit klar ist: Absenden.
Bond schrieb: > Im Datenblatt sieht man die Abhängigkeit der Frequenz des internen > Oszillators von der Betriebsspannung (und der Temperatur). Mit welcher Taktfrequenz kommen denn bei dir die Bits aus der Leitung des Tiny. Hast du die mal nachgemessen, wo du da in den zulässigen Toleranzen zu deiner Datenquelle liegst, bevor du die Abhängigkeit von Betriebsspannung und Temperatur als Fehler höherer Ordnung analysierst.
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.