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.
Also ich bin der meinung das die rechnung die billigere Methode ist... ((MSB<<8)+LSB)/10
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
Wieviel Millionen Sensorwerte pro Sekunde kommen denn rein, daß Du keine Zeit mehr zum Rechnen hast ? Peter
Und welcher Prozessor, der 64k freies FLASH für eine 16Bit LUT hat, ist nicht schnell genug, um die lächerliche /10 zu rechnen?
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
>((MSB<<8)+LSB)/10
((MSB<<8)|LSB)/10
dürfte noch etwas besser sein.
Was'n das für'n Roboter?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.