www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Drehimpulsgeber spinnt


Autor: J. K. (rooot)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Ich hab aus einer alten PC-Maus den Drehimpulgeber ausgebaut. (Mausrad)

Diesen hab ich jetzt an meinen µC (MEGA16) angeschlossen und Programm 
dazu geschrieben.

vorerst sollte eine Variable in/decrementiert werden.

Dazu werte ich aus, welcher der Beiden Anschlüsse zuerst seinen Wert 
ändert.

prinzipiell funktioniert das Programm. Öfters (besonders bei einer der 
beiden  Richtungen) funktioniert das aber nicht. Da wird der Zähler 
immer mal wieder  in die falsche richtung gezählt (zb. 4 5 6 5 4 5 
statt 4 5 6  7).

An was kann das liegen?

Code im Anhang. (MEGA 16 @16Mhz)

Ich weiß, Code ist schlecht, wenn noch andere Sachen gemacht werden 
sollen (böse Warteschleifen)

mfg
J.K

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne mir den Code anzusehen:

Passiert das "In die Falsche Richtung zählen" wenn du schnell drehst? 
Und geht alles wenn du langsam drehst? Dann ist die Abtastung zu langsam 
und kommt mit der Frequenz der Eingangssignale nicht klar.

Mfg

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das was Christian geschrieben hat wäre auch meine erste Idee gewesen:

zu langsame Abtastung.

Das Problem hatte ich bei meinem Drehencoder auch, bei zu langsamer 
Abtastung und einer zu hohen Drehgeschwindigkeit des Drehknopfs hat das 
Modul falsch abgetastet.

Stichwort: http://de.wikipedia.org/wiki/Alias-Effekt

Häufiger Fehler, über den man gerade in der Signalverarbeitung häufig 
stolpert.


Ich habe so gelöst:
Beim Drehen entsteht ein "puls" (low-high z.b.) auf einer Spur (A oder 
B)..
In diese Spur taste ich 4 mal (!) mit einer Frequenz von 1 kHz.
(Realisiert mit dem RTC - Real Time Counter)
An den Spuren entsteht ein so genannter Gray-Code.

Die Routine wertet nun die Signal aus und puffert diese Werte.
Wird nun 4 mal ein "Links-Indikator" detektiert meldet meine Routine 
einen "Links-Impuls"....

das funktioniert bei mir einwandfrei!
Auch bei seeeeeeehr langsamen Drehen (um der Frage gleich vorzubeugen 
;-) )... meine Routine berücksichtigt folgende Fälle:

"Links Indikator"
"Wiederholungs-Indikator" damit ist der Fall des langsamen Drehens 
abgedeckt
"Rechts Indikator"
"Fehler Indikator"

In deinem Fall wäre z.B. ein Fehler-Indikator bei mir gemeldet worden.. 
(unzulässige Code-Folge) meine Routine setzt daraufhin die 
Indikator-Zähler zurück und start neue Zähl-Periode...

damit nicht sowas wie bei dir passiert: 4, 5, 6, 5, 6.....

Die Routine hat eine Ausführungsdauer von 34 Mikrosekunden...
also eine Auslastung unter 4 %... das is noch ok!
Wenn du Code oder sonst was willst! Einfach melden! :-)

Gruß
Sebastian

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Ansatz ist falsch! Und die verschachtelten Warteschleifen sind auch 
nicht grad gut.

Beitrag "Drehgeber auslesen"

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Die Routine ist nur so "langsam", weil ich noch "schnelles Drehen" 
berücksichtige...

also Rückgabewert gibt meine Routine noch einen 
Multiplikations-Faktor... x1, x10, x100....

Will man z.b. über ein Display einen Anlog Wert hochdrehen... dann dreht 
man sich bei einer Auflösung von 0.001 V einen Wolf, wenn man von 1 V 
auf 5 V will...

die routine detektiert "schnelles" drehen... setzt einen 
multiplaktions-indikator.. und mein auswertendes modul kann dann den 
analog-wert mal schnell um faktor 10 oder 100 erhöhen..

da es "merkt", dass der benutzer schnell mal den wert hoch schrauben 
will...

das ganze funktioniert einwandfrei!
auch normale einstellungen +/- 1 sind problemlos möglich ;-)

Da die schwellen (nach tests) optimal gewählt wurden...

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ohje... so viel Diskussion um so ein einfaches Thema ;-)

einfach:

- schnell genug abtasten
- spuren richtig umcodieren
- werte puffern (letzter Wert, neuester Wert)
- auswerten über ne 4x4 Look-Up-Table
- vielleicht noch geschwindigkeitsänderungen detektieren...

und aus die maus ;-)

(Wird aber auch in teuren Geräten oft genug noch falsch gemacht....! Was 
ich da schon an Routinen "gesehen" habe... da kommt einem das kalten 
GRauen...)

Autor: Sebastian B. (mircobolle)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mehr Infos siehe Dateianhang...

das ist ne ganz gute Erklärung zu dem ganzen Thema!

nen guuden!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Sebastian B. (Firma cD) (mircobolle)

>Dateianhang: MasterThesis_auszug.pdf (121,4 KB, 2 Downloads)

Seite 2

"Das ermöglicht die asynchrone Abtastung, ohne mehr als einen Schritt 
vom wahren Ergebnis entfernt zu sein, weil maximal ein Bit falsch 
erfasst wird (weitere Informationen zu diesem Thema unter: [Mik08])."

Kommt mir verdammt bekannt vor der Text ;-)
Muss sowas aber in einer offiziellen Diplomarbeit, ähhh Meisterthese in 
Gänsefüsschen eindeutig als Zitat gekennzeichnet werden?

MfG
Falk

MfG
Falk

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk

Zitat-Hinweise sind natürlich Sache des Professors (wie er es gern mag).
Aber [Mik08]
verweist ja auf den Link, wo die Text Stelle zu finden ist ;-)

Muss hier allgemein mal ein großes Lob an das Forum und besonders das 
Wiki aussprechen. Die Beiträge sind wirklich zum einen verständlich und 
zum anderen auch noch inhaltlich fundiert geschrieben. Großer Respekt

;-)

Leider, sind bei den Beiträgen oft keine Autoren genannt, so dass man 
diese richtig im Literaturverzeichnis zitieren kann. Somit steht als 
"Autor" nur:http://www.mikrocontroller.net

ich hoffe damit fühlt sich niemand beleidigt ;-) oder benachteiligt.

Gruß
Sebastian

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[Mik08]............... Mikrocontroller.net: Drehgeber
URL: [http://www.mikrocontroller.net/articles/Drehgeber]
Stand:18.08.2008

so sieht der Literaturhinweis aus ;-)

Autor: J. K. (rooot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antworten!

Matthias Lipinsky wrote:
> Der Ansatz ist falsch! Und die verschachtelten Warteschleifen sind auch
> nicht grad gut.
>
> Beitrag "Drehgeber auslesen"

warum?

mein Drehencoder ist im Prinzip der wie im Wikiartikel

>http://www.mikrocontroller.net/articles/Drehgeber

dh. er rastet bei 00 und 11 ein.

wie im wikiartikel zu erkennen ändert sich bei Drehrichtung nachts 
rechts die Spur A zuerst, links Spur B

Die Abtastfrequenz ist sichter hoch genug. Der µC ist mit 16Mhz getaktet 
und macht die ganze Zeit nichts anderes(siehe Code)! Er geht nur in die 
Warteschleife wenn eine Weiterdrehung erkannt wurde (um die Änderung der 
2. Spur zu ignorieren).

Das Phänomen tritt bei langsamer und schneller Drehung gleichermaßen 
auf.

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus J.K.

>mein Drehencoder ist im Prinzip der wie im Wikiartikel

>>http://www.mikrocontroller.net/articles/Drehgeber

>dh. er rastet bei 00 und 11 ein.

Was meinst du mit er rastet ein?
Also meiner Meinung nach wird bei einer "Einrastung" (z.B. 24 Raster / 
360 Grad)... ein Impuls (wie im Artikel erzeugt).
Jede Spur erzeugt so einen Impuls.. 90 GRad Phasenversetzt. Je nach dem 
wie die Spuren zueinander stehen lässt sich dann die Drehrichtung 
ermitteln.. (GRay-Code)..

Ich hab mir deinen Code jetzt nicht angeschaut.

Nochmal zur Klarstellung?
Tastest du ab, oder arbeitest du mit Flanken-Interrupts?

>Die Abtastfrequenz ist sichter hoch genug. Der µC ist mit 16Mhz getaktet
>und macht die ganze Zeit nichts anderes(siehe Code)! Er geht nur in die
>Warteschleife wenn eine Weiterdrehung erkannt wurde (um die Änderung der
>2. Spur zu ignorieren).

62,5 Nanosekunden... wäre dein Takt.. bei 16MHz Abtastfrequenz..
in 62,5 Nanosekunden wertest du nix aus... zumindest nicht über 
Assembler/C.. (is ja schließlich ein MICROprozessor.. und kein 
NANOprozessor ;-) ...

so scherz bei seite...

ich glaub an dem Konzept ist was net ganz richtig...
erzeug im Controller einen Takt... z.b. über einen Timer.. und erzeuge 
eine ISR (interrupt service routine).. im 1 ms Takt.

Wenn die Routine aufgerufen wird, wertest du beide Spuren A und B aus.. 
(über eine Look-Up-Table).. wie in der PDF die ich gepostet habe...

Warum gehst du in eine Warteschleife, wenn eine Änderung erkannt wurde?

Ahhh... meinst du etwa mit "Abtastung" die Controller-interne 
Flanken-erkennung? die einen Interrupt auslöst??  :-)
dann reden wir hier aneinander vorbei!

das sind 2 verschiedene Konzepte..
Abtastung arbeitet Takt-gesteuert ohne Flanken-Erkennung... hier werden 
nur Pegel ausgewertet!

das andere Konzept.. ist Flankenerkennung (interrupt) und 
pegelauswertung!
(dieses Verfahren ist UNGENAUER... und kann bei prellenden Encodern.. 
z.b. alten wie aus Computer-Mäusen ;-) zu unerwünscht vielen 
Interrupts.. Flanken führen.. die zu einer Fehl-Interpretation des 
SIgnals führen..

Für mich hört es sich so an als würdest du einfach die Spuren 
"pollen"... im Takt deines Controllers. Und wenn eine Flankenänderung 
erkannt wird wird ausgewertet... das klingt für mich nach einer 
selbstprogrammierten Flanken-Erkennung (Interrupt-mässig) das ist aber 
keine Abtastung...

Abtastung heißt das Signal IMMER und IM GLEICHEN Takt zu analaysieren.. 
und abhängig davon wie die Pegel der spuren sind. Und diese Abtastungen 
auszuwerten... um zu codieren.. und dann per Look-Up-Table 
auszuwerten...

Gruß
seb

