mikrocontroller.net

Forum: Projekte & Code Warten und Verzögern ohne zu Blockieren (avr/delay.h)


Autor: Johann L. (gjlayde) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hi,

immer wieder sieht man Code, in dem per delay gewartet und Zeit 
vertrödelt wird.

Das funktioniert zwar in einfachen Beispielprogrammen, aber spätestens 
wenn die delay-Routinen in Interrupt-Funktionen landen oder mehrere, 
unabhängige Verzögerungen realisiert werden sollen, stellen sich 
erhebliche Probleme ein und es gibt reihenweise Bauchlandungen.

Fragen dazu und vermurxter Code sind Legion.

Um Verzögerungen zu realisieren verwende ich in praktisch all meinen 
Projekten Countdown-Zähler: Die Anwendung zieht einen Zähler auf, und 
wenn er abgelaufen ist, folgt eine Aktion. Ist der Zähler abgelaufen, 
dann bleibt er bei 0 stehen wie ne Eieruhr.

Damit realisiere ich Dinge wie Taster-Abfrage bzw. -Entperllung, 
Einlesen von DCF-Bits, Entprellen von Drehgebern, Ausgabe von 
Morse-Zeichen, blinkende LEDs, Timeouts für Bildschirmschoner und zig 
andere Funktionalitäten.

Der Beispiel-Code anbei ist zusammengeschrumpft aus einem dieser 
Projekte und mit zusätzlichen Kommentaren angereichert:

countdown.c
   Übernimmt das Runterzählen der Countdown-Werte
countdown.h
   Hier werden Zähler eingetragen und verwaltet
timer2.c
   Initialisiert Timer2 (ATmega88) und implementiert eine ISR,
   die im 10ms-Raster die Zähler bedient.
countdonw-demo.c
   Das Hauptprogramm
Makefile
   Ein Makefile eben

Das Hauptprogramm initialisiert den Controller (einen AVR ATmega88) und 
blinkt mit 2 LEDs:
 *  Eine LED an PortC3/VCC blinkt im Takt von 1 Sekunde.
 *  Eine LED an PortB2/GND blinkt im Takt von 1.1 Sekunden.

Die main-Loop ist natätlich ohne Blockierung.

Das ganze ist was komplexer und nicht so simpel hinzutexten wie mit 
einem blockierenden delay-Ansatz, aber vielleicht kann das Beispiel ja 
ein wenig das Elend der missbrauchten delay-Einsätze, denen man ständig 
begegnet, lindern.

Wenn man den Code erstmal hat, ist er easy zu benutzen und tut seine 
arbeit auch im zeitkritischen Echtzeitumfeld.

Johann

p.s.: hier noch ein Blick in die Hauptschleife:
    while (1)
    {
        // Falls Countdown für LED1 abgelaufen ist, 
        // neu aufziehen auf 1 Sekunde (100ms)
        // und toggle LED1
        if (0 == count.ms10.led1)
        {
            PIN_LED1 |= (1 << PAD_LED1);
            count.ms10.led1 = 100;
        }
        
        // Falls Countdown für LED1 abgelaufen ist, 
        // neu aufziehen auf 1.1 Sekunde (110ms)
        // und toggle LED2
        if (0 == count.ms10.led2)
        {
            PIN_LED2 |= (1 << PAD_LED2);
            count.ms10.led2 = 110;
        }
    } // Hauptschleife

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>        if (0 == count.ms10.led1)
>        if (0 == count.ms10.led2)


Da brauchst du ja für jedes Ereignis einen eigenen Zähler, der 
dekrementiert werden muss....

Beitrag "Re: Programm bzw. Ablaeufe steuern"

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jedes vernünftige Betriebssystem hat eine callout-table. Man registriert 
sich mit Wartezeit und wird dann aufgeweckt. Alternativ mit 
Callback-Funktion.

Dein Ansatz geht in diese Richtung.

