AVR8ASM-Projekte

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hallo zusammen,

ich wollte einen DC-Getriebemotor, PWM gesteuert, rechts / links laufen 
lassen können. Das heisst mit verschiedenen, per Hand, einstellbaren 
Geschwindigkeiten.

Ein Handencoder ( so nenne ich ihn ) bzw. Drehgeber (auch 
Inkrementaldrehgeber, Quadraturencoder, Drehencoder, Drehimpulsgeber 
genannt) schien mir dazu bestens geeignet.

Daraus ist das folgende AVR8-Assemblerprogramm für einen ATmega88PA 
im Auslieferungszustand enstanden, das mittels ATMEL STUDIO 7 
programmiert wurde.

Es verwendent lediglich vier Vergleiche um die Handencoderdrehrichtung 
zu erkennen. Arbeit also nicht mit der üblichen LUT programmierweise.

Alle weiteren Informationen in der Header.inc & Hardware.inc

Als Vorlagen bzw. wie man so etwas überhaupt realisieren kann diente mir 
:

https://www.mikrocontroller.net/articles/Drehgeber

und Vorallem Hannes Lux sein Programmausschnitt

Beitrag "Re: Hilfe zu Drehencoder-Auswertung nach Wiki"


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Ach, habe vergessen zu erwähnen, das der Handencoder von *Panasonic EVEQ 
DBRL416B*
beim nach links drehen, also gegen den Uhrzeigersinn ( C.C.W ) in einer 
oder einigen Raststellungen ziemlich heftig prellt.
Die B-Spur schaltet nämlich direkt an den Rastungen und dies führt in 
einigen Raststellungen zum sofortigen Schalten bei minimalem Drehwinkel.

Man kann das Programm auch sehr gut zum Testen von Handencodern 
benutzen.
In jeder Raststellung dreht man mehrmals eine Rastung vor und wieder 
zurück und sieht sich dabei an was die LEDs an PortB machen.

Der Encoder ist wie im DB gezeigt beschaltet.


Bernd_Stein

[Falk B. (falk)]

Bernd S. schrieb:
> Ach, habe vergessen zu erwähnen, das der Handencoder von *Panasonic EVEQ
> DBRL416B*
> beim nach links drehen, also gegen den Uhrzeigersinn ( C.C.W ) in einer
> oder einigen Raststellungen ziemlich heftig prellt.

Dagegen hilft die passende Auswertung.

https://www.mikrocontroller.net/articles/Drehgeber#Dekoder_f.C3.BCr_Drehgeber_mit_wackeligen_Rastpunkten

Geht auch in Assembler.

[Falk B. (falk)]

Hmmm, 12 Warnung sind nicht so dolle für so ein kleines Projekt.

Severity  Code  Description  Project  File  Line
Warning    .def: 'YH' redefinition (r29->r29)  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  67
Warning    .def: 'XH' redefinition (r27->r27)  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  65
Warning    .def: 'XL' redefinition (r26->r26)  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  64
Warning    .def: 'YL' redefinition (r28->r28)  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  66
Warning    .def: 'ZH' redefinition (r31->r31)  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  69
Warning    .def: 'ZL' redefinition (r30->r30)  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  68
Warning    Register r26 already defined by the .DEF directive  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  64
Warning    Register r27 already defined by the .DEF directive  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  65
Warning    Register r28 already defined by the .DEF directive  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  66
Warning    Register r29 already defined by the .DEF directive  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  67
Warning    Register r30 already defined by the .DEF directive  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  68
Warning    Register r31 already defined by the .DEF directive  Einfache Motorsteuerung  C:\Users\Brunner.000\Downloads\Einfache Motorsteuerung\Header.inc  69

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Falk B. schrieb:
> Dagegen hilft die passende Auswertung.
>
> 
https://www.mikrocontroller.net/articles/Drehgeber#Dekoder_f.C3.BCr_Drehgeber_mit_wackeligen_Rastpunkten
>
> Geht auch in Assembler.
>
Dann mach mal ;-)
Wie bereits erwähnt kenne ich den Artikel.

>
> Hmmm, 12 Warnung sind nicht so dolle für so ein kleines Projekt.
>
Hmm, das hätte ich jetzt nicht von dir erwartet, dass du nicht erkennst 
das diese Warnungen lediglich kommen, weil die X,Y und Z-Register die 
wahrscheinlich in der .def schon so benannt worden sind, ich ebenfalls 
so benannt habe ( r26 -> xl, r27 -> xh usw. ).


Bernd_Stein

