Forum: Mikrocontroller und Digitale Elektronik ISR-Handler: Probleme bei Wertzuweisung von volatile Variable


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Chris L. (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe nach langer Zeit beschlossen, mein eingerostetes Wissen über 
uC-Programmierung aufzufrischen (für kleinere private Projekte).
Grundlegendes C und Assemblerwissen vorhanden.

Gestern bin ich auf ein Problem gestoßen, welches ich weder verstehen 
noch lösen konnte: Ich habe einen Timer konfiguriert, damit er alle 
100ms einen Interrupt auslöst. Im Interrupt sollen nur Flags gesetzt 
werden, auf die in der main-Loop reagiert werden soll.

Hier mal den Code auf das Nötigste eingedampft:

Code:
#include <avr/io.h>
#include <stdlib.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include <stdint.h>
#include <avr/cpufunc.h>

volatile uint8_t flag = 0;

ISR(TIMER1_COMPA_vect) {
    // debug: toggle LED at PA3
    PORTA ^= (1 << PA3);

    flag |= 0xFF;
}

int
main(void)
{
    // set up PA0/1/2/3 as outputs
    DDRA |= (1 << PA3) | (1 << PA2) | (1 << PA1) | (1 << PA0);

    // set prescaler to 256 -> Timer runs with 16000000/256 = 62500 Hz
    TCCR1B |= (1 << CS12) | (0 << CS11) | (0 << CS10);

    // enable CTC mode 4 on Timer1
    TCCR1B |= (0 << WGM13) | (1 << WGM12);
    TCCR1A |= (0 << WGM11) | (0 << WGM10);

    // set timer resolution to 6250 - 1 = 6249 to fire interrupt every 100ms
    OCR1A = 6249;

    // enable TIMER1_COMPA interrupt mask
    TIMSK |= (1 << OCIE1A);

    // enable global interrupts
    sei();

    // debug: turn on LED at PA0
    PORTA |= (1 << PA0);

    while(1)
    {

        // debug: turn on LED at PA1
        PORTA |= (1 << PA1);
        
        // flag should be set in ISR
        if(flag)
        {
            //reset flag
            flag = 0;

            // debug: toggle LED at PA2
            PORTA ^= (1 << PA2);
        }
    }

    return EXIT_SUCCESS;
}

Meine Erwartung ist, dass die LEDs an PA0 und PA1 aufleuchten und die 
LEDs an PA2 und PA3 regelmäßig blinken.

Das beobachtete Verhalten ist jedoch, dass die LEDs an PA0 und PA1 
leuchten, die LED an PA3 blinkt, aber die LED an PA2 bleibt dunkel. (Die 
LED funktioniert aber, das habe ich schon getestet).

Ich kann mir das Verhalten jedoch nicht erklären: Die Interrupt-Routine 
scheint regelmäßig ausgelöst zu werden (LED an PA3 blinkt), aber das 
'flag' scheint nicht gesetzt zu werden.

Habe schon im Assembler-Listing geschaut, das 'flag' wird wirklich als 
volatile behandelt (LDS / STS).

Für jede Hilfe oder Input bin ich dankbar.

Viele Grüße
Chris L.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Erstmal: Um welchen Mikrocontroller geht es? Den ATmega64?

Aber ich muss dich mal loben, du bist einer der wenigen, die gleich im 
Eröffnungsbeitrag den Quelltext, das erwartete Verhalten und das 
beobachtete Verhalten beschreiben.

Chris L. schrieb:
> Meine Erwartung ist, dass ...
> die LEDs an PA2 und PA3 regelmäßig blinken.

Du toggelst in der ISR() PA3 und in main() PA2. Sieht soweit gut aus. 
Ich sehe da keinen Fehler.

Hast du vielleicht vergessen, AVCC anzuschließen?

ich würde mal zur Gegenprobe einfach alle LED's einschalten - ohne 
Timer, ohne Schleifen.

: Bearbeitet durch User
von Chris L. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Erstmal: Um welchen Mikrocontroller geht es? Den ATmega64?
>
> Aber ich muss dich mal loben, du bist einer der wenigen, die gleich im
> Eröffnungsbeitrag den Quelltext, das erwartete Verhalten und das
> beobachtete Verhalten beschreiben.
>
> Chris L. schrieb:
>> Meine Erwartung ist, dass ...
>> die LEDs an PA2 und PA3 regelmäßig blinken.
>
> Du toggelst in der ISR() PA3 und in main() PA2. Sieht soweit gut aus.
> Ich sehe da keinen Fehler.
>
> Hast du vielleicht vergessen, AVCC anzuschließen?
>
> ich würde mal zur Gegenprobe einfach alle LED's einschalten - ohne
> Timer, ohne Schleifen.

Hey Stefan,

klar, hier noch ein paar Informationen, die gefehlt haben:
Controller: ATMega64A
Board: So ein fertiges China Board ohne uC oder Schaltplan; uC separat 
gekauft und verlötet.
Compiler: AVR-GCC 5.3.0 mit avr-libc 2.0.0

Wegen der Gegenprobe: Ich habe die LEDs getestet, alle funktionieren. 
Bevor ich mit Timer und Interrupts angefangen habe, habe ich ein kleines 
Lauflicht mit delays implementiert, das hat funktioniert.

Kleiner Nachtrag:
Setze ich das 'flag' manuell aus der main-loop, springt er auch in den 
if-Block.

Habt ihr weitere Ideen, wie ich das Problem weiter eingrenzen könnte?

Viele Grüße
Chris L.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Chris L. schrieb:
> Habt ihr weitere Ideen, wie ich das Problem weiter eingrenzen könnte?

Nö. Das ist der Moment, wo ich den Debugger aus der Mottenkiste holen 
würde und das Programm Zeile für Zeile durchsteppen würde. Manchmal 
sieht man dabei Fehler, die man beim Betrachten des Quelltextes nicht 
gesehen hat.

Falls du keinen Debugger hast, kannst du das vielleicht im Simulator des 
AVR Studio austesten.

: Bearbeitet durch User
von Mario M. (thelonging)


Bewertung
-1 lesenswert
nicht lesenswert
Lass mal das Toggeln von PA3 in der ISR weg. Tut sich dann was an PA2?

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
Ich hab mir's genau angeschaut und kann keinerlei Grund sehen, warum es 
nicht funktionieren sollte.

Klingt vielleicht blöd, aber hast du auch so Trivialitäten 
ausgeschlossen, wie z.B. dass du vielleicht das falsche Binary auf den 
µC flashst - irgendeinen alten Stand statt das gerade frisch compilerte 
oder sowas?

von Michael D. (nospam2000)


Bewertung
0 lesenswert
nicht lesenswert
Chris L. schrieb:
> Habt ihr weitere Ideen, wie ich das Problem weiter eingrenzen könnte?

In der Schleife machst du ein Read-Modify-Write welches durch die ISR 
unterbrochen werden kann und ebenfalls auf PORTA schreibt:
main()
// debug: toggle LED at PA2
            PORTA ^= (1 << PA2);
 11a:  8b b3         in  r24, 0x1b  ; 27
 11c:  89 27         eor  r24, r25
 11e:  8b bb         out  0x1b, r24  ; 27

ISR:
    // debug: toggle LED at PA3
    PORTA ^= (1 << PA3);
  c2:  9b b3         in  r25, 0x1b  ; 27
  c4:  88 e0         ldi  r24, 0x08  ; 8
  c6:  89 27         eor  r24, r25
  c8:  8b bb         out  0x1b, r24  ; 27

Du solltest die Interrupts in main() kurz sperren um race conditions zu 
vermeiden:
            cli();
            PORTA ^= (1 << PA2);
            sei();

Das geht übrigens auch atomar ohne read/xor/write (zumindest bei 
ATMega328) und spart auch cli/sei, siehe Datasheet:
"Writing a logic one to PINxn toggles the value of PORTxn, independent 
on the value of DDRxn. Note that the SBI instruction can be used to 
toggle one single bit in a port."

Ob das mit Deinem Problem zu tun hat, kann ich nicht abschätzen, ist 
eher ein zusätzliches Problem welches sporadisch auftreten kann.

  Michael

von Chris L. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Chris L. schrieb:
>> Habt ihr weitere Ideen, wie ich das Problem weiter eingrenzen könnte?
>
> Nö. Das ist der Moment, wo ich den Debugger aus der Mottenkiste holen
> würde und das Programm Zeile für Zeile durchsteppen würde. Manchmal
> sieht man dabei Fehler, die man beim Betrachten des Quelltextes nicht
> gesehen hat.
>
> Falls du keinen Debugger hast, kannst du das vielleicht im Simulator des
> AVR Studio austesten.

Guter Punkt. Habe leider keinen Debugger, sondern nur einen dieser 
usbasp-clone (mkII clone), darüber geht HW-Debugging ja nicht, oder? AVR 
Studio nutze ich nicht, aber werde am Wochenende mal simulavr probieren.

Mario M. schrieb:
> Lass mal das Toggeln von PA3 in der ISR weg. Tut sich dann was an PA2?

Gerade getestet, hat leider nichts geändert (außer, dass die LED an PA3 
nicht mehr blinkt ;-P )

Rolf M. schrieb:
> Klingt vielleicht blöd, aber hast du auch so Trivialitäten
> ausgeschlossen, wie z.B. dass du vielleicht das falsche Binary auf den
> µC flashst - irgendeinen alten Stand statt das gerade frisch compilerte
> oder sowas?

Klingt nicht blöd, war auch eine meiner Vermutungen. Habe schon mehrfach 
alles außer Makefile und *.c gelöscht und alles neu bauen lassen - ohne 
Erfolg.



Die ATMega64A habe ich im 5er Pack aus China über AliExpress. Könnten 
die Chips eventuell Schrott sein? Oder beim Löten verbrutzelt? Habe zwei 
Boards bestückt und beide uC verhalten sich identisch. Die Chips melden 
sich auch mit der korrekten DeviceSignature beim Programmer an.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Chris L. schrieb:
> darüber geht HW-Debugging ja nicht, oder?

Nee, geht nicht

Chris L. schrieb:
> Die ATMega64A habe ich im 5er Pack aus China über AliExpress. Könnten
> die Chips eventuell Schrott sein? Oder beim Löten verbrutzelt?

Unwahrscheinlich, denn du hast ja alle LEDs per Software einschalten 
können, und die eine LED die gerade nicht geht, soll ja immer noch per 
Software geschaltet werden.

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
Michael D. schrieb:
> In der Schleife machst du ein Read-Modify-Write welches durch die ISR
> unterbrochen werden kann und ebenfalls auf PORTA schreibt:

Ein durchaus verfolgenswerter Ansatz.

Der mögliche Fehler entsteht aber nicht an der genannten Stelle, sondern 
hier:

Chris L. schrieb:
> PORTA |= (1 << PA1);

Da hält sich das Programm die meiste Zeit auf. Entweder sperrt man dafür 
die Interrupts oder setzt diese Anweisung in den zeitgesteuerten Teil 
der Schleife. Die Anweisung macht an dieser Stelle sowieso keinen Sinn. 
Was in dem if(flag)-Teil passiert ist praktisch vom Timing her 
geschützt.

von Chris L. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael D. schrieb:
> Chris L. schrieb:
>> Habt ihr weitere Ideen, wie ich das Problem weiter eingrenzen könnte?
>
> In der Schleife machst du ein Read-Modify-Write welches durch die ISR
> unterbrochen werden kann und ebenfalls auf PORTA schreibt:
> main()
> // debug: toggle LED at PA2
>             PORTA ^= (1 << PA2);
>  11a:  8b b3         in  r24, 0x1b  ; 27
>  11c:  89 27         eor  r24, r25
>  11e:  8b bb         out  0x1b, r24  ; 27
>
> ISR:
>     // debug: toggle LED at PA3
>     PORTA ^= (1 << PA3);
>   c2:  9b b3         in  r25, 0x1b  ; 27
>   c4:  88 e0         ldi  r24, 0x08  ; 8
>   c6:  89 27         eor  r24, r25
>   c8:  8b bb         out  0x1b, r24  ; 27
>
> Du solltest die Interrupts in main() kurz sperren um race conditions zu
> vermeiden:
>             cli();
>             PORTA ^= (1 << PA2);
>             sei();
>
> Das geht übrigens auch atomar ohne read/xor/write (zumindest bei
> ATMega328) und spart auch cli/sei, siehe Datasheet:
> "Writing a logic one to PINxn toggles the value of PORTxn, independent
> on the value of DDRxn. Note that the SBI instruction can be used to
> toggle one single bit in a port."
>
> Ob das mit Deinem Problem zu tun hat, kann ich nicht abschätzen, ist
> eher ein zusätzliches Problem welches sporadisch auftreten kann.
>
>   Michael

Danke dir, habe ich gerade getestet, wie es sich mit gesperrten 
Interrupts während dem Schreiben nach PORTA verhält / leider ohne 
Erfolg.
cli();
PORTA ^= (1 << PA2);
sei();


Danke für den Tipp mit dem Togglen der Pins! Kenne das Feature aus der 
Automotive / ATmegaxx8 Reihe, ist aber für den ATmega64A nicht verfügbar 
(zumindest nicht dokumentiert)

von Michael D. (nospam2000)


Bewertung
0 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Der mögliche Fehler entsteht aber nicht an der genannten Stelle, sondern
> hier:
> Chris L. schrieb:
>> PORTA |= (1 << PA1);
>
> Da hält sich das Programm die meiste Zeit auf.

Das stimmt prinzipiell schon, allerdings hat der Compiler laut Listing 
aus dieser Zeile eine atomare Operation gemacht:

        // debug: turn on LED at PA1
        PORTA |= (1 << PA1);
 10c:  d9 9a         sbi  0x1b, 1  ; 27

Lass es mal weg, vielleicht beeinflusst das ja tatsächlich den Ablauf.

  Michael

: Bearbeitet durch User
von Chris L. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Chris L. schrieb:
>> Die ATMega64A habe ich im 5er Pack aus China über AliExpress. Könnten
>> die Chips eventuell Schrott sein? Oder beim Löten verbrutzelt?
>
> Unwahrscheinlich, denn du hast ja alle LEDs per Software einschalten
> können, und die eine LED die gerade nicht geht, soll ja immer noch per
> Software geschaltet werden.

Ja, stimmt. Beim verbrutzelt meinte ich eher "Den internen RAM 
verbrutzelt"...Ist das erste mal, dass ich den RAM bei den neuen Chips 
genutzt habe.

Aber ja, war eher der verzweifelte Versuch eine Erklärung zu finden ^^

von Chris L. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael D. schrieb:
> Das stimmt prinzipiell schon, allerdings hat der Compiler laut Listing
> aus dieser Zeile eine atomare Operation gemacht:
>
>         // debug: turn on LED at PA1
>         PORTA |= (1 << PA1);
>  10c:  d9 9a         sbi  0x1b, 1  ; 27
>
> Lass es mal weg, vielleicht beeinflusst das ja tatsächlich den Ablauf.
>
>   Michael

Leider auch erfolglos, aber gute Idee

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Hat der Mega64 nicht die m103 Fuse?

von Chris L. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Hat der Mega64 nicht die m103 Fuse?

Ja hat er; gerade gesehen, dass die standardmäßig auch 'programmed' ist 
o.O
Werde später den Kompatibilitätsmodus ausschalten und erneut testen.

von mIstA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Chris L. schrieb:
> Ja, stimmt. Beim verbrutzelt meinte ich eher "Den internen RAM
> verbrutzelt"...Ist das erste mal, dass ich den RAM bei den neuen Chips
> genutzt habe.

Klingt zwar irgendwie unwahrscheinlich, aber kannst Du ja mal testen, 
indem Du für Dein Flag 0xFF als default nimmst und im Interrupt auf 0 
setzt.

von foobar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Du weißt schon, dass bei diesen Zeilen
    // set prescaler to 256 -> Timer runs with 16000000/256 = 62500 Hz
    TCCR1B |= (1 << CS12) | (0 << CS11) | (0 << CS10);

    // enable CTC mode 4 on Timer1
    TCCR1B |= (0 << WGM13) | (1 << WGM12);
    TCCR1A |= (0 << WGM11) | (0 << WGM10);
das "0 << x" zwar schön dokumentiert, dass du das Bit nicht setzen 
willst, es aber auch nicht explizit gelöscht wird - ist es schon 1, 
bleibt es 1.

Das mit dem cli/sei in main um den "PORTA ^= x" wurde schon genannt 
("^=" geht nicht atomar), sollte dann aber eher dazu führen, dass die 
LED der ISR "spinnt".

Sonst seh ich keinen Programmfehler.  Ich würd erstmal PA2 und PA3 in 
ISR und main tauschen und schauen, ob nun die andere blinkt.  Wenn du 
ein Scope hast, mal an den Pins testen, ob die LEDs nicht doch mal sehr 
kurz blinken.  Ansonsten den Assemblercode posten.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Die ISR toggelt doch erst den Pin und setzt erst danach das Flag. Daraus 
ergibt sich, dass sich die beiden Zugriffe aus der ISR und der 
Hauptschleife nicht überlappen können - selbst wenn der Compiler das als 
nicht-atomare Operation übersetzt hätte.

von foobar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Die ISR toggelt doch erst den Pin und setzt erst danach das Flag. Daraus
> ergibt sich, dass sich die beiden Zugriffe aus der ISR und der
> Hauptschleife nicht überlappen können - selbst wenn der Compiler das als
> nicht-atomare Operation übersetzt hätte.

Die ISR ist immer atomar - es geht um das ^= in main, das von der ISR 
unterbrochen wird:
    main:  read port(00)
           toggle bit(01)
                          ISR:  read port(00)
                                toggle bit(02)
                                write port(02)
           write port(01)
Hier wird die LED der ISR nur für ein paar Takte kurz blitzen, bis sie 
von main wieder gelöscht wird.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Chris L. schrieb:
> Peter D. schrieb:
>> Hat der Mega64 nicht die m103 Fuse?
>
> Ja hat er; gerade gesehen, dass die standardmäßig auch 'programmed' ist
> o.O
> Werde später den Kompatibilitätsmodus ausschalten und erneut testen.

Problem gelöst, Ende der Diskussion...

https://www.mikrocontroller.net/articles/AVR_Checkliste#Besonderheiten_bei_ATmega128_und_seinen_Derivaten_im_64-Pin-Geh.C3.A4use

Oliver

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
foobar schrieb:
> Die ISR ist immer atomar - es geht um das ^= in main, das von der ISR
> unterbrochen wird:

Ja aber das passiert doch erst 100ms später in nächsten Interrupt.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Problem gelöst, Ende der Diskussion...

Du bist da vermutlich auf der falschen Baustelle. Er hat weder ein 
Problem mit ISP, noch mit den "besonderen" Ports.

Chris, hast du diese 103er Fuse gelöscht?

: Bearbeitet durch User
von foobar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Ja aber das passiert doch erst 100ms später in nächsten Interrupt.

Ja, wenn der Timer richtig programmiert ist ;-)  Feuert er ständig ... 
(oder main trödelt irgendwo rum - hier nicht der Fall)