Deine Main-Schleife sollte den AVR bis zum nächsten Interrupt in den 
Sleep-Modus schicken, da bis zum nächsten Timer die Counter unverändert 
sind. Spart Energie.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias Lipinsky schrieb:
>>        if (0 == count.ms10.led1)
>>        if (0 == count.ms10.led2)
> Da brauchst du ja für jedes Ereignis einen eigenen Zähler, der
> dekrementiert werden muss...

Jepp. Ein Byte wird man noch übrig haben, und dekrementiert wird er nur 
alle 10ms.

Binnen 10ms sind schon Weltreiche aufgestiegen und wie der zerfallen... 
Un die 1-Sekunden Zähler werden gar nur 1x pro Sekunde angefasst.

Zum Entprellen von Tastern braucht man übrigens keine eigenen Zähler: 
die Taster-Routine klinkt man einfach in die 10ms-ISR ein.

Mit einem Callback-Mechanismus oder wie auch immer musst du auch 
irgenwdo und irgendwie die Zeit verwalten oder zählen.

Eine der obigen Abfragen kostet inclusive Sprung 6 Ticks, ich verstehe 
das Problem daher nicht wirklich.

Johann

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Jedes vernünftige Betriebssystem hat eine callout-table. Man registriert
> sich mit Wartezeit und wird dann aufgeweckt. Alternativ mit
> Callback-Funktion.

Das ist der Fall, wenn man ein Betriebssystem einsetzen kann und will.

Ich muss ehrlich gestehen, daß es mir im Hobby-Bereich zu weit geht ein 
OS einzusetzen und damit ein Großteil der Resources eines µC 
aufzufressen. Das wäre Overkill :-)

Ausserdem steht der obige Code für sich, es verwendet keine Externa 
wie Lib-Funktionen oder ein OS, braucht keine Task-Umschaltung etc.

> Deine Main-Schleife sollte den AVR bis zum nächsten Interrupt in den
> Sleep-Modus schicken, da bis zum nächsten Timer die Counter unverändert
> sind. Spart Energie.

Ja, das ist sinnvoll.

Der Code vermeidet aber bewusst alle unnötigen Erweiterungen, er dient 
dazu, eine simple und überschaubare Alternative zu blockierenden 
Routinen aufzuzeigen, ohne die Komplexität eines OS zu enthalten oder 
Dinge zu implementieren, die nichts mit der angesprochenen Aufgabe zu 
tun haben.

Johann

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ich verstehe das Problem daher nicht wirklich.

Was ich nur meine ist folgendes:

Nimm einfach eine Varaible, die zyklisch hochgezählt wird.
Und jedes zeitliche Ereignis benötigst du dann eine Speichervariable als 
aktuellen Zeitstempel.

Also quasi Kosntante und Zählwert vertauscht..

Ist kein Problem, nur ein Vorschlag

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias Lipinsky schrieb:

> Was ich nur meine ist folgendes:
>
> Nimm einfach eine Varaible, die zyklisch hochgezählt wird.
> Und jedes zeitliche Ereignis benötigst du dann eine Speichervariable als
> aktuellen Zeitstempel.
>
> Also quasi Kosntante und Zählwert vertauscht..
>
> Ist kein Problem, nur ein Vorschlag

äh... sorry, ich steh am Schlauch

dann braucht man doch auch ne Variable. Dann muss man eben Vergleichen, 
nicht Vermindern.

Im Beispielcode sind nur zyklische Ereignisse drin; bei abgelaufenem 
Zähler wird direkt wieder aufgezogen.

Ebenso einfach könnte man aber auch One-Shot-Zähler umsetzen, also zB 
sowas:

Auf Tastendruck hin wird immer wieder ein Zähler aufgezogen. Ist er 
abgelaufen, etwa nach 2 Minuten oder so, wird ein Display ausgeschaltet 
oder ein Bildschirmschoschoner aktiviert.