[c-hater (Gast)]

Bernd S. schrieb:

> Wie bereits erwähnt kenne ich den Artikel.

Warum nutzt du sinnvolle Konzepte nicht, wenn du sie schon kennst?

> Hmm, das hätte ich jetzt nicht von dir erwartet, dass du nicht erkennst
> das diese Warnungen lediglich kommen, weil die X,Y und Z-Register die
> wahrscheinlich in der .def schon so benannt worden sind, ich ebenfalls
> so benannt habe ( r26 -> xl, r27 -> xh usw. ).

Natürlich hat er das verstanden.

Was du allerdings nicht verstehst: Warnungen sind da, um zu Warnen. Wenn 
du die Warnung geprüft hast und dir sicher bist, das das so in Ordnung 
geht, dann sorge dafür, dass die Warnung verschwindet, damit erstens 
niemand davon unnötig irritiert wird und zweitens neue Warnungen im Zuge 
von Codeänderungen oder -erweiterungen nicht in der Flut alter (bereits 
als unberechtigt verifizierter) Warnungen untergehen.

So geht Software-Entwicklung. Auch (und gerade) in Assembler. Da gibt es 
nämlich weiss Gott genug Fallstricke und wenig Möglichkeiten für den 
Assembler, dem Programmierer zu helfen. Da nutzt man dann wenigstens 
konsequent die, die es gibt.

Das Zauberwort in diesem Fall heisst: .undef

[Uhu U. (uhu)]

c-hater schrieb:
> Auch (und gerade) in Assembler.

Dem echt harten Hund sind Warnungen schnuppe. .undef ist was für 
Weicheier ;-)

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

c-hater schrieb:
> Das Zauberwort in diesem Fall heisst: .undef
>
Das nenne ich doch mal sinnvolle Kritik.
Gefällt mir jetzt auch besser wenn keine Warnungen da sind.

>
> Warum nutzt du sinnvolle Konzepte nicht, wenn du sie schon kennst?
>
Würd mich ja interessieren, ob dies wirklich sinnvoller ist und mit 
meiner Breadboardschaltung testen, aber es gibt ja kein fertiges 
AVR8ASM-Programm und erst recht nicht für den ATmega88.

Übrigens es ist von Vorteil an der L298N-Platine, bei der ich beide 
Ausgänge und Signaleingänge parallel verschaltet habe, den EN-Eingang 
mit einem Pulldown-Widerstand zu versehen, da es beim Einschalten der 
Versorgungsspannung sonst für einen Augenblick zu einem ungewolltem 
Drehen des Motors kommen kann.

Ich habe auch die IB_2-Platine mit dem BTS7960, dort wäre es von 
Vorteil den High-Side-Zweig beim Bremsen zu nutzen da dieser besser 
leitet, aber Programmtechnisch ist dies aufwändiger.

Beitrag "Re: Motorsteuerung mit L298N und Attiny"

Beitrag "BTS7960B_IBT_2 Chinaplatine"


Bernd_Stein

[c-hater (Gast)]

Bernd S. schrieb:

> Würd mich ja interessieren, ob dies wirklich sinnvoller ist

Ist es natürlich, das sagen schon die Gesetze der Logik. Wenn eine 
Hardware einen systemimmanenten Mechanismus anbietet, um mögliche Fehler 
zu unterdrücken, dann nutzt man den natürlich.

> und mit
> meiner Breadboardschaltung testen, aber es gibt ja kein fertiges
> AVR8ASM-Programm und erst recht nicht für den ATmega88.

So what? Du bist Programmierer.

Übrigens muss man den Mechanismus nicht sklavisch so abbilden, wie in 
der Vorlage. Für einen einzelnen schnellen Encoder wäre das suboptimal. 
Die Vorlage nutzt den Mechanismus effizent für mehrere, relativ langsame 
Encoder.

Der Kern ist also, den Mechanismus zu verstehen. Die Implementierung 
kann dann ganz erheblich von der Vorlage abweichen. Sogar so sehr, das 
das gemeinsame Konzept kaum noch erkennbar ist.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

c-hater schrieb:
> So what? Du bist Programmierer.
>
Nein - vielleicht du.

Ich merke schon, jetzt wird wieder nur rumgequatscht aber nicht konkret 
daraufhin gearbeitet eine AVR8-Assemblerversion aus dem µC-Artikel zum 
Drehgeber zu erstellen, damit ich beide Versionen mal austesten kann.

