Full-Bridge (H-Bridge) mit AVR ansteuern

[Stefan G. (steg13)]

ich würde gerne die Impulse wie im Bild erzeugen.
Geht das mit den PWM-Ausgängen?
X ist variabel von 0 bis 25% T

[TravelRec. (Gast)]

Mit den PWMs geht (fast) alles, also um Deine Frage zu beantworten: ja! 
Dein Programm muß lediglich dafür Sorge tragen, daß die OCRs zum 
richtigen Zeitpunkt übergeben werden. Und Du wirst 2 getrennte PWM-Timer 
für diese Impulsform brauchen, die zueinander sysnchron laufen müssen.

[Stefan G. (steg13)]

also ich habs gerade mit einem Tiny26 versucht.
Es geht nicht daß OC1B später beginnt.(Bild)
Kann mir mal jemand einen Tip geben?

[Sonic (Gast)]

Du brauchst nur einen PWM wenn du den einen Pfad (A) mit statischem 
Signal und den Anderen (B/) mit PWM ansteuerst. Mit einem 7400 kannste 
den PWM mit einem statischen Signal von Vorwärts auf Rückrarts 
umschalten (von B/ auf A/).

[Sonic (Gast)]

Bischen missverständlich ausgedrückt! das 'statische' Signal musste 
natürlich Zeitabhängig vom PWM schalten, meinte einen normalen 
Ausgangspin damit.

[Stefan G. (steg13)]

Hab nix verstanden :-(
Die negierten Signale habe ich ja an OC1A und OC1B
Wo soll ich die NAND anschließen.
Ausserdem sollte es ohne andere ICs gehen

[Sonic (Gast)]

Hmm.. bischen verunglückte Zeichnung, vielleicht kann man's erkennen. 
Ein Bild sagt mehr als tausend Worte.

[Stefan G. (steg13)]

@sonic

also ich denke da kommt nie das Signal raus das ich brauche.
Du kannst zwar ein PWM Signal auf vorwärts oder rückwärts schalten.
Aber es sind keine um x versetzte PWM-Signale wie in meinem Bild.

[Sonic (Gast)]

Hast du Recht, das ist'n alter Entwurf eines RC-Fahrtreglers. Die 
statischen Signale dienen hier nur dazu, die PWM um- bzw. abzuschalten. 
Die versetzten Signale müssen zusätzlich in Abhängigkeit vom PWM 
geschaltet werden.

[Stefan G. (steg13)]

ich habe selbst alles versucht, scheint nicht zu gehen.
Man bräuchte Timer mit der Möglichkeit unteren und oberen Wert bei PWM 
einstellen zu können.

Werde es dann normal über Timer und Ports programmieren

[Knut B. (Firma: TravelRec.) (travelrec)]

1. Antwort ganz oben auf Deine Frage:

>Und Du wirst 2 getrennte PWM-Timer für diese Impulsform brauchen, die zueinander 
sysnchron laufen müssen.

Wenn Du nun OCR1A und OCR1B nimmst, dann ist das 1 Timer, nämlich 
Timer1. Du mußt also Timer0 (bzw. Timer2, je nach Controller) und Timer1 
benutzen, mit den entsprechenden OCR-Pins.

Lesebrille putzen ;-)

[unsichtbarer WM-Rahul (Gast)]

Du brauchst 4 Pins, also für jeden Transistor einen, wenn du keine 
weiteren (externen) Bauteile verwenden willst:
Die beiden OC-Ausgänge steuern die beiden oberen Transistoren an; zwei 
weitere Portpins steuern die beiden unteren an.
Will man jetzt in die eine Richtung "drehen" lassen, schaltet man den 
einen OC-Pin auf den Timer und den gegenüberliegenden Portpin ein.
In die andere Richtung halt den anderen OC-Pin und Transistor.
Man braucht nur einen Timer mit 2 OC-Interrupts...

[Axel R. (Gast)]

Es gibt die "neuen" Tinys mit Totzeit zwischen den PWM Ausgängen. Könnte 
das funktionieren? (AtTiny45/85?)

[Stefan G. (steg13)]

