www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Struct gut so?


Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

Anfänger mit Atmega8 am Heulen:

PortB.0 soll TASTER, PortC.0 ne LED darstellen und auch so heissen. 
(Aufs Minimum reduziert)
Aus zahlreichen Treats habe ich folgendes zusammengestellt:

struct bits
{
  uint8_t b0:1;
  uint8_t b1:1;
  uint8_t b2:1;
  uint8_t b3:1;
  uint8_t b4:1;
  uint8_t b5:1;
  uint8_t b6:1;
  uint8_t b7:1;
};

#define BIT(r,n) (((volatile struct bits *)&r)->b##n)
#define TASTER BIT(PORTB, 0)
#define LED BIT(PORTC, 0)

DDRB = 0b00000000;     // PORTB als Eingang
DDRC = 0b11111111;     // PortB als Ausgang
PORTB = 0b11111111;           // PortB auf high schalten
PORTC = 0b00000000;           // PortB auf low schalten

int main(void)
{
        while (TASTER1)
  {
  LED = on;
  }
return 0;
}

Es funzt aber nicht. Wo könnte der Fehler liegen?

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rofl. Dabei war der 1. April doch erst ;)
Spaß beiseite -- Welche Sprache soll das sein? C?
Schon ins AVR-GCC-Tutorial geschaut?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>#define TASTER BIT(PORTB, 0)

#define TASTER BIT(PINB, 0)

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Japp, das soll 1A ANSI-C sein. Oder mal werden.
Im Moment ist Hauptsache, dass es funktioniert. Wenn es denn mal 
funktioniert.

@Holger: Danke für den PIN- Tipp!!

Prost!

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage nach dem AVR-GCC-Tutorial bleibt offen...
Da wird das mit den Ports/Pins wie folgt gelöst:
int main(void) {
DDRB = 0x00    //Alle Eingänge (tut eigentlich nicht nötig!!)
DDRC = (1<<PC7)|(1<<PC6)|(1<<PC5)|(1<<PC4)|(1<<PC3)|(1<<PC2)|(1<<PC1)|(1<<PC0);

return 0;
}

^das schafft (mit ein paar Leerzeichen) viel Übersichtlichkeit, das 
solltest du dir angewöhnen!

oder so:
#define sbi(PORT, BIT) PORT=(1<<BIT)

int main(void) {
sbi(DDRC,PB1);
sbi(PORTC,PB1);

return 0;
}

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>oder so:
>
>#define sbi(PORT, BIT) PORT=(1<<BIT)

Fein, gleich mal den kompletten Port plattmachen;)

So geht das:

#define sbi(PORT, BIT) PORT |= (1<<BIT)

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Fein, gleich mal den kompletten Port plattmachen;)

Alta, es ist schon spät ;-D

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Scheiss Jägermeister. Hirn ist schon bissel träge..

Wo/wie benenne ich denn da ein PIN mit TASTER?

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt kannst du aber auch mal ins AVR-GCC-Tutorial gucken. Oder müssen 
wir dir vorbeten, was Tausende vor dir schon fragten?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wo/wie benenne ich denn da ein PIN mit TASTER?

#define TASTER (PINB &  1 << PB0)

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab´s ja quasi mit Hilfe des structs schon hinbekommen. Bei LED= on 
ging´s Lämpchen an...

Nur jetzt, wo ich mit Ein- UND Ausgängen arbeiten möchte, treten 
Probleme auf.
Werd mir wohl morgen wirklich mal das Tutorial eingehend vornehmen 
müssen...

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger, was heisst

sbi(DDRC,PB1);  ??