In meinen Theorien klappen die Mechanismen auch immer wunderbar.
Wenn ihr also nur rumquatschen wollt, dann mach ich dabei nicht mehr 
mit.


Bernd_Stein

[Karl M. (Gast)]

Hallo Bernd S.,

für LunaAVR verwenden wir schon seit Anfang an, nur eine Assembler 
Version.
Da das interne FrameWork auf Assembler implementierte Bibliotheken 
(Interface und Module) basiert.

https://avr.myluna.de/doku.php?id=de:download

Wenn es Dich interessiert, schau mal in das Interface "KeyMgr", eine 
kurze Beschreibung steht im Interface auch direkt drin.

Anbei einige Bilder dort hin.

Hier ist ein Beispielcode, man kann sich auch die erzeugte 
Assemblerausgabe in der *.s Datei ansehen.

'---------------------------------------
' KeyManager Samble Code
' 2019-08-06
'---------------------------------------

'---------------------------------------
' System Settings
'---------------------------------------
const F_CPU = 8000000
avr.device   = atmega328p
avr.clock  = avr.F_CPU
avr.stack  = 42

'---------------------------------------
' Macros
'---------------------------------------
#define BV(n)  as (1<<(n))
#define NBV(n)  as (not BV(n))

#macro BEGIN_ATOMIC
asm
xIn _TMP0,SREG
cli
endasm
#endmacro

#macro END_ATOMIC
asm
xOut   SREG,_TMP0
endasm
#endmacro

'---------------------------------------
' Library
'---------------------------------------
#library "Library/KeyMgr.interface"
#library "Library/Wdt.interface"

part I/O Ports
// Tasten
#define SW1    as PORTB.0
#define SW2    as PORTB.1
#define KEY_PORT  as PORTB

const SW1_BIT    = 0
const SW1_MASK    = BV(SW1_BIT)
const SW2_BIT    = 1
const SW2_MASK    = BV(SW2_BIT)
endpart

'---------------------------------------
' Init
'---------------------------------------
part I/O Ports
// Tasten
// nur der Vollständigkeit halber.
SW1.mode = input, pullup
SW2.mode = input, pullup
endpart

part KeyManager
const KEYMGR_CYCLE_TIME = 16 ' ms, see WDT settings

const KEYMGR_MASK    = (SW1_MASK or SW2_MASK)
const KEYMGR_REPEAT_MASK = 0 ' no key with repeat function

KeyMgr.RepeatTime    = word(300/ KEYMGR_CYCLE_TIME +.5)
KeyMgr.LongPressTime = word(800/ KEYMGR_CYCLE_TIME +.5)
KeyMgr.InterruptMode = 1
KeyMgr.Init(KEY_PORT, KEYMGR_MASK, KEYMGR_REPEAT_MASK, 0) ' run on timer interrupt

WDT_Init()
endpart

avr.Interrupts.Enable()

do

// Taster gedrückt
if KeyMgr.KeyPress(SW1_MASK) then
' ...
endif

if KeyMgr.KeyPress(SW2_MASK) then
' ...
endif

// Taster losgelassen
if KeyMgr.KeyRelease(SW1_MASK) then
' nur ein Beispiel
endif

if KeyMgr.KeyRelease(SW2_MASK) then
' nur ein Beispiel
endif


loop

' Main Sub-Functions

procedure WDT_Init()
WDT.isr = WDT_vect
WDT.Clock = 16ms
WDT.mode = Interrupt
endproc

isr WDT_vect fastauto
avr.KeyMgr.Debounce() ' <-- call KeyManager Debounce
endisr

[c-hater (Gast)]

Karl M. schrieb:

> Wenn es Dich interessiert, schau mal in das Interface "KeyMgr", eine
> kurze Beschreibung steht im Interface auch direkt drin.

Das ist völlig ungeeignet, denn es nutzt gerade nicht die Besonderheit 
von Rotationsencodern. Das ist für Taster. Sagt ja auch schon allein der 
Name...

Kann mann allenfalls für den "Drücker" eines handbetätigten Encoders 
nutzen.

[Karl M. (Gast)]

c-hater schrieb:
> Karl M. schrieb:
>
>> Wenn es Dich interessiert, schau mal in das Interface "KeyMgr", eine
>> kurze Beschreibung steht im Interface auch direkt drin.
>
> Das ist völlig ungeeignet, denn es nutzt gerade nicht die Besonderheit
> von Rotationsencodern. Das ist für Taster. Sagt ja auch schon allein der
> Name...
>
> Kann mann allenfalls für den "Drücker" eines handbetätigten Encoders
> nutzen.

