Bitte nur eine RTC Lösung!

[DJLinux]

Hallo oog
Danke für die kurze aber gute Erklärung.

Grüsse Joshy

[drohne235]

Hier übrigens noch ein Tip von Uwe zum Thema RTC: DS1647

Wenn ich das richtig sehe, ist das ein NV-RAM mit integriertem RTC + Batterie. Passt als RAM von der Pinbelegung (soweit ich das sehen kann) genau statt unseren momentan verwendeten Typen - man kann also einfach einen der beiden RAM's mit dem Chip ersetzen. Die Daten der RTC werden einfach in den obersten Speicherzellen eingeblendet. Die einzigen Haken die ich sehe:

- Preis
- Zugriffszeit: Der Ram ist wesentlich langsamer (120ns); in Spin/TriOS egal in PASM lästig.
- Kompatibilität: Wenn der Chip wirklich so teuer ist, kommt auf der nächsten Platine eh ein I2C-Chip drauf - dann gibt es wieder Kuddelmuddel beim Code.
- Am besten würde mir ein RTC an Administra gefallen (ohne jetzt einen Glaubenskrieg auszulösen)

Aber ansonsten ein toller Chip muß ich sagen, vielleicht interessant auch für andere Projekte, da der RAM ja mitgepuffert! wird.

[drohne235]

Hab von Uwe einen Tip zum Thema RTC bekommen: DS1647