Autor: J. K. (rooot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich taste im Takt des Mikrocontrollers ab. (ohne interrupt, ohne timer, 
kann das zu schnell sein?)

wenn einer der beiden Spuren seinen Zusand (im gegensatz zum vorher 
gespeicherten Wert) ändert wird vor,bzw. zurückgezählt.

momentan hab ich aber das Problem, dass die Spannung bei einem High nur 
ca. 1 Volt beträgt. war gesten noch nicht so.

versuchma mal dieses Problem zu behebeh...

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich taste im Takt des Mikrocontrollers ab. (ohne interrupt, ohne timer,
>kann das zu schnell sein?)

Nicht zu schnell, aber zu ungenau...

Hast du mal ein Oszi dran gehängt und geschaut wie lang die Pulse 
minimal sind?

>momentan hab ich aber das Problem, dass die Spannung bei einem High nur
>ca. 1 Volt beträgt. war gesten noch nicht so.

Wie verbindet du die Spuren mit deinem Controller?

Mein Tipp:

Spur A --> Pull-Up (ca. 5 K gegen 5 V)... dann ein RC Glied... 
Widerstand ca. 10 K... Kondensator ca. 10 N... R*C--> 0.1 ms 
Zeitkonstante..

damit beugst du schon mal einem Prellen von 0.1 ms vor...

wenn du dein Problem nicht über Timer-Interrupts und Abtastung lösten 
willst, dann dimensionier einfach deinen Tiefpaß richtig damit das 
Prellen deines Encoders ausgeglichen wird...
ist zwar nicht schön. aber sollte fürs erste besser funktionieren..

Gruß

Autor: J. K. (rooot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist über 10k auf +5V




                         VCC
                          |
                          |
                          |
                         .-.
                         | |
                         | |
                         '-'
                          |
                          |
                          |----------
                          |
                          |
                       \  o
                        \
                         \.
                          o
                          |

                         GND
(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)


dann auf µC

wenn ich pegelproblem behoben hab, werd ich mal timer interrupts 
probieren.

mfg
J.K.

Autor: J. K. (rooot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich mit Multimeter mess, Schaltet 1 Spur zwischen 0,1 Ohm und 
Overflow (also >20MOhm)
...

Autor: J. K. (rooot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab zufällig noch ne 2. Maus herumliegen gehabt.

mit dem neuen Drehimpulsgeber gehts wieder. auch die falsche Erkennung 
ist besser.

Die Timerinterrupt-Variante werd ich mir aber auch noch ansehen.

Danke Sebastian B. für deine Hilfe!

@deinem Code:
Danke, aber schreib ich mir lieber selber, lern ich vll was dabei ;-)

Autor: Sebastian B. (mircobolle)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mhm, sieht vernünftig aus...

Warum ist dann aber der Pegel so niedrig..
bei offenem Encoder sollte ja VCC anliegen...

wie gesagt Tiefpaß zur Glättung könnte auch nix schaden!
Kannst ja R und C variieren...

Hab dir gerade noch schnell ein Bild gemacht, wie das aussieht, wenn du 
"ganz schnell abtastest" (rote Striche).. aber dein Encoder prellt... 
also nicht sauber öffnet und schließt...
daran kannst du ja die Problematik des "einfachen" Abtastens erkennen...

Klar, seh ich auch so, dass man den code besser selbst schreibt! :-)
Hab auch erst vor kurzem so richtig mit Hardware begonnen.. komme eher 
aus der Informatik... :-) deshalb kann ich dich gut verstehen.


Das mit dem vorgänge Wert und dem aktuellen Wert machst du schon sehr 
richtig!! Aber ich würde dies noch nicht als festes Indiz für eine 
Auf/Abzählung nehmen...

wenn du den GrayCode benutzt... dann sage ich z.b. müssen 4 korrekte 
Codes aufeinander folgen damit ein vollständiger Dreh-Puls erkannt 
wird... somit verkleinert sich auch die Wahrscheinlichkeit einer 
falsch-abtastung...


Für was willst du den encoder eigentlich einsetzen?
ODer ist das nur zum Testen? Könnte ich auch gut verstehen.

Beste Grüße und noch viel Erfolg!

Autor: J. K. (rooot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>wenn du den GrayCode benutzt... dann sage ich z.b. müssen 4 korrekte
>Codes aufeinander folgen damit ein vollständiger Dreh-Puls erkannt
>wird... somit verkleinert sich auch die Wahrscheinlichkeit einer
>falsch-abtastung...

ok, werd ich machen

bisweilen nur zum testen.

vll bau ich mal einen "Kran", der sich durch ein Modell steuern lässt.

der Drehimpulsgeber kommt ins Modell um die Drehung um die eingene Achse 
zu detektieren, am Kran kommt dann zb ein Schrittmotor, der die Drehung 
ausführt.


mfg
J.K

Autor: J. K. (rooot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wollte grad anfangen zu programmieren da ist mir aufgefallen:

>wenn du den GrayCode benutzt... dann sage ich z.b. müssen 4 korrekte
>Codes aufeinander folgen damit ein vollständiger Dreh-Puls erkannt
>wird... somit verkleinert sich auch die Wahrscheinlichkeit einer
>falsch-abtastung...


mir ist der Vorteil schon klar, aber wird aber die Auflösung halbiert?!

die 4 Graycode zustände wiederholen sich mit 2 Rasterpunken.

Naja, wird auf einen Kompromiss hinauslaufen müssen
1. sicherer oder
2. höhere Auflösung

mfg
J.K

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soweit ich weiß braucht man beim Abtastprinzip (Standard Dannegger Code) 
überhaupt keine Entprellung vorsehen, da der Gray-Code in diesem Sinne 
Prellsicher ist. Nachdem der Encoder sich also in den nächsten Raster 
fertiggeprellt hat, stimmt der Wert wieder.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>wenn du den GrayCode benutzt... dann sage ich z.b. müssen 4 korrekte
>Codes aufeinander folgen damit ein vollständiger Dreh-Puls erkannt

Ich denke, er meinte: '4 gleiche Codes'.

MfG Spess

Autor: Sebastian B. (mircobolle)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
>Soweit ich weiß braucht man beim Abtastprinzip (Standard Dannegger Code)
>überhaupt keine Entprellung vorsehen, da der Gray-Code in diesem Sinne
>Prellsicher ist. Nachdem der Encoder sich also in den nächsten Raster
>fertiggeprellt hat, stimmt der Wert wieder.

Hallo,

das stimmt, der Gray-Code den die Spuren erzeugen und die Auswertung 
schützen vor Falsch-Erkennung.
Jetzt kommt aber ein kleines "aber": Der Encoder prellt ja trotzdem ein 
wenig..
Ich bin jetzt auch kein Profi auf diesem Gebiet, wenn man aber jetzt 
noch einen kleinen Tiefpaß nach den Signalen reinsetzt, dann wird ja das 
Prellen schon mal verringert, falls man wirklich mal ungünstigerweise in 
so einen "Prell-Zeitpunkt" reintasten sollte...

Ist nicht zwingend erfoderlich, da ja die Code-Auswertung, diese Fehler 
erkennen kann.

@spess53:
>>wenn du den GrayCode benutzt... dann sage ich z.b. müssen 4 korrekte
>>Codes aufeinander folgen damit ein vollständiger Dreh-Puls erkannt

>Ich denke, er meinte: '4 gleiche Codes'.

Ich versuche meine Abtastfrequenz so zuwählen, dass ich (mindestens) 4 
mal in einen Dreh-Impuls hineintasten kann.

Wenn man sich einen Puls auf 2 Spuren (A und B) mal aufzeichnet, wenn 
sie 90 GRad zu einander Phasen versetzt sind und dann im gleichen 
Abstand vertikale (Abtast)-Striche einzeichnet, dann kann man an den 
Strichen Kombinationen ablesen... Z.b. Spur A: 0 Spur B: 1...

--> Nun kommt der Trick bei der Auswertung diese Zustandspaare z.B. 0;1 
werden umcodiert. Für jedes mögliche Paar wird ein Zustand definiert... 
So ergeben sich logischerweise 4 mögliche Zustände.

Diese 4 möglichen Zustände varrieren in ihrer Reihenfolge ob man nach 
Links oder Rechts dreht.

Die Auswertung erfolgt nun folgendermaßen:
Aus altem Zustands-Code und neuem Zustands-Code lässt sich nun ein 
"Indikator" für die Drehrichtung erkennen... (siehe dazu Look-Up-Table 
aus der PDF aus meinem Posting...)

aus dieser Look-Up-Table lässt sich nun dieser Indikator ablesen.
Anhand eines korrekten Zustands-Übergangs, wie ich es jetzt mal nenne, 
lässt sich aber noch nicht vorhersagen ob es sich um einen korrekten 
Links oder Rechts-Puls handelt.

Es müssen also 4 korrekte INDIKATOREN erkannt werden bis ein PULS 
erkannt wird. Das hängt zum einen mit der Abtastgenauigkeit und der 
Code-Folge zusammen.

@J.K
>mir ist der Vorteil schon klar, aber wird aber die Auflösung halbiert?!

>die 4 Graycode zustände wiederholen sich mit 2 Rasterpunken.

>Naja, wird auf einen Kompromiss hinauslaufen müssen
>1. sicherer oder
>2. höhere Auflösung

Die Gray-Code Zustände wiederholen sich bei JEDEM Rasterpunkt.
Durch die Abtastung mit 4-fach höherer Abtastfrequenz als maximale 
Puls-Frequenz ist die Genauigkeit verVIERfacht.

Es ist sicherer und genauer.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Sebastian B. (Firma cD) (mircobolle)

>Jetzt kommt aber ein kleines "aber": Der Encoder prellt ja trotzdem ein
>wenig..

Erfinde das Rad nicht neu und eckig. Du hast ja deine Informationen 
schon hier aus dem Wiki. Dann liess sie noch mal und denk drüber nach, 
anstatt wilde Theorien aufzustelln.

a) Die im Wiki gezeigten Routinen werden durch prellende Encoder KEIN 
BISSCHEN aus dem Tritt gebracht. PUNKT!

>Ich versuche meine Abtastfrequenz so zuwählen, dass ich (mindestens) 4
>mal in einen Dreh-Impuls hineintasten kann.

b) Es muss pro CODEWECHSEL mindestens eine Abtastung erfolgen, mehr 
schaden nicht. PUNKT.

>Wenn man sich einen Puls auf 2 Spuren (A und B) mal aufzeichnet, wenn
>sie 90 GRad zu einander Phasen versetzt sind und dann im gleichen

Dumm nur, dass gerade billige Encoder alles andere als 90 Grad 
Phasenversatz haben. Da gabs schon welche mit 30 Grad und weniger!.

>--> Nun kommt der Trick bei der Auswertung diese Zustandspaare z.B. 0;1
>werden umcodiert. Für jedes mögliche Paar wird ein Zustand definiert...
>So ergeben sich logischerweise 4 mögliche Zustände.

Vollkommen unötig, von Peters Ultrakompaktroutine mal abgesehen.

>Es müssen also 4 korrekte INDIKATOREN erkannt werden bis ein PULS

Was soll ein INDIKATOR sein?

>erkannt wird. Das hängt zum einen mit der Abtastgenauigkeit und der
>Code-Folge zusammen.

????

MFG
Falk

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerne für Kritik offen.
Aber das was jetzt hier passiert finde ich nicht mehr i.O.

Ich dachte ich könnte mit ein paar Informationen helfen. Ich hatte 
Auszüge aus meiner Master-Thesis und meine Routine veröffentlicht.

Ich sehe nun keine Berechtigung warum "Falk Brunner" mich hier im Forum 
auseinander zunehmen versucht.

Falls ich mich umständlich ausgedrückt haben sollte war das sicher 
unglücklich und auch, wenn manche Informationen sogar falsch gewesen 
sein sollten.

Ich habe es so wieder gegeben wie ich es verstanden habe, wie ich es mit 
einem Oszilloskop verifiziert habe und ich wie es implementiert und 
getestet habe.

Die Routine funktioniert sehr gut - ich habe keinen Grund mich jetzt 
dafür zu verstecken.

Es waren Beispiels die ich gebracht habe - falls man sie nicht verstehen 
konnte dann ist das sicherlich unglücklich.

Es ist eine Sache Informationen zu veröffentlichen (wie es hier Wiki 
geschieht). Diese Informationen müssen dann nur noch auf eine konkrete 
Problemstellung angewandt werden.

Es ist egal um wie groß der Phasenversatz ist. Hauptsache es entsteht 
eine Code-Folge.

Mir war es nicht klar, dass ich das Rad nochmal eckig nach erfinde. Was 
gelinde gesagt eine grobe Unverschämtheit ist - so eine Aussage.

Hast du mein Posting überhaupt gelesen oder bist du nur auf ein paar 
Schlagwörter angesprungen und dachtest du müsstest deinen Senf dazu 
abgeben.
Ich habe jetzt nicht verifiziert wie ein Encoder sich verhält wenn er 
prellt. Was ich jedoch weiß:
Die Code-Folge schützt vor Abtastfehlern die durch Prellen entstehen 
(PUNKT)
Die Code-Folge schützt in geringem Masse vor Aliasing-Fehlern die durch 
Unterabtastung entstehen (PUNKT)

Wenn ein Encoder prellt und in so einen Fehlerfall hineingetastet wird 
schützt die Code-Folge vor Falscherkennung (PUNKT)

Wenn nun aber ein Tiefpaß davor sein sollte, der die Flankensteilheit 
etwas abflacht und schnelle Pegel-Wechsel durch Prellen verursacht 
unterdrückt... ist das sicher kein Fehler.

Ich habe nichts neu erfunden.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian B. wrote:
> Die Code-Folge schützt vor Abtastfehlern die durch Prellen entstehen
> (PUNKT)
> Die Code-Folge schützt in geringem Masse vor Aliasing-Fehlern die durch
> Unterabtastung entstehen (PUNKT)
>
> Wenn ein Encoder prellt und in so einen Fehlerfall hineingetastet wird
> schützt die Code-Folge vor Falscherkennung (PUNKT)

> ...

> Wenn nun aber ein Tiefpaß davor sein sollte, der die Flankensteilheit
> etwas abflacht und schnelle Pegel-Wechsel durch Prellen verursacht
> unterdrückt... ist das sicher kein Fehler.

Das gibt für mich überhaupt keinen Sinn, du sagst doch quasi geradezu 
dass der Tiefpass Unsinn ist.
Dass er nicht Schaden kann, ist uns allen klar. Es geht darum diesen 
wegzulassen, was definitiv in Ordnung ist.

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz einfach: Lass ihn weg.

(Wenn deine Routine dann aber weniger oft den Fehler-Fall erkannt und 
somit jeder Raster-Punkt auch immer als Puls erkannt werden kann is das 
sicher auch net so schlecht)

Was soll das ganze eigentlich?
In meinem Fall ist das nur ein Drehknopf.
Ich steuere damit ein rotierendes Display-Menü. Stelle Werte ein.

Es funktioniert!

Denkt mal ein bisschen mehr Ingenieurs-mäßiger.
Das Ding soll möglichst gut funktionieren.

That's it.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian B. wrote:
> Mehr Infos siehe Dateianhang...
>
> das ist ne ganz gute Erklärung zu dem ganzen Thema!

Entschuldigung, das finde sogar ich ein wenig halbgar.

"Die Auswertung der Drehgeber Signalspuren erfolgt nicht über 
Flankenerkennung und Pegelauswertung von B, da dies einige Nachteile mit 
sich bringt:"

"Die Auflösung wird auf ein Viertel reduziert, weil nur jede steigende 
Flanke von A ausgewertet wird."

Zusammenhang? Und wenn man beide Flanken auswerten würde hätte man die 
halbe Auflösung? Plausibilität?

"Pendelt der Encoder zwischen zwei Codes, bei denen A seinen Pegel 
wechselt, kommt es zu (sehr) vielen Interrupts, die den MikroController 
vollkommen auslasten können."

Was hat das Auswerten der Flanken im Allgemeinen mit Interrupts im 
Speziellen zu tun?

Wenn man dafür sorgt, dass das Signal nicht prellt und man bei 
zyklischer Abtastung von A eine Zustands-Änderung erkennt, funktioniert 
eine Betrachtung von B zum Zeitpunkt der Zustands-Änderung von A sehr 
wohl ganz hervorragend und zuverlässig.
Wenn man den nackten Drehimpulsgeber mit Pullup-Widerständen benutzt ist 
das sicherlich nicht ein Weg der leicht sauber ans Ziel führt.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Sebastian B. (Firma cD) (mircobolle)

>Ich bin gerne für Kritik offen.

Wirklich?

>Ich sehe nun keine Berechtigung warum "Falk Brunner" mich hier im Forum
>auseinander zunehmen versucht.

Mach ich nicht.

>Ich habe es so wieder gegeben wie ich es verstanden habe, wie ich es mit
>einem Oszilloskop verifiziert habe und ich wie es implementiert und
>getestet habe.

Sicher, was aber nicht heisst, dass es richtig ist, wie du selber 
geschrieben hast.

>Die Routine funktioniert sehr gut - ich habe keinen Grund mich jetzt
>dafür zu verstecken.

Nöö, aber man kann sie kritisieren.

>Es ist eine Sache Informationen zu veröffentlichen (wie es hier Wiki
>geschieht). Diese Informationen müssen dann nur noch auf eine konkrete
>Problemstellung angewandt werden.

Diese Formulierung "nur noch" würde ich sparsamer einsetzen. Den gerade 
bei diesem "nur noch" hapert es oft in der Praxis.

>Es ist egal um wie groß der Phasenversatz ist. Hauptsache es entsteht
>eine Code-Folge.

Ein Irrtum.

Stell dir vor, dein Encoder macht 20 Codes/U und dreht mit max. 10 U/s. 
Macht 200 Codes/s mit 5ms Codedauer, WENN die beiden Spuren A und B 
exakt 90Grad Phasenversatz haben. Eine Abtastung mit etwas über 200 Hz 
ist dan ausreichend.

ABER

Wenn der Phasenversatz auf grund schlechter Qualität, Produktionsfehler 
etc. nur 45 Grad beträgt, dann verschluckt eine Abtastung mit knapp über 
200 Hz Schritte.

Das ist aber allgemein so und NICHT auf deinen Code beschränkt.

>Mir war es nicht klar, dass ich das Rad nochmal eckig nach erfinde. Was
>gelinde gesagt eine grobe Unverschämtheit ist - so eine Aussage.

Soviel zu deiner Kritikfähigkeit.

>Hast du mein Posting überhaupt gelesen

Durchaus.

>Ich habe jetzt nicht verifiziert wie ein Encoder sich verhält wenn er
>prellt.

Aha, plötzlich backen wir doch kleine Brötchen.

> Was ich jedoch weiß:
>Die Code-Folge schützt vor Abtastfehlern die durch Prellen entstehen
>(PUNKT)
>Die Code-Folge schützt in geringem Masse vor Aliasing-Fehlern die durch
>Unterabtastung entstehen (PUNKT)

>Wenn ein Encoder prellt und in so einen Fehlerfall hineingetastet wird
>schützt die Code-Folge vor Falscherkennung (PUNKT)

Du macht verdammt viele Punkte mit deinen jungen Jahren. Ich sehe ja ein 
dass deine Masterthesis im Moment der Mittelpunkt deines Lebens ist und 
du sie für das Wichtigste in der Welt hältst. Aber andere Leute 
vieleicht nicht. Und erst recht nicht, wenn du dich bockig hinstellst, 
dich Kritik verweigerst und dann noch Unsinn erzählst.

>Die Code-Folge schützt in geringem Masse vor Aliasing-Fehlern die durch
>Unterabtastung entstehen (PUNKT)

Ist schlicht falsch, weil das Abtasttheorem hier gar keine sinnvolle 
Anwendung erfährt. Wir tasten asynchron ein Digitalsignal ab, kein 
(bandbegrenztes) Analogsignal. Und der Graycode schützt KEIN bisschen 
vor Unterabtastungsfehlern.

>Wenn nun aber ein Tiefpaß davor sein sollte, der die Flankensteilheit
>etwas abflacht und schnelle Pegel-Wechsel durch Prellen verursacht
>unterdrückt... ist das sicher kein Fehler.

Hat keiner behauptet.

>Ich habe nichts neu erfunden.

Aber du schreibst gern alles nochmal ab, was schon mehrfach in Links 
(besser) dargestellt wurde. ;-)