Danke,

korrekt, da habe ich mich vertan.

Für Drehencoder findet man auch das entsprechende 
RotaryEncoder.interface im Datenbestand.

Einen 4-fach Version gibt es auch noch auf meiner Festplatte.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Weil ich doch so gerne mit dem ATmega88PA arbeite und meine 
Englischkenntnisse miserabel sind :

https://www-user.tu-chemnitz.de/~heha/viewchm.php/hs/ATmegaX8.chm/

Beitrag "Datenblatt (ATmega48, ATmega88, ATmega168, ATmega328) auf deutsch"


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Da es sehr wenige Open Source Projekte gibt, die eine PID-Regelung in 
AVR-Assembler vorstellen, habe ich versucht, dass Wenige, das es hierzu 
gibt mal zu analysieren, um zu verstehen wie so etwas funktioniert.

Die für mich beste Quelle ist :

https://www.loetstelle.net/projekte/tiny13pid/tiny13pid.html


Ich habe die Sache so abgewandelt, dass ein 1µF Kondensator anstelle der 
Akkus benutzt wird ( siehe Schaltplan ). Wichtig ist dass der BF245 
wirklich ein B-Typ ist.

Da der BF245 nicht mehr Produziert wird, weiß ich nicht, ob mit den 
Alternativen J111, J112, J113 und PN4393 dass selbe Resultat erreicht 
wird.


https://www.elektronik-kompendium.de/public/schaerer/anasw1.htm


In der Firmware habe ich die mit dem Breakpoint markierten Stellen 
eingefügt, damit bei einem Sollwert von Null, der sonst übliche Spike 
ausbleibt.

Der 220 Ohm Widerstandstrimmer ist auf 0,992xV eingestellt ( ADC2 ).

CH1 ( Gelb ) zeigt die Spannung am Kondensator.
CH2 ( Cyan ) zeigt die Spannung an PB0 bzw. dem OC0A-Ausgang ( Fast PWM 
Mode ).

Ich verstehe nicht, warum es kein nachregeln gibt, obwohl die 
Kondensatorspannung sinkt. Erst bei ca. 240mV wird wieder geregelt.



Der nachfolgende Link ist mir zu kompliziert :

Beitrag "PID-Regler für Atmega8"


Bernd_Stein

[c-hater (Gast)]

Bernd S. schrieb:

> https://www.loetstelle.net/projekte/tiny13pid/tiny13pid.html

Das ist ziemlicher Mist. Alle drei Koeffizienten sind fix und gleich 8. 
Außerdem kein Schutz gegen WindUp für den Integralteil.

Unbrauchbar, jedenfalls für den allgemeinen Einsatz. Und es würde mich 
sehr wundern, wenn es für die konkrete Anwendung eine auch nur 
zufriedenstellende Lösung wäre. Das wäre reiner Zufall.