Mit nur einer Zählvariable müsste man immer schauen, wo diese gerade 
steht um die richtige Differenzzeit bis zum endgültigen Eintreffen des 
Events zu bestimmen. Bei zyklischen Variablen etwas unangenehm, der Code 
müsste zudem atomar sein.

Es können sich dann auch Glitches ergeben wie bei 
nicht-phasen/-frequenzkorrekter PWM wenn man die Wartezeit 
erhöht/erniedrigt.

Die Vergleiche auf die 8-Bit Countdown-Zähler sind hingegen atomar ohne 
spezielle Vorhehrungen -- die braucht man oben nur bei den 16-Bit 
Zählern, falls man ne hohe 10ms-Auflösung haben muss, was nur selten der 
Fall ist.

Johann

Autor: Default User (shyguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mir gefällt die Demo sehr. Der gewählte Ansatz ist ja nicht 
unbekannt und wird von so manchem anderen Compiler nativ unterstützt; 
aber ich finde es wunderbar, dass man anderen, die immer stur mir DELAY 
coden auch 'mal einen anderen Ansatz aufzeigt - So lange man auf den 
verwendeten Timer global verzichten kann :)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Johann L. (gjlayde) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Default User schrieb:
> Also mir gefällt die Demo sehr. Der gewählte Ansatz ist ja nicht
> unbekannt und wird von so manchem anderen Compiler nativ unterstützt;
> aber ich finde es wunderbar, dass man anderen, die immer stur mir DELAY
> coden auch 'mal einen anderen Ansatz aufzeigt - So lange man auf den
> verwendeten Timer global verzichten kann :)

Jo, wurde bestimmt schon 1000x in unterschiedlichsten 
Geschmacksrichtungen implementiert; hier ist die 1001...

Natürlich braucht man dafür einen Timer. Für nicht verwendete Timer gilt 
das gleiche wie für nicht belegten Speicher: Es gibt dafür keine Knete 
vom Hersteller zurück ;-)

Falls schon alle Timer belegt sind dann ist guter Rat teuer. Oft ist ein 
Takt von 10ms nicht essenziell, zum Entprellen etc. gehen auch 8ms oder 
15ms. Das öffnet die Möflichkeit, sich in einen schon belegten Timer 
einzuklinken und in einer seiner ISRs die Jobs zu erledigen und damit 
den Timer mehrfach zu nutzen.

Beispiel wäre ein Timer im PWM-Mode, der beim Überlauf die Jobs bedient.

Was mit nicht so gut gefällt ist die countdown.c. Für Anfänger dürfte 
die zu kompliziert sein und schwer nachvollziehbar. Einfacher und klarer 
wird es, wenn man auf allen SchnickSchnack verzichtet wie im Anhang 
gezeigt (ohne 100µs-Zähler, ohne 16-Bit-Zähler, ohne asm-Variante)

Johann

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und in Geschmacksrichtung Jörg Wunsch auch noch mal:

http://www.sax.de/~joerg/avr-timer/


ich würde mir wünschen, dass Beiträge des Zuschnitts "Rad erfunden die 
257ste" nicht automatisch in "Codesammllung" landen, sondern das vorab 
mal diskutiert.

Oder vielleicht mal prüfen, ob es das schon gibt - zB tauchen hier X 
Sonnenstands-Algorithmen auf, dabei gibts die in C per Festmeter und 
funktioniered - liest da noch jemand, vor codiert wird?

-mah

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast schrieb:

> ich würde mir wünschen, dass Beiträge des Zuschnitts "Rad erfunden die
> 257ste" nicht automatisch in "Codesammllung" landen, sondern das vorab
> mal diskutiert.

Nirgendwo wird behauptet, das Rad oder irgendein Rad neu erfunden zu 
haben. Trotzdem begegnet man alle Nase lang immer wieder problematischem 
Code durch blockierende Verzögerungsschleifen. Da wirst du mir 
zustimmen.
Zwar scheinen auch andere Codevorlagen das nicht aus der Welt schaffen 
zu können, aber man darf ja noch daran glauben und drauf hoffen :-)

