Stromsparen und Atmega8?

Schaltung kann so weit nicht verändert werden.
Aber anscheinend gibt es nichts um den ATMEGA etwas zahmer zu machen, 
egal muss auch ohne gehen ;).

Danke für die Antworten!

MFG Julian

Julian Schild schrieb:
> Schaltung kann so weit nicht verändert werden.

Naja, einen ATmega88P kannst du ohne Veränderung der Schaltung
einsetzen.  Zusammen mit angepasster Firmware kannst du damit
durchaus Energie sparen.

Hallo,
der hört sich gar nicht so schlecht an. Was müsste geändert werden?
Das Programm?

Anderer Gedanke, wenn ich die Frequenz verringere müsste sich ebenfalls 
die Stromaufnahme verringern oder etwa nicht? Laufe zur Zeit auf 8Mhz, 
da würden 4Mhz auch schon reichen.

MFG

Schrotty schrieb:
> Anderer Gedanke, wenn ich die Frequenz verringere müsste sich ebenfalls
> die Stromaufnahme verringern oder etwa nicht?

Die Stromaufnahme ja, der Energieverbrauch nicht.  Geht ja alles
entsprechend langsamer.

Jörg Wunsch schrieb:
> Die Stromaufnahme ja, der Energieverbrauch nicht.  Geht ja alles
> entsprechend langsamer.

Auf die CPU alleine bezogen richtig. Bei höherem Takt (und damit höherem 
Stromverbrauch) steigt aber der Verlust am (Innen-)Widerstand der 
Stromversorgung.

Das kann relevant sein, muss aber nicht, kommt immer auf den 
Anwendungsfall an.

Andreas

LordZiu schrieb:
> Das wurde in der aktuellen Elektorausgabe eindeutig widerlegt. Da wurden
> Tests gemacht, die zeigten, dass es (energietechnisch) günstiger ist,
> kurze aber schnelle Operationen durchzuführen, als längere, langsamere.

Wenn man nur die Berechnung an sich betrachtet, kann das hinkommen, da 
man dann aufgrund des statischen Stromverbrauchs durch Leckströme in der 
kürzeren Zeit weniger Energie verbraucht.

Wenn man die schnellere CPU aber den Rest der Zeit, den die langsamere 
braucht, im Sleep-Modus weiter mit Strom versorgt (in der Regel wird das 
Gerät ja nicht nach einer Berechnung wieder ausgeschaltet), dürfte da 
im wesentlichen kein Unterschied mehr sein, ausser die CPU hat im 
Sleep-Modus deutlich kleinere Leckströme.

Betrachtet man im letzteren Fall (also im wesentlichen gleicher 
Energieverbrauch der beiden CPUs) aber den Energieverlust in der 
Stromversorgung, so gilt dort P=I^2*R. Die Verlustleistung dort steigt 
also letztlich mit dem Quadrat des Taktes, während die Rechenleistung 
nur linear zunimmt, deshalb ist es dann insgesamt günstiger, langsamer 
und dafür länger zu rechnen.

Andreas

Ist des denn eine ATmega8L oder ein normaler ATmega8?

Es ist ein ATMEGA8.

Naja, die Anwendung ist nicht wirklich zeitkritisch, also wäre es egal 
wenn er etwas länger benötigt. Es geht hier um die momentane 
Stromaufnahme und eben nicht die Dauer.

D.h. es ist besser wenn er 10min 1mA konsumiert als 5min 2mA (falls man, 
das so rechnen kann).

Danke für eure Antworten, aber ich seh schon da ist nicht viel zu holen. 
Ich schau mal, vllt kann ich an der Hardware auch noch was machen :).
Der ATMEGA88P wäre dann natürlich der letzte Ausweg.

Andreas Ferber schrieb:

> Wenn man nur die Berechnung an sich betrachtet, kann das hinkommen, da
> man dann aufgrund des statischen Stromverbrauchs durch Leckströme in der
> kürzeren Zeit weniger Energie verbraucht.

Leckströme sind Leckströme, die sind auch im Sleep noch da (idealer-
weise nur noch die).  Die einzige Methode, wie man diese reduzieren
könnte während des Sleeps wäre eine Reduzierung der Betriebsspannung.
Wird meines Wissens aber nicht gemacht.

> (in der Regel wird das
> Gerät ja nicht nach einer Berechnung wieder ausgeschaltet),

Genau da liegt aber das Einsparpotenzial.  Man muss sich bemühen,
den Prozessor möglichst nicht "Kreise drehen" zu lassen, sondern
ihn schlafen zu legen so häufig es geht.  Jedes _delay_us() etc.
ist energiepolitisch Mist, _delay_ms() verbietet sich bei einer
solchen Applikation nahezu von selbst.  Timer programmieren,
schlafen legen, warten auf Interrupt, weiter.

> Betrachtet man im letzteren Fall (also im wesentlichen gleicher
> Energieverbrauch der beiden CPUs) aber den Energieverlust in der
> Stromversorgung, so gilt dort P=I^2*R.

Das geht davon aus, dass der Innenwiderstand der Energiequelle ein
Ohmscher sei.  Ist er aber nicht (bzw. nur zu einem geringen Teil),
ansonsten könnte man ihn ja gleich ausbauen. ;-)  Der Innenwiderstand
ist doch nur ein fiktives Maß dafür, wie weit sich die Quellspannung
unter Last verringert.  An ihm wird aber keine (oder nur sehr wenig)
Energie "verheizt".

Allerdings gebe ich dir Recht dahingehend, wenn durch die höhere
Taktfrequenz die Strombelastung für die Quelle zu hoch wird, dann
ist es natürlich nicht mehr egal, ob man sich eine hohe Frequenz mit
kurzer Ausführungszeit oder eine niedrige mit langer Zeit auswählt.

Julian Schild schrieb:
> Der ATMEGA88P wäre dann natürlich der letzte Ausweg.

Nun, er hätte die erste Wahl sein müssen statt der letzte Ausweg.
Allein die nicht-P-Variante hätte dir schon massig Einsparpotenzial
im Vergleich zum Großvater ATmega8 geboten.

Tja mangels Erfahrung (halbes Jahr im µC Bereich unterwegs), hab ich 
eben einen ATMEGA8 und keinen 88P.

Julian Schild schrieb:
> Tja mangels Erfahrung (halbes Jahr im µC Bereich unterwegs), hab ich
> eben einen ATMEGA8 und keinen 88P.

Kostet es denn so viel, ihn noch zu tauschen?

Haha, nein die ~3€ sind nicht das Problem.

Es geht mir hier lediglich um den Aufwand- Nutzenfaktor. Wie gesagt ich 
werd mir noch mal die Hardware anschauen. Wenn dort nichts zuholen ist, 
muss eben der 88er herhalten ;).

Die Möglichkeit den µC jedes mal Schlafen zulegen wenn er nichts zu tun 
hat wäre natürlich eine Möglichkeit, da aber der ADC ständig seine 
Arbeit verrichten muss und diese Ausgewertet ist es etwas sinnlos ihn 
für Xµs schlafen zu legen ;).

Danke für eure Tipps.

Julian Schild schrieb:
> Danke für eure Antworten, aber ich seh schon da ist nicht viel zu holen.

Ooch, da ist ne Menge zu machen (diverse Power-Down Modi, kleinerer 
Quarz. kleinere VCC), aber dazu müßte man Deine Software kennen und was 
die machen soll.
Die ATmega48/88 haben natürlich wesentlich mehr Sparoptionen.


> Der ATMEGA88P wäre dann natürlich der letzte Ausweg.

Generell sollte man für ein neues Preojekt immer auch einen aktuellen MC 
verwenden.
Die ATmega48/88 sind doch gut verfügbar.
Wenns aber unbedingt P sein soll, CSD hat z.B. den ATmega328P.