MFG
Falk

P.S. Zur Kritkfähigkeit gehört auch, nicht immer gleich alles persönlich 
zu nehmen und den Kopf zu verlieren.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Sebastian B. (Firma cD) (mircobolle)

>Was soll das ganze eigentlich?
>In meinem Fall ist das nur ein Drehknopf.
>Ich steuere damit ein rotierendes Display-Menü. Stelle Werte ein.

>Es funktioniert!

Ach plötzlich? Und wozu der Ganze Aufriss dann?

>Denkt mal ein bisschen mehr Ingenieurs-mäßiger.

Das tun die meisten hier mehr, als du dir vorstellen kannst.  Nun dass 
"ingenieurmässig denken" != "Hobbybastlerdenken" ist, ala

"Bei mir läuft der UART auch mit RC-Oszillator stabil."

;-)

MFg
Falk

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Falk,

ok, jetzt habe ich meinen Zustand etwas "stabilisiert" ;-)

Aber ist verständlich, dass vielleicht etwas empfindlich auf Kritik 
gegen meine Master-Thesis verstehe (die gerade schreibe...).

Aber sei es drum ihr habt sicher mehr Erfahrung und das akzeptiere ich. 
Schließlich will ich ja dazu lernen.

Vor einem halben Jahr hatte ich nicht mal ne Ahnung davon was ein 
Encoder ist. (ich studiere Informationstechnik..)

