Kommentare zu "Modul zur Umkehrklappensteuerung"

[Muehi]

Kommentare, Wünsche, Verbesserungsvorschläge zu [thread=33442]diesem Baubericht[/thread]...

[Guest TeKieler]

Moin!

Hört sich alles schon sehr vernünftig an! Cooles Projekt!

Mit solchen Spielereien bekommt man richtig Lust, das nächste Projekt mit Jets auszurüsten!

 

Aber dein µC ist doch recht überdimensioniert! Der ATtiny13 schafft das auch, mit nur 8 Beinchen

 

Ich hatte auch schon überlegt, die beiden Fahrmotoren meines S100 auszulesen und bei Vollgas die Stauruder automatisch zu spreizen.

Da es aber immer sehr viel Eindruck schindet, wenn man den Zuschauern den Unterschied zeigen kann, hab ich es erstmal gelassen.

 

Programmierst du in C?

 

Ole

[Muehi]

Moin,

 

der Tiny13 hat aber nur einen 8Bit Timer, zum jetztigen Zeitpunkt hab ich noch keine Idee, ob das ausreicht um die Impulslänge auszuwerten und die beiden Signale zu generieren. Prinzipiell solltes gehen, aber ob das dann hinreichend genau wird... Außerdem war der ATMega8 grade übrig, hätte sonst auch noch nen ATMega8515 nehmen können mit 40 Pins.

 

Programmieren tu ich in Assembler mittels AVR-Studio.

[hoppppla]

Hallo,

interessantes Projekt

der Tiny13 hat aber nur einen 8Bit Timer, zum jetztigen Zeitpunkt hab ich noch keine Idee, ob das ausreicht um die Impulslänge auszuwerten und die beiden Signale zu generieren.

Hm, prinzipiell müßte das gehen, da Du die Signale ja nicht gleichzeitig erzeugen mußt. Mit dem 8-Bit-Timer kommst Du im einfachen Fall auf einen Auflösung von 10µs, d.h. 100 Schritte von voll zurück bis voll voraus. Wenn das reicht, sollte das ganze kein Problem sein. Ansonsten wirds aufwendiger

eleganter und genauer ist es aber definitiv mit nem 16-Bit-Timer und nem Quarz.

Programmieren tu ich in Assembler mittels AVR-Studio.

Hm, schade, mit Assembler kann ich leider nicht so viel anfangen. Bei interesse könnte ich aber ein bisschen C-Code zur Verfügung stellen.

 

viele Grüße,

Hermann

[Muehi]

Moin,

 

ausreichen tun die 100 Schritte wahrscheinlich schon, auf feinfühlige Regler kann man dann aber getrost verzichten

 

Deswegen habe ich nun noch ne andere Variante auserkoren, nach Datenblattwälzen was prinzipiell alles möglich ist:

16Bit Timer, maximaler Wert auf 20.000, und mittels Output-Compare werden die beiden Ausgangsimpulse erzeugt.

Zur Impulslängenmessung des Eingangs würde ich dann einen externen Interrupt verwenden, der auf fallende und steigende Flanke reagiert. Jeweils den Zählerstand gemerkt, beide subtrahieren, fertig. Den Fall, dass der Zähler zwischendurch überläuft, kann man auch abfangen.

 

Das ganze mit ner Taktfrequenz von 1MHz, nem Vorteiler von 1, ergibt genau 1µs Taktzeit und damit 1000 Schritte zwischen Minimum und Maximum.

 

Und wegen der 16 Biterei werd ich mir den Umstieg auf C durchn Kopf gehen lassen, da ist das ganze etwas einfacher.

[hoppppla]

Hallo,

Deswegen habe ich nun noch ne andere Variante auserkoren, nach Datenblattwälzen was prinzipiell alles möglich ist:

16Bit Timer, maximaler Wert auf 20.000, und mittels Output-Compare werden die beiden Ausgangsimpulse erzeugt.

jup, damit ist es relativ genau. Wobei sich vl. trotzdem anbietet, die beiden Signale nacheinander mit einem Compare-Int auszugeben, da man dann die Auswertung des Eingangssignals gleich mit der Input-Capture-Einheit machen kann

 

Zur Impulslängenmessung des Eingangs würde ich dann einen externen Interrupt verwenden, der auf fallende und steigende Flanke reagiert. Jeweils den Zählerstand gemerkt, beide subtrahieren, fertig. Den Fall, dass der Zähler zwischendurch überläuft, kann man auch abfangen.

s.o. hier bietet sich an, Input-Capture mal anzuschauen, das ist genau für sowas gmacht

 

Das ganze mit ner Taktfrequenz von 1MHz, nem Vorteiler von 1, ergibt genau 1µs Taktzeit und damit 1000 Schritte zwischen Minimum und Maximum.

hm, da würd ich dann aber eher 8Mhz und n Vorteiler von 8 vorschlagen, dann ist ein bisschen mehr Rechenleistung über, und man kann im Notfall auch den internen RC-Osszilator verwenden.

 

