Zitat : perl hat am  6 Apr 2010 12:33 geschrieben :

Du solltest mal das ganze Programm zeigen

Bitteschön.
So wie es jetzt ist,funktioniert das.
(Nach vielen Stunden probieren)
Wenn ich allerdings X und X1 rausnehme,und das so schreibe wie oben erwähnt,dann geht nichts.
Also das Unterprogramm "regeln" tut dann nix,der Rest funktioniert (und funktionierte) schon immer.
(Den Meß und Anzeigekram für den zweiten Sensor hab ich mal wegen besserer Übersichtlichkeit rausgelöscht)

Code :

$regfile = "m8def.dat" $crystal = 4000000 $baud = 9600 Config Lcdpin = Pin , Db4 = Portc.0 , Db5 = Portc.1 , Db6 = Portc.2 , Db7 = Portc.3 , E = Portc.4 , Rs = Portc.5 Config Lcd = 16 * 2 Config 1wire = Portb.0 Config Portb.1 = Output Config Portb.2 = Output Config Timer1 = Pwm , Prescale = 1 , Pwm = 8 , Compare A Pwm = Clear Down , Compare B Pwm = Clear Down Enable Timer1 Dim X As Byte Dim X1 As Byte Dim Y As Single Dim Z As Byte Dim T As Integer Dim T1 As Integer Dim T4 As String * 10 Dim T6 As Single Dim Ar1(9) As Byte Dim Id1(8) As Byte Dim Id2(8) As Byte Dim Tmp As Byte Id1(1) = 1wsearchfirst() Id2(1) = 1wsearchnext() Cls Cursor Off Do Config Pind.7 = Input Bitwait Pind.7 , Set Gosub Messen Wait 5 If T6 > 25 Then Compare1a = 60 Gosub Regeln Else Compare1a = 0 End If Loop Regeln: X = 30 X1 = 10 Do Gosub Messen Y = T6 Wait 4 Gosub Messen If T6 > Y Then Z = Z + X If T6 < Y Then Z = Z - X1 If Z < 60 Then Z = 60 If Z > 255 Then Z = 255 Compare1a = Z If T6 < 26 Then Return If Pind.7 = 0 Then Gosub Nachlauf End If Loop Nachlauf: Compare1a = 255 Wait 120 Compare1a = 0 Cls Return Messen: 1wreset 1wwrite &H55 1wwrite Id1(1) , 8 1wwrite &H44 Waitms 400 1wreset 1wwrite &H55 1wwrite Id1(1) , 8 1wwrite &HBE Ar1(1) = 1wread(9) 1wreset Tmp = Ar1(1) And 1 If Tmp = 1 Then Decr Ar1(1) T = Makeint(ar1(1) , Ar1(2)) T = T * 50 T = T - 25 T1 = Ar1(8) - Ar1(7) T1 = T1 * 100 T1 = T1 / Ar1(8) T = T + T1 T = T / 10 T6 = T / 10 T4 = Fusing(t6 , "#.#") Locate 1 , 1 : Lcd "Case = " ; T4 ; " C" Return

Zitat :

P.S.: Setze vorsichtshalber auch mal Klammern: If (A > B) Then C = C+10

Das hab ich schon so versucht,da meckert der Compiler aber immer mit
"Assignment Error"

_________________
Manche Männer bemühen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitätstheorie.
(Albert Einstein)

[ Diese Nachricht wurde geändert von: Kleinspannung am  6 Apr 2010 13:30 ]

Moin KS!

Da T eine globale Variable ist, und durch messen verändert wird, wird der Compiler vermutlich eine fehlerhafte "Optimierung" durchführen.

Das ändert aber nichts an der Tatsache, dass nicht auf Gleichheit getestet wird.
Mithilfe der Operatoren <= und >= kann man das umgehen.

Die Variable 'Z' kann übrigens vorzeichenlos nur max. 255 beinhalten, daher ist folgender Ausdruck zu überprüfen:

If T6 > Y Then Z = Z + X

If T6 < Y Then Z = Z - X1

If Z < 60 Then Z = 60

If Z > 255 Then Z = 255

Ein guter Compiler würde meckern, von wegen "Ausdruck immer falsch aufgrund des Wertebereichs" oder so ähnlich und gnadenlos wegoptimieren.
Ich vermute jedenfalls einen Zusammenhang mit der Tatsache, dass T global ist.