Peter

Julian Schild schrieb:
> da aber der ADC ständig seine
> Arbeit verrichten muss und diese Ausgewertet ist es etwas sinnlos ihn
> für Xµs schlafen zu legen ;).

Nein, ist es nicht.  So schnell ist der ADC ja ohnehin nicht, und
es gibt einen eigenen Schlafmodus, der nur dafür da ist, dass die
Takt-Wackelei während der ADC-Messung so weit reduziert wird, dass
das Messergebnis davon nicht verfälscht wird.

Du musst den Controller ja nicht in den Tiefschlaf versenken, aber
selbst ein idle sleep bringt schon eine Energieverbrauchseinsparung.

Hi Julian,

Julian Schild schrieb:
> Haha, nein die ~3€ sind nicht das Problem.
>
> Es geht mir hier lediglich um den Aufwand- Nutzenfaktor. Wie gesagt ich
> werd mir noch mal die Hardware anschauen. Wenn dort nichts zuholen ist,
> muss eben der 88er herhalten ;).
>
> Die Möglichkeit den µC jedes mal Schlafen zulegen wenn er nichts zu tun
> hat wäre natürlich eine Möglichkeit, da aber der ADC ständig seine
> Arbeit verrichten muss und diese Ausgewertet ist es etwas sinnlos ihn
> für Xµs schlafen zu legen ;).

Gerade an der Stelle glaube ich dass Du sehr wohl sparen kannst. Die 
Interne Spannungsreferenz zum Beispiel. Musst Du wirklich "konstant 
messen"? Du sagst dass die CPU ruhig langsam sein kann. Wie hoch ist 
denn Deine Messrate? Wenn Du hier an die Grenze gehst kannst Du bestimmt 
einiges raus holen. Wie genau muss die Messung sein? Brauchst Du 
überhaupt eine genaue Referenzspannung?

>
> Danke für eure Tipps.

Schreibe doch einfach mal wie viel Strom Du im Moment brauchts und die 
viel Du einsparen musst. Dann können wir schon recht gut abschätzen ob 
Dir das Sparen was bringt.

Jörg Wunsch schrieb:
> Leckströme sind Leckströme, die sind auch im Sleep noch da (idealer-
> weise nur noch die).  Die einzige Methode, wie man diese reduzieren
> könnte während des Sleeps wäre eine Reduzierung der Betriebsspannung.
> Wird meines Wissens aber nicht gemacht.

Eben. Und deshalb ist es für den Energieverbrauch der CPU egal, ob man 2 
Sekunden bei 4 MHz rechnet, oder ob man 1 Sekunde bei 8 MHz rechnet und 
dann 1 Sekunde schläft.

>> (in der Regel wird das
>> Gerät ja nicht nach einer Berechnung wieder ausgeschaltet),
> Genau da liegt aber das Einsparpotenzial.  Man muss sich bemühen,
> den Prozessor möglichst nicht "Kreise drehen" zu lassen, sondern
> ihn schlafen zu legen so häufig es geht.

Davon bin ich schon ausgegangen, nicht dass die Wartezeit mit 
Warteschleifen verbracht wird. Was ich meinte mit Ausschalten ist das 
Abklemmen der Versorgung, um die Leckströme zu unterbinden.

>> Betrachtet man im letzteren Fall (also im wesentlichen gleicher
>> Energieverbrauch der beiden CPUs) aber den Energieverlust in der
>> Stromversorgung, so gilt dort P=I^2*R.
> Das geht davon aus, dass der Innenwiderstand der Energiequelle ein
> Ohmscher sei.

Ganz so einfach ist es für eine reale Stromquelle nicht, richtig, da 
dort z.B. der Innenwiderstand auch stromabhängig sein kann. Wobei bei 
den meisten realen Stromquellen der Innenwiderstand bei steigendem Strom 
eher steigen als sinken dürfte. Damit geht es dann eher noch in Richtung 
P ~ I^3.

Was sonst noch für Terme bei der Berechnung der Verluste vorkommen ist 
aber völlig egal, entscheidend ist der eine (mindestens) quadratische 
Term, der in jedem Fall vorhanden ist.

> Ist er aber nicht (bzw. nur zu einem geringen Teil),
> ansonsten könnte man ihn ja gleich ausbauen. ;-)  Der Innenwiderstand
> ist doch nur ein fiktives Maß dafür, wie weit sich die Quellspannung
> unter Last verringert.  An ihm wird aber keine (oder nur sehr wenig)
> Energie "verheizt".

Nimm zwei identische Batterien (gleicher Ladungszustand), und entlade 
sie, einmal mit einem niedrigen und einmal mit einem hohen Strom. Mit 
dem niedrigen Strom wirst du insgesamt mehr Energie aus der Batterie 
ziehen können als mit dem hohen Strom. Da aber vorher die gleiche 
(chemische) Energie in beiden Batterien steckte, ist ganz offensichtlich 
beim hohen Strom der Verlust höher als beim niedrigen.

Dann mach mal einen (idealen) Kurzschluss mit einer frischen Batterie. 
Dabei wird die komplette Energie am Innenwiderstand verheizt, bei 
einer Klemmenspannung von 0V. Wenn das nicht so wäre, würde sich die 
Batterie dabei nicht entladen, Stichwort Energieerhaltung.

Andreas

Andreas Ferber schrieb:
> Was sonst noch für Terme bei der Berechnung der Verluste vorkommen ist
> aber völlig egal, entscheidend ist der eine (mindestens) quadratische
> Term, der in jedem Fall vorhanden ist.

Ergänzend noch: natürlich könnte man jetzt hingehen und eine 
Stromversorgung konstruieren, bei der diese Terme alle kompensiert 
werden. Das wäre aber dann genau das, ein konstruierter Fall, und hätte 
mit normalen Stromversorgungen, mit denen man es meist zu tun hat, wenn 
es auf's letzte bisschen Effizienz ankommt, wie z.B. Batterien und 
Akkus, nicht wirklich viel zu tun.

Andreas

Andreas Ferber schrieb:
> Nimm zwei identische Batterien (gleicher Ladungszustand), und entlade
> sie, einmal mit einem niedrigen und einmal mit einem hohen Strom. Mit
> dem niedrigen Strom wirst du insgesamt mehr Energie aus der Batterie
> ziehen können als mit dem hohen Strom.

Das ist aber nicht unser Testfall.

Nimm zwei identische Batterien und entnimm ihnen gepulst die gleiche
Ladungsmenge, das eine Mal durch längere Entnahme bei geringem Strom,
das andere Mal umgekehrt.  Der Unterschied wird bei weitem nicht mehr
so groß sein wie in deinem Szenario.  Die Energie wird am Innenwider-
stand (größtenteils) nicht verheizt, sondern sie ist beim höheren
Strom nicht entnehmbar, aber dennoch weiterhin vorhanden.  Die
kurzzeitige Entladung gestattet der Batterie längere Erholungsphasen,
sodass sie beim nächsten Entladevorgang wieder "frisch ans Werk"
gehen kann.

Gegenläufig zum von dir genannten Effekt kommt aber hinzu, dass der
Controller selbst bei geringerer Spannung auch eine geringere Strom-
aufnahme hat.

Jörg Wunsch schrieb:
> Gegenläufig zum von dir genannten Effekt kommt aber hinzu, dass der
> Controller selbst bei geringerer Spannung auch eine geringere Strom-
> aufnahme hat.

Ack.

Es bleibt unterm Strich: es kommt darauf an, man muss im Einzelfall 
schauen, was das günstigste ist.

Andreas

Chris schrieb:
> Der ist nochmal einen
> Tick sparsamer.

Aber schlechter verfügbar (im Moment).  Lass ihn doch erstmal den
Rest seines Einsparpotenzials ausreizen, mir scheint, hier geht's
noch lange nicht um das letzte Mikroampere.