Setze Bit PortB1 im DDRC?

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jägermeister alle :(

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Holger, was heisst
>
>sbi(DDRC,PB1);  ??
>
>Setze Bit PortB1 im DDRC?


Nö, setze in DDRC das Bit das mit der Konstanten
PB1 definiert ist.

Aufgelöst:

DDRC |= 1<<1;

oder

DDRC |= 2;

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was habt ihr alten Hasen nur dagegen, einem Bit einen Namen zu geben und 
ihm zu sagen "Du, Bit, bist jetzt ne 1!" ?!

Ich pick es nicht :(

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alter Hase? Ich bin 16!
Das hat Performance Gründe. Zudem ist es in ANSI-C (ich bin nicht 
sicher) nicht vorgeschrieben, dass das Struct auch nur den einen Bit 
verwendet. Für 8 Bit verpulverst du mal eben 8 Byte... Das ist aufm AVR 
ne Hausnummer.
Aber wie gesagt: ich bin nicht sicher!

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für 8 Bit verpulvert Mann 8 Byte? (?)
Ich dachte, man kreiert extra einen 1-Bit-Datentyp, um Platz zu sparen!

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was habt ihr alten Hasen nur dagegen, einem Bit einen Namen zu geben und
>ihm zu sagen "Du, Bit, bist jetzt ne 1!" ?!

Nichts, viele Wege führen nach Rom.

#define LED_ON   sbi(PORTC, 0)
#define LED_OFF  cbi(PORTC, 0)

Da kannste auch ganz schnell wechseln wenn die LED an Plus hängt;)

#define LED_ON   cbi(PORTC, 0)
#define LED_OFF  sbi(PORTC, 0)

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Lichtblick!!
Ja warum sagst Du das denn nicht gleich?

Aber zum Abschluss noch mal ne richtig doofe Frage. Achtung, festhalten!
Sie lautet:
Muss ich LED_ON wie eine Funktion aufrufen?

(Ich verstand #define bisher nur in der Art "#define PI 3.14159")

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
int main(void)
{
  while (TASTER1)
  {
    LED = on;
  }
  return 0;
}

1) 'TASTER1' gibts nicht, wenn Dein Compiler Dir das nicht um die Ohren 
haut, schmeiß ihn weg

2) Preisfrage: Was macht Dein Programm wohl, wenn der Taster nicht 
gedrückt ist?

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jein. Bei einer Funktion siehts so aus:
function();

Bei #define kann es auch so aussehen:
#define LED_ON   sbi(PORTC, 0)

LED_ON;


oder mit anderen Worten: Bei einer Funktion folgt dem Bezeichner IMMER 
ein Klammer!!

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1) Warum gibts TASTER1 nicht?? (Ich hab sogar zwei!) Wenn er doch 
definiert ist?!

2) Denke, dein Miniprogramm berücksichtigt keine Nichtgedrückt..

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Silvan König schrieb:
> 2) Preisfrage: Was macht Dein Programm wohl, wenn der Taster nicht
> gedrückt ist?

lol.

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Silvan König schrieb:
> 1) Warum gibts TASTER1 nicht?? (Ich hab sogar zwei!) Wenn er doch
> definiert ist?!

Du hast TASTER definiert, aber nicht TASTER1.
Der Compiler ist pingelich!

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> 1) Warum gibts TASTER1 nicht?? (Ich hab sogar zwei!) Wenn er doch
> definiert ist?!

Wo ist er denn definiert? In Deinem ersten Post jedenfalls nicht! Und 
auch in keinem anderen.

Stephan R. schrieb:
> 2) Denke, dein Miniprogramm berücksichtigt keine Nichtgedrückt..

Das ist DEIN Programm nicht meins! Kennst Du Deine eigenen Posts nicht?

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich dreh gleich durch!
Was passt Mr. Compiler an

main (void)
{
  DDRC=  0xff;
  PORTC= 0xff;
  sbi (PORTC,0);
return 0;
}


nicht?? (undefined reference to sbi)

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Woher soll der Compiler wissen was 'sbi' ist? Hast Du ihm schließlich 
nicht gesagt.

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab ihm auch nicht gesagt was return ist!

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, wenn man es ganz genau nimmt ists dem Compiler eigentlich egal, der 
sollte nur eine Warnung ausspucken. Die Fehlermeldung stammt vom Linker, 
der nicht weis wo er die Implementation der Funktion sbi finden soll.

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab das sbi- Problem gelöst, hängt wohl mit dem Alter (/Neuer) meines 
Compilers zu tun.

