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
Soll es ein Einzelstück oder eine Serie werden? Stromversorgung vom Kfz-Akku? Was bist du denn grob bereit auszugeben? mfg Esko
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
> Es könnten dann leicht 10 Geräte werden.
die dann natürlich ein clubkollege Nachbaut ,um kosten zu Sparen.
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.
Na für einen Hobby-Progger ist das ein interessantes Projekt und dafür auch noch 150 Euro zu bekommen wäre nicht schlecht.
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
>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
@ 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
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
@ 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
Hallo, als Anregung...wäre da ein GPS Modul keine Alternative? Zeit und Ort bestimmen?
> 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.
@Falk, du scheinst ja fix zu sein, hast schnell mal was guenstig zusammengekloppt. Kann man dich chartern ?
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.
@ 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
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
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.
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.
Angehängte Dateien:
-
MINIATM4.JPG
160 KB
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
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.
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
@ 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
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
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
@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#EEPROM_Schreibzugriffe_minimieren 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
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.
@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?
@ 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
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
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.
> 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. ...
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
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
@ 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
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
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
@ 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
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
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
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.
@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.
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
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.
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
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
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.
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.
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
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.
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
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...
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
@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
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
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…
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
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
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.
@ 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
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
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
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
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
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
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
@ picbastler (Gast)
>Nur zum besseren Verständnis... oder sehe ich das falsch?
Das siehst du vollkommen richtig.
MFG
Falk
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.
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
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.