Von wegen Abtasttheorem:
Mit Aliasing habe ich gemeint, dass bei schnellen Pegel-Wechseln 
(schnellem Drehen) und bei zu geringer Abtastfrequenz ein Aliasing 
Effekt entsteht...

Wenn mein Signal mit 100 Hz seine Pegel wechselt und ich beispielsweise 
mit 50 Hz abtaste will ja wohl keiner bestreiten, dass das nicht 
funktioniert.

>Aber du schreibst gern alles nochmal ab, was schon mehrfach in Links
>(besser) dargestellt wurde. ;-)

Hast du die Look-Up-Tabele Darstellung aus meiner PDF gesehen ? Ich 
finde diese Darstellung ist mir ganz gut gelungen.. ;-)

Scherz bei Seite... ok, das nächste mal stell ich nur noch einen Link zu 
einem Wiki Artikel rein und erspar mir den Zirkus

Prost Mahlzeit

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Sebastian B. (Firma cD) (mircobolle)

>Von wegen Abtasttheorem:
>Mit Aliasing habe ich gemeint, dass bei schnellen Pegel-Wechseln
>(schnellem Drehen) und bei zu geringer Abtastfrequenz ein Aliasing
>Effekt entsteht...

Weisst du überhaupt, was der Aliasing-Effekt WIRKLCIH ist?