@  Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite

>Lass ihn doch erstmal den
>Rest seines Einsparpotenzials ausreizen,

Welche EInsparpotentiale? Der OP und das Forum reden über des Kaisers 
neue Kleider! NICHTS Substantielle! Klarer Fall für Netiquette!!

>mir scheint, hier geht's
>noch lange nicht um das letzte Mikroampere.

Eben. Eh das mal ne Rolle spielt, muss man schon einiges machen. Vor 
allem mal klar kommunizieren.

MFG
Falk

Julian Schild schrieb:
> Ich brauche zur Zeit einen ADC und einen Timer.

Da das die einzige konkrete Aussage bisher ist, guck ich mal in die 
Glaskugel:

Timer mit 32kHz Quarz und ADC alle 100ms auslesen: dürfte als Mittelwert 
etwa 50µA verbrauchen.

Wieviel µA aber gewünscht werden, wäre endlich mal an der Zeit.


Peter

Ich habe den Eindruck, der lässt das Teil im Moment mit "Vollgas"
laufen und wundert sich, dass eine mittlere Batterie nach einem
Tag alle ist...

LOOOL, ich liebe Vermutungen :D.

Ich will da jetzt nicht näher drauf eingehen...


Gibt es von einem ATTINY25 auch eine "Sparversion"?

MFG

Ja, picoPower ist ja soooo offensichtlich....

Außerdem braucht der ATTiny25 Automotive gleich viel wie der normale 
ATTiny25, laut Datenblättern.

http://www.atmel.com/dyn/resources/prod_documents/doc7598.pdf
http://www.atmel.com/dyn/resources/prod_documents/doc2586.pdf

Warum keifen hier alle rum :(
Bin halt kein PRO...

Julian Schild schrieb:
> LOOOL, ich liebe Vermutungen :D.

Klar.  Wir lieben dein Hinterm-Berg-Halten sämtlicher Informationen
auch.

Julian Schild schrieb:
> Ich will da jetzt nicht näher drauf eingehen...

D.h. Du willst garkeine Hilfe.


> Gibt es von einem ATTINY25 auch eine "Sparversion"?

Wenn Du nicht bereit bist, Deine Software daraufhin anzupassen, sparen 
Dir die Sparversionen überhaupt nichts. Im Vollastbetrieb haben sie 
einen ähnlichen Verbrauch.

Das Sparen ist nur dadurch möglich, daß man Baugruppen zeitweise 
abschaltet oder langsamer taktet.


Peter

Natürlich bin ich bereit meinen Code anzupassen.

Im Anhang mein Code. ADU läuft nur während der Wandlung.
Genauso wie der Timer.

;-)
Sind wird überrascht?
Nicht wirklich . . .

Kleiner Tip: Sleep Mode.

Julian Schild schrieb:
> Natürlich bin ich bereit meinen Code anzupassen.

Optimierungsverdächtige Stellen:

1

   for (usiWait;usiWait<1000;usiWait++)

2

    {

3

      for (usiWait2;usiWait2<1000;usiWait2++);

4

      usiWait2=0;

5

    }

6

    usiWait=0;

Naja, wird der Compiler wohl sowieso durch usiWait = 0 ersetzen. ;-)

(Btw., "usi" ist sehr verwirrend: dieser Begriff bezeichnet beim
AVR das universal serial interface.  Aber ungarische Notation ist
sowieso mehr als umstritten.)

Ansonsten sollte an dieser Stelle ein Timer rein, und dann ein
sleep.  Zwar kannst du nur einen idle sleep machen, keinen
powerdown, aber wenn du einen ATmega88 im idle mode mit einem
ATmega8 full speed vergleichst (jeweils CPU-Frequenz 1 MHz), dann
reduzierst du den Stromverbrauch in dieser Zeit von 2,3 mA auf
150 µA, also mehr als den Faktor 10.  Den Oszillator mit 8 MHz
laufen zu lassen, ist unter diese Umständen völlige Energiever-
schwendung, ich würde ihn mit 1 MHz laufen lassen.

Wenn du jetzt noch dem Timer 2 einen 32-kHz-Quarz spendierst, kannst
du stattdessen den power-save sleep mode benutzen.  Das würde den
Stromverbrauch auf 15 µA beim ATmega8 oder 8 µA beim ATmega88
reduzieren.  Dann musst du allerdings auch deinen Primärzeitgeber
von Timer 1 auf Timer 2 umbauen.

1

  while(ADCSRA&(1<<ADSC)) 

2

    {

3

       // auf Abschluss der Konvertierung warten

4

    }

Auch hier ein sleep rein.  Warum willst du in dieser Zeit die CPU
Däumchen drehen lassen?  Hier kannst du den ADC noise reduction
mode benutzen, bei dem gegenüber idle mode der IO-Takt noch
abgeschaltet ist, nur der ADC wird noch getaktet.

All diese Wartezeiten machen den Hauptteil deiner Applikation aus.

Übrigens:

1

ISR(TIMER1_OVF_vect)

2

{  

3

  TCNT1H = 0xE1;              // Reload des

4

  TCNT1L = 0x7C;              // Timer- Register

Dafür haben dir die Atmel-Ingenieure einen CTC-Modus in die Timer
gebaut (clear timer on compare match).

Mein Controller wird jetzt mit einem Spannungsregler versorgt, damit 
sollte das Problem geklärt sein.

Danke Jörg für deine Verbesserungsvorschläge, werde sie umsetzten.
Die for-Schleife wird nicht weg-optimiert :P.
Unter Umständen werd ich hier den Timer verwenden.

Aber leider habt ihr mich nicht ganz verstanden. Schon klar das man mit 
Sleep Modus und so weiter Strom sparen kann, bringt mir aber nichts wenn 
ich Einbrüche hab bei Vollast und somit falsche Ergebnisse bekomme.
Mir ging es darum den Gesamtverbrauch möglichst gering zu halten. Ich 
dachte da an etwaige Peripherie die Standardmäßig läuft.

Julian Schild schrieb:

> Danke Jörg für deine Verbesserungsvorschläge, werde sie umsetzten.
> Die for-Schleife wird nicht weg-optimiert :P.

Zufall.

Wenn du die Variablen usiWait und usiWait2 statt global lokal in die
Funktion schreibst, wird die Schleife weg optimiert.  Der Compiler
schnallt dann, dass sie nichts macht.  Wenn du mit -O3 compilierst,
wird aus der Schleife eine bedingte Zuweisung von 0 an die Variable
usiWait2.

Solide Programmierung würde ich das nicht nennen.  Wenn du partout
CPU-Zyklen verheizen musst, dann guck dir die Routinen aus
<util/delay.h> oder <util/delay_basic.h> an.

> Aber leider habt ihr mich nicht ganz verstanden. Schon klar das man
> mit Sleep Modus und so weiter Strom sparen kann, bringt mir aber
> nichts wenn ich Einbrüche hab bei Vollast und somit falsche
> Ergebnisse bekomme.

Was für "Einbrüche"?  Die paar Millisekunden, die das Ding wirklich
rechnet (oder Mikrosekunden, wenn du mit 8 MHz arbeitest und das
Aufwachen per 32-kHz-Quarz und power-save sleep steuerst), die
pufferst du noch mit einem mittelmäßigen Kondensator; einer Batterie
(selbst einer schwachbrüstigen Lithium-Knopfzelle) geht das am Popo
vorbei.  Was bricht da wo ein, und welches Ergebnis wird verfälscht?

Wenn überhaupt, dann spendiere deinem Sensor einen Spannungsregler,
und zwar einen, den man in den shutdown bringen kann, wenn er nichts
zu sensen hat.  Dann bleibt auch dessen Spannungsversorgung konstant.
Dem AVR ist das reichlich wurscht, mit welcher Spannung der genau
läuft.

> Mir ging es darum den Gesamtverbrauch möglichst gering zu halten.

Der Gesamtverbrauch wird zu 99 % durch deine selbst verschuldet hohe
CPU-Last verursacht.  Der Verbrauch der Peripheriemodule spielt im
Moment noch gar keine Geige.

Bin nur ich, das oder macht ihr mich hier nach Strich und Faden fertig?
Wie oft soll ich noch sagen, dass ich ein Anfänger bin....



Schluff schrieb:
> Deine Anwendung ist so kritisch, daß Dir die Leistung Deines Prozessors
> nicht ausreicht. Daraufhin hast Du ihm einen Spannungsregler verpaßt.
> Dieser bricht aber zusammen, woraufhin Du seinen Code geändert hast, was
> aber zu falschen Ergebnissen führt.
>
> Also ich habe Dich voll verstanden!

Keine Ahnung wie du, das interpretierst, jedenfalls falsch.
Schon der erste Satz stimmt nicht, die Leistung meines Prozessor reicht 
mir sehr wohl aus...aber egal.


Also, als ersters werde ich die Frequenz verringern. Dann den µC während 
der ADU wandelt  in ADC Noise Reduction Mode setzten. Dann werd ich noch 
die delay- Funktionen nutzen. Diese for's sind ja nur dazu da das mein 
Display nicht flackert, sonder alles schön angezeigt wird.
Dann schauen wir mal weiter :). Mir ist aber noch nicht klar wie genau 
das Funktioniert mit "Schlafen legen und wieder aufwecken". Muss mich da 
mal genauer ins Tutorial einlesen.