Die Chance, dass das sein Problem ist, scheint mir eher gering (würde 
die flasche LED betreffen).  Ist aber ein genereller Fehler und sollte 
man vermeiden.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
foobar schrieb:
> Ja, wenn der Timer richtig programmiert ist ;-)

Wenn das nicht der Fall wäre, hätte er es am Blinken von PA3 erkannt.

Chris, was ist mit der Fuse?

: Bearbeitet durch User
von Chris L. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Hat der Mega64 nicht die m103 Fuse?

Oliver S. schrieb:
> Problem gelöst, Ende der Diskussion...
>
> 
https://www.mikrocontroller.net/articles/AVR_Checkliste#Besonderheiten_bei_ATmega128_und_seinen_Derivaten_im_64-Pin-Geh.C3.A4use

Stefan ⛄ F. schrieb:
> Chris, hast du diese 103er Fuse gelöscht?

Hey zusammen,
habe die M103C-Fuse gelöscht und das hat das Problem beseitigt.
Ich bin nochmals durch die Doku und das AssemblerListing gegangen und 
konnte den Fehler nun nachvollziehen:

Das 'flag'-Byte wurde an Adresse 0x0100 gelegt, was in beiden Modi eine 
gültige RAM-Adresse ist, jedoch hat der Compiler im Epilog den 
StackPointer für den nicht-Kompatibilitätsmodus initialisiert (0x10FF), 
was mit der M103C-Fuse im "External Ram" Adressbereich liegt. Ich gehe 
also davon aus, dass am Ende der ISR das RETI einfach 0x0000 vom Stack 
'geholt' hat und daher der uC einen Soft-Reset gestartet hat. Da ich den 
PORTA über die Veroderung setze, wurde die LED dann auch nicht sofort 
ausgeschaltet, sondern blieb bis zum Toggle aktiv, bis die ISR wieder 
getroffen wurde. Das würde das Verhalten (auch das 50/50 Tastverhältnis 
der LED) erklären.

Vielen Dank an alle, die mitgeholfen haben, das Problem zu lösen; auch 
nach 10 Jahren uC-Abstinenz seid ihr immer noch das beste Forum =)

von foobar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> jedoch hat der Compiler im Epilog den StackPointer für den
> nicht-Kompatibilitätsmodus initialisiert (0x10FF),
> was mit der M103C-Fuse im "External Ram" Adressbereich liegt.

Uh, fiese Falle.

Ich hatte mich schon gewundert, was in dem verlinkten Artikel die 
Aussage mit dem RET sollte.  Evtl könnte ja jemand den Absatz im Artikel 
auf folgendes ändern:
> Dies hat zur Folge, dass sich an der Adresse, an der ein für den
> ATmega64 oder ATmega128 geschriebenes Programm den Stack erwartet,
> kein RAM befindet.  Spätestens beim ersten RET-Befehl stürzt das
> Programm ab.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
foobar schrieb:
> Evtl könnte ja jemand den Absatz im Artikel
> auf folgendes ändern

Guter Vorschlag. Mache das.

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.

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