Wenn ich einen 1 KHz Sinus mit 10 kHz abtaste, werde ich in den 
digitalen Daten den auch ganz gut wiedererkennen.

Wenn ich mit 2 kHz abtaste, ist das THEORETISCH noch machbar, PRAKTISCH 
aber zu langsam, wenn ich z.B. immer die Nulldurchgänge erwische.

Taste ich mit 800 Hz ab, sehe ich in den digitalen Daten plötzlich einen 
Sinus von 2*800Hz-1kHz = 600 Hz. Und wenn ich nicht anderweitig weiss, 
dass es aber 1 kHz sein muss, kann ich mich sehr schön verarschen 
lassen. ;-)

Kann man sehr einfach mit einen Digitaloszilloskop zeigen. Sinus 
einspeisen und Zeitauflösung MASSIV runterdrehen. Man sieht wieder einen 
Sinus mit vollkommen falscher Frequenz. Ein Analogoszi würde richig 
einen breiten Strich zeigen.

>Wenn mein Signal mit 100 Hz seine Pegel wechselt und ich beispielsweise
>mit 50 Hz abtaste will ja wohl keiner bestreiten, dass das nicht
>funktioniert.

Hat keiner bestritten, ist aber wie gesagt nicht wirklich Aliasing.

>Aber du schreibst gern alles nochmal ab, was schon mehrfach in Links
>(besser) dargestellt wurde. ;-)

