Hallo,
ich arbeite an einem Projekt welches sehr leistungskritisch ist.
Meine Versorgungsspannung bricht mir leider stark ein, meine Frage nun,
gibt es irgendwelche Möglichkeiten beim ATMEGA8 Strom zu sparen?
Vllt zusätzliche Hardware auszuschalten?
Ich brauche zur Zeit einen ADC und einen Timer.
MFG Julian
Höchste Leistungseffizienz erreicht man immer durch ein ausgereiftes
Energiekonzept.
Ein Zusammenbruch der Versorgungsspannung ist nicht evident, solange der
Benutzer nicht zusammenbricht.
Konkrete Frage - konkrete Antwort!
Bricht dir die Spannung im Betrieb ein und "erholt" sich wieder, oder
betreibst du das Ganze aus einem Akku und willst einfach die "Laufzeit"
verlängern?
Wenn Deine Versorgung wirklich so labol ist, dass diese ein Atmega8 zum
Einbrechen bringt, dann nusst Du diese verstaerken.
Ich allerding glaube meiner Glaskugel entnehmen zu koennen, dass fuer
solche Probleme meistens die Peripherie verantwortlich ist.
Also lass mal sehen, was alles aus der Versorgungsspannung betrieben
wird.
Gast
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
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.
--> das ist auf jeden Fall ein Ansatz!
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.
>Die Stromaufnahme ja, der Energieverbrauch nicht. Geht ja alles>entsprechend langsamer.
klar, im Prinzip schon, wenn der Controller dadurch doppelt so lange
rechnen muss, aber wenn der Controller softwaremässig irgendwo an einer
Abfrage "hängt" und z.B auf einen Tastendruck wartet, dann braucht er in
dieser Zeit weniger Strom wobei die Zeit zwischen den "Aktionen" von
externen Ereignissen gesteuert und somit konstant bleibt.
Daher kann doch schon von einer Reduzierung ausgegangen werden.
Letztendlich rührt die Verlustleistung eines Controllers ja von den
Umschaltvorgängen in den Registern her. Und wenn pro Zeiteinheit weniger
davon durchgeführt werden, dann sinkt die mittlere Stromaufnahme.
oder anderes Beispiel:
Wenn der Controller eine bestimmte, konstante zeit läuft und immer
wieder die gleiche Berechnung durchführt, es aber für die Applikation
ausreichend ist, wenn der Controller in der bestimmten Zeiteinheit die
Berechnung nur halb so oft durchführt, dann kann man mit der Reduzierung
des Taktes durchaus Strom (oder Energie) sparen...
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
Jörg Wunsch schrieb:
> Die Stromaufnahme ja, der Energieverbrauch nicht. Geht ja alles> entsprechend langsamer.
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.
Ob das mit der Aussage von Andreas zu erklären ist, weiß ich aber nicht.
>Da wurden Tests gemacht, die zeigten, dass es (energietechnisch) günstiger >ist,
kurze aber schnelle Operationen durchzuführen, als längere, langsamere.
Kann ich aus eigenen Messungen ebenfalls bestätigen.
@jaytharevo:
Schalte alles an Peripherie im Controller ab, was Du gerade nicht
brauchst und nur dann kurz an wenn Du es benötigst.
Schau dir mal den ATmega88PA an. Das wäre genau der richtige Controller
für dich. Der ist zwar in D kaum erhältlich, aber vielleicht hast Du ja
die Möglichkeit bei Digikey oder Mouser (mit) zu bestellen.
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
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.
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:
> 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.
leider gibt es da auch wieder ein extrem. Wenn ich die Batterie mit
einem unentlich grossen Widerstand entlade, dann habe ich keine Energie
entnommen und die Batterie ist auch irgendwann leer.
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
>Tja mangels Erfahrung (halbes Jahr im µC Bereich unterwegs), hab ich>eben einen ATMEGA8 und keinen 88P.
Wenn schon, dann keinen 88P, sondern einen 88PA. Der ist nochmal einen
Tick sparsamer.
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
moin
zBsp.:
ACD: Analog Comparator Disable
+
enter ADC Noise Reduction mode, stopping the CPU but allowing the ADC,
the external interrupts, the
Two-wire Serial Interface address watch, Timer/Counter2 and the Watchdog
to continue
Mehr fällt mir dazu jetzt nicht ein.
mal das Datenblatt durchforsten !
mfg
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
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
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.
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!
> LOOOL, ich liebe Vermutungen :D.
und ich erstmal.
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
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
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.
@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
Julian Schild schrieb:
> haha ich find das so lustig das du mir da mal meine Diplomarbeit> programmierst
Ist jetzt bitte nicht dein Ernst, oder? Falls doch, so hoffe ich sehr
für dich, dass Du hier nicht unter deinem richtigen Namen postest.
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.
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
Moin,
schau mir das Programm jetzt sicher schon zum 5. mal durch, jedes mal
mit einem Grinsen, und muss sagen, dass es schon sehr intelligent gelöst
ist. Aber, da spielt die Erfahrung halt eine große Rolle. Diese streng
definiert Datentypen aus stdint
sind mir halt lieder nicht sehr geläufig. Ich bin bei meinem
Programmierstil halt leider stark von unserem Unterricht und wie unser
Lehrer programmiert beeingflusst worden. Das mit switch ist natürlich
genial, leider ist mir diese Funktion in 4 Jahren C ein bis zweimal
gezeigt worden....
Was ich von dir übernehmen werde ist die Timer0 Lösung. Hier mit beiden
Timern herum zu spielen ist, in der Tat, etwas umständlich.
MFG Julian
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
>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?
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...
@ 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?
@ 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.
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.
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.
@ 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
Thread beobachten
Seitenaufteilung abschalten