Bei genauerer Betrachtung (hab' ich jetzt keine Lust zu) wird es wohl 
darauf hinauslaufen, dass da in Wirklichkeit ein leicht "wackliger" 
Zweipunktregler läuft. Sowas kann man allerdings viel einfacher 
programmieren...

> Der nachfolgende Link ist mir zu kompliziert :
>
> Beitrag "PID-Regler für Atmega8"

Ist aber vom Ansatz her trotzdem weit besser als der Mist von oben. Es 
gibt immerhin konfigurierbare Koeffizienten. Anti-Windup allerdings 
ebenfalls nicht. Und: die Implementierung ist schlicht fehlerhaft. Die 
Fehler haben mit dem Algorithmus selber überhaupt nix zu tun, das sind 
einfach nur Flüchtigkeitsfehler. Die passieren auch Profis. Die sind 
dann allerdings in der Lage, die Fehler selbstständig zu finden und zu 
fixen...

Nach >10 Jahren Asm-Programmierung solltest du allerdings definitiv so 
weit sein, auch wenn du das nicht beruflich machst...

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

c-hater schrieb:
> Bernd S. schrieb:
>
>> https://www.loetstelle.net/projekte/tiny13pid/tiny13pid.html
>
> Das ist ziemlicher Mist. Alle drei Koeffizienten sind fix und gleich 8.
> Außerdem kein Schutz gegen WindUp für den Integralteil.
>
Zumindest mal ein Ansatz wo gezeigt wird, wie so etwas in AVR8ASM 
umzusetzen ist, ohne gleich hoch kompliziert zu sein und dennoch eine 
"funktionierende" Anwendung.

Das Programm zum ASURO ist ja auch nie fertig gestellt worden.
Zumindest nicht vom Thread-Eröffner. Wie überhaupt 99% der Threads hier 
nur Datenleichen sind, wo kein Projekt abgeschlossen wurde und mit 
dessen Informationen man sich die Zeit vertreiben kann, wie auch jetzt 
wieder mit deinem Posting.

Da ist die oben verlinkte Seite schonmal 100 mal mehr Wert als alles was 
ich hier zu PID-Reglern in AVR8ASM gelesen habe.


c-hater schrieb:
> Bei genauerer Betrachtung (hab' ich jetzt keine Lust zu) wird es wohl
> darauf hinauslaufen, dass da in Wirklichkeit ein leicht "wackliger"
> Zweipunktregler läuft. Sowas kann man allerdings viel einfacher
> programmieren...
>
Da sich die PWM-Pulsbreite verändert ( siehe DSO-Screenshots ), denke 
ich nicht dass es sich im weitesten Sinne um einen Zweipunktregler 
handeln kann.


Bernd_Stein

[c-hater (Gast)]

Bernd S. schrieb:

> Zumindest mal ein Ansatz wo gezeigt wird, wie so etwas in AVR8ASM
> umzusetzen ist, ohne gleich hoch kompliziert zu sein

Der Lösungsansatz aus deinem zweiten Link ist auch nicht 
"hochkompliziert".
Er stellt vielmehr das absolute Minimum für einen einigermaßen 
tauglichen PID-Regler dar. Wenn dir das schon zu kompliziert ist, ist 
Assembler einfach nicht die richtige Sprache für dich. Dann musst du auf 
Sprachen zurückgreifen, die die zwingend nötige (wenn auch recht 
triviale) Mathematik auf höherer Ebene abstrahieren.

Trivial ist übrigens nur die Implementierung des Reglers. Die 
Modellierung hingegen ist es nicht. Das gilt vollkommen unabhängig von 
der zur Implementierung verwendeten Sprache.

> Da sich die PWM-Pulsbreite verändert ( siehe DSO-Screenshots ), denke
> ich nicht dass es sich im weitesten Sinne um einen Zweipunktregler
> handeln kann.

Was zeigt, dass du auch keine Ahnung von der Interpretation von 
Messergebnissen hast. Ich sehe da genau zwei vorkommende Werte für die 
PWM-Pulsbreite. Das ist aber nun ziemlich genau das, was man von einem 
Zweipunktregler erwarten könnte...

> wo kein Projekt abgeschlossen wurde und mit
> dessen Informationen man sich die Zeit vertreiben kann, wie auch jetzt
> wieder mit deinem Posting.

Heul doch. Willst du programmieren oder Copy&Paste betreiben? Falls 
letzteres: lass' ab von Assembler (das überfordert dich offensichtlich 
massiv) und mach einen auf Arduino. Das machen die anderen Arduidioten 
auch und kriegen damit wenigstens das eine oder andere tatsächlich 
gebacken. Natürlich immer fernab des Optimums, aber es läuft halt 
wenigstens. Irgendwie...

Der Arduino-Code hat in etwa dieselbe Qualität wie deine präferierte 
Lösung eines PID-Reglers. Es scheint irgendwie zu funktionieren, 
allerdings aus "unklaren Gründen" nicht wirklich gut...

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

c-hater schrieb:
> Was zeigt, dass du auch keine Ahnung von der Interpretation von
> Messergebnissen hast. Ich sehe da genau zwei vorkommende Werte für die
> PWM-Pulsbreite. Das ist aber nun ziemlich genau das, was man von einem
> Zweipunktregler erwarten könnte...
>
Tja, dafür hab ich ja die Screenshots hochgeladen, damit jeder diese 
interpretieren kann und wenn du da _nur_ zwei verschiedene Pulsweiten 
siehst, dann ist das so für dich. Der Screenshot bleibt ja 
glücklicherweise davon unberührt und jeder kann sich zu unseren 
Äußerungen hierzu sein eigenes Bild machen.

In diesem Sinne danke für deine Sichtweise, aber auch hier kommen wir 
zwei auf keinen gemeinsamen Nenner.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Weil ich doch so gerne mit dem ATmega88PA arbeite und meine
> Englischkenntnisse miserabel sind :
>
> https://www-user.tu-chemnitz.de/~heha/viewchm.php/hs/ATmegaX8.chm/
>
> Beitrag "Datenblatt (ATmega48, ATmega88, ATmega168, ATmega328) auf
> deutsch"
>
Was muss ich tun um das Ganze auch Offline nutzen zu können?

Mit dem einfachen herunterladen wie Thread geschrieben geht es nicht !


Es wäre sehr, sehr schade, wenn die Seite mal nicht mehr existiert und 
man diese wirklich hervorragende Arbeit nicht mehr nutzen kann.

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hier mal eine ganz simple Auswertung eines Drehencoders :

https://www.youtube.com/watch?v=bBhbynj6NYM


Bernd_Stein

[Thomas F. (igel)]

Bernd S. schrieb:
> Hier mal eine ganz simple Auswertung eines Drehencoders :
> https://www.youtube.com/watch?v=bBhbynj6NYM

Aua Autsch: Entprellen mit zwei 10nF Kondensatoren und Auswertung per 
Interrupt-Eingang.

Man hat dir doch erst kürzlich erklärt dass das Unsinn ist. Ich mag es 
jetzt nicht raussuchen.

[Carsten-Peter C. (carsten-p)]

Hallo Bernd, mach das einfach so, wie es für deine Anwendung optimal 
ist. Es gibt viele Möglichkeiten der Entprellung und Auswertung und kein 
„Das macht man so und nicht anders“. Alle haben Vor- und Nachteile. Das 
über Interrupt’s zu machen ist sicher eine gute Option.
Gruß
Carsten

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Carsten-Peter C. schrieb:
> Das
> über Interrupt’s zu machen ist sicher eine gute Option.
>
Demnächst will ich einen Motor-Encoder testen, da ist per Interrupt 
Pflicht.


Bernd_Stein

[Falk B. (falk)]

Carsten-Peter C. schrieb:
> Hallo Bernd, mach das einfach so, wie es für deine Anwendung optimal
> ist.

Ist es aber nicht.

> Es gibt viele Möglichkeiten der Entprellung und Auswertung und kein
> „Das macht man so und nicht anders“.

Doch, das gibt es. Ein "alles ist richtig" ist einfach nur Unfug.

> Alle haben Vor- und Nachteile. Das
> über Interrupt’s zu machen ist sicher eine gute Option.

Nur, wenn es ein Timer-Interrupt ist und nicht ein flankengesteuerter!
Das wurde schon tausendfach diskutiert und auch NACHGEWIESEN!
Aber daß unser Bernd immer alles "etwas anders" machen muss, ist 
weitläufig bekannt. Ebenso wie seine Lernresistenz.

[Falk B. (falk)]

https://www.youtube.com/watch?v=bBhbynj6NYM#t=6m30s

Quark. Mal angesehen davon, daß 100k Pull-Ups bissel viel sind, darf 
beim Wechsel von B der Kanal A NICHTS machen! Auch kein Übersprechen! 
Wenn doch, ist der Drehgeber im Eimer! Und da tut man auch nicht warten! 
Sondern mittels Timer-Interrupt in gleichmäßigen Abständen 
abtasten. Siehe Drehgeber. Tausendfach diskutiert, tausendfach 
bewiesen. Trotzdem kommen immer wieder Schlaumeier, die das Rad eckig 
erfinden wollen. Viel Spaß dabei!

https://www.youtube.com/watch?v=bBhbynj6NYM#t=8m

Jaja, einfach 10nF gegen den Schaltkontakt. OMG!

NEIN! Da gehört ein Längswiderstand rein, dann ist es nämlich auch ein 
RICHTIGER RC-Tiefpass der in BEIDE Richtungen wirkt (steigende und 
fallende Flanke) und der Kontakt wird nicht gebrutzelt!

https://www.mikrocontroller.net/articles/Entprellung#Einfacher_Taster

So und nicht anders!

[Carsten-Peter C. (carsten-p)]

Moin,
ich bastel gerade an einer Motorsteuerung mit einen ATMega 1284P. Ich 
möchte ein Poti nutzen und ev. zusätzlich einen Drehgeber. Es ist kein 
freier Timer vorhanden. Eine zyklische Abfrage über einen Timer per ISR 
würde eine ständige Unterbrechung und somit in der Zeit keine weiteren 
Interupts erlauben. Sowas kann ich wirklich nicht gebrauchen. Eine 
Abfrage im Hauptprogramm geht nicht, weil die einzelnen Durchläufe 
zeitlich sehr unterschiedlich sein können. Da ich eigentlich nur den 
Port A nutzen kann, kommt nur ein PCINT in Frage. Ich würde zunächst nur 
Signal A über das Register PCMSK0 selektieren und auf eine Änderung 
warten. In der ISR würde ich dann den Pin sperren und auf den Pin vom 
Signal B schalten. Das sollte sehr schnell gehen und keine Entprellung 
brauchen, solange nicht zwei Pegelwechsel gleichzeitig wechseln. Soweit 
zum Standardprogramm.
Gruß
Carsten

[Falk B. (falk)]

Carsten-Peter C. schrieb:
> Moin,
> ich bastel gerade an einer Motorsteuerung mit einen ATMega 1284P. Ich
> möchte ein Poti nutzen und ev. zusätzlich einen Drehgeber. Es ist kein
> freier Timer vorhanden.

Wollen wir wetten, daß das nicht stimmt? Das bissel Abfrage des 
Drehgebers kann man LOCKER in andere Timer einbauen.

> Eine zyklische Abfrage über einen Timer per ISR
> würde eine ständige Unterbrechung und somit in der Zeit keine weiteren
> Interupts erlauben.

Unsinn!

> Sowas kann ich wirklich nicht gebrauchen.

Du hast das Thema Interrupt nicht verstanden.

> brauchen, solange nicht zwei Pegelwechsel gleichzeitig wechseln. Soweit
> zum Standardprogramm.

Unfug^3. Aber mach mal.

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:
> Wollen wir wetten, daß das nicht stimmt? Das bissel Abfrage des
> Drehgebers kann man LOCKER in andere Timer einbauen.

Solange du nicht die Drehgeschwindigkeit des Teils messen willst, 
sondern nur den Winkel, kannst du mit ein paar 10ms Zykluszeit pollen. 
Und das muss auch nicht zwingend äquidistant sein. Das wir deine 
Mainloop doch noch hergeben, oder?

[Carsten-Peter C. (carsten-p)]

Falk B. schrieb:
> Wollen wir wetten, daß das nicht stimmt? Das bissel Abfrage des
> Drehgebers kann man LOCKER in andere Timer einbauen.

Moin,
also es handelt sich u. A. um eine Ansteuerung eines BergerLahr 5-Phasen 
Schrittmotors. Der braucht 5 PWM Signale in meiner Schaltung. Dafür 
nutze OCR0A+B, OCR2A+B und OCR3A sowie den Timer 1 für die 
Geschwindigkeit des Motors. Damit sind alle Timer genutzt. Der Motor 
arbeitet im Halbschrittbetrieb, wobei jeder Halbschritt in bis zu 255 
Mikroschritte unterteilt wird. Es werden 4 der 5 Wicklungen mit jeweils 
bis zu 2,7A bei bis zu 80 V gespeist. Das Programm ist in Assembler 
geschrieben. Das funktioniert auch soweit recht gut. Ein periodischer 
Int für den Drehgeber würde die Laufruhe negativ beeinflussen. Mit dem 
Poti (und Drehgeber) sowie über die serielle Schnittstelle kann man die 
Geschwindigkeit oder die Position des Motors einstellen. Manchmal wird 
in der Mainloop die genaue Position oder der Winkel berechnet. 4 Byte 
von Hex nach Dez oder umgekehrt zu berechnen und auszugeben dauert eben.
Eigentlich ist es mir egal, ob Du das glaubst, oder eben nicht.
Gruß
Carsten

[Falk B. (falk)]

Carsten-Peter C. schrieb:
> Moin,
> also es handelt sich u. A. um eine Ansteuerung eines BergerLahr 5-Phasen
> Schrittmotors. Der braucht 5 PWM Signale in meiner Schaltung. Dafür
> nutze OCR0A+B, OCR2A+B und OCR3A sowie den Timer 1 für die
> Geschwindigkeit des Motors. Damit sind alle Timer genutzt.

Ja und? Was schrieb ich denn wohl?

> Der Motor
> arbeitet im Halbschrittbetrieb, wobei jeder Halbschritt in bis zu 255
> Mikroschritte unterteilt wird. Es werden 4 der 5 Wicklungen mit jeweils
> bis zu 2,7A bei bis zu 80 V gespeist. Das Programm ist in Assembler
> geschrieben. Das funktioniert auch soweit recht gut. Ein periodischer
> Int für den Drehgeber würde die Laufruhe negativ beeinflussen.

;-) Nur wenn man's nicht kann!