Edit:

Zitat :

Schreibe ich If A > B Then C = C + X Else C = C - X end if

Das ist so völlig korrekt und wird auch auf Gleichheit nicht unerwartet reagieren.



_________________


[ Diese Nachricht wurde geändert von: DonComi am  6 Apr 2010 17:11 ]

zitat "http://www.rn-wissen.de/index.php/Bascom#Syntax_f.C3.BCr_Rechenoperationen":

Syntax für Rechenoperationen

BASCOM kann nur eine Rechenoperation pro Zeile verarbeiten!

a = b * 2 + c

funktioniert nicht. Stattdessen müssen die Operationen aufgeteilt werden:

a = b * 2
a = a + c


und "http://www.rn-wissen.de/index.php/Bascom#Wie_man_besonders_kompakten_Code_erzeugt":

Vermeide a>b, verwende a>=c oder b<a (RISC-Prozessor kennt kein größer als)

Zitat : knallerbse hat am 13 Apr 2010 10:52 geschrieben :

BASCOM kann nur eine Rechenoperation pro Zeile verarbeiten!

Ich habs geahnt...

Zitat :

(RISC-Prozessor kennt kein größer als)

Das wußt ich,aber irgendwie gehts trotzdem.
Wobei ich nicht weiß,in was es das Programm bzw. der Compiler dann so verwurschtelt...






_________________
Manche Männer bemühen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitätstheorie.
(Albert Einstein)

Zitat :

Das wußt ich,aber irgendwie gehts trotzdem

Dann solltest du dir mal in der Assembly ansehen, was der Compiler daraus macht.
Zum Einen gibt es Äquivalenzen, z.B. ist a > b das Gleiche wie b < a, die der Compiler ausnutzen kann,
und zum Anderen wäre es möglich, dass die Operanden zunächst in Hilfsvariablen geladen werden um sie in die benötigte Form zu bringen. Letzeres kostet natürlich Zeit und Speicherplatz.

Zitat :

BASCOM kann nur eine Rechenoperation pro Zeile verarbeiten!

...

_________________

Zitat : DonComi hat am 13 Apr 2010 18:15 geschrieben :

Zitat : BASCOM kann nur eine Rechenoperation pro Zeile verarbeiten! ...

Da kannst du johlen wie du willst,aber mir ist eine Programmiersprache 10x lieber in der ich ein oder zwei Befehle tippe und dann passiert was,anstatt ne ellenlange Litanei kryptischer Zeilen zu produzieren um irgendwelche register mit irgendwas zu laden.
Mich (und vermutlich die Hälfte aller Hobbyprogrammierer) tangiert nämlich peripher in welchem Register was herumhampelt solange am ende das herauskommt was man wollte.
Vielleicht lerne ich mal noch was anderes als Bascom,aber Assembler vermutlich nichtmal unter Androhung von Gewalt.
Das ist was für Masochisten und Hyperintelligente,und ich zähle mich zu keiner der beiden Randgruppen.

_________________
Manche Männer bemühen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitätstheorie.
(Albert Einstein)

Ich lache ja nur, weil es ulkig ist - BASCOM kostet Geld und kann nichtmal mehrere Operationen pro Zeile.

C (GCC) kostet nix und kann es.
(Gut, in C und Konsorten spielen Zeilenumbrüche auch keine Rolle, da muss es klappen, wenn es C-konform sein soll; das ist eines der sympathischen Dinge daran.)


Ich lache ja deshalb keineswegs die Benutzer von BASCOM aus - im Gegenteil!




_________________

Zitat : Kleinspannung hat am 13 Apr 2010 23:24 geschrieben :

...kryptischer Zeilen zu produzieren um irgendwelche register mit irgendwas zu laden...

Das ist wie Schrauben an einer Karre, bei der man jedes Teil kennt.

_________________
„Schreibe nichts der Böswilligkeit zu, was durch Dummheit hinreichend erklärbar ist.“
(Hanlon’s Razor)

Zitat :

mir ist eine Programmiersprache 10x lieber in der ich ein oder zwei Befehle tippe und dann passiert was,

Die Frage ist nur, -wie in deinem Fall-, was dann passiert.
Da ist der Assemblerprogrammierer klar im Vorteil, denn i.A. weiß er sehr genau was jeder Befehl bewirkt. Mit etwas Erfahrung nimmt er auch die Optimierungsmöglichkeiten wahr, die dieser "Compiler" ja offenbar nicht bietet.