>Scherz bei Seite... ok, das nächste mal stell ich nur noch einen Link zu
>einem Wiki Artikel rein und erspar mir den Zirkus

Wenn du viel Energie hast, kannst du auch einen Wikiartikel schreiben 
oder erweitern. Das bringt allen mehr, vor allem weil dann die 
Informationen GEBÜNDELT und SCHELL aufindbar vorliegen, nicht verstreut 
in 1001 Thread.

MFG
Falk

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. wrote:
> ...
Was ist an den Aussagen jetzt halbgar?

> Was hat das Auswerten der Flanken im Allgemeinen mit Interrupts im
> Speziellen zu tun?
Sorry, aber diese Frage verstehe ich nicht. "im Allgemeinen" und "im 
Speziellen" widerspricht sich.

> Wenn man dafür sorgt, dass das Signal nicht prellt und man bei
> zyklischer Abtastung von A eine Zustands-Änderung erkennt, funktioniert
> eine Betrachtung von B zum Zeitpunkt der Zustands-Änderung von A sehr
> wohl ganz hervorragend und zuverlässig.
Ja, es ist ja auch eine mögliche Methode das so zu machen.

> Wenn man den nackten Drehimpulsgeber mit Pullup-Widerständen benutzt ist
> das sicherlich nicht ein Weg der leicht sauber ans Ziel führt.
Da hat du es, und deswegen benutzt man lieber einen anderen Weg (zum 
Beispiel die Abtastung). Da brauchts dann auch keine Entprellung mehr 
und das ist ein eindeutiger Vorteil.

Falk: Du bist heute aber auch wieder ziemlich grob zu den Leuten ;)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Simon K. (simon) Benutzerseite

>Falk: Du bist heute aber auch wieder ziemlich grob zu den Leuten ;)

Es ist Sonntag, und mein Kreidevorrat ist erschöpft . .  . ;-)

MFG
Fa - der böse Wolf - lk

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
> Rudolph R. wrote:
>> ...
> Was ist an den Aussagen jetzt halbgar?

Was ich meine habe ich schon geschrieben.

>> Was hat das Auswerten der Flanken im Allgemeinen mit Interrupts im
>> Speziellen zu tun?
> Sorry, aber diese Frage verstehe ich nicht. "im Allgemeinen" und "im
> Speziellen" widerspricht sich.

Die Ansage im verlinkten Dokument ist erstmal ganz allgemein, dass auf 
eine Flanken-Auswertung verzichtet wurde, da das Nachteile hat.
Und unter der Auflistung der Nachteile tauchen plötzlich Interrupts auf, 
was wiederrum eine spezielle Methode der Flanken-Auswertung darstellt.

>> Wenn man dafür sorgt, dass das Signal nicht prellt und man bei
>> zyklischer Abtastung von A eine Zustands-Änderung erkennt, funktioniert
>> eine Betrachtung von B zum Zeitpunkt der Zustands-Änderung von A sehr
>> wohl ganz hervorragend und zuverlässig.
> Ja, es ist ja auch eine mögliche Methode das so zu machen.
>
>> Wenn man den nackten Drehimpulsgeber mit Pullup-Widerständen benutzt ist
>> das sicherlich nicht ein Weg der leicht sauber ans Ziel führt.
>
> Da hat du es, und deswegen benutzt man lieber einen anderen Weg (zum
> Beispiel die Abtastung).

Nochmal lesen, Abtastung führe ich auch auf, die Auswertung ist anders.

> Da brauchts dann auch keine Entprellung mehr
> und das ist ein eindeutiger Vorteil.

Keine Frage.

