Begrenzung eines Wertes auf 0

Vermutlich ist wert unsigned und wird später als signed angezeigt.

Bitte Code posten

Der Code mit Anzeige und geänderten Namen.

1

if ( !(PINA & (1<<PINA7)) )

2

      {        

3

      if(OCR1B > 0);

4

        {

5

        OCR1B = OCR1B - 10;

6

        }

7

      if(OCR1B<0)

8

        {

9

        OCR1B = 5;

10

        }  

11

      _delay_ms(1);

12

      }  

13

14

     utoa(OCR1B,wert,10);        // Berechne wert von OCR1B

15

     lcd_printlc(3,2,"OCR1B =");    // Anzeige CCR1B

16

     lcd_printlc(3,11,"        ");    // lösche aleten Wert

17

     lcd_printlc(3,12,wert);      // Anzeige wert 

18

19

     grad = OCR1B / 16;

20

     utoa(grad,grade,10);        // Berechne Wert von OCR1B für Winkel

21

     lcd_printlc(4,3,"Grad =");

22

     lcd_printlc(4,11,"        ");  

23

     lcd_printlc(4,12,grade);

Die Anzeige der Werte erfolgt mit utoa korrekt, ebenfalls die Bgrenzung 
nach oben auf 2890. Wenn ich 0 erreiche geht es in den negativen 
Bereich.
OCR1B kann doch nur 0 -3999 haben (Timer 16 Bit mit 16MHz Quarz auf 
20ms)
Es geht dabei nur um die Begrenzung von OCR1B auf 0.

Udo S. schrieb:
> was soll hier das Semikolon hinter der Bedingung?

Danke, das war der Fehler. Brauche wohl doch bald eine Brille.

Udo S. schrieb:
> was soll hier das Semikolon hinter der Bedingung?

Damit soll die IF Anweisung sofort beendet werden, damit der 
nachfolgende Code auf jeden Fall ausgeführt wird.
Und dieser Nachfolgenden Anweisungsblock solle einen eigenen unbenutzten 
Namensraum/Geltungsbereich öffnen.
(wozu auch immer)

Müsste die IDE nicht an dieser Stelle eine Warnung anzeigen?

Udo S. schrieb:
> was soll hier das Semikolon hinter der Bedingung?

Scharfer Blick, nicht schlecht!

Und ein schönes Beispiel für eine völlig verrückte Programmiersprache, 
die solchen Unfug zulässt.

Jeden Tag aufs Neue ein Wunder, dass unsere Welt noch immer 
zusammenhält, irgendwie zumindest, wenn man sich überlegt, mit welchen 
mistigen Sprachen Software gebaut wird. Wahnsinn.

Seit wann kann ein OCR negativ werden?

Du solltest eine Dummy-Variable nutzen und nach der Versrbeitung dem
Register zuweisen, dubble-buffered oder in Software timersynchron

Stefan ⛄ F. schrieb:
> Müsste die IDE nicht an dieser Stelle eine Warnung anzeigen?

Anweisungen und auch Anweisungsblocks dürfen leer sein.
Also nein.

Kann/wird sich allerdings ändern.
z.B. while(1);

EAF schrieb:
> Anweisungen und auch Anweisungsblocks dürfen leer sein.

Ist mir schon klar. Von einer zeitgemäßen IDE erwarte ich trotzdem 
solche Hilfestellungen.

Stefan ⛄ F. schrieb:
> Von einer zeitgemäßen IDE erwarte ich trotzdem solche Hilfestellungen

ein compiler ist doch keine "Mutti" :-)

Helge schrieb:
> ein compiler ist doch keine "Mutti" :-)

Wer solche Warnungen unterdrückt oder ignoriert ist von Mutti wohl zu 
heiß gebadet worden. Da muss dann der Compiler Ran.

Stefan ⛄ F. schrieb:
> Müsste die IDE nicht an dieser Stelle eine Warnung anzeigen?

In C?
Warum sollte eine leere Anweisung verboten sein?
Die Syntax-Regeln erlauben soviel logische Sch..ße zu bauen ...
Warnungen sind der verzweifelte Versuch dem C die 
Assemblernähe/-freiheit auszutreiben

Rolf M. schrieb:
> Man könnte noch die magischen Werte ersetzen:

🎹 ... this is the road ...

Helge schrieb:
>> Von einer zeitgemäßen IDE erwarte ich trotzdem solche Hilfestellungen
> ein compiler ist doch keine "Mutti" :-)

Ich habe "IDE" geschrieben, nicht "Compiler".

Forist schrieb:
> Warum sollte eine leere Anweisung verboten sein?

Es geht nicht um "verboten", sondern um "wahrscheinlich so nicht 
gewollt". Von meinen Entwicklungsumgebungen bin ich entsprechende 
Warnhinweise gewohnt.

Auch z.B. wenn man einen switch/case schreibt, in dem ein wahrscheinlich 
case vergessen wurde. Oder wenn man eine Variable liest, bevor man sie 
beschrieben hat.

Rolf M. schrieb:
> Warum ist das jetzt besser?

Weil jetzt viel eher auffällt, dass der Anweisungsblock der if-Bedingung 
leer ist. Das Semikolon im ersten Beitrag des TO hab' ich auch erst 
nicht gesehen.

Der Bastler schrieb:
> Udo S. schrieb:
>> was soll hier das Semikolon hinter der Bedingung?
>
> Danke, das war der Fehler. Brauche wohl doch bald eine Brille.

Wäre mit Python nicht passiert.

Rolf M. schrieb:
> if (x<0){;}
> Warum ist das jetzt besser?

Weil man so etwas nicht aus Versehen hin schreibt. Wenn das so im Code 
steht, war es mit Sicherheit Absicht.

Rolf M. schrieb:
> Also könnte der Compiler, ... vorzuschlagen

Ich sehe es wie Helge

Helge schrieb:
> ein compiler ist doch keine "Mutti"

Diese ganzen Checks gehören meiner Meinung nach in ein separates 
Programm ausgelagert welches in die IDE eingebunden ist. Die Zeiten wo 
mir mit Edlin programmierten sind nämlich vorbei.

Rolf M. schrieb:

>

1

>     if (x<0){;}

2

>

> Warum ist das jetzt besser?

Weil damit angezeigt wird, dass dieser Schwachsinn, so schwachsinnig er 
auch ist (und immer bleiben wird) BEABSICHTIGT ist. Es ist schlicht sehr 
einfach, versehentlich ein ";" zu schreiben, aber schon sehr viel 
unwahrscheinlicher, versehentlich ein "{;}" zu schreiben.

Das eigentliche Ziel ist also, sehr wahrscheinlich nicht so gewollte 
Sachen nochmal zum Nachdenken vorzulegen. Und der Vorschlag dient dazu, 
für den unwahrscheinlichen Fall, dass der Schwachsinn doch beabsichtigt 
war, die Warning für die Zukunft nicht mehr erscheinen zu lassen. Der 
Schwachsin darf also Bestand haben, wenn es denn wirklich so gewollt 
ist. Wozu auch immer...

Aber wer würde sich mit den richtigen C-Cracks auf eine Sinndiskussion 
einlassen? Das ist genauso nutzlos, wie mit erz-islamischen Taliban über 
Frauenrechte zu streiten oder mit dem Papst über den Sinn des Zölibats.

Eiferer jeder Coleur, die ihren ganzen Lebensinhalt darin sehen, eine 
"Schrift" möglichst wortgenau zu befolgen, sind einfach keine dankbaren 
Diskussionspartner.