mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik präzise Schaltuhr


Autor: Gunter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
hoffentlich finde ich hier jemanden, der mir folgendes Mikrocontroller 
gesteuertes Gerät bauen und programmieren kann. Gegen Materialkosten und 
Aufwandsentschädigung natürlich.
-kleine Bauform
-Echtzeitfähig; DCF77 Abgleich alle 2 Stunden und auf Knopfdruck
-LED-oder LCD Anzeige von Stunden Minuten und Sekunden
-Jede volle Minute ein Ausgabeimpuls zum Schalten von externen Geräten;
 Dieser Inpuls sollte auf die Zehntelsekunde genau jede Minute
 erfolgen
-Stromversorgung bis 12V
Ein solches Gerät bräuchte ich für die Synchronisation von Uhren und zum
Starten von Uhren und Coutern bei Gleichmäßigkeitsrallyes.

Angebote an gu.nae@t-online.de

MfG
Gunter

Autor: Esko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soll es ein Einzelstück oder eine Serie werden?
Stromversorgung vom Kfz-Akku?

Was bist du denn grob bereit auszugeben?

mfg Esko

Autor: Gunter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Esko,
ich sag jetzt einfach mal 150 € ins Blaue. Sollte das völlig daneben 
sein
möge man mir das sagen.
Sollte das Gerät so funktionieren wie gedacht, wollen meine Club-
kameraden natürlich auch sowas . Es könnten dann leicht 10 Geräte 
werden.
MfG
Gunter

Autor: Clubkollege (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es könnten dann leicht 10 Geräte werden.

die dann natürlich ein clubkollege Nachbaut ,um kosten zu Sparen.

Autor: 1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
50 stunden Hardware Design, Leiterplatte fertigen und bestuecken, 50 
Stunden Software schreiben, debuggen, fuer 1.50 Euro pro stunde - passt. 
Ich hab leider keine Zeit.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na für einen Hobby-Progger ist das ein interessantes Projekt und dafür 
auch noch 150 Euro zu bekommen wäre nicht schlecht.

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann mach' es doch.

...

Autor: Gunter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke für die Antworten , ich weiß jetzt woran ich bin.

Eine Anmerkung noch: Für jemanden der 50 h an dieser Hardware
entwickeln möchte , war die Anfrage nicht gedacht!
Natürlich habe ich mich vorher über die Suchenfunktion usw kundig 
gemacht, was es schon gibt ; jede Menge Ähnliches aber eben leider nur
Ahnliches.

MfG
Gunter

Autor: gast3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Eine Anmerkung noch: Für jemanden der 50 h an dieser Hardware
>entwickeln möchte , war die Anfrage nicht gedacht!
>Natürlich habe ich mich vorher über die Suchenfunktion usw kundig
>gemacht, was es schon gibt ; jede Menge Ähnliches aber eben leider nur
>Ahnliches.

Leute, die das schneller machen sind Pfuscher oder haben einen deutlich 
hoeheren Stundenpreis... (>50EUR/h + Mwst)


Gast3

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Gunter (Gast)

>-kleine Bauform

Wie klein? Zigarettenschachtel?

>-Echtzeitfähig; DCF77 Abgleich alle 2 Stunden und auf Knopfdruck

Warum so oft?

>-LED-oder LCD Anzeige von Stunden Minuten und Sekunden

Hmm.

>-Jede volle Minute ein Ausgabeimpuls zum Schalten von externen Geräten;
> Dieser Inpuls sollte auf die Zehntelsekunde genau jede Minute
> erfolgen

Relais oder Transistor?

Mal rechnen wie genau so ein Quarz ist. Mit Abgleich schafft der 5ppm 
und besser, macht pro Stunde einen Fehler von 18ms, macht pro Tag ne 
halbe Sekunde. Hmm, OK dann muss man schon des öfteren per DCF77 
synchronisieren.

>Starten von Uhren und Coutern bei Gleichmäßigkeitsrallyes.

Was ist eine Gleichmäßigkeitsrallye?

Ich mach dir das, wird aber ein paar Tage dauern, vor allem wenn es eine 
professionelle Platine sein soll, Bilex oder PCB-Pool oder wasauchimmer.

Ich sag mal ein kleines LCD mit 16x1 Zeichen, darunter eine kleine 
Platine mit einem kleinen AVR plus bissel Gemüse und DCF77 Modul und 
fertig. Materialkosten irgendwo um die 20-30 Euro.

>Eine Anmerkung noch: Für jemanden der 50 h an dieser Hardware
>entwickeln möchte , war die Anfrage nicht gedacht!

Stimmt.

@ Alle Motzer

Man muss nicht jeden der nach soetwas fragt gleich auseinandernehmen. 
Und der Guther war ganz sicher einer der seriösen Frager mit 
angemessenem Tonfall.

MfG
Falk

Autor: Gunter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
jetzt bin ich doch froh, dass sich auch jemand ernsthaft mit meinem 
Anliegen beschäftigt.
Zu Deinen Fragen Falk:
-Zigarettenschachtelgröße ist super ,kann aber auch doppelt so groß 
sein.
(Gehäuse und Platine brauchen nicht superprofessionell sein)
-ich weiß nicht wie genau heutige Mikrocontroller sind, vor einem Jahr 
habe ich eine Schaltuhr von ELV nachgebaut, die ist bereits nach einen
Stunde 1/2 s daneben gewesen und hat nur alle 4h synchronisiert.
-zu den minütlichen Ausgabeimpulsen: Bei den Glrallyes wird immer zur 
vollen Minute (nach Funkuhr) bei den Wertungsprüfungen gestartet, der 
Beifahrer muss dann seine Uhren und Downcounter von Hand starten , was 
naturgemäß immer ungenau ist, das sollte das Gerät übernehmen. Und da 
ich nicht vor jeder WP eine handelübliche Schaltuhr programmieren kann ( 
das
dauert zu lang) könnte mir das Gerät zu jeder Zeit einen genauen Start-
impuls geben , dann würde es per Schalter vom den Uhren getrennt bis zur 
nächsten WP.
-Bei einer Gleichmäßigkeitsrallye ( für Oldtimer ) muss auf sog.
Wertungsprüfungen eine vorgegebene Strecke mit einer vorgegebenen
Geschwindigkeit (zwischen 30 und 50 km/h)zurückgelegt werden; auf der 
Strecke und am Ziel wird mit Lichtschranken die Zeit gemessen. Der Start 
erfolgt wie schon gesagt per Funkuhr.
MfG
Gunter

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Gunter (Gast)

>(Gehäuse und Platine brauchen nicht superprofessionell sein)

Naja, aber wenn du das relativ leicht nachbauen willst, wäre eine 
geätzte Platine besser als ein Lochrasteraufbau. Was also nun? 
Lochraster oder richtige Platine?

>Stunde 1/2 s daneben gewesen und hat nur alle 4h synchronisiert.

Naja, für ne normale Schaltuhr auch ausreichend. Für ne Zeitmessung 
dieser Art natürlich nicht.

>-Bei einer Gleichmäßigkeitsrallye ( für Oldtimer ) muss auf sog.
>Wertungsprüfungen eine vorgegebene Strecke mit einer vorgegebenen
>Geschwindigkeit (zwischen 30 und 50 km/h)zurückgelegt werden;

Hoffentlich schummelt da keiner mit Tempomat ;-)

Bleibt noch die Frage nach dem Schaltausgang. Wie soll der sein? Relais, 
Transitor oder was. Schliesslich soll der doch die Uhr synchcronisieren.

MfG
Falk

Autor: GPSler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

als Anregung...wäre da ein GPS Modul keine Alternative?
Zeit und Ort bestimmen?

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Man muss nicht jeden der nach soetwas fragt gleich auseinandernehmen.

Warum nicht? Wir leben im Kapitalismus. Wenn ich zum Gunter gehen würde 
und sagen würde "Du, würdest du für mich umsonst arbeiten?" würde er mir 
bestenfalls einen Vogel zeigen.

Autor: 1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk,
du scheinst ja fix zu sein, hast schnell mal was guenstig 
zusammengekloppt. Kann man dich chartern ?

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich ganz oben u.a. "Synchronisation von Uhren" aller 2 Stunden 
lese,
setzt das ja auch einen guten DCF-Empfang und ausreichende Genauigkeit 
voraus. Je nach Standort könnte der Erfolg sehr verschieden sein.

Bevor ich da einen € für weitere Konstruktion ausgeben würde, wäre es 
nützlich den DCF-Empfang an diesem Ort zu prüfen. Je nach Störnebel oder 
Keller könnte die ganze Sache auch in die Hose gehen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Hannes Jaeger (pnuebergang)

>> Man muss nicht jeden der nach soetwas fragt gleich auseinandernehmen.

>Warum nicht? Wir leben im Kapitalismus.

Welcher Merkbefreiung und sinnloses gegenseitiges Zerfleischen 
einschlisset, was?

> Wenn ich zum Gunter gehen würde
>und sagen würde "Du, würdest du für mich umsonst arbeiten?"

Er sprach von 150 Euro + Material. Für eine Profilösung zu wenig, für 
einen Hobbybastler OK.

MfG
Falk

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
>Er sprach von 150 Euro + Material. Für eine Profilösung zu wenig, für
>einen Hobbybastler OK.

>MfG
>Falk

Was sind denn das für neue Töne? Du motzt doch sonst immer und überall
herum? Hut ab und bleibe bitte so.

Das mit den 50 Stunden sollte man eigentlich für deutlich übertrieben 
halten, aber der Teufel steckt meist in ganz banalen Dingen. Welche kann 
ich jetzt auch nicht sagen, aber unterschätzen sollte man es nicht.

Mal so nebenbei, wo soll denn das Teil überall eingesetzt werden?
"In ganz Europa" könnte da schon zum banalen Unding werden.

Viel Erfolg, Uwe

Autor: Martin S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein AVR Butterfly wäre hier ideal. Einfach noch die DCF-Antenne 
anchließen, ein Schalttransistor als Ausgang anlöten und schon ist die 
Hardware fertig. Das Programm ist sollte ja nicht so schwierig sein.

Autor: 1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vom Butterfly rate ich dringendst ab. Der hat alle Peripherie schon 
vergeben, die zusaetzlichen Stecker passen schlecht zum Design, und voll 
ist er auch schon.

