"while(1)" will nicht so wie Ich

[Dennis K. (dkeipp)]

N'abend

Ich sitze jetz seit Mittag am Rechner, studiere den GCC Kurs und 
Programmiere eine Steuerung für's Garagentor (Die Alte habe ich wegen 
blindheit abgeschossen --> 230V an den Triggereingang ;-)
Soweit macht der AVR auch das was er soll, aber halt nur ein mal.

Ich habe testhalbe nochmal versucht ein Ausgang Blinken zu lassen, 
dieser geht aber nur einmal auf "1" dann wieder zu "0". Woran könnte das 
liegen?

#define F_CPU 1000000UL  // 1 MHz
#include <avr/io.h>
#include <util/delay.h>

int main (void) 
{

DDRD = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (0 << DDB4) | (0 << DDB5) | (0 << DDB6) | (0 << DDB7);
PORTD = 0x00; //PortD zurücksetzen und keine Pullup's
_delay_ms(500); //Netzteil bedenk zeit

//In undefinierten Zustand Tor öffnen
  if ((PIND & (1<<PIND5)) && (PIND & (1<<PIND6)))  //Wenn PinD4=1 und PinD5=1 (Beide Endschalter frei)
    {
    //tor_oeffnen(); Ignorieren, funktioniert
    }

//##-Hauptschleife-##\\
  while(1) 
  {
    _delay_ms(500);
    PORTD |= (1 << PD2);
    _delay_ms(500);
    PORTD &= ~(1 << PD2);
  }
  
return 0;
}

[Mark B. (markbrandis)]

Wenn

while(1)

 nicht tut, dann nimm

for(;;)

 ;-)

[Dennis K. (dkeipp)]

hmmm... selbes problem!
trotzdem Danke!

Ich geh jetzt einen Trinken. Vielleicht geht's morgen besser...


Prost
Dennis

[MeinerEiner (Gast)]

Kann mich täuschen, aber welche Optimierung ist denn beim Compiler drin?
O0 (also keine) mag die delay-Funktionen (zumindest bei mir) nicht.
Mit Os gehts wie's soll.

[ozo (Gast)]

Der Parameter für _delay_ms ist beschränkt. Steht in der Doku, 500 ist 
zu groß afaik.

[Simon K. (simon)]

ozo schrieb:
> Der Parameter für _delay_ms ist beschränkt. Steht in der Doku, 500 ist
> zu groß afaik.

http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html
---
The maximal possible delay is 262.14 ms / F_CPU in MHz.

When the user request delay which exceed the maximum possible one, 
_delay_ms() provides a decreased resolution functionality. In this mode 
_delay_ms() will work with a resolution of 1/10 ms, providing delays up 
to 6.5535 seconds (independent from CPU frequency). The user will not be 
informed about decreased resolution.
---

[Jörg W. (dl8dtl) (Moderator)]

Dennis Keipp schrieb:

> DDRD = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) |
> (0 << DDB4) | (0 << DDB5) | (0 << DDB6) | (0 << DDB7);

OK, also Bits 0...3 sind Eingang, bits 4...7 Ausgang.

> PORTD = 0x00; //PortD zurücksetzen und keine Pullup's
> ...
>   if ((PIND & (1<<PIND5)) && (PIND & (1<<PIND6)))

So du nicht gerade die beiden Ausgänge hier mit Brachialgewalt
hochziehst (Kurzschluss am Ausgang nach Vcc) sind die beiden Bits
immer 0, da der Ausgang ja bisher auf 0 gesetzt worden war.

>     PORTD |= (1 << PD2);
>     ...
>     PORTD &= ~(1 << PD2);

Hier wird der Pullup an PORTD2 aus- und eingeschaltet.  Ein typischer
AVR-Pullup liefert bei Vcc = 5 V und 2 V am Eingang (Flussspannung einer
nicht-blauen LED) ca. 80 µA.  Könnte man im Dunkeln gerade noch so
erkennen.

[Stefan E. (sternst)]

Jörg Wunsch schrieb:

>> DDRD = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) |
>> (0 << DDB4) | (0 << DDB5) | (0 << DDB6) | (0 << DDB7);
>
> OK, also Bits 0...3 sind Eingang, bits 4...7 Ausgang.

Ähm ...

[Peter (Gast)]

>Wenn
>
>while(1)
> nicht tut, dann nimm
>for(;;)
> ;-)