Und ja, ich habe die Suche bemüht und nix ansprechendes in die Richtung 
gefunden.

Über unterschiedliche Ansätze kann man natürlich diskutieren und ihre 
Vor- und Nachteile darstellen.

-1-
Solche Countdown-Zähler sind in fast allen meinen Projekten enthalten. 
Das bezieht sich auf kleine, private Bastelprojekte. Der Code ist also 
genügend in der Praxis erprobt und easy auf andere Projekte anpassbar.

-2-
Die Technik ist bewusst simpel gehalten: Es ist nicht möglich, zur 
Laufzeit neue Zähler hinzuzufügen oder zu entfernen -- ich hab das 
schlicht und einfach noch nie genbraucht in dem Umfeld.
Wenn eine Komponente/Funktionalität wie ein Bildschirmschoner vorhanden 
ist, dann ist sie eben vorhanden und bekommt ihren Zähler statisch 
zugewiesen. Das ist erstens codemässig leichter nachzuvollziehen und 
zweitens schlicht und einfach schlanker. Nirgendwo brauch ich mehr als 
10 Zähler, die sich grob fifty-fifty auf 10 Millisekunden bzw- 1 
Sekunden-Raster aufteilen. Der Overhead durch das Runterzählen ist 
praktisch vernchlässigbar. Es braucht keine Tastwechsel o.ä., keine 
dynamische Verwaltung, keine Semaphore, etc.

-3-
Viele existierende Beispiele mag ich persönlich nicht. Ich habe keine 
Lust, bei Verfahren, der in gewissem Grade exemplarisch sein sollen (das 
erwarte ich von Code in einer Codesammlung) mir erst mal wegen kaum 
vorhandener oder trivialer Kommantare aus nem Spaghetti-Code zu 
extrahieren, was jede beteiligte Funktion macht oder wozu die 
beteiligten Dateien da sind. Ich will den Code nicht nur einsetzen, 
sondern auch verstehen, ohne daß meine grauen Zellen Rauchschwaden 
produzieren und ich ewig Zeit drauf verwende, das nachzukommentieren.
Aus dem Grunde habe ich beim vorliegenden Code mit Kommentaren nicht 
gegeizt, auch wenn das ein paar mehr Sätze gibt als notwendig wären, um 
die Sache anhand der Kommentare zu verstehen.

-4-
Dito für Beispiele, wo ich erst mal mit dem Tranchierbesteck an die 
beteiligten Dateien ansetzten müsste, um unabhängige, wiederverwendbare 
Module zu erhalten.

-5-
Es ist ein Vorschlag, eine Anregung, eine Alternative. Mehr nicht. Wer 
es nicht mag, wird es nicht verwenden.
Vielleicht gibt es aber auch jemand, der damit zurande kommt und dem es 
ein lästiges Thema vom Hals schafft.

> Oder vielleicht mal prüfen, ob es das schon gibt

Da brauche ich nix zu prüfen. Ich bin nicht so vermessen zu glauben, 
noch nie sei jemand auf die Idee gekommen, ähnliche Aufgaben zu lösen.
Aber auch hier siehe die Punkte oben.

Johann

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Der Code vermeidet aber bewusst alle unnötigen Erweiterungen,

Einen schlichten sleep_mode()-Aufruf am Anfang der Hauptschleife, um die 
CPU bis zum nächsten Interrupt schlafen zu legen, würde ich nicht als 
unnötige Erweiterung betrachten, sondern als konsequentes Umsetzen 
Deines Anspruchs, mit dem Code zur Vermeidung von Busy-Loops 
beizutragen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Max schrieb:
> Einen schlichten sleep_mode()-Aufruf am Anfang der Hauptschleife, um die
> CPU bis zum nächsten Interrupt schlafen zu legen

