GizZilla vs. IBF, Delldog, Normen, Bugs, ...

Zitat

Da habe ich mich nicht darauf verlassen. Zum Testen benutze ich die Conrad-Test-PWS (sind ein Poti mit einer kleinen SMD-Platine drauf, da kann man dann eine Pulsweite von 0,8ms bis 2,2ms einstellen). Wenn man zwei von diesen Dinger verwendet, kommen die Pulse garantiert nicht nacheinander.

Nun, das ist richtig... Solange es nur 2 Kanäle sind bin ich dagegen auch unempfindlich, ich bin INT gesteuert... Die Jungs die jedoch pollen werden es als lustig empfinden...

Zitat

Vielleicht habe ich jetzt eine passende Antwort zur falschen Frage: Wenn mir bei einem Projekt die Ports ausgehen, dann nehme ich immer ein paar Latches her.

Bei mir darf es aber kein IC Grab werden... Max 3: uC, Treiber und OP (Bei Dual Version natürlich 4, weil zweiter Treiber). Ich hab kein Problem mit der Anzahl der Pins, eher mit dem Timing...

Zitat

1. RC-Signal digitalisieren
Einen der 4 Timer (8Bit) habe ich als interne Uhr mit einer Auflösung von 0,01ms geschaltet (long-Counter-Variable).
Da das RC-Signal pro Kanal zw. 1ms und 2ms liegt (je nach Stick-Position) bedeutdet das eine AUflösung von 100 Schritten ... das reicht dicke zum Steuern.

Ein ATmega32 hat nicht 4 sondern nur 3 Timer, 2x 8 bit und 1x 16 bit...

Zitat

ls Eingang zum uC verwende ich auch die INT-Eingänge. Über ein externes OR-Gatter habe ich Kanal 1&3 und an einem Zeiten Gatter 2&4 zusammengeführt. (DAS KLAPPT!)

Das ist schön, kommt aber nicht in Frage weil das einen externen Baustein verlangt der absolut unnötig ist... Da gibts elegantere Varianten mehr als 2 RC Signale einzulesen, auch ohne externe Logik...

Zitat

Laut meinem Oszi liegen die fallende Flanke des Kanal 1 und die steigende Flanke des Kanal 2 bei entsprechender Stick-Position so nahe beisammen dass eine Interruptbehandlung das teilweise nicht mehr erfassen kann.

Das geht alles wenn man die externen INTs benutzt...

Zitat

In der Interruptroutine speichere ich einfach den Zählerstand der oben beschriebenen Uhr. In der Main-Scheife (also nicht in der Intterruptroutine) berechne ich dann die Stickposition und steuere damit den PWM Ausgang.

Auch als free running timer bekannt... Das mach ich übrigens genau so...

Zitat

Um nicht pollen zu müssen haben ich zur Steuerung die beiden 16Bit-Timer-Pwm-Einheiten des ATMega32 auf 4KHZ eingestellt.

Nur ein 16bit Timer mit 2 16 bittigen output compare Einheiten die sie jedoch beide auf den 16 bit Timer beziehen und damit auf der gleichen PWM Frequenz laufen. Hier ja aber nicht tragisch, sogar erwünscht...

Zitat

Um aber auch individuell steuern zu können , will ich jede Seite der H-Bridge über einen HIP direkt vom uC ansteuern ansteuern. D.H. 4 Pins mit den Steuersignal vom uC zum HIP plus eine Disable-Leitung (Also die PWM-Ausgangssignale werden hardwareseitig nicht benutzt!).
Die Hardware-PWM Signale generieren jeweils einen Interrupt beim Match des PWM-Counters mit dem Vergleichsregister und beim Überlauf.

Das hab ich am Anfang auch gemacht, bin dann aber dazu übergegangen die beiden freien Timer zu benutzen um die PWM für Modus 2b selbst zu erzeugen... Das geht aber nicht weil die eine PWM ins stocken gerät wenn gerade die andere berechnet wird. Also zurück zu den OC Einheiten... Da wird die PWM auch dann weiterlaufen wenn gerade die andere berechnet wird...