Quatsch mit Sauce! while(1) funktioniert mit Sicherhet und tut beim 
AvrGcc das selbe wie for(;;). Ich persönlich finde while(1) schöner, 
lesbarer, logischer, besser... aber hierüber streiten sich bereits die 
Gemüter.

> OK, also Bits 0...3 sind Eingang, bits 4...7 Ausgang.

Es ist umgekehrt!

[Peter (Gast)]

Welche IDE verwendest Du? AvrStudio? Eclipse? Programmers-Notepad? Gibt 
es Warnings beim Compilieren? Hast Du den CPU-Typ definiert? Poste mal 
den Compiler-Output.

==> ../main.c:18:1: warning: multi-line comment

Mit //##-Hauptschleife-##\\ wird die nächste Zeile "while(1)" ebenfalls 
auskommentiert, Du musst die "\\" am ende der Zeile wegnehmen!

Und wie schon erwähnt, _delay_ms(500) ist zu gross!
> The maximal possible delay is 262.14 ms / F_CPU in MHz.

Folgende Version müsste funktionieren

#define F_CPU 1000000UL  // 1 MHz
#include <avr/io.h>
#include <util/delay.h>

void delay_ms(unsigned int timeout);

void delay_ms(unsigned int timeout)
{
  while(timeout--)
  {
    _delay_ms(1);
  }
}
int main (void)
{
  DDRD  = 0x0F;
  PORTD = 0x00; //PortD zurücksetzen und keine Pullup's
  delay_ms(500); //Netzteil bedenk zeit
  //In undefinierten Zustand Tor öffnen
  if ((PIND & (1<<PIND5)) && (PIND & (1<<PIND6)))  //Wenn PinD4=1 und PinD5=1 (Beide Endschalter frei)
  {
    //tor_oeffnen(); Ignorieren, funktioniert
  }

  // ##-Hauptschleife-##
  while(1)
  {
    delay_ms(500);
    PORTD |= (1 << PD2);
    delay_ms(500);
    PORTD &= ~(1 << PD2);
  }
  return 0;
}

[Stefan E. (sternst)]

Peter schrieb:

> Und wie schon erwähnt, _delay_ms(500) ist zu gross!
>> The maximal possible delay is 262.14 ms / F_CPU in MHz.

Nein, ist es nicht.
Bei größeren Werten reduziert sich nur die Auflösung etwas:

When the user request delay which exceed the maximum possible one,
_delay_ms() provides a decreased resolution functionality. In this mode
_delay_ms() will work with a resolution of 1/10 ms, providing delays up
to 6.5535 seconds (independent from CPU frequency). The user will not be
informed about decreased resolution.

[Peter (Gast)]

>Nein, ist es nicht.

Ups, das war mal früher so, ich hätte einen Satz weiter lesen sollen! 
;o)

[Jörg W. (dl8dtl) (Moderator)]

Peter schrieb:

>> OK, also Bits 0...3 sind Eingang, bits 4...7 Ausgang.
>
> Es ist umgekehrt!

Tja.  Prima Beweis, dass die gewählte Schreibweise reichlich
unsinnig ist.  Die Anordnung der Bits auf der rechten Seite
widerspricht der ,,natürlichen Darstellung'', dadurch habe ich
mich verwirren lassen.

Ich hätte geschrieben:

DDRD = 0b00001111; /* falls GCC-Erweiterungen OK sind */
DDRD = 0x0f;       /* sonst */

[Jörg W. (dl8dtl) (Moderator)]

Ansonsten wüsste ich nicht, warum das alles nicht funktionieren sollte.
Da müsste der OP wohl mal komplett den bei ihm nicht funktionierenden
Sourcecode samt der Informationen zum benutzten Board und der
Compileroptionen posten, damit man das nachvollziehen kann.

[Stefan E. (sternst)]

Jörg Wunsch schrieb:
> Ansonsten wüsste ich nicht, warum das alles nicht funktionieren sollte.

Ich denke, Peter hatte schon den Finger drauf.

//##-Hauptschleife-##\\
  while(1)

ist ein Multi-Line-Kommentar.

[Johann L. (gjlayde)]

Stefan Ernst schrieb:

>

//##-Hauptschleife-##\\
>   while(1)
>

> ist ein Multi-Line-Kommentar.

...was gcc auch anmeckert mit -Wall:

warning: multi-line comment

[TheMason (Gast)]

schließe mich ebenfalls an mit der aussage : multiline-comment.

lass das \\ in der zeile davor weg (wofür ist das überhaupt ?!) und dann 
sollte es funktionieren.