MFG Julian

nicht haun

Julian Schild schrieb:
> Wie oft soll ich noch sagen, dass ich ein Anfänger bin....

Interessiert nicht die Bohne, wenn du nicht in der Lage bist konkrete 
Zahlen zu nenne such dir ein anderes Hobby.

Julian Schild schrieb:
> Bin nur ich, das oder macht ihr mich hier nach Strich und Faden fertig?

Wer "macht dich fertig"?

> Wie oft soll ich noch sagen, dass ich ein Anfänger bin....

Naja, dann solltest du dir zumindest Bemerkungen wie "LOOOL, ich
liebe Vermutungen :D." verkneifen.  Wenn hier jemand was vermuten
muss, dann liegt es nicht an uns, sondern daran, dass man dir
lange Zeit so ziemlich jedes Detail aus der Nase ziehen muss.
Jemand, der sich Mühe gibt, dir zu helfen, lässt sich nur ungern
auslachen dafür.

> Also, als ersters werde ich die Frequenz verringern.

Das reduziert den Stromverbrauch in gleichem Maße, da CMOS-Logik
nur beim Umschalten Strom braucht.

> Dann werd ich noch
> die delay- Funktionen nutzen.

Die machen deine delays nur voraussagbar, aber Strom sparen sie
natürlich nicht.  Dafür müsstest du schon einen Timer + Sleep
bemühen.

> Mir ist aber noch nicht klar wie genau
> das Funktioniert mit "Schlafen legen und wieder aufwecken". Muss mich da
> mal genauer ins Tutorial einlesen.

Ja, probier das am besten mal an einem einfachen Beispiel.  Danach
kannst du dir ja überlegen, wie du ggf. deine Timer umbauen müsstest.

David ... schrieb:
> Interessiert nicht die Bohne, wenn du nicht in der Lage bist konkrete
> Zahlen zu nenne such dir ein anderes Hobby.

Was für Zahlen????

Jörg Wunsch schrieb:
> Das reduziert den Stromverbrauch in gleichem Maße, da CMOS-Logik
> nur beim Umschalten Strom braucht.

Also bei delay, etc. müsste er nicht mehr so oft umschalten, somit denk 
ich schon, dass er weniger Strom brauchen wird.



Jörg Wunsch schrieb:
> Die machen deine delays nur voraussagbar, aber Strom sparen sie
> natürlich nicht.

Das mach ich nur weil du geschrieben hast:
> Solide Programmierung würde ich das nicht nennen.

Jörg Wunsch schrieb:
> Wer "macht dich fertig"?
Naja nicht wirklich fertig, aber jeder 2. post ist halt irgendetwas 
negatives. Vllt hab ich es ja verdient^^. Aber "lol" hab ich erst 
geschrieben wie ihr mit den Vermutungen angefangen habt...egal.

Julian Schild schrieb:
> David ... schrieb:
>> Interessiert nicht die Bohne, wenn du nicht in der Lage bist konkrete
>> Zahlen zu nenne such dir ein anderes Hobby.
>
> Was für Zahlen????

Wieviel mA liefert deine Stromquelle genau? Um wieviel ist das zu wenig? 
Weitere Verbraucher? usw

@  Julian Schild (jaytharevo)

>Also bei delay, etc. müsste er nicht mehr so oft umschalten, somit denk
>ich schon, dass er weniger Strom brauchen wird.

Denke nie gedacht zu haben, denn das Denken der Gedanken ist 
gedankenloses Denken.

Lies den Artikel Sleep Mode und lerne.

>Naja nicht wirklich fertig, aber jeder 2. post ist halt irgendetwas
>negatives. Vllt hab ich es ja verdient^^.

Eben . . .

> Aber "lol" hab ich erst
> geschrieben wie ihr mit den Vermutungen angefangen habt...egal.

Und wenn du schon dabei bist, dann lies und lerne was über 
Netiquette.

MFG
Falk

Brauch ich für diese Sleep_Modes einen externen Takt oder geht das mit 
dem internen Oszillator? Irgendwie ist, das nicht ganz ersichtlich.

MFG

Das IST ersichtlich.

Ich warte immernoch auf eine Antwort.

Hey,
jetzt melde ich mich mal wieder. Ich würde gern mein "optimiertes" 
Programm posten und von euch wissen was ihr denkt oder wo ich eventuell 
noch ein wenig mehr raus holen kann.


Eins ist mir bewusst, ich verwende "nur" den Idle Mode, da nicht die 
Möglichkeit habe den Timer2 asynchron laufen zu lassen, deswegen lasst 
mal den verwendeten Modus links liegen ;).

Und noch etwas, die Timer1 Overflow routine ist auch noch nicht ganz 
fertig.


MFG Julian

@  Julian Schild (jaytharevo)

>    * DA_Program_optimized.c (7,9 KB, 3 Downloads) | Codeansicht

Besser, aber immer noch reichlich vermurkst.

>noch ein wenig mehr raus holen kann.

Sicher. Zum ersten macht man beim AVR keinen Timer Reload sondern nutzt 
den CTC Modus.

Weiterhin sind deine wild und reichlich verteilten

vWait_Timer0();

ziemlicher Quark. Wie man es richtig macht findest du im Artikel [[Sleep 
Mode]].

Ausserdem ist es unnötig und kontraproduktiv, das LCD immer wieder 
komplett zu löschen. Das Überschreiben der Werte reicht und ist deutlich 
schneller.

>Und noch etwas, die Timer1 Overflow routine ist auch noch nicht ganz
>fertig.

Und warum präsentierst du dann hier halbgare Sachen?

MfG
Falk

Falk Brunner schrieb:
> Besser, aber immer noch reichlich vermurkst.

Wow, der berühmte Schlag ins Gesicht.


> Sicher. Zum ersten macht man beim AVR keinen Timer Reload sondern nutzt
> den CTC Modus.

Hum, finde ich nicht weniger umständlich wenn ich verschiedene 
Wartezeiten mit einem Timer habe.


> Weiterhin sind deine wild und reichlich verteilten
> vWait_Timer0();
> ziemlicher Quark. Wie man es richtig macht findest du im Artikel Sleep
> Mode.