Und wegen der 16 Biterei werd ich mir den Umstieg auf C durchn Kopf gehen lassen, da ist das ganze etwas einfacher.

ja, das lohnt sich in meinen Augen durchaus, man verliert weniger schnell den Überblick.

 

viele Grüße,

Hermann

[Muehi]

Moin,

 

Input-Capture hab ich mir schon mal überlegt und angeschaut. Als Problem seh ich dabei nur, dass mir dabei automatisch ins ICRx Register geschrieben wird, mit dem ich im CTC-Modus den maximalen Zählerstand festlege.

Alternativ könnte ich natürlich auch für das CTC das OCRx Register verwenden, dabei geht mir aber einer von den beiden möglichen Output-Compares drauf.

Somit müsste ich die Ausgänge hintereinander ansteuern, auch möglich, erfordert aber eine Softwarelösung.

Muss ich mir alles nochmal genauer anschauen, was nun besser ist

 

 

8MHz mit Vorteiler 8 ist natürlich noch besser...

Wieso bin ich da bloss noch nicht selber draufgekommen?

[hoppppla]

Hallo,

 

Muss ich mir alles nochmal genauer anschauen, was nun besser ist

klar, hat alles Vor- und Nachteile. Wünsch Dir schon mal viel Spaß beim Knobeln

 

viele Grüße,

Hermann

[hoppppla]

Hm, grad ist mir noch eingefallen: die Lösung für ganz faule wäre der Mega162, der hat nämlich 2 16-Bit-Timer

alternativ wäre noch der Tiny44, der hat zwar auch nur einen 16-Bit-Timer, steckt dafür aber in einem sehr handlichen Dil-14-Gehäuse.

 

viele Grüße,

Hermann

[Muehi]

Nen Mega162 ist dann vielleicht doch etwas übertrieben...

Dann doch eher nen ATTiny2312 mit 20 Pins, der hat dafür zwei externe Pin-Change-Interrupts ( ATTiny44 nur einen richtigen, wenn ich das richtig sehe ).

 

Hab mir übrigens das Datenblatt zwischen die Ohren eingepflegt, die Input Capture Funktion ist doch nicht ganz für diesen Zweck gemacht, sondern mehr zur Frequenzmessung. Zur Impulslängenmessungen müsste man die manuell nach jedem Interrupt von steigender Flanke auf fallende Flanke umstellen und umgekehrt.

[hoppppla]

Hallo,

Nen Mega162 ist dann vielleicht doch etwas übertrieben...

Dann doch eher nen ATTiny2312 mit 20 Pins, der hat dafür zwei externe Pin-Change-Interrupts ( ATTiny44 nur einen richtigen, wenn ich das richtig sehe ).

hm, zu was benötigst Du mehr als einen INT-Eingang? Taster o.ä. würde ich eher pollen, da man sonst probleme mit dem prellen bekommt.

 

Hab mir übrigens das Datenblatt zwischen die Ohren eingepflegt, die Input Capture Funktion ist doch nicht ganz für diesen Zweck gemacht, sondern mehr zur Frequenzmessung. Zur Impulslängenmessungen müsste man die manuell nach jedem Interrupt von steigender Flanke auf fallende Flanke umstellen und umgekehrt.

na ja, das ist ja kein Problem, einfach in der dazu gehörigen ISR die Flanke umstellen, ist im Prinzip ja nur ein Bit, das gesetzt/gelöscht werden muß. Der Vorteil ist einfach, das Du die Werte sofort in das ICR1 gespeichter bekommst, und die restliche Verarbeitung nicht mehr so zeitkritisch ist, da Du ja dann 1-2ms Zeit hast.

 

viele Grüße,

Hermann

[Muehi]

[...]

hm, zu was benötigst Du mehr als einen INT-Eingang? Taster o.ä. würde ich eher pollen, da man sonst probleme mit dem prellen bekommt.

[...]

 

Zwei Motoren, die ich separat steuere. Also auch 2 Kanäle zum auswerten. Falls irgendwie möglich, will ich schon versuchen beide auf einer Platine unterzubringen.

 

 

Zum InputCapture:

Jap, im Prinzip nur ein Bit. Die Genauigkeit ist ein Argument.

Mit der manuellen Methode müsste ich halt sichergehen, dass zwischen Interrupt und Zählerstand sichern bei steigender und fallender Flanke die gleiche Verzögerung stattfindet. Ist im Prinzip auch kein Problem, gleich in den ersten beiden Zeilen der Interrupt-Routine den Zählerstand sichern, und erst anschließend in das jeweilige Register kopieren.

Mal gugge

 

Danke auf jedenfall für deine rege Beteiligung, eine andere Sicht der Dinge zu haben ist nie verkehrt

[hoppppla]

Hallo,

 

Zwei Motoren, die ich separat steuere. Also auch 2 Kanäle zum auswerten. Falls irgendwie möglich, will ich schon versuchen beide auf einer Platine unterzubringen.