[Oliver (Gast)]

>lass das \\ in der zeile davor weg (wofür ist das überhaupt ?!)

//##-Hauptschleife-##\\

sieht aber doch so schön symmetrisch aus. Das der Compiler aber auch so 
ein Kunstbanause sein muß...

Oliver

[Simon K. (simon)]

/* Hauptschleife */
Ist viel schöner.
Ganz weglassen ist aber auch nicht verkehrt ;) Wer nicht erkennt dass 
das eine Endlosschleife bzw. Hauptschleife ist...

[Peter (Gast)]

Ich sags ja schon lange, das "\\" am Zeilenende muss wech!

Das Doppel-Backslash bewirkt, dass die nächste Zeile dieser Zeile 
angehängt wird und da diese Zeile ausskommentiert ist, ist die nächse 
Zeile "while(1)" halt eben auch auskommentiert...!!!

Schreibe 1000 Mal:  Ich beachte und eliminiere alle Warnings in einem 
Programm!

MfG Peter

[Dennis K. (dkeipp)]

Jetzt Funktionierts. Ist mir schon Peinlich...

TheMason schrieb:
> ... (wofür ist das überhaupt ?!) ...

Beruflich Programmiere ich Roboter (Die Teile die Autos bauen, kein 
Spielzeug ;-) z.B. www.kuka.de), da habe ich mir solche Kommentare 
angewöhnt um schneller bestimmte Programmteile zu finden.

Gruß
Dennis

[Simon K. (simon)]

Simon K. schrieb:
> /* Hauptschleife */
> Ist viel schöner.
> Ganz weglassen ist aber auch nicht verkehrt ;) Wer nicht erkennt dass
> das eine Endlosschleife bzw. Hauptschleife ist...

[Dennis K. (dkeipp)]

Simon K. schrieb:
>> Ganz weglassen ist aber auch nicht verkehrt ;) Wer nicht erkennt dass
>> das eine Endlosschleife bzw. Hauptschleife ist...

Hast ja recht! Ich würde das als Hauptschleife erkennen, nur wäre das 
dann mit Sucharbeit verbunden. In diesem Code zwar eher weniger, da hier 
eigentlich nix drin ist.

[TheMason (Gast)]

>nur wäre das dann mit Sucharbeit verbunden

ist eig. nur dann mit sucharbeit verbunden wenn sonst in dem haupt-modul 
noch zig andere sachen stehen. ich z.b. hab mir angewöhnt das 
hauptprogramm entweder ein einer main.c oder in <projektname>.c zu 
schreiben, und bis auf test-sachen oder sachen die einfach direkt zum 
hauptprogramm gehören (z.b. initialisierung der sub-systeme) 
reinzupacken, die hauptschleife immer ganz unten im quellcode, und nach 
möglichkeit so kurz wie möglich zu halten. erhöht die übersicht und die 
lesbarkeit. mal so als anregung :-)

[Oliver (Gast)]

>Ist mir schon Peinlich...

Das braucht es nicht. Von den vier Editoren, die ich hier auf dem 
Notebook habe, stellen weder Notepad++, PN oder das AVR-Studio die Zeile 
richtig im Syntax-Highlighting dar. Da darf man schon mal drauf 
reinfallen. Nur Eclipse macht es richtig.

Oliver

[Oliver (Gast)]

Nachtrag: Das Foren-highlighting kann es natürlich auch nicht...

Oliver

[yalu (Gast)]

Oliver schrieb:

> Von den vier Editoren, die ich hier auf dem Notebook habe, stellen
> weder Notepad++, PN oder das AVR-Studio die Zeile richtig im
> Syntax-Highlighting dar. Da darf man schon mal drauf reinfallen. Nur
> Eclipse macht es richtig.

Nicht einmal Emacs färbt den Kommentar richtig ein. Mein Standardeditor,
der Vim, macht's zum Glück richtig. Sonst hätte ich natürlich sofort
einen Patch für das C-Syntax-File eingereicht :)

Aber der Fehler ist schon sehr fies. Ich habe ihn beim Durchlesen des
Quellcodes im Ursprungsbeitrag ebenfalls völlig übersehen.

[Abdul K. (ehydra)]

Cypress PSoC Designer 4.3 akzeptiert es so wie der Poster es meinte.

Gruß -
Abdul

[Sven P. (Gast)]