Autor: Wolfgang Schmidt (wsm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Als Platine kann ich meine neue MiniAtmega8-Platine mit direkter 
Anschlussmöglichkeit für ein Standard-LCD anbieten.

Versorgung 7V - 15V oder Lionakku  3,6V-4,2V

PortB = ISP und LCD
Port C und Port D frei verfügbar.
habe noch einige Platinen, da ich bei der Platinenbestellung eine 
Europakarte ausgenutzt habe.

Größe 4,5cm x 5cm

Wolfgang

Autor: Mikki Merten (mmerten)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich jetzt so die Anforderungen lese, dürfte der Controller mit 
Bedienelementen und Ausgängen das kleinere Problem sein. DCF77 Empfang
in Rallye-Fahrzeugen oder Oldtimern dürfte wohl das grössere Problem
sein, wenn überhaupt machbar. Evtl. muss man da zu anderen Lösungen
z.b. GPS greifen. Aus dieser Sicht ist ein Kostenrahmen wohl schwer 
bestimmbar, solange da die Machbarkeit nicht geklärt ist. Sicher ein
interessanten Projekt für`s Hobby. Kommerziell in Auftrag gegeben dürfte
es wohl bei weitem den Preisrahmen sprengen.

Autor: Gunter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
was habe ich da losgetreten !!
Aber ich möchte sachlich bleiben:
-GPS ist per Reglement verboten (Mikrocontroller (noch??) nicht.
-über die Empfangsqualitäten von DCF77 Modulen bin ich mir im Klaren.
-von ganz Europa war nie die Rede mir reicht Süddeutschland

@ Falk

-natürlich ist eine geätzte Platine besser als Lochraster ( aber
 ( und das kann ich mir jetzt doch nicht verkneifen) Du solltest
 nicht über Gebühr " umsonst für mich arbeiten")
-Transistorausgang ist OK

MfG
Gunter

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Gunter (Gast)

>-natürlich ist eine geätzte Platine besser als Lochraster ( aber
> ( und das kann ich mir jetzt doch nicht verkneifen) Du solltest
> nicht über Gebühr " umsonst für mich arbeiten")

Mir ist das vollkommen egal. Eigentlich ist mir eine geätzte Platine 
lieber, denn layouten macht Spass und die Bestückung ist wesentlich 
einfacher und schneller als Fädeln auf Lochraster. Und die Platine mach 
ich nicht selber, das machen PCB-Pool & Co. Kostet halt ein paar 
Euronen.

Also was nun?

>-Transistorausgang ist OK

Open Collektor oder Push Pull? Was für ein Stecker?

MFG
Falk

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin, ich habe gerade so herumgegoogelt und bin hier gelandet… Nun, ich 
habe gerade eine ähnliche Anlage erstellt und kann davon ein Lied 
singen: Für’n Appel und´n Ei  (150 Eus) ist da nichts zu machen. Alleine 
füre die SW-Entwicklung vergingen etliche Stunden. Schau doch einfal mal 
bei HOPF vorbei; die machen da Uhrenkarten und bieten bereits 
serienmäßig allerlei Features.

ToM

Autor: Dr. ToM (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Moin allerseits. So, nun wollte ich eigentlich zu meinem Problemchen 
kommen…
Ich möchte Euch mal dazu befragen, da sicherlich  - zumindest ist dies 
an den Kommentaren teilweise  erkennbar -  einige Fachleute sind.

Ich habe eine DCF-Schaltuhr auf der Basis der HOPF 6021 mit entwickelt. 
Das ganze habe ich in ein 19-Zoll-Gehäuse verpackt, kleine LCD für die 
wichtigsten Anzeigen und einen Prozessor dazu  - fertig war die Kiste. 
Ergebnis: Sekundengenaue Schaltzeiten in möglichst flexibler und 
„unendlicher“ Vielzahl. Die Schaltzeiten lassen sich im typischen 
Wochenprogramm fahren. Oder aber  - und dies ist sicherlich 
interessanter -  auch nach genauem Datum sowie nach Wochentag (also z.B. 
nur freitags) nach Monat (z.B. nur im April), nach Jahren (…eher etwas 
für Optimisten :-) oder  - und dies dürfte auch interessant sein -  nach 
Sommer- und Winterzeit. Eine Kombination vieler dieser Kriterien ist 
möglich und bietet dadurch vielfältigste Einsatzmöglichkeiten. Nun, 
soweit läuft alles sehr gut. Ein Watchdog in Verbindung mit einem 
nonvolatiblen RAM sorgen für definierte Zustände nach einem Stromausfall 
oder sonstigen Netzpeaks. Nun zum eigentlichen Problem: Ich habe eine 
Schalttabelle, die mit der DCF-Zeit im Pollingverfahren eingelesen und 
Zeile für Zeile verglichen wird. Soweit so gut. Liegen identische 
Kriterien an, Lampe an  - in meinem Fall 24 schaltbare Kanäle möglich. 
Wenn ich aber aus technischen Gründen den Strom abschalte oder Strom 
ausfällt und erst einige Minuten (oder Stunden!) später wieder 
einschaltet, „findet“ das Programm natürlich nicht die Ein- und 
Ausschaltmarken, die in der Stromlosphase waren. Ergo: die Schaltzeiten 
werden nicht berücksichtigt. Schlimmstenfalls wurde eine Terminzeit 
programmiert und diese auch eingeschaltet. Der Ausschalttermin lag aber 
in der stromlosen Phase… Die Lampe würde nie wieder erlöschen und die 
Schaltsequenz müsste von Hand nachgestellt werden.
Ich werde im Moment „besoffen“ von meinem eigenen Quellcode und es 
blockiert irgendwie mein Hirn. Wie könnte ich programmtechnisch die 
Abfrage lösen, dass auch die „vergangenen „ Schaltpunkte nach einem 
Stromausfall „nachgesetzt werden und ggf. dazu führen, dass dann die 
Lampe ausgeschaltet bleibt, wenn die Ausschaltzeit in der Stromlosphase 
lag. Was ich nicht will, ist eine Pufferung mit einem Akku o.ä.. Auf die 
Idee wäre ich auch selber gekommen… Ich möchte jetzt einen Algorithmus 
anwenden, der (…und dies möglichst effizient) die Schalttabelle 
untersucht und „erkennt“ in welchen ZeitFENSTER sich der Schaltkanal 
gerade befindet.
Ich programmiere ausschließlich in Assembler  - womit ich recht 
effiziente Programmteile entwickeln konnte. Es fehlt mir aber hier der 
entscheidende „Kick“, der richtige Einfall. Letzlich ist mir die 
Programmiersprache egal. Wenn Ihr eine Idee habt oder so ein Problem 
schon einmal gelöst habt, traue ich mir es schon zu, es für meinen 
Exoten umzuschreiben. Der Ansatz mag nicht recht kommen…

Die Schalttabelle sieht so aus wie im Anhang „Schaltzeit“ zu sehen ist. 
Weitere Erläuterungen sind dort ebenfalls enthalten.

Besten Dank für Eure konstruktive Auseinandersetzung.

ToM

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dr. ToM (Gast)

>Wenn ich aber aus technischen Gründen den Strom abschalte oder Strom
>ausfällt und erst einige Minuten (oder Stunden!) später wieder

Muss man halt fix den aktuellen Stand speichern,

http://www.mikrocontroller.net/articles/Speicher#E...

bzw. in den Sleep Mode wechslen, wo nur die Uhr weiterläuft.

>einschaltet, „findet“ das Programm natürlich nicht die Ein- und
>Ausschaltmarken, die in der Stromlosphase waren.

Doch, denn der uC sollte immer weiter laufen. Ist auch kein wirkliches 
Problem, einfach per Lithiumzelle puffern und den Rest abschalten.

>werden nicht berücksichtigt. Schlimmstenfalls wurde eine Terminzeit
>programmiert und diese auch eingeschaltet. Der Ausschalttermin lag aber
>in der stromlosen Phase… Die Lampe würde nie wieder erlöschen und die
>Schaltsequenz müsste von Hand nachgestellt werden.

Nöö, der uC kann ja weiter rechnen, nur dass eben die Ausgabe auf die 
externen Treiber nicht erfolgt.

>Ich werde im Moment „besoffen“ von meinem eigenen Quellcode und es
>blockiert irgendwie mein Hirn. Wie könnte ich programmtechnisch die

>lag. Was ich nicht will, ist eine Pufferung mit einem Akku o.ä..

Warum?

>Ich programmiere ausschließlich in Assembler  - womit ich recht
>effiziente Programmteile entwickeln konnte.

;-)
Du bist ein kleiner Freak, der die wahre Bedeutung von "Effizienz" nicht 
wirklich kennt. Die paar Dutzend Bytes die du da einsparst, 
verschwendest du 10fach an Entwicklungszeit, Wartung etc.

> Es fehlt mir aber hier der
>entscheidende „Kick“, der richtige Einfall.

Nimm C. ;-)

>Exoten umzuschreiben. Der Ansatz mag nicht recht kommen…

Speichere beim Netzausfall die Zeit im EEPROM und beim Wiederkehren der 
Netzspannung scannst du deine Tabelle vom Anfang an bis zur 
gespeicherten Ausfallzeit. Fertig.

MFG
Falk

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde 2 Lösungen ins Auge fassen:

* die pragmatische
   Definiere für jeden Ausgang eine 'Failsafe Position'
   Wenn der Strom kommt, geht erst mal alles in die Failsafe Position
   bis dann nach und nach das Schaltprogramm uhrengesteuert
   wieder einsetzt

* speichere im EEPROM die letzte Schaltzeit
  wenn die Uhrzeit wieder da ist, gehe im Schnelldurchlauf von dieser
  letzten Zeit bis 'jetzt' das Uhrenprogramm durch und notiere alle
  Änderungen. Bist du im 'jetzt' angekommen, kennst du die benötigten
  Stellungen und kannst sie schalten.

> Ich möchte jetzt einen Algorithmus
> anwenden, der (…und dies möglichst effizient)

Alte Regel: Machs erst richtig, dann lehn dich zurück und sieh nach ob 
du schnell genug bist. Wenn nein, dann machs schneller.

Nicht falsch verstehen: Effizienz ist schon wichtig, aber ob deine 
Schaltuhr 1/10 oder 1 ganze Sekunden mit dem Scannen der Tabelle 
verbringt, ist nach einem Stromausfall von 2 Stunden sowas von egal.

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk:
Wollte mal fragen ob aus dem Auftrag von Gunter noch was geworden ist.
Und was noch interessanter ist: Wie lang hat das Entwickeln gedauert. 
Mit Software-, Hardwareentwicklung und Inbetriebnahme hätte ich 10 - 15h 
veranschlagt. Liege ich da total daneben?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Alexander Schmidt (esko)

>Wollte mal fragen ob aus dem Auftrag von Gunter noch was geworden ist.

Der läuft im Moment. Schaltplan + Layout sind fertig. Alles weitere 
folgt.

>Und was noch interessanter ist: Wie lang hat das Entwickeln gedauert.

Bis jetzt so geschätzt 3-4h, hab nicht auf die Uhr geschaut.

>Mit Software-, Hardwareentwicklung und Inbetriebnahme hätte ich 10 - 15h
>veranschlagt. Liege ich da total daneben?

Nein, aber das ist schon sportlich.

MFG
Falk

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
@Dr. ToM
Kannst du die Schaltzeiten aufsteigend ablegen? Wenn ja, bei Neuanlauf,
bginnend mit 0, alle Schaltzeiten abfragen. Damit sollte sich der
aktuelle Zustand ergeben und du brauchst nichts stützen oder 
aufschreiben.
Habe ich jedenfalls so gemacht und klappt auch.
Beim proggen der Schaltzeiten muss man natürlich etwas aufpassen oder
man lässt den µC sortieren.(tut aber dem EEProm nicht gut)

Viel Erfolg, Uwe

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Moment mal, du hast es doch schon fast fertig,
>Ich habe eine Schalttabelle, die mit der DCF-Zeit im Pollingverfahren
>eingelesen und Zeile für Zeile verglichen wird. Soweit so gut.
>Liegen identische Kriterien an, Lampe an
Dein Vergleich ist nur nicht ganz io.
Du machst "Soll = Ist ", versuche es mal mit "Soll <= Ist"
dann klappt es doch.

Viel Erfolg, Uwe

Ps.:

>>Ich programmiere ausschließlich in Assembler  - womit ich recht
>>effiziente Programmteile entwickeln konnte.

>;-)
>Du bist ein kleiner Freak, der die wahre Bedeutung von "Effizienz" nicht
>wirklich kennt. Die paar Dutzend Bytes die du da einsparst,
>verschwendest du 10fach an Entwicklungszeit, Wartung etc.

>> Es fehlt mir aber hier der
>>entscheidende „Kick“, der richtige Einfall.

>Nimm C. ;-)

>>Exoten umzuschreiben. Der Ansatz mag nicht recht kommen…

>Speichere beim Netzausfall die Zeit im EEPROM und beim Wiederkehren der
>Netzspannung scannst du deine Tabelle vom Anfang an bis zur
>gespeicherten Ausfallzeit. Fertig.

>MFG
>Falk

Unser kleiner Motzbrocken ist ja auch wider der alte. Wie konnte ich nur
anderes Denken.

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du machst "Soll = Ist ", versuche es mal mit "Soll <= Ist"

Vergiss nicht den "Will-Wert", der weicht oftmals von Soll und Ist ab...

;-)

> Unser kleiner Motzbrocken ist ja auch wider der alte. Wie konnte ich nur
> anderes Denken.

So dachte ich auch mal. Inzwischen kann ich es aber nachvollziehen. 
Schau Dir die vielen unqualifizierten Fragen in diesem Forum an, dann 
siehst Du die Ursache. Nein, ich meine nicht die Anfängerfragen, 
interessierten Anfängern wird geholfen, ich meine die Fragen der 
Möchtegern-Anfänger, die null Ahnung haben und zu faul sind, selbst 
etwas zur Klärung ihrer Frage zu tun.

...

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
@Hannes
Ich denke man sollte nicht alle über einen Kamm scheren und dem 
jeweiligen
Poster auch entsprechend antworten. Wenn ich zb.:
>> Es fehlt mir aber hier der
>>entscheidende „Kick“, der richtige Einfall.

>Nimm C. ;-)

lese, schwillt mir der Kamm. Ich will es mal noch etwas böser sagen:
Wer ASM nicht beherrscht ist für mich kein Programierer sondern ein 
Möchtegern der sich über die Tragweite seiner geistigen Ergüsse nicht 
bewusst ist.

Viel Erfolg, Uwe

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. ToM wrote:

> Wenn ich aber aus technischen Gründen den Strom abschalte oder Strom
> ausfällt und erst einige Minuten (oder Stunden!) später wieder
> einschaltet, „findet“ das Programm natürlich nicht die Ein- und
> Ausschaltmarken, die in der Stromlosphase waren.

Du zählst mit einer internen Uhr im Schnellauf bis an die DCF77-Zeit ran 
und läßt in jedem Durchlauf die Schaltzeiten prüfen.
Das sollte nur einige Sekunden dauern, wenn man nicht sehr ineffizient 
programmiert hat.
Die interne Uhr inclusive Sommerzeitautomatik brauchst Du ja eh. Wenn 
mal der DCF77-Empfang gestört ist, soll ja trotzdem pünktlich geweckt 
werden.


> Ich programmiere ausschließlich in Assembler  - womit ich recht
> effiziente Programmteile entwickeln konnte.

Dann ist wohl eher der Weg das Ziel (Programmieren als Freihzeit).

Ich benutze Assembler nur für sehr kleine Programme (aber immer 
weniger).
Ab etwa 2kB wird die Übersichtlichkeit und Wartbarkeit drastisch 
schwieriger. Ich vermute, Dein Programm wird diesen Punkt schon lange 
überschritten haben.
Es ist schon recht nervig, ganze Routinen in Assembler schreiben zu 
müssen, die in C nur wenige Zeilen wären.
Ich würde daher dazu raten, in C weiter zu machen.


Peter

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Uwe (Gast)

>>Nimm C. ;-)

>lese, schwillt mir der Kamm.

http://de.wikipedia.org/wiki/Smiley

> Ich will es mal noch etwas böser sagen:
>Wer ASM nicht beherrscht ist für mich kein Programierer sondern ein
>Möchtegern der sich über die Tragweite seiner geistigen Ergüsse nicht
>bewusst ist.

Was führt dich zu der irrigen Annahme, dass

a) ich kein Assembler kann
b) nur ASM-Programmierer wahre Helden sind

?

Peter hat es schon auf den Punkt gebracht. Ich hab mehrere Jahre den AVR 
in ASM programmiert, rein hobbymässig und minimal in der 4ma. Vor zwei 
Jahren hab ich dann den GCC "entdeckt" und war spontan begeistert. Der 
liefert gute Ergebnisse, die nur an wenigen Punkte Anlass zu Kritik 
geben. Andere Compiler sind da wahrscheinlich ähnlich. Egal, um den 
Compiler geht es nicht sondern um das Handhaben von Komplexität. Und da 
ist C hundertmal besser als ASM.

MFG
Falk

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe wrote:
> Wer ASM nicht beherrscht ist für mich kein Programierer sondern ein
> Möchtegern der sich über die Tragweite seiner geistigen Ergüsse nicht
> bewusst ist.

ROFL. YMMD!

Die Sprache ist doch nur ein Werkzeug zum Lösen verschiedener Probleme. 
Jemand der weiß, mit welchem Werkzeug er welches Problem am 
effizientesten löst, versteht was von seinem Handwerk. Jemand der aber 
versucht jedes Problem mit ein und dem selben Werkzeug zu lösen, der ist 
für mich ein Möchtegern, der vom eigentlichen Handwerk nichts versteht, 
sondern nur mit (s)einem Werkzeug umgehen kann.

Gruß
Dominique 'Programmierer, der noch nie eine Zeile ASM geschrieben hat' 
Görsch

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dominique Görsch wrote:

> Dominique 'Programmierer, der noch nie eine Zeile ASM geschrieben hat'

Ich behaupte mal, wenn jemand Assembler kann, dessen C-Programme sind 
höchstens halb so groß und mindestens doppelt so schnell.

Daher ist Grundlagen lernen mit Assembler von Vorteil.
Man sollte schon das Listing des C-Compilers lesen können.

Assembler hat mir auch das C Lernen erleichtert. Insbesondere die ganze 
Pointersache ist ja nicht leicht zu verstehen und dann habe ich einfach 
im Listing nachgesehen, ob der Compiler das gemacht hat, was ich wollte.


Peter

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Peter Dannegger (peda)

>Ich behaupte mal, wenn jemand Assembler kann, dessen C-Programme sind
>höchstens halb so groß und mindestens doppelt so schnell.

Naja, vielleicht.

>Daher ist Grundlagen lernen mit Assembler von Vorteil.

Die Welt der Programmierer besteht nicht nur aus (kleinen) 
Mikrocontrollern. Verdammt viele Leute programmieren nur auf PCs, Unix, 
whatever. Nicht zu vergessen die in den letzten 15 Jahren entstandenen 
Netzsprachen ala HTML, Java, PHP etc. Was wollen DIE mit Assembler? Sind 
das nur halbe Programmierer?

>Assembler hat mir auch das C Lernen erleichtert.

Subjektiver Eindruck.

MFG
Falk

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:

> Die Welt der Programmierer besteht nicht nur aus (kleinen)
> Mikrocontrollern. Verdammt viele Leute programmieren nur auf PCs, Unix,
> whatever. Nicht zu vergessen die in den letzten 15 Jahren entstandenen
> Netzsprachen ala HTML, Java, PHP etc. Was wollen DIE mit Assembler? Sind
> das nur halbe Programmierer?

Ich fürchte, ja.

Die Langsamkeit und Größe vieler Windowsprogramme dürfte auf fehlendes 
Grundlagenwissen zurückzuführen sein.

Wenn man die Optimierung ausschließlich nur den Compilerbauern überläßt, 
verschenkt man einen Großteil an Potential.

Ich weiß garnicht, ob es überhaupt Ausbildungen oder Kurse für 
effizientes Programmieren gibt. Wenn doch, sind sie bestimmt keine 
Pflicht für Programmierer.


Peter

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>...entstandenen Netzsprachen ala HTML, Java, PHP etc. Was wollen DIE mit 
>Assembler?

Zumindest für Java gibt es eine Art Assembler -> Jasmin.

MfG Spess

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In vielen Ausbildungen erlernst du die Logiken des Programmierens ganz 
ohne Bezug zu einer Hochsprache oder oft auch zu einer sehr simpel 
gestrickten Sprache. Bei mir war es in der Ausbildung anfangs schlicht 
nur Pseudocode und nachher VB. Ich finde es schade, dass in unserem 
Jahrgang VB statt C gewählt wurde, der Jahrgang vor mir hat noch auf der 
Grundlage von C das Programmieren erlernt.

Ich ziehe ganz klar meinen Hut vor Leuten, die ASM beherrschen, aber 
selbst wenn ich es könnte, würde ich es nichtmehr anwenden wollen. Meine 
ersten Schritte auf dem AVR habe ich durchaus sehr erfolgreich mit 
Bascom-Basic gemacht und zur Zeit nutze ich den AVR in erster Linie 
dazu, endlich mal mein C aufzubessern.

Windowsprogramme sind in der Tat viel Bloat, was aber oft einfach daran 
liegt, dass Ressourcen billiger sind als Manpower. Will heißen: Das was 
die verschwendeten Ressourcen kosten, spart man durch die Verwendung von 
fertigen Modulen und Bibliotheken (z.B. in VB, C#, .Net, ...) x-mal in 
der Entwicklungszeit ein.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Dannegger (peda)

>> das nur halbe Programmierer?

>Die Langsamkeit und Größe vieler Windowsprogramme dürfte auf fehlendes
>Grundlagenwissen zurückzuführen sein.

OK, zwei Punkte für dich :-0

>Wenn man die Optimierung ausschließlich nur den Compilerbauern überläßt,
>verschenkt man einen Großteil an Potential.

Wohl leider wahr. Heute hat Hello World 1MB++ ;-)

>Ich weiß garnicht, ob es überhaupt Ausbildungen oder Kurse für
>effizientes Programmieren gibt. Wenn doch, sind sie bestimmt keine
>Pflicht für Programmierer.

Stimmt.

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohje... ich war doch nur über's Wochenende nicht da...Lieben Dank für 
Eure Anmerkungen zum Schaltproblemchen  - zumindest an einige!
Dass teilweise daraus Gesülze um die "richtige" Programmiersprache 
wurde, hätte ich im Forum wie dieses gerne vermieden. Dank an Peter und 
Falk, die es offenbar verstanden haben.
Also, nochmals zu den Sprachen: Ich programmiere in ASM ausschließlich 
für nonkommerzielle Zwecke; also eher aus Lust und Laune. Und, dies 
schon seit Einführung des 8085er von Intel (damals auch Siemens). Ich 
denke mal, dass ein in ASM geschriebener Rumpf generell die 
effizienteste Programmierung ist. Das ich heute damit nicht mehr 
kommerziell tätig werden kann, ist mir wohl bewusst. Allerdings sieht 
man auch an objektorientierten Programmiersprachen was für ein Müll 
produziert wird. Ich programmiere selber die gängigsten Sprachen und 
kann davon ein Lied trällern. Nur, ich kann ASM (verstehen)! Und somit 
sehe ich, was der Compiler für'n Dreck rausschleudert: Doppelte (oder 
gleich mehrfache!) Routinen, schlechte Arithmetik usw. Nee, dann doch 
lieber die Hälfte an Quellcode und dafür die doppelte Zeit :-)).
Soviel dazu.
Zum Schaltproblem würde ich gerne einige Eurer Erörterungen ein wenig 
hinterfragen wollen. So z.B. die von Dir, Falk:
Du schreibst: "Muss man halt fix den aktuellen Stand speichern, 
http://www.mikrocontroller.net/articles/Speicher#E...bzw. in den Sleep 
Mode wechseln, wo nur die Uhr weiterläuft. "
Das mit dem aktuellen Stand abspeichern soll wohl heißen, dass ich die 
aktuelle Ausfallzeit festhalten soll? Die habe ich. Im Moment habe ich 
sie nur noch nicht für andere Zwecke verwendet als nur für das 
Vergleichen der Schaltzeit und zum Darstellen des Strings in 
leserfreundliche Ansicht auf LCD - so wie man eben eine Uhr gewöhnt ist. 
Das funktioniert so: Eine separate HOPF-Karte 6021 (Funkuhr mit 
ASCII-String der Zeitausgabe, sekündlich) wird von meinem Prozz 
eingelesen, zwischengespeichert und dann aus dem Zwischenspeicher heraus 
verglichen. Fällt die Uhrenkarte aus (...hat eigenen Watchdog), habe ich 
immer noch den letzten Zeiteintrag. Da ein Trägerzeichen fehlt, merkt 
mein Prozz, dass sich die Zeit nicht mehr ändert und setzt ggf. einen 
Reset an die Karte ab. Fehlerprotokoll wird erstellt und als String an 
PC oder Drucker gesandt (später als SMS geplant).Die Idee mit dem 
Ausfall-Zeitstempel auswerten finde ich schon ganz brauchbar. Im Übrigen 
- und hier kommt wieder der ASM-Programmierer mit seinem endlichen RAM - 
wollte ich diese gesamte Fehler-Routine ohnehin nur aufrufen lassen, 
wenn zuvor ein Fehler war bzw. beim Neustart nach dem Einschalten. Es 
sei denn, es gibt eine geniale Routine, sodass ich meine triviale 
Pollingroutine gänzlich über den Haufen werfen kann und dabei nur ein 
paar Zeilen (und Millisekunden) einbüße…
Falk, ich habe keine EEPROMs laufen. Nonvolatible RAMs. Die haben sowatt 
wie einen Puffer und sind aber physikalisch absolut wie RAM. Die 
Probleme mit sterbenden EEPROMS (nach immerhin etlichen Schreibzyklen) 
könnte ich nicht ertragen  - abgesehen von der Schreib-/Lesezeit. Das 
System muss so sicher wie möglich sein  - deswegen auch die HOPF-Karte 
(DCF-Fehlererkennung "onboard"...).Falk, warum ich nicht mit Akkus 
arbeiten möchte ist einfach erklärbar. Das System wird sehr lange 
alleine gelassen. Sehr lange! Ich habe in anderen Foren viel über Akkus 
gelesen. Mir wurde ganz schwindelig, wenn ich nur an die Problematik des 
richtigen Ladegerätes denke. Nee, das Gerät muss softwaremäßig ganz 
autark wieder auf die Beine kommen. Und, ich bin mir sicher, dass dies 
auch ganz trivial möglich ist. Man muss ja nur die Birne einschalten… 
Das mit dem (vorhandenen!) Fehler-Zeitstempel war ja immerhin ein erste 
guter Ansatz von Dir, Falk.
Hm, das meine ich mit "besoffen vom Quellcode"... Wenige Zeilen tiefer 
schreibst Du, Falk: "Speichere beim Netzausfall die Zeit im EEPROM und 
beim Wiederkehren der Netzspannung scannst du deine Tabelle vom Anfang 
an bis zur gespeicherten Ausfallzeit. Fertig." Nun, dies müsste ja 
bedeuten, dass ich nach dem Einschalten erst einmal die gesamte 
Ausfallzeit simultan im Schnelldurchlauf fahre  - bis zur aktuellen 
Zeit. Mache ich jetzt einen Gedankenfehler? Zu Dir, Karl Heinz: Die 
pragmatische Lösung würde mir gefallen. Im Moment habe ich so etwas wie 
eine Failsafe bereits in Betrieb. Wenn keine Ausschaltzeit nach dem 
Einschalten "dazwischenkommt", geht alles in Ordnung. Auch schalten alle 
Ausgänge entsprechende des letzten Zustands. Problematisch wird es ja 
erst, wenn genau der oben von mir beschriebene Fall eintritt: Lampe 
zeitgesteuert an und durch Stromausfall die Ausschaltzeit "verpennt". 
Das ist das Problem. Tja, dann sehe ich jetzt beim Beantworten, dass Du, 
Karl Heinz, genau diese Idee ansprichst. Den Schnelldurchlauf... Hm, 
gefällt mir! Darüber lässt sich nachdenken, Karl Heinz.
Alexander, Deine Anmerkung mit der alten Regel ist schon ok. Aber, mir 
geht es nicht um ein paar µs Zeitverlust. Die kann ich sogar per 
HOPF-Karte korrigieren. Genau das mit den 2 Stunden Ausfall und der 
damit möglicherweise verpassten Schaltsequenz(en) geht es mir. Außerdem: 
ein ordentlich strukturiertes und effizient angelegtes Progrämmchen 
macht i.d.R. auch seine Arbeit zuverlässig(er)! Die Effizienz liegt aus 
meiner Sicht in der Geschwindigkeit beim Durchlauf einer vollen Tabelle 
und auch  - und dies ist insbesondere beachtenswert -  im endlichen 
Speicher für alles in allem (benutzerfreundliche Bedienerführung 
(dialogfreundliche Klartextdarstellung), einfache Handhabung, 
("unendlich") viele Schaltspiele pro Kanal, evtl. noch mehr Kanäle 
(wer's braucht)).
An Dich Uwe, nee, wenn es geht, würde ich nicht gerne irgendwelche 
Schaltspiele sortieren oder aber die Reihenfolge festlegen. Das würde ja 
bedeuten, dass ich Speicherplatz reservieren muss. Genau dies will ich 
in jedem Fall verhindern. Meine Tabelle "Wächst" mit den Aufgaben. Keine 
oder wenige Aufgaben = geringer Pollingaufwand...Und richtig, Sortieren 
kostet den EEPROM (den ich nicht verwende) und aber jede Menge Zeit... 
(die ich auch nicht habe). Die Tabelle enthält ja auch Parameter, die es 
gestatten, dass sich der Schaltbefehl "irgendwo befinden darf. Und, was 
machst Du, wenn gleich mehrere Ausschaltbedingungen auf nur ein 
Einschalten reagieren soll (Wenn "Sommer", dann...)? Dein Vorschlag "Du 
machst "Soll = Ist ", versuche es mal mit "Soll <= Ist" dann klappt es 
doch." interessiert mich. Aber, wie geht's dann weiter? Wo vergleiche 
ich was wie? Ich habe in diesem Zusammenhang auch schon überlegt, wie 
ich das Carry-Bit des Prozessors dazu verwenden könnte. Nur, vielleicht 
denke ich zu umständlich.
Naja, Uwe, diesen Kommentar "So dachte ich auch mal. Inzwischen kann ich 
es aber nachvollziehen. Schau Dir die vielen unqualifizierten Fragen in 
diesem Forum an, dann siehst Du die Ursache. Nein, ich meine nicht die 
Anfängerfragen, interessierten Anfängern wird geholfen, ich meine die 
Fragen der Möchtegern-Anfänger, die null Ahnung haben und zu faul sind, 
selbst etwas zur Klärung ihrer Frage zu tun." solltest Du lieber stecken 
lassen! Ich frage hier an, weil ich mich beruflich mit anderen Details 
beschäftige. Denn, auch hier gibt es genügend Leute, die noch weniger 
Ahnung haben, sich aber zu Antworten hinreißen...

Noch mal zu Falk: Die Idee mit der internen Uhr muss ich verwerfen, 
Falk. Selbst, wenn es recht trivial zu lösen wäre, käme ich mir ein 
wenig schäbig vor. Eine (schlechtergehende) Uhr soll die DCF77 stützen, 
wenn der Prozz (welcher ja nicht zum DCF gehört) nicht mag. Und, wenn 
der Prozz ausfällt (Strom), dann tickt zwar die interne Uhr  - wer aber 
vergleicht inzwischen? Neee, ist nicht so mein Ding! Wäre wohl so was 
wie ein Watchdog für den Watchdog… Die HOPF-Karte kann zwar auch mal 
abschmieren  - hat aber dann auch eine Quarzreserve.
Tja, Peter, Deine Behauptung stimmt garantiert, wenn Du sagst "Ich 
behaupte mal, wenn jemand Assembler kann, dessen C-Programme sind 
höchstens halb so groß und mindestens doppelt so schnell." Und ist ja 
auch logisch. Unübersichtlich ist es auch nicht, wenn man es gelernt 
hat, seine Programme zu strukturieren. Wer kennt denn heute noch ein 
Struktogramm, geschweige wer hat je mal eins gezeichnet/entworfen? Dann, 
ja, spätestens dann lernst Du Deine Zeilen zu kommentieren und in 
entsprechenden UP zu gruppieren  - immer im  Hintergrund, wie viel Bytes 
dieser Befehl gegenüber einfachen Jump-Routinen hat... Und netter 
Nebeneffekt: Diese Strukturierarbeit zieht sich wie ein roter Faden 
durchs Leben: Du denkst strukturiert...Tja, ich habe auch genügend 
Erfahrung mit anderen Hochsprachen wie C, Pascal und sogar noch Cobol. 
Nebenbei lasse ich die Uhr auch noch über einen Monitor auf dem PC 
laufen. Da habe ich dann C++ und Delphi eingesetzt  - nicht Assembler 
;-)). Und, die so zu lösen, wie ich es bisher gemacht habe, ist auch ein 
Philosophieansatz...Abgesehen davon, nicht die Sprache führt zur Lösung 
des Problems.

Also, erst einmal lieben Dank an alle konstruktiven Überlegungen zum 
Thema

ToM

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. ToM wrote:

> Zeit. Mache ich jetzt einen Gedankenfehler? Zu Dir, Karl Heinz: Die
> pragmatische Lösung würde mir gefallen. Im Moment habe ich so etwas wie
> eine Failsafe bereits in Betrieb. Wenn keine Ausschaltzeit nach dem
> Einschalten "dazwischenkommt", geht alles in Ordnung. Auch schalten alle
> Ausgänge entsprechende des letzten Zustands. Problematisch wird es ja
> erst, wenn genau der oben von mir beschriebene Fall eintritt: Lampe
> zeitgesteuert an und durch Stromausfall die Ausschaltzeit "verpennt".
> Das ist das Problem.

Wo ist das Problem? Die pragmatische Lösung geht jetzt so vor:
Der Strom kommt wieder.
Der µC startet neu und holt sich die Failsafe Position für diese Lampe. 
Und die sagt: im Zweifel ist sie auszuschalten -> Lampe geht auf jeden 
Fall mal aus.
Im Lauf der nächsten Stunden wird die Lampe dann durch das Schaltwerk 
wieder eingeschaltet bis dann nach einiger Zeit wieder alles so läuft, 
wie es laufen soll.

> Tja, dann sehe ich jetzt beim Beantworten, dass Du,
> Karl Heinz, genau diese Idee ansprichst. Den Schnelldurchlauf... Hm,
> gefällt mir! Darüber lässt sich nachdenken, Karl Heinz.

Frei nach Udo Jürgens
Tausend Jahreeeee, sind ein Tag

Unter Umständen musst du ein bischen umstrukturieren. Ist wahrscheinlich 
nicht so prickelnd, wenn deine Lampen in rascher Folge ein und wieder 
ausgehen, nur weil das Programm ein paar Stunden aufholen muss und ein 
paar Ein/Auszyklen verpennt hat.

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ha, so eben nicht, Karl Heinz:

"Wo ist das Problem? Die pragmatische Lösung geht jetzt so vor:
Der Strom kommt wieder.
Der µC startet neu und holt sich die Failsafe Position für diese Lampe.
Und die sagt: im Zweifel ist sie auszuschalten -> Lampe geht auf jeden
Fall mal aus.
Im Lauf der nächsten Stunden wird die Lampe dann durch das Schaltwerk
wieder eingeschaltet bis dann nach einiger Zeit wieder alles so läuft,
wie es laufen soll."

Im Moment kennt das Gerät den letzten funktionierenden Schaltbefehl, 
z.B. Lampe an. Dann kommt der Stromausfall. Failsave ist auf "EIN" 
gesetzt. Strom kommt wieder und kat aber zwischenzeitlich den 
Ausschaltzeitpunkt "verpasst". Der Kanal würde also nun einschalten, 
weil Failsave auf EIN, und dauerbrennen, bis im günstigsten Fall der 
nächste AUS-Befehl kommt. Oder es geht wie bei Deiner Überlegung: Im 
Zweifel: aus. Das will ich ja genau verhindern. Ich muss die Zeiträume 
erfassen und diese auswerten, damit nicht versehentlich ein Kanal etwas 
falsches wiedergibt oder aber ein Signal fehlt.
Das mit dem raschen Einschalten habe ich schon klar gemacht. Dies wäre 
auch tödlich! Nach dem (Wieder-)Einsschalten werden zuerst die 
Failsave-Speicher ausgelesen, danach erst die Lampen aus- bzw. 
eingeschaltet.
Die Scanroutine "Schnelldurchgang" müsste ich ja nur mit einer 
zusätzlichen Konstante beim ersten Einschalten als Indikator setzen. 
Wenn k=1, dann überspringe...  Soweit ok. Es bleibt knifflig  - jedoch 
erscheint mir Dein Ansatz wirklich praktikabel zu sein. Da ich im Moment 
sowiso nicht weitermachen kann, warte ich mal noch andere 
Gedankenansätze ab. Vielleicht sind ja auch Kombinationen daraus 
verwertbar. Soweit, lieben Dank vorerst.

ToM

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. ToM wrote:

> Noch mal zu Falk: Die Idee mit der internen Uhr muss ich verwerfen,
> Falk. Selbst, wenn es recht trivial zu lösen wäre, käme ich mir ein
> wenig schäbig vor. Eine (schlechtergehende) Uhr soll die DCF77 stützen,
> wenn der Prozz (welcher ja nicht zum DCF gehört) nicht mag.

Dann bist Du warscheinlich der einzigste, der es nicht macht.

Übliche DCF77-Uhren holen sich nur einmal in der Nacht die Zeit und 
synchronisieren sich damit. Dann laufen sie 24h mit ihrem eigenen Quarz.
Das wird gemacht, um eine lange Laufzeit mit einer Batterie zu erzielen.
Der DCF77-Empfänger schluckt relativ viel Strom.
Außerdem ist Langwellenempfang nicht besonders stabil, d.h. es kommt 
öfters vor, daß der Empfang gestört ist (z.B. bei Gewitter).

Am besten läßt Du diese Uhr im FRAM laufen, d.h. sie bleibt bei 
Stromausfall einfach stehen. Und bei Wiederkehr holt sie wieder auf bis 
zur DCF77-Zeit und vergleicht dabei die vergangenen Weckzeiten.


Peter

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. ToM wrote:

> Im Moment kennt das Gerät den letzten funktionierenden Schaltbefehl,
> z.B. Lampe an. Dann kommt der Stromausfall. Failsave ist auf "EIN"
> gesetzt. Strom kommt wieder und kat aber zwischenzeitlich den
> Ausschaltzeitpunkt "verpasst". Der Kanal würde also nun einschalten,
> weil Failsave auf EIN, und dauerbrennen, bis im günstigsten Fall der
> nächste AUS-Befehl kommt. Oder es geht wie bei Deiner Überlegung: Im
> Zweifel: aus. Das will ich ja genau verhindern.

Genau darum nennt man das die 'pragmatische Lösung'. Die ist:
simpel und dafür auch manchmal falsch.

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
> Übliche DCF77-Uhren holen sich nur einmal in der Nacht die Zeit und
> synchronisieren sich damit.

Ausnahmslos alle Wecker mit DCF die ich in den letzten 10 Jahren in der 
Hand hatte, taten das stündlich. Manche zur vollen Stunde, manche ab 
Minute :58 damit sie zur vollen Stunde synchronisiert sind.

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter, ich verstehe. Das Kerlchen von Hopf ist aber nicht ganz 
üblich... Nun, das mit dem Stehenbleiben usw. ist kein Problem, da ich 
ja in meinem Prozess eh einen Zeitstempel habe. Ich habe statt FRAMs nur 
diese schönen nonvolatiblen Tierchen. Die Technik steht auch. Das 
Wiederanlaufen und Synchronisieren mit dem LW-Signal verschlingt ca. 3 
Minuten. In diesen 3 Minuten (oder bei anderen Fehlern) geht meine Uhr 
(nicht die HOPF-Karte) auf "Störung". Nach 3 Minuten  - nach einem Reset 
- hat die HOPF-Karte in jedem Fall über seinen Goldcap die Zeit über 
einen Quarzbetrieb angezeigt. Der Ausfall oder die Tücken des DCF sind 
im Moment vernachlässigbar. Dafür könnte ich bei Funktionieren dann auch 
eine GPS-Karte einbauen.
Das Problem ist nicht das Zeitsignal. Das kommt (vorerst) störungsfrei 
über diese Karte. Natürlich läuft diese streckenweise auch "unrund"  - 
nur, dadurch würden mir nie Schaltstellungen verloren gehen. Mein 
Problem ist der Stromausfall und das elektrisch korrekte Nachziehen der 
Schaltsequenzen nach erstmaligem Wiederinbetriebnehmen.

Gruß
ToM

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. ToM wrote:

> Noch mal zu Falk: Die Idee mit der internen Uhr muss ich verwerfen,
> Falk. Selbst, wenn es recht trivial zu lösen wäre, käme ich mir ein
> wenig schäbig vor. Eine (schlechtergehende) Uhr soll die DCF77 stützen,
> wenn der Prozz (welcher ja nicht zum DCF gehört) nicht mag.

Es soll ja auch schon vorgefallen sein, dass der DCF Sender in Frankfurt 
ausgefallen ist.


Wenn du die 'Schnelldurchlauflösung' näher untersuchst, spiel das Ganze 
auch mal für den Fall Sommer/Winterzeitumstellung durch.

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter, die HOPF-Produkte sind nicht mit Wecker vergleichbar. Was da 
physikalisch beim DCF-Empfang abgeht, weiß ich. Kann man ja viel drüber 
lesen. Schau mal unter: http://www.hopf-time.com/de/fg6021.htm

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl Heinz, ich überlege, wie ich meinen vorhandenen Pollingprozess 
beibehalten kann und nur im "oberen" Teil des Programmes beim 
Wiedereinschalten einen Zeitraffer einsetze, bis Zeitraffer = Realtime 
ist. dann erst wird der Programmblock für die Dauer des Betriebs 
verlassen. Ich habe fast das Gefühl, dass dies mich weiterbringt und nur 
einige 10kb kostet...

Ich bleibe dran...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. ToM wrote:
> Hallo Peter, ich verstehe. Das Kerlchen von Hopf ist aber nicht ganz
> üblich... Nun, das mit dem Stehenbleiben usw. ist kein Problem, da ich
> ja in meinem Prozess eh einen Zeitstempel habe. Ich habe statt FRAMs nur
> diese schönen nonvolatiblen Tierchen.

FRAM sind nonvolatile und wie SRAM benutzbar.
Was für Tierchen hast Du denn, hoffentlich nicht die mit interner 
Batterie (Dallas/Maxim), damit hast Du in etwa 10 Jahren ein Problem.

Wenn Dein Programm modular aufgebaut ist, dann sollte es kein Problem 
sein, noch eine interne Quarzuhr zwischen dem Hopf-Dekoder und Deinem 
Weckzeitvergleich dazwischen zu schalten (zu programmieren).
Solange die Quarzuhr feststellt, daß sie nachgeht, zählt sie so schnell 
hoch, wie zum Weckzeitvergleich nötig ist. Ist sie dann synchron, zählt 
sie normal im Sekundentakt.

Du brauchst keinerlei Sonderbehandlung, jede Weckzeit wird geprüft.
Wenn 10 Tage Stromausfall waren, blitzt z.B. eine Lampe, die täglich 
geschaltet wird, 10-mal auf, um dann auf dem richtigen Zustand zu 
bleiben.

Und damit ist dann Dein Problem erschlagen.


Peter

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dr. ToM (Gast)

>Falk, ich habe keine EEPROMs laufen. Nonvolatible RAMs.

Umso besser.

>Probleme mit sterbenden EEPROMS (nach immerhin etlichen Schreibzyklen)
>könnte ich nicht ertragen

???
Fällt 1 Million mal der Strom aus?

> - abgesehen von der Schreib-/Lesezeit.

Naja, ist in dem Moment glaub ich egal.

>arbeiten möchte ist einfach erklärbar. Das System wird sehr lange
>alleine gelassen. Sehr lange!

Was ist sehr lange bei dir? 10 Jahre?

>bedeuten, dass ich nach dem Einschalten erst einmal die gesamte
>Ausfallzeit simultan im Schnelldurchlauf fahre  - bis zur aktuellen
>Zeit. Mache ich jetzt einen Gedankenfehler?

Nein, genau so ist das gemeint.

>kostet den EEPROM (den ich nicht verwende) und aber jede Menge Zeit...
>(die ich auch nicht habe).

Wieso? Was hat denn dein AVR so todwichtiges zu tun, dass er nicht ein 
paar Tabellen sortiren könnte? MIt do bissel DCF Zeit und ein paar 
Schaltkanälen langweilt der sich zu Tode.

>Noch mal zu Falk: Die Idee mit der internen Uhr muss ich verwerfen,
>Falk. Selbst, wenn es recht trivial zu lösen wäre, käme ich mir ein
>wenig schäbig vor. Eine (schlechtergehende) Uhr soll die DCF77 stützen,

Besser ein ungenaue Zeit als GAR KEINE!

>wenn der Prozz (welcher ja nicht zum DCF gehört) nicht mag. Und, wenn
>der Prozz ausfällt (Strom), dann tickt zwar die interne Uhr  - wer aber
>vergleicht inzwischen?

Wenn der Stom ausfällt, ist deine gesammte Maschine Out of order.

Mfg
Falk

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. ToM wrote:
> Karl Heinz, ich überlege, wie ich meinen vorhandenen Pollingprozess
> beibehalten kann und nur im "oberen" Teil des Programmes beim
> Wiedereinschalten einen Zeitraffer einsetze, bis Zeitraffer = Realtime
> ist. dann erst wird der Programmblock für die Dauer des Betriebs
> verlassen. Ich habe fast das Gefühl, dass dies mich weiterbringt und nur
> einige 10kb kostet...

Ich hab grad mal nachgezählt, die Uhrenroutine mit Kalender ist 72 Byte 
groß, die Sommerzeitumstellung 38 Byte:

Beitrag "Zeit + Temperatur auf LCD mit AVR"

Wie willst Du denn auf 10kB kommen?
Machst Du etwa alle Variablen als float?


Peter

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter wrote:
>FRAM sind nonvolatile und wie SRAM benutzbar.
>Was für Tierchen hast Du denn, hoffentlich nicht die mit interner
>Batterie (Dallas/Maxim), damit hast Du in etwa 10 Jahren ein Problem.

>Wenn Dein Programm modular aufgebaut ist, dann sollte es kein Problem
>sein, noch eine interne Quarzuhr zwischen dem Hopf-Dekoder und Deinem
>Weckzeitvergleich dazwischen zu schalten (zu programmieren).
>Solange die Quarzuhr feststellt, daß sie nachgeht, zählt sie so schnell
>hoch, wie zum Weckzeitvergleich nötig ist. Ist sie dann synchron, zählt
>sie normal im Sekundentakt.

>Du brauchst keinerlei Sonderbehandlung, jede Weckzeit wird geprüft.
>Wenn 10 Tage Stromausfall waren, blitzt z.B. eine Lampe, die täglich
>geschaltet wird, 10-mal auf, um dann auf dem richtigen Zustand zu
>bleiben.

>Und damit ist dann Dein Problem erschlagen.


Hallo Peter, ich habe derzeit Dallas verbaut. Ist aber auch nicht 
tragisch, da das ganze Fragliche Drumherum eh als Laboraufbau mehr oder 
weniger herumhängt bzw. auf Sockeln ist. Hast natürlich Recht  - die 
Kerlchen sind nonvolatil  - weniger „-bel“…
Nun, gibt es hierzu Alternativen, die nicht nach 10 Jahren in den Soden 
verglühen?
Das mit der Quarzuhr lässt mich aber noch nicht in Ruhe. Die Karte hat 
sowatt onboard. Die Zeit wird auch ggf. bei schlechtem Empfang 
substituiert und angezeigt. Nochmal, mein Problem ist, das es nicht 
passieren darf, dass die Lampe nunmehr an ist obwohl eigentlich aus sein 
muss. Das mit dem Blitzen kann man softwaremäßig verhindern  - sollte 
man auch, wenn es um andere Lasten geht. Ich habe keine trivialen 
Wochenprogramme laufen. Da wäre es natürlich vernachlässigbar, wenn ein 
Tag mal etwas spinnt. Obwohl schlimm genug…

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk, nee, so oft fällt natürlich nicht der Strom flach. Nur, wenn ich 
sekündlich einen String ablege, ist die Zeit in 12 Tagen abgelaufen…
Vielleicht habe ich Dich auch nicht verstanden und Du meinst wirklich 
nur das Abspeichern des Failsave-Strings. Nun, mit FRAM  - so nennt man 
die Kerlchen auch (wieder etwas hinzugelernt…) -  ist es eben einfacher, 
da ich dann auch die Schalttabelle und den zwischengespeicherten String 
der Zeit darauf habe.
Zu Deiner Frage, die sich ja höchstwahrscheinlich auf die Akkus bezieht, 
wie lange „lange“ ist, kann ich Dir sagen, es sind ca. 2 Jahre unter 
miesen klimatischen Bedingungen.

>>bedeuten, dass ich nach dem Einschalten erst einmal die gesamte
>>Ausfallzeit simultan im Schnelldurchlauf fahre  - bis zur aktuellen
>>Zeit. Mache ich jetzt einen Gedankenfehler?

>Nein, genau so ist das gemeint.

Falk, wie hast Du es dann gemeint?

>Wieso? Was hat denn dein AVR so todwichtiges zu tun, dass er nicht ein
>paar Tabellen sortiren könnte? MIt do bissel DCF Zeit und ein paar
>Schaltkanälen langweilt der sich zu Tode.

Nee, der Prozz langweilt sich nicht. Er hat noch eine komplette 
Industriesteuerung (Sensorik/Aktorik) über Interruptaufruf am Hals.

>Wenn der Stom ausfällt, ist deine gesammte Maschine Out of order.

Jo, richtig. Aber wenn der Strom kommt soll nicht der Rest auch noch in 
den Soden verglühen…

ToM

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter wrote:

>Ich hab grad mal nachgezählt, die Uhrenroutine mit Kalender ist 72 Byte
>groß, die Sommerzeitumstellung 38 Byte:

>Beitrag "Zeit + Temperatur auf LCD mit AVR"

>Wie willst Du denn auf 10kB kommen?
>Machst Du etwa alle Variablen als float?
>Peter

…gut gerechnet! Aber: Ich brauche nicht das Signal aufbereiten. Ich 
glaube übrigens diesen Thread zu kennen. Ich will nicht das DCF-Signal 
aufbereiten. Dies kommt per String aus der HOPF-Karte. Naja, mit 10k 
habe ich mich auch mächtig vertan. Es dürften vielleicht  - wenn die 
Routine komplett wiederholt werden muss ein paar hundert sein.

ToM

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. ToM wrote:
> Falk, nee, so oft fällt natürlich nicht der Strom flach. Nur, wenn ich
> sekündlich einen String ablege, ist die Zeit in 12 Tagen abgelaufen…

Ich würds auch nicht sekündlich ablegen, sondern nur dann wenn ein 
Schaltzyklus anfällt. Du wirst ja nicht jede Sekunde was schalten 
müssen. Und im Grunde brauchst du ja für einen Neuaufsatz nur die Zeit, 
wann zuletzt was geschaltet wurde. Wenn an deiner Steuerung die nächsten 
2 Stunden nichts geschieht ehe der Strom ausfällt, ist es doch beim 
Neustart belanglos, ob du diese 2 'stillen' Stunden noch ein 2-tes mal 
im Schnelldurchgang durchsimulierst oder nicht. Aber dein EEPROM (oder 
was auch immer) wird es dir mit verlängerter Lebendsdauer danken, wenn 
du ihm etliche Schreibzyklen ersparst.

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den legst du natürlich nur dann ab, wenn die Spannung abfällt.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Dr. ToM (Gast)

>sekündlich einen String ablege, ist die Zeit in 12 Tagen abgelaufen…
>Vielleicht habe ich Dich auch nicht verstanden und Du meinst wirklich

In der Tat. Die Vorposter haben es schon gesagt.

>Zu Deiner Frage, die sich ja höchstwahrscheinlich auf die Akkus bezieht,
>wie lange „lange“ ist, kann ich Dir sagen, es sind ca. 2 Jahre unter
>miesen klimatischen Bedingungen.

Das schaffen Lithiumzellen problemlos, zumal sie nur dann Energie liefen 
müssen, wenn der Saft weg ist, was nicht ewig dauern sollte. Die paar 
Dutzen Mikroampere die dann der AVR zieht (Siehe Power Save 
Sleep-Mode) bringt so eine Zelle mehrere Jahre.

>Falk, wie hast Du es dann gemeint?

Genau so wie ich es beschrieben habe und die wiederholt hat.

Für einen der "effizent in ASM programmiert" und dessen 
"Strukturierarbeit sich wie ein roter Faden durchs Leben zieht" bist du 
reichlich begriffsstutzig . . .

Ab und an mal den Rechner ausschalten und an die frische Luft gehen.

>Nee, der Prozz langweilt sich nicht. Er hat noch eine komplette
>Industriesteuerung (Sensorik/Aktorik) über Interruptaufruf am Hals.

Ja und? Ne kleine SPS mit 10..100ms Zykluszeit. Oder steuert ein AVR ein 
ganzes Kraftwerk? ;-)

>Jo, richtig. Aber wenn der Strom kommt soll nicht der Rest auch noch in
>den Soden verglühen…

Wurde dreimal gesagt, Failsafe Postion definieren und gut.

MFG
Falk

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
>Die Tabelle enthält ja auch Parameter, die es
>gestatten, dass sich der Schaltbefehl "irgendwo befinden darf.
Ich denke mal das ist dein Grundproblem welcher es dir sehr schwer macht 
den richtigen Schaltzustand zu finden. Eine Strukturierung wäre da recht 
hilfreich. Eben wegen deiner "Unordnung" kannst du nur auf "==" testen 
und du findest das davorliegende aber relevante Ereignis nicht. Ein "<=" 
wie ich es mache geht leider nur wenn sortiert ist. Egal wann sortiert 
wird.
Habe jetzt nochmal ne ganze Zeit drüber nachgedacht, die einzige Art wie 
du mit deinen wirren Daten erneut zu einem aktuellen Ausgangsstatus 
kommst, ist jene wie sie Herr Buchegger und Herr Dannegger beschrieben 
haben. Du musst wirklich für jede Sekunde deine Tabelle durchackern....
-3 Tage Stromausfall ...das kann dauern. Ist übrigens auch eine Art des 
Sortierens.

Viel Erfolg, Uwe

Ach übrigens die Meldung
>lese, schwillt mir der Kamm.
sollte sich auf Falks geistreichen Beitrag:

> Es fehlt mir aber hier der
>entscheidende „Kick“, der richtige Einfall.

>Nimm C. ;-)

beziehen. Oder war da etwar Vitamin C gemeint?

Der Rest des Textes war nur ein wenig ungünstig angeordnet und sollte 
auf keinen Fall gegen C an sich gehen.
Ich will es mal noch etwas anders darstellen.
Wenn ich kein Ahnung von chinesisch habe und benutze einen Translator 
zum übersetzen einer deutschen Bauanleitung ins chinnesische, wird dann 
der Chinese das tun was ich wollte?

Einfach nur mal so für sich drüber nachdenken...

schönen Abend noch, Uwe

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

>Ich würds auch nicht sekündlich ablegen, sondern nur dann wenn ein
>Schaltzyklus anfällt. Du wirst ja nicht jede Sekunde was schalten
>müssen. Und im Grunde brauchst du ja für einen Neuaufsatz nur die Zeit,
>wann zuletzt was geschaltet wurde. Wenn an deiner Steuerung die nächsten
>2 Stunden nichts geschieht ehe der Strom ausfällt, ist es doch beim
>Neustart belanglos, ob du diese 2 'stillen' Stunden noch ein 2-tes mal
>im Schnelldurchgang durchsimulierst oder nicht. Aber dein EEPROM (oder
>was auch immer) wird es dir mit verlängerter Lebendsdauer danken, wenn
>du ihm etliche Schreibzyklen ersparst.

Tja, habe ich auch lange drüber nachgedacht. Aber dann fehlt mir der 
Failsave-Zeitstempel, wenn ich nicht sekündlich speichere. Dies stört 
mich auch überhaupt nicht, solange ich nicht mit EEPROMs arbeite. Ich 
habe im Übrigen kein AVR. Wer redet davon? Ich kann zwar sehr wohl den 
Syntax nachvollziehen und auf meinem 80C537er umdenken und anwenden  - 
jedoch nicht jedes dieser hier besprochenen Features hat dieser Kerl zu 
bieten. Bitte auch keine Grundsatzdiskussionen über den Prozessortypen 
in diesem Thread. Das ist so und ICH kann damit prima leben. Als 8051er 
hat er auch genügend Derivate usw. Wir sind eben Freunde!

Das Schnellsimulieren habe ich gestern als eigenen Programmblock zum 
Laufen bekommen. Ich kann nunmehr einen Monat (...und dies wird 
normalerweise dicke reichen!) durchlaufen. Hierfür brauche ich nicht 
einmal eine Minute. Zur Zunahme der Zeitverzögerung bei voller 
Schalttabelle kann ich im Moment nichts sagen. Das ist vollkommen ok, da 
ja auch diese Zeit hinten drangestellt wird. Über eine weitere Abfrage 
könnte ich rein theoretisch den Scanvorgang auch für längere 
Außerbetriebszeiten lösen (neu beginnen oder gesamte Zeit seit dem 
letzten Betrieb). Will ich aber mal lieber nicht. Ich muss nur noch mal 
ein bisschen überlegen, wie ich um die Monate der Sommer- 
Winterzeit-Umstellung klar komme.


Falk wrote:

>Für einen der "effizent in ASM programmiert" und dessen
>"Strukturierarbeit sich wie ein roter Faden durchs Leben zieht" bist du
>reichlich begriffsstutzig . . .

>Ab und an mal den Rechner ausschalten und an die frische Luft gehen.

Hm, den Tipp mit dem Rechner ausschalten finde ich gut!

Ich bin gerne mal begriffsstutzig. Bislang glaube ich aber, Falk, dass 
ich nicht alleine bin:
>Wurde dreimal gesagt, Failsafe Postion definieren und gut.

Nichts ist gut! Failsafe kennt mein Prozz nicht. Erst softwaremäßig habe 
ich in etwa sowatt wie ein clock monitoring erreichen können.



uwe wrote:

>Ich denke mal das ist dein Grundproblem welcher es dir sehr schwer macht
>den richtigen Schaltzustand zu finden. Eine Strukturierung wäre da recht
>hilfreich. Eben wegen deiner "Unordnung" kannst du nur auf "==" testen
>und du findest das davorliegende aber relevante Ereignis nicht. Ein "<="
>wie ich es mache geht leider nur wenn sortiert ist. Egal wann sortiert
>wird.
>Habe jetzt nochmal ne ganze Zeit drüber nachgedacht, die einzige Art wie
>du mit deinen wirren Daten erneut zu einem aktuellen Ausgangsstatus
>kommst, ist jene wie sie Herr Buchegger und Herr Dannegger beschrieben
>haben. Du musst wirklich für jede Sekunde deine Tabelle durchackern....
>-3 Tage Stromausfall ...das kann dauern. Ist übrigens auch eine Art des
>Sortierens.

>Viel Erfolg, Uwe

Jo, Uwe, danke dir! Ich habe den genialen Vorschlag von Herrn Buchegger 
weiter aufgegriffen und   - so ist es nun einmal -  den Rechner über 
Nacht eben doch EINgeschaltet gelassen... die Scanroutine 
(Schnelldurchlauf) ist fast fertig und ich bin über den geringen 
Mehraufwand deutlich zufrieden. Momental läuft dies als Simulation  - 
noch nicht in dem Programmteil der Uhr. Es wurde im Thread nur immerzu 
der selbe Gedankenansatz verwendet: Ich habe keine gewöhnliche Schaltuhr 
(wollen), sondern eine, die eben auch jeden x-beliebigen Termin 
wahrnehmen kann und ein Höchstmaß an Ausfallsicherheit bietet. Das mit 
der Ausfallsicherheit und dem Nichtzulassen eines Akkus machte die Sache 
zum Alleinstellungsmerkmal  - zugegeben, nicht gerade der einfachste 
Weg. Dies erklärt auch den Einsatz einer Industrie-Funkuhr, die eben 
keine Synchronisation im tagesweisen Rhytmus macht und auch u.a. dafür 
ein paar Cent teurer war. HOPF konnte mir aber auch kein vergleichbares 
Komplettsystem anbieten. Für eine Versuchsreihe im Freifeld brauche ich 
aber so eine Uhr. Es geht dabei um viel Geld und um ein Höchstmaß an 
Sicherheit  - wenn der Strom da ist.

Mit Failsafe sichern und aufrufen habe ich bis jetzt nicht begriffen. 
Wie auch? Ich muss meinen Tabellenbestand mit den vergangenen (und eben 
auch allen möglichen!) Zwischenzeiten seit des Ausfalls überprüfen. Die 
Zwischenzeiten müssen somit generiert werden! Ein noch nicht gelöstes 
Problem sind nunmer die Ausfallmomente um die 
Sommer-Winterzeit-Umstellung herum. Aber auch hier könnte ich ja 
schlimmstenfalls großzügig und überlappend scannen lassen (die Tage der 
Umschaltung haben kein regelmäßiges Datum, da immer Sonntag). Einmal mit 
Sommerzeit (auch auf die Gefahr hin, dass es um eine Menge paradoxische 
Daten geht) und einmal mit Winterzeiteinstellung. In der Schalttabelle 
können diese Paradoxa nicht auftreten, da ich sie mit dem 
gregorianischen Kalender und einem darauf aufbauenden Algorithmus 
herausfiltere. Diesen Ansatz bekomme ich aber beim besten Willen nicht 
auch noch für den Schnelldurchlauf hin. Zumal ich noch nicht weiß, wie 
lange ich eigentlich eine Ausfallzeit wirklich rückabwickeln will. Im 
Moment bewege ich mich schon weit über das reale Maß meiner jetzigen 
Anwendung hinaus. Ich rechne eigentlich nur mit kurzzeitigen 
Stromausfällen von maximal ein paar Stunden. Jedoch darf mir dadurch 
kein Chaos entstehen.
Dein Ansatz, Uwe, mit <= war auch meine erste Überlegung, bevor ich mich 
im Internet und schließlich hier einfand, ist eben auch nicht einfach. 
Weiter oben beschrieb ich es mit dem Carry-Bit. Da es eben micht nur die 
Einer und Zehner der Sekunden, Minuten und Stunden sind, wird das ganze 
auch recht komplex. Es gibt ja die Möglichkeit, z.B. nur freitags oder 
nur einmal im Jahr usw. zu schalten. Ferner, die Sache mit 
Sommer/Winter... Das über einen Softwarekomparator laufen zu lassen, ist 
möglicherweise doch sehr sehr viel aufwändiger als das generieren 
(triviale Hochzählen) der Zeit mit Datumsnachführung. Ich habe mich 
vorerst für diese zweite Variante entschieden und danke allen, die mich 
wieder in die richtige Richtung lenkten ganz herzlich. Dennoch würde ich 
für jeden weiteren Einfall gerne Vorhandenes revidieren/probieren. Das 
mit dem Sortieren ist schier unmöglich und aus meiner Sicht unnütz. Die 
würde allenfalls ein Performance-Problem lösen  - sowatt habe ich nicht 
(zu befürchten). Der Anwender soll über Display einfach weitere 
Schaltzeiten eingeben können  - von mir aus, bis der Speicher grunzt. 
Auch logische Verknüpfungen innerhalb der Schaltprozesse sollen möglich 
sein (wenn Sommer, dann 12.00 Uhr, wenn Winter, 17.00 Uhr und nur 
freitags...).
In der Tabelle werden Marken angelegt für den Kanal, für den 
Schaltzustand, eine für eine Adresse zum Hinterlegen eines 
Kommentartextes (16 Zeichen). Ich kann nach diesen Marken suchen und 
diese auch anzeigen (auf LCD und am PC natürlich auch) bzw. editieren. 
Das ist für mich erst einmal ok so. Ein neuer Schaltwert wird immer in 
die vorletzte Zeile eingefügt (letzte besteht aus Ende-Zeichen (für den 
Vergleichsvorgang). Das Löschen kann ebenfalls am Gerät über die selbe 
Anwahl erfolgen.
Also, ich ahne es dennoch, es bleibt noch eine Baustelle...
Allen erst einmal einen verdienten Feierabend und Gruß

ToM

Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dr. ToM wrote:

> habe im Übrigen kein AVR. Wer redet davon?

Daher ist es immer schön, wenn man das gleich zu Anfang selber sagt.

> Ich kann zwar sehr wohl den
> Syntax nachvollziehen und auf meinem 80C537er umdenken und anwenden  -
> jedoch nicht jedes dieser hier besprochenen Features hat dieser Kerl zu
> bieten. Bitte auch keine Grundsatzdiskussionen über den Prozessortypen
> in diesem Thread. Das ist so und ICH kann damit prima leben. Als 8051er
> hat er auch genügend Derivate usw. Wir sind eben Freunde!


Man kann AVR-Code schnell in 8051 umwandeln und umgekehrt, die sind sich 
ziemlich ähnlich.
Anbei mal die Uhrenroutine, die Du ja für Dein "Schnellsimulieren" 
brauchst, umgeschrieben.
Sie ist leicht größer (88 Byte), da ich nicht wußte, ob Du noch ne 
Registerbank frei hast. Mit Registern wirds etwas kleiner als beim AVR.


Es würde mich mal interessieren, wie groß Dein Code schon ist, ich 
vermute mal, schon etwas über 4kB.

Ich hab früher auch viel aufm 8051 in Assembler gemacht. Die 8051 ohne 
Flash habe ich allerdings kaum verwendet, das Platine layouten war mir 
zu umständlich. Seit 1993 gibts ja die Atmel 8051 als Flash.


Peter

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Peter,

naja, ich erachtete es in der Tat als nicht so wichtig, mit welchem 
Prozessor mein Problem lösbar ist. Mir ging es ja mehr oder weniger um 
einen logischen und möglichst effizienten Lösungsansatz, der mir einfach 
nicht so recht in den Sinn kommen wollte. Ja, den Code von AVR setze ich 
gerne und ohne Probleme um. Ist eben ein beliebter Controller und somit 
wird natürlich auch viel über und für ihn publiziert. Deine Uhrenroutine 
lade ich mir mal runter und schaue sie mir heute in der Mittagspause mal 
an :-).
Die gesamte Uhrensoftware liegt tatsächlich derzeit bei 4k. Allerdings 
sind auch noch längst nicht alle Menüpunkte implementiert. Auch fehlt 
jetzt noch der Schnelldurchlauf. Diesen habe ich ja vorerst als 
eigenständiges SW-Modul  - ohne DCF-Anbindung -  laufen. Tja, der 80537 
ist ohne RAM/ROM. Schon deswegen habe ich auch mit Lithiumzellen so 
meine Bedenken, da externe Speicher und in meinem Fall auch noch einige 
8255er versorgt werden wollen...

Sag mal, Peter, ich fragte schon weiter oben: Gibt es erst zu nehmende 
Alternativen zum FRAM?

ToM

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter, exakt!
Mehr ist es in der Tat nicht. Ich habe den Schnelldurchlauf ganz an den 
"Anfang" gesetzt. Dieser greift  - genauso wie die DCF-Abfrageroutine - 
auf die Tabelle zu. Um zu verhindern, dass es zum Schalten (Aufflackern) 
kommt, habe ich einfach eine virtuelle Kanalnummer angesteuert  - 
solange sich das Programm in diesem Scanprozess befindet.

Meine Erfahrungen beim ersten Implementieren in das Hauptprogramm werde 
ich gerne hier erläutern. Habt erst einmal herzlichen Dank für die 
vielen Denkanstösse. Besonderen Dank an Karl Heinz, Du hattest diesen 
Ansatz als erstes eingebracht und meine Zellen reanimiert...
Wenn Interesse besteht, stellle ich auch gerne den ganzen Quellcode ein. 
Nur, vorsicht, ist natürlich schon ziemlich spezifisch geworden (und 
noch geplant). Wobei die HOPF-Karte sicherlich das kleinste Problem ist. 
Einen String bekomme ich ja auch mit Conrad-DCF-Empfängern softwaremäßig 
generiert. Die Anwendung meiner Schaltuhr liegt im wissenschaftlichen 
Bereich und ist eine wichtige "Teilmenge" meines Forschungsvorhabens 
geworden. Mehr kann ich im Moment nicht zur Anwendung sagen. Ist aber 
nichts militärisches oder sonstwie übles. Nur meine Anforderungen 
richten sich gerne an Mil-Normen  - so auch auf die verwendeten Bauteile 
-und gruppen. Soll eben watt ordentliches werden...

Die kommenden zwei Wochen bleibt mein Rechner aus dienstlichen Gründen 
ausgeschaltet. Ich wünsche  allen Beietiligten gesegnete Ostertage und 
vielleicht auch geruhsame Stunden mit etwas weniger geöffneten Tasks...

ToM

Autor: picbastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ToM, mir ist beim Lesen aufgefallen, dass du unter "failsafe" 
vermutlich etwas anderes verstehst als Falk - zumal du gelegentlich auch 
"failsave" schreibst.

Falks "failsafe position": für jeden Kanal ist grundsätzlich eine 
Position festgelegt, auf die er gehen soll, wenn der STrom wiederkommt. 
Diese "failsafe position" wird im Betrieb nicht mehr geändert.

ToMs "failsave": vor dem "fail" ein "save", d.h. es wird jeweils die 
aktuelle Position gespeichert.

Nur zum besseren Verständnis... oder sehe ich das falsch?
Ulrich

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  picbastler (Gast)

>Nur zum besseren Verständnis... oder sehe ich das falsch?

Das siehst du vollkommen richtig.

MFG
Falk

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @  picbastler (Gast)
>
>>Nur zum besseren Verständnis... oder sehe ich das falsch?
>
> Das siehst du vollkommen richtig.

Und so seh ich das ebenfalls:

Eine gespeicherte Position, die im Fehlerfall (fail) als sichere 
Position (save) angesehen wird und daher eingenommen wird. Eben ein 
failsave - Wert.

Anderes Beispiel: Viele Modellbau-Empfänger bzw. Servos erlauben 
mitlerweilse die Definition eines failsave Wertes. Fällt das 
Sender-Signal aus, so geht das Servo in eine definierte sichere 
Position. Bei einem Flugzeug könnte das dann sein: Gas weg, Seitenruder 
leicht nach links, Höhenruder auf Gleitflug. Der Flieger versucht 
dadurch bei einem Ausfall des Fernsteuerungssignals eigenständig 
zumindest so zum Boden zu kommen, dass nicht allzuviel passiert. Und das 
ist allemal besser, als wie wenn er mit halbvollem Tank eigenstabil ein 
paar Kilometer über Wald und Flur ins nächste Gebäude kracht.

Autor: Dr. ToM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Ulrich, moin Falk,

exakt! Ich habe diese Funktion Failsafe offenbar missgedeutet und das 
"f" eher als "Schreibfehler" abgetan. Ich habe also tatsächlich soetwas 
wie eine failsave eingesetzt. Es wird die letzte funktionierende 
Zeitmarke (mit Datum etc.) festgehalten. Mit failsafe hingegen kann ich 
mir  - nachdem Ihr mich aufgeklärt habt -  aber dennoch nicht viel 
anfangen. Die Uhr stürzt zu 99,9% immer im Pollingbetrieb (Durchsuchen 
der Schaltzeiten in der Tabelle) ab. Die 0,1% des Interruptaufrufs der 
sekündlichen Hopfkarte ist da hingegen verschwindend gering und 
insgesamt betrachtet nicht wirklich wichtig. Das Wiedereinschalten des 
Stromes (...und hierzu gehören auch die angeschlossenen und zu 
steuernden Anlagenteile) werden ja vorerst vermieden und auch erst nach 
Verifikation mit dem nicht geschalteten (stromlosen) Zeitraum. Ich lasse 
diese Überprüfung auch nach dem "Ersteinschalten" zu. Zu überlegen ist 
nur, ob ich in der Anzeige soetwas wie "überspringen?" unterbringe und 
damit auf Tastendruck diesen Scan überspringen kann. Soweit funktioniert 
es nunmehr auch schon in der Theorie... nach den letzten goldwerten 
Überlegungen von Herrn Buchegger wird es auch bestimmt praxistauglich.
Nun, nachdem ich wieder im Lande bin, werde ich mich mal wieder um das 
Programmieren kümmern. Im Sommer wollte ich mit der ersten Versuchsreihe 
im Freifeld anfangen...

Eure vielen Hinweise waren mir sehr wichtig und hilfreich.

Besten Gruß
ToM

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.