Naja, die sleep-Macros des AVR-GCC sind kreuzgefährlich, da nicht 
interruptfest!!!

Besser ist es daher, wenn man die entsprechenden Modebits selber setzt, 
dann weiß man was man tut und wo man atomic verwenden muß.

Bei Netzbetrieb benutze ich generell kein Sleep.
Der Programmieraufwand und das Einbauen zusätzlicher Fehlerquellen ist 
den geringen Effekt nicht wert.
Die Stromabsenkung bei Idle ist zwar meßbar, haut einen aber nicht vom 
Hocker. Und in der Regel ist die CPU ja nicht der Hauptverbraucher.
Der Sleep-Mode für die ADC-Wandlung hatte bei mir keinen merkbaren 
Effekt, die Lesungen waren gleicht gut, wie ohne Sleep. Dafür geht dann 
die RTC nach, die man mit nem Timer macht.


Sleep zu verwenden, nur weil noch etwas Flash frei ist, halte ich daher 
nicht für sinnvoll.


Und bei Verwendung von Power-Down im Batteriebetrieb, immmer höllisch 
aufpassen, daß man sich nicht vom Aufwachen aussperrt!
Kann man nicht oft genug betonen.


Peter

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Naja, die sleep-Macros des AVR-GCC sind kreuzgefährlich, da nicht
> interruptfest!!!
>
> Besser ist es daher, wenn man die entsprechenden Modebits selber setzt,
> dann weiß man was man tut und wo man atomic verwenden muß.

Ich habe mir eben mal die Definition von sleep_mode() angeschaut:
#define sleep_mode()                           \
do {                                           \
    _SLEEP_CONTROL_REG |= _BV(SE);             \
    __asm__ __volatile__ ("sleep" "\n\t" :: ); \
    _SLEEP_CONTROL_REG &= ~_BV(SE);            \
} while (0)

Kann man daran in Sachen Interruptfestigkeit etwas verbessern, wenn man 
es händisch macht, anstatt das Makro zu verwenden?

> Der Programmieraufwand und das Einbauen zusätzlicher Fehlerquellen ist
> den geringen Effekt nicht wert.

Mal abgesehen vom Stromspareffekt kann es sogar Fehlerquellen 
ausschließen: Wenn ich eine Hauptschleife habe, die wie im obigen 
Beispiel immer erst nach dem nächsten Timer-Interrupt wieder etwas zu 
tun hat, bekomme ich durchs Schlafenlegen ein definiertes Verhalten, 
weil die Schleife nach dem Interrupt immer an der gleichen Stelle 
losläuft. Klar kann man das auch durch eine innere Schleife lösen, die 
auf ein Flag wartet, das von der ISR gesetzt wird, das ist dann aber 
mehr Aufwand als ein einfaches sleep_mode().

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Max schrieb:

> Kann man daran in Sachen Interruptfestigkeit etwas verbessern, wenn man
> es händisch macht, anstatt das Makro zu verwenden?

Ich setzte das SE-Bit zusammen mit den Modebits als Zuweisung (=), dann 
ist es atomar.
Ich finde es reichlich sinnlos, das SE-Bit alleine zu setzen.

Die Mainloop macht dann nur den Assemblerbefehl "SLEEP".


Peter

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Ich setzte das SE-Bit zusammen mit den Modebits als Zuweisung (=), dann
> ist es atomar.

... vorausgesetzt Du hast keinen Tiny, bei dem in dem Register auch noch 
andere Bits liegen.

Warum muß das denn überhaupt atomar sein? Solange keine ISR die 
Sleep-Bits anfaßt ist es doch egal, wenn dazwischen Interrupts 
passieren.

> Ich finde es reichlich sinnlos, das SE-Bit alleine zu setzen.