Zitat

Das reicht, um in den Interruproutinen die entsprechenden Pins zm HIP manuell korrekt zu setzen (2 Zeilen Code!).

Ich weiß ja nicht welchen Modus du fährst, aber 2b ist sicherlich nicht (ohne externe Logik) in 2 Zeilen zu machen ...

Zitat

3. Performance
Um einschätzen zu können, wieviel Rechenkapazität ich noch habe, zähle ich die Main-Schleifen-Durchgänge und gebe die Pro Sekunde aus: mit den beschriebenen Funktionalitäten durchlaufe ich die Mainschleife immer noch ca. 12500 mal pro Sekunde. Das reicht dicke zum Steuern und noch für evtl. zusätzliche Aufgaben .... Kanal 4 des RC-Signals ist schon erfasst ... aber noch ungenutzt.

Mein ATmega32L kann max mit 8 MHz laufen und rennt aktuell auf 7,3728 MHz... Dazu kommt noch mein I2C und mein LCD Display... Aber selbst das funktioniert wenn man da behutsam vorgeht...

Zitat

Mit weniger Hardware geht es kaum noch.

Das ist so nicht richtig... Das ODER Gatter und die Optokoppler lassen sich weg optimieren...

Zitat

Der Hip hat den Vorteil, dass der das Detail-Timing der H-Bridge übernimmt (Totzeit zwischen dem Umschalten). Diese Aufgabe übernehme ich im uC nicht (ist mir im Moment zu heiß das Thema und er HIP kann es ja!)

Das ist eigentlich nur als Schutz und nicht als Dauerfeature gedacht... Meiner Meinung nach grob fahrlässig wenn man sich da aussschließlich auf den HIP verläßt...

Zitat

Ich mache KEINE Strombegrenzung .. da die Akkus überhaupt nicht den Strom bei 12V liefern können (wie gesagt ... muss ich noch genau testen.... bis herläuft die Logik und die H-Bridge aus einem älteren AUfbau ... zusammen hab ich sie noch nicht laufen gehabt.)

Das finde ich ehrlich gesagt schon fast unverschämt fahrlässig... Nimm ein Multimeter (aber ein gutes!) oder besser eine (gute) Stromzange, schließ deinen 12V/3Ah NiCD Akku kurz und miss den Strom... Aber nicht zu lange! Gewisse exotherme Rekationen sind nich auszuschließen, und warum? Weil ein nicht zu verachtendes "Strömchen" fließt....

Zitat

Ich berechne die PWM-Signal aber nicht im Interrupt (das hatte ich probiert, war absolut tödlich für das Timing der anderen interrupts)! die Berechne ich in der Main-Schleife.

In meiner Main Schleife bleibt durch oben genannte Peripherie im Moment nicht viel übrig... Des Rätsels Lösung, alles raus nehmen was nicht unbedingt rein muss, aber erst wenn alles andere fehlgeschlagen ist...

Zitat

Wo gibts diese Auflistung der Modi? ich kann sie nicht finden.
Ich setze die 4 Pins mit einem Befehl. Ist doch immer das gleiche Schema.

Ahja, das bei dir nicht vorhandene Problem der zeitgerechten Ansteuerung der FETs...

Zitat

Wieso die L-Variante? Erst schreibst du, dass du Timing-Probleme hast, und dann nutzt du die langsamere Low-Voltage-Variante.

In erster Linie ist es "nur" ein Prototyp mit dem ausgetestet werden soll was alles geht und was nicht... Zweitens hab ich die Module zufälligerweise in nicht geringer Anzahl aus ehemaligen Projekten zur Verfügung...

Zitat

Am ANfang des Threads habt ihr dazu noch anders geklungen.

Zu Optokopplern? Ich kann in meinem Thread hier nichts dazu finden... An anderer Stelle wurde das mal diskutiert, aber das bezog sich auf Optokoppler zwischen uC und Treiber, und das geht nun mal gar nicht weil die Flanken dabei langsam werden....

Zitat

