Hallo zusammen,
ich lese einen Sensor aus per I2C (HCS12) aus, 2 Byte. Daraus kann man
nun einen Wert ermitteln, also die Sensordaten quasi. Das MSB wir zuerst
gelesen.
Um nun beide zusammen zu bringen, muss man ja nun 256*(1.Byte)+(2.Byte)
rechnen. Anschließend muss ich das ganze noch durch 10 teilen und ich
habe meinen gewünschten Wert.
Ich würde nun aber gerne so weit wie möglich auf Rechnungen verzichten
und würde das gerne mit Look-Up-Table machen. Für ein anderes Projekt
habe ich einfach ein Array erstellt. Der Sensorwert war dann das x-te
arrayelement.
Hier muss ich aber eh erst einmal die beiden Byte zusammen bringen mit
256*(1.Byte)+(2.Byte). da lohnt sich so eine Tabelle ja nicht.
Hat jemand eine Idee, wie ich das noch lösen könnte?
Vielen Dank
Grüße
>Hat jemand eine Idee, wie ich das noch lösen könnte?
Eine solche Tabelle hat ja nur 65536 Einträge...
Ich weiß leider nicht, wie lange ein HCS12 zum Schieben eines Bytes und
einer Division braucht. Der AVR kann das relativ schnell machen...
Hallo,
am einfachsten ist ein Linearisierungspolynom. Oft reicht schon 2. oder
3. Grades, um eine gekrümmte Sensorkennlinie gerade zu biegen.
Wieso soll sich eine Look-Up-Table nicht lohnen ? Die muß ja nicht über
die ganze Datenbreite des Sensorwertes gehen. Möglicherweise reichen
schon 16 Korrekturwerte, die über die 4 MSBs adressiert werden und zum
Sensorwert addiert werden.
Jörg
>Wieso soll sich eine Look-Up-Table nicht lohnen
Steht da irgendwas von Linearisierung?
Für mich steht da nur, dass jemand meint, ein Lookup-Table wäre
effizienter als zwei Casts, ein achtfaches Linksschieben, ein bitweises
16-Bit-Verodern und eine Division.
Das einzige Problem, das ich dabei sehe, wäre eine
Assembler-Implementation (und da dann auch nur die Division).
a)
>Ich würde nun aber gerne so weit wie möglich auf Rechnungen verzichten
b)
>Oft reicht schon 2. oder 3. Grades, um eine gekrümmte Sensorkennlinie >gerade zu
biegen.
a) verbietet b), oder?
Hallo,
das mit der Korektur verstehe ich auch nicht. Ich will ja nix
korrigieren. ich habe halt nur Zwei Byte, die den Sensorwert
Repräsentieren. Um nun einen brauchbaren Wert zu bekommen, muss ich nun
noch ein wenig rumrechnen. Also erst einmal die beiden Byte zusammen
bekommen und diesen Wert dann noch durch 10 teilen. Dabei möchte ich
gerne soweit wie möglich auf Rechnungen verzichten.
Grüße
>Dabei möchte ich gerne soweit wie möglich auf Rechnungen verzichten.
Warum?
Die einzelnen Schritte habe ich oben doch schon genannt.
Wie lange sowas bei dem Controller dauert, weiß ich nicht, weil ich ihn
nicht kenne.
http://www-user.tu-chemnitz.de/~heha/Mikrocontroller/Division.htm
> Also erst einmal die beiden Byte zusammen> bekommen und diesen Wert dann noch durch 10 teilen. Dabei möchte ich> gerne soweit wie möglich auf Rechnungen verzichten.
Aus den beiden Bytes den Wert zusammenzusetzen ist eigentlich
keine wirkliche Berechnung im arithmetischen Sinn. Das ist
mehr ein: Das Byte an die richtige Stelle kopieren.
Bleibt noch die Division durch 10. Da fällt mir aber
auch kein Trick dafür ein, wie man um die Division rumkomt.
Eine 16Bit Division Ist aber auch nicht so wild.
NB: Worüber reden wir eigentlich? Assembler oder C?
Ansonsten kann ich nur sagen: Du hast grade die
'Space for Time' Gesetzmässigkeit entdeckt: Entweder
du investierst ein bischen Laufzeit und hast einen
kleinen Speicherverbrauch oder aber du erkaufst dir
Laufzeit mit einer Investition in den Speicherverbrauch.
Das ist bei vielen Projekten so.
Eine Division durch 10 ist auch in Assembler nicht so wild. Eine
Division durch 2-er-Potenzen geht durch reine Bitschieberei. Dann muß
man nur noch addieren. X/10 = X/16 + X/32 + X/256 + X/512 ... usw. je
nach gewünschter Genauigkeit.
Jörg
Hi!
Das Ding hat HW-IDIV, was willst du denn noch.
<Das MSB wir zuerst gelesen.
<Um nun beide zusammen zu bringen, muss man ja nun 256*(1.Byte)+(2.Byte)
<rechnen.
Verstehe ich überhauptnicht. Ich sehe nur einen 16
Bit-Wert,MSB+7Bit=High,
7Bit+LSB=low.
Wenn sie einzeln kommen
LDAA (high)
LDAB,(low)
ansonsten
LDD(high)
ldx #10
IDIV
Ergebnis steht in X
Rest steht in D
MFG Uwe
Hallo,
das ding wir in einen Roboter eingebaut. der hat noch "hunderte" andere
Sensoren und nicht nur diesen einen. Das ding hat usb, Bluetooth und
andere Funkschnittstelle. Da muss man dann schon Rechenzeit sparen wo es
geht.
Grüße
Sumli wrote:
> andere Funkschnittstelle. Da muss man dann schon Rechenzeit sparen wo es> geht
Nö.
Das ist der vollkommen falsche Ansatz.
Man kann nur dort Rechenzeit sparen, wo es sich auch bemerkbar macht.
Also immer erstmal prüfen, wie oft wird eine Task aufgerufen und wieviel
CPU-Last bedeutet das überschlagsmäßig.
Wozu stunden- oder tagelang nutzlos rumoptimieren, wenn es eh schon
unter 1% CPU-Last liegt.
Wenn ich die Festplatte aufräume, gucke ich mir ja auch nur die
Dateien/Verzeichnisse an, die größer 100MB sind. Irgendwelche
100kB-Winzlinge laß ich einfach liegen.
Peter
Hallo,
habe das jetzt einfachso gelöst, wie oben vorgeschlagen:
((MSB<<8)+LSB)/10
Das funktioniert.
Stimmt schon, dass das Auslesen ja nicht immer läuft. Der Sensor wird
auch nicht ständig abgefragt.
Vielen Dank.
Grüße
