Hallo, ist wohl besser einen Thread zu benutzen statt immer wieder neue aufzumache, zudem ich die eh nicht mehr wiederfinde bei dem Durchsatz hier :-) Ich werde daher künftig nur noch hier reinschreiben und bitte die Leser hier nicht zu spammen, danke. Ich konnte inzwischen feststellen, dass die RTC eine Abweichung von ca 10s-15s / Tag hat, wenn sie mit externem Quarz läuft und mit einer 3V Batterie gepuffert wird. Wenn ich zb früher eine DS13xx RTC verwendet habe, dann musste ich zwingend einen 15pf C-Trimmer an den Quarz anschliessen und mit einem Frequenzzähler den Quarz solange justieren, bis die Frequenz am Testpin bei der mittleren Einsatztemperatur stimmte. Denn exakt passende Quarze sind selten, vor allem wenn die Lastkapazität nicht einstellbar ist, ein 12pf Quarz an einem 6pf Oscillator läuft nunmal zu schnell. Ausserdem ist es wichtig ob er ein Serienschwinger ist oder Parallelschringer. Nur als Bastler kann man ja immer nur die nehmen, die es von der Stange bei Reichelt etc gibt. Gibt es da ähnliche Mechanismen wie man die RTC im Arm Trimmen kann? Hat cda mal jemand experimentiert? Gruss, Christian
Manche ARMs (keine Ahnung welchen du hast) haben extra einen 32kHz Quarz eingang... hab selbst einen (lpc2148) der hat eine extra Uhrenquarz. Bei dem habe ich nach ~1woche 5sec abweichung gehabt... Aber wenn man den aus dem Systemtackt generiert... ist klar das der recht starke abweichungen hat.
Ich erzeuge aus einem 32khz Quarz am LPC2138, der hat dafür einen internen Oscillator eingebaut. Aus dem Systemtakt dürfte auch nicht ungenauer sein, da er ein Vielfaches ist und zudem einen exkakt einstellbaren Teiler hat, d.h. man gibt die Zahl an, die ein interner Timer hochzählen muss, damit er aus Systemtakt exakt 32768 macht. Ist ein Timer-Match Register.
Hallo, vielleicht finde ich ja noch einen Crack hier :-) Anbei ist das FAT Projekt für Rowley Crossworks 1.7 mit der efsl Library aus sourceforge.net. Es enthält eine völli abgespeckte main Routine mit sinnlosen Funktionaufrufen damit die Routinen nicht wegoptimiert werden. Problem: Beim Compilerlauf mit "Flash Debug" wird ein Linkerfehler "__debug_io_lock not referenced" erzeugt dessen Ursache ich nicht lokalisieren kann, da sich diese Funktion im Inneren einer Liberary der Entw.umgebung befindet, genauer im ctl.lib Code. Funktionsweise: Beim "Flash Debug" wird vermutlich ein DEFINE DEBUG automatisch erzeugt (im Preprocessor aber nicht sichtbar). denn fügt man den manuell ein ergibt es eine Fehlermeldung, dass der doppelt ist. Bei "Flash release" ist das nicht der Fall, es werden auch alle Debug Funktionen des Codes nicht mit compiliert, weil die alle durch ifdef Abfragen eingebunden sind. Vielleicht findet ja jemand den Fehler und schickt mir den Code zurück, dann hat er eine konfortable Basis für ein SD Card Filesystem unter ARM7 bzw alternativ auch AVR, das Zieltarget lässt sich in der config.h einstellen. Bin echt am Ende mit meiner Weisheit :-( Gruss, Christian
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.