Dann ist entweder Cypress nicht Standard-C-konform oder aber du 
arbeitest mit Windumm, welches ja naturgemäß den Zeilenwechsel mit 
Wegenrücklauf+Zeilenvorschub, also Cr+Lf darstellt, und Cypress versteht 
(z.B. wie unter Linux üblich) nur den Lf als Zeilenwechsel. Dann wirkt 
nämlich der Rückstrich als Escape auf das Cr und der Zeilenwechsel kommt 
korrekt durch.

[Jörg W. (dl8dtl) (Moderator)]

Sven P. schrieb:
> Dann ist entweder Cypress nicht Standard-C-konform oder aber du
> arbeitest mit Windumm, welches ja naturgemäß den Zeilenwechsel mit
> Wegenrücklauf+Zeilenvorschub, also Cr+Lf darstellt, und Cypress versteht
> (z.B. wie unter Linux üblich) nur den Lf als Zeilenwechsel.

Auch dann wäre das Cypress aber kaputt, denn backslash-newline muss
mit dem native line ending des Betriebssystems zurecht kommen, auf
dem es läuft.

Solche Fehler dürften legitim höchstens dann passieren, wenn man auf
einem shared filesystem arbeitet und bspw. unter Unix editiert, aber
dann unter Windows compiliert.

[Peter (Gast)]

>Aber der Fehler ist schon sehr fies. Ich habe ihn beim Durchlesen des
>Quellcodes im Ursprungsbeitrag ebenfalls völlig übersehen.

Beim blossen Durchschauen des Codes bin ich auch darüber gestolpert, 
bzw. es ist mir nicht aufgefallen.

Wenn man sich aber die Compilerwarnigs zu Herzen nimmt und nicht einfach 
ignoriert, sollte man es schon merken!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Da bin ich mal beruhigt:
Mir wäre so ein Fehler früher aufgefallen, weil ich das nicht so

//##-Hauptschleife-##\\
  while(1) 
  {
    :
  }

sondern so schreibe

//##-Hauptschleife-##\\
  while(1) {
    :
  }

> Beruflich Programmiere ich Roboter, da habe ich mir solche Kommentare
> angewöhnt um schneller bestimmte Programmteile zu finden.
Diese Kommentare sind redundant, verwirrend und (vor allem) FALSCH 
:-o

  if ((PIND & (1<<PIND5)) && (PIND & (1<<PIND6)))  //Wenn PinD4=1 und PinD5=1 (Beide Endschalter frei)

Siehst du den Fehler?

Das hätte gereicht und es wäre in sich konsistent:

  if ((PIND & (1<<PIND5)) && (PIND & (1<<PIND6)))  // Beide Endschalter frei?

Fazit:
Kommentare, die das Offensichtliche kommentieren, sind überflüssig.

[Abdul K. (ehydra)]

Jörg Wunsch schrieb:
> Sven P. schrieb:
>> Dann ist entweder Cypress nicht Standard-C-konform oder aber du
>> arbeitest mit Windumm, welches ja naturgemäß den Zeilenwechsel mit
>> Wegenrücklauf+Zeilenvorschub, also Cr+Lf darstellt, und Cypress versteht
>> (z.B. wie unter Linux üblich) nur den Lf als Zeilenwechsel.
>

Äh. Es ging um den Unterschied zwischen '//' und '\\'.
Und wieso meckert ihr? Ein einzeiliger Kommentar wird in C mit '//' 
eingeleitet und die nächste Zeile ist dann kein Kommentar mehr. Genauso 
macht es der Cypress-Compiler. Wo also der Fehler?


> Auch dann wäre das Cypress aber kaputt, denn backslash-newline muss
> mit dem native line ending des Betriebssystems zurecht kommen, auf
> dem es läuft.
>
> Solche Fehler dürften legitim höchstens dann passieren, wenn man auf
> einem shared filesystem arbeitet und bspw. unter Unix editiert, aber
> dann unter Windows compiliert.

Wie auch immer, zumindest weiß ich nun worauf ich achten muß. Besser man 
kennt die Fehler/Features. Anhand des automatischen Syntax-Highlighting 
fällt es sowieso sofort auf.

Noch kaputter als Windoof finde ich übrigens C. Praktisch keinerlei 
Absicherung gegen Fehlbenutzung in der Syntax/Semantik.


Moment: Ist 'backslash-newline' teil der C-Syntax? Also bewahrheitet es 
sich wieder: C sollte nur auf Unix laufen. Portieren ist immer Mist.


Gruß -
Abdul

[Mark B. (markbrandis)]

C ist halt ein mit Syntax verzuckerter Assembler ;-)

