Fragen zu Power-Down Modus und Quarzverwendung (Uhrzeit?)

[cmock]

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.

[markusj]

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.

[MelMan]

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]

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.

[cmock]

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

[MelMan]

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)

[cmock]

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.

[MelMan]

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.

[markusj]

Right, wenn du den Uhrenquarz verwendest, um den Timer asynchron zu Takten, musst der AVR mit einer der internen Taktquellen betrieben werden.

mfG
Markus

[MelMan]

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

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