> Mit dem
> Poti (und Drehgeber) sowie über die serielle Schnittstelle kann man die
> Geschwindigkeit oder die Position des Motors einstellen. Manchmal wird
> in der Mainloop die genaue Position oder der Winkel berechnet. 4 Byte
> von Hex nach Dez oder umgekehrt zu berechnen und auszugeben dauert eben.

Und ist vollkommen egal, wenn man weiß was man tut und die 
zeitkritischen Ding in der richtigen Art und Weise im Interrupt erledigt 
und den Rest passen puffert.

> Eigentlich ist es mir egal, ob Du das glaubst, oder eben nicht.

Umso besser! Du wärst aber nicht der Erste, der meint, eine 
Herkulesaufgabe zu bewältigen nur um dann festzustellen, daß das Konzept 
bestenfalls funktioniert, aber nicht gut ist und daß man es DEUTLICH 
besser machen kann. Das wurde in diesem Forum schon recht oft 
nachgewiesen. Kostprobe gefällig?

Der Zweifler

Beitrag "Re: Arduino Nano, SD Card, PCM"

Der Beweis

Beitrag "Re: Arduino Nano, SD Card, PCM"

[Thomas F. (igel)]

Carsten-Peter C. schrieb:
> ich bastel gerade an einer Motorsteuerung mit einen ATMega 1284P. Ich
> möchte ein Poti nutzen und ev. zusätzlich einen Drehgeber. Es ist kein
> freier Timer vorhanden.