Hm, dann würde sich schon der 162 anbieten da könnte man das sauber trennen und für beide Motoren einen eigenen Timer benutzen. Am Preis machts keinen großen Unterschied, Programierung sowiso nicht, der einzige Unterschied ist das etwas größere Gehäuse, aber da kann man sich ja überlegen, eine passende Platine fertigen zu lassen, wenn sich noch ein paar Leute finden, die an sowas Interesse haben, ist das nicht all zu teuer.

Zum entwickeln kann man ja auch erstmal einen vorhandenen Controller benutzen, und sich auf einen Kanal beschränken, die Erweiterung ist dann simpel.

 

Zum InputCapture:

Jap, im Prinzip nur ein Bit. Die Genauigkeit ist ein Argument.

Mit der manuellen Methode müsste ich halt sichergehen, dass zwischen Interrupt und Zählerstand sichern bei steigender und fallender Flanke die gleiche Verzögerung stattfindet. Ist im Prinzip auch kein Problem, gleich in den ersten beiden Zeilen der Interrupt-Routine den Zählerstand sichern, und erst anschließend in das jeweilige Register kopieren.

Mal gugge

Im Moment werte ich mit einem 16-Bit-Timer 3 Servosignale aus, und erzeuge eins. Die Ausgabe ließe sich sicher auch noch soweit aufbohren, das zwei Signale erzeugt werden, ist dann nur nicht mehr so elegant Oder man benötigt einen Timer mit 3 Compare-Registern, vl. gibts das ja bei den ganz neuen Controllern

Das Prinzip ist ganz einfach:

der Timer läuft einfach ganz normal durch, dann muß man sich nämlich keinen Kopf wegen der Überläufe machen (natürlich vorrausgesetzt, man verwendet jeweils uint16_t). Dann gilt nämlich 1000 - 64535 = 2000

Zum Einlesen der Signale benutzte ich 2 externe INTs und die Input-Capture-Einheit, die einfach jeweils den aktuellen Zählerwert in die Variabelen schreiben. Ausgerechnet wird dann im Hauptprogramm. Die Ungenauigkeit bei der INT-Methode hält sich in Grenzen (3-6 µs).

Die Erzeugung des Servosignals läuft über die zwei Compare-Einheiten:

COMPA benutzte ich, um die 20ms Framerate zu erzeugen, d.h. in der ISR wird einfach in das Compareregister A und B der aktuelle Zählerstand + mein gewünschtes Zeitintervall geschrieben. Bei 1MHz Timertakt: OCR1A = TCT1 + 20000; und OCR1B = TCT1 + 1500; (bei Mittelstellung Servo) und gleichzeitig der Ausgangspin auf '1' gesetzt.

COMPB löscht dann einfach nur den Pin.

Fehlerüberwachung o.ä. ist da jetzt natürlich noch nicht dabei, sollte aber nicht all zu aufwendig sein, das nachzurüsten.

Bei Interesse kann ich Dir gern auch mal ein paar Zeilen Code schicken, ist halt in C und kein asm.

 

Danke auf jedenfall für deine rege Beteiligung, eine andere Sicht der Dinge zu haben ist nie verkehrt

ja, in der Tat nachdem ich gerade an etwas ähnlichem sitze, ist das durchaus interessant, wie andere das lösen.

 

viele Grüße,

Hermann

[hoppppla]

Hallo,

 

hab mich heut nochmal damit beschäftigt...

jedenfalls hab ich mal eine C-lib zusammengestrickt, die unter Benutzung eines 16-Bit-Timers bis zu 4 Servosignale einlesen/ausgeben kann.

Pro Kanal, der eingelesen werden soll, wird eine Interrupt-Quelle benötigt (die Pin-Change-Ints werden noch nicht unterstützt, müßte sich aber nachrüsten lassen).

Bei 2 Kanälen reicht also ein kleiner Tiny24 (Input-Cap-Int und Int0).

Die Ausgabekanäle werden nacheinander über die Compare-Ints ausgegeben, theoretisch könnte man also auch mehr als 4 Kanäle ausgeben.

 

viele Grüße,

Hermann

[Muehi]

Hallo,

 

hab mich heut nochmal damit beschäftigt...

[...]

 

Hab ich leider schon nen paar Tage nicht mehr geschafft.

 

Dafür bin ich mittlerweile auch auf C umgestiegen. Tippt sich leichter, und den bissl Mehrbedarf an Speicherplatz kann ich auch verschmerzen

[hoppppla]

Hallo,

Hab ich leider schon nen paar Tage nicht mehr geschafft.

na ja, im Moment mach ich das in Vollzeit (-> Praktikum) deswegen ist das auch keine Kunst

wie gesagt, bei Interesse kann ich Dir die Lib zur Verfügung stellen, da gibts sich auch noch das ein oder andere zu verbessern...

 

viele Grüße,

Hermann

[Muehi]

[...]

wie gesagt, bei Interesse kann ich Dir die Lib zur Verfügung stellen, da gibts sich auch noch das ein oder andere zu verbessern...

[...]

 

Jap, das Angebot nehme ich nun auch gerne an

 

E-Mail kommt per PN.