Der Timer0 kann bei größtmöglichem Prescaler und einem Takt von ~1.8MHz 
nur maximal ~142ms laufen bis zum Overflow. Um jedoch eine Sekunde 
zuerreichen muss dieser halt öfters aufgerufen werden.

> Ausserdem ist es unnötig und kontraproduktiv, das LCD immer wieder
> komplett zu löschen. Das Überschreiben der Werte reicht und ist deutlich
> schneller.

Hum, das wusste ich nicht, dachte ich muss vor jeder Änderung das 
Display löschen.

> Und warum präsentierst du dann hier halbgare Sachen?

Da die Erweiterung kaum Einwirkung auf das Energiesparen hat.
Was noch fehlt: Wenn 1min vergangen ist soll der µC wiederrum schlafen 
gelegt werden und bei einem Rising Edge Flanke auf PB0 (ICP) wieder 
aufwachen und schaun ob sich die Frequenz die am Port anliegt zwischen 
500 und 1000kHz liegt.

Julian Schild schrieb:
> Falk Brunner schrieb:
>> Besser, aber immer noch reichlich vermurkst.
>
> Wow, der berühmte Schlag ins Gesicht.

Naja, Falk ist manchmal ein diplomatisches Trampeltier...

>> Sicher. Zum ersten macht man beim AVR keinen Timer Reload sondern nutzt
>> den CTC Modus.

> Hum, finde ich nicht weniger umständlich wenn ich verschiedene
> Wartezeiten mit einem Timer habe.

Es geht hier nicht darum, ob es umständlich ist, sondern ob es
korrekt (im Sinne des erzielten Timings) ist.  Das ist die
Nachlademethode nicht, da du eine Interruptlatenz hast, die dort
mit reinzählt, während sich beim CTC-Modus die Hardware darum
kümmert, dass beim Erreichen des Zählerwertes augenblicklich der
Zähler gelöscht wird.

Die Interruptlatenz mag bei einem sehr einfachen Setup kalkulierbar
sein, aber bei größeren Projekten ist sie es nicht mehr, insofern
sollte man sich diese Krücke gar nicht erst angewöhnen.  (Ganz früher
gab's mal noch keinen CTC-Modus beim AVR, da ging es nicht besser.)

> Der Timer0 kann bei größtmöglichem Prescaler und einem Takt von ~1.8MHz
> nur maximal ~142ms laufen bis zum Overflow. Um jedoch eine Sekunde
> zuerreichen muss dieser halt öfters aufgerufen werden.

Das kann man im Timerinterrupt selbst erledigen.

@  Julian Schild (jaytharevo)

>> Besser, aber immer noch reichlich vermurkst.

>Wow, der berühmte Schlag ins Gesicht.

Die ungeschminkte Wahrheit.

>> Sicher. Zum ersten macht man beim AVR keinen Timer Reload sondern nutzt
>> den CTC Modus.

>Hum, finde ich nicht weniger umständlich wenn ich verschiedene
>Wartezeiten mit einem Timer habe.

;-)
Wirklich? Nicht wirklich.

>Der Timer0 kann bei größtmöglichem Prescaler und einem Takt von ~1.8MHz
>nur maximal ~142ms laufen bis zum Overflow. Um jedoch eine Sekunde
>zuerreichen muss dieser halt öfters aufgerufen werden.

Richtig, aber das macht man anders, allein schon aus ästhetischen 
Gründen. Vom sinnvollen und formal richtigen Programmablauf mal ganz zu 
schweigen.
Man zählt im Interrupt eine Variable hoch, z.B. im 10ms Raster. Damit 
kann man dann im Hauptprogramm entsprechende Aktionen ableiten.

>Hum, das wusste ich nicht, dachte ich muss vor jeder Änderung das
>Display löschen.

So ein LCD ist keine Kreidetafel ;-)

MFG
Falk

Hallo,
da bin ich wieder um zu nerven :D.

Jörg Wunsch schrieb:
> Es geht hier nicht darum, ob es umständlich ist, sondern ob es
> korrekt (im Sinne des erzielten Timings) ist.  Das ist die
> Nachlademethode nicht, da du eine Interruptlatenz hast, die dort
> mit reinzählt, während sich beim CTC-Modus die Hardware darum
> kümmert, dass beim Erreichen des Zählerwertes augenblicklich der
> Zähler gelöscht wird.

Das wird richtig sein, aber es geht mir ja nicht um die letzten 3ms da 
es hier um keine Zeit kritische Anwendung geht. Beim einen zum Beispiel 
soll einfach gewartet werden, dass das Display nicht flackert. Aber, da 
ich ja ein bisschen perfektionistisch bin (mag auf den ersten Blick vllt 
nicht erkennbar sein :P) werde ich mir den CTC Modus auch noch 
anschauen.

Falk Brunner schrieb:
> So ein LCD ist keine Kreidetafel ;-)

Also wann müsste ich nun, das Display konkret löschen?

MFG Julian

@  Julian Schild (jaytharevo)

>Also wann müsste ich nun, das Display konkret löschen?

Nahezu niemals.

MFG
Falk

Dann werd ich es einmal beim Willkommen machen und dann einfach nicht 
mehr^^

Falk Brunner schrieb:

>>Also wann müsste ich nun, das Display konkret löschen?
>
> Nahezu niemals.

Allgemein: wenn du nicht mehr entscheiden kannst, was die vorange-
gangenen Schritte ggf. an Müll auf dem Display hinterlassen haben
könnten und damit nicht genau weißt, wo du überall jetzt drüber
schreiben musst (eine einzelne Stelle kann man ja durch Überschreiben
mit einem Leerzeichen löschen).

Bei deiner einfachen Applikation ist das aber vermutlich immer
deterministisch.

Jörg Wunsch schrieb:
> Nahezu niemals.

Blödsinn, meine clrs() sind essentiell. Ich habe die weggelassen, dass 
Resultat war, wie ich es mir gedacht hatte, Blödsinn. Wenn ich nach 
einem langem String einen kurzen schreibe, bleibt das vorherige soweit 
stehen soweit der kurze ihn nicht überschrieben hat. Mit Leerzeichen 
auffüllen wäre natürlich auch eine Möglichkeit, aber warum dann nicht 
gleich löschen?



Anbei mein überarbeiteter Code.

Nach einem Edit kann ich leider keine Datei mehr anhängen.

@Julian Schild (jaytharevo)

>Blödsinn, meine clrs() sind essentiell.

Du bist ja auch der grosse Programmiermeister.

>einem langem String einen kurzen schreibe, bleibt das vorherige soweit
>stehen soweit der kurze ihn nicht überschrieben hat.

Niemand hat was anderes bahuptet. Aber das Problem ist leicht ohne clr 
und komplettes Neuschreiben des LCD lösbar.

> Mit Leerzeichen
>auffüllen wäre natürlich auch eine Möglichkeit, aber warum dann nicht
>gleich löschen?

Weil das clr zu lange dauert, nämlich ~1,4ms. Klingt wenig, ist aber 
viel, wenn an der falschen Stelle im Programm steht. Ausserdem flackert 
die Anzeige beim kompletten Löschen und Neuschreiben. Beim Überschreiben 
(auch mit Leerzeichen zu füllen) nicht.

MfG
Falk

@  Julian Schild (jaytharevo)

>    * DA_Program_optimized.c (7,9 KB, 1 Downloads) | Codeansicht

Deine neue Version ist nicht wirklich besser.

Sag mal in Worten, was dein uC tun soll, dann kann ich dir vielleicht 
das Programm so schreiben, wie man es richtig macht.

MFG
Falk

Haha, langsam gewöhnt man sich ja doch an deinen Charme ;).
Spaß bei Seite, finde ich gut, dass du hier nicht um den heißen Brei 
redest.


