Hallo,
nun im richigem Thread?
ich möchte gerne mal eine neue Idee verwirklichen.
Ich komme mal gleich zu den Details:
Ein ATmega16, evtl. ATmega8, DOGM 163 LCD, 4 Taster, RC-Signal Eingang,
LED und Piezo Summer.
Compiler: WinAVR oder CodeVisionAVR, also beides in C.
Ich möchte von einem frei wählbaren Wert, zB. 2000, pro Minute einen
Wert von 70 bis 200, je nach RC-Signal abziehen.
Die RC Auswertung mache ich per INT0, starte bei steigender Flanke einen
16 Bit Timer, stoppe ihn bei fallender Flanke.
Zur Zeit habe ich Pulslängen von 120 bis 245 Timer Takten.
Nun muß ich diese Pulslängen auf die 70-200 Werte anpassen.
Frage: Wie geht das?
Dann möchte ich im nächsten Schritt die 70-200 Werte nicht Linear,
sondern mit einer 3 Punkt Kurve berechnen, diese Kurve soll auch frei
Wählbar sein.
Frage: Wie geht das?
Ach, noch was, ich möchte auf dem Display den Wert 2000 minus dem
abgezogenen Wert nicht alle Minute angezeigt bekommen, sondern schon
eine schnellere Aktuallisierng haben.
Ab einem bestimmen Wert, z.B. 200 soll dann eine Warn LED an gehen und
ein PiezoSummer Ton ertönen.
Mit den 4 Tastern soll später mal ein kleines Menü erstellt werden, um
die Werte 2000, 70 - 200, 3 Punkt Kurve, Warnschwelle einzustellen.
Für ein wenig Gedankenanstoß wäre ich sehr dankbar.
Gruß Toby
Erst einmal sortieren, also 1 Problem nach dem anderen und nicht gleich
alles auf einmal:
Also: Womit willst Du anfangen, welches Problem muss als erstes gelöst
werden, worauf setztz anderes auf?
Ich habe gleich mal alles beschrieben,
weil ja alles irgendwie zusmmen hängt.
Als erstes würde ich gerne das RC Signal auf die Werte 70 bis 200
anpassen.
Gruß
>Zur Zeit habe ich Pulslängen von 120 bis 245 Timer Takten.>Nun muß ich diese Pulslängen auf die 70-200 Werte anpassen.
50 abziehen?!
Dann kommst du zwar nur noch auf 195 statt 200, aber das erspart dir das
Rechnen mit Komma-Zahlen.
> Ach, noch was, ich möchte auf dem Display den Wert 2000 minus dem> abgezogenen Wert nicht alle Minute angezeigt bekommen, sondern schon> eine schnellere Aktuallisierng haben.
Wieso? Wenn der Wert sich doch sowieso nur einmal pro Minute ändert,
bringt es doch gar nichts, wenn die Display-Aktualisierung häufiger
durchgeführt wird.
Hi,
mit 50 abziehen komme ich nicht klar, da die Werte 70-200 variabel sein
sollen.
70-200 pro Minute ist nur ein Richtwert.
Es muß kotinuirlich etwas abgezogen werden.
Die 70-200 sind der Verbrauch von ml pro Minute.
Gruß Toby
Ergebniss: R1
Ist nur ein Konzept.
also: ((Wert-120)*266/256)+70
[edit: evtl. musst du noch irgendwo 1 addieren z.B. anstelle von lsl R0
einfach ein sec, machen]
-wiebel
Gehen wirs doch mal mit ein bischen Theorie an:
> Zur Zeit habe ich Pulslängen von 120 bis 245 Timer Takten.>> Nun muß ich diese Pulslängen auf die 70-200 Werte anpassen.> Frage: Wie geht das?
Du hast also eine Eingangsvariable, nennen wir sie mal x
x kann Werte von 120 bis 245 annehmen
Aus diesen Eingangswerten willst du Ausgangswerte generieren,
die nennen wir mal y und die können sich im Bereich 70 bis 200
bewegen.
Da zeichnen wir uns doch gleich mal ein Schaubild, damit das
mal etwas übersichtlich zusammengestellt wird:
(Siehe beiliegende Grafik)
Deine Abbildungsfunktion ist die blaue Gerade. Aus dem Matheunterricht
weist du vielleicht noch, dass eine Gerade mit der 'Geradengleichung'
y = k * x + d beschrieben werden kann (ist für Computergrafik nicht
optimal geeignet, aber für deinen Zweck wirds das tun).
x ist der Wert den du von der RC-Auswertung kriegst
y ist der Wert den du für die Subtraktion brauchst.
Die Frage ist daher: wie gross ist das k und das d, damit die
Gleichung eindeutig beschrieben ist.
Nun wir kennen 2 Punkte auf der Geraden (die beiden roten Kreise)
Für einen x Wert von 120, soll sich ein y Wert von 70 ergeben.
Ergo: 70 = k * 120 + d
Und für einen x Wert von 245 soll sich ein y Wert von 200 ergeben.
Ergo: 200 = k * 245 + d
Das macht daher 2 Gleichungen in 2 Unbekannte
70 = k * 120 + d
200 = k * 245 + d
das sollte sich doch lösen lassen :-)
(Führe ich jetzt nicht konkret aus. Ein lineares Gleichungssystem
in 2 Unbekannten zu lösen ist trivial).
Es ergibt sich: k = 1.04, d = 54.8
Das ist also deine Umrechnung:
Subtraktionswert = RC_Wert * 1.04 - 54.8
Da das k sehr nahe an 1 liegt und das d relativ nahe an 50,
ist also die Lösung von Michael gar nicht so schlecht.
Ansonsten besteht die weitere Kunst jetzt darin, aus den
Fliesskommazahlen ganze Zahlen zu machen, damit für die
Berechnung nicht unbedingt Fliesskommaarithmetik gebraucht
wird.
Eine (simple) Möglichkeit ist es, einfach alles mal 100
zu nehmen. 1.04 -> 104, 54.8 -> 5480. Das Ergebnis, das
du erhältst ist dann allerdings auch mal 100. Du kriegst
daher nicht 70 raus sondern 7000. Das sollte aber weiter
kein Problem sein, man kann ja noch doch 100 dividieren.
Schlauer agiert man allerdings, wenn man nicht einen Faktor
von 100 nimmt, sondern eine 2-er Potenz. Denn dann wird die
abschliessende Division für den µC trivial.
Aber das überlasse ich dir zur Übung: Eine 2-er Potenz zu
finden, sodass aus 1.04 und 54.8 möglichst ganze Zahlen
werden. Im schlimmsten Fall probierst du einfach durch.
Soviele 2-er Potenzen in einem vernünftigen Bereich gibt
es ja nicht ( 2, 4, 8, 16, 32, 64, 128, 256 )
> Dann möchte ich im nächsten Schritt die 70-200 Werte nicht Linear,> sondern mit einer 3 Punkt Kurve berechnen, diese Kurve soll auch frei> Wählbar sein.> Frage: Wie geht das?
Indem du dich mit dir selber einigst, wie denn die Kurve aussehen
soll, die die 3 Punkte verbindet.
Das könnte zb. eine Parabel sein. Das könnten aber einfach nur
2 Geraden sein. Und von denen weist du ja schon, wie man sie
behandelt.
Da das eh eine Kurve wird, würde ich gleich einfach eine Lookuptable
machen.
Das ist mit abstand das flexibelste, ansonsten musst du womöglich doch
auf Kommazahlen ausweichen und das will ja doch keiner
@kbuchegg:
>Da das k sehr nahe an 1 liegt und das d relativ nahe an 50,>ist also die Lösung von Michael gar nicht so schlecht.
Hey, was soll das heissen, mein 1 ist mit immerhin 1.039(=266/256) näher
an den tatsächlichen 1.04 als an 1. Gut mit den 50 bin ich mit 52.63
nicht ganz so nahe an den 54, aber trotzdem. ;)
Ich würde dennoch lieber zuerst einen Wert von dem Messwert abziehen,
sonst läuft man zu leicht Gefahr einen Overflow beim mul zu generieren,
es reicht zwar, ist aber doch sehr knapp, wenn jetzt doch mal irgendwie
246 ankommen sind wir schon drüber. Aber du hast die Implementierung ja
ohnehin aussen vorgelassen. -wiebel
wiebel42 wrote:
> 246 ankommen sind wir schon drüber. Aber du hast die Implementierung ja> ohnehin aussen vorgelassen.
Na ja. Irgendetwas muss er schon selber auch noch machen.
Wenn er mit der Implementierung Schwierigkeiten hat, kann er
fragen. Aber auf dem Silbertablett präsentiere ich ihm die
komplette Lösung nicht.