Das ist ein RAM (pinkompatibel zu unseren verwendeten RAM's!) mit integriertem RTC + Energiequelle. Der Ram wird übrigens mitgepuffert. Die Timerwerte werden einfach in den obersten Speicherzellen eingeblendet - genial. Allerdings hab ich zwei Haken gefunden:

1. Preis - das Ding ist ja sündhaft teuer!
2. Zugriffszeit - 120ns sind in Spin/TriOS egal, in Pasm extra NOP's oder Verschachtlungen

Aber eventuell ist der Chip für andere Projekte eine sinnvolle Sache.

[laserjones]

Mal ein ganz anderer Gedanke: Warum nicht einen ordinären DCF77-Empfänger (z. B. bei Reichelt für 13,80 Euro) an einen Pin hängen und das Signal von TriOS auswerten lassen? OK, das widerspricht der weiter oben genannten Forderung nach zeitquellenunabhängiger OS-Funktion, andererseits wäre es super-simpel und würde so gut wie keine Rechenzeit kosten, da nur wenige Male pro Sekunde der Pin abgefragt werden müsste (der Code hat nur 1 bit pro Sekunde).

Irgendwie widerstreben mir sogenannte RTC-Chips, die ihre "Echtzeit" selber machen müssen, statt sich eine echte Echtzeit zu besorgen. Und da der HIVE nicht zwingend immer am Internet oder im LAN hängt, bleibt dann eigentlich nur DCF77.

Zugegebenermaßen wäre es ein gewisser Nachteil, dass die Uhrzeit dann frühestens eine Minute nach Abschluss des Bootens zur Verfügung steht. Insofern wäre ein Empfänger mit integrierter, batteriegepufferter Uhr wohl doch die bessere Lösung. Und dann kann die OS-Funktion auch wieder zeitquellenunabhängig sein.

[TuxFan]

Moin moin!

@ drohne235
Wenn ich das richtig sehe, benötigt DS1647 eine 5V-Spannungsversorgung.

@Laserjones
Ich befürchte, daß ein DCF77-Empfänger ein ständig laufendes Uhrenprogramm benötigt.
Ich hatte mal derbe Empfangsprobleme mit einer Uhr mit DCF77-Empfänger. Das hängt wohl zum großenTeil von der Güte des Empfängers ab.

Ich persönlich sehe eine normale RTC als systemerforderlich an und wäre mit deren Genauigkeit allemal zufrieden.
Wenn man es genauer haben muß, stehen PTB etc. im Internet zu Verfügung oder halt auch die Synchronisation mit einem DCF77-Empfänger. Das sehe ich aber dann als einmaligen (täglichen) Vorgang an, zu dessen Zweck ein entsprechender Treiber geladen und dann wieder aus dem Arbeitsspeicher entfernt wird.

Mein derzeitiger Favorit für eine RTC : DS1337 (3,3V)
Gibt es als DIP8 (Reichelt, CSD) und Quarze 6pF (Reichelt) als SMD (Chip und Quarz, CSD)
Ausführung am Hive: Huckepack-Platine am EEProm-Steckplatz des Administra.
EEProm, RTC, Quarz werden als SMD-Bauteil verwendet, wegen Platzmangel unterhalb einer eventuell erforderlichen Erweiterungsplatine im 1/2-Euro-Format und Erzielung möglichst kurzer Leitungen.

Gruß
Günter

[drohne235]

Wenn ich das richtig sehe, benötigt DS1647 eine 5V-Spannungsversorgung.

Die RAM's im Hive laufen mit 5V, müßte also gehen. Ich hab aber die Pinbelegung und das Datenblatt nur überflogen, also keine Garantie. Aber ich glaube preislich ist der Chip keine Option.

Warum bevorzugst Du den DS1337, mal abgesehen von dem geringen Preisunterschied?

[TuxFan]

....Die RAM's im Hive laufen mit 5V, müßte also gehen. Ich hab aber die Pinbelegung und das Datenblatt nur überflogen, also keine Garantie. Aber ich glaube preislich ist der Chip keine Option.....

das ist mir jetzt peinlich, hab nicht im Schaltplan nachgeschaut und dachte das RAM läuft mit 3,3V.

....Warum bevorzugst Du den DS1337, mal abgesehen von dem geringen Preisunterschied?

Meine derzeitigen Beweggründe :
1. Bei meinem Vorhaben mit der Huckepackplatine im Hive wollte ich keine 5V-Leitung (für DS1307 erf.) zusätzlich übers Board ziehen. Worst-Case : Wenn der Deibel es will bricht das Versorgungskabel ab und 5V vagabundieren im Hive umher. Find ich nicht so gut.
2. Das Problem der Quarze (6pF Lastkapazität) hat sich erledigt, sind verfügbar.
3. Zwei Alarmfunktionen. Ob das besser ist als die Speicherung von ein paar Byte im DS1307... ich weiß es noch nicht. Eine Paßwortspeicherung o.ä. wo der DS1307 im Vorteil ist sehe ich im Moment noch nicht.

Noch offener Punkt :
Was ich noch nicht geprüft habe, ob der benötigte Befehlssatz (erstmal ohne Alarmfunktion) für den DS1307 und den DS1337 kompatibel sind.

Kurzes Konzept : Den DS1337 Chip gibt es in DIP8 und SO8 . D.h. ich kann erstmal auf einem Lochrasterboard experimentieren und dann die fertige Platine in SMD aufbauen. Als Pufferbatterie ist eine 12,5mm Lithium-Zelle vorgesehen. Das EEProm (64kB) kommt innerhalb des Adaptersteckers auch als SMD-Bauteil. Der RTC-Chip mit Quarz kommt auf die Unterseite außerhalb des Adaptersteckers die Batterie nach oben. Beide der 0,1µF Kondensatoren für den ENC28J60 sind schon als Keramik-Typen eingebaut, stehen also nicht im Weg. In dieser Konfiguration paßt das gerade soeben in den zur Verfügung stehenden Platz. D.h. nach erfolgreichen Experimenten : EEProm raus Adapterplatine rein fettich.
Das kann man theoretisch auch mit der zusätzlichen Leitung und dem DS1307 machen, mag ich aber ncht so recht.

Wenn man weiß was auf eine Erweiterungsplatine (Huckepack-Platine mit Bus-Stecker) kommen soll, könnte man den Adapterstecker darin integrieren und RTC und Administra EEProm auf diese Platine verlegen. Da ich aber im Moment noch keinen blassen Schimmer habe was ich auf einer Erweiterungsplatine mal benötige möchte ich mir erstmal alle Türen aufhalten. Eine weitere Randbedingung, manchmal auch Hemmnis, bei mir ist immer noch die Vorstellung die Gehäusegrundfläche nicht wesenlich größer als die Hive-Platine zu machen.

Ob das, wie ich es mir im Moment so vorstelle der optimale Weg ist, weiß ich nicht. Ich bin für weiter Diskussionen auf dem Gebiet erstmal offen. Für meine Webserverplatine kann ich beide RTC-Versionen einplanen, da ist noch alles offen.

Gruß
Günter

[drohne235]

Das mit der Spannung ist ein Argument. So würde man wirklich mit einer kleinen Platine ohne Kabel auskommen. Sach ma, wenn du eh bestellst und ätzt: Kannst du mir gleich eine Platine mitätzen und die SMD's mitbestellen - sofern du noch nicht bestellt hast?

[BorgKönig]

Das mit der Spannung ist ein Argument. So würde man wirklich mit einer kleinen Platine ohne Kabel auskommen. Sach ma, wenn du eh bestellst und ätzt: Kannst du mir gleich eine Platine mitätzen und die SMD's mitbestellen - sofern du noch nicht bestellt hast?

Und, wenn Du auf dieser Platine ein Rom- Switcher (TriOS mit/ ohne Uhr) Aufbaust, nehme ich auch eine...

[oog]

Bei einer RTC kann ich auf internen RAM verzichten. Es steht ja jede Menge nichtflüchtiger Speicher zur Verfügung, 3 mal EEPROM und die SD-Karte. Dort können alle Informationen dauerhaft gespeichert werden.
Eine RTC sollte einfach zu installieren sein und mit Stützbatterie weiterlaufen können, wenn der Hive ausgeschaltet ist.

- Am besten würde mir ein RTC an Administra gefallen (ohne jetzt einen Glaubenskrieg auszulösen)

Glücklicherweise gehören wir alle zum Kollektiv, wo Glaubenskriege aufgrund des gemeinsamen höheren Bewusstseins völlig ausgeschlossen sind.

Ich würde die RTC auch an Administra hängen. Selbst für den Fall, dass sich sonst niemand für die Zeit interessiert ... der FAT-Treiber braucht diese Information beim Anlegen von Dateien und kann sie sich schnell und einfach besorgen.

Mal ein ganz anderer Gedanke: Warum nicht einen ordinären DCF77-Empfänger (z. B. bei Reichelt für 13,80 Euro) an einen Pin hängen und das Signal von TriOS auswerten lassen?

Das finde ich einen ausgezeichneten Vorschlag. Insbesondere, da ich hier schon einige Empfänger aus alten Funkweckern herumliegen habe.

Allerdings würde ich dies nur als Option ansehen. Ein Ersatz für eine RTC ist dies nicht, da nicht überall der Empfang möglich ist (z.B. im Keller).

Ich möchte auch nicht permanent einen Task im Hintergrund laufen haben, der ausschließlich die DCF-Zeit empfängt und dabei Hub-RAM belegt.
Aber ich würde gerne per Batch bei jedem Systemstart einen Task starten, der die DCF-Zeit misst, danach die RTC stellt und sich dann selbst beendet.
Sollte ein Empfang innerhalb der ersten fünf Minuten nicht möglich sein, beendet sich der Task ebenfalls, ohne die RTC anzufassen.

Gruß, oog