Naja um was geht es.
Ich habe 2 Spannungen. Die eine Spannung steht für eine Leistung die 
andere ob die erste richtig ist (hört sich dumm an, hängt mit der 
Linearität eines ICs zusammen). Wenn die zweite Spannung >1,2V ist muss 
ich aufhören das erste zuwandeln. Sollte die erste Spannung aber richtig 
sein, dann muss die Leistung berechnet werden und zwar über einen 
gleitenden Mittelwert. Die Leistung entspricht 4W/1V. Soll heißen, dass 
wenn der ADU 1V wandelt dies 4W entspricht. Diese 4W sollten, dann auch 
am LCD ausgegeben werden.
Weiters soll solange die zweite Spannung <1,2V im Hintergrund ein Timer 
laufen, welcher nach 1min am PortC Pin4 ein Abschaltsignal senden soll 
(soll einfach High werden).
Nach dem abgeschalten wurde soll der µC sich schlafen legen und auf 
einen Interrupt warten der von der Input Capture Unit ausgelöst werden 
soll.
Am ICP Pin soll, dann die Frequenz festgestellt werden. Wenn sie 
zwischen 600 und 700Hz liegt darf er das Ganze wieder von vorne machen 
wenn nicht wieder schlafen gehen.

Hoffe, dass ist genau genug beschrieben.

MFG Julian

@  Julian Schild (jaytharevo)

>Ich habe 2 Spannungen. Die eine Spannung steht für eine Leistung die
>andere ob die erste richtig ist (hört sich dumm an, hängt mit der
>Linearität eines ICs zusammen).

Fällt mit zwar schwer das so zu glauben, aber das wollen wir einfach mal 
annehmen.

> Wenn die zweite Spannung >1,2V ist muss
>ich aufhören das erste zuwandeln.

Wie aufhören?

> Sollte die erste Spannung aber richtig
>sein, dann muss die Leistung berechnet werden und zwar über einen
>gleitenden Mittelwert.

Über wieviel Werte soll die Mittelwertbildung erfolgen? Welche 
Abtastrate?

>Weiters soll solange die zweite Spannung <1,2V im Hintergrund ein Timer
>laufen, welcher nach 1min am PortC Pin4 ein Abschaltsignal senden soll
>(soll einfach High werden).

Also wenn die 2. Spannung für 1min <1,2V ist, schaltet der uC ab. Und 
was ist, wenn zwischenduch einmal eine Messung >1,2V ist?

>Nach dem abgeschalten wurde soll der µC sich schlafen legen und auf
>einen Interrupt warten der von der Input Capture Unit ausgelöst werden
>soll.

Das ist leicht.

>Am ICP Pin soll, dann die Frequenz festgestellt werden. Wenn sie
>zwischen 600 und 700Hz liegt darf er das Ganze wieder von vorne machen
>wenn nicht wieder schlafen gehen.

Auch leicht.

>Hoffe, dass ist genau genug beschrieben.

Programmieren braucht viele Details ;-)

MFG
Falk

P S Ich werd mich in den nächsten Tagen mal dransetzen.

Hallo,
haha ich find das so lustig das du mir da mal meine Diplomarbeit 
programmierst. Wenn ich denk, das ich vor einem halben Jahr bei 0 
angefangen hab und eigentlich bis ca. 120h investiert hab und du sagst 
so einfach,

"> P S Ich werd mich in den nächsten Tagen mal dransetzen."


Nun zu deinen Fragen:

Falk Brunner schrieb:
> Fällt mit zwar schwer das so zu glauben, aber das wollen wir einfach mal
> annehmen.

Der IC heißt LM13700 und ist ein so genannter Steilheitsintegrator (so 
heißt der glaub ich). Jedenfalls richtet der mir die Spannung so, dass 
ich sie nachher verarbeiten kann.

Falk Brunner schrieb:
> Wie aufhören?

Naja, da die zweite Spannung anzeigt, dass die erste ein Blödsinn ist 
soll diese so lange nicht mehr gewandelt werden und auch nicht am LCD 
angezeigt werden, so lange die zweite Spannung >=1,2V ist.

Falk Brunner schrieb:
> Über wieviel Werte soll die Mittelwertbildung erfolgen? Welche
> Abtastrate?

4.
Der Abtastrate hab ich gar nicht so viel Aufmerksamkeit geschenkt, da 
diese bereits über einen Kondensator integriert wurde.

Falk Brunner schrieb:
> Also wenn die 2. Spannung für 1min <1,2V ist, schaltet der uC ab. Und
> was ist, wenn zwischenduch einmal eine Messung >1,2V ist?

Dann muss der Zähler für die eine Minute wieder zurückgestezt werden und 
von neuem begonnen werden mit zählen.

Falk Brunner schrieb:
> Das ist leicht.
> Auch leicht.

Das freut mich. Das ICP hab ich ja noch überhaupt nicht durchschaut.

An dieser Stelle mal ein "DANKE" an dich Falk.

MFG Julian

Ich werde das Programm natürlich NICHT übernehmen.
Es interessiert mich nur wie Falk, dass programmieren würde
da er anscheinend nicht lang benötigen wird.

Du kannst ihn doch allemal als Quelle mit angeben. ;-)

So, hier mal der Entwurf. Kompiliert fehlerfrei, ist aber logischerweise 
nicht getestet, da ich die Hardware nicht hab. Das Prinzip sollte aber 
klar werden. Statemachine, saubere Struktur.

Ein paar Anmerkungen.

Deklarationen immer in .h Files, nicht in .c, sauberer Stil
Konstanten als #define in die Header schreiben, keine "magic numbers" im 
Quelltext.
Deine Mittelwertberechnung ist ungenau, erst alles addieren, dann 
dividieren, siehe Festkommaarithmetik.
Besonders auf Mikrocontrollern streng definiert Datentypen aus stdint 
nutzen, unsigend short int kann 8 oder 16 Bit sein, einer der vielen 
Diffusitäten von C.
ADC lesen mit Zugriff auf ADCW
Die Aufgabe ist LOCKER mit einem 8-Bit Timer lösbar, der wertvole 16 Bit 
Timer 1 muss hier nicht verplempert werden.
Wenn man einen 32kHz Uhrenquarz am Timer 2 asynchron laufen lässt, kann 
man noch mal RICHITG Strom sparen, siehe Sleep Mode
Was noch fehlt ist das Auswerten der Frequenz nach dem wiederaufwachen.

MFG
Falk

Hallo,
bin beeindruckt. Aber warum ist deine Variante nun besser als meine?
Ich bin leider noch nicht dazu gekommen es zu probieren, werde es aber 
so bald als möglich nach holen. Nächste Woche stehen eh die Osterferien 
vor der Tür :).

Falk Brunner schrieb:
> Wenn man einen 32kHz Uhrenquarz am Timer 2 asynchron laufen lässt, kann
> man noch mal RICHITG Strom sparen, siehe Sleep Mode

Wie geasgt, ist nicht mehr möglich, da Schaltung fest steht.


MFG Julian

@  Julian Schild (jaytharevo)

>bin beeindruckt. Aber warum ist deine Variante nun besser als meine?

Weil sie von mir ist ;-)

>Ich bin leider noch nicht dazu gekommen es zu probieren,

Viel wichtiger ist das VERSTEHEN! Dann wird dir vielleicht auch klar, 
warum sie besser ist.

MfG
Falk

1

            case power_down:

2

                sleep_mode();

3

                state = resync;

Kann mir nicht vorstellen das ich den state noch nach dem aktivieren des 
Schlafmodus verändern kann. Oder doch?

Ich bin gerade dabei ICP zu implementieren. Jetzt hab ich eine Frage. 
Muss der Timer1 eig die ganze Zeit laufen? Blödsinn oder?

1

ISR( TIMER1_CAPT_vect )