Warum nimmst du dann keinen AtXmega128A3. Der hat massenhaft Timer, 
Drehgeber-Eingänge in Hardware, doppelte Geschwindigkeit, etc.

[Carsten-Peter C. (carsten-p)]

Thomas F. schrieb:
> Warum nimmst du dann keinen AtXmega128A3. Der hat massenhaft Timer,
> Drehgeber-Eingänge in Hardware, doppelte Geschwindigkeit, etc.

Moin,
1. Den hatte ich noch liegen.
2. Der hat ein bastelfreundliches Gehäuse, das ich direkt zum Testen in 
mein altes Pollin EV-Board stecken kann.
3. Der hat genügend Timer und ausreichend SRAM für den seriellen Puffer.
4. Programmteile kann ich einfach von einem anderen Projekt übernehmen 
(Beitrag "Re: Zeigt her eure Kunstwerke (2021)").
5. Den kenne ich, weil ich damit einiges gemacht habe.
Warum ich für den Drehgeber keinen Timer möchte, habe ich bereits 
versucht zu erklären. Die Auswertung des Drehgebers sollte eigentlich 
kein Problem sein und so nebenbei laufen.
Gruß
Carsten

[Falk B. (falk)]

Carsten-Peter C. schrieb:
> 5. Den kenne ich, weil ich damit einiges gemacht habe.
> Warum ich für den Drehgeber keinen Timer möchte, habe ich bereits
> versucht zu erklären. Die Auswertung des Drehgebers sollte eigentlich
> kein Problem sein und so nebenbei laufen.