Dann mach mal einen Bugreport an Atmel, die Manuals emfehlen nämlich 
genau diese Vorgehensweise: SE an, sleep, SE aus, um zu vermeiden, daß 
man die CPU versehentlich schlafen legt.

> Die Mainloop macht dann nur den Assemblerbefehl "SLEEP".

Auch dafür hat die avr-libc ein Makro. ;)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Max schrieb:
> ... vorausgesetzt Du hast keinen Tiny, bei dem in dem Register auch noch
> andere Bits liegen.

Dann muß man es atomar klammern.


> Warum muß das denn überhaupt atomar sein? Solange keine ISR die
> Sleep-Bits anfaßt ist es doch egal, wenn dazwischen Interrupts
> passieren.

Genau das ist aber sehr gebräuchlich:
Der Pin-Change-Interrupt weckt die CPU auf und damit sie nicht weiterhin
mit Interrupts geflutet wird, disabled er sich selber und schaltet 
Power-Down aus.
Aber das nicht atomare sleep_mode() schaltet Power-Down wieder ein und 
schon haben wir den Salat.

Bei den ATTiny könnte auch ein externer Interrupt die Flanke umschalten 
und der zufällig unterbrochene sleep_mode() macht dies dann zunichte.
Zwar friert die CPU nicht ein, aber ist ja auch unschön, wenn dann die 
Impulsflanken totalen Mumpitz messen.


> Dann mach mal einen Bugreport an Atmel, die Manuals emfehlen nämlich
> genau diese Vorgehensweise: SE an, sleep, SE aus, um zu vermeiden, daß
> man die CPU versehentlich schlafen legt.

Es steht drin, aber ohne genaue Erklärung.
Die einzig mögliche Erklärung wäre, er könnte schon bei gesetztem SE-Bit 
zufällig in Sleep gehen, ohne das der Sleep-Befehl ausgeführt wurde :-(
Damit würden Sie aber dem AVR das Armutszeugnis ausstellen, er wäre 
unzuverlässig.
Entweder eine CPU macht etwas immer auf einen Befehl hin oder macht es 
nie. Ein "vielleicht" oder "manchmal" darf es nicht geben.



>> Die Mainloop macht dann nur den Assemblerbefehl "SLEEP".
>
> Auch dafür hat die avr-libc ein Makro. ;)

O.k., dieses Macro wäre brauchbar.


Peter

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Max schrieb:
> Johann L. schrieb:
>
>> Der Code vermeidet aber bewusst alle unnötigen Erweiterungen,
>
> Einen schlichten sleep_mode()-Aufruf am Anfang der Hauptschleife, um die
> CPU bis zum nächsten Interrupt schlafen zu legen, würde ich nicht als
> unnötige Erweiterung betrachten, sondern als konsequentes Umsetzen
> Deines Anspruchs, mit dem Code zur Vermeidung von Busy-Loops
> beizutragen.

Das hat der Code garnicht als Anspruch. Daß die Vermeidung von 
Unbusy-Loops einfach umzusetzen ist, ist allerdings ein angenehmer 
Nebeneffekt (den man mit jedem anderen nichtblockierenden Ansatz auch 
erreicht).

Ein Sleep stünde genau da, wo es auch mit Verwendung von Delay als 
"Design-Pattern" stehen würde: am Anfang der Main-Loop zum Beispiel.

Der Effekt ist nur, daß der Code mit Delay viel Zeit vertrödelt und 
daher weniger schläft -- daß weniger Zeit über bleibt trifft aber auf 
alle anderen Teilnehmer an der Main-Loop ebenso zu, nicht nur auf Sleep.

Ohne Blockierung stehen sich die Teilnehmer nicht gegenseitig auf den 
Füßen rum. Das ist alles. Sie arbeiten effektiver -- damit natürlich 
auch ein denkbares Sleep -- oder die Zusammenarbeit/Unabgängigkeit wird 
dadurch erst ermöglicht.

Johann

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.