Hey, möchte mir eine schöne kleine Wanduhr bauen mit einem µC und einem RTC. Kann mir jemand vielleicht ein einfaches und leichtes Tutorial verraten? Also wo ich einmal werte an den RTC übermittel um die Uhr im RTC zu stellen und einmal eine einfache Abfrage der Zeit. Würde gern mit dem I2C Bus anfangen mich zu beschäftigen. Michael
Im Ordner von Bascom gibt es ein beispiel. siehe: C:\Programme\MCS Electronics\BASCOM-AVR\SAMPLES\I2C\ds1307.bas Gruss k.
Ja gut, ihn gibts. Habs mir angeguckt, nur so noch nicht richtig verstanden habe ich wie ich da nun die Aktuelle Zeit rein bekomme. Weil so weiß er ja nicht welcher Tag heute ist und wie spät. Weil den Code hatte ich schon mal genommen, stand in einem Forum und er hat nur müll ausgegeben und keine normale Uhrzeit bzw. Datum. Danke für Eure Hilfe. Michael
Schau mal hier:
1 | ' assigning the time will call the SetTime routine |
2 | Time$ = "23:58:59" ' to watch the day changing value |
3 | Date$ = "11-13-02" ' 13 november 2002 |
Damit stellt man die aktuelle Zeit und das Datum ein. SDA und SCL müssen auch stimmen. Ich bezweifle, dass der Code nicht funktioniert. Der I2C-Bus bzw. die daran angeschlossene DS1307-RTC reagiert recht empfindlich auf Störungen, zu lange Leitungen und unpassende Pull-Up-Widerstände.
Angehängte Dateien:
-
rtc-Anbindung.png
82 KB
Ich habe den RTC wie folgt angeschlossen. Bild Packe ich in den Anhang. Michael
geh mit den Pullups mal lieber so auf 2k. Gruss k
Also wenn die beiden Jumper geschlossen sind, ist das gut so. Du kannst auch mal das Minimalbeispiel im Anhang ausprobieren und berichten.
Werte es gleich mal Testen. Also Widerstände tauschen und den minimalcode übermitteln. Hoffe es klappt dann. Melde mich dann.
So ich habe es gerade getestet. Und bei dem Code gibt er bei meinem COM - Schnittstelle nur folgendes aus: @5.@5.@5 @5:@5:@5 Und dies fortlaufend anzeigend. Also keine Erneuerung der Zeit oder so. Habe die Zeit aus dem Code einfach ersma übernommen, was aber ja noch keine Probleme bereiten soll. Weil der RTC ja nicht weiß ob ich Ihm die Wahrheit erzähle. Ich benutze das AVR Board von Pollin. Eine Frage noch vorab: Const DS1307w = &HD0 Const DS1307r = &HD1 Ist doch die Adresse des RTCs. Die ist aber nicht wie beim einem 1-Wire Bus fest eingestellt oder? Den Widerstand habe ich gegen 2,2kOhm getauscht. Und Kabellänge sollte eigentlich noch nich das Problem sein. es sind nur 10 cm (wenn nich sogar weniger) zzgl. das kurze Flachbandkabel was den Adapter für das Laborbrett mit dem AVR Board verbindet. Michael
Michael N. schrieb: > @5.@5.@5 > @5:@5:@5 Typische Anzeige bei "schlechter" Verbindung. Verlangsame mal die Busgeschwindigkeit:
1 | Config I2cdelay = 100 |
oder probier mal Hardware TWI
1 | $lib "i2c_twi.lbx" |
2 | Config Twi = 100000 |
Michael N. schrieb: > Const DS1307w = &HD0 > Const DS1307r = &HD1 Die Adressen sind fest. Michael N. schrieb: > Und Kabellänge sollte > eigentlich noch nich das Problem sein. es sind nur 10 cm (wenn nich > sogar weniger) 10 cm ist schon nicht ohne. Die Buskapazität ist hier entscheidend.
So habe beide Varianten schon getestet. Leider kommt das gleiche ergebnis raus. Also er gibt weiter dieses Oben genannte aus. Habe auch noch mal alles kontrolliert, dass ich nichts verkehrt zusammen gesteckt habe. Nur normal dachte ich, dass das Laborbrett und das AVR Board von Pollin wäre eine gute Wahl für den Anfang. Nur an sich ist es ärgerlich. Weil ich wollte jetzt nicht alles auf einer Platine löten um einen nahezudirekte Verbindung hin zu bekommen. Wäre fürs üben nur etwas umständlich. Daher habe ich mir das Board gekauft gehabt. Michael
Das Pollin-Board, dass ich habe, führt teilweise die Pins in Verbindung mit dem Breadboard-Adapter nicht richtig heraus. Ich benutze es bloß schon länger nicht mehr, so dass ich nicht mehr genau weiß, wie das war. Probier doch einfach mal andere Pins aus (dann halt nur Software-I2C) oder teste die Pins auf Funktion (LED leuchten lassen, Spannung messen, etc).
Ich weiß, dass die Pins verschoben sind, wenn ich den Mega8 nehmen, aber dafür gab es eine Schablone für. Also in der hinsicht sollte das hin hauen. Aber ich werde mal eine LED anklemmen und LEDs ein und ausschalten lassen. Meld mich gleich noch mal dann. Michael
So habe schon die Ports getestet. Und es klappte. Also habe die entsprechenden Output Pins im wechsel ein und ausgeschalten und es funktionierte wunderbar. Also schon mal zur Info. Michael
Hey, irgendetwas stimmt mit Deinem DS1307 auf dem Schaltplan nicht. Schau mal ins Datenblatt: http://datasheets.maxim-ic.com/en/ds/DS1307.pdf So, muss jetzt mal ins Bett....
Habe mir das noch mal angeguckt. Also wenn ich beim aufstecken nichts falsch gemacht habe sollte das Passen. Also den Quarz habe ich auf Pin 1 und 2 gepackt, Pin 3 ist + der Batterie, 4 GND von VCC und Batterie, 5 sda, 6 scl, 7 offen und 8 VCC. SDA und SCL sind mit Widerständen von 2,2 k gegen Vcc. Michael
1. Der Quarz muss kurz und kapazitätsarm angeschlossen werden. Sonst läuft die Uhr nicht. Belastung am Quarz (DVM, Oszi) lässt ihn sofort stoppen. 2. Der DS1307 muss gestartet werden, d.h. es eventuell muss das Clock-Hold-Bit geleöscht werden, sonst läuft die Uhr nicht los. 3. Der DS1307 muss mit einer gültigen Zeit initialisiert werden, sonst stehen irgendwelche Werte in den Registern, und wenn er nicht läuft bleiben die auch so. In ASM sieht das so aus, ist also nicht sonderlich kompliziert:
1 | ;**** RTC initialisieren **** |
2 | |
3 | init_rtc: |
4 | rcall twi_start ;Start TWI |
5 | |
6 | ldi DATA, 0b11010000 ;DevSel und /Write |
7 | rcall twi_write ;DevSel senden |
8 | ldi DATA, 0x00 ;Adresse 0x00 |
9 | rcall twi_write ;Adresse senden |
10 | |
11 | rcall twi_stop ;Stop TWI |
12 | |
13 | rcall twi_start ;Start TWI |
14 | ldi DATA, 0b11010001 ;DevSel und Read |
15 | rcall twi_write ;DevSel senden |
16 | rcall twi_readnoack ;TWI lesen, sec |
17 | |
18 | rcall twi_stop ;Stop TWI |
19 | |
20 | sbrs DATA, 7 ;Test auf ClockHalt |
21 | rjmp rtc_ok ;wenn nicht gesetzt, Uhr ok |
22 | |
23 | ;Uhr neu starten |
24 | push DATA ;DATA sichern |
25 | rcall twi_start ;Start TWI |
26 | ldi DATA, 0b11010000 ;DevSel und /Write |
27 | rcall twi_write ;DevSel senden |
28 | ldi DATA, 0x00 ;Adresse 0x00 |
29 | rcall twi_write ;Adresse senden |
30 | pop DATA ;DATA holen |
31 | cbr DATA, 1<<7 ;ClockHalt löschen, muß 0 sein |
32 | rcall twi_write ;Daten senden |
33 | |
34 | rcall twi_stop ;Stop TWI |
35 | rtc_ok: |
36 | ret ;zurück RTC init |
37 | |
38 | ;**** RTC Zeit senden **** |
39 | |
40 | rtc_set_time: |
41 | rcall twi_start ;Start TWI |
42 | |
43 | ldi DATA, 0b11010000 ;DevSel und /Write |
44 | rcall twi_write ;DevSel senden |
45 | |
46 | ldi DATA, 0x00 ;Adresse 0x00 |
47 | rcall twi_write ;Adresse senden |
48 | |
49 | lds DATA, Artcss ;Daten sec |
50 | cbr DATA, 0b10000000 ;ClockHalt löschen, muss 0 sein |
51 | rcall twi_write ;Daten senden |
52 | |
53 | lds DATA, Artcmm ;Daten min |
54 | rcall twi_write ;Daten senden |
55 | |
56 | lds DATA, Artchh ;Daten hours |
57 | rcall twi_write ;Daten senden |
58 | |
59 | rcall twi_stop ;Stop TWI |
60 | |
61 | ret ;zurück RTC Zeit senden |
62 | |
63 | ;**** Zeit holen **** |
64 | |
65 | rtc_get_time: |
66 | rcall twi_start ;Start TWI |
67 | |
68 | ldi DATA, 0b11010000 ;DevSel und /Write |
69 | rcall twi_write ;DevSel senden |
70 | ldi DATA, 0x00 ;Adresse 0x00 |
71 | rcall twi_write ;Adresse senden |
72 | |
73 | rcall twi_stop ;Stop TWI |
74 | |
75 | rcall twi_start ;Start TWI |
76 | ldi DATA, 0b11010001 ;DevSel und Read |
77 | rcall twi_write ;DevSel senden |
78 | rcall twi_readack ;TWI lesen, sec |
79 | sts Artcss, DATA |
80 | rcall twi_readack ;TWI lesen, min |
81 | sts Artcmm, DATA |
82 | rcall twi_readnoack ;TWI lesen, hours |
83 | sts Artchh, DATA |
84 | |
85 | rcall twi_stop ;Stop TWI |
86 | |
87 | ret ;zurück Zeit holen |
Michael N. schrieb: > Habe mir das noch mal angeguckt. Also wenn ich beim aufstecken nichts > falsch gemacht habe sollte das Passen. Also den Quarz habe ich auf Pin 1 > und 2 gepackt, Pin 3 ist + der Batterie, 4 GND von VCC und Batterie, 5 > sda, 6 scl, 7 offen und 8 VCC. Ja, ok. Auf dem Schaltplan sind die Pins in der falschen Reihenfolge. Das war etwas verwirrend. Ist GND überall gleich oder verwendest Du unterschiedliche Spannungsquellen? Ansonsten würde ich einfach die Busgeschwindigkeit herunter regeln (Config I2Cdelay). Sehr unwahrscheinlich können sowohl die RTC als auch der Quarz defekt sein. Du kannst auch in jede Sub nach jedem I2cstop "Print Err" einfügen, um zu sehen, ob es irgendwelche Fehler gibt (0=OK, 1= Fehler). @Timm Thaler BASCOM "kümmert" sich eigentlich um Punkt 2 und 3. Vielleicht Punkt 1 oder falsch angeschlossen oder defekt.
Am besten sagst du mal was du für einen Prozessor verwendest und in welchem Takt der läuft . k.
Ich verwenden den ATMega8 mit 16Mhz Quarz Tackt, wie auf dem Pollinboard verbaut. Den Quarz habe ich ganz nah mit auf die Platine gepackt wo die Pins für den Quarz sein sollen. Habe nämlich den RTC mit Knopfzelle und Quarz auf eine kleine Platine zusammengelötet und führe mit sehr kurzen Leitungen VCC, SDL, SCL und GND vom Board auf die Platine. Fand dies als beste Lösung, weil der Quarz so minimalistisch ist und so kann er nicht verlohren gehen. Habe mir den RTC mit der Artikel_Nr. 170823098864 bei Ebay erworben und an sich gab es mit diesem Händler nie Probleme. Als Spannungsquelle nutze ich den Vcc vom Board und als Batteriespannung habe ich einfach eine Knopfzelle (CR2032 mit 3V) genommen. Wenn eins von beidem defekt wäre, wäre ärgerlich. Kann das aber mit dem Print Err mal einbauen und gucken was passiert. Werde ich dann später mal machen. und das mit der Busgeschwindigkeit hab ich schon gemacht, wurde oben schon angesprochen und habe den Wert 100 erst eingesetzt, dann noch weiter reduziert auf den Wert 50. Ist es den auch Problemlos, dass der Pin SQW in der Luft hängt? Vielleicht könnte man ja auch die Softwarelösung des i2c Bus mal testen, nicht das es doch irgendwie dadran hängt? Man müsste mich nur aufklären wie das klappt. Ich hoffe es sind alle Fragen beantwortet, wenn nicht bitte nachfragen. Michael
Hi, ich habe dir nochmals eine bas angehängt, die einwandfrei funktioniert. Sie benutzt den Hardware TWI und enthält ein paar Kommentare. Versuch das nochmal. Stelle bitte auch sicher, dass dein uC wirklich auf 16Mhz läuft. Da 16Mhz ja auch ziemlich schnell ist könntest für die ersten Tests mal auf internen RC Oscillator mit 8Mhz umstellen und den Quellcode anpassen. Gruss Klaus p.s. die Hardware TWI funktioniert meiner Meinung nach eher unproblematischer als die Soft-Lösung
Ich habe das per http://www.engbedded.com/fusecalc auf den externen Quarz umgestellt, nach Anleitung aus dem Netz. Da ich jetzt zurück auf Intern stellen soll / könnte, wollte ich einmal zur Überprüfung die FB Lösung zeigen, bevor ich sie Umsetze. Ich benutze PonyProg2000 nur zur Info. LOW: SUT0 (Check) CKSEL3 (Check) CKSEL1 (Check) CKSEL0 (Check) High: SPIEN (Check) BOOTSZ1 (Check) BOOTSZ0 (Check) Mit Check mein ich, der Harken ist gesetzt. Als Option oben bei Futurs habe ich ausgewählt: Int. RC Osc 8MHz; Start-uup time: 6 CK + 64 ms;[CKSEL=0100 SUT =10] Oder ist da irgendwas falsch dran? Nicht das ich den µC nachher abschieße :-) daher frag ich mal zur Sicherheit lieber nach. Momentane Einstellungen sind: High: High: SPIEN (Check) BOOTSZ1 (Check) BOOTSZ0 (Check) Michael
Michael N. schrieb: > Den Quarz habe ich ganz nah mit auf die Platine gepackt wo die Pins für > den Quarz sein sollen. Habe nämlich den RTC mit Knopfzelle und Quarz auf > eine kleine Platine zusammengelötet und führe mit sehr kurzen Leitungen > VCC, SDL, SCL und GND vom Board auf die Platine. Fand dies als beste > Lösung, weil der Quarz so minimalistisch ist und so kann er nicht > verlohren gehen. Da ich es schon gelegentlich gelesen habe. Hast Du eine Lochraster- oder eine Streifenrasterplatine verwendet?
Streifenrasterplatine und die Löcher direkt nebebeinander genommen um dort keine großen kabelwege zu haben und zum anderen um für den RTC nicht eine irre große platine zu verwenden. man will ja sparen ;-) Oder is das ein Problem? Falls Frage kommt ob ich unterbrochen habe, ja habe ich. Also zwischen den Pins des RTC (hab den auf einen Sockel gesetzt) habe ich die Pins natürlich getrennt also zwischen 1 und 8 und so weiter meine ich. Michael
Du solltest die Busleitungen und die zum Quarz so kurz wie möglich halten (ggf. nur 1 bis 2 Löcher). Ansonsten überprüfe noch einmal genau, ob die Bahnen richtig durchbrochen sind. Auch eine hauchdünne Verbindung kann alles "ruinieren". Ein oder mehrere Fotos vom Aufbau der RTC wären auch nicht schlecht. Dabei bitte folgendes beachten: http://www.mikrocontroller.net/articles/Bildformate
Unterbrochen sind die Ganz sicher, mache ich immer bei Jedem mal, wenn ich unterbreche mit nem durchgangspiepser einmal piepsen bevor bauteile dazu kommen. Mache aber gleich mal fix Fotos. Also von dem Flachbandkabel, welches das AVR Board mit dem Laborbrett verbindet und einmal die verbindung vom RTC zum Laborbrett. Bilder kommen sofort. Aber sind den Fusebits richtig gesetzt das es damit keine Probs gibt? Michael PS: So hier das Bild. Da wo unten rechts die LEDs sind habe ich den I2c Bus drin. LEDs habe ich raus genommen. Hoffe man kann alles halbwegs erkennen. Bild lade ich hier rauf: http://freewareecke.de/2012-05-09-008.jpg
Angehängte Dateien:
-
Fehlermeldung.PNG
1,6 KB
Habe den Code getestet, also der hier gepostet wurde, nur leider haut der Compiler nen Fehler raus. Eigentlich sollte dieser Code ja funktionieren. Ich will aber nicht unterstellen, das es nicht so wäre. Michael
Hi Michael, das ist doch prima, du bekommst realistische Meldungen. Ein Mega8 Prozessor hat keinen Port A. (Den gibt es nicht) Denk doch mal drüber nach, ob man irgendwelche Beispiele einfach ohne Nachdenken übernehmen sollte. Du sagst , du hättest einen Mega 8 und postest diese Fehler über Port A. Denk doch bitte nochmal nach. Gruss klaus p.s. ... und vergiss mal für einen Moment die gut gemeinten Ratschläge über Quarze und kurze Leitungen. Das sagen alle , die noch nie einen TWI am Laufen hatten. .... und hättest du meinen Code verwandt, indem Port A niemals erwähnt wurde, hättest du auch kein Problem.
Sry dass ich das jetzt sage, aber genau den Code habe ich verwendet. (an Klaus De lisson) und genau bei dem Code gab es den oben genannten Fehlercode. Das wunderte mich nämlich. Weil wie gesagt kein Port A erwähnt wurde. Habe diesen auch noch ein zweites mal kopiert in Bascom AVR und Erfolg war der selbe, bzw der Misserfolg. Und ich denke bei Copy + Paste sollte man nichts falsch machen können. Michael
Klaus De lisson schrieb: > Das sagen alle , die noch nie einen > TWI am Laufen hatten. Bitte, Klaus! Man versucht hier zu helfen und wird von Dir indirekt mit haltlosen Behauptungen konfrontiert. Was soll das? Schlechten Tag gehabt? Dein Beispiel funktioniert genau so gut wie mein Beispiel oder das Beispiel aus der Hilfe. Wieviel Beispiele soll Michael den noch brennen? Es liegt nun mal zu 99% nicht am Code. Würde meinen, das solltest Du ebenfalls sehen. Ich bin hier jedenfalls raus.
PS. Dein Code lässt sich so nicht compilieren. Hätte man ja mal vorher überprüfen können.
Karl, wäre schade, wenn jetzt hier abbrichst. Dachte eigentlich immer viele Leute kommen gemeinsam zu einer Lösung. Jap er lässt sich nicht Compilieren und ich habe mehrfach drüber geguckt und leider irgendwie finde ich zumindest mit meinen noch beschrenkten Fähigkeiten keinen Fehler zumindest kann keinen zuordnen. Michael
Bevor hier weiter im Trüben gestochert wird: Hast Du ein Oszi, kannst Du Dir die Signale mal anschauen?
Ne hab ich leider nicht, gibt zwar Möglichkeiten ja eine Softwarelösung zu machen, nur soweit bin ich ersma noch nicht. Also per µC sich ein Oszi zu bauen und dann Signal grafisch am PC darstellen zu lassen. Habe bislang nur ein paar normale Multimeter hier. Michael
Karl schrieb: > Bitte, Klaus! Man versucht hier zu helfen und wird von Dir indirekt mit > haltlosen Behauptungen konfrontiert. Was soll das? Schlechten Tag > gehabt? Hallo Karl, nun nimm das doch nicht gleich in den falschen Hals. Ich wollte damit keinen angreifen. Sollte es falsch angekommen sein, entschuldige ich mich. Allerdings ist dein Code, den du am Datum: 08.05.2012 22:30 gepostet hattest nicht sonderlich hilfreich gewesen, da du sehr krumme Einträge darin hast: $crystal = 3686400 $baud = 19200 und diese für den Fragesteller nicht weiter kommentiert hattest @Autor: Michael N. (lwl2012) Nun habe ich mir das mit dem Port A nochmal angeschaut und muss sagen, ich war verwirrt. Das Problem verschwindet wenn du entgegen meiner Bemerkung nun doch die Portdefinitionen in den Quelltext einfügst: 'configure the scl and sda pins Config Sda = Portc.4 Config Scl = Portc.5 Interessanterweise geht es bei M644def.dat auch ohne. Das ist offenbar ein Tribut des letzten Bascom Updates. Seitdem die da nun auf "Teufel komm raus" den XMEGA mit einflechten wird das Bascom immer abscheulicher. zudem habe ich mir dein Bild vom Aufbau mal angesehen, welches ich wohl zuvor überlesen hatte. (http://freewareecke.de/2012-05-09-008.jpg) und muss sagen dass das so wohl nicht gehen wird. Es entspricht auch in keiner Weise deiner Aussage "Und Kabellänge sollte eigentlich noch nich das Problem sein. es sind nur 10 cm (wenn nich sogar weniger)" Leider habe ich 2ten Absatz deines Satzes überlesen . Da steht ja: "zzgl. das kurze Flachbandkabel was den Adapter für das Laborbrett mit dem AVR Board verbindet." In deinem Foto wird das ganze Desaster ja sichtbar. Evt. kannst du das ans Laufen bringen indem du 2 weitere Pullups einbaust. 2 Pullups am Atmega und 2 Pullups direkt am DS. Für die ersten Tests würde ich aber vorschlagen den DS mit kurzen Kabelstücken direkt auf die Pins des Mega zu löten. (Also kein Steckbrett und so) Wenn es dann geht, kannst du ja wieder die Leitungen verlängern. Gruss Klaus
Klaus De lisson schrieb: > Hallo Karl, > nun nimm das doch nicht gleich in den falschen Hals. Ich wollte damit > keinen > angreifen. Sollte es falsch angekommen sein, entschuldige ich mich. Ok, Klaus. Kein Problem. Hatte Gestern wohl selbst keinen so guten Tag, dass ich gleich so empfindlich darauf reagiert habe. > Allerdings ist dein Code, den du am Datum: 08.05.2012 22:30 gepostet > hattest > nicht sonderlich hilfreich gewesen, da du sehr krumme Einträge darin > hast: > $crystal = 3686400 > $baud = 19200 Ja, das stimmt. Da ich Michael jedoch schon an anderer Stelle mal geholfen hatte, wusste ich, dass er das meistern wird. Letztendlich sind wir nun alle zu der Überzeugung gelangt, dass es wohl an der Hardware / Verkabelung etc. liegen muss. Gruß, Karl
Karl schrieb: > Letztendlich sind wir nun alle zu der Überzeugung gelangt, dass es wohl > an der Hardware / Verkabelung etc. liegen muss. Ja! .. und schön, dass du jetzt nicht nachtragend bist. Ich gebe auch zu, das ich auch etwas hyperaktiv war. Gruss Klaus
Ich werde es dann versuchen direkt an den Controller zu bekommen, nur anlöten direkt dran ist eigentlich schlecht (Weils direkt auf dem Board steckt). Aber werde mir was überlegen. Vielleicht packe ich alles direkt aufs Steckbrett. Wäre nicht die Ideale Lösung, aber vielleicht ein kompromiss? Wollte gleich noch gucken nach einem Software Oszi, also ob ich das hin bekomme aus dem Buch zu holen. Habe hier eines Rumliegen (Basiskurs Bascom - AVR). Nur nicht alles ist verständlich gemacht. Also ich Programmiere den Controller und stecke diesen dann aufs Steckbrett mit minikleinen kabeln zwischen Controller und RTC. Als ausgabe werde ich einfach den LC-Bildschirm nehmen. Michael
Michael N. schrieb: > einem Software Oszi vergiss es .. es klappt nicht .. und es ist unnötig. Einfanch mal testweise direkt an die Pins des uC löten. Wenn es dann klappt hast du die halbe Miete. k.
Reichts notfalls auch, wenn ich Sockel für RTC und Controller auf eine Platine löte mit ganz kurzen Leitungen für den I2C? Und was würdet ihr als Pullup nehmen? 4,7k oder mehr oder weniger? Michael
Hi Michael, ich glaube du denkts zu kompliziert. Wenn du einfach deine vorhandene Platine mit dem RTC und der Batterie mal direkt an die Pins vom uC anklemmst sollte es klappen. Du darfst aber gern auch 10cm Kabel zwischen uC und RTC einsetzen. Es sind doch nur 4 Leitungen (+.-,SDA,SCL) Das kann doch so schwer nicht sein. Die Pullups sind zwischen 1k und 10k. Je niederohmiger desto stabiler das Signal und desto höher der Stromverbrauch. Mit deinen 2k liegst du schon im sicheren Bereich. Gruss k.
So, hier funktionierender Bascom-Code. Vorsicht, der DS1307 kann nur mit 100khz betrieben werden, mit 400khz Busspeed kommt der laut datenblatt nicht klar, dann kommt nur datenmüll raus! Habe mit dem Code grade eben eine meiner DS1307-Platinchen mit Zeit gefüttert.
1 | $regfile = "m8def.dat" |
2 | $crystal = 16000000 |
3 | $baud = 9600 |
4 | $lib "mcsbyte.lbx" ' for smaller code |
5 | $lib "ds1307clock.lib" ' lib |
6 | 'statt der ds1307clock.lib kann auch die ds1307clock_GER.lib verwendet werden. |
7 | 'dann ist das Datumsformat direkt in der deutschen Darstellung |
8 | |
9 | $lib "i2c_twi.lbx" ' Für Hardware TWI |
10 | |
11 | $framesize = 16 |
12 | $hwstack = 24 |
13 | $swstack = 16 |
14 | |
15 | |
16 | 'configure the scl and sda pins |
17 | Config Sda = Portc.4 |
18 | Config Scl = Portc.5 |
19 | |
20 | 'die Definition von SDA und SCL entfällt, da wir den Hardware TWI verwenden. |
21 | 'Allerdings muss der Uhrbaustein zwingend an die Hardware TWI Ports angeschlossen werden. |
22 | ' Sda = Portc.4 |
23 | ' Scl = Portc.5 |
24 | |
25 | Config Twi = 100000 ' Init TWBR und TWSR |
26 | 'Typical you need a speed of 400000Hz. Some devices will work on 100000Hz as well. |
27 | |
28 | |
29 | |
30 | ' TWI gleich einschalten, das macht Bascom ansonsten erst beim I2CStart ! |
31 | Twcr = &B00000100 ' nur TWEN setzen |
32 | |
33 | 'address of ds1307 |
34 | Const Ds1307w = &HD0 ' Addresses of Ds1307 clock |
35 | Const Ds1307r = &HD1 |
36 | |
37 | Config Clock = User ' this will dim the bytes automatic |
38 | 'dim other needed variables |
39 | Dim Weekday As Byte |
40 | |
41 | Print "DS1307" |
42 | Waitms 100 |
43 | ' assigning the time will call the SetTime routine |
44 | Time$ = "23:58:59" ' to watch the day changing value |
45 | Date$ = "11-13-02" ' 13 november 2002 |
46 | Do |
47 | Print "Date Time : " ; Date$ ; " " ; Time$ |
48 | Waitms 500 |
49 | Loop |
50 | |
51 | End |
52 | |
53 | 'called from ds1307clock.lib |
54 | Getdatetime: |
55 | I2cstart ' Generate start code |
56 | I2cwbyte Ds1307w ' send address |
57 | I2cwbyte 0 ' start address in 1307 |
58 | |
59 | I2cstart ' Generate start code |
60 | I2cwbyte Ds1307r ' send address |
61 | I2crbyte _sec , Ack |
62 | I2crbyte _min , Ack ' MINUTES |
63 | I2crbyte _hour , Ack ' Hours |
64 | I2crbyte Weekday , Ack ' Day of Week |
65 | I2crbyte _day , Ack ' Day of Month |
66 | I2crbyte _month , Ack ' Month of Year |
67 | I2crbyte _year , Nack ' Year |
68 | I2cstop |
69 | _sec = Makedec(_sec) : _min = Makedec(_min) : _hour = Makedec(_hour) |
70 | _day = Makedec(_day) : _month = Makedec(_month) : _year = Makedec(_year) |
71 | Return |
72 | |
73 | Setdate: |
74 | _day = Makebcd(_day) : _month = Makebcd(_month) : _year = Makebcd(_year) |
75 | I2cstart ' Generate start code |
76 | I2cwbyte Ds1307w ' send address |
77 | I2cwbyte 4 ' starting address in 1307 |
78 | I2cwbyte _day ' Send Data to SECONDS |
79 | I2cwbyte _month ' MINUTES |
80 | I2cwbyte _year ' Hours |
81 | I2cstop |
82 | Return |
83 | |
84 | Settime: |
85 | _sec = Makebcd(_sec) : _min = Makebcd(_min) : _hour = Makebcd(_hour) |
86 | I2cstart ' Generate start code |
87 | I2cwbyte Ds1307w ' send address |
88 | I2cwbyte 0 ' starting address in 1307 |
89 | I2cwbyte _sec ' Send Data to SECONDS |
90 | I2cwbyte _min ' MINUTES |
91 | I2cwbyte _hour ' Hours |
92 | I2cstop |
93 | Return |
Markus
Hallo, ist die Backupbatterie auch wirklich richtig gepolt und ist die Spannung der Batterie noch ausreichend ?
Sollte richtig sein. Kontrollier es aber zur sicherheit noch mal. Und auch ob sie noch gut ist teste ich eben. Aber denke ja ist eine gute Duracell Knopfzelle. Michael PS: Batterie geprüft und für gut befunden. Plarität passt auch. Aber außer wenn die Polarität falsch wäre sollte ja nicht schlimm sein, wenn Batterie leer ist. Soll ja nur zum Backup sein.
Hi, schau mal unter http://www.fakedomain.de/elektronik/messuhr/index.htm. Da hab ich ne Uhr mit ds1307 gebastelt und auch den BASCOM-Quelltext dazu veröffentlicht. Die Uhr läuft seit ihrem Bau ohne Probleme und ist auch nur auf Lochraster aufgebaut. Vielleicht hilft es ja. Bei mir waren die Bus-Widerstände mal ein Problem, aber mit 4,7k lauft es.
Hallo, vielleicht hilft dir auch mein Programm mit automatischer Sommerzeitumschaltung, läuft recht brav seit einigen Monaten im Echtbetrieb: Beitrag "Sommerzeitberechnung mit Bascom"
Danke für Zahlreiche Hilfen, hab eine Lösung im Netz gefunden, die Funktioniert. Hier der Code:
1 | $regfile = "m8def.dat" |
2 | $crystal = 16000000 |
3 | $baud = 9600 |
4 | |
5 | Config Sda = Portc.4 |
6 | Config Scl = Portc.5 |
7 | |
8 | Dim _weekday As Byte |
9 | Dim _day As Byte |
10 | Dim _month As Byte |
11 | Dim _year As Byte |
12 | Dim _sec As Byte |
13 | Dim _min As Byte |
14 | Dim _hour As Byte |
15 | |
16 | Dim Wt As String * 15 |
17 | |
18 | Dim Ds1307w As Byte |
19 | Dim Ds1307r As Byte |
20 | |
21 | Ds1307w = &B11010000 |
22 | Ds1307r = &B11010001 |
23 | |
24 | '_day = 24 |
25 | '_month = 5 |
26 | '_year = 12 |
27 | '_sec = 00 |
28 | '_min = 38 |
29 | '_hour = 15 |
30 | |
31 | Input "Wd.: " , _weekday |
32 | Input "Tag: " , _day |
33 | Input "Mon: " , _month |
34 | Input "Jah: " , _year |
35 | Input "Sec: " , _sec |
36 | Input "Min: " , _min |
37 | Input "Std: " , _hour |
38 | |
39 | |
40 | Rem Zeitsetzen |
41 | _sec = Makebcd(_sec) |
42 | _min = Makebcd(_min) |
43 | _hour = Makebcd(_hour) |
44 | I2cstart
|
45 | I2cwbyte Ds1307w |
46 | I2cwbyte 0 |
47 | I2cwbyte _sec |
48 | I2cwbyte _min |
49 | I2cwbyte _hour |
50 | I2cstop
|
51 | |
52 | Rem Datumsetzen |
53 | _day = Makebcd(_day) |
54 | _month = Makebcd(_month) |
55 | _year = Makebcd(_year) |
56 | I2cstart
|
57 | I2cwbyte Ds1307w |
58 | I2cwbyte 3 |
59 | I2cwbyte _weekday |
60 | I2cwbyte _day |
61 | I2cwbyte _month |
62 | I2cwbyte _year |
63 | I2cstop
|
64 | |
65 | |
66 | Do
|
67 | |
68 | Rem Datum und Zeit holen |
69 | I2cstart
|
70 | I2cwbyte Ds1307w |
71 | I2cwbyte 0 |
72 | |
73 | I2cstart
|
74 | I2cwbyte Ds1307r |
75 | I2crbyte _sec , Ack |
76 | I2crbyte _min , Ack |
77 | I2crbyte _hour , Ack |
78 | I2crbyte _weekday , Ack |
79 | I2crbyte _day , Ack |
80 | I2crbyte _month , Ack |
81 | I2crbyte _year , Nack |
82 | I2cstop
|
83 | |
84 | Select Case _weekday |
85 | Case 1 |
86 | Wt = "Montag" |
87 | Case 2 |
88 | Wt = "Dienstag" |
89 | Case 3 |
90 | Wt = "Mittwoch" |
91 | Case 4 |
92 | Wt = "Donnerstag" |
93 | Case 5 |
94 | Wt = "Freitag" |
95 | Case 6 |
96 | Wt = "Samtag" |
97 | Case 7 |
98 | Wt = "Sonntag" |
99 | |
100 | End Select |
101 | |
102 | Print Wt ; " /" ; Bcd(_day) ; "." ; Bcd(_month) ; "." ; Bcd(_year) |
103 | Print
|
104 | Print Bcd(_hour) ; ":" ; Bcd(_min) ; ":" ; Bcd(_sec) |
105 | Print "---------------------------------------" |
106 | |
107 | Waitms 1000 |
108 | |
109 | Loop
|
Michael
Michael N. schrieb: > Rem Datumsetzen Das ist ein Auszug aus dem von dir geposteten Quelltext. Ich bezweifle doch, das das so durchkompiliert und dann auch noch funktioniert. k.
Doch funktioniert erste Sahne. Wollte es eigentlich nur erwähnt haben, falls wer anders noch mal eine Codealternative sucht. Michael
Michael N. schrieb: > Wollte es eigentlich nur erwähnt haben, falls wer anders noch mal eine > Codealternative sucht. Hallo Michael, das finde ich auch gut, dass du deine Lösung zur verfügung stellst. Trotzdem bezweifle ich dass der Bascom Compiler Dinge wie: Rem Zeitsetzen _sec = Makebcd(_sec) _min = Makebcd(_min) und Rem Datum und Zeit holen I2cstart I2cwbyte Ds1307w ohne Fehlermeldung durchlaufen lässt. Insofern erzeugt deine Lösung nun für jeden, der es nachmachen will ein fehlerhaftes Abbild der Realtität. Falls dein Quelltext bei dir nun funktioniert, so hast du diesen hier fehlerhaft dargestellt. Deine Definitionen Dim _weekday As Byte Dim _day As Byte Dim _month As Byte Dim _year As Byte Dim _sec As Byte Dim _min As Byte Dim _hour As Byte sind interessant aber normalerweise unter Verwendung: Config Clock = User ' this will dim the bytes automatic werden all diese Teile automatisch dimensioniert. einzig dieser hier: 'dim other needed variables Dim Weekday As Byte müsste manuell gemacht werden. Andererseits hast du es geschafft, den "Config Clock = User " manuell nachzubilden und das ist auch gut. Gruss Klaus
Naja ob man bei Copy Past was falsch machen kann, weiß ich nicht. Also habs aus BascomAVR rauskopiert und hier eingefügt. Also Text ist 1 zu 1, zu dem welcher auf dem µC liegt. Und Kommentare in Bascom kann man entweder mit REM beginnen bzw '. Das Rem stammt noch aus QBasic zeiten. Den soweit ich weiß stammt Bascom von Basic ab. Nur die oben geposteten Codes funktionierten nicht, das weiß ich. Meiner Funktionierte. Den in den anderen Codes fehlte mir irgendwie das kontinuierliche Abrufen der Zeit. Aber egal. Es funktioniert. Ich möchte diesen RTC in ein Wanduhrprojekt einbauen. Muss mich nur wo möglich noch mit dem Funkempfänger auseinander setzen. Also um dadraus eine Funkuhr zu bauen. Alternativ soll ein Eingang abgefragt werden, ob er im Programmiermod oder im Laufmod ist. Also dass nicht bei jedem Stromausfall immer oben der Code durchläuft, wo man Uhr und Datum stellt. Aber das ist nicht mehr der große Aufwand. Eher das mit dem Funkempfänger wäre noch interessant, aber mal gucken. Michael
Ohhh Michael, michael ich muss mich entschuldigen. REM geht tatsächlich und ich dachte es würde es nicht. Nun habe ich schon seit 8 Jahren Bascom und bin Betriebsblind weil ich immer das "'" verwende. Verzeih also bitte. Klaus
Kein Problem. Sowas kann vorkommen. Vielleicht kannst mir nen bischen Hilfe gehen, wie das mit dem Funkempfänger geht? Habe den hier zuhaus: http://www.pollin.de/shop/dt/NTQ5OTgxOTk-/Bausaetze_Module/Module/DCF_Empfangsmodul_DCF1.html Hast mal mit sowas gearbeitet: http://www.pollin.de/shop/dt/OTI5OTgxOTk-/Bausaetze_Module/Module/Funkmodul_RFM12_Sende_Empfangsmodul.html ist sowas schwer an zu steuern? Also nur aus interesse mal gefragt. Michael
Michael N. schrieb: > Vielleicht kannst mir nen bischen Hilfe gehen, wie das mit dem > Funkempfänger geht? Hmmm, ich kann versuchen dir zu helfen aber ich lebe in Südfrankreich und bin daher nicht der Superkunde für DCF77, da ich das hier sehr schlecht empfange. Ich habe einen Empfänger für Radio Monaco gebaut, der mit 216khz als refeferenztakt ins Haus liefert. damit kann ich dann ggf. Frequenzzähler eichen. Du willst ja nur eine einfache Uhr bauen und ich kann dir gerne den Baustein DS3232 empfehlen, da dieser mit der Bascom Software für DS1307 compatibel ist. Das ergibt dann schon eine gute Genauigkeit, die kein DCF mehr erfordert. Ich könnte mir vorstellen, dass die Uhr dann ein serielles (RX/TX) Terminal hat, welches ich von Zeit u Zeit mit dem Computer verbinde und die aktuelle Atomzeit in den Wecker schiebe. Da benötigt man kein DCF mehr. wegen deiner Funkmodule kann ich dir sagen, dass die durchaus kompliziert sind. Es ist kein Hexenwerk aber diese Module verlangen vom Programmierer die implentierung eines Protocols. Das protocol und ggf. eine Fehlerkorrektur werden ja gebraucht wenn mehrere Module gleichzeitig funken. Ob es nun das Modul des Nachbarn oder eines aus deiner Gruppe ist. Du musst ja per Software herausfiltern, ob die Daten die ankommen für dich sind. Insofern kann ich dir gern als Anfänger die anderen Module á la Zigbee empfehlen, da diese das Protocol schon innen drinne haben. Ansonsten gibt es für die RFM Teile auch schon recht viele Softwarebeispiele. Gruss Klaus
Michael N. schrieb: > Nur die oben geposteten Codes funktionierten nicht, das weiß ich. Meiner > Funktionierte. Naja, die anderen Codes funktionieren schon. Warum sie auf Deinem System nicht funktionieren, sollte man sich eher fragen. Michael N. schrieb: > Den in den anderen Codes fehlte mir irgendwie das > kontinuierliche Abrufen der Zeit. Zeit und Datum werden kontinuierlich in Time$ und Date$ aktualisiert. Aber wenn Deine Lösung funktioniert..... Michael N. schrieb: > Habe den hier zuhaus: > > http://www.pollin.de/shop/dt/NTQ5OTgxOTk-/Bausaetz... Geht theoretisch ganz einfach (siehe BASCOM-Hilfe, Config Dcf77). Der Pollin-Empfänger will aber 3,3 V und ist recht störanfällig.
Vom Pollin-Empfänger gibt es zwei Versionen. Eine davon funktioniert problemlos auch mit 5 V. Oftmals kann man die Empfänger aus Uhren ausbauen, verwenden und damit billiger weg kommen. Alternativ zu einem DCF77 Empfänger kommt man auch mit einem GPS Empfangsmodul an die genaue Zeit zum syncronisieren seiner RTC. Ist zwar bissel teuerer als ein DCF77 Empfänger aber u.U. sicherer im Betrieb. Ich habe ein relativ billiges GPS Empfangsmodul das sogar unterm Dach in einem Raum die GPS Daten empfängt. Also ohne frei Sicht zum Sateliten.
Starkstromer schrieb: > Vom Pollin-Empfänger gibt es zwei Versionen. Eine davon funktioniert > problemlos auch mit 5 V. Und welche Version ist das? Bei Pollin gibt es momentan nur eine Version zu kaufen und da steht 3,5V max.
Gute Frage. Wenn du gut im suchen bist, wirst du die entsprechende Seite finden. Ich glaube sogar es gab hier bei Mikrocontroller diese Info mit Bildern des Unterschiedes oder es gab links dazu. Andererseits, wieso sollte diese derzeit käufliche Version nur mit 3,5 V max gehen? Nur weil Pollin das so angibt um bei irgendwelchen Fehlfunktionen aus dem Schneider zu sein und argumentieren zu können Sie haben da garantiert mehr als 3,5 V angelegt? So'n Käse kennt man doch aus Amerika, wo an jeder Waschmaschine ein Schild kleben muss, dass man keine Katze usw in die Waschmaschine tun darf. Normalerweise bräuchte man solche Aufkleber nicht. Sie dienen nur gewissen versicherungstechnischen Gründen. Mein Pollinmodul hängt seit langem an 5 V. Übrigens, wie bereits gesagt gibt es bei Disountern oft billige Uhren mit DCF77 Modul für unter 5 Euro. baut man den DCF77 Empfänger aus, läuft die Uhr noch und die Raumtemperatur wird weiter angezeigt.
Eine kleine Anfrage, zum Verständnis. Der RTC läuft mit geänderter Zeit weiter, sobald man die Zeit an diesen übergeben hat oder? Also wenn ich z.B. Manuell per Uart Terminal die Zeit übergebe. Und für meine Uhr bin ich am überlegen, eine Sommer / Winterzeit umschaltfunktion ein zu bauen. Also es wäre zwar eher die "schmutzige" Lösung, aber okay. Da ich nur die Uhrzeit anzeigen möchte wäre es aber nicht weiter schlimm. Als Lösung dachte ich, ein einfachen Schalter, der an einem Pin angeschlossen wird, dieser manipuliert eigentlich nur die Zeit, die vom RTC kommt um 1h. Also im allgemeinen läuft die eine Zeit (vermutlich Winterzeit werde ich wohl nehmen) normal weiter, nur wird dieser Schalter umgelegt, wird zu der Stunde vom RTC eine Stunde hinzugerechnet. Wie gesagt ist eher die "schmutzige" Lösung, aber wäre eine einfache Lösung, um nicht jedesmal den PC mit der Uhr zu verbinden. Dieses wäre aber nur dann die Lösung, wenn ich das mit dem Funkempfänger nicht hin bekommen sollte irgendwie. Und als RTC wollte ich schon den DS1307 nehmen, weil davon habe ich 3 Stück hier rum fliegen. Also von daher danke für Tip für Alternativen, aber erstmal bleib ich bei dem. Aber wenn die Identisch sind, könnte ich die im nachgang austauschen. Den der RTC wird gesockelt auf die Platine gebracht. Wollte dies mal als Diskusionsbeitrag hinterlassen. Michael
Für die SZ/WZ-Umschaltung brauchst Du das Datum in der Uhr, inkl. Wochentag und Jahr. Mit Jahr macht der 1307 auch korrekte Schaltjahre. Den Wochentag musst Du selbst setzen, der 1307 hat keinen WT-Kalender. Dann hast Du zwei Möglichkeiten: Wenn die Uhr läuft, prüfst Du mit dem AVR auf SZ/WZ-Regel. Die Regel ist nicht so schwierig zu implementieren, wie es auf den ersten Blick aussieht. a) Wenn SZ, rechnest Du eine Stunde zur Uhrzeit dazu. Musst aber dann ab 23:00 das Datum auch weiterrechnen, falls Du es brauchst. b) Wenn Zeitpunkt für Umschaltung, stellst Du die Uhr 1 Stunde vor / zurück. Dann setzt Du im Sommer ein Flag in einem freien Register der Uhr als SZ-Merker. Wird die Uhr eingeschalten, die SZ-Regel greift und der Merker ist gesetzt, alles in Ordnung. Wenn Merker nicht gesetzt, Uhr vorstellen, im Winter umgekehrt. Ist nicht so schwierig, und Du hast immer korrekte Zeit und korrektes Datum.
Hi, vielleicht hilft dir auch mein Programm mit automatischer Sommerzeitumschaltung, läuft recht brav seit einigen Monaten im Echtbetrieb, ich brauche weder einen Schalter noch ein eigenes Bit, noch eine Wochentagseingabe. Die Uhr läuft immer ganz normal weiter, vorm Anzeigen, wird der Offset von +/- 1 Stunde berechnet, den Wochentag gibts ja automatisch in Bascom mit dayofweek. Beitrag "Sommerzeitberechnung mit Bascom", Beitrag "Sommerzeitberechnung mit Bascom"
Thread beobachten
Seitenaufteilung abschalten
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.