Archiv verlassen und diese Seite im Standarddesign anzeigen : Fragen zu Power-Down Modus und Quarzverwendung (Uhrzeit?)
Hallo zusammen,
Ich plane ein Projekt bei welchem ich zwei µCs (ATMEGA168P und ATMEGA328P) zusammen kommunizieren lasse. Der ATMEGA168P soll Messungen durchführen, die per RS232 an den ATMEGA328P übertragen werden sollen und der zeigt diese auf einem Display an. Der ATMEGA328P soll auch noch die Uhrzeit auf dem Display ausgeben. Jetzt ist das erste Problem: Ich wollte keinen Uhrenquarz verweden sondern einen 10Mhz Quarz pro µC. Theoretisch könnte man damit ja auch eine relativ genaue Uhrzeit anzeigen lasse (Je nach programmierungsaufwand) oder? Des weitern sollen die µCs auch im Sleep Modus betrieben werden. Die Versorgung soll dann über eine Knopfzelle erfolgen. Da die Knopfzelle die primäre (also häufigere) Versorgungsquelle wird sollte so wenig Strom wie möglich gezogen werden, solange die µCs im Sleep Modus sind. Die Uhr soll aber trotzdem weiterlaufen und ein INT soll die µCs wieder "aufwecken". Ich hatte mir überlegt den "Stand-by" zu nehmen, da dieser laut Datenblatt mir einem externen Quarz zu empfehlen ist
Standby Mode
When the SM2...0 bits are 110 and an external crystal/resonator clock is selected, the SLEEP instructions make the MCU enter Standby mode. This mode is identical to Power-down with the exception that the Oscillator is kept running. From Standby-mode. the device wakes up in six clock cycles.
Ist mit Oscillator jetzt ein interner oder der externe gemeint? Denn mit 10Mhz komme ich bestimmt nicht auf eine Stromaufnahme von 4,2µA (laut Datenblatt). Das Wichtigste ist eig. dass die Uhr weiterläuft während der µC im Standby ist. Habe schon mal nach Knopfzellen geschaut und welche mit 650mAh gefunden. Wenn möglich sollten die schon so 2-3 Jahre halten. Könnt ihr mir da weiterhelfen ob ich das so überhaupt umsetzen kann oder ob das völlig unrealistisch ist? Habe leider noch nie mit den "Sleepmodi" gearbeitet.
Mfg Mel
Es sollte sich hierbei um den externen handeln, sagt zumindest mal auch Tabelle 9-1 (Seite 39)
Und im übrigen ist es für mich absolut unverständlich, warum du einerseits sagst, du willst Stromsparen, andererseits aber einen Quarz mit 10 Mhz verbauen willst! Der Stromverbrauch steigt annähernd linear zur Quarzfrequenz, du brauchst also im Vergleich zu einem Uhrenquarz das rund 300-fache an Strom!
Im übrigen wird das Display vermutlich den Löwenanteil des Stromverbrauchs ausmachen, zumindest wenn es kein passives (also ohne eigene Lichtquelle) Display ist.
mfG
Markus
Edit: Seite entsprechend dem aktuellsten Datasheet korrigiert
oberallgeier
04.09.2009, 13:21
... absolut unverständlich, warum du einerseits ... Stromsparen, andererseits aber einen Quarz mit 10 Mhz ...Ich glaube, das geht jetzt an eine Optimierungsrechnung. Wie lange brauche ich bei 38 kHz Prozessortakt für den Datentransfer und wie lange bei 10 MHz. Mal so - nach der Methode Milchmädchen - würde ich sagen: man braucht mit nem Uhrenquarz für den Datentransfer um den von Dir genannten Faktor länger - und entsprechend länger auch SOB *gggg* (Saft on board). Fazit wäre, dass es gehupft wie gesprungen ist. Aber das ist nun wirklich nur grob geschätzt.
Also die 10Mhz nehme ich weil ich, wie schon vermutet, eine schnelle Datenübertragung brauche und der ATMEGA168P ne Menge Daten schnell erfassen, umrechnen und weiterleiten soll. Das Display und andere Verbraucher sind so geschaltet/verdrahtet dass sie nur Spannung bekommen wenn die Platine von extern, also nicht von der Batterie versorgt wird. Ich brauche halt eine Möglichkeit die Uhr mit wenig Stromverbrauch dauerhaft zu betreiben, aber auch ne Menge an Rechenleistung zu bewältigen.
EDIT: Also habe grad ein bisschen nachgerechnet. Der ATMEGA168P muss hauptsächlich 2 Signale erfassen und übermitteln (die Signale treten immer gleichzeitig auf und sollen ca. alle 300ms übertragen werden)
1. Signal: ___|___|___|___ (Impulssignal mit max. 100Hz)
2. Signal: ___||___||___||___ (Impulssignal mit max. 350Hz)
Kann man die µCs auch so verwenden dass sie im "Aktivmodus" die 10Mhz Quarze verwenden und im Sleep-Modus auf einen internen Takt umschalten? Ich hatte schon überlegt einen µC mit 10Mhz laufen zu lassen und den anderen mit einem Uhrenquarz aber der wird dann denke ich zu langsam für die Übertragung werden.
Hubert.G
04.09.2009, 15:28
Und was machst du noch alles, weil du schreibst
aber auch ne Menge an Rechenleistung zu bewältigen
Die beiden Signale erfassen, auf einem Display anzeigen und eine Uhr mitlaufen lassen, lasten einen Kontroller aber nicht aus, geschweige denn zwei.
oberallgeier
04.09.2009, 16:09
... 10Mhz nehme ich weil ... der ATMEGA168P ... Daten schnell ... weiterleiten soll ...Bei diesem Entwurfsziel vermisse ich aber bei Dir die Kontrollrechnung, welches Deine schnellste Baudrate ist >>mit tolerierbarem Fehler<< (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=438494&sid=5137008cd176f6045f86716977621f8b#438494) (Link zeigt ein Beispiel für 20 MHz) in Abhängigkeit vom Quarztakt. Vermutlich sind die 10 MHz nicht das Optimum, möglicherweise wird ein anderer, krummer Quarztakt eine erheblich schnellere Datenübertragung (weil kleinere Fehlerabweichung) ermöglichen. Das trifft genaugenommen nur zu, wenn Du eine "Standardschnittstelle" hast, z.B. am PC, mit einer eng tolerierten Standardbaudrate. Bei zwei Controllern, die mit dem gleichen Quarz ausgerüstet sind, ist der Fehler vernachlässigbar, weil beide vergleichbare Abweichungen haben. ABER - in der Testphase oder so - wenns dann mal wirklich standardmässig ist - könnte das Störungen geben.
Besserwessi
04.09.2009, 16:41
Die Aufgabe sieht nicht so kompliziert aus. Den µC ganz mit 32 kHz laufen zu lassen wird vielleicht etwas knapp, könnte aber auch nochgehen. Bei 10 MHz braucht schon der Oszillator zu viel Strom für ein Knopfzelle. Die normale Lösung wäre den µC mit dem RC Takt laufen zu lassen, und nur die Zeit über den 32 kHz Takt. Dabei sollte ein µC ausreichen, sonst halt einen Meag324 oder ähnliches.
Wenn man die UART nur zwischen 2 eignen µCs nutzen will, ist man nicht auf standardfrequenzen angewiesen. Man hat dann kein Problem mit z.B. 1000 Baud statt der sonst üblichen 1200 Baud.
Ok eine Kontrollrechnung habe ich nicht durchgeführt 8-[ .
Ich hab schon mal was ähnliches gemacht, auch mit identischen Messungen und habe damals einen ATMEGA32 genommen. Der kam aber nicht damit klar, die Messungen zu erfassen, umzurechnen und auf einem Display auszugeben. Da gabs immer Probleme das wenn grade Text auf dem Display ausgegeben wurde und ein INT kam, dass der µC quasi abgestürzt ist. Kann jetzt auch nicht ausschließen dass es an meiner Programmierung lag, so viel Erfahrung habe ich da noch nicht, aber ich hab mir gedacht 2 Prozessoren sind sicherer.
Beim RC-Takt ist es doch so dass die Frequenz stark temperaturabhängig ist, was für eine Uhr nicht ideal wäre oder? Da die Platine Temperaturschwankungen von -10°C-40°C ausgesetzt ist könnte das doch problematisch werden.
vielleicht schilderst du mal genauer, was du eigentlich messen willst, wie das umgerechnet, bearbeitet und gespeichert werden soll und wie es ausgegeben werden soll.
mißt du von den genannten beiden impulsen die frequenz, die breite, das tastverhältnis? werden dann am display nur die letzten meßwerte ausgegeben, irgendein durchschnitt oder eine history? soll, wenn das gerät ohne externe stromversorgung läuft, überhaupt gemessen werden oder nur die uhrzeit mitgeführt werden?
wenn du ein LCD verbaust, würde ich auch drüber nachdenken, ob nicht auch noch platz und gewichtsbudget für AA- oder AAA-zellen vorhanden ist - die haben mehr kapazität als knopfzellen, sind billger und leichter zu beschaffen.
ich hab zb einen temperatur- und feuchtesensor, der minütlich aufwacht, den sensor ausliest und die werte per funk überträgt; der läuft mit 2 AA-zellen ein knappes jahr...
Ok also mein Projekt soll ein Tacho (Motorrad) werden mit Geschwindigkeitsmessung, Drehzahlmessung, Öltemperaturmessung, Uhrzeit und eine Art Alarm.
Wenn man fahren möchte wird die Zündung eingeschaltet, die Hardware kann über z.B. einen 7805 versorgt werden, Stromaufnahme ist eig. egal (solange nicht >1A, was aber eh nicht vorkommt). Bei der Fahrt soll folgendes gemessen werden:
1. Geschwindigkeit
Dies geschieht über einen Reedkontakt mit 2 Magneten an der Bremsscheibe. Der Reifenumfang beträgt ca. 1,8m. Bei einer Geschwindigkeit von 300km/h (nein in real nicht so schnell ;)) schaltet der Reed-kontakt somit ca. 90mal pro Sekunde. Beim alten Projekt (also der alte Tacho der jetzt im Moment eingebaut ist) habe ich dazu immer einen PIN nach high oder low abgefragt (in einer Timerroutine wo der Timer 10000x pro Sekunde überlief. Eine meiner Meinung nach sehr unschöne Variante aber mit einem INT hatte ich wie schon geschrieben immer Probleme).
Jetzt würde ich erst mal versuchen jeden Schaltvorgang durch einen INT zu erfassen und mitzuzählen und dies dann später umzurechnen.
2. Drehzahl
Hierzu habe ich vor ein Stück Draht um das Zündkabel zu wickeln um mir bei jedem Zündvorgang eine Spannung zu induzieren die ich dann über einen Optokoppler an meinen AVR weitergeben will. Da weiß ich aber noch nicht genau wie ich das umsetze, deshalb weiß ich auch noch nicht genau wie das Signal aussieht, ich vermute aber ähnlich wie das zur Geschwindigkeitsmessung. Bei 20000rpm habe ich eine Frequenz von ca. 330 Hz. Die soll dann auch mitgezählt, in RPM umgerechnet und übertragen werden.
3. Öltemperatur
Dies geschieht über einen Sensor am Motorgehäuse. Die Messung erfolgt mit dem AD-Wandler. Das klappt soweit auch ganz gut.
4. Uhrzeit
Wenn möglich würde ich mir gerne die Uhrzeit anzeigen lassen da ich diese Klebedinger die es fürs Mopped gibt nicht besonderlich mag.
5. Alarm
Das Motorrad soll, sobald es bewegt wird und die Zündung ausgeschaltet ist, einen Alarm geben. Dazu dachte ich mir den durch den Reedkontakt hervorgerufenen Schaltvorgang beim Bewegen des Motorrads als INT zu verwenden um den µC aufzuwecken und eine Alarmroutine abzuarbeiten. Die zweite Möglichkeit zum Aufwecken ist natürlich die Zündung zu starten.
Wenn die Zündung eingeschaltet ist soll auf dem Display(128x64) die Geschwindigkeit, die Uhr, Kilometerstand und die Öltemp. als Zahlenwerde ausgegeben werden.
Zusätzlich soll die Drehzahl und die Öltemp in einem Diagramm dargestellt werden, was dann der andere µC übernehmen soll sobald ihm die Daten vom ersten µC zugesendet wurden.
Ist die Zündung nicht aktiv soll das Display ausgeschaltet sein. Nur die Uhr soll weiterlaufen um beim nächsten Startvorgang wieder angezeigt werden zu können. Aufgeweckt werden sollen die µCs/der µC wie gesagt nur durch das Einschalter der Zündung oder durch das Bewegen des Motorrads, was einen Pegelwechsel zur Folge hat.
So sry für die Massen an Text, könnte auch schon in den Thread "Geplante Projektvorstellungen" passen 8-[
Ich hoffe ihr seid noch willig mir ein bisschen auf die Sprünge zu helfen.
Ach ja das ganze soll möglichst klein gehalten werden. Die µCs sollen als TQFP-Bauform ausgeführt sein und die anderen Bauteile möglichsts als SMD. Das Platinenlayout etc. ist auch schon fertig (wird ne doppelseitig bestückte Platine)
Ok also mein Projekt soll ein Tacho (Motorrad) werden mit Geschwindigkeitsmessung, Drehzahlmessung, Öltemperaturmessung, Uhrzeit und eine Art Alarm.
na siehst, und schon steigt meine motivation, zu helfen, weil's ein sinnvolles projekt ist :-)
ausgehend davon, daß dein motorrad überhaupt eine batterie hat (könnt ja anhand der vorliegenden daten auch ein 2takt-crosser mit sumo-felgen sein :-) ), würd ich das ganze über dauerplus versorgen. mit einem der neuen picopower-AVRs sollte das mit unter einem µA gehen (ATmega 168PA im power-save mode mit 32kHz-oszillator = 0,83µA), das ist sicher unter der selbstentladung der batterie. dazu käme dann noch der eigenverbrauch des spannungsregler-ICs.
ein zündungsplus-anschluß muß natürlich auch dran, aber nur an einen input-pin (mit spannungsteiler), um festzustellen, wann die zündung ein ist; dann kann man aufwachen (softwareseitig) und das display einschalten. hat das einen enable-pin, und wieviel strom schluckt es im ausgeschalteten zustand? alternativ könnt man einen zweiten spannungsregler davorsetzen, da gibt es welche mit einem enable-eingang und minimalem stromverbrauch im off-zustand.
1. Geschwindigkeit
Dies geschieht über einen Reedkontakt mit 2 Magneten an der Bremsscheibe. Der Reifenumfang beträgt ca. 1,8m. Bei einer Geschwindigkeit von 300km/h (nein in real nicht so schnell ;)) schaltet der Reed-kontakt somit ca. 90mal pro Sekunde.
yup, das kommt an einen interrupt-pin; mit selbigen kann man den uC auch aus dem sleep erwecken, die basis für die alarmanlagenfunktion ist also auch gegeben.
2. Drehzahl
Hierzu habe ich vor ein Stück Draht um das Zündkabel zu wickeln um mir bei jedem Zündvorgang eine Spannung zu induzieren die ich dann über einen Optokoppler an meinen AVR weitergeben will.
meine ZRX hat zwar einen mechanischen tacho, aber einen elektronischen drehzahlmesser, da kommt aus der zündbox ein signal an. evtl ist das bei dir ja auch so, dann ersparst dir das mit dem zündkabel.
Zusätzlich soll die Drehzahl und die Öltemp in einem Diagramm dargestellt werden, was dann der andere µC übernehmen soll sobald ihm die Daten vom ersten µC zugesendet wurden.
ich bin ja ein freund von hardware-minimalismus und würd versuchen, das alles mit einem ATmega48 abzufackeln :-) -- aber ich hab auch keine ahnung von grafischen displays.
aber wenn man's mit 2 uCs macht, wär für mich die logische aufteilung die, daß der erste die meßwerterfassung, real-time-clock und alarmierung macht, auf minimalen stromverbrauch ausgelegt ist und über einen spannungsregler mit enable den zweiten plus das display einschaltet. der zweite steuert das display und bekommt vom ersten einfach in regelmäßigen intervallen die aktuellen meßwerte.
ich würd mir als nächstes mal das datenblatt der ATmega*8PA reinziehen wegen der stromsparmodi.
und ich bin neugierig, was das für ein motorrad ist, bei dem für 300km/h und 20kRPM dimensioniert wird, das aber noch keine elektronischen zünd- und tachosignale hat :-)
ciao,
cm, ZRX1100R.
Hi,
1. die Probleme mit dem Reedkontakt hattest du vermutlich, weil der Kontakt geprellt hat - durch deine reduzierte Abtastfrequenz wurde das dann weitestgehend ausgefiltert.
2. 330Hz langweilen den AVR bestenfalls
3-5. geschenkt
Alles in allem bringst du damit den AVR bestenfalls zum gähnen.
mfG
Markus
EDIT: Wenn du dich wirklich anstrengst, schaffst du es sicherlich, dass die Interrupt-Timings nicht mehr klappen - wenn du aber n bisschen optimierst, könnten die 32kHz sogar vollkommen reichen. - Sonst würde ich einfach interne 1MHz verwenden und mit dem Uhrenquarz nur den Timer2 asynchron betreiben.
Hah super Motorradfahrer kann man doch immer schnell für sinnvolle Sachen begeistern=). Muss dich leider enttäuschen, fahre keine PS-Schleuder wie du=). Fahre ne Honda FMX 650, also mit deiner Crosser mit sumo-Felgen warste nicht ganz falsch;) (Ist aber einiges dran gemacht...sieht also nicht ganz Standard aus und hat auch ein bisschen mehr Dampf als die 38 Pferdchen).
Das mit dem Zündsignal abgreifen hatte ich auch schon überlegt aber da ich den Anschluss so einfach wie möglich machen möchte (ggf. wollten auch ein paar Freunde ein Tacho bekommen) wollte ich dadrauf verzichten, genau wie das Dauerversorgen mit Spannung von der Batterie, denn dazu müsste man ja ein zusätzliches Kabel ziehen. Das Datenblatt hab ich schon ein bisschen gewältzt, ich versteh aber leider nicht ganz genau wie die Quarze im einzelen Modi eine Rolle spielen. Das ist glaub ich das größte Problem, dass ich mit Zündung einen Quarz verweden kann, meinetwegen 10Mhz, und beim Stromsparen drauf verzichte, die Uhr aber trotzdem weiterlaufen kann. Bei meinem jetzigen selbstgebauten Tacho habe ich keine Uhr, folglich auch das Problem nicht.
Das mit dem Display habe ich im Moment mit Didoden geregelt, so dass das Display nur Spannung bekommt wenn diese über den 7805 zur Verfügung gestellt wird.
Und dass ich den Tacho für solche Geschwindigkeiten auslege liegt einfach dadran dass ich so perfekt abgepasste Sache nicht so mag sondern lieber was "allgemeineres" verwende, was dann später auch in der Verwendung flexibler ist. Sonst hätt ich nur bis 130 km/h gehen müssen, mehr gibt meine Übersetzung nicht her;)
Besserwessi
04.09.2009, 20:22
Wenn man nur einen µC nimmt, braicht man keinen so genauen Takt für die UART mehr. Für die Tempo- und Drehzahl- Messung sollten die etwa 2 % Ungenauigkeit des Internen RC-Taktes noch nicht so schlimm sein. Wenn man unbedingt will, kann man den Takt aber auch gegen den 32 kHz Uhrenquarz nachmessen, bzw korrigieren.
Damit sehe ich keine Probleme damit den eigentlichen µC mit 1 MHz oder auch 8 MHz vom RC Takt laufen zu lassen, und den 32 KHz Quarz für Timer 2 zu nutzen, so wie oben schon angesprochen.
Wenn es früher mal nicht mit Interrupts geklappt hat, dann war das vermutlich ein realtiv einfaches Softwareproblem, das man vermutlich einfacher lösen kann, als die kommunikation mit 2 µCs.
Muss dich leider enttäuschen, fahre keine PS-Schleuder wie du=).
man sollt ZRX und ZXR nicht velwechsern :-Q
genau wie das Dauerversorgen mit Spannung von der Batterie, denn dazu müsste man ja ein zusätzliches Kabel ziehen.
wennst schon kabel vom reed-sensor, dem zündkabel und dem geschalteten plus ziehen mußt, ist ein weiteres meines erachtens auch schon wurscht. aber gut, ich hab's noch nichtmal geschafft, mein GPS zu verkabeln.
besonders am eintopf gibt's aber bei batterieversorgung eins zu beachten: daß die kontakte bei den vibrationen nicht zeitweise von der batterie hüpfen... siehe die diskussionen über diverse navis am motorrad.
Das Datenblatt hab ich schon ein bisschen gewältzt, ich versteh aber leider nicht ganz genau wie die Quarze im einzelen Modi eine Rolle spielen. Das ist glaub ich das größte Problem, dass ich mit Zündung einen Quarz verweden kann, meinetwegen 10Mhz, und beim Stromsparen drauf verzichte, die Uhr aber trotzdem weiterlaufen kann.
ich bezieh mich im folgenden immer auf das aktuelle datenblatt für mega48/88/...
ich würd prinzipiell nur einen timer über den uhrenquarz laufen lassen (datenblatt s.32 "low frequency crystal oscillator") und die CPU selber über den internen RC-oszillator genaugenommen geht's eh nicht anders, weil das die gleichen pins sind. falls du wirklich 2 uCs einsetzen willst, kannst du über den CLKO-pin den takt des einen ausgeben und dem anderen als externen takt verfüttern, damit ist auch UART-kommunikation kein problem mehr.
lt datenblatt s.39 kannst du mit dem 32kHz-quarz den timer2 laufen lassen im power-save-modus. zum aufwachen hast du dann timer2 (für die uhr) und die externen und pin change interrupts, also das was du brauchst, bei < 1µA verbrauch.
den timer2 kannst dann im "normal mode" betreiben, beim overflow gibt's einen interrupt, den den controller aufweckt, dort zählst die uhr weiter und legst ihn wieder schlafen. wegen betrieb mit dem uhrenquarz siehe s. 155, wesentlich ist hier glaub ich nur der punkt, daß du den uC nicht wieder schlafen schicken darfst, bevor ein neuer taktzyklus des uhrenquarzes angefangen hat; das sind bei 8MHz takt 244 CPU-takte, könnt also bei effizienter programmierung schon vorkommen. im zweifelsfall läßt man da halt noch eine LED aufblitzen als alarmanlagen-simulator :-)
den prescaler kannst du auf 128 setzen, dann wacht der uC jede sekunde auf, oder gleich auf 1024, dann mußt halt jedesmal 8 sekunden weiterzählen.
wenn man schon eine quarzgenaue taktquelle hat, liegt es nahe, die auch für die drehzahl- und geschwindigkeitsmessung zu verwenden; dafür sind allerdings die 256Hz auflösung, die du (mit prescaler 128) kriegst, du wenig, man müßt also entweder beim "einschalten" den prescaler umschalten (da steht nix konkretes im datenblatt, was dann passiert) oder den RC-oszillator at runtime kalibrieren, und das wohl auch noch regelmäßig, weil zwischen z.B.heiligenblut und hochtörl sind ja doch ein paar grad temperaturunterschied.
soweit einmal meine ideen,
cm.
man sollt ZRX und ZXR nicht velwechsern :-Q
Keine Sorge hab ich schon nicht verwechselt aber im Gegensatz zu meiner ist da doch einiges mehr an Power vorhanden=)
Mit dem Kabel hast du eig. Recht...wenn ich schon welche ziehen dann richtig aber die Lösung mit der Batterie find ich eleganter...denn zum Überwintern nehm ich die Hauptbatterie ja raus (ok ein mal im Jahr Uhr neustellen ist nicht das Problem...aber trotzdem).
Im Moment bin ich auch am überlegen alles mit einem µC zu machen. Mit der Programmierung muss ich dann mal schauen aber das sollte ich vllt hinbekommen. Das einzige was halt stört sind die schwankenden Temperaturen, was die Frequenz und somit die Uhr beeinflusst.
Wenn das mit den Interrupts für Geschwindigkeit und RPM ordentlich klappt würde ein Uhrenquarz doch evtl. ausreichen oder? Ich müsste ja nur die ANzahl von Interrupts auf eine bestimmte Zeitspanne auswerten. Die Zeitspanne kann ich mir ja selber definieren (Timerüberlauf)
Keine Sorge hab ich schon nicht verwechselt aber im Gegensatz zu meiner ist da doch einiges mehr an Power vorhanden=)
naja, es gibt bei uns die faustregel, daß unter 100PS grad einmal fürs semmel-holen in der früh reichen :-)
Im Moment bin ich auch am überlegen alles mit einem µC zu machen. Mit der Programmierung muss ich dann mal schauen aber das sollte ich vllt hinbekommen. Das einzige was halt stört sind die schwankenden Temperaturen, was die Frequenz und somit die Uhr beeinflusst.
wenn du die uhr über den uhrenquarz ansteuerst, hast du dieses problem nicht, bzw nur insoweit, wie der uhrenquarz temperaturabhängig ist. der interne RC-oszillator wird ja nicht für die uhr verwendet: timer2 läuft immer mit dem uhrenquarz.
Wenn das mit den Interrupts für Geschwindigkeit und RPM ordentlich klappt würde ein Uhrenquarz doch evtl. ausreichen oder? Ich müsste ja nur die ANzahl von Interrupts auf eine bestimmte Zeitspanne auswerten. Die Zeitspanne kann ich mir ja selber definieren (Timerüberlauf)
ich würd für drehzahl und geschwindigkeit die zeit zwischen 2 impulsen messen, weil du mit impulsen/zeiteinheit bei zB einer sekunde (was schon lang ist) bei der geschwindigkeit nur eine auflösung von 3,24km/h hast und bei der drehzahl 60RPM.
die geschwindigkeitsimpulse kommen bei 300km/h alle 1ms, die drehzahlimpulse bei 20kRPM alle 3ms. wenn du jetzt einen 16bit-timer mit einem prescaler von 64 und einer CPU-frequenz von 8MHz benutzt, hast du 125 counts pro ms, das sollt reichen.
dann könnt man zum kalibrieren auch einfach den 16bit-timer mit dem timer2 abgleichen und hätte jede sekunde einen aktuellen kalibrierungsfaktor, den man einrechnen kann...
ciao,
cm.
naja, es gibt bei uns die faustregel, daß unter 100PS grad einmal fürs semmel-holen in der früh reichen Freudig
Dann werd ich mich erstmal nicht in Wien blicken lassen mit meiner karre ;)
Ich hab eine Frage zur Verständnis. So wie ich das jetzt verstanden habe (und in anderen Threds gelesen habe) wird der Uhrenquarz an den µC angeschlossen, ich besorge mir als nen Uhrenquarz der als Hardware an die entsprechenden Pins angeschlossen wird. Somit kann ich mir über den Timer eine genau Uhr programmieren. Zusätzliche habe ich noch die Möglichkeit den µC über den internen Takt (meintewegen 8Mhz) zu betreiben um anderen Operationen durchzuführen, wie z.B. Messungen erfassen richtig? Denn einen zusätzlichen externen Quarz kann ich ja nicht mehr verwenden wenn ich schon den Uhrenquarz verwende.
Right, wenn du den Uhrenquarz verwendest, um den Timer asynchron zu Takten, musst der AVR mit einer der internen Taktquellen betrieben werden.
mfG
Markus
So hab mich jetzt mal ausführlicher mit dem "asynchron-Mode" beschäftigt.
Habe mir folgendes PDF durchgelesen
http://www.google.de/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Fwww.atmel.com%2Fdyn%2Fresources%2 Fprod_documents%2FDOC1259.PDF&ei=cp-iSoXYHsaGsAbz_JjSBA&rct=j&q=timer+asynchron+ATMEL&usg=AFQjCNHcQJ0Jqy5fkcp7Amt4flSVu05PMA
Da sind jeweils ein Uhrenquarz und ein Quarz an TOSC1/2 und XTAL1/2 angeschlossen. Könnte ich also auch einen externen Quarz statt dem internen Takt nehmen? Der einzige Nachteil den ich dadurch finden konnte ist die "Aufwachzeit" von 35ms mit externem Quarz, was dann im Endeffekt doch mehr Strom benötigt. Fiele diese lange Aufwachzeit mit dem internen Takt weg bzw. würde sich der Stromverbrauch ändern? Ich habe vor alles mit einem µC zu machen. Hierbei läuft dann ein Timer im RTC Mode um die Uhr zu steuern. Wenn die Zündung an ist werden die ganzen Operationen dann mit einem internen/externen Tank von 1Mhz oder 4Mhz erledigt. (So wie markusj schon vorgeschalgen hat).Im Ruhezustand muss der µC dann nur immer beim Timerüberlauf den Power-Save Mode verlassen, die Variablen hochzählen und dann wieder in den Power-Save Mode wechseln. Um da auch möglichst wenig Strom zu verbrauchen könnte ich den Timer ja alle 8s zum Überlauf bringen (wie auch schon vorgeschalgen wurde).
Habe mich vorhin mal an die Zündspule gemacht. Da kann ich super ein Signal von Klemme 1 abgreifen...es handelt sich um ein Signal von ca. 8V (warum auch immer 8V anstatt 12V) was dann bei jedem Zündvorgang kurz gegen Masse geschaltet wird. Also muss ich im Endeffekt doch Strippen ziehen :-D
EDIT: Das mit dem XTAL und TOSC getrennt bezieht sich auf einen ATMEGA32 wie ich grad bemerkt habe. Beim ATMEGA32P sind die beide auf den gleichen Pins
Wie du schon festgestellt hast, bei den AVRs der x8PA-Reihe hast du entweder nen externen Quarz als System-Taktquelle oder als Taktquelle für den asynchronen Timer.
Du musst also den internen RC-Oszillator verwenden, was aber auch kein Beinbruch ist - der reicht für deine Rechenaufgaben vollkommen, eine stabile Zeitbasis hast du ja mit dem externen Quarz.
mfG
Markus
Super Jungs ich danke euch erst mal für eure Hilfe. Werd die Tage meine Platine ätzen und dann schauen wie das alles klappt. Wenns Probleme gibt meld ich mich wieder;)
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.