Miniprojekt Tonnen-Blinker Unsere Stadtwerke scheinen ganz auf unsere Gesundheit bedacht zu sein. Wie sonst ist es zu erklären, daß wir mittlerweile im Schnitt alle 2,5 Tage irgendeine Mülltonne zur Straße bringen müssen, oder zurück. Die denken echt ich leide an Bewegungsmangel ;-) Regelmäßig wird hier auch nix mehr abgeholt. Mal Montag, mal Dienstag, mal Mittwoch... das kann sich kein Schwein merken. Für sowas gibt’s bestimmt 'ne „Händie Äpp für's Ei-Phhone“ die einen erinnert, aber dann vergißt man's sicher doch wieder wenn man grad sowieso aus der Bude geht und Zeit/Lust hätte die Tonnen rauszugurken. Daher werde ich mir die nächsten Tage einen kleinen Bilderrahmen oder sowas in der Art suchen und meinen „Tonnen-Blinker“ dort reinfummeln. Das Teil wird dann im Flur neben das Schlüsselbrett gehängt und wenn ich eh raus gehe sehe ich dann ob heute oder morgen Müll abgeholt wird. Aus meiner Grabbelkiste habe ich geborgen: einen ATMega8, ein RTC-Modul mit DS3231 und vier verschiedenfarbige LEDs (eine für jede Mülltonne). Schaltung und Software im Anhang, falls es wer nutzen will oder als Ideenvorlage. Falls morgen eine Mülltonne abgeholt wird, leuchtet die entsprechende LED, falls heute eine Mülltonne abgeholt wird, blinkt die entsprechende LED, denn es ist höchste Eisenbahn, falls die Tonne noch nicht an der Straße steht. Definiert wird alles in der „config.h“ Dort muß man sich eine Tabelle erstellen die die Abholdaten beinhaltet. Dazu muß man sich ein halbes Stündchen hinsetzten und seinen „Abholkalender“ erstellen. Zum kompilieren hab ich den „avr-gcc (GCC) 4.8.2“ genutzt. Das RTC-Modul mit dem DS3231 hat eine Batterie eingebaut. Somit läuft die Zeit auch bei Stromausfall weiter. Das ist auch nötig, da ich keine Bedienelemente vorgesehen habe mit denen man die Zeit/Datum einstellt. Die Startzeit wird ebenfalls in der „config.h“ definiert und zu dieser Zeit muß das Gerät dann (nachdem der AVR gebrannt ist) mit gestecktem Jumper eingeschaltet werden. Dann wird Uhrzeit/Datum aus dem AVR in den DS transportiert und die RTC ist gestellt. Alle LEDs blinken dann und das Gerät muß ausgeschaltet werden (Uhr läuft durch Batterie auf dem Modul weiter) Jumper dann entfernen und das Teil ist vorbereitet zum normalen Betrieb... Einfach wieder unter Strom setzten (ohne Jumper). Im Normalbetrieb holt sich der AVR ca. jede Stunde das aktuelle Datum vom DS3231 ab und steuert die entsprechenden LEDs an. NICHT berücksichtigt ist die Zeitumstellung ME(S)Z. Die eine Stunde die das Gerät dann falsch geht, kann ich verschmerzen, denn wichtig ist ja nicht die genaue Zeit sondern das aktuelle Datum.
Nettes Projektchen für "Verweigerer moderner Technik" ("Händie Äpp") die
allerdings schon so modern sind, das Ihnen der klassische Papierkalender
doch etwas zuuu "oldschool" ist. :D
:
Bearbeitet durch User
Oliver S. schrieb: > Einer der wenigen sinnvollen Skills: > > https://www.amazon.de/Mankei-Abfallkalender/dp/B06XVYJMLM Sinnvoll? Höchstens für die Leute die dich ausschnüffeln. Dann schon lieber ein Miniprojekt wie oben. Nebenbei: tut es auch ein ATTiny13A?
Jaja, ich hab auch so nen Abholkalender in Papierform. Da steh ich allerdings immer mit Fragezeichen über'm Kopf davor. :D Fünf verschiedenfarbige Spalten pro Monat mit Ziffern und Buchstaben drinne wo man hin und her suchen muß. Geht das als Ausrede durch? Vorletztes Jahr war das noch einfach... ganz ohne Kalender Müllabholung immer Dienstags. Sniff schrieb: > Nebenbei: tut es auch ein > ATTiny13A? Mit ner Menge an Anpassungen vielleicht. Momentane Codegröße für Mega8 = 1188 Bytes Davon 432 Bytes Abfuhrtabelle im Flash Das Uhrenmodul hat neben der RTC noch einen EEPROM vom Typ 24C32 (4096 Bytes) drauf. Da könnte man sich seine Abfuhrtabelle unterbringen und kommt dann auf eine Codegröße von 756 Bytes. Allerdings hat der Tiny13A kein TWI-Interface (oder hab ich das übersehen?) I2C Kram müßte dann in Software abgewickelt werden, was den Code wieder vergrößert. Codegröße kann man noch einsparen wenn man statt 4 LEDs nur eine nimmt und/oder statt die LEDs am Vortag der Abholung + am Tag der Abholung anzusteuern, sich auf einen Tag beschränkt.
Dominik S. schrieb: > Nettes Projektchen für "Verweigerer moderner Technik" ("Händie Äpp") die > allerdings schon so modern sind, das Ihnen der klassische Papierkalender > doch etwas zuuu "oldschool" ist. :D Zielgruppe erkannt ;-) Wobei ich noch ergänzen muß: Oder für Deppen wie mich, die mit dem Papierkalender nicht klar kommen. Vielleicht sollte ich doch mal wieder zum Optiker.
Tja hier im Landkreis bekommt man vom Landratsamt eine Kalenderdatei zum herunterladen und im Thunderbird einbinden, in der die Termine stehen. Dafür wurde aber das Thema Müll auch teuerer, nach dem es natürlich groß hieß, das alle sparen werden, wenn der Landkreis die Entsorgung organisiert.
Schönes Projekt. Man muss das Gerät ja nicht unbedingt für sich slebst bauen, es gibt in jeder Familie auch weniger technikaffine Menschen. Oder bei Mehrfamilienhäusern kann man es ggf. auch ins Treppenhaus hängen.
Thomas G. schrieb: > Fünf verschiedenfarbige Spalten pro Monat mit Ziffern und Buchstaben > drinne wo man hin und her suchen muß. Geht das als Ausrede durch? Bei unseren Stadtwerken kann man sich per Mail benachrichtigen lassen. Da kommt dann am Vorabend immer eine Nachricht "morgen wird Ihre $wasauchimmer$-Tonne geleert".
soul e. schrieb: > Bei unseren Stadtwerken kann man sich per Mail benachrichtigen lassen. > Da kommt dann am Vorabend immer eine Nachricht "morgen wird Ihre > $wasauchimmer$-Tonne geleert". Auch ne gute Sache, allerdings brauch ICH dann doch nen Hinweis (Arschtritt) zur RICHTIGEN Zeit. Idee war ganz einfach: Morgens Schuhe anziehen, Jacke greifen, Schlüssel nehmen ab zum Auto... Moooment - da blinkt ne LED, jetzt aber fix die Tonnen raus. Alles andere sind tatsächlich Ausreden für meine Faulheit, Trägheit, Vergesslichkeit, Bequemlichkeit, Blindheit oder sonst was. Für mich persönlich ist das DIE ultimative Erinnerungshilfe genau wenn ich sie brauche. (Naja Praxistest abwarten ;-) Hat halt so jeder seine Methode wie man hier so liest: Mail, Alexa, Papierkalender, App. usw.
Thomas G. schrieb: > soul e. schrieb: >> Bei unseren Stadtwerken kann man sich per Mail benachrichtigen lassen. >> Da kommt dann am Vorabend immer eine Nachricht "morgen wird Ihre >> $wasauchimmer$-Tonne geleert". > > Auch ne gute Sache, allerdings brauch ICH dann doch nen Hinweis > (Arschtritt) zur RICHTIGEN Zeit. > Idee war ganz einfach: Morgens Schuhe anziehen, Jacke greifen, Schlüssel > nehmen ab zum Auto... Moooment - da blinkt ne LED, jetzt aber fix die > Tonnen raus. > > Alles andere sind tatsächlich Ausreden für meine Faulheit, Trägheit, > Vergesslichkeit, Bequemlichkeit, Blindheit oder sonst was. > Für mich persönlich ist das DIE ultimative Erinnerungshilfe genau wenn > ich sie brauche. (Naja Praxistest abwarten ;-) > Hat halt so jeder seine Methode wie man hier so liest: Mail, Alexa, > Papierkalender, App. usw. Ich finde dein (Wochenende?) Projekt super! :) Braucht keine Email, keine Alexa, keine anlogen Kalender, kein Internet. Gegen Emails, digitale Kalender usw. ist man eh schon "immun". Ich würde das ggf. "nachbauen" als Geschenk für jemanden. Mit kleinen Veränderungen und Modifikationen. Allerdings habe ich noch etwas Bedenken, was den Hunger des Stromverbrauch angeht. Wieviel mA verbraucht deine Schaltung mit einer blinkenden und dauerleuchtenden LED? Wie lange halten die Batterien durch oder versorgst du deine Schaltung über dem Schlüsselbrett mittels Steckdose und USB-Adapter? Ein Bild von deiner noch nicht finalen Version im Bilderrahmen wäre auch toll. :)
:
Bearbeitet durch User
H. E. schrieb: > Allerdings habe ich noch etwas Bedenken, was den Hunger des > Stromverbrauch angeht. > > Wieviel mA verbraucht deine Schaltung mit einer blinkenden und > dauerleuchtenden LED? Wie lange halten die Batterien durch oder > versorgst du deine Schaltung über dem Schlüsselbrett mittels Steckdose > und USB-Adapter? Ich bin zwar nicht der TO, aber kann dir deine Bedenken nehmen: Ein AVR braucht ca. 5-10mA, je nachdem wie viel er tut und welcher genau es ist. Im Sleep wesentlich weniger. Aber selbst mit 10mA ist man bei 50mW. Mit einem Schaltnetzteil (Meanwell bsp.) ist man wohl noch unter 100mW an der Steckdose. Wenige Cent pro Jahr, die wirlich niemanden stören.
Man habt ihr Probleme! Aber die Idee zur Lösung derer finde ich gut ;) PS: Hier kommt der Müllmann immer Donnerstags. Außer bei Feiertagen, da verschiebt sich die Woche um einen Tag. Alle 2 Wochen kommt Hausmüll, dann im Wechsel Altpapier und Gelber Sack. Und wir haben auch nur eine Tonne und zwar für Hausmüll. Ganz simpel. Und immer gegen 6:15 Uhr, pünktlich wie ein Uhrwerk.
Hier in Berlin könnten sich die Jungs gar nicht leisten, irgendwann zu kommen, damit würden sie so durcheinander kommen, das gar nichts mehr klappt. Ausserdem pflegt die BSR eine Website, bei dem man sich für jede einzelne Adresse und Hausnummer die kommenden Termine anschauen oder downloaden kann.
H. E. schrieb: > Allerdings habe ich noch etwas Bedenken, was den Hunger des > Stromverbrauch angeht. Die Frage beschäftigt mich auch gerade. Idee: Arduino mit E-Ink Display. Das braucht ja statisch überhaupt keinen Strom. Da kann man den Arduino stundenlang schlafen legen. Eine LED, die kurz aber hell aufblinkt, könnte auch lange funktionieren, das müsste man mal genauer untersuchen.
Für Batteriebetrieb hab ich nix optimiert, da eh Strom in der Nähe ist. Mal gemessen: 8mA alle LEDs aus, 13mA alle an. Auf dem DS-Board ist noch ne LED die dauernd an ist und bei dem Teil hab ich gesehen daß man dessen 32kHz Ausgang abschalten kann, was beides vielleicht noch ein wenig einspart. Wieviel weiß ich ned. Für Stromsparvariante könnte man allerdings vom DS-Modul die Alarmregister nutzen... RTC Alarm=nächster Abfuhrtag, AVR tiefschalf legen wenn heute keine LED an ist.... AVR wird am Abfuhrtag vom DS aufgeweckt. Glaub über Signal SQW/INT vom DS-Board sollte das gehen. Wenn heute Abfuhr ist, LEDs kurz flashen (50-100ms) halbe Sekunde pause und wieder von vorn, wenn morgen Abfuhr flashen und Sekunde Pause. Oder ganz auf einen der Modi verzichten.
https://www.mymuell.de/download.html Ist ganz praktisch, gerade jetzt, wenn die Tannenbäume abgeholt werden.
Da meine Nachbarin jetzt auch so ein Blinkteil haben wollte, mußte ich mich noch mal hinsetzten und ihre Wünsche berücksichtigen. Sie wollte: - Am Vortag der Abholung blinkende LEDs - Am Tag der Müllabfuhr LEDs aus - Einen „Ja laß mich in Ruhe ich hab die Tonnen rausgebracht – Taster“ um die LEDs auszuschalten - Batterieversorgung Daher ist's jetzt mit einem ATTiny24 gemacht. Und die Abfuhrtabelle ist vom Flash ins EEPROM des DS3231-Boards gewandert. - Einmalig Board mit dem AVR und Gedöns, LEDs basteln - Jährlich zu Jahresbeginn Abfuhrkalender erstellen - DS-Board vom AVR-Teil trennen - Abfuhrdaten ins EEPROM des DS-Boards schreiben (EEPROMMER für I2C EEProms muß vorhanden sein). Im EEPROM gleich die Zeit/Datum speichern zu welchem der ganze Kram dann eingeschaltet wird (Stellt die Uhrzeit der RTC) - Alles wieder verbinden - Taster drücken, Strom einschalten, Taster 5 Sekunden gedrückt lassen ---> Uhrzeit/Datum der RTC wird gestellt auf Daten aus EEPROM - Kurz wieder vom Strom trennen und ohne Tasterdruck wieder einschalten - Falls im Jahresverlauf Batteriewechsel nötig ist, läuft das DS-Board mit seiner Uhrenzelle weiter, also einfach Hauptbatterie wechseln und ohne Tasterdruck wieder einschalten Software läuft jetzt so: Jeden Tag zur selben Uhrzeit wird der AVR vom DS3231 geweckt. AVR prüft ob LEDs geschaltet werden müssen... Falls NEIN, wird der AVR wieder schlafen gelegt Falls JA, werden die LEDs angesteuert bis: - der Nutzer den Taster drückt (LEDs aus, AVR geht wieder schlafen) - sich das Datum geändert hat , dann werden die LEDs weiterhin passend zum Datum gesteuert bis Tastendruck oder gehen ganz aus (falls keine LED Daten für diesen Tag) - AVR schlafen legen Vom DS-Board habe ich die Power-LED abgefummelt, was 2 mA dauerhaft einspart. Stromverbrauch wenn der AVR schläft ca. 3 mA, wenn LEDs angesteuert werden ca. 6-8 mA. Was bei mir an ca. 150 Tagen im Jahr der Fall ist. Rest kann jeder selber ausrechnen. Mit im Anhang: - Software im Quellcode und kompiliert als Variante mit blinkenden LEDs und einmal Variante wo die LEDs dauerhaft an sind, wenn die Müllabfuhr kommt. - Datei „Abfuhrkalender.ods“ in welcher man sich (mittels Libre Office Calc) einen Abfuhrkalender basteln kann, und dort gleich die Daten für's EEPROM erzeugt werden. Software für den ATTiny24 belegt ca. 800 Bytes, sollte somit auch in kleinere Modelle passen. Im EEPROM des DS-Boards liegen 390 Byte Daten für Abfuhrtabelle und Zusätzliches.
Matthias S. schrieb: > Hier in Berlin könnten sich die Jungs gar nicht leisten, irgendwann zu > kommen, damit würden sie so durcheinander kommen, das gar nichts mehr > klappt. > > Ausserdem pflegt die BSR eine Website, bei dem man sich für jede > einzelne Adresse und Hausnummer die kommenden Termine anschauen oder > downloaden kann. Naja - wenn's exklusiv die BSR wäre, ist es aber nicht. Die gelben Säcke werden teilweise von Alba abgeholt, und die haben bei uns monatelang die Abholkalender als frei interpretierbare Empfehlung gesehen. Die Füchse und Krähen haben mit der Entsorgung dann schon mal angefangen... Papier kann man von Alba, Berlin Recycling, Veolia und wahrscheinlich noch weiteren abholen lassen. Und die Verschiebung bei Feiertagen macht auch jeder Entsorger anders. Mir fehlt daher noch eine App, in die man mehrere Entsorgungskalender gefiltert importieren kann. Die derzeit funktionierende wird manuell gefüttert und besteht aus Papier...
Matthias L. schrieb: > Die gelben Säcke werden teilweise von Alba abgeholt, und die haben bei > uns monatelang die Abholkalender als frei interpretierbare Empfehlung > gesehen. Das ist wahr - da hilft aber auch der Müllblinker nicht mehr. Matthias L. schrieb: > Die Füchse und Krähen haben mit der Entsorgung dann schon mal > angefangen Jo, da sahen die Strassen dann entsprechend aus. Die Tiere sind ja nicht dumm. Veolia hält ja jetzt bei den Papiertonnen auch zu allen Seiten die Hände auf. Geld fürs Abholen und dann Geld fürs Verkaufen. Nicht schlecht, wenn man sich erstmal mit kostenlosen Papiertonnen den Markt gesichert hat...
Thomas G. schrieb: > alle 2,5 Tage irgendeine Mülltonne zur Straße bringen müssen Verleitet mich dazu, die Tonnen gleich da stehen zu lassen. BTW finde ich das von den Müllwerkern immer sehr gelungen, dass man in den Orten erstmal komplett ab 6 Uhr die Hauptstrasse abklappert und blockiert. Alternativ ist man da auch um 17Uhr unterwegs. Damit auch ja immer ALLE Pendler davon betroffen sind. -statt erstmal in den Wohnstrassen anzufangen.
● J-A V. schrieb: > Thomas G. schrieb: >> alle 2,5 Tage irgendeine Mülltonne zur Straße bringen müssen > > Verleitet mich dazu, die Tonnen gleich da stehen zu lassen. Da kann ich mir vorstellen daß das 1-2 Wochen gut geht und dann gibt's nen netten Brief von der Gemeinde: "Ihre Mülltonnen blockieren dauerhaft öffentlichen Grund" oder sowas in der Art. Am Besten noch mit Ordnungsgeld ;-)
Thomas G. schrieb: > Stromverbrauch wenn der AVR schläft ca. 3 mA, wenn LEDs angesteuert > werden ca. 6-8 mA. IHMO, sind da noch 2-3 Größenordnungen an Optimierungspotential im Schlafmodus.
µA schrieb: > IHMO, sind da noch 2-3 Größenordnungen an Optimierungspotential im > Schlafmodus. Wo du Recht hast, hast du Recht! Ein Fehler ist mir bei der Tiny24-Variante noch unterlaufen: Im Anhang der Version ist ein Bild/Anleitung zum Umbau des DS3231-Boards (Lötbrücken setzten). Dabei hab ich natürlich nicht bedacht, daß dadurch an den Pull-Ups auf dem Board massig Strom "verheizt" wird. Also die Lötbrücken weglassen und das Board im Originalzustand lassen (ggf. Power-LED entfernen). Da man sich das EEPROM auf dem Board eh selber füllen muß, sollte man sich dann die Slave-Adresse des EEPROMS notieren/rausfinden. OHNE Lötbrücken ist (bei mir) die Adresse = 0b1010110X (X = R/W Bit). --- Eigentlich hatte ich ohne Lötbrücken "1010|111|X" erwartet!? Naja egal. Danach im Quellcode Datei "at24c32.c" oben ändern: #define AT_I2CADR_R 0b10100001 #define AT_I2CADR_W 0b10100000 auf: #define AT_I2CADR_R 0b10101101 #define AT_I2CADR_W 0b10101100 bzw. seine ermittelte Slave-Adresse dort eintragen. Neu compilieren, fertich. Danach Stromverbrauch für ganzen Kram (Tiny + DS-Board): 3-5 mA wenn die LEDs blinken. 200 µA wenn der AVR schäft (Alle LEDs aus)
Die Idee ist gut! Thomas G. schrieb: > Software für den ATTiny24 belegt ca. 800 Bytes, sollte somit auch in > kleinere Modelle passen. Im EEPROM des DS-Boards liegen 390 Byte Daten > für Abfuhrtabelle und Zusätzliches. Einziges Manko: man braucht einen Zugriff (Programmer) für das EEPROM im DS-Board. Was nimmst du da? Wäre doch sicher auch möglich, einen Tiny84 (512 Byte EEPROM) zu nehmen und in dessen EEPROM die Daten abzulegen - oder übersehe ich was? Da könnte man ohne extra Programmer mit dem Atmel Studio die Daten programmieren. Oder halt im Progmem wie in V1, neu übersetzen ist ja auch kein Act und ob Tiny 24 oder 84 - den Euro kann man sich schenken. BTW: du besuchst dann mindestens einmal, kurz nach Neujahr, deine Nachbarin und implementierst in deren Exemplar den neuen Abfallkalender?
Hmm, also ich weiß ja nicht. Wenn man mit den Papierkalender schon nicht klar kommt, wie bringt man dann die Daten in das Programm? Sinn würde es (wenn überhaupt) nur machen, wenn man das auch mit den Wecker koppelt, der dann 5min früher bimmelt. Mit einem ESP, der sich die Daten aus dem Internet holt, fände ich das Ganze etwas interessanter...
HildeK schrieb: > man braucht einen Zugriff (Programmer) für das EEPROM im > DS-Board. Bastelkram, da gehört eine SD-Karte dran, die der Benutzer am PC selbst befüllen kann.
HildeK schrieb: > Einziges Manko: man braucht einen Zugriff (Programmer) für das EEPROM im > DS-Board. Was nimmst du da? Selbstbau EEPROMMER der eh hier steht, sollte aber sicher auch mit "Feld-, Wald-, Wiesen-EEPROMMER für die I2C EEPROMS (24er) Funktionieren. Man muß nur beachten, daß nur SDA/SCL vom EERPOMMER angesteuert werden und man sich in dessen Software die Adressbits für's EEPROM selber auswählen kann. HildeK schrieb: > Wäre doch sicher auch möglich, einen Tiny84 (512 Byte EEPROM) zu nehmen > und in dessen EEPROM die Daten abzulegen - oder übersehe ich was? Neneee ist schon richtig. War nur dem geschuldet, daß der Code unter 1k sein sollte... und wenn eh schon auf dem DS-Board ein EEPROM "rumgammelt". Für mich ist das dann auch komfortabler, da ich eh 2-3 DS-Boards rumliegen habe... Also am Jahresanfang ein "neues" DS-Board nehmen, Abfuhrtabelle drin speichern, rüber zur Nachbarin, das alte DS-Board aus ihrem Teil gegen das neu tauschen, Tasse Kaffee als Bezahlung einnehmen und Ende.
Manfred schrieb: > Bastelkram, da gehört eine SD-Karte dran, die der Benutzer am PC selbst > befüllen kann. Richtig! - Was anderes als "Bastelkram" ist das nicht. Ich hatte nicht den Anspruch ein Gerät für den "normalen Markt" zu machen ;-) Ebensowenig Lust noch Dateisystemkram für SD-Kartenzugriff zu fummeln. Sollte so wenig wie nötig "Arbeitsaufwand" sein.
Thomas G. schrieb: > noch Dateisystemkram für SD-Kartenzugriff zu fummeln Schon klar, würde vmtl. garnicht in Deinen Tiny passen. Du erinnerst mich gerade daran, meine Liste auszudrucken, die dann in den Küchenkalender geklebt wird.
@ Thomas G. Das ist doch mal ne gute Idee. Ich bin nämlich auch so ein "vergesser". /* stelle dann nach ein paar Metern Fahradfahrt fest, uuups, die XYZ-Tonnen stehen draussen. Zurückfahren iss nich, weil keine Zeit mehr. */ Ich würde das auch gleich zweimal aufbauen. Einmal für mich persönlich und einmal für meine Vermieterin. Vielleicht kann ich damit punkten. ;-) Was mich aber interessiert, welches DS3231-Modul hast Du da verwendet? Da scheint es ja mehr als eins zu geben. Gruss Asko
Angehängte Dateien:
-
NullChip_Reminder.jpg
16 KB
Thomas G. schrieb: > Sollte so wenig wie nötig "Arbeitsaufwand" sein. Mein NullChipReminder war bisher die schnellste Lösung am Müllkalender.
Asko B. schrieb: > Was mich aber interessiert, welches DS3231-Modul hast Du da verwendet? > Da scheint es ja mehr als eins zu geben. Die sind alle relativ gleich. Keine Ahnung mehr wo ich meine genau her habe. Guck auf den Bildern in den Anhängen wie die Dinger aussehen, dann dürfte's schon passen. Guck daß die Anschlüsse (Namen Reihenfolge) so sind wie bei meinem Modul und daß im Artikeltext noch sowas steht wie: "24c32 EEPROM mit auf Platine" und darauf achten, daß auf dem Modul noch ne Kopfzelle untergebracht ist.
Finale Tiny24-Version hab ich mal auf github hochgeladen, damit ich wenigstens ein µC Projektchen dort hab. https://github.com/thgoso/muell-blinker Neu ist wieder eine config.h wo man sich alles einstellen kann. U.a. kann man dort wählen ob die Daten im EEPROM auf dem DS-Board, dem AVR-Flash oder (bei größeren Typen) im EEPROM des AVR gespeichert werden sollen. Da kann man seine Tabelle ggf. gleich einfügen. Weiter hab ich das Statusblinken noch angepaßt, sodaß die Fehlersuche vielleicht etwas erleichtert wird: - Alle LEDs blinken schnell = Zeit nach 5-Sek. Tasterdruck gesetzt - LED0 & LED1 blinken schnell = Fehler beim Zugriff auf RTC DS3231 - LED2 & LED3 blinken schnell = Fehler beim Zugriff auf EEPROM AT23C32 (Falls diese Variante kompiliert) Nach dem Einschalten (ohne Tasterdruck) werden jetzt Datum und Zeit angezeigt in der Form: LED0 = 5x blink, LED1 = 2x blink, LED2 = 15x blink, LED3 = 12x blink Es ist der 5. Februar 15:12 Uhr Noch ein kleines Bash-Script womit man sich aus der Abfuhrtabelle im CSV-Format eine Intel-Hex Datei basteln kann, falls man Variante "Daten im AT24C32" gewählt hat und der EEPROM-Brenner dieses Format will. Blinky hat 'n Gehäuse bekommen... Batteriehalter fehlen noch. Fertich, Ende aus.
Thomas G. schrieb: > Nach dem Einschalten (ohne Tasterdruck) werden jetzt Datum und Zeit > angezeigt in der Form: > LED0 = 5x blink, LED1 = 2x blink, LED2 = 15x blink, LED3 = 12x blink > Es ist der 5. Februar 15:12 Uhr Viel Spaß beim Ablesen an Silvester ;) Hätte es nicht ein klitzekleines LCD getan? Oder das ganze mit einem größeren Kalender? Oder auch was ähnlich der Wordclock?
Schaafer Kritiker schrieb: > Thomas G. schrieb: >> Nach dem Einschalten (ohne Tasterdruck) werden jetzt Datum und Zeit >> angezeigt in der Form: >> LED0 = 5x blink, LED1 = 2x blink, LED2 = 15x blink, LED3 = 12x blink >> Es ist der 5. Februar 15:12 Uhr > > Viel Spaß beim Ablesen an Silvester ;) > > Hätte es nicht ein klitzekleines LCD getan? Oder das ganze mit einem > größeren Kalender? Oder auch was ähnlich der Wordclock? An Silvester, Mitte Dezember denk ich "dies' Jahr nemme". ;) Die Datumsfunktion ist nice to have und schießt ja eh schon über das eigentliche Ziel hinaus, dann doch lieber ein sprechender Bilderrahmen. :D
H. E. schrieb: > Die Datumsfunktion ist nice to have und schießt ja eh schon über das > eigentliche Ziel hinaus Ist auch kein "Feature" sondern nur zum evtl. Fehler eingrenzen. Sieht man eh nur wenn man neue Batterien einsetzt. Wenn das Gerät sonst am "Saft hängt" gibt's die Anzeige auch nicht. Wie das ganze andere Statusgeblinke nur zum Fehler finden nutzt.
Angehängte Dateien:
-
Muelltonne_Schematics.png
100 KB
Ich habe mir auch ein paar Module mit dem DS3231 / 24C32 beschafft - mit dem Ansinnen ähnliches zu bauen wie Thomas G. und ein Prototyp liegt inzwischen vor. Dazu habe ich noch einige Bemerkungen bzw. Bericht über meine Variante: - Den Speicherinhalt im 24C32 habe ich invertiert abgelegt, damit: schnellers Schreiben, weniger 'Abnutzung' und die Daten werden bei LEDs nach VCC direkt angezeigt. Unbedeutend. - die Backupbatterie war bei meinen Modulen mit dabei, eine CR2032. Damit sollte man das Modul besser nicht an 5V hängen. Es ist zwar eine Diode + 200R von VCC_Modul zu VBATT zum 'Laden' vorhanden, aber 3 AAA für VCC_Modul führen dann zu einem 'Ladestrom' von 6mA-7mA. Ob das der CR2032 was ausmachen - k.A., es ist aber zumindest Verschwendung, wenn man das Teil mit drei AAA betreiben will. Ich habe die CR2032 und den Batteriehalter entfernt und einen 1F GoldCap eingebaut (gut, der verteuert das Modul um 100% :-), es lagen aber noch welche in der Kiste). Das Modul darf jetzt auch problemlos mit 5V betrieben werden. Da der 32k-Ausgang nicht verwendet wird, kann man die Leiterbahn auf dem Modul auftrennen und dort die VCC_µC über eine Diode anlegen. So ist der GoldCap immer an der Hauptversorgung und ist eigentlich nur noch dazu da, bei Batteriewechsel oder während des Transports zum Laden neuer Kalenderdaten die RTC-Uhrzeit aufrecht zu halten. Für ein paar Stunden Backupzeit tut es sicher auch ein 0.1F GoldCap. - auf dem Modul sind zwei vierfache 4k7 R-Arrays. Das untere (am Platinenrand) sind die Pulls für die EE-Deviceadressen, ein R ist unbenutzt. Den kann man einfach auslöten, offen Adresseingänge sind lt. DB LOW und dürfen sein. Es muss also intern im 24C32 ein PullDown da sein, der ev. auch Strom braucht, wenn die 4k7 PUs aktiv sind. - das zweite Array trägt die PullUps für I2C und die beiden Ausgänge 32k und INT/SQW. Dieses habe ich um eine Padraster zum Boardrand verschoben, so dass INT/SQW keinen PU mehr hat. Zweck: Ich will das Modul im Wesentlichen von der Backupbatterie bzw. einem GoldCap betreiben und während der Schlafphasen die VCC_Modul abschalten. Die RTC-Uhr läuft vom GoldCap, der Alarm-IRQ kommt auch - deshalb auch das Entfernen des PU, denn der bezog sich auf VCC_Modul. Stattdessen muss ein extra PU auf µC-Seite direkt an VCC_µC gelegt werden. Ziel ist es, das RTC-Modul einfach mit einem Port zu schalten, wenn der µC durch den INT0 geweckt wurde, um dann die I2C-Kommunikation mit EEPROM und DS3231 durchzuführen. Der Grund: Gemessen habe ich eine Stromaufnahme bei VCC_Modul mit ca. 120-130µA und von der Backupbatterie jedoch nur <3µA. Es sind zwar bei beiden Betriebsarten noch kurze Stromimpulse feststellbar, jedoch: bei VCC_Modul im 1s-Raster sind es Pulse mit 10ms und ca. 200µA Stromzunahme und bei VBatt sind es ähnlich große Pulse, dort allerdings nur alle 10s mit etwa 15ms Dauer. Im Mittel ist es dann weniger als ein halbes µA bei VBatt bzw. 2..3µA an VCC_Modul. - Stromverbrauch: Annahmen für die Berechnung: Betrachtung mit LED-Strom von 10mA (je nach Typ könnten es deutlich weniger sein können) Es blinken durchschnittlich weniger als zwei LEDs pro Woche (bei uns), Berechnungsgrundlage: 2 LEDs/Woche Tastverhältnis LED-Blitzen: 1/16 Berechnung mit der maximalen Blinkzeit von 10h, als gäbe es nie eine Quittung; Praxis: eher max. 2h-3h/Tag, dann Quittung Nachschauen durch Tastendruck oder bei Quittung: ca. 4 mal pro Woche (200/Jahr) für 2s - 2 LEDs (20mA + 120µA Modulstrom + 220µA µC) blinken max. 10h/Tag (14:00 Uhr - 24:00 Uhr), Tastverhältnis 1/16 an 52 Tagen/a (einmal/Woche): ca. 660mAh (bei Qittung nach <3h: ca. 200mAh) - beim Tastendruck (2s/Tag an 200 Tagen = 400s/a, 2 LEDs zus. 20mA + 3mA Pullup- µC- u. Modulstrom): ca. 2.6mAh - Prozessor (Power Down + tägliches Aufwachen ohne Alarm) und Uhrenmodul (Batterie) ohne Alarm: 3µA Dauerstrom --> ca. 26mAh im Jahr Damit in Summe: Stromverbrauch ca. <700mAh pro Jahr, Batterielebensdauer AA) 2...3 Jahre, mit AAA >1 Jahr! Bei Quittung innerhalb 3h: 230mAh; AA gut für 6-8 Jahre, mit AAA rund 4 Jahre. ABER: je nach LEDs kann man nicht bis zu 2.7V Entladung runter gehen (0.9V/Zelle), dann leuchten die nicht mehr :-)! - Zum Stellen der RTC und zum Laden des Kalenders habe ich ein zweites µC Board gefädelt, den Code meiner DCF-Uhr hergenommen und um I2C Routinen erweitert. Es wird die DCF-Zeit empfangen und nach Verifkation die RTC gestellt. Mangels Programmiertool für das EEPROM des RTC-Moduls wird das auch über diesen µC erledigt. Zunächst werden die Daten mit dem AVR Studio in das µC-eignene EEPROM geschrieben und nach dem Setzen der Zeit auf den 24C32 der RTC kopiert. Es ist eleganter, die Daten im EE des RTC zu halten, denn das Modul ist mit Steckkontakten versehen und kann so leicht vom Müllkalender-µC-Board abgenommen werden, um die Daten im Folgejahr zu aktualisieren. Dabei wird dann auch die RTC neu gestellt. Dauert halt 2-3 Minuten. - mit einer Taste kann ich sowohl den Alarm quittieren (wie gehabt) als auch jederzeit per Tastendruck die LED-Anzeige aktivieren. - Die Sommerzeit/Winterzeitumstellung kann man auch berechnen und muss nicht jährlich neu abgespeichert werden. Der Einfachheit halber wird nur die Alarmzeit im Sommer um +1h angepasst, die RTC läuft auf MEZ weiter. Nach https://electronicfreakblog.wordpress.com/2014/03/06/die-zeit-im-sommer-und-im-winter/ umgesetzt: (RTC_time ist ein Struct mit Uhrzeit und Datum, bei mir global definiert)
1 | uint8_t check_summer_time (void) |
2 | {
|
3 | // Bestimmt den Tag der Sommerzeit- bzw. Winterzeitumstellung
|
4 | |
5 | uint8_t dday = bcd_to_dez(RTC_time.day); // Für Arithmetik ist eine Umrechnung notwendig - für Vergleiche nicht |
6 | uint8_t wday = (RTC_time.wday); // RTC liefer Mo...So -> 1...7 |
7 | uint8_t mesz=0; |
8 | |
9 | if (wday == 7) wday = 0; // für wday muss 0=So, 1=Mo ... 6=Sa, bei RTC_time.wday ist aber So=7 |
10 | if ((RTC_time.month < 0x03) && (RTC_time.month > 0x10)) mesz= 0; // MEZ Wintermonate |
11 | if ((RTC_time.month > 0x03) && (RTC_time.month < 0x10)) mesz= 1; // MESZ Sommermonate |
12 | if ((RTC_time.month == 0x03) && ((dday - wday) >= 25)) mesz= 1; // MESZ |
13 | if ((RTC_time.month == 0x10) && ((dday - wday) < 25)) mesz= 1; // MESZ |
14 | return mesz; |
15 | }
|
Im Anhang der Schaltplan, der nur dann brauchbar ist, wenn man die beschriebenen Modifikationen am RTC auch umsetzt. C4 soll zur Kontaktreinigung beitragen. Über D2 kann der µC auch von einer Taste geweckt werden, um die Anzeige für den aktuellen Tag kurz einzuschalten Über D1/R13 wird der GoldCap geladen über den zweckentfremdeten Pin "32K" Die LED-Vorwiderstände muss ich noch an die Helligkeit der gerade eingekauften LEDs anpassen.
HildeK schrieb: > Über D2 kann der µC auch von einer Taste geweckt werden, um die Anzeige > für den aktuellen Tag kurz einzuschalten Das gefällt mir! Werd ich bei mir auch mal nachrüsten, denn im praktischen Betrieb steh ich jetzt manchmal vor'm nicht blinkenden "Blinky" und frag mich: "Wie heute echt nix abzuholen? Lebst du noch oder hast dich aufgehangen, geht's dir gut?" ;-) Nur halt beim Tasterdruck kurzes Blinken zum quittieren, daß er noch "lebt" HildeK schrieb: > Es ist eleganter, die Daten im EE des RTC > zu halten, denn das Modul ist mit Steckkontakten versehen und kann so > leicht vom Müllkalender-µC-Board abgenommen werden, um die Daten im > Folgejahr zu aktualisieren. Da will/muß wohl noch jemand die ganze Straße/Verwandtschaft versorgen. Edit/PS: Bei mir im git-repro ist nun noch ein kleines Bash-Script um sich die EEPROM-Daten aus einer ics-Datei (die es vielleicht auf der Webseite des entsorgers gibt) zu erzeugen.
:
Bearbeitet durch User
Thomas G. schrieb: > HildeK schrieb: >> Es ist eleganter, die Daten im EE des RTC >> zu halten, denn das Modul ist mit Steckkontakten versehen und kann so >> leicht vom Müllkalender-µC-Board abgenommen werden, um die Daten im >> Folgejahr zu aktualisieren. > Da will/muß wohl noch jemand die ganze Straße/Verwandtschaft versorgen. Da bin ich einzig deinem Vorschlag gefolgt - bisher weiß noch niemand in der Straße/Verwandtschaft von dem Vorhaben :-). Außerdem fehlt mir einfach ein Tool, um das 24C32 direkt zu beschreiben. Sorry - so wie ich es schrieb sieht es so aus, als ob es meine Idee war. Es ist aber eindeutig deine gewesen! > Edit/PS: > Bei mir im git-repro ist nun noch ein kleines Bash-Script um sich die > EEPROM-Daten aus einer ics-Datei (die es vielleicht auf der Webseite des > entsorgers gibt) zu erzeugen. Ja, da hatte ich mir ein C Programm auf dem PC geschrieben, das die ics-Datei durchforstet, die Daten extrahiert und in das vorgesehene Intel-Hex-Format bringt. Thomas G. schrieb: > Nur halt beim Tasterdruck kurzes Blinken zum quittieren, daß er noch > "lebt" Das sollte ich auch noch nachrüsten :-). Ich wollte eigentlich nur schon vor der Alarmzeit und ggf. nach der Quittung mal nachschauen können, was heute anliegt/anlag.
??? schrieb: > Du hast aber einen komischen Kalender mit mehr als 12 Monaten. > 0x10 != 10 Hast du in der Schule nicht aufgepasst? 0x10 könnte BCD sein. https://www.sps-lehrgang.de/bcd-code/
Karl schrieb: > ??? schrieb: >> Du hast aber einen komischen Kalender mit mehr als 12 Monaten. >> 0x10 != 10 > > Hast du in der Schule nicht aufgepasst? 0x10 könnte BCD sein. Richtig, es ist packed BCD, wie auch im Kommentar des Beispiels bzw. der verwendeten Funktion "bcd_to_dez" und ggf. auch im Datenblatt des DS3231 zu finden wäre.
HildeK schrieb: > Sorry - so wie ich es schrieb sieht es so aus, als ob es meine Idee war. > Es ist aber eindeutig deine gewesen! Kein Problem! Ich bin nicht eitel. ;-) Dirk B. schrieb: > Bei http://www.zabex.de/site/muellerinnerung.html gibt es auch eine > Müllerinnerung Die Umsetzung sieht auch interessant aus. Hatte also doch schon jemand das Problem vor mir (gelöst).
??? schrieb: > Entschuldigt bitte tausend mal, aber BCD hatte ich total verdrängt. Kein Problem, wir haben dich hier nur ein wenig erhellt :-). Thomas G. schrieb: > Die Umsetzung sieht auch interessant aus. Ja, aber davon würde mir grauen - die Mechanikarbeiten, oh je ... :-)
Hallo, Ein für mich interessantes Projekt.... aber wie schon geschrieben zu kompliziert für den unerfahren Bastler. Meine Vorstellung wäre: Das ganze für einen Atiny85 umschreiben um es au einen Chip zu bekommen. Da dazu meine Kenntnisse nicht reichen, ein paar einfache BASCOM Sachen geht noch, frage ich in die Runde ob sich jemand findet der das Prg. entsprechend umschreibt? Ich habe z.B. Den Programmer von MyAVR und mit diesem wäre das brennen für mich sehr leicht. Es mag sein das für viele Elektroniker das programmieren mit einem I2C EEPrommer keine Schwierigkeit ist, aber ich konnte nichts finden wie man(n) mit dem Prg. so einen EEProm beschreibt. Und Beiträge wo es teilweise beschrieben ist sind von 2006 und früher. Ich hoffe ich habe das Problem verständlich beschrieben. Also alles in einen ATTiny85 und programmieren in ein Rutsch wäre ein feine Sache. Mit freundlichem Gruß Hans-Ulrich
Mit einem Tiny85 hast du das Problem, dass der nicht genügend Pins hat. Deshalb habe ich den 861 genommen. (Preisunterschied waren 5ct vom 261 zum 861). Vier oder fünf Müllarten und sowie 2 Pins für die I2C-Kommunikation mit dem Uhrenbaustein, dann noch Stromversorgung, Quittungstaste und Resetpin ... Zähle selber .... Und wenn du die Kommunkation mit dem Uhrenbaustein erledigt hast (Such mal nach einer Lib von Peter Fleury), dann ist auch die Kommunikation mit dem EEProm kein Problem mehr. Nur eine andere Adresse und andere Daten ... Allerdings: mit BASCOM kann ich dir nicht helfen, Fleury hat in C und Assembler geschrieben. Ich hab zum Laden der Daten (und zum Testen während der Entwicklung) ein kleines Board gefädelt mit dem ich EEPROM-Daten vom 861 auf das Uhrenmodul kopieren kann. Die HW ist fast die selbe ... Ich hab das so gemacht: - mit einem C-Programm auf dem PC den Outlook Kalenderfile durchforstet und die Daten in einen File im Intel-Hex-Format geschrieben. - den dann auf das EE des Testboardprozessors geladen - das Progamm auf dem Testboardprozessor kopiert diese Daten dann in das EE des RTC-Moduls und stellt auch gleichzeitig die RTC-Uhr (habe eine Ankopplung an meine DCF77-Uhr). - dann wird das Modul einfach in das eigentliche Prozessorboard vom Müllkalender kopiert.
Hans-Ulrich schrieb: > Es mag sein das für viele Elektroniker das programmieren mit einem I2C > EEPrommer keine Schwierigkeit ist, aber ich konnte nichts finden wie > man(n) mit dem Prg. so einen EEProm beschreibt. Du mußt ja nicht zwangsweise den I2C-EEPROM brennen. Dazu hab ich doch extra bei meinem Code die config.h eingefügt. Nimm wie ich nen Tiny24. Erstelle dir mit der Abfuhrkalender.ods deine Daten. (Fleißarbeit) config.h öffnen, Zeile 39 abändern auf "FROM_FLASH_AVR" Drunter dann deine Daten aus der Abfuhrkalender.ods einfügen. Compilieren, fertig. (Abfuhrdaten liegen dann NICHT im externen EEPROM, sondern im Flash des AVR) DU mußt dann halt jährlich den Code neu compilieren und AVR brennen. Ich spar mir das jährliche neu compilieren und muß nur den EEPROM brennen.
Thomas G. schrieb: > DU mußt dann halt jährlich den Code neu compilieren und AVR brennen. Sein Problem ist eher, dass er mit BASCOM arbeiten will und auch da die Kenntnisse nur rudimentär sind. Aber, das wäre eine gute Gelegenheit, sich mal mit C zu beschäftigen ...
Ich hatte's ehr so verstanden, daß er nicht mit dem EEPROM rumfummeln will sondern alles auf'm AVR haben möchte und Bascom nur im Zusammenhang nannte, weil er da eben mal fix was selbst ändern könne, statt sich mit dem C-Code "runzuärgern". Wobei den anzupassen ja auch nicht vieler Kenntnisse bedarf. Daher hat's mich gewundert, daß er schrieb das wäre alles zu kompliziert. Das Interesse sich bei so kleinen Projekten in fremden Code einzuarbeiten um größere individuelle Anpassungen vorzunehmen ist eh meist gering und läuft (bei mir zumindest) sowieso immer drauf raus, daß man's selbst noch mal neu programmiert.
Thomas G. schrieb: > und läuft (bei mir zumindest) sowieso immer drauf raus, daß > man's selbst noch mal neu programmiert. Ja, so hab ich es mit deinem Code auch gemacht ... :-) Für die Anregungen bin ich aber trotzdem dankbar! Thomas G. schrieb: > Ich hatte's ehr so verstanden, daß er nicht mit dem EEPROM rumfummeln > will Mir ging es zunächst auch so. Aber zu Beginn eines Jahres nur das DS-Modul zu tauschen, hat mich überzeugt. Und die I2C-Kommunikation mit dem RTC war ja sowieso erforderlich, also war die Kommunikation mit dem EEProm als Abfallprodukt zu sehen.
Hallo Elektroniker, ich danke ! euch für eure Antworten. Nein, ich habe nur einfache Erfahrungen mit BASCOM. Für mehr reicht es nicht :-( und als Rentner noch C lernen das wird nichts. Ich habe es schon mal versucht, aber C nein ! Thomas G. schrieb: > Ich hatte's ehr so verstanden, daß er nicht mit dem EEPROM rumfummeln > will sondern alles auf'm AVR haben möchte weil für mich die Programmierung des AVR leichter ist. Schon gemacht… Thomas G. schrieb: > Du mußt ja nicht zwangsweise den I2C-EEPROM brennen. Dazu hab ich doch > extra bei meinem Code die config.h eingefügt. > Nimm wie ich nen Tiny24. > Erstelle dir mit der Abfuhrkalender.ods deine Daten. (Fleißarbeit) > config.h öffnen, Zeile 39 abändern auf "FROM_FLASH_AVR" > Drunter dann deine Daten aus der Abfuhrkalender.ods einfügen. > Compilieren, fertig. (Abfuhrdaten liegen dann NICHT im externen EEPROM, > sondern im Flash des AVR) Entschuldigung, aber in dem Projekt mit dem Attiny24 fehlt die config.h. ich habe keine Datei mit diesem Namen im Verzeichnis gefunden. Und mit welchem Compiler wird dann neu programmiert ? Müsste ich mich auch erst einarbeiten. Die "Fleißarbeit" zum erstellen der Daten ist nicht das Problem … Also Jungs ihr lest wie es bei mir bestellt ist. Ich habe zwar Spaß am basteln, aber dieser ganze Programmierkram wie C, Assembler usw. ist nichts für mich. Ich hab da mal einem Freak über die Schulter geschaut… ????? Böhmische Berge Vielen Dank, vielleicht kann mir Thomas G. meine Fragen noch beantworten, dann werde ich weiter sehen… Frohes Schaffen !
Hans-Ulrich schrieb: > Entschuldigung, aber in dem Projekt mit dem Attiny24 fehlt die config.h. > ich habe keine Datei mit diesem Namen im Verzeichnis gefunden. > Und mit welchem Compiler wird dann neu programmiert ? Müsste ich mich > auch erst einarbeiten. > Die "Fleißarbeit" zum erstellen der Daten ist nicht das Problem … Thomas hat das in Thomas G. schrieb: > Finale Tiny24-Version hab ich mal auf github hochgeladen, damit ich > wenigstens ein µC Projektchen dort hab. > https://github.com/thgoso/muell-blinker veröffentlicht. In dem zip ist alles drin, auch die config.h. Nur nicht das Binary, um es einfach ohne Änderung zu programmieren. Also, den fertigen Code mit den Einstellungen "FROM_EEPROM_AVR" müsstest du selbst kompilieren. Dazu muss eben vorher in config.h die Zeile
1 | #define DATA_LOAD FROM_EEPROM_AT24C32
|
in
1 | #define DATA_LOAD FROM_EEPROM_AVR
|
geändert werden. Wenn du die Möglichkeit hast, die Müllkalenderdaten in das EEPROM eines Tiny zu programmieren, dann brauchst du statt dem Tiny24 den Tiny84. Nur bei dem ist das EE groß genug, man braucht knapp 400Byte. Er ist sonst aber kompatibel, außer dem Flash, das ist auch größer. Hans-Ulrich schrieb: > Nein, ich habe nur einfache Erfahrungen mit BASCOM. Für mehr reicht es > nicht :-( und als Rentner noch C lernen das wird nichts. Ich habe es > schon mal versucht, aber C nein ! Gut, das kann ich zwar verstehen, auch ich will keinen Assembler mehr lernen. :-) Aber, gerade als Rentner hat man doch Zeit, oder nicht? (Ich bin in wenigen Wochen auch einer ...). Aber für das Projekt wäre es am Einfachsten, wenn du die Möglichkeit hättest, einen bestehenden C-Code geringfügig anzupassen, zu kompilieren und in einen Tiny zu brennen. Ich fürchte, du wirst kaum jemanden finden, der den Code von Thomas in Bascom umschreibt. Ich könnte es mal versuchen, ein Tiny84-Binary mit der obigen Option zu erstellen, kann dir aber nichts garantieren.
@Hans-Ulrich (Gast) HildeK schrieb: > Ich könnte es mal versuchen, ein Tiny84-Binary mit der obigen Option zu > erstellen, kann dir aber nichts garantieren. Ich hab es versucht, es hat auch funktioniert, nur nützt es dir nichts: die Kalenderdaten sind eincompiliert und dann hättest du den Kalender von Thomas G. Trotzdem: falls du was zum Testen benötigst, dann hänge ich das gerne noch an. Testen konnte ich es allerdings mangels HW nicht. Zum Ändern/Anpassen auf deine eigenen musst du zwangsläufig einen C-Compiler anwerfen ...
Ich brauche auch so etwas. Ich denke an den Müll, gehe aus dem Haus und wenn ich zurückkomme, denke ich wieder an den Müll. Zwischendrin gehe ich 2x an den Mülltonnen vorbei und vergesse den Müll. Aber ich werde wohl eher einen ESP8266 nehmen, in der witty cloud Ausführung.
Thomas G. schrieb: > vier verschiedenfarbige LEDs (eine für jede Mülltonne Super Sache, wo kann ich denn eine braune und eine graue LED kaufen?
Beitrag #6422559 wurde vom Autor gelöscht.
>Ich brauche auch so etwas.
Das war jetzt schon wichtig, dass du das nach über 2 Jahren Pause noch
gesagt hast. Gut. Gerade noch rechtzeitig.
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.