Autor: J. K. (rooot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute seid nett zueinander!

Ich finde nicht dass jemand runtergemacht werden sollte, nur weil er 
nicht den Wissensstand wie man selbst hat!


@topic

>Die Gray-Code Zustände wiederholen sich bei JEDEM Rasterpunkt.
>Durch die Abtastung mit 4-fach höherer Abtastfrequenz als maximale
>Puls-Frequenz ist die Genauigkeit verVIERfacht.

>Es ist sicherer und genauer.

ah, da liegt der Hund begraben! bei meinem Drehgeber widerholen sich die 
4 Zustände nur alle 2 Rasterpunkte. (wie im Wikiartikel)

Autor: J. K. (rooot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, die Abtastlösung funktioniert um einiges besser!

Hab zuerst mit 1kHz abgetastet. Da hatte ich aber das Problem, dass oft 
die Phasenverschiebung nicht erkannt wurde. Die Spuren sind von 00 auf 
11 (Rasterpunkte) gesprungen.

Eine Drehung wurde nur erkannt, wenn sehr langsam gedreht wurde.

hab jetzt auf 5 kHz erhöht, ist aber nicht viel besser geworden.

in anderen Beiträgen (Beitrag "Drehimpulsgeber mit Rasterstellung bei 00/11 auswerten") ist 
von 500Hz die Rede.


soll ich einfach weitererhöhen? Welche Abtastrate ist in diesem Fall ist 
"normal"? Kann man da eine Aussage machen?

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also ich taste mit 1 kHz - jede 1 ms - die Spuren A und B ab.

So, dass ich alle 4 Zustandsänderungen pro Rasterung mitbekomme. Ich 
habe mir ausgerechnet, dass ich mit einer Abtastfrequenz von 1 kHz und 
15 Rasterpunkten (alle 15 Grad) somit mit einer maximalen Drehzahl von 
etwa 3750 Grad  Sek - also etwa 10 Umdrehungen  Sekunde meinen 
Drehgeber drehen kann und die Drehrichtung noch korrekt erkannt werden 
kann.

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ah, da liegt der Hund begraben! bei meinem Drehgeber widerholen sich die
>4 Zustände nur alle 2 Rasterpunkte. (wie im Wikiartikel)

Anhand deiner Aussage würde ich sagen du brauchst, nicht wie ich 4 
Zustandswechsel, sondern nur 2. Damit würde sogar eine niedrige 
Abtastfrequenz ausreichen.. Aber mit 1 kHz und normaler 
Drehgeschwindigkeit sollte es auf jeden Fall gehen.

Andere Frage:
- Was für einen Controller verwendest du?
- Assembler oder C ?

Autor: Yngvar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hello,

I think I have alomst the same problem like J.K.

Sorry, my german is not really good. I'm from norway but I stay here in 
germany for my semester abroad.

I'm interessted in microcontroller programming.

So what I did unterstand is that the econding of the rotary encoder 
didn't worked correct... so he had to changed his programming concept.

Could somebody describe me how the encoding works best?
I saw this PDF Document above my post... I liked the pictures, which 
helped me a lot to get how the ecnoder works... espacially the signal 
waveform of the encoder.

Thanks a lot!

Yngvar

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Yngvar (Gast)

>Could somebody describe me how the encoding works best?

Look here, but german only. Sorry.

Drehgeber

Regards
Falk

Autor: Yngvar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello Falk,

thank you for your fast response!
So I will look at your linked document, so I can improve my 
german-reading skills, too.

I have another question, but with the same background.

Does encoder exists, that have more then the normal 'left / right' 
direction? Does encoder exists, which are able to be controlled by 
different movements additional to the 'left/rigt' direction... like a 
joy-stick, that can be moved in 4 directions and could be pushed too.

all this controls in one device would be fantastic... so I think

Thanks a lot!

Yngvar

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Yngvar (Gast)

>Does encoder exists, that have more then the normal 'left / right'
>direction?

Some have a zero indicator signal, so you can reset your counter and 
have a absolut position.

> Does encoder exists, which are able to be controlled by
>different movements additional to the 'left/rigt' direction... like a
>joy-stick, that can be moved in 4 directions and could be pushed too.

Push buttons are quiet common, more than one axis AFAIK not.

>all this controls in one device would be fantastic... so I think

Such things are usually doe using a analoge joystick, controlled by two 
potentiometers.

The only two axis device I know is the classic mechanical mouse.

Regards
Falk

Autor: J. K. (rooot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Andere Frage:
>- Was für einen Controller verwendest du?
>- Assembler oder C ?

>-MEGA16
>-C

Die eine Richtung funktioniert auch sehr gut, die andere weniger. Mir 
scheint, dass in die eine Richtung ein gößerer Abstand ist als in die 
andere. (Habe mir die Portzusände über die RS232 ausgebenlassen)

>The only two axis device I know is the classic mechanical mouse.

My mechanical mouse works with 2 light barriers. There are two axis. On 
the ends are plates with gaps, which interrupt the beam.

Autor: J. K. (rooot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Habe mir die Portzusände über die RS232 ausgeben lassen

das war der Fehler!!!

Die Übermittlung des der Werte (mit kleiner Beschreibung dauerte zulang)

9600 Baud
//printf("\rZahl:%3i Spur A B %i %i Zustand: %i",z,PIND.6,PIND.7,zust);

ca 35 zeichen

bei 9600 zeichen pro sekunde

sind das 3,64 ms !

mfg
J.K

Autor: Michael H* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yngvar wrote:
regarding the rotary encoders: on page 7 this pdf elaborates pretty much 
both rotation recognition methods:
http://www.altron.de/_pdf/ddm/427z1.pdf
even in english, though ^^

> I have another question, but with the same background.
>
> Does encoder exists, that have more then the normal 'left / right'
> direction? Does encoder exists, which are able to be controlled by
> different movements additional to the 'left/rigt' direction... like a
> joy-stick, that can be moved in 4 directions and could be pushed too.

alps does produce such devices, listed under joysticks. couldn't find em 
right now, but they exist ^^

Autor: nols (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I think you mean something like this:
http://www.reichelt.de/?;ACTION=3;LA=4;GROUP=B254;...

The order number is RKJXP122002

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.