2

{TCCR1B = (1<<CS10);    // Timer aktivieren ohne Prescaler

3

iZaehlerStand=TCNT1L;

4

iZaehlerStand += (TCNT1H<<8);

5

}

Nachdem rising edge gekommen ist einfach den Timer anwerfen oder?

MFG

@  Julian Schild (jaytharevo)

1

            case power_down:

2

                sleep_mode();

3

                state = resync;

>Kann mir nicht vorstellen das ich den state noch nach dem aktivieren des
>Schlafmodus verändern kann. Oder doch?

Nach dem wieder Aufwachen passiert das.

>Ich bin gerade dabei ICP zu implementieren. Jetzt hab ich eine Frage.
>Muss der Timer1 eig die ganze Zeit laufen?

Ja.

> Blödsinn oder?

Nö.

>ISR( TIMER1_CAPT_vect )
>{TCCR1B = (1<<CS10);    // Timer aktivieren ohne Prescaler
>iZaehlerStand=TCNT1L;
>iZaehlerStand += (TCNT1H<<8);

Lass den unsinnigen 8 Bit Zugriff! Dafür gibt es TCNT1, das ist der 
Timer als 16 Bit Variable. Der GCC kümmert sich darum.

>Nachdem rising edge gekommen ist einfach den Timer anwerfen oder?

Nöö, laufen lassen. Die Differenz der Zeiten zwischen zwei (rising edge) 
Interrupts ist gleich der Periodendauer.

MfG
Falk

Falk Brunner schrieb:
> Nöö, laufen lassen. Die Differenz der Zeiten zwischen zwei (rising edge)
> Interrupts ist gleich der Periodendauer.

Ja, deswegen kommt es mir etwas unsinnig vor den Timer1 die ganze Zeit 
laufen zu lassen. Ich mein wenn meine Schaltung über Nacht wartet bis 
das Einschaltsignal kommt dann gibts ja zig tausend Überläufe. Außerdem 
würde der µC auch jedes mal aufwachen und dann erst wieder schlafen 
gehen...

Etwaige Messungenauigkeiten sind mir egal. Ich frag mich nur ob das 
laufen des Timers notwendig ist um die rising Edge zu erfassen.

@  Julian Schild (jaytharevo)

>> Nöö, laufen lassen. Die Differenz der Zeiten zwischen zwei (rising edge)
>> Interrupts ist gleich der Periodendauer.

>Ja, deswegen kommt es mir etwas unsinnig vor den Timer1 die ganze Zeit
>laufen zu lassen.

Muss er aber. Das ist ja schliesslich deine Zeitbasis für die 
Frequenzmessung.

> Ich mein wenn meine Schaltung über Nacht wartet bis
>das Einschaltsignal kommt dann gibts ja zig tausend Überläufe.

Das tut dem Timer nicht weh.

> Außerdem
>würde der µC auch jedes mal aufwachen und dann erst wieder schlafen
>gehen...

Nöö, wer sagt denn, dass der Timer Overflow einen Interrupt auslösen 
muss? Das muss nur die ICP Funktion. Kann man alles einstellen.

>Etwaige Messungenauigkeiten sind mir egal.

Warum misst du dann überhaupt?

> Ich frag mich nur ob das
>laufen des Timers notwendig ist um die rising Edge zu erfassen.

EINE Flanke kann man auch ohne Timer erfassen. Das kann beim ATmega8 
aber nur die INT Pins. Beim pinkompatiblen ATmega88 kann an jedem Pin 
ein Flankenwechsel erfasst werden, Pin Change Interrupt.
Aber für eine Periodendauermessung ist ICP schon das Mittel der Wahl.

MFG
Falk

Falk Brunner schrieb:
> Warum misst du dann überhaupt?

Weil es egal ist ob bei der Messung 600 oder 800 Hz heraus kommt, 
solange es in einem gewissen Bereich liegt ist alles in Butter.

Falk Brunner schrieb:
> EINE Flanke kann man auch ohne Timer erfassen. Das kann beim ATmega8
> aber nur die INT Pins.

Die sind leider bereits durch das Display belegt. Außerdem soll dir 
Frequenz zu Fehlererkennung dienen. Der Controller soll nicht durch 
jedes beliebige Signal eingeschalten werden.

Also noch mals.
Ist es möglich die rising edge zu erfassen OHNE das der Timer1 im 
Hintergrund die GANZE Zeit laufen muss oder ist es GRUNDSÄTZLICH NICHT 
möglich?


MFG Julian

@  Julian Schild (jaytharevo)

>Ist es möglich die rising edge zu erfassen OHNE das der Timer1 im
>Hintergrund die GANZE Zeit laufen muss

Sicher, aber dann muss die CPU in einer Art Endlosschleife das Pin 
abfragen. Nicht wirklich stromsparender.
Wo ist das Problem mit dem laufenden Timer1?

MfG
Falk

Hallo,
ok du wirst mich dafür zwar an den Pranger stellen Falk, aber ich muss 
schauen, dass ich das Programm fertig bekomme. Deswegen ist es zur Zeit 
sehr umständlich und nicht schön programmiert (Interrupts sollten nie so 
lange sein, viele variablen,...). Falls ich noch ein mal die Zeit habe 
werde ich es besser schreiben. Aber im Moment steht halt die 
Fertigstellung im Vordergrund. Deswegen schau bitte noch einmal drüber 
ob es so funktionieren KÖNNTE.


Danke.

MFG Julian

@  Julian Schild (jaytharevo)

>ok du wirst mich dafür zwar an den Pranger stellen Falk,

Viel schlimmer. Ich strafe dich mit Ignoranz.

> aber ich muss
>schauen, dass ich das Programm fertig bekomme.

Jaja.

> Deswegen ist es zur Zeit
>sehr umständlich und nicht schön programmiert (Interrupts sollten nie so
>lange sein, viele variablen,...). Falls ich noch ein mal die Zeit habe
>werde ich es besser schreiben.

Wenn du es eilig hast, gehe langsam.

Konfuzius

Mit diesem "mal schnell fetig machen, hab keine Zeit für Schönschreiben" 
wirst du immer wieder richtg schön auf Maul fallen. Viel Spass dabei.

> Aber im Moment steht halt die Fertigstellung im Vordergrund.

> Deswegen schau bitte noch einmal drüber ob es so funktionieren KÖNNTE.

pah

lulz.....

Edit: Außerdem, um es besser zu schreiben müsste ich es so machen wie 
du, also mit dem Switch und du wirst doch verstehen, dass ich dein 
Programm nicht abkupfern kann, oder nicht?

Wieso abkupfern? Und der switch() ist nicht patentgeschützt.
Nimm mein Programm und bau die Frequenzmessung sauber ein.

Falk Brunner schrieb:
> Nimm mein Programm und bau die Frequenzmessung sauber ein.

Genau DAS ist doch abkupfern. Ich kann ja nicht das von dir geschriebene 
Programm nehmen. Dann kann ich gleich meinen 5er abholen....

@  Julian Schild (jaytharevo)

>> Nimm mein Programm und bau die Frequenzmessung sauber ein.

>Genau DAS ist doch abkupfern. Ich kann ja nicht das von dir geschriebene
>Programm nehmen. Dann kann ich gleich meinen 5er abholen....

Erzähl keinen Unsinn. Willst du es per Hand abschreiben?
Setz ne Quellenangabe in deine Arbeit und gut. Auch in einer 
Diplomarbeit darf man sich helfen lassen.
Der Anteil an Eigenleistung in einer Diplomarebit ist nicht 100%, 20% 
und bisweilen weniger sind OK, hab ich mal gehört.
Schliesslich hast du den uC auch nicht selber gebaut.

MFG
Falk

Falk Brunner schrieb:
> Setz ne Quellenangabe in deine Arbeit und gut. Auch in einer
> Diplomarbeit darf man sich helfen lassen.

Sehe ich auch so.

Natürlich solltest du aber verstanden haben, was eine "state
machine" (dt.: zustandsgesteuerter Automat) ist und warum der
switch sinnvoll benutzt wird, um eine solche zu implementieren.
Sonst könnte es sein, dass dir das einer in der Verteidigung als
peinliche Frage stellt...

Falk was für eine lcd.h verwendest du?

Ich bekomme lauter Fehler beim kompilieren. Lauter unidefined references 
die mit dem LCD zu tun haben.

@  Julian Schild (jaytharevo)

>Falk was für eine lcd.h verwendest du?

Die aus dem Tutorial. Musst du halt wieder auf deine etwas anderen 
Funktionsnamen umschreiben.

MfG
Falk

Hoi,
hatte nur die lcd.c Datei nicht eingebunden.
Jetzt bekomm ich aber einen anderen Fehler:

>make: *** No rule to make target `../../DA', needed by `lcd.o'.  Stop.

Kannst du damit was anfangen?

Problem wurde behoben.

Hab dein Programm probiert, geht nicht sonderlich. Kommt über Willkommen 
nicht raus. Blinkt fröhlich vor sich hin.

@  Julian Schild (jaytharevo)

>Hab dein Programm probiert, geht nicht sonderlich. Kommt über Willkommen
>nicht raus. Blinkt fröhlich vor sich hin.

Ist schon wirklich schlimm, dass die Lösung nicht fix und fertig auf dem 
Silbertablett serviert wird. Und lesen ist auch ncht deine Stärke.

Beitrag "Re: Stromsparen und Atmega8?"

Und DU willst eine DIPLOMARBEIT schreiben? So wie du hier rummjammerst 
und dich anstellst ist das nicht mal Praktikanenniveau!

Falk Brunner schrieb:
> Ist schon wirklich schlimm, dass die Lösung nicht fix und fertig auf dem
> Silbertablett serviert wird.

Ist mir klar, es sind wären einige Dinge zu ändern. Trotz einiger 
Versuche kommt er nicht über Willkommen hinaus.
Hab einiges versucht. Code auskommentieren, neuen schreiben,... ändert 
sich nicht viel. Timer0 Überlauf kommt. Was übersehe ich?

>Und lesen ist auch nicht deine Stärke.

In deinem Beitrag schreibst du lediglich wie man es machen sollte.


>Und DU willst eine DIPLOMARBEIT schreiben? So wie du hier rummjammerst
>und dich anstellst ist das nicht mal Praktikantenniveau!

:(

Julian Schild schrieb:
> Blinkt fröhlich vor sich hin.

Was heißt das denn genau?  Ist ja keine LED dran, die blinken könnte...

Falls du den Cursor des LCD meinst: das macht der Controller im LCD
selbst, dafür braucht man keine Interaktion vom Master.

Nein, das Willkommen blinkt.

In Falks Programmrumpf fehlt meiner Erinnerung nach noch irgendeine
ISR (in die du natürlich deinen eigenen Code reinbringen musst).
Dadurch springt das Programm bei jedem Interrupt wieder an Adresse 0.

1

// Interrupt bei Timer0 Overflow

2

ISR(TIMER0_OVF_vect) {  

3

    static uint8_t tick;

4

5

    PORTB = ~PORTB;                     // Kontrollausgabe ob Timer Überlauf kommt

6

7

    tick++;

8

    if(tick==15) {                      // ~0.5 Sekunde 

9

        tick=0;

10

        flag_timer=1;

11

    }

12

}

Hat er doch. oO
Oder meinst du etwas anderes :)?

Irgendwo macht der Controller einen powerdown, daraus muss er doch
wieder aufwachen.  Habe mir nicht die Mühe gegeben, alles darin zu
verstehen.

Wurde ausgebessert auf IDLE Mode.
Komisch komisch....

Werde wohl schon wieder mit Ignoranz bestraft :(.

Vllt könnte sich unser Falk durchringen und mir sagen was ich übersehe 
:).

BITTE BITTE BITTE BITTE BITTE :)