[Abdul K. (ehydra)]

Lothar Miller schrieb:

>

>   if ((PIND & (1<<PIND5)) && (PIND & (1<<PIND6)))  //Wenn PinD4=1 und
> PinD5=1 (Beide Endschalter frei)
>

> Siehst du den Fehler?
>
> Das hätte gereicht und es wäre in sich konsistent:
>

>   if ((PIND & (1<<PIND5)) && (PIND & (1<<PIND6)))  // Beide Endschalter
> frei?
>

>

Wo ist bei den beiden Zeilen der Unterschied? Für mich sehen die exakt 
binär gleich aus!!!


Gruß -
Abdul

[Jörg W. (dl8dtl) (Moderator)]

Abdul K. schrieb:

> Und wieso meckert ihr? Ein einzeiliger Kommentar wird in C mit '//'
> eingeleitet und die nächste Zeile ist dann kein Kommentar mehr. Genauso
> macht es der Cypress-Compiler. Wo also der Fehler?

Der Fehler ist, dass ein Backslash direkt am Zeilenende (also ohne
ein Leerzeichen davor) die logische Zeile auf der nächsten
physischen Zeile fortsezt.  Diese Verkettung erfolgt vor der
Bewertung eines Kommentars.  Wenn der Cypress das also nicht macht,
ist er kein C-Compiler.

Das Feature dürfte insbesondere aus der Zeit stammen, da Editoren
nur begrenzte Zeilenlängen verarbeiten konnten.  Seine einzige
heutige Relevanz ist es noch, dass man damit eine Makro-Definition
(die per definitionem auf einer einzigen logischen Zeile stehen
muss) über mehrere physische Zeilen aufteilen kann.

> Noch kaputter als Windoof finde ich übrigens C. Praktisch keinerlei
> Absicherung gegen Fehlbenutzung in der Syntax/Semantik.

Dafür gibt es halt Warnungen.

> Moment: Ist 'backslash-newline' teil der C-Syntax?

Ja.

> Also bewahrheitet es
> sich wieder: C sollte nur auf Unix laufen.

Nein.  Das "newline" dabei bezieht sich nicht auf ein einzelnes
Zeichen 0x0a, sondern auf was auch immer das Hostsystem als
Zeilenendekennung benutzt.  Auf einem Unix wäre die entsprechende
Sequenz also 0x1b 0x0a, auf Windows 0x1b 0x0d 0x0a, auf MacOS
0x1b 0x0c.

Daher muss das also auch auf einem Windows-Compiler funktionieren,
sofern die Datei von einem Windows-Texteditor erstellt worden ist.

[Stefan E. (sternst)]

Abdul K. schrieb:

> Wo ist bei den beiden Zeilen der Unterschied? Für mich sehen die exakt
> binär gleich aus!!!

Lothar bezog sich einzig und allein auf den Kommentar.
Das geht doch klar und deutlich aus seinem Post hervor.

[Abdul K. (ehydra)]

Mark Brandis schrieb:
> C ist halt ein mit Syntax verzuckerter Assembler ;-)

Ja, so war es mal gedacht. Aber irgendwie hat man nach PASCAL nichts 
besseres mehr gefunden. Wohl der KGV ;-)


Gruß -
Abdul

[Abdul K. (ehydra)]

Stefan Ernst schrieb:
> Abdul K. schrieb:
>
>> Wo ist bei den beiden Zeilen der Unterschied? Für mich sehen die exakt
>> binär gleich aus!!!
>
> Lothar bezog sich einzig und allein auf den Kommentar, das geht doch
> klar und deutlich aus seinem Post hervor.

Das hatte ich nicht registriert. OK.


Gruß -
Abdul

[Abdul K. (ehydra)]

Jörg Wunsch schrieb:
> Abdul K. schrieb:
>
>> Und wieso meckert ihr? Ein einzeiliger Kommentar wird in C mit '//'
>> eingeleitet und die nächste Zeile ist dann kein Kommentar mehr. Genauso
>> macht es der Cypress-Compiler. Wo also der Fehler?
>
> Der Fehler ist, dass ein Backslash direkt am Zeilenende (also ohne
> ein Leerzeichen davor) die logische Zeile auf der nächsten
> physischen Zeile fortsezt.  Diese Verkettung erfolgt vor der
> Bewertung eines Kommentars.  Wenn der Cypress das also nicht macht,
> ist er kein C-Compiler.

Aha. Mal wieder was gelernt. Ich muß halt mit dem Leben, was mir andere 
vorgeben. Da gibt es schlimmeres.