Travel Rec. wrote:
> 1. Antwort ganz oben auf Deine Frage:
>
>>Und Du wirst 2 getrennte PWM-Timer für diese Impulsform brauchen, die zueinander 
sysnchron laufen müssen.
>
> Wenn Du nun OCR1A und OCR1B nimmst, dann ist das 1 Timer, nämlich
> Timer1. Du mußt also Timer0 (bzw. Timer2, je nach Controller) und Timer1
> benutzen, mit den entsprechenden OCR-Pins.
>
> Lesebrille putzen ;-)

ja das geht wenn ich einen Mega nehme, ich brauche ja den dritten Timer 
für die Zeit X (also die Differenz)

[Stefan G. (steg13)]

ich denke ich mache die ganze PWM-Geschichte doch per Hardware.
Also auch die Erzeugung mit einem TL494 oder sowas
Dann die Schaltung wie im Bild.

Ich weiß ja nicht was passiert wenn der AVR mal abstürzt.

[TravelRec. (Gast)]

>was passiert wenn der AVR mal abstürzt...

Dann kommt der Watchdog und hilft ihm wieder auf die Beine.

[Sonic (Gast)]

Dann muss der Watchdog auch neue Leiterbahnen auftragen. Ist mir auch 
schon passiert, beim Programmieren noch den Akkupack dran, Vorwärts und 
Rückwärts (zufällig) gleichzeitig durchgesteuert, dicke MOSFETs => 
heller Blitz!

[TravelRec. (Gast)]

>beim Programmieren noch den Akkupack dran...

MosFets an den ISP-Leitungen?! Oh Mann.... Andererseits klemmt man 
während des Programmierens doch wohl sicherheitskritische Sachen ab. Man 
irrt sich ja auch hin und wieder im Erstellen von Code. Dagegen hilft 
weder ein Hardware- noch ein interner Watchdog.

[Sonic (Gast)]

Nö, die MOSFETs waren nicht an den ISP-Leitungen. Nur passiert einiges 
mit den Portpins, zumindest mit den Pullups wärend dem Programmieren, 
das langt den MOSFETs zum Durchsteuern. Im Eifer des Gefechtes kann's 
schon mal vorkommen dass man was vergisst, aber sowas nur einmal, grins!

[Stefan G. (steg13)]

Akkupacks sind noch harmlos, bei mir wären es 400V und 63A.
Die Mosfets kann man auch als Bremsklötze fürs Auto benutzen ;-)

[Knut B. (Firma: TravelRec.) (travelrec)]

>Nur passiert einiges mit den Portpins, zumindest mit den Pullups wärend dem 
Programmieren

Wie das? Normal werden die beim Programmieren durch den RESET hochohmig, 
mehr nicht. Dadurch könnten sich freilich die Gates an den MosFets durch 
Fremdspannungen aufladen. Deshalb habe ich an den MosFets immer 10k 
Widerstände vom Gate zur Source. Dann bleibt während des Proggens alles 
im Grünen Bereich.

[Sonic (Gast)]

Hast recht, die werden hochohmig, d. h., der Portpin wird als Eingang 
definiert. Die Pullups, also das PORTx - Register wechselt aber während 
des Programmiervorganges unkontrolliert die Zustände. Das kann bei einer 
MOSFET-Gate zum Durchsteuern dicke reichen!

[Knut B. (Firma: TravelRec.) (travelrec)]

>Die Pullups, also das PORTx - Register wechselt aber während
>des Programmiervorganges unkontrolliert die Zustände

Halte ich für ein Gerücht. Der Controller ist während des gesamten 
Programmiervorgangs im RESET, hat also keinen Zugriff auf irgendwelche 
Register, also bleiben diese auch genau so, wie sie direkt vor dem RESET 
waren. Beim Löschen des Reset-Zustandes gehen alle I/O-Register, zu 
denen auch die PORTx-Register gehören, auf ihre INIT-Werte - in diesem 
Falle $00, also alles auf "Eingang, PullUp aus"; bis irgendwann das 
Anwenderprogramm dann etwas anderes vorgibt.