Und da haben wir schon das erste Problem: Woher wissen wir was mit dem Wert gemacht werden soll und was nicht? Er gab uns nur Codeauszüge.
Zufällig war die Dimensionierung von Strom jetzt mit dabei.
Vorallem mag Bascom es nicht wenn man eine Fliesskommazahl in einen Datentyp speichern möchte der nur Ganzzahlen aufnehmen kann.
Probier es mal aus Strom as Single zu machen, eine zweite Variable benötigst Du, wie ich oben ja anders schrieb, wohl nicht.
Geändert von HeXPloreR (31.10.2013 um 12:00 Uhr)
... jo ... erstmal Dank für Eure Hinweise. Ich habe es jetzt "irgendwie" gelöst bekommen, schaut aber ganz schön gruselig aus ^^
Sinn der Sache:
Über einen Shunt von 0,47Ohm gegen Masse wird die Stromaufnahme eines Motors gemessen. Der Spannungsabfall wird via 3k3 an den Pin und mit 100n Pin gegen Masse gegen all zu schnelle Spitzen geblockt.
Als Konstante gebe ich den Maximalwert in mA vor.
Abgefragt wird via Timer0 etwa alle 100ms in der dazu gehörenden ISR. Wenn der Strom (resp. die Spannung an Pin5) den vorgegebenen Wert übersteigt, wird eine BitVar (Iover) gesetzt und der EN des Motorcontrollers abgeschaltet. So lange das Bit gesetzt ist, wird eine ByteVar bei jedem Aufruf der ISR um eins hochgezählt und bei 100 das Flag wieder gelöscht.
Eigentlich wäre es schöner, wenn man irgendwie dafür sorgen könnte, das bei Erreichen/Überschreiten eines Vorgabewertes der DAC selbst einen IRQ auslöst ohne das man aktiv in Intervallen den DAC abfragen muß. Aber dazu habe ich in Bascom keine Möglichkeit finden können.
Ok, wie gesagt tut es nun (VarTypen angepasst), aber natürlich hätte ich nichts dagegen, wenn von Euch noch ein paar andere Lösungen kommen, damit ich vielleicht eine andere Denkweise bei solchen Sachen erlernen kann...
DlzG
Micha
Hallo Micha,
Prozessoren ohne FPU müssen Fliesskommaberechnung über eine Bibliothek erledigen. Diese braucht einiges an Platz im ROM und ist etwa 100x langsamer als eine FPU.Zitat von M_I_B
Es macht also in vielen Fällen Sinn, Fliesskommaoperationen zu vermeiden.
Es kann also Sinn machen, wenn du alles in mV und mA rechnest, dann kommst du mit Integern durch.
Und anstatt
x *0.47
zu rechnen, was eben nur mit Fliesskomma geht, kann man auch
(x * 100) / 47
rechnen, was mit Integern geht (Allerdings muss man aufpassen, dass (x *100) in jedem Fall noch in den gewählten Integer passt. Obwohl du eine Multiplikation und eine Division machen musst, ist das oft als Integerrechnung schneller als eine einzelne Fliesskomma-Multiplikation.
Bei der Ausgabe muss man dann den Dezimalpunkt an der richtigen Stelle einsetzen, aber das geht rein über Textmanipulation.
Ich kann mich nicht erinnern, dass ich in den letzten 30 Jahren auf einem Microcontroller einmal Fliesskommaoperationen gebraucht habe. Selbst bei der Linearisierung eines NTC lässt sich so umformen, dass man mit Integern zurecht kommt. Im professionellen Bereich bedeuten mehr ROM und mehr Rechenleistung immer auch höhere Kosten, welche man dann mit den Stückzahlen multiplizieren muss.
Wie schon gesagt, ich habe da dann auch mal mit 1/40tel Grad gerechnet (wegen den Rundungsfehlern, gefordert waren nur 1/10 Grad).
MfG Peter(TOO)
Doch HeXPloreR, genau dieses "Casten" mag Bascom, nur nicht Ganzzahl und Fließkomma vergleichen.
ja for_ro, Du hast recht. Bascom macht automatisch einen cast aus 0,00215 wird 0. Man merkt hier sehr gut jetzt ist wieder der Programmierer gefragt darauf zu achten das wenn er 0,XXX Werte mit einem Ganzzahlentyp weiter verarbeitet das möglicherweise etwas abgeschnitten wird und nicht nur, wie in diesem Fall zwei verschieden Datentypen der Vergleich nicht klappt, sondern das der Vergleich auch nicht korrekt sein könnte nach einem solchen cast, wenn es auch um die Dezimalstellen geht.
Berechtigungen
Zitieren
Lesezeichen