>
> Das Feature dürfte insbesondere aus der Zeit stammen, da Editoren
> nur begrenzte Zeilenlängen verarbeiten konnten.  Seine einzige
> heutige Relevanz ist es noch, dass man damit eine Makro-Definition
> (die per definitionem auf einer einzigen logischen Zeile stehen
> muss) über mehrere physische Zeilen aufteilen kann.
>

Oh, Experte.


>> Noch kaputter als Windoof finde ich übrigens C. Praktisch keinerlei
>> Absicherung gegen Fehlbenutzung in der Syntax/Semantik.
>
> Dafür gibt es halt Warnungen.
>

Das ist in keiner Weise das gleiche! Aber lassen wir das hier einfach so 
stehen, damit die Diskussion nicht beginnt.


>> Moment: Ist 'backslash-newline' teil der C-Syntax?
>
> Ja.

Hm. Nie benutzt. Glück gehabt.


>
>> Also bewahrheitet es
>> sich wieder: C sollte nur auf Unix laufen.
>
> Nein.  Das "newline" dabei bezieht sich nicht auf ein einzelnes
> Zeichen 0x0a, sondern auf was auch immer das Hostsystem als
> Zeilenendekennung benutzt.  Auf einem Unix wäre die entsprechende
> Sequenz also 0x1b 0x0a, auf Windows 0x1b 0x0d 0x0a, auf MacOS
> 0x1b 0x0c.
>
> Daher muss das also auch auf einem Windows-Compiler funktionieren,
> sofern die Datei von einem Windows-Texteditor erstellt worden ist.

Du verlangst viel. Was nun, wenn das Programm nur aus einer einzigen 
Zeile besteht. MUSS die in C mit einem 'return' abgeschlossen sein oder 
darf die 'offen' bleiben? Du weißt, worauf ich hinaus will...


Und im Übrigen: Das Verhalten kann ich eh nicht ändern!



Gruß -
Abdul

[Johann L. (gjlayde)]

Lothar Miller schrieb:

> Diese Kommentare sind redundant, verwirrend und (vor allem) *FALSCH*
> :-o
>

>   if ((PIND & (1<<PIND5)) && (PIND & (1<<PIND6)))  //Wenn PinD4=1 und
> PinD5=1 (Beide Endschalter frei)
>

> Siehst du den Fehler?
>
> Das hätte gereicht und es wäre in sich konsistent:
>

>   if ((PIND & (1<<PIND5)) && (PIND & (1<<PIND6)))  // Beide Endschalter
> frei?
>

>
> Fazit:
> Kommentare, die das Offensichtliche kommentieren, sind überflüssig.

Nun ja, dein Kommantar "Beide Endschalter frei?" ist auch falsch. Denn 
in den if-Block kommt man durchaus auch dann, wenn nur ein Schalter 
"frei" ist.

Diese fiese Race-Condition mag hier irrelevant sein, aber manch andere 
Anwending hin und wieder unerwartet reagieren lassen...

Code, der zum Kommentar passt, ist zB so aus:

if ( ((1<<PIND5) | (1<<PIND6)) == (((1<<PIND5) | (1<<PIND6)) & PIND))

Johann

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

>>> Wo ist bei den beiden Zeilen der Unterschied? Für mich sehen die exakt
>>> binär gleich aus!!!
>> Lothar bezog sich einzig und allein auf den Kommentar, das geht doch
>> klar und deutlich aus seinem Post hervor.
> Das hatte ich nicht registriert. OK.

ROTFL :-D
Da sieht man, wie trotz deutlichem Hinweis Kommentare gelesen werden...

Nochmal das
>>>> Fazit:
>>>> Kommentare, die das Offensichtliche kommentieren, sind überflüssig.

EDIT:
> Diese fiese Race-Condition mag hier irrelevant sein, aber manch andere
> Anwending hin und wieder unerwartet reagieren lassen...
Und ich sach noch: Junge, lies alle Eingänge gleichzeitig und arbeite 
mit dem eingelesen Prozessabbild. Nicht umsonst machen SPSen das so...
- Eingänge einlesen
- mit den eingelesenen Abbild arbeiten
- Ausgänge schreiben
- und wieder von vorn.

Aber das gehört eigentlich nicht hierher ;-)

[Karl H. (kbuchegg)]

Abdul K. schrieb:

> Du verlangst viel. Was nun, wenn das Programm nur aus einer einzigen
> Zeile besteht. MUSS die in C mit einem 'return' abgeschlossen sein oder
> darf die 'offen' bleiben? Du weißt, worauf ich hinaus will...

He, he
Nein, sie darf laut Norm nicht 'offen' bleiben.
Das letzte Zeichen eines Source Codes muss offiziell ein Return sein.

Aber es gibt praktisch keinen Compiler, der sich daran stört, wenn dem 
nicht so ist.


mal was anderes, was auch viele nicht wissen:

Wenn mehrere Strings aufeinanderfolgen, dann müssen sie vom Compiler 
automatisch zu einem einzigen zusammengesetzt werden.
Ob du also "Hallo world" oder "Hallo" " world" oder
"Hallo "
"world"
oder ...
schreibst, kommt alles aufs gleiche hinaus :-)

Das ist zb in solchen Fällen praktisch

const char* ErrMsg = "Error:   %d\n"
                     "File:    '%s'\n"
                     "Line:    %d\n"
                     "Message: %s";

wenn man also in einen printf-Formatstring eine "Rudimentärformatierung" 
mittels Returns einbaut, die Ausgabe selber auf mehre Zeilen verteilen 
möchte und trotzdem nicht lange Leerzeichen zählen will.

Oder zb hier

#define ESC "\x1B"

int main()
{
  printf( "Dies ist ein Escape: " ESC ". geht doch!" );
}

man also in einem Text irgendwelche Sonderzeichen einbetten möchte, für 
die man auf Hex-Codes zurückgreifen muss.

[Abdul K. (ehydra)]

@Lothar:
Nein, deine Bemerkung ist überaus wichtig! Genauso die Sache mit Treiben 
von Transis und immer eine Null an genau diesem Pin "komischerweise" 
lesend, oder oder. Schert sich C einen Dreck drum.
Na die wegoptimierte Timing-Loop kennen wohl die meisten (??). Klar, C 
läuft ja wie auch die meisten anderen Programmiersprachen auf einer 
abstrakten Maschine, die keine Zeit brauch, nur sequentiell ist.


@Karl heinz Buchegger:
zu 2.: Das wußte ich, habe es aber bislang nie benutzt. Ich neige zum 
Zuviellesen von Anleitungen ;-)


Gruß -
Abdul

[Karl H. (kbuchegg)]

Abdul K. schrieb:
> Schert sich C einen Dreck drum.

Natürlich.
Der Compiler prüft die Syntax, ob dein Programm den grammatikalischen 
Regeln gehorcht. Die Logik ist dein Bier.

Aber dazu muss man halt zumindest mal die Regeln kennen.

 "Das Segelschiff liest den Mond"

ist im Deutschen ein grammatikalisch richtiger Satz. Kein 
'Deutsch-Compiler' dieser Welt hätte irgendetwas daran auszusetzen. Er 
genügt den grammatikalischen Regeln, so wie sie festgelegt sind.
Und trotzdem ist er Unsinn.

Ein Compiler macht nur den ersten Teil (Grammatiktest).

[Abdul K. (ehydra)]

Das ist klar. Der Weg in die Zukunft des Programmierens solllte 
vielleicht mal überdacht werden. Interessante Ansätze wie FORTH 
(Verschmelzung respektive Nie-Trennung von Interpreter und Compiler) 
sind leider verschwunden. Es fällt auf, das sich meiner Ansicht auf 
diesem Gebiet nichts mehr tut.

Man ist heutzutage praktisch fest gebunden an C (wegen HAL-Libraries), 
Microsoft und ähnliche Standards.


Sehr erfreut war ich letztens, als ich entdeckte, das man bei Windoof 
problemlos einen Editor öffnen und in diesem über den Öffnen-Dialog eine 
URL als zu lesende Datei angeben kann.


Aber ok, das hat mit dem Thema nix mehr zu tun.


Gruß -
Abdul

[Karl H. (kbuchegg)]

Abdul K. schrieb:

> Interessante Ansätze wie FORTH
> (Verschmelzung respektive Nie-Trennung von Interpreter und Compiler)
> sind leider verschwunden.

Na ja.
Forth ist gewöhnungsbedürftig. Und so toll dann auch wieder nicht.

> Man ist heutzutage praktisch fest gebunden an C (wegen HAL-Libraries),
> Microsoft und ähnliche Standards.