Wenn der Bascom tatsächlich die von knallerbse genannten Einschränkungen hat, -und dann wohl noch ein paar mehr-, so ist das auch nur ein schlechterer Assembler.
Wenn man nicht masochistisch veranlagt ist, wird man damit nicht ernsthaft die großen Programme schreiben wollen, die in die Speicher moderner Controller hineinpassen.

Zitat :

anstatt ne ellenlange Litanei kryptischer Zeilen zu produzieren

Das ist gar nicht so wild.
Bei kleinen Programmen kann es durchaus sein, dass das eigentliche Programm viel kürzer ist als diese "kryptischen Zeilen". Dabei handelt es sich oft genug nur um die maschinengerechte Beschreibung des Prozessors und um Anweisungen an den Assembler wie er das Programm übersetzen soll. Da sich das oft von Programm zu Programm überhaupt nicht ändert, kann man es auch einmalig schreiben und dann auslagern und so unsichtbar machen. Dadurch werden die Programmlistings wesentlich schlanker.
Die Compiler/Linker von Hochsprachen machen das nicht viel anders, aber sie setzen das entstehende Maschinenprogramm mosaikartig aus einer Vielzahl kleiner Programmstückchen zusammen, die in Bibliotheken bevorratet werden. Oft hat der Anwender aber nur wenig oder gar keinen Einfluss darauf, wie dies geschieht.
Deshalb sollte man, um rätselhafte Fehler in compilierten Hochsprachenprogrammen zu finden, sogar sehr gut Assembler können.

Offtopic :

Wobei mir noch nicht ganz klar geworden ist, warum man sowas kompliziertes wie C braucht (viel zu unübersichtlich, die ganzen Initalisierungen, bei BASCOM stehen die am Anfang und damit hat es sich) BASCOM kann auch Subroutinen, aber viel übersichtlicher als C ... Wird man vom ständigen ;-Tippen nicht wahnsinnig?

_________________

Offtopic :

Zitat : warum man sowas kompliziertes wie C braucht C ist nicht kompliziert, eher das Gegenteil. Aber der Sourcecode ist sehr dicht, fast jedes Zeichen "tut" nach strengen Formalismen irgendetwas und dadurch kann man sehr leicht unübersichtliche und kryptische Programme schreiben. Je nach Version und/oder Einstellung ist es damit auch möglich falsche Programme zu schreiben, deren grobe Fehler nicht entdeckt werden und anstandslos in irrwitzige Maschinenbefehle übersetzt werden.

@Nicki

Sieht so aus, als hättest du noch nie in C programmiert...

Bekanntlich kann man viel unübersichtlich machen (da gibt es speziell für C sogar Wettbewerbe, wer am besten unleserlichste Programme schreiben kann), aber der Normalfall ist das nicht.

Man sollte halt auch verstehen, was da passiert.
Bei BASCOM habe ich immer das Gefühl, dass selbst der verhältnismäßig simple C-Präprozessor leistungsfähiger ist...

Edit:
Jetzt gerade sitze ich dabei, ein Programm auf drei Architekturen zu portieren. Alles in C geschrieben.
Was meinst du; mit Sachen wie BASCOM wäre das gar nicht denkbar. Viel zu speziell.
Mit C kann man praktisch für alle existierenden Architekturen Programme entwickeln, und gegen die angesprochenen Bibliotheken linken.
Diese Bibliotheken hängen von Architektur und eventuell vorhandenem Betriebssystem ab.

Zudem solltest du bedenken, dass C in der Industrie oder sonstwo absolut unverzichtbar ist. Treiberschnittstellen z.B. sind klassisch in C kodiert.


P.S.: ich habe mal mit VB "gearbeitet", das war ein Krampf nach dem anderen...
Da sind selbst die diversen Versionen untereinander inkompatibel.
Wenn man sich bei C an einen Standard hält (z.B. ANSI-C), dann läuft die Laube.
Wenn man dann noch auf POSIX-komp. OS entwickelt, kann man das Programm auf unterschiedlichen OS' übersetzen - es läuft!

_________________


[ Diese Nachricht wurde geändert von: DonComi am 14 Apr 2010  2:30 ]