Ihr verrennt euch nicht mit euren Interrupts-Orgien? Was passiert, wenn mal ein bißchen Störung auf den Empfangsleitungen eintrifft? Keine Sorgen, dass das ganze Timing aus dem Ruder läuft?

Gar nichts, weil der Impuls dann als Fehler gewertet wird wenn er nicht innerhalb der Spezifikation eines RC Pulses ist... Deweiteren müssen erst 3 gültige Impulse eintreffen bevor was passiert, die Methode kennst du, ist doch bei dir geklaut

Zitat

aber es funktioniert narrensicher....

Tschuldige, aber das gilt es erst noch zu beweisen... Je mehr ICs desto mehr mögliche Fehlerquellen...

Zitat

Trotzdem viel Glück bei euren restlichen Entwicklungen!

Danke dir auch... Nächste Revision bei dir schon raus?

Zitat

Die drei gültigen Pulse wurden auf vier erweitert, damit die Mittelwertbildung anschließend ein bißchen flotter über den Prozessor geht (vier Char in eine Integer addiert, dann zweimal rechts geshiftet... das geht schneller als geteilt durch 3 ) => Das ist der Nachteil bei der Hausfrauenmethode (=Polling): man muß kurze und schnelle Subroutinen haben.

Tja, dann nimm doch mal nen vernünftigen Prozessor der Additionen und ggfs. auch Multiplikationen in einem Takt schafft... RISC rulez, gelle? :engel:

Zitat

ok, ok..... sollte meinerseits nicht überheblich klingen. Nur hat meine bisherige Praxis gezeigt, je mehr man einem Prozessor aufbürdet, desto leichter treten irgendwelche Nebeneffekte auf, die leider nicht im Proz.-Handbuch beschrieben sind. Bei diskreten Lösungen kann man mit dem Oszi seine Fehler suchen und ggf. durch ein paar Hardwaretricks beseitigen.

Ja ich gebs zu, manchmal gibts da unvorhergesehene Effekte... Allerdings hat die Variante so viel wie möglich in Software zu erledigen gewisse Vorteile... Einer davon ist der schon angesprochene und der andere ist dass nicht gleich ne neue Revision der Hardware her muss wenn ein nicht hackbarer Hard Wired Fehler drauf ist...

Zitat

Der Empfänger gibt also bei fehlendem Trägersignal von den Nachbarkanälen kleine Fehlsignale heraus. Die möchte ich noch abfiltern. Wir so laufen, dass ich nicht nur auf vier gültige Signale schaue, sondern diese Signale müssen alle die gleiche Größenordnung haben.

Solche Scherze sind mir bisher noch gar nicht aufgefallen, da ich immer mit meinem Joystick RC Pulse Gen experimentiere... Lustig

[Update]

So, jetz jetz weiß ich wohl wozu man Optokoppler verwendet... Gerade ist das CPU Modul "grundlos" abgeraucht... Und zwar wollte ich nach einer kompletten Überarbeitung des RC Decoders den Failsafe austesten indem ich wie immer den Strom des RC Pulsgenerators unterbrach... Das war wohl ein Fehler...

Wir schreiben zwar jetzt die neue Minor Versionsnummer 1.1.4, aber Freude wollte sich doch nicht so recht einstellen...

Zitat

Um das Thema nicht in Vergessenheit geraten zu lassen:

http://www.mcmanis.com/chuck/robotics/pr...e/h-bridge.html

vieleicht sind hier wichtige Infos verborgen.

Schon lustige Sachen die der da macht. Allerdings erachte ich hier die Spannungspumpe als Problem, da sie vermutlich nur ein paar mA liefern kann. In anderen Worten heißt das dass die FETs wieder nur mäßig schnell angesteuert werden können. Ausserdem die Problematik mit den Optokopplern. Optokoppler sind zwar ne tolle Sache, aber zu langsam. IBF kann ein Lied davon singen...

Ja mir scheint als würde das Interesse nach diversen Bränden wieder aufflammen...

Mein Ziel ist alles bis zum 900 BB Turbo abzudecken...