MFG

Er hat deine Schaltung doch auch nicht (und wird sie sicher auch nicht
aufbauen extra für dich).

Du kennst die alte Regel der Softwareerstellung?  Die ersten 90 % des
Projekts nehmen 90 % der Zeit in Anspruch.  Die verbliebenen 10 %
brauchen dann jedoch nochmal 90 %.  Irgendwo an der Stelle bist du
gerade.

Da hilft dann kein Draufgucken mehr, sondern nur noch debuggen.  Da
du mit einem ausreichend altertümlichen Controller ins Rennen gegangen
bist, der kein Online-Debugging kann, musst du dich wohl oder übel
mit einer Simulation rumquälen.  Oder du schmeißt den alten ATmega8
doch noch raus und nimmst einen ATmega88 und einen AVR Dragon, dann
kannst du das am "lebenden Objekt" angucken.

Schuld an dem ständigen wiederholen war die ADU- Konfiguration. Nachdem 
ich sie neu geschrieben hab hat es funktioniert.

Hab jetzt auch eine "saubere" Statemachine programmiert.
Werd sie nach ein paar "Schönheitskorrekturen" hier reinstellen falls 
Interesse besteht.

MFG Julian

@  Julian Schild (jaytharevo)

>Hab jetzt auch eine "saubere" Statemachine programmiert.

Schön.

>Werd sie nach ein paar "Schönheitskorrekturen" hier reinstellen falls
>Interesse besteht.

Tu das.

MfG
Falk

HA! Ich wusste doch du schaust noch zu ;).

Boa, freu ich mich auf dein Kommentar wie ich, dass schon wieder 
vermurkst hab.
Jetzt kann ich das Programm auch ohne Gewissensbisse nehmen, da kaum 
noch was von dir ist.

Jetzt bin ich mal gespannt wie ein Flitzebogen ;) xD!

Wie immer Falk, die ungeschminkte Wahrheit, danke!

MFG Julian

@  Julian Schild (jaytharevo)

>Wie immer Falk, die ungeschminkte Wahrheit, danke!

Nun ja. Es bewegt sich in die richtige Richtung. Allerdings fehlt wieder 
ein gutes Stück, dass ich dir eigentlich schon mal gut gezeigt habe.
Und dieses unsinnige vWait_Timer0() ist auch wieder drin! NEIN! Der 
Timer läuft immer. Und man muss nicht dauernd den Presclaer umstellen. 
Wie das sinnvoll geht, habe ich gezeigt.

Was auch das Lesen erschwert sind die vermurksten Tabulatoren. Man 
sollte seine Editor so einstellen, dass der keine Tabulatoren erzeugt, 
sondern Leerzeichen.
Dann gibt es auch keine Darstellungsprobleme mit der Einrückung, wenn 
ein anderer Editor auf einen anderen Tabulatorabstand eingestellt ist.

Von mir würdest du eine 3- bekommen.

MFG
Falk

Wow, richtige Richtung :D! Wohooo!
Die 3- bekomme ich nur wegen dem "vermurkstem" Timer?

Wieso ist, dass so schlecht? Ich mein, dass macht die Sache doch um 
einiges einfacher und den Timer1 muss ich sowieso wegen ICP verwenden.

@  Julian Schild (jaytharevo)

>Die 3- bekomme ich nur wegen dem "vermurkstem" Timer?

Im Wesentlichen ja.

>Wieso ist, dass so schlecht?

Weil man den Timer nicht grundlos dauern ein. und aus schaltet.

> Ich mein, dass macht die Sache doch um
>einiges einfacher

Keine Sekunde.

> und den Timer1 muss ich sowieso wegen ICP verwenden.

Eben DESHALB muss der Timer immer laufen!

MFg
Falk