Hallo, grundlegend suche ich keinen Code sondern würde gerne Ideen zur Umsetzung aufgreifen. Es geht darum eine Schaltuhr zu proggen, die 6 Schaltkanäle aufweist. Dafür nutze ich einen Atmega32L (3,3v) eine RTC DS1307 und Müsli drum herum. Jetzt überlege ich mir wie ich grundsätzlich vorgehe und entwickle mir nun meinen PAP. Im Prinzip ist die Aufgabe wie ein Wecker mit 6 Alarmzeiten. Grundsätzlich plagt mich die Frage wie ich die Daten der Alarmzeiten speichere. Also wenn die Alarmzeit nur Stunden und Minuten aufweist also keine Wochentage dann wären es jedesmal schon zwei Byte. Bei 6 Kanälen sind es schon 12 Byte. Eventuell könnten die im batteriegepuferten RAM der RTC abgelegt werden. Damit die Daten auch nach Stromausfall bestehen. Weiterhin wäre bei einem Wochentag ein zusätzliches Byte notwendig. Insgesamt also 18 Byte. Dann möchte ich mindestens eine Zeit vorgeben wie lange ein Kanal geschaltet bleibt, also dafür pro Kanal auch ein Byte 0-255sec. Wären jetzt schon 4x6 Byte also 24 Byte Konfigurationsdaten. Wenn ich später mal zwei Schaltzeiten pro Kanal möchte wären es ja schon 48 Byte. Naja... So jetzt die Frage wie ich grundsätzlich die Abfrage gestalte... Macht es Sinn immer die aktuelle Uhrzeit/Datum aus der RTC zu lesen und mit den 6 Schaltzeiten zu vergleichen? Denn dann müsste ich ja wenn es Minutengenau sein sollte mindestens alle Sekunde einen Vergleich durchführen. Obwohl mir auch eine Genauigkeit von 10sec. reichen würde. Ob jetzt die Schaltuhr um 09:30:00 oder um 09:30:10 oder wegen der Abtastung (nichts anderes ist es ja... Timer läuft ja nicht Synchron zur RTC) irgendwelche Uhrzeiten 09:30:09 oder 09:30:11 aufweist ist mir egal. Wie kann man dem Problem am güsntigsten Begegnen? Für unterstützenden Ideen wäre ich dankbar. mfg
Hallo Wenn der RTC einen Interruptausgang hat, dann einfach den RTC auf die nächste Uhrzeit programmieren. Dann macht er einen Interrupt zum uC. Du schaltest deinen Ausgang und programmierst die nächste Zeit und legst dich schlafen. Gruß Joachim
Ich habe mal vor jahren eine Schaltuhr mit 16 kanälen und einen mega32 gebaut. Die Schaltzeite habe ich im EPROM gespeichert. Eine Echtzeituhr ist nicht notwendig, da der µC von sich aus geneue zeiten erzeugen kann. MfG Turbotoni
@XXX wie meinst du das das ich die RTC mit der nächsten Zeit programmiere? Also wie soll das funktionieren? Im Daetnblatt steht da nichts davon das der DS1307 da eine speicherbare Uhrzeit hat oder doch? Also in den RTC-Registern kann ich nichts dazu finden... Allerdings das mit dem Interrupt hört sich gut an... Schlafen legen brauche ich ja nicht gerade das die Schaltuhr von Haus aus ja am Stromnetz hängt, da sonst ja die Relais nicht versorgt werden. @TT Also ich wollte das eben mit der RTC machen um auch die DAten im RAM zu speichern... EEprom möchte ich so wenig wie nötig beschreiben, sind hauptsächlich Kalibrirungsdaten drin.
Hallo Vergiß das mit dem Interruptausgang. Ich habe bei einem Projekt einen DS1337, der hat so einen Interruptausgang. Habe mich da verlesen, du hast ja einen DS1307. Sorry und Gruß Joachim
Hallo, ja der DS1337 hat ja keine Battery... da sitzt ja der IntA... also kann ich den auch nicht 1 zu 1 austauschen... sonst wäre es ja schon genial gewesen. Wie hält der DS1337 eigentlich seine Daten bzw. wie wird das weiterlaufen der Uhr da gelöst?
Hallo, also ich würde jetzt tatsächlich alle Sekunde (Oder alle 20sec.) die RTC auslesen und mit den gespeicherten Uhrzeiten im Atmega (Alarme vergleichen). Eine ständige Sortierung nach nächster Alarmzeit halte ich für Überflüssig, da es ja nur 12 Alarmzeiten maximal sein können. Wobei man es in Tage Stunden und Minuten nacheinander abfragen kann und immer den nächsten rausnimmt. Dann müssten 6 Abfragen immer reichen. Der Aufwand in einer Abfrage dauert keinen Bruchteil einer Sekunde und die Sortierung würde nur dazu führen, dass nach jedem Alarm oder Setup ständig neu sortiert werden muss. Da in der Schaltuhr noch ein paar andere Feature drin verbaut werden, will wohl überlegt sein was alles in die 30K passen.
Hey,
also in 32Bit bekommt man ein ganzes Datum:
typedef struct
{
uint32_t day : 5,
month : 4,
year :13,
week : 3,
calweek : 6,
leapjear: 1;
}date_t;
zudem könnte man das EEPROM nutzen wie hier bereits erwähnt.
>>Also wenn die Alarmzeit nur Stunden und Minuten aufweist also
keine Wochentage dann wären es jedesmal schon zwei Byte.<<
für eine Zahl zwischen 0 und 23 ist ein Byte wohl etwas hoch gegriffen,
oder?
T.
Angehängte Dateien:
-
DSC02370.jpg
290 KB -
DSC02371.jpg
310 KB
Hallo Hier mal eine Schaltuhr mit 18 Ausgänge. Die Alarmzeiten werden bei mir im EEprom gespeichert. Für alle Ausgänge ist das unter 1KByte. Die Uhr wird mit einem DS1307 und Batterie realisiert. Dabei wird die Zeit jede Sekunde abgefragt, weil sie auch angezeigt wird. Auf den Bilder siehste wie ein Menue aussehen kann.
Turbo Toni schrieb: > Eine Echtzeituhr > ist nicht notwendig, da der µC von sich aus geneue zeiten erzeugen kann. ....wobei Genauigkeit ein dehnbarer Begriff ist. Elektrische Werte eines gängigen Quarzoszillators (XO 32) Frequenz 12,000000 MHz Frequenztoleranz ± 50 ppm Lastkapazität 15 pF Das entspricht einer Abweichung von ca. +- 130s/Monat. Es wäre also durchaus sinnvoll, das Ganze mit einem DCF 77-Modul zu takten.
@Thorsten S. Joo...Danke erstmal ... ich hätte eben die Zahlen direkt in BCD gespeichert. Daher wären die 1 und 10 er ja eben jeweils 4 Bit. Daher ein Byte für die Zahlen der Minuten usw... könnte ich mir aber auch umstricken. Wobei 32 Bit auch 4 Byte sind... aber ich brauche ja das Jahr nicht... wer schaltet schon einmal im Jahr!? @Peter K Ja mit 18 Ausgängen ist ja Toll,... allerdings ist die Schaltuhr bei mir nur ein kleiner Teil des Programms. Sonst wäre der Atmega32 ja auch gelangweilt. Weiterhin werden je nach Schaltzeit Schrittmotoren über I2c mit nem TMC222 angefahren. Zu jeder Schaltzeit gibts da wiederum einige Parameter für die Postitionen usw.. die Kalibrierugsdaten werfe ich schon ins Eeprom. Sowie vordefinierte Referenzpunkte der Stepper etc... da wirds eng. Meine Menüsteuerung läuft über ein GLCD mit 320x240Pixel in zwei Schriftarten wegen der Größe, die Schriftsätze liegen bei mir auch im Eeprom, zum Glück nur die Zeichen die ich brauche da bei 32x32 Pixel der Speicher Eng wird. Also daher die Idee Alarmzeiten im RAM der RTC zu sichern mit den Paramtern aus jeweils einem Byte, also insgesamt auch 4 Byte x 6 Kanäle x 2 Schaltzeiten = 48 Byte... 56 oder so sind da in der RTC frei.
noname schrieb: > Das entspricht einer Abweichung von ca. +- 130s/Monat. > Es wäre also durchaus sinnvoll, das Ganze mit einem DCF 77-Modul zu > takten. Man kann den µC auch kalibrieren. Einfach mal einen Tag laufen lassen und die Zeit messen. Danach die exakte Quarzfrequenz ausrechnen.
Samuel K. schrieb: > Man kann den µC auch kalibrieren. Einfach mal einen Tag laufen lassen > und die Zeit messen. Danach die exakte Quarzfrequenz ausrechnen. Eine Kalibrierung wird natürlich vorausgesetzt. Die genannte Methode ist zwar etwas umständlich, funktioniert aber durchaus. In der Praxis wird man aber eher mit einem präzisen Frequenzzähler arbeiten. Der Toleranzbereich der Frequenz von +-50ppm bezieht sich jedoch nicht auf den Auslieferungszustand des Quarzoszillators. Er ist hauptsächlich bedingt durch die Temperaturabhängigkeit des Schwingquarzes. Andere Faktoren spielen eine untergeordnete Rolle, wie etwa die Alterung des Quarzes oder auch Temperaturabhängigkeit von Bauelementen (Kondensatoren).
Der DS1307 besitzt einen Ausgang, an dem er 1Hz ausgeben kann. So kannst Du in einem IRQ jede Sekunde alle 6 (12, ...) Schaltzeiten vergleichen. Gruß Jobst
Hallo, @Jobst Ja so dachte ich mir das. Da der Ausgang ja mit 1 Hz arbeitet läuft es auf eine Sekunde heraus. Da aber ja immer die Stepper bei einer gesetzten Schaltzeit bedient werden, würde da immer ein Interrupt dazwischen funken, also unterbinde ich die globalen Interrupt während einer Abfrage nach den Schaltzeiten mit der aktuellen Uhrzeit. Muss ich ja ohnehin... Überlege mir nur ob es da nicht sinnvoll wäre eine feste Größe vorzugeben an der Schaltzeiten eingestellt werden können, z.B. alle 5 Minuten also 09:30 und dann 09:35 und dann 09:40 etc... Denn die Stepper benötigen eventuell länger als eine Minute im Extremfall. Wenn dann eine Schaltzeit 09:30 und die zweite 09:31 wäre und der Interrupt in der Zeit deaktiviert wäre.. diese zweite Schaltzeit einfach ausfällt. Logisch das man da nicht sinniger Weise solche Zeiten einstellt. Allerdings würde ich gerne alle Eventuallitäten ausmerzen... Also Schaltzeiten immer in 5 min Schritten auswählbar. Wäre das wohl sinnig?
Hallo! Aus langer Erfahrung -auch mit Schaltuhren- hier noch der Hinweis: nicht nur vergleichen ob die Einschaltzeit oder die Ausschaltzeit übereinstimmen, sondern auch, ob man sich gerade dazwischen befindet. Bei Stromausfall und -wiederkehr oder Watchdogreset kann das wichtig sein (hängt von der Anwendung ab). Also, wenn Du Schaltzeiten und Dauer speicherst, immer auch "rückwärts" rechnen, ob zu der voreingestellten Dauer die gespeicherte Einschaltzeit noch nicht zu lange zurück liegt. Diese ganze Betrachtung hängt natürlich vom Zweck der Schaltuhr ab und ob ein Stromausfall mit den verpassten Schaltpunkten gravierende Probleme bringen kann.
Hi, ich würde die Daten in diesem Format
1 | typedef struct |
2 | {
|
3 | uint32_t day : 5, // if (day == 0) |
4 | month : 4, // use month as week |
5 | year : 7, // if (day == 0) & (month == 0) |
6 | hour : 5, // switch daily |
7 | minute : 6, |
8 | output : 4, |
9 | on_of : 1 |
10 | } date_t; |
im EEPROM ablegen. - Speicherbedarf: Vier Byte pro Schaltung. - Zeitliche Auflösung: 1 Minute. - Kann bei Bedarf für Datumsgenaue (== einmalige) Schaltung, wöchentliche und tägliche Schaltung verwendet werden. Ob man auch eine Rückrechnung der Schaltzustände in die Vergangenheit durchführen sollte, wage ich zu bezweifeln. Dann macht es schon mehr Sinn, den akutellen Schaltzustand und den Zeiger auf den letzten abgearbeiteten Eintrag per Wear-Leveling im EEPROM mit abzulegen. Carsten
Hallo! @carsten Wille Ich sagte ja, es hängt von der Anwendung ab. Ein Beispiel: jeden Morgen um 8:00 für 120 Sekunden die Futtermaschine im Terrarium betreiben. Wenn um 7:59 das Netz ausfällt und erst um 8:01 das System wieder startet, bekommen die Tiere Hunger. Jetzt könnte man 1. die restlichen 60s noch füttern, 2. die volle Schaltzeit von 120s "nachlaufen" lassen, 3. bei Wiederkehr erst um 8:05 für 120s "verspätet" füttern. Es sollte auch keine Kritik am Konzept sein, sondern Anregung zum Nachdenken über die Möglichkeiten von selbst programmierten Schaltuhren.
Hallo! Also ich sehe keine Anwendung für den Uhrenbaustein, da viele kleine und kleinste CPUs über eine interne RTC verfügen, die extern nur noch einen 32kHz Quarz benötigen. Da viele I2C Clocks auf ebenfalls einem solchen Quarz basieren oder ihn extern benötigen, ist keine höhere Genauigkeit und Temperaturstabilität zu erwarten. Möchte man den Uhrenteil per Goldcap oder Akku puffern, und sich nebenbei noch Schaltzustände merken, dann muss man entweder auf einen RTC mit BatteryBackup RAM setzen, oder gleich die CPU puffern. Letzteres gibt einem aber mehr Komfort, da man bei bei PowerOn nicht entscheiden muss, in welchem Zustand das System gerade ist, bzw. vor dem PowerOff war. Man macht einfach weiter. Natürlich muss man sich ein wenig mehr Gedanken machen, wie und wann man die CPU schlafen schickt, damit ein Goldcap auch mal ein paar Tage überbrücken kann. Das ist aber bei den genannten Zielen des Projektes sehr leicht machbar. Die RTC gestaltet sich dann auch recht einfach, man zählt einfach die Sekunden oder Millisekunden oder was einem passt und im Teiler der RTC einstellbar ist, hoch. Das ganze vielleicht einfach ab 1.1.2000 00:00:00. Denn wann benötigt man eine echte Uhrzeit? Nur zum Anzeigen und einstellen. Also schreibt man sich eine Funktion zum Decodieren und eine zum Codieren in den 32bit Zähler. (Bei Sekunden sollte das ausreichen 2^32/60/60/24/365=~136 Jahre) Damit können die ganzen Vergleiche, die mit den Schaltzeiten zusammen hängen einfach als Vergleiche zwischen zwei uint32_t erfolgen als eine verkettung von h,m,s... Vergleichen. Bei erreichen einer zyklischen Schaltzeit, wird einfach diese um ihren Zyklus in die Zukunft addiert. So braucht man einfach nur einzelne Eventes auf if(jetzt > event) ausführen(); Danach event += Zyklus_event. Das geht schnell und die CPU kann gleich wieder schlafen gehen und überlegt so mit einem kleinen Goldcap Wochen oder Monate ohne an der Steckdose zu klemmen. Wenn eine Längensteuerung gewünscht wird, muss man nur die Einschaltzeit in uint32_t umrechnen und die Dauer dazu addieren um die Ausschaltzeit zu erhalten. Aus dem Bauch heraus würde ich behaupten, dass das ein kleiner AVR sogar dann schafft, wenn die 32kHz auch für die CPU selbst verwendet werden, statt der internen 8MHz. Auf alle Fälle reichen 1MHz (interne 8MHz bei aktiviertem CLKDIV8). Beim Hardware Layout muss man aber darauf achten, dass die Zweige für eventuelle Treiber von Relais oder ähnlichem sauber vom gepufferten Teil der CPU getrennt sind. Sonst saugen einem die Leckströme den Goldcap leer. Alternativ kann man auch die Netzteilversorgung auf einen Interrupt Pin legen und im Moment des Stromausfalls schnell noch ein paar GPIOs passend einstellen. Dann merkt man sich diesen Zustand oder fragt beim Aufwachen durch die RTC den Pin ab und spart noch einmal GoldCap Energie, in dem man ohne Netzteil die ganze Alarmberechnung auf lediglich das Nachführen der Zeit begrenzt. Ist ein nettes Projekt und z.B. als Fischteich Steuerung bestimmt sehr gut zu gebrauchen. Pumpe, Beleuchtung, Futter... Coole Idee, ich mach vielleicht mit :) Gruß, Ulrich
Da gab es eine zeitliche Überschneidung mit Route_66 :) Bei meinem Konzept, hat man stets alle Variablen im RAM aktuell zur Verfügung. Es ist also bei einer Ein-Zeit+Dauer Schaltung möglich, die Ein-Zeit um die korrekte Zyklus-Zeit zu verschieben, aber die Dauer auf basis der Jetzt-Zeit ablaufen zu lassen ohne neue Berechungen anstellen zu müssen. Ein EEPROM ist dafür nicht nötig. Für eine Aquariums-/Teichsteuerung wäre es aber vielleicht sinnvoll ein Feature einzubauen, dass bei einem Netzausfall etwas 'intelligenter' entscheided, welcher der Vorgänge nachzuholen ist und welcher nicht. Die Pumpe, die immer von 7:00 bis 22:00 laufen soll, würde ja per ein-zeit und aus-zeit gesteuert. fällt das netz aus und kommt wieder, dann ist dabei leicht zu entscheiden, was jetzt zu tun ist. Aber es ist fraglich, ob man ein verpasstes Füttern von gestern Abend 10min vor der morgentlichen Fütterung noch nachholen möchte. Hier wäre zumindest eine einfache Entscheidung sinnvoll, ob die eingestellte Zykluszeit bereits zur Hälfte abgelaufen ist. Ist weniger Zeit vergangen, dann noch füttern, wenn mehr, dann müssen die Fischels eben warten. Da manche Fische kein Sattgefühl kennen ist ein schlanker Fisch immer noch besser als ein geplatzter Fisch. Ulrich
Ulrich P. schrieb: > Ein EEPROM ist dafür nicht nötig. Nun, die AVRs haben doch heute alle irgendein EEPROM on-chip dabei. Warum es also nicht nutzen? Es erlaubt der Uhr auch, die Schaltzeiten bei längerem Nichtgebrauch zu behalten. Ich muß zugeben, an Anwendungen, die eine bestimmte Einschaltdauer erfordern, an die habe ich nicht gedacht. Aber dann bohrt man den Datensatz um eine 8-11 Bit Einschaltdauer auf. Carsten
Hallo, danke für die zahlreichen Antworten. Eine Entscheidungsfindung, eine Aktion in der Vergangenheit nach einen Stromausfall erneut auszuführen halte ich für den Anwendungsfall unterschiedlich. Dies sollte von der Priorität abhängen. Abgesehen würde ich nie Aquarium (Meerwasser) oder Terrarien unbeaufsichtig länger laufen lassen (Eigene Erfahrungen!). Wenn an einem Tag mal die Fütterung ausfällt ist das nicht wirklich schlimm eher natürlich, allerdigs gibts andere Systeme die schlimmere Wirkungen haben können. Daher wäre eine kleine USV hier sinnvoller. Aber Egal...Ansichtssache! Ich denke der Aufwand mit der gepufferten CPU ist eine gute Idee. Allerdings habe ich ja ein Grafik-Display dran und mir gehts nicht um Stromsparen sondern um Datenerhalt bei Stromausfall. Respektive ist die CPU allein schon mit den Datenaufbereitung für das Display immer beschäftigt. Da kommt nur Eeprom und gepufferter RAM in Frage. Da bei mir wie erwähnt schon die Kalibrierungsdaten und Pre-Positionen der Stepper im Eeprom abgelegt sind, wirds da eng. Die I2C-Routine ist in ASM eingebunden und ist auf 100KHz (Empirisch mit Oscar gemessen) eingestellt. Nur am Rande: Oftmals habe ich von Problemen bei dem Umgang mit dem Auslesen der RTC DS 1307 gehört. Diese hatte ich auch anfangs. Man sollte immer das Datenblatt lesen. Wenn dort am Ende eines Lesevorgangs ein NAK verlangt wird, dann sollte man dieses auch beachten. Ansonsten steht die RTC nach jedem Lesevorgang und wartet... Viele behalfen sich dadurch das immer die Sekudnen zurückgeschrieben wurden... was ein völligster Quatsch war. Also als Info falls jemand das gleiche programmiert hat. Zum Thema: Um Zeit zu sparen bzw. Rechenzeit zu gewinnen werde ich den 1Hz Ausgang als Interupt nutzen und einen Zähler hochzählen lassen. Alle 20sek würde der Overflow einen weiteren INT auslösen der dann die aktuelle Zeit einliest. Oder besser noch die Schaltzeiten in 5min Abständen dann könnte ich alle 60sek abfragen das reicht doch auch. Die Uhrzeit und der nächste Schaltvorgang bzw. Aktion der Stepper wird immer im Display angezeigt.
Wobei die angezeigte Zeit dann ja nur alle 5 Minuten aktuallisiert wird.. Hmmm... Das würde ungewohnt aussehen auf dem Display. Also ich glaube ich bleibe bei der 20Sek. Das wäre dann 3 mal so schnell wie die Abtastfrequenz und stimmt dann mit dem Abtasttheorem (>2) überein. Sollte also keine Minuten verschlucken und Schaltzeiten auch nicht.
Hi! Also das Aquarium war jetzt eine Sache, die hier aufgekommen ist. Ich habe auch keine Ahnung was ein PAP ist und warum der Stepper benötigt. Ich sehe auch nicht, warum eine CPU dauernd mit der LCD Aufbereitung beschäftigt sein sollte und man keinen sauberen Refresh eines LCDs im Sekundenrhythmus hin bekommen sollte und das vollkommen ohne Assembler. Naja, was ich auch nur sehr selten gesehen habe, ist eine korrekte Implementation von I2C. Weder in Hardware, noch in Software scheint es Herstellern möglich zu sein, I2C ganz einfach und nach der Spec zu implementieren. Abgesehen von NXP haben bislang nur ST und Zilog wirklich sehr gute I2C Bausteine oder BusI/F in ihren CPUs untergebracht. Schlusslicht sind fast alle Chips von Microchip und sehr unrühmlich ist auch der At91SAM7S. Auch die älteren Libraries von TI für ihre Consumer DSPs sind gruselig. Damit muss man sich halt abfinden. Da das Projekt als Schaltuhr avisiert wurde, könnte man es ja auch als Schaltuhr weiter laufen lassen, wenn es deinem PAP nicht komplett widerspricht? Zu Deinem Datenerhalt: Wenn der Netzteil Pin erkennt, dass nun Akku/GoldCap angesagt ist, dann kann er ja zu aller erst das LCD komplett in PowerDown schalten, bzw. den Refresh der Daten auf ein Minimum beschränken. Das könnte man auch in Stufen machen, ganz wie Du willst. Je länger das System aus eigener Kraft laufen muss, desto mehr reduziert es seine Funktionen und sorgt dafür, dass wenigstens die Setup- und Laufzeit-Daten erhalten bleiben. Wenn Du bereits Daten im EEPROM zyklisch ablegst, die Du erhalten willst, die aber nix mit dem Schaltuhr Prozess zu tun haben, dann überlegen dort auch noch mal, welche der Daten statisch gespeichert werden müssen und welche eigentlich einfach zu rekonstruieren wären, bzw. welche durch Pufferung des RAM ohnehin erhalten bleiben. Vielleicht bleibt dann genug EEPROM übrig, um 1) Nur statische Setup-Daten im EEPROM zu haben 2) Das System möglichst kurz aus dem Sleep erwachen zu lassen, wenn es auf Akku/GoldCap läuft. Wenn man den einen Teil optimiert nützt es nix, wenn man den anderen teil vergisst :) Gruß, Ulrich
Hallo, also ein PAP ist ein Programablaufplan. Der i2C ist sauber implementiert in meiner Applikation. Ich wollte nur in meinem Post darauf hinweisen, dass dies oft nicht der Fall ist. Mein Display wird doch gar nicht ständig refresht..?? Wo steht das? Was hat das GLCD mit dem Assembler zu tun? Ich wollte nur ausrücken , das die CPU ja ohnehin das Display refresht. Natürlich nicht immer.. würde ja sonst auch unsinnig sein. Im EEprom sind keine zyklischen Daten! Wo habe ich das geshrieben? Es sind einmlaig festglegete Kalibrierungsdaten der Stepper-Motoren und deren Positionen. Die verändern sich im Normalfall niemals. Müssen aber einmal festgelegt werden. Die Stepper benötige ich, um diese anzusteuern. Es geht ja im Prinzip, um das Prinzip Schaltuhr. Nur das nicht ein einfacher Schaltkontakt gesetzt wird, sondern um komplexe Abläufe zeitlich Ablaufen zu lassen. Dabei soll die Art des Ablaufs und die Zeit individuell speicherbar sein. Daher hatte ich den SRAM der RTC im Auge. Da es kein LCD sondern ein GLCD ist, verbraucht es mehr Energie. Da auch eine einfache Schaltuhr immer am Netz hängt, erübrigt sich der Gedankengang einer Energiesparmassnahme. Das Diplay geht in den Sleep-Mode wenn es für eine gewisse Zeit X keine Touchfeldberührung gab.
Tja, entschuldige, das ich Dich das so missverstanden habe... Natürlich stand das alles so nicht in Deiner Aufgabenstellung, aber es stand auch nichts gegenteiliges darin. Und wenn man nur im Prinzip eine Schaltuhr braucht, aber 'im Prinzip' nicht weiter aufschlüsselt, dann ... ... lassen wir das. Ich habe Dir nicht unterstellt, dass Du I2C nicht sauber implementiert hast, ich habe nur auf die Gefahren hingewiesen, wenn man zugekaufte I2C Bausteine einsetzen will und sich dann wundert, warum es nicht geht. Ich wollte Dich also lediglich vor den Problemen der Anderen warnen, die sie Dir bereiten können, gerade wenn Du I2C richtig implementiert hast und Dich dann wunderst. Das mit dem LCD lassen wir mal, ich habe vermutlich ein Problem mit der Grammatik. Das mit den Stepper Werten im EEPROM war ebenfalls ein Missverständnis, weil sich deine Fragestellung so anhörte, als wäre es eng im EEPROM. Naja, wenn Du meine Schaltuhr-Idee gelesen hast, die sich nun als OT heraus stellt, dann hast Du trotzdem erfahren, dass Du eigentlich gar kein EEPROM brauchst, wenn Du nur dafür sorgst, dass der uC immer genug Strom bekommt. Auf die paar uA Unterschied swischen einem in Standby geschalteten GLCD oder LCD kommt es dabei wirklich nicht an. ... hmmm, habe jetzt noch mal ganzt aufmerksam Deine Fragestellung durchgelesen. Da wird doch im Prinzip eine Schaltuhr mit 6 Schaltzeiten inkl. Wochentag Berücksichtigung gesucht... In der ursprünglichen Fragestellung ist auch keine Rede von Steppern. Warum fragst Du denn nicht einfach: Ich habe x Bytes EEPROM, muss bereits n Bytes Konfiguration für was anderes darin speichern und möchte jetzt noch 6 Schaltzeiten mit hh:mm,dd unterbringen, wie macht man das am geschicktesten? Dann waren alle Antworten schon dabei, mit codeschnipsel von Thomas. Und warum sollte man, wenn man nur eine Diode, einen Goldcap und einen Widerstand braucht, nicht auch eine Notversorgung unterbringen, oder hast Du bei Dir alle Sicherungen gebrückt? Wird bei Dir nie gestaubsaugt, oder braucht Dein Staubsauger keinen Strom aus der Steckdose? Oder stellst Du nach einem kleinen Stromausfall, warum auch immer, alle Uhren im Haus? Oder ist das ganze eine Aufgabe vom Chef und es muss was kommerzielles oder Industrielles dabei heraus kommen? Mann Leute, fragt doch exakt, was ihr wissen wollt, dann kann man Euch auch präzise helfen. Immer dieses 'ich habe Angst was zu verraten'. Das hilft hier keinem und schon garnicht denen, die Hilfe suchen. Wir wissen, dass hier ebenso viele Entwickler Fragen stellen, die bei einer beruflichen Sache fest stecken, wie Bastler, die beim Hobby fest stecken. Ist doch Ok, wo ist das Problem? Gruß, Ulrich
@Ullrich ... hmmm, habe jetzt noch mal ganzt aufmerksam Deine Fragestellung durchgelesen. Da wird doch im Prinzip eine Schaltuhr mit 6 Schaltzeiten inkl. Wochentag Berücksichtigung gesucht... Falsch! Ich suchte nach diesem "Hier" im Thread ganz oben: ************************************************************* So jetzt die Frage wie ich grundsätzlich die Abfrage gestalte... Macht es Sinn immer die aktuelle Uhrzeit/Datum aus der RTC zu lesen und mit den 6 Schaltzeiten zu vergleichen? Denn dann müsste ich ja wenn es Minutengenau sein sollte mindestens alle Sekunde einen Vergleich durchführen. Obwohl mir auch eine Genauigkeit von 10sec. reichen würde. Ob jetzt die Schaltuhr um 09:30:00 oder um 09:30:10 oder wegen der Abtastung (nichts anderes ist es ja... Timer läuft ja nicht Synchron zur RTC) irgendwelche Uhrzeiten 09:30:09 oder 09:30:11 aufweist ist mir egal. Wie kann man dem Problem am güsntigsten Begegnen? Für unterstützenden Ideen wäre ich dankbar. ************************************************************* Dabei sind auch ein paar gute Ideen rausgekommen! Und ob Stepper dran sind oder nicht.. ist völligst unwichtig. Oder soll ich auch noch jede LED aufzählen? Und jeden Port wo was dranhängt? Also grundlegend sollte man von der komplexen Aufgabe abstrahieren können. Das zerlegen in einfache Einzelaufgaben. Das lernt man im ersten Semester schon... kapiert wohl keiner! Davon erstellt man einen PAP und entwickelt das gesamte Konzept. Die Fragestellung war nicht nach einer fertigen Schaltuhr, sondern nach einer Vorgehensweise der Vergleiche der Sollzeit mit der Istzeit. Also der ideale Weg dafür.
Also war mein Basis-Gedanke, aus dem später die komplette Uhr entstand garnicht so verkehrt. Die (versteckten) Antworten waren: Der AVR kann, direkt mit dem zusätzlichen Quarz versehen, dass auch eine I2C-RTC benötigt, selbst die Uhrzeit generieren. Du kannst die Uhrzeit per Interrupt aus diesem RTC Timer aktualisieren, sie wird also ohne viel Einfluss auf das Gesammtsystem 1/100s od. 1/10s oder auf die Sekunde genau gehen. Optional: Du kannst statt der zusätzlichen RTC auch den AVR direkt mit einer Backup-Versorgung ausrüsten (Batterie oder GoldCap) um die Uhr weiter laufen zu lassen. Ich würde und habe auch bei Systemen mit einer externen RTC immer die interne RTC verwendet, diese wurde immer um 12:00 und 0:00 mit der externen RTC synchronisiert. Das mache ich auch heute noch bei mit Netzwerk verbundenen Systemen auf uC Basis so, dann via NTP oder SNTP. Der Vorteil der internen RTC ist, dass der Interrupt sehr schnell abgearbeitet werden kann und nur ein einziger Interrupt abgearbeitet werden muss pro definierter Zeiteinheit (kommt eben auf den eingestellten Vorteiler der RTC an). Bei RTCs, die an einem Bus hängen, muss man immer einige Bytes senden und empfangen und dann dekodieren. Das hat deutlich mehr Einfluss auf das System, gerade wenn es nur ein kleiner uC ist. Ich hoffe, ich bin jetzt im Thema geblieben. Du hast recht, wenn man davon ausgeht, dass Du etwas festes designt hast und unbedingt diese RTC verwenden willst, dann ist nur der 2. Teil dieser Antwort interessant. Ich war aber bemüht Dir zu erklären, dass Du die RTC womöglich garnicht benötigst, eben weil Du später auch geschrieben hast, dass die Stromversorgung immer gewährleistet ist. Ich wollte Dir damit also Zeit, Mühe und Geld sparen. Und wenn Du das anders lösen möchtest, ist das völlig ok, aber in einem offenen Forum kann man ja auch anderen eine Idee liefern, die hier nur mitlesen. Also, entscheide Dich für eine Lösung und zieh sie durch. Ich finde das weder schlimm noch wäre ich beleidigt. Selbst wenn Du dann irgendwo im I2C hängen bleibst, frag ruhig, ist mein Spezial-Lieblings-Bus. Ich werde Dir weiterhin helfen. Ich werde jetzt erst mal den RTC Treiber für meinen STM32F107 schreiben und ins Nut/OS mit einbinden. Ist ein schöner Zeitvertreib für einen Abend an dem nur $&(/$§$ im TV läuft :) Gruß, Ulrich
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.