Das tut sie auch, wenn man weiß wie es geht. Aber du bist ja, ähhh, 
anders . . .

[Wilhelm M. (wimalopaan)]

Carsten-Peter C. schrieb:
> Warum ich für den Drehgeber keinen Timer möchte, habe ich bereits
> versucht zu erklären.

Hast Du den Kommentar zum sampling des encoders gelesen?

[Michael B. (laberkopp)]

Bernd S. schrieb:
> Hier mal eine ganz simple Auswertung eines Drehencoders :

Dreck, 11 Minuten mit durchaus schöner Darstellung wie Drehgeber prellen 
und dann eine Interruptauswertung.

Bernd S. schrieb:
> Demnächst will ich einen Motor-Encoder testen, da ist per Interrupt
> Pflicht.

Was genau hast du nicht verstanden. Alles ?

Ja, man kann Drehgeber auch mit Interrupts auswerten wenn man ein paar 
Millisekunden (Prellzeit) nach dem Interrupt sampelt. Aber man muss 
dabei Interrupts sperren und wieder freigeben, sonst kann man von 
hunderten Prellimpulsen überrannt werden, das erfordert einige sonst 
überflüssige zusätzliche Programmzeilen, und man wird damit weder 
Impulse durch vibrierende Drehachsen noch Störungen durch mangelnden 
Kontakt der Schleifer auf der Kontaktbahn los.

Sprich: es funktioniert nicht, nur in der Theorie unter unvollständig 
simulierter Realität, in der Praxis bekommt man Fehlzählungen.

Lediglich des zyklische Pollen verzählt sich auch in der üblen Realität 
nicht.

Aber wer, der sein Wissen auf Teletubbiniveau erwirbt, will das schon 
wissen.

https://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29