Folgendes gefällt mir sehr gut und läuft auch:
#define led_on sbi(PORTC,1)


Nun möchte ich noch in der Art auch einen Eingang anfragen können.
#define led (PORTC,1)
funzt leider nicht. Was möchte Mr. Compiler da hören?

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest vielleicht erst mal ein gutes C-Buch lesen!
'return' ist ein im C-Sprachstandard definiertes Schlüsselwort, 'sbi' 
nicht!

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
syntax error:

meinte #define taster (PINC, 0)

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An der Zeile ist erstmal nichts verkehrt. Ist absolut korrekter C-Code.

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das finde ich -soweit beurteilbar- auch.
Hier mein gesamtes Programm:

#include <avr/io.h>
#include <util/delay.h>
#include <stdio.h>


#define led (PORTC, 1)
#define taster (PINC, 0)

void main (void)
{
  DDRC =  0b00000010;
  PORTC = 0x00000010;

  if (taster == 1)
  led = 1;
}

aber:   lvalue required as left operand of assignment

Ist er müde?

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1) Du solltest lernen hier im Forum Code-Tags zu verwenden
2) Du solltest Dir angewöhnen Deinen Sourcecode korrekt einzurücken

Spiel doch einfach mal selbst Präprozessor.
Du hast da ein "#define taster (PINC, 0)" stehen, also ersetzt Du in 
Deinem restlichen Code überall das Wort "taster" durch die Zeichenkette 
"(PINC, 0)" (ohne die Anführungsstriche). Und dann siehst Du auch was da 
rauskommt und was der Compiler dann nicht versteht.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch vergessen:

3) Hier im Forum: NIEMALS Sourcecode abtippen! IMMER Copy&Paste 
benutzen!

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> if (taster == 1)

An der Stelle setzt der Compiler (eigentlich der Präprozessor, aber wir 
wollns nicht übertreiben)
(PINC,0) ein.

Sieht also so aus:
if ( (PINC,0) == 1)

Das geht nicht!

Guck ins AVR-GCC-Tutorial!!!!
if ( bit_is_set(PORTC,0) )
{
  //tue dies und das
}

PS: ich müsste nachlesen, wie bit_is_set definiert ist. So wird der 
Compiler es aber nicht nehmen!!

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier, ein Paste (nicht abgetippt):

void main (void)
{
  DDRC =  0b11111110;
  PORTC = 0b00000000;

  if ((PINC, 0) == 0)
         sbi (PORTC, 1);

  if ((PINC, 0) == 1)
         cbi (PORTC,1);
}


Einziges Prob: Es läuft nix. LED ist an. Immer.

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit bit_is_set läufts!! (Ein bissel erstmal)
Hab Dank!

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wen´s interesiert, hier meine Lösung.

void main (void)
{
  DDRC =  0b11111110;
  PORTC = 0b00000001;

  while (1)
  {
  if (bit_is_set(PINC, 0))
  cbi (PORTC, 1);

  if (bit_is_clear(PINC,0))
  sbi (PORTC,1);
  }

}

Gute Nacht!

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> Einziges Prob: Es läuft nix. LED ist an. Immer.

Genau das, was Du progrmmiert hast.
OK wenn man ganz pingellig ist hängt das auch noch von der 
Compilerversion ab, entweder die LED ist tatsächlich immer an oder der 
µC wird ständig resettet und die LED flimmert (unsichtbar, da zu schnell 
fürs Auge).
((PINC, 0) == 0)
Dieser Ausdruck ist immer wahr!
((PINC, 0) == 1)
Dieser Ausdruck ist immer falsch!

