Hallo zusammen, mein Name ist Milos ich komme aus der Schweiz und bin neu hier :) Ich studiere zurzeit Maschinenbau und habe ein kleines Projekt am laufen, was für mich absolutes Neuland ist. Ich habe im Studium Python programmieren gelernt (Basic und Advanced). Mit dem Thema Micro Controller haben wir uns leider nie beschäftigt. Ich möchte eine micro Pumpe ansteuern (3.5V) das aber immer zu einer bestimmten Zeit, ich versuche es in Worte zu fassen: -Ruhestand -Pumpe soll nach einer Zeit X die Pumpe mit Strom versorgen für eine Zeit Y -Ruhestand, wartet wieder bis Zeit X abgelaufen ist um dann wieder die Pumpe anzutreiben. Das wars eigentlich. Jetzt meine Fragen an euch Spezialisten: -Welchen Controller nehme ich da? -Ist Python hierfür geeignet? Das Pflichtenheft wäre: -Die Pumpe wird mit 3.5V betrieben -Alles wird mit einer oder evtl auch 2 Batterien bestromt (xD) -Der Microcontroller soll so günstig (nicht billig!) wie möglich sein. Wenn es möglich ist, wäre ich sehr froh auch eine Literaturempfehlung zu bekommen über dieses Thema. Bin gespannt auf eure Gedanken und Anmerkungen! :) Freundliche Grüsse Milos
Milos M. schrieb: > -Ist Python hierfür geeignet? Recht neu gibt es CircuitPython - also ja wenngleich es unüblich ist Milos M. schrieb: > Ich möchte eine micro Pumpe ansteuern (3.5V) das aber immer zu einer > bestimmten Zeit, ich versuche es in Worte zu fassen: > > -Ruhestand > -Pumpe soll nach einer Zeit X die Pumpe mit Strom versorgen für eine > Zeit Y > -Ruhestand, wartet wieder bis Zeit X abgelaufen ist um dann wieder die > Pumpe anzutreiben. Je nachdem wie genau und lang die Zeiträume sein müssen brauchst du eine RTC. Milos M. schrieb: > Alles wird mit einer oder evtl auch 2 Batterien bestromt (xD) Batterie ist ein weites Feld: von Knopfzelle bis Autobatterie (ja klar ist eigentlich ein Akku) Batteriebetrieb setzt aber einen sparsamen Mikrocontroller vorraus bzw. einen mit für deine Anwendung sinnvollen sleep modes. Milos M. schrieb: > Ich möchte eine micro Pumpe ansteuern (3.5V Wie groß ist die Stromaufnahme? Brauchst du noch Treiber? Ohne nähere Informationen wird eine konkrete Empfehlung schwierig. Allgemein würde ich einem Anfänger Arduino Empfehlen aber sleep modes zum Stromsparen wäre schön kein Anfängerthema mehr.
Danke für deine Antwort! Was die Zeitabstände betrifft kann ich keine konkrete Zahl nennen, es können für X maximum etwa 45min sein, Y ist da eher bei unter einer Minute, genaueres kann ich erst nach einem Test sagen :) Und sorry, mit Batterie habe ich mich nicht genau ausgedrückt, habe an diese Art gedacht: https://www.fzr.ch/de-product-batterie_procell_alkaline~lr_3_1_5v Frage zu dem Sleep mode: ist das etwas, was ich selbst programmieren muss oder kommt das mit dem Microcontroller? Bekannte Daten zur Pumpe sind: 4.5V, 0.18A, 0.91W ist eine China Pumpe :) Wenn du bessere Vorschläge hast, wie man das lösen könnte dann bin ich offen dafür auch wenn es etwas komplett anderes ist :) Grüsse
Sali Milos, Fuer eine vernetzte Bewaesserung habe ich die Linkit Duo 7688-module hergenommen, die waren aber in letzter Zeit nicht einfach bzw. nicht mehr so guenstig (10USD) zu bekommen. Sind aber sehr robust und haben einen Atmega drauf. Python wuerde ich allerdings nur bedingt auf dem uC laufen lassen, es gibt einige nette Referenzdesigns mit MicroPython, aber wenn das alles richtig zuverlaessig laufen soll, gibt's ein paar Fallstricke. Drum lasse ich Python lieber im User-Space und die pure Echtzeit im uC. Auf dem Linkit kannst du firmata oder netpp laufen lassen, dafuer gibt's Python-Wrapper.
Milos M. schrieb: > Bekannte Daten zur Pumpe sind: 4.5V, 0.18A, 0.91W ist eine China Pumpe Milos M. schrieb: > Ich möchte eine micro Pumpe ansteuern (3.5V) Deine Spannungsangabe zur Pumpe wiederspricht sich... Der Strom setzt auf jeden Fall einen Treiber vorraus (Relais, Mosfet etc.). Milos M. schrieb: > Und sorry, mit Batterie habe ich mich nicht genau ausgedrückt, habe an > diese Art gedacht: > https://www.fzr.ch/de-product-batterie_procell_alkaline~lr_3_1_5v Und davon 1-2? Das ergibt höchstens etwas über 3V. Bei 1200mAh ist die Betriebsdauer mit den angegebenen Einschaltintervallen auch nur wenige Wochen (ganz grob überschlagen). Milos M. schrieb: > Wenn du bessere Vorschläge hast, wie man das lösen könnte dann bin ich > offen dafür auch wenn es etwas komplett anderes ist :) Wenn die Zeitintervalle nicht so richtig genau sein müssen nimm einen beliebigen Mikrocontroller (z.B. Atmega / Attiny bzw. einen Arduino) und probiere erstmal aus.
Bei den kleinen Batterien würde ich von sämtlichen Scriptsprachen abraten. Übrig bleibt damit praktisch nur noch Bascom (Basic) oder C/C++. Der Sleep Modus muss vom Mikrocontroller und der Beschaltung drumherum unterstützt werden. Durch deine Programmierung startest du einen Timer, der den Mikrocontroller später wieder aufwecken wird und versetzt ihn dann in den Sleep Modus. Ist Dir klar, dass die Pumpe mit diesen Batterien nur wenige Stunden laufen wird? Wegen dem Sleep Modus kannst du nicht auf die üblichen Arduino Module zugreifen. Die Bauteile auf der Platine nehmen zu viel Ruhestrom auf, meist mehrere mA. Also nimmst du besser einen "nackten" Chip und einen sparsamen Spannungsregler, zum Beispiel den HT7833. Für die Verbindung zum PC brauchst du einen ISP Programmieradapter mit 3,3V Signalen (was auf die allermeisten USBASP Sticks trotz 3,3V Jumper nicht zutrifft!). Bei der Pumpe solltest du klären, ob sie für Batteriebetrieb taugt. Deine 4 Zellen haben in frischem Zustand 6 Volt. Die Spannung fällt dann aber allmählich bis auf 3,6 Volt ab. Wenn du nur 3 Zellen verwendest, geht der Spannungsbereich von 4,5 Volt bis 2,7 Volt. Du hast geschrieben, dass die Pumpe mit 3,5V betrieben wird. Aber weiter unten hast du geschrieben, dass die Pumpe für 4,5V ausgelegt ist. Wenn es wirklich fest 3,5V sein sollen, dann brauchst du für die Pumpe einen weiteren Spannungsregler, der die Batteriespannung auf 3,5V runter bringt und durch den Mikrocontroller steuerbar ist (enable Eingang). Auch da musst du wieder auf möglichst geringen Ruhestrom achten. Und bedenke, dass Motoren beim Anlaufen locker den 5 bis 10-Fachen Strom aufnehmen. Dafür sind diese Batterien meiner Meinung nach schon arg knapp bemessen. Wenn die Pumpe wegen zu wenig Batterieleistung nicht zuverlässig anläuft, besteht Gefahr, dass deren Motor durchbrennt. Dann hast du geschrieben, das das alles mit 2 Zellen versorgt werden soll. Die liefern dann aber nur 1,8 bis 3 Volt, nicht 3,5 Volt. Und da die Spannung beim Anlaufen der Motoren noch etwas absacken wird, reicht das nicht einmal, um den Mikrocontroller zu versorgen. Du brauchst dann also einen Step-Up Wandler, der die Spannung erhöht. Aber diese Wandler haben eine nicht zu vernachlässigende Ruhestromaufnahme, die für den Batteriebetrieb kontraproduktiv ist. Dazu kommt, dass sich durch die Wandlung der Eingangsstrom entsprechend erhöht. Ich schätze, dass die Pumpe beim Anlaufen rund 1A ziehen wird. Durch den Spannungswandler werden etwa 1,5A aus den Batterien gezogen. Das schaffen die nur in ganz frischem Zustand. Man kann die Batterien so gar nicht vernünftig ausnutzen. Wenn schon, solltest du unbedingt 4 Zellen Benutzen, sonst wird damit niemand glücklich. Um dich in die Thematik einzulesen, empfehle ich Dir mein Tutorial: http://stefanfrings.de/mikrocontroller_buch/index.html Viel Spaß.
Danke für deine Antwort, manchen Sachen habe ich einfach in den Raum geschmissen habe echt keinen blassen wie das alles funktioniert, aber deine Antwort hat mir sehr geholfen danke!
Ihr seid echt alle so geil! Ich danke dir dass du dir die Zeit genommen hast mir dass alles so ausführlich zu erklären, denn ich bin eine Niete was Elektrotechnik angeht. Ich werde mir mal deinen Link reinziehen und dann schauen, wie ich dass alles machen werde. Wird wohl ein steiniger Weg für einen der mit Elektrotechnik gar nicht klar kommt :) Danke nochmal!
Mach Dir nicht zu viel Gedanken wegen der Programmiersprache. Wenn du schon eine kannst, wird es Dir leicht fallen, eine weitere zu erlernen. Das nervigste an C werden wohl die vielen Klammern sein. Probiere es einfach mal aus. Kostet ja (fast) nichts.
Wenn du dir für die Pumpe einen Spannungsregler aussuchst, achte darauf, dass er - einen Enable-Eingang hat, damit du die Pumpen Ein/Aus schalten kannst - eine geringe Ruhestromaufnahme hat (Quiescent current deutlich kleiner als 100µA) - möglichst wenig Verlustspannung hat (Drop-out Voltage kleiner als 500mV) - den Anlaufstrom der Pumpe liefern kann (schätzungsweise 1 Ampere) Den Anlaufstrom kannst du grob abschätzen, indem du die Versorgungs-Spannung durch den Gleichstrom-Widerstand des Motors teilst.
Stefan ⛄ F. schrieb: > Das nervigste an C werden wohl die vielen Klammern sein. Probiere es > einfach mal aus. Kostet ja (fast) nichts. Wenn man den Code vernünftig formatiert/einrückt ist das auch kein großes Problem mehr.
Stefan ⛄ F. schrieb: > Bei den kleinen Batterien würde ich von sämtlichen Scriptsprachen > abraten. Übrig bleibt damit praktisch nur noch Bascom (Basic) oder > C/C++. Oder Assembler. Gerade solche ultrasimplen Anwendungen, die ganz überwiegend doch nur aus ein paar Registerinitialisierungen und ein wenig Pin-Geklimper bestehen, sind so weit einfacher als in jeder anderen Sprache umzusetzen, insbesondere dann, wenn man diese andere Sprache auch erst lernen muss...
c-hater schrieb: > Oder Assembler. Gerade solche ultrasimplen Anwendungen Da muss ich dir tatsächlich mal zustimmen. Auch dazu habe ich "zufällig" etwas vorbereitet: http://stefanfrings.de/avr_workshop/index.html Die Anleitung ist schon ein bisschen angestaubt, aber immer noch gültig.
Stefan ⛄ F. schrieb: > Bei den kleinen Batterien würde ich von sämtlichen Scriptsprachen > abraten. Das würde ich so pauschal nicht sagen. Es hängt davon ab, wie viel Laufzeit das Programm hat und ob man den Mikrocontroller außerhalb dieser Laufzeiten in einen Tiefschlaf versetzen kann. Wenn eine Pumpe nur alle paar Minuten/Stunden/Tage kurz angesteuert werden soll, aber das System ansonsten tief schläft (mit Microampere-Strom), dann spielt es gar keine Rolle mehr, wie "verschwenderisch" das Programm während der im Vergleich zum Schlaf kurzen Laufzeit damit umgeht. z.B. einen ESP32 mit Micropython kann man ohne weiteres sehr sparsam mit Batterie betreiben.
c-hater schrieb: > Gerade solche ultrasimplen Anwendungen, die ganz > überwiegend doch nur aus ein paar Registerinitialisierungen und ein > wenig Pin-Geklimper bestehen, sind so weit einfacher als in jeder > anderen Sprache umzusetzen, insbesondere dann, Völliger Quatsch. Aber was anderes kann man von c-hater ja nicht erwarten. Selbst ein triviales Pin-einlese-ausgabe-Programm ist in C einfacher zu lesen/schreiben/verstehen, als in jeder Asm-Sprache.
Eigentlich ist genau das meine Absicht im Projekt, dass die Pumpe etwa jede Stunde für etwa 30 Sekunden läuft und dann garnichts macht bis die nächste Stunde wieder beginnt und er dann wieder 30Sekunden pumpt.
MaWin O. schrieb: > Völliger Quatsch. Zur Diskussion, welche Programmiersprache die beste ist und wer den längsten hat, möchte ich euch bitten, einen eigenen Thread aufzumachen. Da könnt ihr dann eure Präferenzen zum gefühlten 100. mal durchkauen. Und ich bitte um Entschuldigung, dass ich euch mit meiner Bemerkung dazu angestachelt habe.
MaWin O. schrieb: > Völliger Quatsch. > Aber was anderes kann man von c-hater ja nicht erwarten. > Selbst ein triviales Pin-einlese-ausgabe-Programm ist in C einfacher zu > lesen/schreiben/verstehen, als in jeder Asm-Sprache. Du bist ein Dummschwätzer. Der Unterschied im Umfang des Quelltextes ist minimal. Und ob du nun z.B. schreibst: PORTB |= 1<<PORTB1 vs. sbi PORTB,PORTB1 Da scheint mit die Assemblervariante schon leichter verständlich zu sein, auf jeden Fall für jemanden, der weder C noch AVR8-Assmbler kann. Und wenn man die Gegenrichtung hinzunimmt: PORTB &= ~(1<<PORTB1) vs. cbi PORTB,PORTB1 dann wird es doch schon recht eindeutig, was einfacher zu verstehen ist. Für Assembler muß einfach bloß nachlesen, was sbi bzw. cbi tun und ist schon durch mit dem Thema. Bei der C-Variante muss man hingegen nicht weniger als vier Operatoren erlernen, um dieselbe primitive Funktionalität auszudrücken...
c-hater schrieb: > dann wird es doch schon recht eindeutig, was einfacher zu verstehen ist. Nö. https://www.arduino.cc/reference/de/language/functions/digital-io/digitalwrite/
MaWin O. schrieb: > c-hater schrieb: >> dann wird es doch schon recht eindeutig, was einfacher zu verstehen ist. > > Nö. > > https://www.arduino.cc/reference/de/language/functions/digital-io/digitalwrite/ Das ist NICHT C. Und es setzt ein aufgeblähtes Framework voraus. Und es ist schweinelangsam (was allerdings in der konkreten Anwendung ziemlich egal sein dürfte).
c-hater schrieb: > Das ist NICHT C. Ja doch. c-hater schrieb: > Und es setzt ein aufgeblähtes Framework voraus. Und > es ist schweinelangsam (was allerdings in der konkreten Anwendung > ziemlich egal sein dürfte). Und wo ist nun das Problem? Es ist eindeutlich besser les- und wartbar als dein Assemblyquatsch. Und es löst das Problem.
Sowas einfaches geht auch in Hardware mit zwei NE555. Und ich hätte keine Angst das man mit 1-2 V Überspannung aus Batterien einen Motor durchbrennen lassen kann.
Johannes S. schrieb: > Sowas einfaches geht auch in Hardware mit zwei NE555. Naja, im Stundenbereich wird's schon einigermaßen unbeherrschbar. Vor allem in der Nähe von (Wasser-)Pumpen, denn da ist wohl naturgegeben ein wenig Feuchtigkeit nicht weit... Für einigermaßen reprodizierbare Zeiten würde ich einen kleinen Tiny jederzeit vorziehen.
c-hater schrieb: > Für einigermaßen reprodizierbare Zeiten würde ich einen kleinen Tiny > jederzeit vorziehen. Ja, da muss ich dir zustimmen. Vor allem auch, weil diese Lösung viel flexibler ist, wenn man doch mal andere Zeiten oder Muster fahren will. Hardwareseitig ist ein kleiner Tiny auch einfacher, als irgendeine Timerlösung mit Chip, Widerstand und Kondensator.
Könnt ihr mir einen Link von einem Tiny posten? Habe keine Ahnung was das ist dann kann ich mich ein wenig einlesen
Sowas lief hier zwei Jahrzehnte als Steuerung für eine Spülung einer Umkehrosmose Anlage. In frischem Salzwasser Klima. Ich würde es aber auch mit μC machen, und auch gleich mit einem 32 Bitter :)
Milos M. schrieb: > Könnt ihr mir einen Link von einem Tiny posten? Habe keine Ahnung was > das ist dann kann ich mich ein wenig einlesen https://www.mikrocontroller.net/articles/AVR_Typen
Milos M. schrieb: > Könnt ihr mir einen Link von einem Tiny posten? Habe keine Ahnung was > das ist dann kann ich mich ein wenig einlesen Na genau der, der in meinem Buch behandelt wird: https://ww1.microchip.com/downloads/en/devicedoc/doc2535.pdf oder etwas neuer: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATtiny45-ATtiny85_Datasheet.pdf
Stefan ⛄ F. schrieb: > oder etwas neuer: Es gibt keinen Grund den Tiny13 noch in neuen Designs zu verwenden, außer vielleicht man hat noch welche da und will die verbauen. Der Tiny13 ist in allen Belangen schlechter als der Tiny25, 45 oder 85. Insbesondere auch im Stromverbrauch während des Schlafs. Was ja hier relevant ist.
MaWin O. schrieb: > Es gibt keinen Grund den Tiny13 noch in neuen Designs zu verwenden, > außer vielleicht man hat noch welche da und will die verbauen. Oder man hat eine Anleitung vorliegen, die sich auf genau den bezieht. Die kleinen feinen Unterschiede zu neueren Modellen kann man besser später herausfinden, wenn man nicht mehr am allerersten Projekt sitzt. Der ATtiny13A ist noch in Produktion. > Der Tiny13 ist in allen Belangen schlechter als der Tiny25, 45 oder 85. > Insbesondere auch im Stromverbrauch während des Schlafs. Das bezweifle ich, aber auf die feinen Unterschiede kommt es in diesem Fall sowieso nicht an. Es scheint mir hier am einfachsten, den µC einfach mit minimaler Taktfrequenz durch laufen zu lassen. Beim ATtiny13A sind das 18,75 kHz mit einer Stromaufnahme um 100µA. Beim ATtiny 25, 45 und 85 ist die niedrigste reguläre Taktfrequenz 31,250 kHz. Ich erwarte da eine Stromaufnahme um 150µA. Viel weiter runter geht es ohnehin nicht, weil ohne CPU wenigstens ein Timer laufen muss. Die Batterien würden den µC so etwa ein Jahr lang versorgen können. Die Pumpe wird hier die wesentlich kürzere Gesamtlaufzeit dominieren. Ich habe hier bewusst unterschlagen, dass man den ATtiny auch durch den sparsameren 128 kHz Oszillator (geteilt durch bis zu 256) takten kann (hmm, jetzt habe ich es doch geschrieben), und zwar aus zwei Gründen: a) Viele Programmieradapter versagen, nachdem man die Fuses so eingestellt hat b) Der 128 kHz Oszillator ist ziemlich ungenau
Stefan ⛄ F. schrieb: > Ich erwarte da eine Stromaufnahme um 150µA. Viel weiter > runter geht es ohnehin nicht, weil wenigstens ein Timer laufen muss. ja doch. Bei den neueren Typen kann man ungenutzte Peripherie abschalten. Auch die BOD kann man während des Tiefschlafs abschalten. Das macht nochmal eine Größenordnung in der Stromaufnahme aus.
Stefan ⛄ F. schrieb: > Ich erwarte da eine Stromaufnahme um 150µA. Viel weiter > runter geht es ohnehin nicht, weil ohne CPU wenigstens ein Timer laufen > muss. 6,5 µA im Deep Sleep mit Watchdog, da sind 100-150 µA unnötige Verschwendung. es kostet keine 10 min. googlen um gute Erklärungen und Beispiele für Arduino zu finden: https://www.gammon.com.au/power Ein LPC8xx braucht im Deep Power Down mit Self Wakeup nur 1,3 µA, aber den mag hier ja keiner. Die max. Sleeptime beim Atmega ist wohl 8s, da muss man doch ständig aufwachen. Der LPC kann durch den 32 Bit Timer auch tagelang schlafen.
Johannes S. schrieb: > 6,5 µA im Deep Sleep mit Watchdog, da sind 100-150 µA unnötige > Verschwendung. Wie gesagt ist der 128 kHz Oszillator recht unpräzise. Deswegen empfehle ich nicht, den Watchdog als Timer zu benutzen. Wenn du da machst, kannst du auch gleich wieder auf die Idee mit dem NE555 (bzw, der CMSO Variante davon) zurück kommen.
Stefan ⛄ F. schrieb: > Wie gesagt ist der 128 kHz Oszillator recht unpräzise. Das stimmt zwar, aber wenn's auf Genauigkeit ankommt, können die Tiny 25/45/85 auch mit einem Uhrenquarz als Taktquelle betrieben werden. > Deswegen empfehle > ich nicht, den Watchdog als Timer zu benutzen. Wenn du da machst, kannst > du auch gleich wieder auf die Idee mit dem NE555 (bzw, der CMSO Variante > davon) zurück kommen. Naja, um einiges besser als eine Lösung mit NE555 ist der WD-Oszillator immer noch.
c-hater schrieb: > Das stimmt zwar, aber wenn's auf Genauigkeit ankommt, können die Tiny > 25/45/85 auch mit einem Uhrenquarz als Taktquelle betrieben werden. Wenn man Quarzgenaue Zeiten braucht, sind diese ATtinies natürlich besser geeignet, als der ATtiny13A. Man sollte bedenken, dass auch der Quarzoszillator Strom verbraucht. Die CPU kann man schlafen legen, aber der Oszillator und ein Timer müssen weiter laufen. > um einiges besser als eine Lösung mit NE555 ist der WD-Oszillator > immer noch. Das habe ich anders erlebt. Der 128 kHz Oszillator ist enttäuschend ungenau und sehr von Temperatur und Spannung abhängig.
Johannes S. schrieb: > Die max. Sleeptime beim Atmega ist wohl 8s, da muss man doch ständig > aufwachen. Der LPC kann durch den 32 Bit Timer auch tagelang schlafen. Tja, es ging für die Anwendung aber eher um ATtinys und konkret wurde der der Tiny25/45/85 empfohlen. Und der ist diesbezüglich sehr viel flexibler. Er kann zum einen direkt mit einem Uhrenquarz als Systemtaktquelle betrieben werden und kann zum anderen diesen Systemtakt schonmal um den Faktor 256 reduzieren. Außerdem besitzt er einen Timer1, der im synchronen Modus durch 16384 vorteilen kann und natürlich dann nochmal durch 256. Macht alles zusammen quarzgenaue 0,000030517578125 Hz oder anders ausgedrückt eine Periode von 32768 s, was so ca. 9,1 h maximaler Pennpause entspricht...
Stefan ⛄ F. schrieb: > Das habe ich anders erlebt. Der 128 kHz Oszillator ist enttäuschend > ungenau und sehr von Temperatur und Spannung abhängig. Ja, der WDT-Oszillator ist extrem ungenau. Ich finde es jetzt auf die Schnelle nicht im Datenblatt, aber erfahrungsgemäß liegt die Abweichung irgendwo zwischen 10% und 20%. Je nach Exemplar, Spannung und wahrscheinlich auch Temperatur.
c-hater schrieb: > kann zum anderen diesen Systemtakt schonmal um den > Faktor 256 reduzieren. Wie geht das? Über Fuses kann man einen 8-Teiler einschalten.
MaWin O. schrieb: > erfahrungsgemäß liegt die Abweichung irgendwo zwischen 10% und 20%. der echte Manfred W. von d.s.e.-FAQ? Wow, das wäre mir einen Glückwunsch wert :) Abweichung kann der LPC8xx auch mehr, der 10 kHz low power Oszi hat 40% :) Kann aber auch extern getaktet werden. Habe mir aus Neugier mal die DS3231 angesehen, die brauchen im Standby doch auch nur 1µA und können per Alarm einen µC wecken?
Man braucht auch gar nicht an den Fuses herumfummeln, wenn man den Teiler durch 8 deaktivieren will, denn auch das geht durch Beschreiben des CLKPR Registers. Die Fuse gibt nur den Startwert beim Reset vor.
Simon schrieb: > Microphyton Für solche Aufgaben nehme ich immer Femtopython. Beispiel:
1 | while(1) { |
2 | motor_ein(); |
3 | delay_sec(30); |
4 | motor_aus(); |
5 | delay_sec(3600); |
6 | }
|
Stefan ⛄ F. schrieb: > Ich erwarte da eine Stromaufnahme um 150µA. Viel weiter > runter geht es ohnehin nicht, weil ohne CPU wenigstens ein Timer laufen > muss. Ja, die classic ATtiny sind bezüglich Stromsparen nicht der Bringer. Da muß es schon ein großer ATmega sein. Z.B. der ATmega48A braucht im Power-Save <1µA am 32kHz Uhrenquarz.
Baendiger schrieb: > Batterie ist ein weites Feld: von Knopfzelle bis Autobatterie (ja klar > ist eigentlich ein Akku) Falsch! Eine Autobatterie ist eine Batterie aus Akkuzellen.
Angehängte Dateien:
Für alle die sich mit dem Begriff "Batterie" schwer tun: Das Bild zeigt eine Batterie Munition. Der Begriff bezeichnet weder Akkus noch Primärzellen, sondern die Anordnung der Teile.
c-hater schrieb: > Johannes S. schrieb: > >> Sowas einfaches geht auch in Hardware mit zwei NE555. > > Naja, im Stundenbereich wird's schon einigermaßen unbeherrschbar. Vor > allem in der Nähe von (Wasser-)Pumpen, denn da ist wohl naturgegeben ein > wenig Feuchtigkeit nicht weit... > > Für einigermaßen reprodizierbare Zeiten würde ich einen kleinen Tiny > jederzeit vorziehen. Ja, wer es kann. Eigentlich ist ein zeitlich festes Muster die Kernaufgabe einer einfachen EEPROM-Steuerung: 1 4060 mit Quarz und ein EEPROM, z.B. 64k*8 Damit man mit einem Uhrenquarz z.B. im ms-Takt einen Kanal bis zu 64s steuern, 2 bis zu 32s … 8 bis zu einer halben Sekunde. Für jemanden ohne µController ein guter erster eigener Schritt ins digitale Zeitalter. Leider (oder zum Glück) gibt es heute keine EEPROMMER mehr, so dass der Aufwand heute größer ist als vor 20 oder 30 Jahren. Weiter Betriebsspannungsbereich (2 Batterien bis >12V), einfacher Aufbau (damals, heute ist ein Tiny kleiner als der Quarz), einfache Logik (naja, wenn Daten- als Adressbytes fungieren, wird es auch beliebig aufwändig)
A. S. schrieb: > Leider gibt es heute keine EEPROMMER meh Und leider hat der CD4060 nicht an jedem Binärteiler einen Ausgang-Pin. Das hätte ich schon oft gut gebrauchen können. Und dann hätte ich noch gerne eine Kreuzung aus CD4060 und CD4017, also einen Dezimalzähler mit Oszillator. Gerne mit mehr als 10 Ausgängen. Kennt jemand die Postanschrift vom Wunschkonzert?
was mich dann wundert, warum diese eine online fernhochschule c/c++ streicht für eine skriptsprache python...
Stefan ⛄ F. schrieb: > Kennt jemand die Postanschrift vom Wunschkonzert? https://www.deutschepost.de/de/w/weihnachtspost/weihnachtsmann-christkind/himmelpfort.html
Techniker schrieb: > was mich dann wundert, warum diese eine online fernhochschule > c/c++ > streicht für eine skriptsprache python... Weil Python einfach HIP ist ;) Wenn man es schneller und genauer braucht, dann eben kein HIP'es Produkt verwenden. Ich habe ein Feather M0 von Adafruit mit Micropython, das konnte nichtmal die Timer richtig verwenden. Zeitgesteuert geht nur wenn zwischendurch nichts anderes gemacht wird.... o/ Anselm
Angehängte Dateien:
-
IMG_20200714_141825.jpg
220 KB -
IMG_20200714_141754.jpg
240 KB
So ein kleines Update: Ich habe von Air Wick einen Duftspender gekauft, der im 6 12 und 30 min Takt einen kleinen Motor mit Strom versorgt. Motor:LFU130SA 2370-360/DV (http://szlh-motor.com/Precious-Metal-brush/LFU130SA.html) Controller: siehe Bilder Jetzt meine Frage an euch, denn ich möchte einen Prototypen bauen. Wie kann ich den Takt selber definieren und von dem vorgegebenem wegkommen? Ich möchte statt dem Takt oben z.B. 30,60 und 90min haben. ist das möglich? Jetzt ist es noch so, dass der Motor nach etwa 1sek zurückdreht, kann man das auch verlängern z.B. 15 sek? Jetzt wird eine Lebenszeit von 60Tagen angegeben, kann man das verdoppeln wenn man noch eine zweite Batterie anhängt oder lieg ich da falsch? Grüsse Milos
Diese Schaltung kannst du nicht ändern. Du müsstest sie durch eine eigene komplett ersetzen.
Ganz ehrlich... wenn du auf solche langen Laufzeiten aus so kleinen Batterien setzen möchtest, musst du dich wohl oder übel mit kleinen Mikrocontrollern befassen. Du kannst zum lernen und testen ja einen Arduino kaufen und die Pumpe über einen Mosfet z.B. BS107 ansteuern. Codebeispiele gibts dann mehr als genug im Netz wo man sich was zusammenschnipseln kann. Wenn das ganze läuft, wechselst du auf einen ATTiny mit Minimalbeschaltung siehe das How-to hier auf der Seite. Den Tiny kannst du dann auch mit dem Arduino programmieren! Was dir hier keiner abnehmen kann, ist das du dich zumindest mit den Grundlagen der E-Technik befassen musst. Da du studiert hast oder noch dabei bist kann das ja nicht so schwer sein neues zu lernen!
:
Bearbeitet durch User
yoo Danke dir! Ich will das selber machen keiner soll es für mich machen. Ich habe einfach zu viel nachgedacht was es dann für später bedeutet (Serienproduktion). ich werde mir dann mal einen Arduino ziehen und das dann versuchen. Habe ja eh Zeit bis meine mechanische Teile 3D gedruckt sind :D danke nochmals, werde mich dann auch mit der Anleitung auseinandersetzen! Grüsse
Milos M. schrieb: > yoo Danke dir! > Ich will das selber machen keiner soll es für mich machen. Ich habe > einfach zu viel nachgedacht was es dann für später bedeutet > (Serienproduktion). > ich werde mir dann mal einen Arduino ziehen und das dann versuchen. Habe > ja eh Zeit bis meine mechanische Teile 3D gedruckt sind :D > danke nochmals, werde mich dann auch mit der Anleitung > auseinandersetzen! > > Grüsse Aber heutzutage sollte doch auch im Maschinenbau etwas E Technik und etwas Informatik sein, dass ein Maschinenbauingenieur so etwas zustande bekommt? 3D Druck läuft?? Dann solltest Du mal die oben genannten/verlinkten Werke durcharbeiten. Ich glaube auch das microphyton nur hip ist, und langfristig weniger c/c++ ablösen wird. Oder wird es evtl. bald so sein, wie mit asm ? Ich habe mal asm, c/c++ gelernt und würde da lieber bleiben.
Aber heutzutage sollte doch auch im Maschinenbau etwas E Technik und etwas Informatik sein, dass ein Maschinenbauingenieur so etwas zustande bekommt? Ja, das war schon vor 35 Jahren so, wie ich bestätigen kann
meiner Meinung nach haben wir im MB Studium zu wenig IT und ELT ( in der Schweiz zumindest) zwar habe ich jetzt selbst eine Kreiselpumpe gezeichnet und das restliche Zeugs zeichne ich noch, jedoch hackts bei mir mit der Elektronik, den was bringt mir der mechanische Part, wenn kein elektrischer Part existiert..? Werde mich wohl gröber mit der elektrik auseinander setzen müssen :)
Also das zeigt mir doch, dass die Elektrotechnik, Informationstechnik und der Maschinenbau, zusammen sein sollten. In der heutigen Zeit sowieso, also Mechatronik. Überall wird man ja auch mit Englich und BWL zu geflattert, dass man da Grundlagen hat. Naja ich für meinen Teil habe zu wenig Ahnung von Mechanik und Maschinenbau, da würde ich gerne mehr von wissen wollen, auch mal für das eine oder andere etwas konstruieren können, bzw. berechnen. Gibt es da auch ein gutes Forum?
kenne gerade kein Forum, ha aber gute Literatur die evtl dich weiterbringen könnte? Welches Thema denn?
Naja so Einsteigerliteratur als Beispielt: wie ein Hebel konstruiert sein sollte, das dieser nicht abbricht bei Belastung bzw. Benutzung
Bekanntlich ist es närrisch oder zumindest wenig zielführend die Zukunft voraus sagen zu wollen. Trotzdem nehme ich das Risiko auf mich mich möglicherweise hoffnungslos zu blamieren: C/C++ wird im mC industriellen Bereich noch lange nicht umzubringen sein! Einfach darum weil viele Industrieprodukte viele Jahre an Erfahrung beinheimen die man nicht so leicht über den Haufen wirft. Dann kommt noch eine gewisse Resistenz gegen Änderung seitens der "erfahrenen" Entwickler. Die Jungen Speerwerfer kennen manchmal doch nicht ihre eigenen Grenzen so gut uns können deshalb existierenden Projekten gefährlich werden. Wenn Produkte sicherheitszertifiziert sein müssen ist das ein weiterer Grund nicht zu vorschnell auf etwas moderneres umzusteigen. Oft lohnt es sich deshalb nicht komplexe Produkte zu modernisieren und die notwendigen Kosten der Modernisierung tragen zu müssen. Gerade im Klima von zunehmenden Wirtschaftskrisen sollte man mit den Mitteln weise vorgehen und nicht mit Hochrisiko Umwegen verprassen. Auch vertraut man den kommerziellen Entwicklungswerkzeugen durch ihre langjährige Existenz und Unterstützung doch mehr als neuen unbekannten Werkzeugen die sich noch nicht wirklich im rauen Alltag bewiesen haben. Bis man neuen Werkzeugen in der Industrie vertraut muss noch viel Wasser die Elbe passieren, meinetwegen auch die Donau;-) Trotz aller Schrullen und Eigenheiten und Schwierigkeiten die C/C++ in sich beinhalten, ist der Feind den man kennt nicht so schlimm wie ein unbekannter. Abgesehen davon ist C gar nicht so schlimm wie alle tun. Man muss nur diszipliniert arbeiten. Deshalb wird C/C++ noch lange nicht entthront werden. Computersprachen kommen und gehen. In der Industrie da baut man eher auf Vertrautes auch wenn es nicht Hip ist. Und jetzt dürft ihr mir die Tür einrennen;-) Schönen Tag noch vom Murmeltier P.S. Da Murmeltiere nicht SW entwickeln brauche ich mich auch nicht zu blamieren;-)
Ein Buch das wir verwenden für die Statik ist technische Mechanik 1 und 2, vorausgesetzt wird dass man sehr fit ist in der Vektorrechnung und Integralrechnung. dort ist es super beschrieben
Murmeltier schrieb: > C/C++ wird im mC industriellen Bereich noch lange nicht umzubringen > sein! Dieser Einschätzung würde ich mich anschliessen. > Dann kommt > noch eine gewisse Resistenz gegen Änderung seitens der "erfahrenen" > Entwickler. Jepp. Das ist ein sehr großes Hindernis bei der Einführung von etwas Besserem, wobei Python im hardwarenahen Bereich keinesfalls etwas Besseres sein kann, das hat dort als Interpretersprache einfach nix zu suchen. Da wäre eher Rust ein Kandidat für die Ablösung von C/C++. Das kann alles, was C/C++ auch können, schneidet aber die historisch gewachsenen Kopfschlingen und Fußangeln dieser Sprachen ziemlich gnadenlos ab.
c-hater schrieb: > Das ist ein sehr großes Hindernis bei der Einführung von etwas > Besserem, Kann man auch anders sehen: Wer wirklich Erfahren ist, macht nicht jeden Trend mit. Denn wer das tut, ist ununterbrochen am migrieren.
Ok, dann verstehe ich nicht wieso eine Fernhochschule auf solchen Trend eingeht, da wurde ich evtl. deren Auswahl ein wenig bzw. deutlich in Frage stellen! Milos M. schrieb: > Ein Buch das wir verwenden für die Statik ist technische Mechanik 1 und > 2, vorausgesetzt wird dass man sehr fit ist in der Vektorrechnung und > Integralrechnung. > > dort ist es super beschrieben > Wirkt auf mich, als ob dort eine praktische Anwendung der Ingenieurmathematik sinnvoll ausgeführt wird. Somit ist das für mich sehr interessant.
Stefan ⛄ F. schrieb: > Kann man auch anders sehen: Wer wirklich Erfahren ist, macht nicht jeden > Trend mit. Denn wer das tut, ist ununterbrochen am migrieren. Genau. Deswegen bleibe ich ja im hardwarenahen Bereich bevorzugt bei Assembler ;o) Da brauch ich niemals migrieren, solange es das Target gibt.
Nach all den eher abstrakten Hinweisen hier ein Versuch, dem TO einen praktischen Ansatz zur Lösung seines Problems anzubieten. Die Aufgabenstellung ist: - in konstanten Zeitabständen einen Motor ein- und wieder auszuschalten, - stromsparend für den Batteriebetrieb geeignet und außerdem - preisgünstig zu sein. Der Vorschlag, einen Microcontroller wie den ATtiny25 zu verwenden in Verbindung mit der Programmierung in Assembler oder C erscheint mir dazu zielführend. Nehmen wir also einen ATtiny25. Er hat einen RC-Oszillator, der mit 8MHz taktet. Diesen Takt können wir per Vorteiler 256 auf 8.000.000 / 256 = 31.250 Hz reduzieren. Damit füttern wir den Timer/Counter1. Aber wir benutzen noch dessen Vorteiler, in diesem Fall noch einmal mit dem Divisor 256. Am Ende liegt dann ein Takt an von 31.240 / 256 = 122 Hz. Mit diesen 122 Impulsen pro Sekunde wird der Counter TCNT1 incrementiert und mit seinem Compare-Register OCR1A verglichen. In dieses Register laden wir den Wert 122. Immer wenn der TCNT1 den Wert 122 erreicht (also 1x pro Sekunde) wird ein Interrupt ausgelöst. Bis zu diesem Zeitpunkt lief die gesamte Arbeit in der Hardware des Microcontrollers ab. Nun kommt die Software zum Tragen: Nach jedem Interrupt wird ein Sekundenzähler um 1 erhöht und der TCNT1 auf 0 zurückgesetzt. Anschließend wird geprüft, ob der Zähler den Wert des Einschaltpunktes erreicht hat - dann wird der Motor eingeschaltet - oder den Wert des Ausschaltzeitpunktes - dann wird der Motor abgeschaltet und der Sekundenzähler auf 0 zurückgesetzt. Der Controller geht nun wieder in den Sleep-Modus - bis zum nächsten Interrupt. Und so weiter ... Der Programmcode ist ca. 130 Byte lang, benötigt kein SRAM , denn die Register reichen für die einzige verwendete Variable - den Sekundenzähler - aus. Die Stromaufnahme habe ich mit ca. 200uA bei 3.5V gemessen. Das Programm ist nur exemplarisch. Man würde natürlich einen Uhrenquarz mit 32.768 Hz verwenden, der liefert eine genauere Zeitbasis als der RC-Oszillator bei geringerem Stromverbrauch. Aber einen Uhrenquarz hatte ich gerade nicht verfügbar - und eine fertige Lösung will ich ja auch nicht liefern. Ich denke, die Aufgabenstellung ist gut geeignet, um sich in die Thematik Microcontroller einzuarbeiten. Wobei die "Programmierung" in C auch für den Python-Kenner verständlich sein sollte. Schwieriger wird es sein, die Bedeutung/Funktion der Register des ATtiny zu verstehen, hier wird die Lektüre des Manuals nicht vermeidbar sein. Zum Thema Lektüre: Ich fand das Buch "Mikrocontrollertechnik ..." von Gerhard Schmitt ganz hilfreich. Michael S.
Hallo erstmal, danke für deine ausführliche Antwort ich glaube die hat mir am meissten weitergeholfen. Ich werde mich mal weiter damit beschäftigen, die ganze hardware bestellen und es dann mal testen. Danke nochmals!
Ein kurzer Nachtrag. Ich habe doch noch einen 32KHz Uhrenquarz gefunden und die Prescaler im Programm angepasst. Die Stromaufnahme liegt (bei 3.5V) gemessen irgendwo zwischen 50 bis 100uA. Einige zunächst unverständliche Probleme hatte ich mir mit dem AVRISP mkII Programmer in Verbindung mit dem reduzierten CPU-Takt eingehandelt. Nach dem ersten, erfolgreichen Programmieren des ATtiny mit diesem Prescaler wollte der Programmer den mc nicht mehr finden. Als Hinweis auf mögliche Fehler wird u.a. die Meldung ausgegeben, dass der Programmer maximal mit 1/4 des mc-Taktes arbeiten darf. Reduziert man der Takt des Programmers auf 4KHz, dann wird der mc wieder erkannt. Die Ursache war: Der AVRISP mkII schreibt per default mit 125KHz. Der Takt des RC-Oszillators auf dem ATtiny wird von 8MHz per Prescaler 256 auf ca. 32KHz reduziert. Also muss man den Takt auf dem Programmer reduzieren. Soweit, so gut. Aber mit dem Umstellen der Fuses auf den Uhrenquarz als Taktquelle trat das Problem erneut auf. Obwohl ich den Prescaler für den mc-Takt auf 1 reduziert hatte. Schuld war eine Einstellung in den Fuses: LOW.CKDIV8. Per "Werkseinstellung" wird der Oszillator- bzw. Quarztakt mit dem Faktor 8 reduziert. Aus 32kHz werden also 4 KHz CPU-Takt, der Programmer müsste auf 1KHz gestellt werden. Der kleinste einstellbare Wert beträgt aber 2KHz. Was lerne ich daraus ? Den Schalter LOW.CKDIV8 in den Fuses deaktivieren und den CPU-Takt per Register CLKPR wählen. Mein Lehrgeld: 3 "verfusede" ATtinys. Michael S.
Michael S. schrieb: > Mein Lehrgeld: 3 "verfusede" ATtinys. Verfused sind sie nur, wenn man nicht den richtigen Programmer hat... Man benutzt also am besten einen, dessen Code man selbst unter Kontrolle hat und deshalb leicht an "besondere" Anforderungen anpassen kann... Gerade im "low energy"-Bereich ist das oft wichtig. Aber auch im extremen "low cost"-Bereich (minmaler Pin-Count). Und am Wichtigsten natürlich, wenn beides auch noch gemeinsam eintritt...
Michael S. schrieb: > Die Stromaufnahme liegt (bei 3.5V) gemessen irgendwo zwischen 50 bis > 100uA. Also doch noch etwas weniger als ich geschätzt habe. Das ist doch schon super, da würde ich mir um Sleep Modi keine Gedanken mehr machen. Michael S. schrieb: > Der kleinste einstellbare Wert beträgt aber 2KHz. > Mein Lehrgeld: 3 "verfusede" ATtinys. Sind die 2 kHz wirklich das Minimum oder ist das bloß eine Einschränkung deiner GUI? Schonmal avrdude (mit Parameter -B 2000) probiert? Ich hatte das gleiche Problem mit einem Programmieradapter von der Firma In-Circuit. Doch wenige Wochen nach meiner Reklamation bekam ein ich einen neuen mit verbesserter Firmware zugeschickt, der langsam genug takten konnte - sogar automatisch. Da du die Teile gerade vorliegen hast, kannst du mal ausprobieren, wie stark sich die Stromaufnahme bei Taktfrequenz 32 kHz versus 4 kHz (oder noch weniger) verändert? Meine Vermutung: gar nicht. Leider gehen die Diagramme im Datenblatt nicht so weit, dass man das dort ablesen könnte.
Stefan ⛄ F. schrieb: > Da du die Teile gerade vorliegen hast, kannst du mal ausprobieren, wie > stark sich die Stromaufnahme bei Taktfrequenz 32 kHz versus 4 kHz (oder > noch weniger) verändert? Meine Vermutung: gar nicht. Leider gehen die > Diagramme im Datenblatt nicht so weit, dass man das dort ablesen könnte. Die kannst sie getrost linear extrapolieren. Das passt schon fast. Der Fehler zur Realität liegt unter 20%.
c-hater schrieb: > Die kannst sie getrost linear extrapolieren. Das passt schon fast. Der > Fehler zur Realität liegt unter 20%. Ergänzend: In extremer, mit internen Mitteln erreichbarer Nähe zu 0Hz. Darüber wird er immer geringer. Man kann natürlich noch weitaus geringere Takte extern einspeisen, dann entfernt sich das immer mehr vom linearen Zusammenhang und konvergiert gegen den Ruhestrom aller mit Energie versorgter Gatter im Chip... Sollte logisch und selbsterklärend sein...
Hier die Stromaufnahme bei 3.5V mit einem Diagitalmultimeter an ATtiny45 gemessen: 32KHz, Prescaler 1, Interrupt 1x pro Sekunde 60uA bzw. 110uA, im Sekundentakt wechselnd (vermutlich wegen schaltendem PINB.0 - ohne Last) wie oben, nur der Prescaler ist geändert: 32KHz, Prescaler 8, Interrupt 1x pro 8 Sekunden 30uA fast konstant, kurzzeitig auf 20uA abfallend Genauere Analysen konnte ich nicht anstellen, weil der ATtiny nach dem 1. Flashen nicht mehr ansprechbar war. Ich arbeite mit ATMEL Studio 7, da kann der Takt des AVRISP nur bis 2KHz reduziert werden. Das Flashen dieser extrem langsam taktenden mc's scheint problematisch, zumindest mit meinen Tools. Michael S.
Michael S. schrieb: > wie oben, nur der Prescaler ist geändert: > 32KHz, Prescaler 8, Interrupt 1x pro 8 Sekunden > 30uA fast konstant, kurzzeitig auf 20uA abfallend Dann bringt das ja doch noch deutlich was. Gut zu wissen. > Das Flashen dieser extrem langsam taktenden mc's > scheint problematisch, zumindest mit meinen Tools. Nicht nur mit deinen, daran scheitern viele Produkte. Du kannst da einfach einen schnelleren Takt an XTAL1 (ohne Quarz) einspeisen, dann kommst du wieder heran.
Stefan ⛄ F. schrieb: > Du kannst da einfach einen schnelleren Takt an XTAL1 (ohne Quarz) > einspeisen, dann kommst du wieder heran. Das kannste knicken! Bei auf einen INTERNEN Takt gefuseten Teilen klappt dieser Trick nicht, denn da spielt der Takt an XTAL1 überhaupt keine Rolle. Das einzige, was hier noch helfen kann, wenn der Programmer nicht weit genug herunterkommt, ist der Trick mit dem Reset-Hold, so dass zumindest die per Software (via CLKPR) herbeigeführte Taktreduktion ausser Gefecht gesetzt wird.
c-hater schrieb: > Das kannste knicken! Bei auf einen INTERNEN Takt gefuseten Teilen > klappt dieser Trick nicht, denn da spielt der Takt an XTAL1 überhaupt > keine Rolle. Ja aber er ist doch auf 32kHz Quarz konfiguriert - hatte ich zumindest so verstanden. Wegen: Michael S. schrieb: > 32KHz, Prescaler 1 > wie oben, nur der Prescaler ist geändert: > 32KHz, Prescaler 8 Da müsste ja sonst 128 kHz oder 8 MHz stehen.
> 32KHz, Prescaler 8 ... nicht mehr ansprechbar
An XTAL2 (sic!) z.B. 200 kHz anlegen.
Michael S. schrieb:
> Mein Lehrgeld: 3 "verfusede" ATtinys.
Ich könnte ein Hex-file für einen 'Fuse-resetter', z.B. auf dem
ATtiny85, anbieten.
S. Landolt schrieb: > An XTAL2 (sic!) z.B. 200 kHz anlegen. Das soll funktionieren? Ich möchte das jetzt nicht völlig ausschließen, aber es ist meines Wissens nach rein garnichts dokumentiert, was in irgendeiner Form darauf schließen lassen könnte. Falls doch, würde mich die Quelle stark interessieren.
> Das soll funktionieren?
Wie wäre es mit Ausprobieren, c-hater? Sie sind doch sonst nicht so
schwerfällig.
Ich möchte sogar umgekehrt behaupten:
> einfach einen schnelleren Takt an XTAL1
Das hat Stefan Frings nie ausprobiert, bei Einstellung 'Low-Frequency
Crystal Oscillator'.
S. Landolt schrieb: > Wie wäre es mit Ausprobieren, c-hater? Sie sind doch sonst nicht so > schwerfällig. Das ist nicht der Punkt, natürlich könnte ich das Ausprobieren, sehe aber kein Notwendigkeit dazu, weil ich einen Programmer besitze, der für alle denkbaren Situationen gerüstet ist. Mich hat halt nur interessiert, wie du auf diese Idee gekommen bist.
> wie du auf diese Idee gekommen bist
Kann ich nicht mehr sagen, ist Jahre her. Nachträglich finde ich es
logisch, wenn ich mir diesen Low-Power-Quartz-Oscillator vorstelle, aber
vielleicht hatte ich damals auch nur die Anschlüsse verwechselt.
S. Landolt schrieb: > Das hat Stefan Frings nie ausprobiert, bei Einstellung 'Low-Frequency > Crystal Oscillator'. Stimmt, das war nur ein Vorschlag, den man versuchen kann. Ich habe es nur mit High-Frequency Crystal Oscillator versucht. Warum schreibst du das, geht das nicht?
Eigentlich geschätzter Stefan Frings, warum probieren Sie es nicht einfach? (ich bin versucht, aus Faust II zu zitieren)
S. Landolt schrieb: > Eigentlich geschätzter Stefan Frings, warum probieren Sie es nicht > einfach? Weil ich gerade keine Lust dazu habe. Du hast meine Frage nicht beantwortet: geht das nicht?
Nein, es geht an XTAL1 nicht, nur an XTAL2, zumindest hier bei mir, sonst hätte ich es nicht geschrieben, nicht wahr?
S. Landolt schrieb: > Eigentlich geschätzter Stefan Frings, warum probieren Sie es nicht > einfach? > (ich bin versucht, aus Faust II zu zitieren) "Über Rosen lässt sich dichten. In die Äpfel muss man beißen." Egal welches Zitat Sie wählen, es ist am "geschätzen" F. verschwendet.
S. Landolt schrieb: > Nachträglich finde ich es > logisch, wenn ich mir diesen Low-Power-Quartz-Oscillator vorstelle Darüber muss ich nachdenken. Da könnte eventuell was dran sein. Wenn aber was dran ist, ist zumindest vorab klar, warum das nicht dokumentiert ist ;o)
Ich habe das jetzt mit einem ATtiny85 ausprobiert. Folgendes hängt dran: Programmieradapter: Atmel ISP mkII Stromversorgung: Drei NiMh Zellen Taktversorgung: Externer Quarz Oszillator 4 MHz über 220Ω mit XTAL1 verbunden Fuse für 32kHz Quarz einstellen:
1 | stefan@stefanpc:/opt/AVR8-Burn-O-Mat$ sudo avrdude -c avrispmkii -P usb -B 200 -p attiny85 -U lfuse:w:0x66:m |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.02s |
6 | |
7 | avrdude: Device signature = 0x1e930b (probably t85) |
8 | avrdude: reading input file "0x66" |
9 | avrdude: writing lfuse (1 bytes): |
10 | |
11 | Writing | ################################################## | 100% 0.02s |
12 | |
13 | avrdude: 1 bytes of lfuse written |
14 | avrdude: verifying lfuse memory against 0x66: |
15 | avrdude: load data lfuse data from input file 0x66: |
16 | avrdude: input file 0x66 contains 1 bytes |
17 | avrdude: reading on-chip lfuse data: |
18 | |
19 | Reading | ################################################## | 100% 0.01s |
20 | |
21 | avrdude: verifying ... |
22 | avrdude: 1 bytes of lfuse verified |
23 | |
24 | avrdude: safemode: Fuses OK (E:FF, H:DF, L:66) |
25 | |
26 | avrdude done. Thank you. |
Stromversorgung aus und wieder an. test:
1 | stefan@stefanpc:/opt/AVR8-Burn-O-Mat$ sudo avrdude -c avrispmkii -P usb -B 200 -p attiny85 |
2 | |
3 | avrdude: stk500v2_command(): command failed |
4 | avrdude: stk500v2_program_enable(): bad AVRISPmkII connection status: Unknown status 0x00 |
5 | avrdude: initialization failed, rc=-1 |
6 | Double check connections and try again, or use -F to override |
7 | this check. |
8 | |
9 | avrdude done. Thank you. |
Kacke. Taktquelle auf XTAL2 umgelötet:
1 | stefan@stefanpc:/opt/AVR8-Burn-O-Mat$ sudo avrdude -c avrispmkii -P usb -B 200 -p attiny85 |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.02s |
6 | |
7 | avrdude: Device signature = 0x1e930b (probably t85) |
8 | |
9 | avrdude: safemode: Fuses OK (E:FF, H:DF, L:66) |
10 | |
11 | avrdude done. Thank you. |
Jetzt bin ich aber verunsichert. Ich hatte bisher immer den externen Takt an XTAL1 angeschlossen. Ist das jetzt eine Besonderheit für den Low-Frequency Oscillator oder soll man den Takt immer an XTAL2 einspeisen?
> Low-Frequency Oscillator
Genau um diesen ging es zuletzt bei Michael S.
PS: Die 4 MHz waren sicher Glück, sind eigentlich zuviel; zumindest bei einem AVR8-Typ war bei etwa 300 kHz Schluss (könnte der ATmega328 gewesen sein).
Ich habe noch weiter experimentiert. Diese Versuche habe ich mit zwei 220 Ω Widerständen zwischen dem 4 MHz Oszillator und dem ATtiny85 gemacht. Wenn die Fuse auf "High-Frequency Crystal" eingestellt ist, kann ich den externen Takt wahlweise an XTAL1 oder XTAL2 oder auch beiden Pins gleichzeitig einspeisen. Wenn die Fuse auf "Low-Frequency Crystal" eingestellt ist, muss ich den externen Takt an XTAL2 einspeisen. Beide Pins gleichzeitig geht auch. Nur XTAL1 alleine geht nicht. Offenbar ist der Low-Frequency Oszillator völlig anders aufgebaut, als der normale. Hat jemand irgendwelche Infos dazu? Im Datenblatt steht dazu nur das: "XTAL1 and XTAL2 are input and output, respectively, of an inverting amplifier which can be configured for use as an On-chip Oscillator" Ganz so einfach ist es aber offenbar doch nicht. Sonst hätte ich im "High-Frequency" Modus den Talk wohl kaum wahlweise und sogar gleichzeitig an beiden Pins einspeisen können. Außerdem widerspricht die Info den Beobachtungen im "Low-Frequency" Modus.
Ich hatte immer gewisse Schwierigkeiten, einen 32 KiHz-Oszillator diskret aufzubauen, im Gegensatz zu > 1 MHz, das war einfach. Und hier kommt noch die sehr niedrige Stromaufnahme hinzu.
Angehängte Dateien:
Ich habe dazu noch eine Appnote gefunden, aber auch nach der kann es eigentlich nicht sein, dass man den Takt an XTAL2 einspeisen kann oder soll. Offenbar ist der Chip ganz anders aufgebaut, als dokumentiert wurde.
Angehängte Dateien:
Hier ist noch eine andere Appnote, wo es ausdrücklich um den 32 kHz Quarz geht. Wieder wird die gleiche Innenschaltung gezeigt. Ich verstehe es nicht! Gemäß Datenblatt und dieser beiden Appnotes muss man den Takt immer an XTAL1 einspeisen. Dennoch hat S. Landolt herausgefunden, dass es beim "Low-Frequency" Oszillator XTAL2 sein muss und ich konnte das im Versuch bestätigen. Für mich bricht da eine kleine Welt zusammen, denn ich verlasse mich immer auf die Datenblätter.
Nachdem ich mir die "Datasheet Revision History" für den ATtiny85 angeschaut habe, hat mich Stefans Überraschung überrascht(weil da so einiges im Laufe der Zeit korrigiert wird)...:) Es wird der Oszillator nur bei
1 | 9.6 Rev. 2586L-06/10 |
2 | Table 6-11, “Capacitance of Low-Frequency Crystal Oscillator,” on page 29 |
3 | 9.11 Rev. 2586G-05/06 |
4 | 3. Updated “Low-Frequency Crystal Oscillator” on page 29. |
erwähnt. Aber das ist glaube ich nicht eine komplette Schaltungsänderung, was diesen kuriosen Fund von euch beiden erklären würde. Btw. Spannend;)
Hat jemand einen Vorschlag, wie und wo wir das so dokumentieren, dass die Nachwelt es wieder findet?
Stefan F. schrieb:
> XTAL2 ist ein Ausgang!
Das eben ist nur die halbe Wahrheit, in der Hauptsache ist es der
Takteingang für das Controllerinnere.
S. Landolt schrieb: >> XTAL2 ist ein Ausgang! > > Das eben ist nur die halbe Wahrheit, in der Hauptsache ist es der > Takteingang für das Controllerinnere. Und zudem ein schlapper Ausgang, den man gut extern "überschreiben" kann. Guter Tipp mit XTAL2!
Stefan ⛄ F. schrieb: > Ich hab's mal hier hingeschrieben: > http://stefanfrings.de/avr_verfused/index.html (ganz unten) "Jemand berichtete mir, dass der Oszillator dann maximal 1 MHz haben darf" Jetzt bin ich aber überrascht - wer ist denn dieser andere Jemand, der von "1 MHz berichtete"? Ich kann's ja nicht gewesen sein, ich schrieb 300 kHz.
> Offenbar ist der Low-Frequency Oszillator völlig anders aufgebaut, als > der normale. Klar, die 32khz Quarze haben eine hoehere Guete und sind viel empfindlicher. Deshalb ist es auch so schwer sie ueberhaubt ans Schwingen zu bringen wenn man sowas mal komplett selber baut. Sie duerfen nur wenig belastet werden. Olaf
S. Landolt schrieb: > Jetzt bin ich aber überrascht - wer ist denn dieser andere Jemand, der > von "1 MHz berichtete"? Ich kann's ja nicht gewesen sein, ich schrieb > 300 kHz. Huch, das muss ich ändern. Danke dass du so aufmerksam bist.
Um doch noch einmal kurz auf die Ausgangsfrage dieses Threads zurüclzukommen: Es ist möglich, mit einem ATtinyxx und einem externen Uhrenquarz die Stromaufnahme durch Heruntertakten des CPU-Taktes soweit zu reduzieren, dass ein Batteriebetrieb möglich ist. Der Prescaler für den Oszillator in Verbindung mit dem Compare-Register bestimmen die Stromaufnahme und das Zeitintervall für die Zeitbestimmung. Kritisch ist die Tatsache, dass der Programmieradapter maximal mit 1/4 des CPU-Taktes arbeiten darf. Bei zu geringem CPU-Takt ist eine weitere Programmierung u.U. nicht mehr möglich. Als Workaround könnte man den ATtiny nach dem Reset für einige Zeit mit dem Prescaler 1 laufen lassen und erst nach Aablauf der Wartezeit in einen niedkrigeren Takt wechseln. Unmittelbar nach einem Reset sollte man den mc beschreiben bzw. auslesen können. Zum Rettungsversuch meiner "verfuseden" ATtinys: Da Anlegen eines Rechtecksignals von 3V hat bei mir keinen Erfolg gebracht (Problem: CKDIV8 ist gesetzt). Mit dem Uhrenquarz arbeitet der mc (die LED blinkt), bei gezogenem Uhrenquarz tut sich nichts - wie zu erwarten. Daran ändert sich aber auch nichts, wenn ich ein Rechtecksignale von 30-200KHz an XTAL2 anlege. Auch der Programmer zeigt sich unbeeindruckt und verweigert unverändert die Zusammenarbeit. Aber davon geht die Welt nicht unter. Michael S.
Michael S. schrieb: > Es ist möglich, mit einem ATtinyxx und einem externen Uhrenquarz die > Stromaufnahme durch Heruntertakten des CPU-Taktes soweit zu reduzieren, > dass ein Batteriebetrieb möglich ist. Wie schon oben gesagt wurde, der ATtiny25 braucht ~20..30µA. Der ATmega48A zieht im Power-Save mit Uhrenquarz <1µA.
Michael S. schrieb: > kann der Takt des AVRISP nur bis 2KHz reduziert werden > ... keinen Erfolg ... Das wundert mich - 200 kHz/8 /4 = 6250 Hz, also sollten die 2 kHz locker reichen. > Aber davon geht die Welt nicht unter Schon, mein Angebot für einen 'fuse-resetter' gilt trotzdem.
Michael S. schrieb: > Als Workaround könnte man den ATtiny nach dem Reset für einige Zeit mit > dem Prescaler 1 laufen lassen und erst nach Aablauf der Wartezeit in > einen niedkrigeren Takt wechseln. Der Programmieradapter zieht doch /Reset auf Low, so dass das Programm nicht startet. Daher müsste der Prescaler ohnehin unverändert (wie von der Fuse vorgegeben) bleiben. Die Wartezeit erscheint mir daher nicht notwendig.
Michael S. schrieb: > Es ist möglich, mit einem ATtinyxx und einem externen Uhrenquarz die > Stromaufnahme durch Heruntertakten des CPU-Taktes soweit zu reduzieren, > dass ein Batteriebetrieb möglich ist Batteriebetrieb ist auch völlig ohne Schlafmodi möglich. Es kommt immer darauf an, welche Laufzeit man mit welcher Energie erreichen möchte/muß. Geschätzt braucht Deine Pumpe zur Laufzeit etwa 120 mA, was bei einer Einschaltdauer von 30/3600 Stunden 1 mAh entspricht. Selbst, wenn der µC dauerhaft 1 mA aufnimmt, ist der Wirkungsgrad schon bei 50%. Eine Stromaufnahme < 100 µA reduziert die Verluste schon auf < 5%, was mit 32 kHz auch ohne Schlafmodus erreichbar ist. Ob weitere Reduzierung notwendig ist, muß der TO entscheiden. Wenn die Stromaufnahme in den µA Bereich gebracht werden soll, ist es schon wichtiger, die Schaltung trocken zu halten, damit nicht Leckströme die Batterie entladen.
ATtiny85 mit 32 KiHz-Quarz, idle-mode, Stromaufnahme in uA:
1 | Ucc [V] 5.0 3.0 |
2 | f_CPU [Hz] |
3 | 32768 18.0 8.5 |
4 | 8192 9.5 6.0 |
S. Landolt schrieb: > Schon, mein Angebot für einen 'fuse-resetter' gilt trotzdem. Danke für das Angebot, aber wie kriege ich das HEX-File auf den mc ? Ich kann ja nichts schreiben. Stefan ⛄ F. schrieb: > Der Programmieradapter zieht doch /Reset auf Low, so dass das Programm > nicht startet. Daher müsste der Prescaler ohnehin unverändert (wie von > der Fuse vorgegeben) bleiben. Die Wartezeit erscheint mir daher nicht > notwendig. Hatte ich auch gedacht. Aber nachdem ich gestern den Prescaler auf 8 gesetzt habe, war ich ausgesperrt. S. Landolt schrieb: > Das wundert mich - 200 kHz/8 /4 = 6250 Hz, also sollten die 2 kHz locker > reichen. Hat mich auch gewundert. Auf einem Controller hat es möglicherweise funktioniert, Ich bin mir aber nicht sicher, ob ich bei diesem mc wirklich die fuses auf low freq gesetzt hatte oder irrtümlich auf externem Takt. Außerdem hatte ich beobachtet, dass ich den Takt sowohl an XTAL! als auch an XTAL2 anlegen kann. In beiden Fällen hat der mc wieder getaktet Michael S.
> Danke für das Angebot, aber wie kriege ich das HEX-File auf den mc ?
Sie schreiben das Programm auf einen erreichbaren AVR8, schließen danach
diesen (mit den nötigen vier Leitungen) an den nicht erreichbaren
ATtiny85 an und starten das Programm.
Michael S. schrieb: > Hatte ich auch gedacht. > Aber nachdem ich gestern den Prescaler auf 8 gesetzt habe, war ich > ausgesperrt. Vielleicht wird die CLKDIV8 Fuse nicht beim Reset sondern erst danach angewendet. Dann könnte ein Programm den folgenden Programmiervorgang blockieren, wenn es den Takt bis dahin bereits herabgesetzt hat.
Stefan ⛄ F. schrieb: > Der Programmieradapter zieht doch /Reset auf Low, so dass das Programm > nicht startet. Daher müsste der Prescaler ohnehin unverändert (wie von > der Fuse vorgegeben) bleiben. Die Wartezeit erscheint mir daher nicht > notwendig. Wird wohl doch so stimmen. Man muss aber den Reset und den Programmer genau zum richtigen Zeitpünkt starten. Mit der Verzögerung läuft das wesentlich entspannter. Aus dem laufenden Programm auf dem mc bringt ein Reset durch den Programmer keinen Erfolg. S. Landolt schrieb: > Sie schreiben das Programm auf einen erreichbaren AVR8, schließen danach > diesen (mit den nötigen vier Leitungen) an den nicht erreichbaren > ATtiny85 an und starten das Programm. Hört sich plausibel an, würde ich gerne ausprobieren. Habe mir zwar auch schon avrdude heruntrrgeladen, aber den avrisp kann ich nicht zur Zusammenarbeit überreden. Und die Beschreibungen im www zur Installation eines Treibers sind abenteuerlich. Übrigens habe ich heute die Stromaufnahme noch einmal gemessen: Prescale 8: knapp über 60uA Prescale 16: knapp unter 60uA Das sind wohl eher Anhaltswerte. Michal S.
Michael S. schrieb: > Habe mir zwar auch schon avrdude heruntergeladen, aber den avrisp kann > ich nicht zur Zusammenarbeit überreden. Der wird bestimmt unterstützt. Um welches Produkt genau handelt es sich beim "avrisp"?
> würde ich gerne ausprobieren
Ich gehe mal davon aus, dass Sie
a) mit avrasm2 assemblieren können (wg. 'ATMEL Studio 7')
b) der Mastercontroller ebenfalls ein ATtiny85 ist
Falls nicht (oder sonst Probleme auftreten sollten) melden Sie sich
einfach noch mal.
Stefan ⛄ F. schrieb: > Der wird bestimmt unterstützt. Um welches Produkt genau handelt es sich > beim "avrisp"? AVRISP mkII, produziert 04/2011 meldet sich immer mit dubiosen Seriennr. 0xFFFFFF.... Unter Windows 10 und ATMEL STUDIO 7 läuft das Teil. Und ATMEL STUDIO 7 verwnde ich nur deswegen damit ich stressfrei unter Windows 10 mc's flashen kann. S. Landolt schrieb: > Ich gehe mal davon aus, dass Sie > a) mit avrasm2 assemblieren können (wg. 'ATMEL Studio 7') > b) der Mastercontroller ebenfalls ein ATtiny85 ist Ich werde es versuchen. Ist ein paar Tage her, dass ich Assembler benutzt habe. Es war aber schon erstaunlich, was mit einem ATtiny15 anfangen konnte. Michael S.
Kein Problem, hier ist das Intel-Hex-File. Sie benötigen aber natürlich die Anleitung aus dem Sourcefile.
Michsel S. schrieb: > AVRISP mkII, produziert 04/2011 > meldet sich immer mit dubiosen Seriennr. 0xFFFFFF.... Vermutlich nicht original. Auf jeden Fall unterstützt avrdude ihn. Der Orignale kann bis auf 50 Hz herunter getaktet werden. Gibe mal das ein: avrdude -c avrispmkii -P usb -B 2000 -p attiny85 Er müsste dann die Chip-ID und die Fuses auslesen und anzeigen. Unter Linux musst du es eventuell als root User ausführen, um Zugriff auf den USB Port zu bekommen. Oder alternativ mit "sudo avrdude ..." oder die Zugriffsrechte mit einer "udev rules" Datei konfigurieren. Unter Windows musst du den libusb Treiber so installieren: http://stefanfrings.de/avr_tools/libusb.html
Ich hatte auch den Eindruck, wenn man in der Applikation den Prescaler runter setzt, läßt sich der ATtiny25 am Uhrenquarz nicht mehr programmieren. Ich hatte erst gedacht, der Prescaler überlebt ein Reset. Startet die Applikation, hat er aber zuerst immer den vollen Takt. Meine Vermutung ist daher, daß bei Reset = Low der Prescaler noch gesetzt bleibt. Erst die 0->1 Flanke des Resetpins setzt den Prescaler zurück.
Peter D. schrieb: > Meine Vermutung > ist daher, daß bei Reset = Low der Prescaler noch gesetzt bleibt. Erst > die 0->1 Flanke des Resetpins setzt den Prescaler zurück. Das würde erklären, warum ich früher mal einen ATTiny retten konnte, indem ich /Reset fest mit GND verbinde und erst dann die Stromversorgung einschalte. Ohne diese Maßnahme konnte ich ihn nicht mehr programmieren. Mein damaliger Programmieradapter verlange mindestens 32 kHz Systemtakt.
Stefan ⛄ F. schrieb: > Das würde erklären, warum ich früher mal einen ATTiny retten konnte, > indem ich /Reset fest mit GND verbinde und erst dann die Stromversorgung > einschalte. Genau: Der eigentliche Trick ist der zwischenzeitliche Power-Cycle. Dadurch wird die Hinterlassenschaft des Programms in CLKPR "gelöscht" und der Reset-Hold beim PowerUp sorgt dann dafür, dass das Programm auch nicht wieder zum Zuge kommt. Man hat dann also den per Fuses konfigurierten Takt zum Programmieren.
S. Landolt schrieb: > Kein Problem, hier ist das Intel-Hex-File. Sie benötigen aber natürlich > die Anleitung aus dem Sourcefile Danke, das war aber nicht nötig. Die asm kann ich ansatzweise verstehen und konnte sie selbst kompilieren (lassen). Die Rettung der Tinys ist mir leider trotzdem nicht gelungen. Was ich beobachte: Das Programm zieht Reset auf gnd. Kurz danach liegt an clk ein Signal an. Einen Tuck später wackelt mosi. Aber an miso herrscht Stille. Nach ca. 4 Sekunden ist das Programm beendet, clk liegt auf high (= Fehler). Ich habe Pin0 (mosi) auch testhalber an mosi vom Target angeschlossen. Und clk an XTAL1 / 2. Immer der gleich Ablauf. Ich vermute, dass die ChipId nicht zurückgeliefert wird. Stefan ⛄ F. schrieb: > Unter Windows musst du den libusb Treiber so installieren: > http://stefanfrings.de/avr_tools/libusb.html Danke für die Beschreibung. Die hat mir Mut gemacht, das Abenteuer zu wagen. Hat auch recht gut geklappt, avrdude erkennt nun den avrsipmkII. Mit dem Parameter -B 20000 konnte ich die lfuse auf 0x62 setzen. Jetzt funktionieren alle Tinys wieder ! Danke an alle für die Hilfe. Michael S.
Hallo Ihr Lieben, hat ganz schön gedauert bis ich hier im Thread unten angekommen bin. Es ging ja los mit Microcontroller mit Python. Also auch wenn die Aufgabenstellung ja sehr einfach ist, will ich mal die Lanze für Python brechen. Es gibt ja etliche Kontroller auf denen Circuitpython läuft. Das heißt wenn man Erfahrung mit Python hat, macht das schon Spaß damit zu arbeiten. Speziell beim Probieren mit Sensoren und Servos. Auch der schnelle Zugriff mit der Kommandozeile. Wenn man einen Controller mit Wifi hat, kann man dann die Pumpe auch aus der Ferne überwachen. Python hat auch seine Vorteile wenn man ein KI bauen will. Speziell bei der Auswertung von Kamerabildern hat man es dann mit Assembler schwerer. Klar man kann auch Neuronale Netze am PC erstellen und dann daraus ein C Programm generieren lassen, welches dann natürlich sehr viel schneller auf kleinen Kontrollern läuft. Also wenn man jetzt ein so einfaches Projekt mit Python löst, hat es den Vorteil, wenn dann die Aufgabenstellung komplexer wird, man schon etwas in der Materie drinsteckt. Sich mit einem ATtiny85 und Co. zu beschäftigen erweitert natürlich den Horizont für die Basics. Es ist auch die Frage wieviel Zeit man zur Verfügung hat zum Ziel zu kommen und auf welchem Gebiet es Sinn macht sich weiter zu entwickeln. Na dann noch viel Spaße beim Entwickeln und Tüfteln. Grüße Nils
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.