Microcontroller mit Python

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.

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ß.

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.

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...

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).

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.

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

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

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 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...

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?

MaWin O. schrieb:

> Wie geht das?

Siehe Datenblatt->CLKPR

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.

Microphyton

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

}

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...

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

Diese Schaltung kannst du nicht ändern. Du müsstest sie durch eine 
eigene komplett ersetzen.

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

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?

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;-)

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.

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:
> An XTAL2 (sic!) z.B. 200 kHz anlegen.

XTAL2 ist ein Ausgang!

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.

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.

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.

Es steht ja dabei: "Equivalent" bzw. "simplified".

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!

Ich hab's mal hier hingeschrieben: 
http://stefanfrings.de/avr_verfused/index.html (ganz unten)

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:
> 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

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.

Michael S. schrieb:
> Jetzt funktionieren alle Tinys wieder !

Es freut mich, das zu lesen.