Nachdem der Optimizer Dein Programm in der Fingenr hatte, bleibt davon 
nur noch folgendes übrig:
void main (void)
{
  DDRC =  0b11111110;
  PORTC = 0b00000000;
  sbi (PORTC, 1);
}
Und jetzt sollte Dir auch klar werden, warum Deine LED immer leuchtet.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Huch, da war ich wohl zu langsam.
Das letzte sieht schon besser aus (bis auf die fehlenden Code-Tags hier 
fürs Forum und die mißratenen Einrückungen).

Das mit bit_is_set/bit_is_clear ist aber etwas doppelt gemoppelt. Wenn 
ein Bit gesetzt ist, ist es auf keinen Fall 'clear' und umgekehrt.
Anders gesagt, eins der beiden 'if's kann man sich sparen:
#include <avr/io.h>
#include <compat/deprecated.h>

void main (void)
{
  DDRC =  0b11111110;
  PORTC = 0b00000001;

  while (1)
  {
    if (bit_is_set(PINC, 0))
    {
      cbi (PORTC, 1);
    }
    else
    {
      sbi (PORTC,1);
    }
  }
}

Autor: mal ne Frage (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich hätte da mal 'ne Frage zu:
>#define led_on sbi(PORTC,1)

spricht eigentlich was gegen leere Klammern? So wie das da:
#define LED_AN() sbi(PORTC, 1)

so mach ich das nämlich immer, dann kann ich die defines wie Funktionen 
aufrufen:

if (TASTET_IST_GEDRUECKT())
  LED_AN();
else
  LED_AUS();




...ok meist übertreibe ich etwas, dann sieht's etwa so aus:

#define PORT_LED_AUS PORTC
#define PORT_LED_EIN PINC
#define PORT_LED_OE  DDRC

#define BIT_LED_ROT   0
#define BIT_LED_GELB  1
#define BIT_LED_GRUEN 2


#define LED_AN()  SET_BIT(PORT_LED_AUS, BIT_LED_ROT)

Autor: mal ne Frage (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh Mist, 10-mal durchgelesen und doch noch Fehler:


TASTET_IST_GEDRUECKT() ist gedrückt sollte TASTER_IST_GEDRUECKT() 
heissen

SET_BIT(...) ist natürlich auch eine Definition:
#define SETBIT(XREG,XBIT)  XREG |= (1<<XBIT)


sorry

Autor: mal ne Frage (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nee nee,

jetzt korrigiere ich nichts mehr!!!

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich persönlich finde es übertrieben, aber ich habe gesehen, dass das in 
libs z.B. für das LCD des Nokia3310 genauso gemacht wird.

Daher würd ich sagen, es ist nicht übertrieben, sondern eine 
Notwendigkeit. Damit kannst du deine LEDs schneller neu sortieren.

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"spricht eigentlich was gegen leere Klammern? So wie das da:
#define LED_AN() sbi(PORTC, 1)"

Mault den der Compiler rum? Nein? Dann wirds wohl gehen.

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Zudem ist es in ANSI-C (ich bin nicht
sicher) nicht vorgeschrieben, dass das Struct auch nur den einen Bit
verwendet. Für 8 Bit verpulverst du mal eben 8 Byte... Das ist aufm AVR
ne Hausnummer."

Gibt ja noch __attribute__((packed)). Ist zwar kein ANSI-C, aber der 
AVR-GCC-Compiler machts trotzdem.

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Das hat Performance Gründe."

Wenn du mal in die Situation kommst, das du ein 60 seitiges Programm 
(ausgedruckt) von nem 8051 auf einen AVR übertragen musst, wird dir 
dieser Grund sicherlich recht schnell egal sein. Durch die Struktur sind 
dann 8051 übliche sbit Konstrukte wie:

 if(UEBERNAHME_PC_MC){ ... }

 TAKT_MC_PC=1;
 ...
 TAKT_MC_PC=0;

etc.

Möglich, ohne das du alle entsprechenden Stellen mit Makros wie 
TAKT_MC_PC_ON bzw TAKT_MC_PC_OFF ändern musst. Das macht nämlich nach 10 
Seiten keinen Spass mehr. Performance hin oder her.

Ansonsten stimme ich dir zu. Bei Programmen, die direkt für den AVR 
entwickelt werden sind Makros mit cbi() und sbi() definitiv die bessere 
Wahl.

Autor: Thisamplifierisloud (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne nahetreten zu wollen, empfehle ich Dir,
mal die Grundlagen in C draufzuschaffen,
statt punktuell Problemchen rauszupicken,
die dann irgendwie mit Hilfe eines Forums gelöst werden.

Gruß

TAIL

Autor: Thisamplifierisloud (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bla schrieb:
> "spricht eigentlich was gegen leere Klammern? So wie das da:
> #define LED_AN() sbi(PORTC, 1)"
>
> Mault den der Compiler rum? Nein? Dann wirds wohl gehen.


Warum probierst Du´s nicht einfach aus ?
Geht schneller als auf ne Antwort zu warten.

:-)

Autor: dagger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bla schrieb:
>> Zudem ist es in ANSI-C (ich bin nicht
>> sicher) nicht vorgeschrieben, dass das Struct auch nur den einen Bit
>> verwendet. Für 8 Bit verpulverst du mal eben 8 Byte... Das ist aufm AVR
>> ne Hausnummer.
> Gibt ja noch __attribute__((packed)). Ist zwar kein ANSI-C, aber der
> AVR-GCC-Compiler machts trotzdem.
Das ist auch eine der vielen Gimmicks die der GCC mit sich bringt.
Manche Compiler kennen #pragma pack(n) siehe auch [1].

Wenn ich mich nicht irre, ignorieren Compiler unbekannte pragmas und ich 
weiß nicht, wie verbindlich _attribute_ und pragmas sind. Vielleicht 
sind das nur Empfehlungen für den Compiler und er kann sie, ähnlich wie 
inline bei Funktionen, ignorieren??

[1] 
http://www.hs-augsburg.de/~sandman/c_von_a_bis_z/c...

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dagger:

Ehrlich gesagt: Keine Ahnung. Ich habe zwar Vorlesungen wie 
Programmieren 1, Programmieren 2, und Microprozessortechnik gehört, aber 
auf µC spezifische Programmierung in C sind diese Vorlesungen leider 
nicht eingegangen. In Micorprozessortechnik haben wir 8051 in Assembler 
geproggt. Viel gebracht hat mir das nicht, weil ich voher schon mit dem 
8085 umgehen konnte.
Ich habe mich zusammen mit einem Mitschüler in den letzten 
Wochen/Monaten (Er: ca. 3 Monate. Ich: ca. 6 Wochen) eigenständig in das 
Thema eingearbeitet, da wir es beide für notwendig erachteten. Hier 
nochmal ein dickes Lob an die Autoren dieser Seite für ihre hilfreichen 
Tutorials!

Ich werde mich aber noch tiefer reinarbeiten. C von A bis Z steht hier 
im Regal nebem Kerningham/Ritchie. Danke für den Hinweis.

Autor: Juergen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte keine C Bitfields benutzen, das macht auf die Dauer nur Probleme:

- Genaues Layout ist implementierungsabhängig, erschwert Portierung auf 
anderen Compiler / Prozessor

- Ein Sprachfeature mehr, dessen Feinheiten man sich merken muss und mit 
dem Neulinge Probleme bekommen

- Indizierter Zugriff ist nicht möglich (kein Array von 5 bits in einem 
Byte)

Benutzt Shift und Bitoperationen, da wisst ihr genau, was passiert.

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Juergen:

Stichhaltige Argumente, die auch richtig sind. Aber ich sehe das ganze 
so:

Man sollte schon wissen was Bitfelder sind, welche Vor- und Nachteile 
sie besitzen und wie man mit ihnen umgeht. Ihren Einsatz sollte man aber 
ähnlich sorgfältig durchdenken wie den Einsatz von goto oder globalen 
Variablen, denn manchmal können sie durchaus elegante und effektive 
Lösungen für Probleme sein.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.