Mainstream vielleicht.
Aber in der Forschung stimmt das doch nicht.
Alles was in Richtung AI geht, arbeitet mit Sprachen, die auf ganz 
anderen Prinzipien beruhen. Sieh dir LISP an. Ein LISP Programm kann 
seinen eigenen Code erzeugen und ausführen lassen. Sieh dir Prolog an. 
Sieh dir Smalltalk an, ...

[Abdul K. (ehydra)]

Karl heinz Buchegger schrieb:
> Abdul K. schrieb:
>
>> Interessante Ansätze wie FORTH
>> (Verschmelzung respektive Nie-Trennung von Interpreter und Compiler)
>> sind leider verschwunden.
>
> Na ja.
> Forth ist gewöhnungsbedürftig. Und so toll dann auch wieder nicht.

Aber ein interessanter Ansatz den es in die Zukunft zu verschmelzen 
gilt.


>
>> Man ist heutzutage praktisch fest gebunden an C (wegen HAL-Libraries),
>> Microsoft und ähnliche Standards.
>
> Mainstream vielleicht.
> Aber in der Forschung stimmt das doch nicht.
> Alles was in Richtung AI geht, arbeitet mit Sprachen, die auf ganz
> anderen Prinzipien beruhen. Sieh dir LISP an. Ein LISP Programm kann
> seinen eigenen Code erzeugen und ausführen lassen. Sieh dir Prolog an.
> Sieh dir Smalltalk an, ...

Von diesen ganzen Uniprojekten schafft es so gut wie nie eines in die 
Praxis oder bleibt in einer Nische. Fast so schlechter Wirkungsgrad wie 
die praktische Abschlußarbeit in der Lehre :-)

Bestimmt kein Zufall, das alle aufgeführten Sprachen grob ungefähr 
gleich alt sind!


Naja -
Abdul

[Karl H. (kbuchegg)]

Abdul K. schrieb:
>> Na ja.
>> Forth ist gewöhnungsbedürftig. Und so toll dann auch wieder nicht.
>
> Aber ein interessanter Ansatz den es in die Zukunft zu verschmelzen
> gilt.

Was findest du an Forth so interessant?

Das für mich geile an Forth ist der relative kleine Kern, der in 
Assembler geschrieben sein muss. Alles andere baut dann darauf auf.

Aber abgesehen davon finde ich Forth nicht besonders interessant.

[Jörg W. (dl8dtl) (Moderator)]

Karl heinz Buchegger schrieb:

(Newline am Ende der Datei)

> Nein, sie darf laut Norm nicht 'offen' bleiben.
> Das letzte Zeichen eines Source Codes muss offiziell ein Return sein.

Wobei das einzig und allein damit zu tun hat, dass das preprocessing
in C zeilenweise definiert ist, d. h. alle Direktiven für den
Präprozessor (#define, #if, #ifdef usw.) nehmen immer eine ganze
Zeile ein.  Daher muss das Programm aus Zeilen aufgebaut sein, und
da eine Zeile mit einem Zeilenendezeichen endet, muss folglich rein
syntaktisch ein solches das letzte Zeichen einer (nicht leeren)
Quelldatei sein.

> Aber es gibt praktisch keinen Compiler, der sich daran stört, wenn dem
> nicht so ist.

GCC wirft zumindest eine Warnung dafür raus.  Ich vermute aber, dass
ein Compiler, dessen Präprozessor die dann nicht beendete Zeile einfach
nicht mehr verarbeitet (und daher auch nicht an den Compiler weiter
gibt) immer noch standardkonform wäre.  (Das mit Zitaten aus dem
Standard zu belegen, habe ich gerade keine Lust. ;-)

[Abdul K. (ehydra)]

Jörg Wunsch schrieb:
> Karl heinz Buchegger schrieb:
>
> (Newline am Ende der Datei)
>
>> Nein, sie darf laut Norm nicht 'offen' bleiben.
>> Das letzte Zeichen eines Source Codes muss offiziell ein Return sein.
>
> Wobei das einzig und allein damit zu tun hat, dass das preprocessing
> in C zeilenweise definiert ist, d. h. alle Direktiven für den
> Präprozessor (#define, #if, #ifdef usw.) nehmen immer eine ganze
> Zeile ein.  Daher muss das Programm aus Zeilen aufgebaut sein, und
> da eine Zeile mit einem Zeilenendezeichen endet, muss folglich rein
> syntaktisch ein solches das letzte Zeichen einer (nicht leeren)
> Quelldatei sein.

Wenn es implizit immer vorhanden ist, kann man es natürlich auch wieder 
weglassen ;-)


Gruß -
Abdul