https://rn-wissen.de/wiki/api.php?action=feedcontributions&feedformat=atom&user=OverthereRN-Wissen.de - Benutzerbeiträge [de]2026-04-11T12:11:31ZBenutzerbeiträgeMediaWiki 1.25.1https://rn-wissen.de/wiki/index.php?title=Diskussion:Getriebemotoren_Ansteuerung&diff=13301Diskussion:Getriebemotoren Ansteuerung2008-03-16T11:41:03Z<p>Overthere: </p>
<hr />
<div>hi<br><br />
Bei der ansteuerung von z.b. L298 könte man 2 Ausgangspins sparen wenn man einen Logikinverter vor die Richtungswahl stellt.<br />
<br />
...........|<br><br />
...AVR..|<br><br />
...........|<br><br />
..PB0...|___________[Not]_______Richtung A<br><br />
...........|........|<br><br />
...........|........\_________________Richtung B<br><br />
<br><br />
So könnte man über einen Port die Richtung wählen.<br />
==Kommentar==<br />
Kommentar: Ja, das würde funktionieren. <br />
--[[Benutzer:Overthere|Overthere]] 12:37, 16. Mär 2008 (CET)<br />
<br />
----<br />
<br />
Anmerkung von User shaun zur FET-Schaltung mit Logik Baustein:<br />
Wie ich schon im anderen Eintrag zu dieser Schaltung schrieb, ist diese Schaltung durchaus gar nicht geeignet, da ab einer Betriebsspannung von ca. 4V bei jedem Schalt- und damit Umladevorgang kurzzeitig beiden MOSFETs eines Brückenzweiges leiten, somit also ein Kurzschluss entsteht und erheblicher Strom fliesst. Auch bei niedriger PWM-Frequenz führt dies zu erheblicher Erwärmung und ggf. zur Zerstörung, auf jeden Fall aber zu massiven Störungen auf der Versorgung.<br />
<br />
<br />
----<br />
<br />
Der Hauptteil ist hier die Diskussion der H Brücke als Motortreiber. Die selbe Schaltung wird (2x) auch bei bipolaren Schrittmotoren verwendet. Man sollte die Beschreibungen also zusammenfassen. Der Tietel ist auch etwas unpraktisch, ich bin nur zufällig auf den Artikel gestoßen, gefunden hätte ich ihn nicht, wenn ich danach suchen würde.<br />
<br />
----<br />
<br />
Die aus MOSFETs diskret aufgebaute H-Brücke gehört irgendwie schon noch zu den integrierten H-Brücken dazu.<br />
<br />
Wenn die Neufassung mal fertig (und der Alte Teil weg) ist, ist der Abschnitt auch nicht mehr ganz so lang.</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Diskussion:Getriebemotoren_Ansteuerung&diff=13300Diskussion:Getriebemotoren Ansteuerung2008-03-16T11:38:23Z<p>Overthere: </p>
<hr />
<div>hi<br>--[[Benutzer:Overthere|Overthere]] 12:37, 16. Mär 2008 (CET)--[[Benutzer:Overthere|Overthere]] 12:37, 16. Mär 2008 (CET)<br />
Bei der ansteuerung von z.b. L298 könte man 2 Ausgangspins sparen wenn man einen Logikinverter vor die Richtungswahl stellt.<br />
<br />
...........|<br><br />
...AVR..|<br><br />
...........|<br><br />
..PB0...|___________[Not]_______Richtung A<br><br />
...........|........|<br><br />
...........|........\_________________Richtung B<br><br />
<br><br />
So könnte man über einen Port die Richtung wählen.<br />
==Kritik==<br />
Kommentar: Das Not Gatter überschneidet sich! Wenn B sowie A auf high sind, dann gibt es einen "Quasi-Kurzschluss". Möglich wäre es mit einigen Widerständen, wobei man dann ein OpenDrain (7406) verwenden muss.<br />
<br />
-+-[!]---[A]<br><br />
.|.......<br><br />
.+--[R]--[B]<br><br />
<br />
--[[Benutzer:Overthere|Overthere]] 12:37, 16. Mär 2008 (CET)<br />
<br />
----<br />
<br />
Anmerkung von User shaun zur FET-Schaltung mit Logik Baustein:<br />
Wie ich schon im anderen Eintrag zu dieser Schaltung schrieb, ist diese Schaltung durchaus gar nicht geeignet, da ab einer Betriebsspannung von ca. 4V bei jedem Schalt- und damit Umladevorgang kurzzeitig beiden MOSFETs eines Brückenzweiges leiten, somit also ein Kurzschluss entsteht und erheblicher Strom fliesst. Auch bei niedriger PWM-Frequenz führt dies zu erheblicher Erwärmung und ggf. zur Zerstörung, auf jeden Fall aber zu massiven Störungen auf der Versorgung.<br />
<br />
<br />
----<br />
<br />
Der Hauptteil ist hier die Diskussion der H Brücke als Motortreiber. Die selbe Schaltung wird (2x) auch bei bipolaren Schrittmotoren verwendet. Man sollte die Beschreibungen also zusammenfassen. Der Tietel ist auch etwas unpraktisch, ich bin nur zufällig auf den Artikel gestoßen, gefunden hätte ich ihn nicht, wenn ich danach suchen würde.<br />
<br />
----<br />
<br />
Die aus MOSFETs diskret aufgebaute H-Brücke gehört irgendwie schon noch zu den integrierten H-Brücken dazu.<br />
<br />
Wenn die Neufassung mal fertig (und der Alte Teil weg) ist, ist der Abschnitt auch nicht mehr ganz so lang.</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Diskussion:Getriebemotoren_Ansteuerung&diff=13299Diskussion:Getriebemotoren Ansteuerung2008-03-16T11:37:58Z<p>Overthere: </p>
<hr />
<div>hi<br>--[[Benutzer:Overthere|Overthere]] 12:37, 16. Mär 2008 (CET)--[[Benutzer:Overthere|Overthere]] 12:37, 16. Mär 2008 (CET)<br />
Bei der ansteuerung von z.b. L298 könte man 2 Ausgangspins sparen wenn man einen Logikinverter vor die Richtungswahl stellt.<br />
<br />
...........|<br><br />
...AVR..|<br><br />
...........|<br><br />
..PB0...|___________[Not]_______Richtung A<br><br />
...........|........|<br><br />
...........|........\_________________Richtung B<br><br />
<br><br />
So könnte man über einen Port die Richtung wählen.<br />
==Kritik==<br />
Kommentar: Das Not Gatter überschneidet sich! Wenn B sowie A auf high sind, dann gibt es einen "Quasi-Kurzschluss". Möglich wäre es mit einigen Widerständen, wobei man dann ein OpenDrain (7406) verwenden muss.<br />
<br />
-+-[!]---[A]<br><br />
.|.......<br><br />
.+-------[B]<br><br />
<br />
--[[Benutzer:Overthere|Overthere]] 12:37, 16. Mär 2008 (CET)<br />
<br />
----<br />
<br />
Anmerkung von User shaun zur FET-Schaltung mit Logik Baustein:<br />
Wie ich schon im anderen Eintrag zu dieser Schaltung schrieb, ist diese Schaltung durchaus gar nicht geeignet, da ab einer Betriebsspannung von ca. 4V bei jedem Schalt- und damit Umladevorgang kurzzeitig beiden MOSFETs eines Brückenzweiges leiten, somit also ein Kurzschluss entsteht und erheblicher Strom fliesst. Auch bei niedriger PWM-Frequenz führt dies zu erheblicher Erwärmung und ggf. zur Zerstörung, auf jeden Fall aber zu massiven Störungen auf der Versorgung.<br />
<br />
<br />
----<br />
<br />
Der Hauptteil ist hier die Diskussion der H Brücke als Motortreiber. Die selbe Schaltung wird (2x) auch bei bipolaren Schrittmotoren verwendet. Man sollte die Beschreibungen also zusammenfassen. Der Tietel ist auch etwas unpraktisch, ich bin nur zufällig auf den Artikel gestoßen, gefunden hätte ich ihn nicht, wenn ich danach suchen würde.<br />
<br />
----<br />
<br />
Die aus MOSFETs diskret aufgebaute H-Brücke gehört irgendwie schon noch zu den integrierten H-Brücken dazu.<br />
<br />
Wenn die Neufassung mal fertig (und der Alte Teil weg) ist, ist der Abschnitt auch nicht mehr ganz so lang.</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Diskussion:Getriebemotoren_Ansteuerung&diff=13298Diskussion:Getriebemotoren Ansteuerung2008-03-16T11:37:26Z<p>Overthere: </p>
<hr />
<div>hi<br>--[[Benutzer:Overthere|Overthere]] 12:37, 16. Mär 2008 (CET)--[[Benutzer:Overthere|Overthere]] 12:37, 16. Mär 2008 (CET)<br />
Bei der ansteuerung von z.b. L298 könte man 2 Ausgangspins sparen wenn man einen Logikinverter vor die Richtungswahl stellt.<br />
<br />
...........|<br><br />
...AVR..|<br><br />
...........|<br><br />
..PB0...|___________[Not]_______Richtung A<br><br />
...........|........|<br><br />
...........|........\_________________Richtung B<br><br />
<br><br />
So könnte man über einen Port die Richtung wählen.<br />
==Kritik==<br />
Kommentar: Das Not Gatter überschneidet sich! Wenn B sowie A auf high sind, dann gibt es einen "Quasi-Kurzschluss". Möglich wäre es mit einigen Widerständen, wobei man dann ein OpenDrain (7406) verwenden muss.<br />
<br />
-+-[!]---[A]<br />
.|.......<br />
.+-------[B]<br />
<br />
--[[Benutzer:Overthere|Overthere]] 12:37, 16. Mär 2008 (CET)<br />
<br />
----<br />
<br />
Anmerkung von User shaun zur FET-Schaltung mit Logik Baustein:<br />
Wie ich schon im anderen Eintrag zu dieser Schaltung schrieb, ist diese Schaltung durchaus gar nicht geeignet, da ab einer Betriebsspannung von ca. 4V bei jedem Schalt- und damit Umladevorgang kurzzeitig beiden MOSFETs eines Brückenzweiges leiten, somit also ein Kurzschluss entsteht und erheblicher Strom fliesst. Auch bei niedriger PWM-Frequenz führt dies zu erheblicher Erwärmung und ggf. zur Zerstörung, auf jeden Fall aber zu massiven Störungen auf der Versorgung.<br />
<br />
<br />
----<br />
<br />
Der Hauptteil ist hier die Diskussion der H Brücke als Motortreiber. Die selbe Schaltung wird (2x) auch bei bipolaren Schrittmotoren verwendet. Man sollte die Beschreibungen also zusammenfassen. Der Tietel ist auch etwas unpraktisch, ich bin nur zufällig auf den Artikel gestoßen, gefunden hätte ich ihn nicht, wenn ich danach suchen würde.<br />
<br />
----<br />
<br />
Die aus MOSFETs diskret aufgebaute H-Brücke gehört irgendwie schon noch zu den integrierten H-Brücken dazu.<br />
<br />
Wenn die Neufassung mal fertig (und der Alte Teil weg) ist, ist der Abschnitt auch nicht mehr ganz so lang.</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Getriebemotoren_Ansteuerung&diff=13282Getriebemotoren Ansteuerung2008-03-15T12:30:22Z<p>Overthere: </p>
<hr />
<div>Hat man sich entschlossen, für seinen Roboter oder andere Konstruktion einen Getriebemotor zu verwenden, so muss man sich Gedanken machen, wie man ihn ansteuert. Gewöhnlich will man die Motoren ja sowohl in Bezug auf Drehrichtung und Geschwindigkeit über eine Programmiersprache steuern. Daher wird in der Regel erst mal ein Controllerboard benötigt. Leider kann man an die wenigsten Controllerboards einen Getriebemotor direkt anschließen, eine der wenigen Ausnahmen ist das [[RN-Control]]-Board und das RNBFRA-Board. Bei beiden Boards ist es einfach, dort müssen die Getriebemotoren einfach nur an die Schraubklemmen angeschlossen werden, danach kann man sofort mit der Programmierung loslegen.<br />
<br />
Ich möchte hier aber aufzeigen, wie man Motoren auch bei anderen Boards anschließen kann. Die gleiche Technik läßt sich natürlich auch nutzen, um z.B. mehr als zwei Motoren an [[RN-Control]] anzuschließen.<br />
<br />
==Ansteuerung mit Relais==<br />
<br />
Die einfachste Methode, um Motoren per [[Microcontroller|Controller]] anzusteuern, erreicht man durch die Verwendung von Relais. Mit einem Relais, das zwei Umschaltkontakte besitzt, lässt sich über einen einzelnen Controllerport bequem die Drehrichtung wechseln.<br />
<br />
[[Bild:hbrueckerelais.gif|center]]<br />
<br />
Da auch Relais wegen des Strombedarfes nicht direkt vom Controller geschaltet werden können, wurde in dem oberen Beispiel ein Transistor vorangestellt. Die Diode dient nur dazu, die Spannungen, die beim Ausschalten des Relais induziert werden, abzuleiten. Ohne Diode funktioniert das Ganze in der Regel auch, jedoch könnte der Transistor oder sogar der Controller durch die induzierte Spannung beschädigt werden. <br />
Die Schaltung ist also in der Lage, die Drehrichtung umzuschalten, jedoch nicht in der Lage, den Motor zu stoppen. Um den Motor ganz auszuschalten, müsste man noch ein weiteres Relais vorsehen, das die gesamte Motorspannung abschaltet. Ein Schaltbild können wir uns ersparen, da das Ganze recht ähnlich aussieht. <br />
Der große Nachteil von Relaisschaltungen ist, dass die Geschwindigkeit des Motors nicht geregelt werden kann, zudem haben Relais bei sehr vielen Schaltvorgängen einen gewissen Verschleiß. <br />
Vorteil der Schaltung ist jedoch, das man auch sehr große Lasten/Motoren schalten kann.<br />
<br />
==Ansteuerung mit MOS-FET==<br />
===Neufassung===<br />
{{Ausbauwunsch|Die Neufassung kann im momentanen Stand nur als Anregung verstanden werden.<br />
<br />
Insbesondere fehlen noch angepasste Schaltpläne.<br />
<br />
Einige der Anmerkungen aus dem Abschnitt "Kritik an der Schaltung" sind in der Neufassung noch nicht enthalten, die Beschreibung von Verzögerungsgliedern müsste auch eine Erklärung enthalten, welche Verzögerung mit welchen Werten erreicht wird.<br />
<br />
Wenn die Neufassung komplett fertig ist, sollten die alten Texte weg.<br />
}}<br />
====Grundprinzip====<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz.<br />
<br />
Die Grundschaltung besteht aus 2 N-Kanal-MOSFET (hier BUZ11) und zwei P-Kanal-MOSFET (hier IRF5305), mit denen die Motoranschlüsse nach GND bzw. UB geschaltet werden. Zusätzlich sind noch 4 Schottky-Dioden (z.B. SB530) erforderlich, um Induktionsströme des Motors abzuleiten. Die Dioden werden in Sperrichtung von den beiden Motoranschlüssen nach GND bzw. UB geschaltet.<br />
<br />
Grundsätzlich muss die Beschaltung der Gate-Eingänge so erfolgen, dass zum Starten des Motors die Transistoren einer Diagonale auf "leitend" und die der anderen auf "sperrend" geschaltet werden. Zum Anhalten des Motors werden z.B. die unteren auf leitend und die oberen auf sperrend geschaltet - Der Motor wird dadurch schnell abgebremst, denn durch einen Transistor und eine Freilaufdiode fließt ein nicht unerheblicher Bremsstrom.<br />
Alternativ kann man auch alle Transistoren auf sperrend schalten, der Motor läuft dann im Leerlauf aus.<br />
<br />
Die Transistoren einer Seite dürfen nicht dauerhaft gleichzeitig auf "leitend" geschaltet werden, da dies einen Kurzschluss verursacht.<br />
<br />
Hinweis: Zumindestens bei dem Transistor BUZ11 handelt es sich um ein veraltetes Modell. Wenn es auf hohe Leistung ankommt, sollte da ein anderer Transistor gewählt werden.<br />
<br />
====Elektrische Ansteuerung der Gates====<br />
Beim Umschalten der Transistoren entsteht eine erhöhte Verlustleistung - der Widerstand wechselt von sperrend (sehr großer Widerstand) nach leitend (sehr kleiner Widerstand) und umgekehrt.<br />
<br />
Zwischen beiden Enden des Schaltvorgangs befindet sich der Transistor in der "Widerstandsphase" (weder ganz leitend, noch ganz sperrend), die eine erhebliche Verlustleistung und damit Erwärmung mit sich bringt.<br />
<br />
Deshalb sollte der Schaltvorgang - insbesondere wenn für eine PWM-Gegelung sehr oft geschaltet werden soll - möglichst schnell erfolgen. Da zum Umschalten die durch den Aufbau des MOSFETs bedingte Gatekapazität umgeladen werden muss, ist hierzu (sehr kurzzeitig) ein hoher Stromfluss nötig.<br />
=====Schaltung direkt am Port=====<br />
Eine Ansteuerung unmittelbar über den Ausgang eines Mikrocontrollers (oder eines TTL-IC) ist schon wegen der benötigten Spannungen nicht möglich. <br />
<br />
Bei den N-FET könnte man sog. "Logik-MOSFET" nehmen, die bereits bei 5V ausreichend leitet. <br />
<br />
Bei den P-MOSFET bemisst sich die Schaltspannung gegen UB, mit einem 5V Port und UB=12V würde also zwischen -12V und -7V umgeschaltet, was einen P-MOSFET erfordern würde, der bereits bei -7V sperrt.<br />
<br />
Dass ein Portpin nur einen geringen Stromfluss (~20mA) zulässt, ist ein weiteres Problem und verhindert einen Schaltvorgang mit idealer steiler Flanke. Allerdings ist die Schaltungsvariante mit einem Transistor in diesem Punkt keinesfalls besser, wenn die Gatekapazität durch den PullUp-Widerstand umgeladen werden muss.<br />
=====Schaltung mit einem Transistor=====<br />
Eine einfache Steuerschaltung besteht aus einem Transistor-Schalter und einem Pull-Up-Widerstand. Als Schalter hab ich 1/7 eines ULN2003 IC verwendet, als PullUp 2200 Ohm. Ein diskreter Aufbau mit 1 Transistor und 2 Widerständen ist aber auch nicht komplizierter.<br />
<br />
Der Vorteil liegt in der Einfachheit, der Nachteil liegt darin, dass die Schaltung nicht sonderlich schnell vonstatten geht: Für die Schaltung des FET muss die Gate-Kapazität transferiert werden, was insbesondere beim Wechsel von 0V nach UB einen Moment dauert, da die Ladung durch den Widerstand hindurch muss.<br />
<br />
Ein kleinerer Widerstand könnte hier helfen, verursacht allerdings einen nicht unerheblichen Stromfluss im geschalteten Zustand (zulässige Verlustleistung beachten).<br />
=====Schaltung mit zwei Transistoren=====<br />
Eine bessere Ansteuerung sollte sich ergeben, wenn man zwei Transistoren zur Gate-Ansteuerung verwendet: Einer schaltet gegen 0V, der andere Gegen UC. So kann man erreichen, dass in beide Richtungen rasch umgeschaltet werden kann.<br />
=====Integrierte Gate-Treiber=====<br />
Statt der Beschaltung mit zwei Transistoren kann man auch einen integrierten MOSFET-Treiber verwenden. Mit derartige IC sind darauf ausgelegt, kurzfristig den für eine Umschaltung benötigten hohen Stromfluss zu ermöglichen.<br />
<br />
Es gibt auch Treiber-IC, die zur Ansteuerung der oberen Transistoren eine Spannung oberhalb von UB erzeugen. Mit solchen Highside-Treibern kann die H-Brücke auch aus 4 N-Kanal-Transistoren gebaut werden, was den Vorteil hat, dass N-Kanal-FET mit geringerem Schaltwiderstand zu bekommen sind.<br />
<br />
====Logische Ansteuerung der Gates====<br />
Nach der elektrischen Ansteuerung ist die logische Ansteuerung durch den Mikrocontroller zu überlegen.<br />
<br />
=====Mögliche Querströme=====<br />
In der H-Brücke sind zwei problematische Zustände zu berücksichtigen:<br />
<br />
1. Das offensichtliche Problem ist ein Kurzschluss: Wenn beide Transistoren einer Seite auf leitend geschaltet werden wird dadurch ein Kurzschluss erzeugt. Falls vorhanden brennt die Sicherung durch - ist keine Sicherung vorhanden, brennt was anderes durch.<br />
<br />
2. Ein nicht so offensichtliches Problem rührt daher, dass der Schaltvorgang nur mit endlicher Geschwindigkeit abläuft und der Transistor auch schon vor Erreichen des Zielwertes der Gate-Spannung erheblichen Strom leitet. Hierdurch kommt es zu einem Kurzschluss durch den nicht mehr richtig gesperrten und den noch nicht richtig gesperrten Transistor.<br />
<br />
Die Stromspitze selbst liegt noch im Rahmen der Spezifikationen der Transistoren. Sofern ein Messwiderstand von z.B. 0,1 Ohm da ist oder die Spannungsquelle einen vergleichbaren Innenwiderstand hat fließt ein Strom von weniger als 70A, die Transistoren sind jeweils für Spitzen von über 100A spezifiziert.<br />
<br />
Allerdings hat die Stromspitze drei Auswirkungen: <br />
<br />
# Die Transistoren erwärmen sich<br />
# Es kann an einem Messwiderstand zu einer Spannungsspitze kommen<br />
# Die Versorgungsspannung bricht kurzzeitig zusammen<br />
<br />
----<br />
<br />
Die Erwärmung des Transistors ist solange kein Problem, wie nur selten umgeschaltet wird. Bei einer Regelung per PWM könnten sich die kleinen Energiemengen zu einem relevanten Problem addieren. <br />
<br />
Da die Erwärmung - sofern sie relevant wird - leicht ohne Messinstrumente feststellbar ist, dürfte dieser Teil des Problems insofern handhabbar sein, als man leicht feststellen kann, ob das Problem relevant ist und das Problem auf die Transistoren beschränkt sind.<br />
<br />
Bei Leerlauf-Schaltvorgängen im Abstand von 1/15 Sekunden habe ich keine Erwärmung der Transistoren feststellen können, es wurden auch keine zusätzlichen Kühlkörper verwendet.<br />
<br />
----<br />
Die Spannungsspitze am Messwiderstand kann abgeleitet werden:<br />
Als weitere Vorsichtsmaßnahme habe ich den Messport des Controllers mit einem Widerstand und einer Z5.1 Diode abgesichert.<br />
<br />
----<br />
<br />
Die Störung der Versorgungsspannung lässt sich ohne Oszilloskop nicht messen. Insbesondere in umfangreicheren Schaltungen können Störungen an ganz anderen Stellen (z.B. bei Sensoren) auftreten, die man dann nicht gleich mit der Motorsteuerung in Verbindung bringt.<br />
<br />
Um die Störung vom Controller fernzuhalten habe ich dem Spannungswandler vorsichtshalber eine kleine Schottky-Diode (SB140) vorgeschaltet, um ein Entladen des Stützkondensators zu verhindern.<br />
<br />
=====softwaremäßige Ansteuerung=====<br />
Die einfachste Art der Ansteuerung besteht darin, die Schalter der 4 Gates mit 4 Ausgängen des Controllers zu verbinden.<br />
<br />
Die korrekte Ansteuerung muss dann durch die Software garantiert werden. <br />
<br />
Eine Fehlschaltung der Software z.B. bei einem Absturz kann allerdings zur Zerstörung der Schaltung führen, die Schaltung sollte also in jedem Fall eine Sicherung haben.<br />
<br />
=====Einfache Ansteuerung=====<br />
Etwas sicherer ist es, die Schaltung so aufzubauen, dass ein Kurzschluss nicht dauerhaft geschaltet werden kann.<br />
<br />
Hierzu habe ich die Schaltung so aufgebaut, dass die Gates einer Seite jeweils gemeinsam geschaltet werden. <br />
<br />
Bei einer Gate-Spannung von 0V sperrt der N-MOSFET (U<sub>GS</sub>=0V), der P-MOSFET leitet bei dieser Gate-Spannung, da hier U<sub>GS</sub>=-UB ist. <br />
<br />
Bei einer Gate-Spannung von UB verhält es sich genau umgekehrt: Der N-MOSFET leitet (U<sub>GS</sub>=UB) und der P-MOSFET sperrt (U<sub>GS</sub>=0V)<br />
<br />
Diese einfache Ansteuerung benötigt lediglich zwei Transistorschalter und auch nur 2 Port-Pins, hat jedoch den Nachteil, dass die oben beschriebenen Querströme auftreten.<br />
=====Verbesserungsmöglichkeiten=====<br />
Zur Lösung des Querstrom-Problems gibt es mehrere Ansatzmöglichkeiten, die ebenfalls mit zwei Controller-Ausgängen auskommen.<br />
----<br />
Mittels Logik-Bausteinen werden zwei Ausgänge des Controllers so umgesetzt, dass die folgenden Zustände geschaltet werden können:<br />
<br />
# Motor-Stop: untere Transistoren leitend, obere sperrend (oder umgekehrt)<br />
# Motor-Vorlauf: 1. Diagolale leitend<br />
# Motor-Rücklauf: 2. Diagonale leitend<br />
# Motor-Leerlauf: Alle Transistoren sperrend<br />
<br />
Die Querstrom-Problematik kann hierbei softwaremäßig gelöst werden, indem beim Umschalten jeweils kurz der Leerlauf geschaltet wird, damit alle Transistoren sperren.<br />
----<br />
Eine andere Möglichkeit besteht darin, das Umladen der Gate-Kapazität asymmetrisch zu gestalten, so dass die Transistoren schneller auf sperrend als auf leitend geschaltet werden. Eine einfache Möglichkeit ist die Parallelschaltung einer Diode und eines Widerstandes: In Sperr-Richtung fließt die Ladung langsamer als in die Durchlass-Richtung.<br />
===Heidingscher Encoder===<br />
Aufgrund der Kritik an der alten Schaltung(siehe '''Alte Schaltungsbeschreibung''') entschied ich mich einen neuen, einfachen sowie preisgünstigen Encoder zu entwickeln, den man mit der 74series aufbauen kann. Als Treiber können sowohl Transistoren verwendet werden, dabei aber Vorwiderstände nicht vergessen! Die 74series sind mit 20mA Treiberstrom also natürlich nicht zum direkten Treiben geeignet.<br />
Die Logikanzeigen in den Grafiken sollen je einen Transistor bzw. Mosfet darstellen. Eventuelle Freilaufdioden müssen natürlich noch hinzugefügt werden.<br />
====PR Encoder====<br />
[[Bild:Prtreiber.png]]<br />
<br />
Der PR Encoder(PWM-Richtung Encoder) ist mit zwei NOR Gates sowie eines Inverters aufgebaut, d.h. man kann ihn mit nur einem IC(74HC(T)02) aufbauen. Will mein 2 Encoder verwenden, empfliehlt sich den Inverter auszulagern (74HC(T)04 oder 74HC(T)14 Sollte man keinen Schmitt-Trigger benötigen empfiehlt sich aus Schnelligkeitsgründen die 74HC(T)04 Variante). <br />
Alternativ ist es noch möglich sich den Inverter zu sparen, und die Ansteuerung für den P(WM) Kanal invertiert laufen zu lassen. <br />
====PRK Encoder====<br />
[[Bild:Prktreiber.png]]<br />
<br />
Der Prk-Encoder(PWM-Richtung-Kurzschluss-Encoder) ist eine Erweiterung des PR-Encoders. Er erlaubt es zusätzlich, die Motoren durch einen Kurzschluss zu stoppen.<br />
Aufgebaut werden kann dieser aus 1 NOR und 1 Nand Gate. Dabei werden 3 Nand-Gates als Inverter beschaltet. (d.h. eine die Leitung die übrig bleibt auf Vcc).<br />
====Support====<br />
Fragen einfach in das Forum posten, oder mich anschreiben(User s.o.)<br />
===Alte Schaltungsbeschreibung===<br />
{{FarbigerRahmen|<br />
Achtung! Die Schaltung ist so nicht zu verwenden! Siehe unter '''Kritik an der Schaltung'''<br />
}}<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz. Eine der interessantesten Schaltungen, die im Roboternetz vorgestellt wurde, dürfte diese sein:<br />
<br />
<br />
[[Bild:hbrueckemosfet.gif|center]]<br />
<br />
<br />
Anmerkung: Den 74HC26N gibts wohl nicht , nur die TTL-Version 74LS26, die HC-Mos-Version lautet 74HC03.<br />
<br />
Eine sogenannte H-Brücke, die nur aus zwei MOSFETSs und einem Logik-IC besteht. Mit zwei Controllerports kann diese Schaltung sowohl Geschwindigkeit als auch Drehrichtung regeln. Für die Geschwindigkeit ist ein sogenannter [[PWM]]-Port notwendig. Also ein Port, der durch ein gepulstes Signal den Motor etlichemal innerhalb einer Sekunde ein- und ausschaltet und somit quasi die Leistung regelt (siehe [[PWM]]).<br />
Die Schaltung ist so konstruiert, dass immer nur zwei Transistoren durchschalten. Auf diese Weise fließt einmal der Strom von links oben nach rechts unten und einmal von rechts oben nach links unten, der Motor wird also ähnlich wie bei der Relaisschaltung umgepolt. <br />
Bei niedriger [[PWM]]_Frequenz sollte die Schaltung durchaus für einige Ampere geeignet sein, wobei ca. 8 bis 13V ideal sein sollten.<br />
<br />
Das Logic-IC wurde durch 3x BC547 Transitoren ersetzt.<br />
<br />
<br />
[[Bild:Hbrückenmosfet BD547.PNG|center|900px]]<br />
<br />
====Kritik an der Schaltung====<br />
<br />
Diese Schaltung wird im Forum von mehreren Leuten, u.A. Ratber, shaun, massiv kritisiert, z.B. hier: http://www.roboternetz.de/phpBB2/viewtopic.php?t=33067&sid=892e80c6cd2d003292e607bcd7a7123a .<br />
<br />
Ich habe leider nicht das Wissen eine bessere Lösung zu liefern. Das Problem sind die Querströme: Im Umschaltmoment sind highside und lowside switch für kurze Zeit beide leitend. Das entspricht einem Kurzschluss der Versorgungsleitung bei jedem Umschalten mit allen damit verbundenen Problemen (Erwärmung, Schwingung, Sicherungen, Reset). Aus diesem Grund sind NAND-Gatter nicht geeignet!<br />
<br />
Zum Umschalten muss man<br />
*den bisher leitenden Mosfet ausschalten,<br />
*dann etwas warten,<br />
*und schließlich den nächsten Mosfet schließen.<br />
<br />
Dies kann man erreichen, indem man den Einschaltmoment <br />
*durch RC-Glieder verzögert und <br />
*den Ausschaltmoment durch Dioden beschleunigt.<br />
Die entstehenden Schaltungen sind komplex, benötigen viele Bauteile und sind fehleranfällig.<br />
<br />
<br />
Am sinnvollsten sind integrierte Mosfet-Treiber. Diese haben oft eine einstellbare Tot-Zeit (''Dead-Time''), können hohe Leistungen zum Umladen der Gatekapazität liefern und beachten andere Effekte wie ''Propagation-Time'', Veränderung des Source Potentials beim Highside-switch, etc.<br />
<br />
'''Erklärung von shaun:'''<br />
<br />
die gezeigte Schaltung taugt auch nur als Prinzipschaltung bedingt, da man einen variierenden Aufwand in eine sichere Verriegelung investieren müsste. Bei fixer und nicht zu hoher Betriebsspannung könnte man mit RD-Kombinationen in den Gateleitungen das Ausschalten beschleunigen und das Einschalten verzögern, so dass die Querleitung wegfällt. Allerdings bewirkt diese simple R-Cg-Verzögerung größere Schaltverluste. <br />
<br />
Setzt man die Vezögerung vor dedizierte Treiber, müssen diese wiederum leistungsfähig genug zum Umladen der Gates sein und bis an die Versorgung heranreichen, weshalb man an diesem Punkt überlegen sollte, ob 95% duty cycle nicht auch reichen würden ''(Anmerkung: Bezug auf bootstrapping?)'' und man integrierte Treiber für reine N-Kanal-Bestückung einsetzen sollte - spart dann wieder etwas Verluste am Highside-Switch, weil N-Kanäler gleicher Generation und Leistungsklasse einen niedrigeren Rds(on) als ihre P-Pendants haben.<br />
<br />
{{Ausbauwunsch|Eine vernünftige diskrete Ansteuerung für eine H-Brücke.<br />
Korrektur auf Rechtschreibfehler, Zeichensetzung, Schreibstil, Fachausdrücke. Gibt's denn keinen der etwas verbessern möchte?}}<br />
==Ansteuerung mit einem LeistungsOPV==<br />
Die wohl preislich und platztechnisch günstigste Alternative zur Ansteuerung von Motoren in H-Brücken ist die Verwendung von (Leistungs-)Operationsverstärkern. <br />
===Heidingscher Motortreiber=== <br />
Bei dem Heidingschen Motortreiber wird jeder Anschluss des Motors mit einem Ausgang des Operationsverstärker verbunden, die Eingänge des OPVs selbst als Komparator. Diese Methode ist für kleine und mittlere Motoren(=< 1A) und mäßige PWM-Frequenzen(<10kHz) gut geeignet. Ein RB35 von Conrad kann damit problemlos angesteuert werden. Bei zu hohen PWM-Frequenzen ist die SlewRate von vielen OPVs zu gering und die entsprechenden OPVs sind dann viel zu teuer und man sollte eine Ansteuerung per Mosfet(s.o.) bevorzugen. Momentan hat sich der TCA 0372 DP1 (57ct bei Reichelt) Verwendung gefunden. <br />
Weitere Informationen sind in folgendem Forumsbeitrag zu finden:<br />
http://www.roboternetz.de/phpBB2/viewtopic.php?t=38412<br />
===Gleichstromansteuerung===<br />
Eine weitere Möglichkeit ist es, dem Operationsverstärker eine Gleichspannung vorzugeben, mit denen der OPV die Motoren ansteuert. Diese Methode eignet sich sehr gut für analoge Schaltkreise. Der Wirkungsgrad ist allerdings nicht der beste, da die restliche Spannung in Wärme umgesetzt wird. Zudem werden viele weitere komponenten benötigt, dass den Aufbau treuerer und fehleranfälliger macht.<br />
Der entsprechenden Schaltkreis ist im Datenblatt des TCA 0372 DP1 zu finden.<br />
<br />
==Ansteuerung mit Treiber IC L293 D==<br />
<br />
Dies ist ohne Zweifel die am häufigsten genutzte Ansteuerung bei Roboter-Bastlern: Man nimmt einfach das IC L293D, denn darin sind sogar zwei H-Brücken enthalten. Also mit einem IC lassen sich ohne weiteres externe Bauteile gleich zwei Motoren ansteuern. Zwar nur bis ca. 600mA, aber das reicht oft schon für kleinere bis mittlere Roboteranwendungen aus.<br />
<br />
[[Bild:L293Pinout.JPG|center]]<br />
<br />
<br />
[[Bild:hbrueckel293d.gif|center]]<br />
<br />
Wie aus dem Schaltbild zu ersehen ist, werden für die Ansteuerung jedes Motors 3 Ports benötigt. Die Enable-Leitung führt man oft auf einen PWM-Port welcher wie bei der MOS-FET Schaltung oben die Geschwindigkeit regelt. Die beiden anderen Ports geben die Drehrichtung an. Immer wenn die Ports unterschiedliche Polarität haben dreht der Motor in eine bestimmte Richtung, je nachdem wo Low und High anliegt. Das Besondere ist, dass wenn an beiden Ports der gleiche Pegel anliegt, also zweimal Low oder High, dann wird nämlich der Motor kurzgeschlossen - das fungiert als Bremse. Das Bremsen kann bei Robotern durchaus nützlich sein. Zudem ist bei schnellen Richtungswechseln immer zu empfehlen zuerst kurz zu bremsen, um nicht den Motor oder Motortreiber zu stark zu belasten.<br />
<br />
==Ansteuerung mit dem Schaltkreis L298==<br />
<br />
Der Schaltkreis L298 ist quasi der große Bruder des L293D. Er beinhaltet auch zwei komplette H-Brücken, kann also auch zwei Motoren ansteuern. Die Pinbelegung ist ebenfalls dem L293D sehr ähnlich, jedoch verfügt er über eine andere Bauform:<br />
<br />
<br />
[[Bild:L298Pinout.JPG|center]]<br />
<br />
<br />
Der wichtigste Unterschied besteht jedoch darin, dass jede H-Brücke bei L298 bis zu 2A belastet werden kann. Damit lassen sich also schon wesentlich größere Motoren ansteuern. Ein weiterer Vorzug sind die sogenannten SENSE-Ausgänge, über die der komplette Strom fließt. Oft wird hier ein Hochlastwiderstand angeschlossen, um aus der abfallenden Spannung den genauen Strom berechnen zu können. Dies machen sich Steuerungen wie [http://www.roboternetz.de/phpBB2/viewtopic.php?t=2741 RN-Motor] oder aber andere Schrittmotoransteuerungen zunutze, um den Strom genau zu regeln. Benötigt man keine Strommessung, so müssen die Sense-Ausgänge immer direkt mit GND verbunden werden. In diesem Fall muss allerdings eine andere Strombegrenzung eingeplant werden. Wird keine Strombegrenzung eingebaut, müssen diese Widerstände trotztem eingebaut werden, da der Treiber sonst heiss wird.<br />
<br />
<br />
[[Bild:hbrueckel298.gif|center]]<br />
<br />
<br />
Ein weiteres Schaltbild gibt es hier [http://www.roboternetz.de/bilder/schaltung298getriebe.gif]<br />
<br />
==Ansteuerung mit L6205==<br />
Der Schaltkreis L6205 stellt eine etwas modernere Alternative zur L298 Ansteuerung dar. Die Ansteuerung ist praktisch identisch, der Schaltungsaufbau in etwa gleich. Beim L6205 sind keine Freilaufdioden mehr notwendig, dafür ist ein Kondensator und zwei Dioden für die interne Spannungserzeugung notwendig.<br />
Ein großer Vorteil ist auch das kein extra Kühlkörper mehr notwendig ist. Viele integrierte Schutzfunktionen im L6205 sorgen dafür das der Chip nicht so einfach zerstört werden kann. In der Praxis sind die angegeben 2,8A jedoch mit Vorsicht zu geniesen. Bei Testlayouts erwärmten sich die IC´s bereits bei 2A Dauerstrom (PWM) oft so stark das die automatische Temperaturabschaltung reagierte, somit wird man vermutlich ohne Kühlung oder großes Kühllayout auf er Platine auch nicht mehr als beim L298 erreichen. <br />
<br />
[[Bild:l6205ic.gif]] [[Bild:l6205pinbelegung.gif]]<br />
<br />
<br />
[[Bild:l6205.gif|center]]<br />
<br />
==Noch mehr Power gewünscht?==<br />
<br />
Obwohl der L298 schon einiges abdeckt, so kommt er spätestens bei den Scheibenwischermotoren langsam an seine Grenzen. Bei starker Belastung können solche Motoren kurzzeitig bis ca. 10 A und mehr ziehen. Für solch starke Motoren gibt es jetzt einen ganz interessanten Motorchip aus dem KFZ-Bereich: vnh3sp (Datenblatt im Roboternetz Download-Bereich). <br />
Mit ihm lassen sich sogar recht große Motoren ansteuern; vorausgesetzt, man kühlt ihn entsprechend, so verträgt der Chip bis zu 30A. Aber selbst ohne Kühlung bietet er bedeutet mehr Leistung als der L298. Das Schöne, die Ansteuerung ist kaum anders als beim L298 und L293D.<br />
<br />
Kleiner Nachteil: Da es ein SMD-Chip mit 1mm Kontaktabstand ist, muss man schon eine geeignete Platine (spezielles Layout mit Kühlflächen) und etwas Löterfahrung besitzen. Inzwischen gibt es aber schon verschiedene RN-Projekte mit dem Chip (RN-Power, RN-Mini H-Bridge), Platinen und Chip können über den [http://www.shop.robotikhardware.de/shop/catalog/index.php Robotikhardware.de-Platinenservice] bezogen werden. <br />
<br />
<br />
[[Bild:minihbridge_ansteuerung.gif|center]]<br />
<br />
<br />
Alternativ zum [[SMD]]-Chip VNH3SP30 gibt es noch die Alternative VNH2SP30. Dieser Chip erlaubt zwar nur Motorspannungen zwischen 6 und 16 Volt, jedoch hat er einen wesentlich geringeren Innenwiderstand und wird deshalb nur etwa halb so warm wie der VNH3SP30. <br />
Aus diesem Grund eignet er sich auch ideal für kleine Doppelmotorsteuerungen.<br />
Natürlich gibt's auch hierfür ein Projekt und eine Bauanleitung, siehe [[RN-VNH2Dualmotor]]<br />
<br />
Das Schöne ist, dass es dieses RN-Projekt jetzt auch auch als Fertigmodul gibt!<br />
<br />
<br />
[[Bild:rndualmotoransteuerung.jpeg|center]]<br />
<br />
==Endstufen mit I2C-Bus / RS232==<br />
[[Bild:motctrl.png|thumb|Motoransteuerung über RS232, I2C, RC]]Verwendet man eine der oben vorgestellten H-Bridges, so wird immer vorausgesetzt das ein PWM-Signal und mehrere Ports zur Ansteuerung bereitstehen. Ist dies nicht der Fall weil diese vielleicht schon belegt sind, so lassen sich Endstufen durch einen zusätzlichen Microcontroller auch um beliebige Schnittstellen erweitern. Insbesondere über I2C lassen sich dadurch mehrere Motorboards über einen einzigen Bus ansteuern. Ein Beispiel ist der programmierte Controller MOTCTRL, der speziell für diese Aufgabe gedacht ist. Die Grundscháltung sieht man in der rechten Skizze.<br />
<br />
==Und nie vergessen Motoren zu entstören==<br />
<br />
Das Entstören dient dazu, das sogenannte "Bürstenfeuer" zu verhindern, wodurch Störungen hervorgerufen werden könnten. Und so wirds gemacht:<br />
<br />
<br />
[[Bild:entstoerung.gif|center]]<br />
<br />
==Siehe auch==<br />
* [[Getriebemotoren]]<br />
* [[RN-VNH2Dualmotor]]<br />
<br />
==Weblinks==<br />
* [http://www.roboternetz.de/phpBB2/motordrehmoment.php Drehmoment Berechnung]<br />
* [http://www.roboternetz.de/motoruebersicht.html Motoren Übersicht]<br />
* [http://www.shop.robotikhardware.de/shop/catalog/index.php?cPath=65 Bauteilesets]<br />
* [http://www.roboternetz.de/robotertutorial.html Roboter-Tutorial]<br />
* [http://www.roboternetz.de Roboternetz Forum]<br />
<br />
[[Category:Robotikeinstieg]]<br />
[[Category:Praxis]]<br />
[[Category:Grundlagen]]<br />
[[Category:Motoren]]<br />
[[Category:Elektronik]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Getriebemotoren_Ansteuerung&diff=13281Getriebemotoren Ansteuerung2008-03-15T12:10:50Z<p>Overthere: </p>
<hr />
<div>Hat man sich entschlossen, für seinen Roboter oder andere Konstruktion einen Getriebemotor zu verwenden, so muss man sich Gedanken machen, wie man ihn ansteuert. Gewöhnlich will man die Motoren ja sowohl in Bezug auf Drehrichtung und Geschwindigkeit über eine Programmiersprache steuern. Daher wird in der Regel erst mal ein Controllerboard benötigt. Leider kann man an die wenigsten Controllerboards einen Getriebemotor direkt anschließen, eine der wenigen Ausnahmen ist das [[RN-Control]]-Board und das RNBFRA-Board. Bei beiden Boards ist es einfach, dort müssen die Getriebemotoren einfach nur an die Schraubklemmen angeschlossen werden, danach kann man sofort mit der Programmierung loslegen.<br />
<br />
Ich möchte hier aber aufzeigen, wie man Motoren auch bei anderen Boards anschließen kann. Die gleiche Technik läßt sich natürlich auch nutzen, um z.B. mehr als zwei Motoren an [[RN-Control]] anzuschließen.<br />
<br />
==Ansteuerung mit Relais==<br />
<br />
Die einfachste Methode, um Motoren per [[Microcontroller|Controller]] anzusteuern, erreicht man durch die Verwendung von Relais. Mit einem Relais, das zwei Umschaltkontakte besitzt, lässt sich über einen einzelnen Controllerport bequem die Drehrichtung wechseln.<br />
<br />
[[Bild:hbrueckerelais.gif|center]]<br />
<br />
Da auch Relais wegen des Strombedarfes nicht direkt vom Controller geschaltet werden können, wurde in dem oberen Beispiel ein Transistor vorangestellt. Die Diode dient nur dazu, die Spannungen, die beim Ausschalten des Relais induziert werden, abzuleiten. Ohne Diode funktioniert das Ganze in der Regel auch, jedoch könnte der Transistor oder sogar der Controller durch die induzierte Spannung beschädigt werden. <br />
Die Schaltung ist also in der Lage, die Drehrichtung umzuschalten, jedoch nicht in der Lage, den Motor zu stoppen. Um den Motor ganz auszuschalten, müsste man noch ein weiteres Relais vorsehen, das die gesamte Motorspannung abschaltet. Ein Schaltbild können wir uns ersparen, da das Ganze recht ähnlich aussieht. <br />
Der große Nachteil von Relaisschaltungen ist, dass die Geschwindigkeit des Motors nicht geregelt werden kann, zudem haben Relais bei sehr vielen Schaltvorgängen einen gewissen Verschleiß. <br />
Vorteil der Schaltung ist jedoch, das man auch sehr große Lasten/Motoren schalten kann.<br />
<br />
==Ansteuerung mit MOS-FET==<br />
===Neufassung===<br />
{{Ausbauwunsch|Die Neufassung kann im momentanen Stand nur als Anregung verstanden werden.<br />
<br />
Insbesondere fehlen noch angepasste Schaltpläne.<br />
<br />
Einige der Anmerkungen aus dem Abschnitt "Kritik an der Schaltung" sind in der Neufassung noch nicht enthalten, die Beschreibung von Verzögerungsgliedern müsste auch eine Erklärung enthalten, welche Verzögerung mit welchen Werten erreicht wird.<br />
<br />
Wenn die Neufassung komplett fertig ist, sollten die alten Texte weg.<br />
}}<br />
====Grundprinzip====<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz.<br />
<br />
Die Grundschaltung besteht aus 2 N-Kanal-MOSFET (hier BUZ11) und zwei P-Kanal-MOSFET (hier IRF5305), mit denen die Motoranschlüsse nach GND bzw. UB geschaltet werden. Zusätzlich sind noch 4 Schottky-Dioden (z.B. SB530) erforderlich, um Induktionsströme des Motors abzuleiten. Die Dioden werden in Sperrichtung von den beiden Motoranschlüssen nach GND bzw. UB geschaltet.<br />
<br />
Grundsätzlich muss die Beschaltung der Gate-Eingänge so erfolgen, dass zum Starten des Motors die Transistoren einer Diagonale auf "leitend" und die der anderen auf "sperrend" geschaltet werden. Zum Anhalten des Motors werden z.B. die unteren auf leitend und die oberen auf sperrend geschaltet - Der Motor wird dadurch schnell abgebremst, denn durch einen Transistor und eine Freilaufdiode fließt ein nicht unerheblicher Bremsstrom.<br />
Alternativ kann man auch alle Transistoren auf sperrend schalten, der Motor läuft dann im Leerlauf aus.<br />
<br />
Die Transistoren einer Seite dürfen nicht dauerhaft gleichzeitig auf "leitend" geschaltet werden, da dies einen Kurzschluss verursacht.<br />
<br />
Hinweis: Zumindestens bei dem Transistor BUZ11 handelt es sich um ein veraltetes Modell. Wenn es auf hohe Leistung ankommt, sollte da ein anderer Transistor gewählt werden.<br />
<br />
====Elektrische Ansteuerung der Gates====<br />
Beim Umschalten der Transistoren entsteht eine erhöhte Verlustleistung - der Widerstand wechselt von sperrend (sehr großer Widerstand) nach leitend (sehr kleiner Widerstand) und umgekehrt.<br />
<br />
Zwischen beiden Enden des Schaltvorgangs befindet sich der Transistor in der "Widerstandsphase" (weder ganz leitend, noch ganz sperrend), die eine erhebliche Verlustleistung und damit Erwärmung mit sich bringt.<br />
<br />
Deshalb sollte der Schaltvorgang - insbesondere wenn für eine PWM-Gegelung sehr oft geschaltet werden soll - möglichst schnell erfolgen. Da zum Umschalten die durch den Aufbau des MOSFETs bedingte Gatekapazität umgeladen werden muss, ist hierzu (sehr kurzzeitig) ein hoher Stromfluss nötig.<br />
=====Schaltung direkt am Port=====<br />
Eine Ansteuerung unmittelbar über den Ausgang eines Mikrocontrollers (oder eines TTL-IC) ist schon wegen der benötigten Spannungen nicht möglich. <br />
<br />
Bei den N-FET könnte man sog. "Logik-MOSFET" nehmen, die bereits bei 5V ausreichend leitet. <br />
<br />
Bei den P-MOSFET bemisst sich die Schaltspannung gegen UB, mit einem 5V Port und UB=12V würde also zwischen -12V und -7V umgeschaltet, was einen P-MOSFET erfordern würde, der bereits bei -7V sperrt.<br />
<br />
Dass ein Portpin nur einen geringen Stromfluss (~20mA) zulässt, ist ein weiteres Problem und verhindert einen Schaltvorgang mit idealer steiler Flanke. Allerdings ist die Schaltungsvariante mit einem Transistor in diesem Punkt keinesfalls besser, wenn die Gatekapazität durch den PullUp-Widerstand umgeladen werden muss.<br />
=====Schaltung mit einem Transistor=====<br />
Eine einfache Steuerschaltung besteht aus einem Transistor-Schalter und einem Pull-Up-Widerstand. Als Schalter hab ich 1/7 eines ULN2003 IC verwendet, als PullUp 2200 Ohm. Ein diskreter Aufbau mit 1 Transistor und 2 Widerständen ist aber auch nicht komplizierter.<br />
<br />
Der Vorteil liegt in der Einfachheit, der Nachteil liegt darin, dass die Schaltung nicht sonderlich schnell vonstatten geht: Für die Schaltung des FET muss die Gate-Kapazität transferiert werden, was insbesondere beim Wechsel von 0V nach UB einen Moment dauert, da die Ladung durch den Widerstand hindurch muss.<br />
<br />
Ein kleinerer Widerstand könnte hier helfen, verursacht allerdings einen nicht unerheblichen Stromfluss im geschalteten Zustand (zulässige Verlustleistung beachten).<br />
=====Schaltung mit zwei Transistoren=====<br />
Eine bessere Ansteuerung sollte sich ergeben, wenn man zwei Transistoren zur Gate-Ansteuerung verwendet: Einer schaltet gegen 0V, der andere Gegen UC. So kann man erreichen, dass in beide Richtungen rasch umgeschaltet werden kann.<br />
=====Integrierte Gate-Treiber=====<br />
Statt der Beschaltung mit zwei Transistoren kann man auch einen integrierten MOSFET-Treiber verwenden. Mit derartige IC sind darauf ausgelegt, kurzfristig den für eine Umschaltung benötigten hohen Stromfluss zu ermöglichen.<br />
<br />
Es gibt auch Treiber-IC, die zur Ansteuerung der oberen Transistoren eine Spannung oberhalb von UB erzeugen. Mit solchen Highside-Treibern kann die H-Brücke auch aus 4 N-Kanal-Transistoren gebaut werden, was den Vorteil hat, dass N-Kanal-FET mit geringerem Schaltwiderstand zu bekommen sind.<br />
<br />
====Logische Ansteuerung der Gates====<br />
Nach der elektrischen Ansteuerung ist die logische Ansteuerung durch den Mikrocontroller zu überlegen.<br />
<br />
=====Mögliche Querströme=====<br />
In der H-Brücke sind zwei problematische Zustände zu berücksichtigen:<br />
<br />
1. Das offensichtliche Problem ist ein Kurzschluss: Wenn beide Transistoren einer Seite auf leitend geschaltet werden wird dadurch ein Kurzschluss erzeugt. Falls vorhanden brennt die Sicherung durch - ist keine Sicherung vorhanden, brennt was anderes durch.<br />
<br />
2. Ein nicht so offensichtliches Problem rührt daher, dass der Schaltvorgang nur mit endlicher Geschwindigkeit abläuft und der Transistor auch schon vor Erreichen des Zielwertes der Gate-Spannung erheblichen Strom leitet. Hierdurch kommt es zu einem Kurzschluss durch den nicht mehr richtig gesperrten und den noch nicht richtig gesperrten Transistor.<br />
<br />
Die Stromspitze selbst liegt noch im Rahmen der Spezifikationen der Transistoren. Sofern ein Messwiderstand von z.B. 0,1 Ohm da ist oder die Spannungsquelle einen vergleichbaren Innenwiderstand hat fließt ein Strom von weniger als 70A, die Transistoren sind jeweils für Spitzen von über 100A spezifiziert.<br />
<br />
Allerdings hat die Stromspitze drei Auswirkungen: <br />
<br />
# Die Transistoren erwärmen sich<br />
# Es kann an einem Messwiderstand zu einer Spannungsspitze kommen<br />
# Die Versorgungsspannung bricht kurzzeitig zusammen<br />
<br />
----<br />
<br />
Die Erwärmung des Transistors ist solange kein Problem, wie nur selten umgeschaltet wird. Bei einer Regelung per PWM könnten sich die kleinen Energiemengen zu einem relevanten Problem addieren. <br />
<br />
Da die Erwärmung - sofern sie relevant wird - leicht ohne Messinstrumente feststellbar ist, dürfte dieser Teil des Problems insofern handhabbar sein, als man leicht feststellen kann, ob das Problem relevant ist und das Problem auf die Transistoren beschränkt sind.<br />
<br />
Bei Leerlauf-Schaltvorgängen im Abstand von 1/15 Sekunden habe ich keine Erwärmung der Transistoren feststellen können, es wurden auch keine zusätzlichen Kühlkörper verwendet.<br />
<br />
----<br />
Die Spannungsspitze am Messwiderstand kann abgeleitet werden:<br />
Als weitere Vorsichtsmaßnahme habe ich den Messport des Controllers mit einem Widerstand und einer Z5.1 Diode abgesichert.<br />
<br />
----<br />
<br />
Die Störung der Versorgungsspannung lässt sich ohne Oszilloskop nicht messen. Insbesondere in umfangreicheren Schaltungen können Störungen an ganz anderen Stellen (z.B. bei Sensoren) auftreten, die man dann nicht gleich mit der Motorsteuerung in Verbindung bringt.<br />
<br />
Um die Störung vom Controller fernzuhalten habe ich dem Spannungswandler vorsichtshalber eine kleine Schottky-Diode (SB140) vorgeschaltet, um ein Entladen des Stützkondensators zu verhindern.<br />
<br />
=====softwaremäßige Ansteuerung=====<br />
Die einfachste Art der Ansteuerung besteht darin, die Schalter der 4 Gates mit 4 Ausgängen des Controllers zu verbinden.<br />
<br />
Die korrekte Ansteuerung muss dann durch die Software garantiert werden. <br />
<br />
Eine Fehlschaltung der Software z.B. bei einem Absturz kann allerdings zur Zerstörung der Schaltung führen, die Schaltung sollte also in jedem Fall eine Sicherung haben.<br />
<br />
=====Einfache Ansteuerung=====<br />
Etwas sicherer ist es, die Schaltung so aufzubauen, dass ein Kurzschluss nicht dauerhaft geschaltet werden kann.<br />
<br />
Hierzu habe ich die Schaltung so aufgebaut, dass die Gates einer Seite jeweils gemeinsam geschaltet werden. <br />
<br />
Bei einer Gate-Spannung von 0V sperrt der N-MOSFET (U<sub>GS</sub>=0V), der P-MOSFET leitet bei dieser Gate-Spannung, da hier U<sub>GS</sub>=-UB ist. <br />
<br />
Bei einer Gate-Spannung von UB verhält es sich genau umgekehrt: Der N-MOSFET leitet (U<sub>GS</sub>=UB) und der P-MOSFET sperrt (U<sub>GS</sub>=0V)<br />
<br />
Diese einfache Ansteuerung benötigt lediglich zwei Transistorschalter und auch nur 2 Port-Pins, hat jedoch den Nachteil, dass die oben beschriebenen Querströme auftreten.<br />
=====Verbesserungsmöglichkeiten=====<br />
Zur Lösung des Querstrom-Problems gibt es mehrere Ansatzmöglichkeiten, die ebenfalls mit zwei Controller-Ausgängen auskommen.<br />
----<br />
Mittels Logik-Bausteinen werden zwei Ausgänge des Controllers so umgesetzt, dass die folgenden Zustände geschaltet werden können:<br />
<br />
# Motor-Stop: untere Transistoren leitend, obere sperrend (oder umgekehrt)<br />
# Motor-Vorlauf: 1. Diagolale leitend<br />
# Motor-Rücklauf: 2. Diagonale leitend<br />
# Motor-Leerlauf: Alle Transistoren sperrend<br />
<br />
Die Querstrom-Problematik kann hierbei softwaremäßig gelöst werden, indem beim Umschalten jeweils kurz der Leerlauf geschaltet wird, damit alle Transistoren sperren.<br />
----<br />
Eine andere Möglichkeit besteht darin, das Umladen der Gate-Kapazität asymmetrisch zu gestalten, so dass die Transistoren schneller auf sperrend als auf leitend geschaltet werden. Eine einfache Möglichkeit ist die Parallelschaltung einer Diode und eines Widerstandes: In Sperr-Richtung fließt die Ladung langsamer als in die Durchlass-Richtung.<br />
===Heidingscher Encoder===<br />
Aufgrund der Kritik an der Schaltung entschied ich mich einen neuen, einfachen sowie preisgünstigen Encoder zu entwickeln, den man mit der 74series aufbauen kann. Als Treiber können sowohl Transistoren verwendet werden, dabei aber Vorwiderstände nicht vergessen! Die 74series sind mit 20mA Treiberstrom also natürlich nicht zum direkten Treiben geeignet.<br />
Die Logikanzeigen in den Grafiken sollen je einen Transistor bzw. Mosfet darstellen. Eventuelle Freilaufdioden müssen natürlich noch hinzugefügt werden.<br />
====PR Encoder====<br />
[[Bild:Prtreiber.png]]<br />
<br />
Der PR Encoder(PWM-Richtung Encoder) ist mit zwei NOR Gates sowie eines Inverters aufgebaut, d.h. man kann ihn mit nur einem IC(74HC(T)02) aufbauen. Will mein 2 Encoder verwenden, empfliehlt sich den Inverter auszulagern (74HC(T)04 oder 74HC(T)14 Sollte man keinen Schmitt-Trigger benötigen empfiehlt sich aus Schnelligkeitsgründen die 74HC(T)04 Variante). <br />
Alternativ ist es noch möglich sich den Inverter zu sparen, und die Ansteuerung für den P(WM) Kanal invertiert laufen zu lassen. <br />
====PRK Encoder====<br />
[[Bild:Prktreiber.png]]<br />
<br />
Der Prk-Encoder(PWM-Richtung-Kurzschluss-Encoder) ist eine Erweiterung des PR-Encoders. Er erlaubt es zusätzlich, die Motoren durch einen Kurzschluss zu stoppen.<br />
Aufgebaut werden kann dieser aus 1 NOR und 1 Nand Gate. Dabei werden 3 Nand-Gates als Inverter beschaltet. (d.h. eine die Leitung die übrig bleibt auf Vcc).<br />
====Support====<br />
Fragen einfach in das Forum posten, oder mich anschreiben(User s.o.)<br />
===Alte Schaltungsbeschreibung===<br />
{{FarbigerRahmen|<br />
Achtung! Die Schaltung ist so nicht zu verwenden! Siehe unter '''Kritik an der Schaltung'''<br />
}}<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz. Eine der interessantesten Schaltungen, die im Roboternetz vorgestellt wurde, dürfte diese sein:<br />
<br />
<br />
[[Bild:hbrueckemosfet.gif|center]]<br />
<br />
<br />
Anmerkung: Den 74HC26N gibts wohl nicht , nur die TTL-Version 74LS26, die HC-Mos-Version lautet 74HC03.<br />
<br />
Eine sogenannte H-Brücke, die nur aus zwei MOSFETSs und einem Logik-IC besteht. Mit zwei Controllerports kann diese Schaltung sowohl Geschwindigkeit als auch Drehrichtung regeln. Für die Geschwindigkeit ist ein sogenannter [[PWM]]-Port notwendig. Also ein Port, der durch ein gepulstes Signal den Motor etlichemal innerhalb einer Sekunde ein- und ausschaltet und somit quasi die Leistung regelt (siehe [[PWM]]).<br />
Die Schaltung ist so konstruiert, dass immer nur zwei Transistoren durchschalten. Auf diese Weise fließt einmal der Strom von links oben nach rechts unten und einmal von rechts oben nach links unten, der Motor wird also ähnlich wie bei der Relaisschaltung umgepolt. <br />
Bei niedriger [[PWM]]_Frequenz sollte die Schaltung durchaus für einige Ampere geeignet sein, wobei ca. 8 bis 13V ideal sein sollten.<br />
<br />
Das Logic-IC wurde durch 3x BC547 Transitoren ersetzt.<br />
<br />
<br />
[[Bild:Hbrückenmosfet BD547.PNG|center|900px]]<br />
<br />
====Kritik an der Schaltung====<br />
<br />
Diese Schaltung wird im Forum von mehreren Leuten, u.A. Ratber, shaun, massiv kritisiert, z.B. hier: http://www.roboternetz.de/phpBB2/viewtopic.php?t=33067&sid=892e80c6cd2d003292e607bcd7a7123a .<br />
<br />
Ich habe leider nicht das Wissen eine bessere Lösung zu liefern. Das Problem sind die Querströme: Im Umschaltmoment sind highside und lowside switch für kurze Zeit beide leitend. Das entspricht einem Kurzschluss der Versorgungsleitung bei jedem Umschalten mit allen damit verbundenen Problemen (Erwärmung, Schwingung, Sicherungen, Reset). Aus diesem Grund sind NAND-Gatter nicht geeignet!<br />
<br />
Zum Umschalten muss man<br />
*den bisher leitenden Mosfet ausschalten,<br />
*dann etwas warten,<br />
*und schließlich den nächsten Mosfet schließen.<br />
<br />
Dies kann man erreichen, indem man den Einschaltmoment <br />
*durch RC-Glieder verzögert und <br />
*den Ausschaltmoment durch Dioden beschleunigt.<br />
Die entstehenden Schaltungen sind komplex, benötigen viele Bauteile und sind fehleranfällig.<br />
<br />
<br />
Am sinnvollsten sind integrierte Mosfet-Treiber. Diese haben oft eine einstellbare Tot-Zeit (''Dead-Time''), können hohe Leistungen zum Umladen der Gatekapazität liefern und beachten andere Effekte wie ''Propagation-Time'', Veränderung des Source Potentials beim Highside-switch, etc.<br />
<br />
'''Erklärung von shaun:'''<br />
<br />
die gezeigte Schaltung taugt auch nur als Prinzipschaltung bedingt, da man einen variierenden Aufwand in eine sichere Verriegelung investieren müsste. Bei fixer und nicht zu hoher Betriebsspannung könnte man mit RD-Kombinationen in den Gateleitungen das Ausschalten beschleunigen und das Einschalten verzögern, so dass die Querleitung wegfällt. Allerdings bewirkt diese simple R-Cg-Verzögerung größere Schaltverluste. <br />
<br />
Setzt man die Vezögerung vor dedizierte Treiber, müssen diese wiederum leistungsfähig genug zum Umladen der Gates sein und bis an die Versorgung heranreichen, weshalb man an diesem Punkt überlegen sollte, ob 95% duty cycle nicht auch reichen würden ''(Anmerkung: Bezug auf bootstrapping?)'' und man integrierte Treiber für reine N-Kanal-Bestückung einsetzen sollte - spart dann wieder etwas Verluste am Highside-Switch, weil N-Kanäler gleicher Generation und Leistungsklasse einen niedrigeren Rds(on) als ihre P-Pendants haben.<br />
<br />
{{Ausbauwunsch|Eine vernünftige diskrete Ansteuerung für eine H-Brücke.<br />
Korrektur auf Rechtschreibfehler, Zeichensetzung, Schreibstil, Fachausdrücke. Gibt's denn keinen der etwas verbessern möchte?}}<br />
==Ansteuerung mit einem LeistungsOPV==<br />
Die wohl preislich und platztechnisch günstigste Alternative zur Ansteuerung von Motoren in H-Brücken ist die Verwendung von (Leistungs-)Operationsverstärkern. <br />
===Heidingscher Motortreiber=== <br />
Bei dem Heidingschen Motortreiber wird jeder Anschluss des Motors mit einem Ausgang des Operationsverstärker verbunden, die Eingänge des OPVs selbst als Komparator. Diese Methode ist für kleine und mittlere Motoren(=< 1A) und mäßige PWM-Frequenzen(<10kHz) gut geeignet. Ein RB35 von Conrad kann damit problemlos angesteuert werden. Bei zu hohen PWM-Frequenzen ist die SlewRate von vielen OPVs zu gering und die entsprechenden OPVs sind dann viel zu teuer und man sollte eine Ansteuerung per Mosfet(s.o.) bevorzugen. Momentan hat sich der TCA 0372 DP1 (57ct bei Reichelt) Verwendung gefunden. <br />
Weitere Informationen sind in folgendem Forumsbeitrag zu finden:<br />
http://www.roboternetz.de/phpBB2/viewtopic.php?t=38412<br />
===Gleichstromansteuerung===<br />
Eine weitere Möglichkeit ist es, dem Operationsverstärker eine Gleichspannung vorzugeben, mit denen der OPV die Motoren ansteuert. Diese Methode eignet sich sehr gut für analoge Schaltkreise. Der Wirkungsgrad ist allerdings nicht der beste, da die restliche Spannung in Wärme umgesetzt wird. Zudem werden viele weitere komponenten benötigt, dass den Aufbau treuerer und fehleranfälliger macht.<br />
Der entsprechenden Schaltkreis ist im Datenblatt des TCA 0372 DP1 zu finden.<br />
<br />
==Ansteuerung mit Treiber IC L293 D==<br />
<br />
Dies ist ohne Zweifel die am häufigsten genutzte Ansteuerung bei Roboter-Bastlern: Man nimmt einfach das IC L293D, denn darin sind sogar zwei H-Brücken enthalten. Also mit einem IC lassen sich ohne weiteres externe Bauteile gleich zwei Motoren ansteuern. Zwar nur bis ca. 600mA, aber das reicht oft schon für kleinere bis mittlere Roboteranwendungen aus.<br />
<br />
[[Bild:L293Pinout.JPG|center]]<br />
<br />
<br />
[[Bild:hbrueckel293d.gif|center]]<br />
<br />
Wie aus dem Schaltbild zu ersehen ist, werden für die Ansteuerung jedes Motors 3 Ports benötigt. Die Enable-Leitung führt man oft auf einen PWM-Port welcher wie bei der MOS-FET Schaltung oben die Geschwindigkeit regelt. Die beiden anderen Ports geben die Drehrichtung an. Immer wenn die Ports unterschiedliche Polarität haben dreht der Motor in eine bestimmte Richtung, je nachdem wo Low und High anliegt. Das Besondere ist, dass wenn an beiden Ports der gleiche Pegel anliegt, also zweimal Low oder High, dann wird nämlich der Motor kurzgeschlossen - das fungiert als Bremse. Das Bremsen kann bei Robotern durchaus nützlich sein. Zudem ist bei schnellen Richtungswechseln immer zu empfehlen zuerst kurz zu bremsen, um nicht den Motor oder Motortreiber zu stark zu belasten.<br />
<br />
==Ansteuerung mit dem Schaltkreis L298==<br />
<br />
Der Schaltkreis L298 ist quasi der große Bruder des L293D. Er beinhaltet auch zwei komplette H-Brücken, kann also auch zwei Motoren ansteuern. Die Pinbelegung ist ebenfalls dem L293D sehr ähnlich, jedoch verfügt er über eine andere Bauform:<br />
<br />
<br />
[[Bild:L298Pinout.JPG|center]]<br />
<br />
<br />
Der wichtigste Unterschied besteht jedoch darin, dass jede H-Brücke bei L298 bis zu 2A belastet werden kann. Damit lassen sich also schon wesentlich größere Motoren ansteuern. Ein weiterer Vorzug sind die sogenannten SENSE-Ausgänge, über die der komplette Strom fließt. Oft wird hier ein Hochlastwiderstand angeschlossen, um aus der abfallenden Spannung den genauen Strom berechnen zu können. Dies machen sich Steuerungen wie [http://www.roboternetz.de/phpBB2/viewtopic.php?t=2741 RN-Motor] oder aber andere Schrittmotoransteuerungen zunutze, um den Strom genau zu regeln. Benötigt man keine Strommessung, so müssen die Sense-Ausgänge immer direkt mit GND verbunden werden. In diesem Fall muss allerdings eine andere Strombegrenzung eingeplant werden. Wird keine Strombegrenzung eingebaut, müssen diese Widerstände trotztem eingebaut werden, da der Treiber sonst heiss wird.<br />
<br />
<br />
[[Bild:hbrueckel298.gif|center]]<br />
<br />
<br />
Ein weiteres Schaltbild gibt es hier [http://www.roboternetz.de/bilder/schaltung298getriebe.gif]<br />
<br />
==Ansteuerung mit L6205==<br />
Der Schaltkreis L6205 stellt eine etwas modernere Alternative zur L298 Ansteuerung dar. Die Ansteuerung ist praktisch identisch, der Schaltungsaufbau in etwa gleich. Beim L6205 sind keine Freilaufdioden mehr notwendig, dafür ist ein Kondensator und zwei Dioden für die interne Spannungserzeugung notwendig.<br />
Ein großer Vorteil ist auch das kein extra Kühlkörper mehr notwendig ist. Viele integrierte Schutzfunktionen im L6205 sorgen dafür das der Chip nicht so einfach zerstört werden kann. In der Praxis sind die angegeben 2,8A jedoch mit Vorsicht zu geniesen. Bei Testlayouts erwärmten sich die IC´s bereits bei 2A Dauerstrom (PWM) oft so stark das die automatische Temperaturabschaltung reagierte, somit wird man vermutlich ohne Kühlung oder großes Kühllayout auf er Platine auch nicht mehr als beim L298 erreichen. <br />
<br />
[[Bild:l6205ic.gif]] [[Bild:l6205pinbelegung.gif]]<br />
<br />
<br />
[[Bild:l6205.gif|center]]<br />
<br />
==Noch mehr Power gewünscht?==<br />
<br />
Obwohl der L298 schon einiges abdeckt, so kommt er spätestens bei den Scheibenwischermotoren langsam an seine Grenzen. Bei starker Belastung können solche Motoren kurzzeitig bis ca. 10 A und mehr ziehen. Für solch starke Motoren gibt es jetzt einen ganz interessanten Motorchip aus dem KFZ-Bereich: vnh3sp (Datenblatt im Roboternetz Download-Bereich). <br />
Mit ihm lassen sich sogar recht große Motoren ansteuern; vorausgesetzt, man kühlt ihn entsprechend, so verträgt der Chip bis zu 30A. Aber selbst ohne Kühlung bietet er bedeutet mehr Leistung als der L298. Das Schöne, die Ansteuerung ist kaum anders als beim L298 und L293D.<br />
<br />
Kleiner Nachteil: Da es ein SMD-Chip mit 1mm Kontaktabstand ist, muss man schon eine geeignete Platine (spezielles Layout mit Kühlflächen) und etwas Löterfahrung besitzen. Inzwischen gibt es aber schon verschiedene RN-Projekte mit dem Chip (RN-Power, RN-Mini H-Bridge), Platinen und Chip können über den [http://www.shop.robotikhardware.de/shop/catalog/index.php Robotikhardware.de-Platinenservice] bezogen werden. <br />
<br />
<br />
[[Bild:minihbridge_ansteuerung.gif|center]]<br />
<br />
<br />
Alternativ zum [[SMD]]-Chip VNH3SP30 gibt es noch die Alternative VNH2SP30. Dieser Chip erlaubt zwar nur Motorspannungen zwischen 6 und 16 Volt, jedoch hat er einen wesentlich geringeren Innenwiderstand und wird deshalb nur etwa halb so warm wie der VNH3SP30. <br />
Aus diesem Grund eignet er sich auch ideal für kleine Doppelmotorsteuerungen.<br />
Natürlich gibt's auch hierfür ein Projekt und eine Bauanleitung, siehe [[RN-VNH2Dualmotor]]<br />
<br />
Das Schöne ist, dass es dieses RN-Projekt jetzt auch auch als Fertigmodul gibt!<br />
<br />
<br />
[[Bild:rndualmotoransteuerung.jpeg|center]]<br />
<br />
==Endstufen mit I2C-Bus / RS232==<br />
[[Bild:motctrl.png|thumb|Motoransteuerung über RS232, I2C, RC]]Verwendet man eine der oben vorgestellten H-Bridges, so wird immer vorausgesetzt das ein PWM-Signal und mehrere Ports zur Ansteuerung bereitstehen. Ist dies nicht der Fall weil diese vielleicht schon belegt sind, so lassen sich Endstufen durch einen zusätzlichen Microcontroller auch um beliebige Schnittstellen erweitern. Insbesondere über I2C lassen sich dadurch mehrere Motorboards über einen einzigen Bus ansteuern. Ein Beispiel ist der programmierte Controller MOTCTRL, der speziell für diese Aufgabe gedacht ist. Die Grundscháltung sieht man in der rechten Skizze.<br />
<br />
==Und nie vergessen Motoren zu entstören==<br />
<br />
Das Entstören dient dazu, das sogenannte "Bürstenfeuer" zu verhindern, wodurch Störungen hervorgerufen werden könnten. Und so wirds gemacht:<br />
<br />
<br />
[[Bild:entstoerung.gif|center]]<br />
<br />
==Siehe auch==<br />
* [[Getriebemotoren]]<br />
* [[RN-VNH2Dualmotor]]<br />
<br />
==Weblinks==<br />
* [http://www.roboternetz.de/phpBB2/motordrehmoment.php Drehmoment Berechnung]<br />
* [http://www.roboternetz.de/motoruebersicht.html Motoren Übersicht]<br />
* [http://www.shop.robotikhardware.de/shop/catalog/index.php?cPath=65 Bauteilesets]<br />
* [http://www.roboternetz.de/robotertutorial.html Roboter-Tutorial]<br />
* [http://www.roboternetz.de Roboternetz Forum]<br />
<br />
[[Category:Robotikeinstieg]]<br />
[[Category:Praxis]]<br />
[[Category:Grundlagen]]<br />
[[Category:Motoren]]<br />
[[Category:Elektronik]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Getriebemotoren_Ansteuerung&diff=13280Getriebemotoren Ansteuerung2008-03-15T12:10:22Z<p>Overthere: nochmals layout gefixed</p>
<hr />
<div>Hat man sich entschlossen, für seinen Roboter oder andere Konstruktion einen Getriebemotor zu verwenden, so muss man sich Gedanken machen, wie man ihn ansteuert. Gewöhnlich will man die Motoren ja sowohl in Bezug auf Drehrichtung und Geschwindigkeit über eine Programmiersprache steuern. Daher wird in der Regel erst mal ein Controllerboard benötigt. Leider kann man an die wenigsten Controllerboards einen Getriebemotor direkt anschließen, eine der wenigen Ausnahmen ist das [[RN-Control]]-Board und das RNBFRA-Board. Bei beiden Boards ist es einfach, dort müssen die Getriebemotoren einfach nur an die Schraubklemmen angeschlossen werden, danach kann man sofort mit der Programmierung loslegen.<br />
<br />
Ich möchte hier aber aufzeigen, wie man Motoren auch bei anderen Boards anschließen kann. Die gleiche Technik läßt sich natürlich auch nutzen, um z.B. mehr als zwei Motoren an [[RN-Control]] anzuschließen.<br />
<br />
==Ansteuerung mit Relais==<br />
<br />
Die einfachste Methode, um Motoren per [[Microcontroller|Controller]] anzusteuern, erreicht man durch die Verwendung von Relais. Mit einem Relais, das zwei Umschaltkontakte besitzt, lässt sich über einen einzelnen Controllerport bequem die Drehrichtung wechseln.<br />
<br />
[[Bild:hbrueckerelais.gif|center]]<br />
<br />
Da auch Relais wegen des Strombedarfes nicht direkt vom Controller geschaltet werden können, wurde in dem oberen Beispiel ein Transistor vorangestellt. Die Diode dient nur dazu, die Spannungen, die beim Ausschalten des Relais induziert werden, abzuleiten. Ohne Diode funktioniert das Ganze in der Regel auch, jedoch könnte der Transistor oder sogar der Controller durch die induzierte Spannung beschädigt werden. <br />
Die Schaltung ist also in der Lage, die Drehrichtung umzuschalten, jedoch nicht in der Lage, den Motor zu stoppen. Um den Motor ganz auszuschalten, müsste man noch ein weiteres Relais vorsehen, das die gesamte Motorspannung abschaltet. Ein Schaltbild können wir uns ersparen, da das Ganze recht ähnlich aussieht. <br />
Der große Nachteil von Relaisschaltungen ist, dass die Geschwindigkeit des Motors nicht geregelt werden kann, zudem haben Relais bei sehr vielen Schaltvorgängen einen gewissen Verschleiß. <br />
Vorteil der Schaltung ist jedoch, das man auch sehr große Lasten/Motoren schalten kann.<br />
<br />
==Ansteuerung mit MOS-FET==<br />
===Neufassung===<br />
{{Ausbauwunsch|Die Neufassung kann im momentanen Stand nur als Anregung verstanden werden.<br />
<br />
Insbesondere fehlen noch angepasste Schaltpläne.<br />
<br />
Einige der Anmerkungen aus dem Abschnitt "Kritik an der Schaltung" sind in der Neufassung noch nicht enthalten, die Beschreibung von Verzögerungsgliedern müsste auch eine Erklärung enthalten, welche Verzögerung mit welchen Werten erreicht wird.<br />
<br />
Wenn die Neufassung komplett fertig ist, sollten die alten Texte weg.<br />
}}<br />
====Grundprinzip====<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz.<br />
<br />
Die Grundschaltung besteht aus 2 N-Kanal-MOSFET (hier BUZ11) und zwei P-Kanal-MOSFET (hier IRF5305), mit denen die Motoranschlüsse nach GND bzw. UB geschaltet werden. Zusätzlich sind noch 4 Schottky-Dioden (z.B. SB530) erforderlich, um Induktionsströme des Motors abzuleiten. Die Dioden werden in Sperrichtung von den beiden Motoranschlüssen nach GND bzw. UB geschaltet.<br />
<br />
Grundsätzlich muss die Beschaltung der Gate-Eingänge so erfolgen, dass zum Starten des Motors die Transistoren einer Diagonale auf "leitend" und die der anderen auf "sperrend" geschaltet werden. Zum Anhalten des Motors werden z.B. die unteren auf leitend und die oberen auf sperrend geschaltet - Der Motor wird dadurch schnell abgebremst, denn durch einen Transistor und eine Freilaufdiode fließt ein nicht unerheblicher Bremsstrom.<br />
Alternativ kann man auch alle Transistoren auf sperrend schalten, der Motor läuft dann im Leerlauf aus.<br />
<br />
Die Transistoren einer Seite dürfen nicht dauerhaft gleichzeitig auf "leitend" geschaltet werden, da dies einen Kurzschluss verursacht.<br />
<br />
Hinweis: Zumindestens bei dem Transistor BUZ11 handelt es sich um ein veraltetes Modell. Wenn es auf hohe Leistung ankommt, sollte da ein anderer Transistor gewählt werden.<br />
<br />
====Elektrische Ansteuerung der Gates====<br />
Beim Umschalten der Transistoren entsteht eine erhöhte Verlustleistung - der Widerstand wechselt von sperrend (sehr großer Widerstand) nach leitend (sehr kleiner Widerstand) und umgekehrt.<br />
<br />
Zwischen beiden Enden des Schaltvorgangs befindet sich der Transistor in der "Widerstandsphase" (weder ganz leitend, noch ganz sperrend), die eine erhebliche Verlustleistung und damit Erwärmung mit sich bringt.<br />
<br />
Deshalb sollte der Schaltvorgang - insbesondere wenn für eine PWM-Gegelung sehr oft geschaltet werden soll - möglichst schnell erfolgen. Da zum Umschalten die durch den Aufbau des MOSFETs bedingte Gatekapazität umgeladen werden muss, ist hierzu (sehr kurzzeitig) ein hoher Stromfluss nötig.<br />
=====Schaltung direkt am Port=====<br />
Eine Ansteuerung unmittelbar über den Ausgang eines Mikrocontrollers (oder eines TTL-IC) ist schon wegen der benötigten Spannungen nicht möglich. <br />
<br />
Bei den N-FET könnte man sog. "Logik-MOSFET" nehmen, die bereits bei 5V ausreichend leitet. <br />
<br />
Bei den P-MOSFET bemisst sich die Schaltspannung gegen UB, mit einem 5V Port und UB=12V würde also zwischen -12V und -7V umgeschaltet, was einen P-MOSFET erfordern würde, der bereits bei -7V sperrt.<br />
<br />
Dass ein Portpin nur einen geringen Stromfluss (~20mA) zulässt, ist ein weiteres Problem und verhindert einen Schaltvorgang mit idealer steiler Flanke. Allerdings ist die Schaltungsvariante mit einem Transistor in diesem Punkt keinesfalls besser, wenn die Gatekapazität durch den PullUp-Widerstand umgeladen werden muss.<br />
=====Schaltung mit einem Transistor=====<br />
Eine einfache Steuerschaltung besteht aus einem Transistor-Schalter und einem Pull-Up-Widerstand. Als Schalter hab ich 1/7 eines ULN2003 IC verwendet, als PullUp 2200 Ohm. Ein diskreter Aufbau mit 1 Transistor und 2 Widerständen ist aber auch nicht komplizierter.<br />
<br />
Der Vorteil liegt in der Einfachheit, der Nachteil liegt darin, dass die Schaltung nicht sonderlich schnell vonstatten geht: Für die Schaltung des FET muss die Gate-Kapazität transferiert werden, was insbesondere beim Wechsel von 0V nach UB einen Moment dauert, da die Ladung durch den Widerstand hindurch muss.<br />
<br />
Ein kleinerer Widerstand könnte hier helfen, verursacht allerdings einen nicht unerheblichen Stromfluss im geschalteten Zustand (zulässige Verlustleistung beachten).<br />
=====Schaltung mit zwei Transistoren=====<br />
Eine bessere Ansteuerung sollte sich ergeben, wenn man zwei Transistoren zur Gate-Ansteuerung verwendet: Einer schaltet gegen 0V, der andere Gegen UC. So kann man erreichen, dass in beide Richtungen rasch umgeschaltet werden kann.<br />
=====Integrierte Gate-Treiber=====<br />
Statt der Beschaltung mit zwei Transistoren kann man auch einen integrierten MOSFET-Treiber verwenden. Mit derartige IC sind darauf ausgelegt, kurzfristig den für eine Umschaltung benötigten hohen Stromfluss zu ermöglichen.<br />
<br />
Es gibt auch Treiber-IC, die zur Ansteuerung der oberen Transistoren eine Spannung oberhalb von UB erzeugen. Mit solchen Highside-Treibern kann die H-Brücke auch aus 4 N-Kanal-Transistoren gebaut werden, was den Vorteil hat, dass N-Kanal-FET mit geringerem Schaltwiderstand zu bekommen sind.<br />
<br />
====Logische Ansteuerung der Gates====<br />
Nach der elektrischen Ansteuerung ist die logische Ansteuerung durch den Mikrocontroller zu überlegen.<br />
<br />
=====Mögliche Querströme=====<br />
In der H-Brücke sind zwei problematische Zustände zu berücksichtigen:<br />
<br />
1. Das offensichtliche Problem ist ein Kurzschluss: Wenn beide Transistoren einer Seite auf leitend geschaltet werden wird dadurch ein Kurzschluss erzeugt. Falls vorhanden brennt die Sicherung durch - ist keine Sicherung vorhanden, brennt was anderes durch.<br />
<br />
2. Ein nicht so offensichtliches Problem rührt daher, dass der Schaltvorgang nur mit endlicher Geschwindigkeit abläuft und der Transistor auch schon vor Erreichen des Zielwertes der Gate-Spannung erheblichen Strom leitet. Hierdurch kommt es zu einem Kurzschluss durch den nicht mehr richtig gesperrten und den noch nicht richtig gesperrten Transistor.<br />
<br />
Die Stromspitze selbst liegt noch im Rahmen der Spezifikationen der Transistoren. Sofern ein Messwiderstand von z.B. 0,1 Ohm da ist oder die Spannungsquelle einen vergleichbaren Innenwiderstand hat fließt ein Strom von weniger als 70A, die Transistoren sind jeweils für Spitzen von über 100A spezifiziert.<br />
<br />
Allerdings hat die Stromspitze drei Auswirkungen: <br />
<br />
# Die Transistoren erwärmen sich<br />
# Es kann an einem Messwiderstand zu einer Spannungsspitze kommen<br />
# Die Versorgungsspannung bricht kurzzeitig zusammen<br />
<br />
----<br />
<br />
Die Erwärmung des Transistors ist solange kein Problem, wie nur selten umgeschaltet wird. Bei einer Regelung per PWM könnten sich die kleinen Energiemengen zu einem relevanten Problem addieren. <br />
<br />
Da die Erwärmung - sofern sie relevant wird - leicht ohne Messinstrumente feststellbar ist, dürfte dieser Teil des Problems insofern handhabbar sein, als man leicht feststellen kann, ob das Problem relevant ist und das Problem auf die Transistoren beschränkt sind.<br />
<br />
Bei Leerlauf-Schaltvorgängen im Abstand von 1/15 Sekunden habe ich keine Erwärmung der Transistoren feststellen können, es wurden auch keine zusätzlichen Kühlkörper verwendet.<br />
<br />
----<br />
Die Spannungsspitze am Messwiderstand kann abgeleitet werden:<br />
Als weitere Vorsichtsmaßnahme habe ich den Messport des Controllers mit einem Widerstand und einer Z5.1 Diode abgesichert.<br />
<br />
----<br />
<br />
Die Störung der Versorgungsspannung lässt sich ohne Oszilloskop nicht messen. Insbesondere in umfangreicheren Schaltungen können Störungen an ganz anderen Stellen (z.B. bei Sensoren) auftreten, die man dann nicht gleich mit der Motorsteuerung in Verbindung bringt.<br />
<br />
Um die Störung vom Controller fernzuhalten habe ich dem Spannungswandler vorsichtshalber eine kleine Schottky-Diode (SB140) vorgeschaltet, um ein Entladen des Stützkondensators zu verhindern.<br />
<br />
=====softwaremäßige Ansteuerung=====<br />
Die einfachste Art der Ansteuerung besteht darin, die Schalter der 4 Gates mit 4 Ausgängen des Controllers zu verbinden.<br />
<br />
Die korrekte Ansteuerung muss dann durch die Software garantiert werden. <br />
<br />
Eine Fehlschaltung der Software z.B. bei einem Absturz kann allerdings zur Zerstörung der Schaltung führen, die Schaltung sollte also in jedem Fall eine Sicherung haben.<br />
<br />
=====Einfache Ansteuerung=====<br />
Etwas sicherer ist es, die Schaltung so aufzubauen, dass ein Kurzschluss nicht dauerhaft geschaltet werden kann.<br />
<br />
Hierzu habe ich die Schaltung so aufgebaut, dass die Gates einer Seite jeweils gemeinsam geschaltet werden. <br />
<br />
Bei einer Gate-Spannung von 0V sperrt der N-MOSFET (U<sub>GS</sub>=0V), der P-MOSFET leitet bei dieser Gate-Spannung, da hier U<sub>GS</sub>=-UB ist. <br />
<br />
Bei einer Gate-Spannung von UB verhält es sich genau umgekehrt: Der N-MOSFET leitet (U<sub>GS</sub>=UB) und der P-MOSFET sperrt (U<sub>GS</sub>=0V)<br />
<br />
Diese einfache Ansteuerung benötigt lediglich zwei Transistorschalter und auch nur 2 Port-Pins, hat jedoch den Nachteil, dass die oben beschriebenen Querströme auftreten.<br />
=====Verbesserungsmöglichkeiten=====<br />
Zur Lösung des Querstrom-Problems gibt es mehrere Ansatzmöglichkeiten, die ebenfalls mit zwei Controller-Ausgängen auskommen.<br />
----<br />
Mittels Logik-Bausteinen werden zwei Ausgänge des Controllers so umgesetzt, dass die folgenden Zustände geschaltet werden können:<br />
<br />
# Motor-Stop: untere Transistoren leitend, obere sperrend (oder umgekehrt)<br />
# Motor-Vorlauf: 1. Diagolale leitend<br />
# Motor-Rücklauf: 2. Diagonale leitend<br />
# Motor-Leerlauf: Alle Transistoren sperrend<br />
<br />
Die Querstrom-Problematik kann hierbei softwaremäßig gelöst werden, indem beim Umschalten jeweils kurz der Leerlauf geschaltet wird, damit alle Transistoren sperren.<br />
----<br />
Eine andere Möglichkeit besteht darin, das Umladen der Gate-Kapazität asymmetrisch zu gestalten, so dass die Transistoren schneller auf sperrend als auf leitend geschaltet werden. Eine einfache Möglichkeit ist die Parallelschaltung einer Diode und eines Widerstandes: In Sperr-Richtung fließt die Ladung langsamer als in die Durchlass-Richtung.<br />
===Heidingscher Encoder===<br />
Aufgrund der Kritik an der Schaltung entschied ich mich einen neuen, einfachen sowie preisgünstigen Encoder zu entwickeln, den man mit der 74series aufbauen kann. Als Treiber können sowohl Transistoren verwendet werden, dabei aber Vorwiderstände nicht vergessen! Die 74series sind mit 20mA Treiberstrom also natürlich nicht zum direkten Treiben geeignet.<br />
Die Logikanzeigen in den Grafiken sollen je einen Transistor bzw. Mosfet darstellen. Eventuelle Freilaufdioden müssen natürlich noch hinzugefügt werden.<br />
====PR Encoder====<br />
[[Bild:Prtreiber.png]]<br />
<br />
Der PR Encoder(PWM-Richtung Encoder) ist mit zwei NOR Gates sowie eines Inverters aufgebaut, d.h. man kann ihn mit nur einem IC(74HC(T)02) aufbauen. Will mein 2 Encoder verwenden, empfliehlt sich den Inverter auszulagern (74HC(T)04 oder 74HC(T)14 Sollte man keinen Schmitt-Trigger benötigen empfiehlt sich aus Schnelligkeitsgründen die 74HC(T)04 Variante). <br />
Alternativ ist es noch möglich sich den Inverter zu sparen, und die Ansteuerung für den P(WM) Kanal invertiert laufen zu lassen. <br />
====PRK Encoder===<br />
[[Bild:Prktreiber.png]]<br />
<br />
Der Prk-Encoder(PWM-Richtung-Kurzschluss-Encoder) ist eine Erweiterung des PR-Encoders. Er erlaubt es zusätzlich, die Motoren durch einen Kurzschluss zu stoppen.<br />
Aufgebaut werden kann dieser aus 1 NOR und 1 Nand Gate. Dabei werden 3 Nand-Gates als Inverter beschaltet. (d.h. eine die Leitung die übrig bleibt auf Vcc).<br />
====Support====<br />
Fragen einfach in das Forum posten, oder mich anschreiben(User s.o.)<br />
===Alte Schaltungsbeschreibung===<br />
{{FarbigerRahmen|<br />
Achtung! Die Schaltung ist so nicht zu verwenden! Siehe unter '''Kritik an der Schaltung'''<br />
}}<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz. Eine der interessantesten Schaltungen, die im Roboternetz vorgestellt wurde, dürfte diese sein:<br />
<br />
<br />
[[Bild:hbrueckemosfet.gif|center]]<br />
<br />
<br />
Anmerkung: Den 74HC26N gibts wohl nicht , nur die TTL-Version 74LS26, die HC-Mos-Version lautet 74HC03.<br />
<br />
Eine sogenannte H-Brücke, die nur aus zwei MOSFETSs und einem Logik-IC besteht. Mit zwei Controllerports kann diese Schaltung sowohl Geschwindigkeit als auch Drehrichtung regeln. Für die Geschwindigkeit ist ein sogenannter [[PWM]]-Port notwendig. Also ein Port, der durch ein gepulstes Signal den Motor etlichemal innerhalb einer Sekunde ein- und ausschaltet und somit quasi die Leistung regelt (siehe [[PWM]]).<br />
Die Schaltung ist so konstruiert, dass immer nur zwei Transistoren durchschalten. Auf diese Weise fließt einmal der Strom von links oben nach rechts unten und einmal von rechts oben nach links unten, der Motor wird also ähnlich wie bei der Relaisschaltung umgepolt. <br />
Bei niedriger [[PWM]]_Frequenz sollte die Schaltung durchaus für einige Ampere geeignet sein, wobei ca. 8 bis 13V ideal sein sollten.<br />
<br />
Das Logic-IC wurde durch 3x BC547 Transitoren ersetzt.<br />
<br />
<br />
[[Bild:Hbrückenmosfet BD547.PNG|center|900px]]<br />
<br />
====Kritik an der Schaltung====<br />
<br />
Diese Schaltung wird im Forum von mehreren Leuten, u.A. Ratber, shaun, massiv kritisiert, z.B. hier: http://www.roboternetz.de/phpBB2/viewtopic.php?t=33067&sid=892e80c6cd2d003292e607bcd7a7123a .<br />
<br />
Ich habe leider nicht das Wissen eine bessere Lösung zu liefern. Das Problem sind die Querströme: Im Umschaltmoment sind highside und lowside switch für kurze Zeit beide leitend. Das entspricht einem Kurzschluss der Versorgungsleitung bei jedem Umschalten mit allen damit verbundenen Problemen (Erwärmung, Schwingung, Sicherungen, Reset). Aus diesem Grund sind NAND-Gatter nicht geeignet!<br />
<br />
Zum Umschalten muss man<br />
*den bisher leitenden Mosfet ausschalten,<br />
*dann etwas warten,<br />
*und schließlich den nächsten Mosfet schließen.<br />
<br />
Dies kann man erreichen, indem man den Einschaltmoment <br />
*durch RC-Glieder verzögert und <br />
*den Ausschaltmoment durch Dioden beschleunigt.<br />
Die entstehenden Schaltungen sind komplex, benötigen viele Bauteile und sind fehleranfällig.<br />
<br />
<br />
Am sinnvollsten sind integrierte Mosfet-Treiber. Diese haben oft eine einstellbare Tot-Zeit (''Dead-Time''), können hohe Leistungen zum Umladen der Gatekapazität liefern und beachten andere Effekte wie ''Propagation-Time'', Veränderung des Source Potentials beim Highside-switch, etc.<br />
<br />
'''Erklärung von shaun:'''<br />
<br />
die gezeigte Schaltung taugt auch nur als Prinzipschaltung bedingt, da man einen variierenden Aufwand in eine sichere Verriegelung investieren müsste. Bei fixer und nicht zu hoher Betriebsspannung könnte man mit RD-Kombinationen in den Gateleitungen das Ausschalten beschleunigen und das Einschalten verzögern, so dass die Querleitung wegfällt. Allerdings bewirkt diese simple R-Cg-Verzögerung größere Schaltverluste. <br />
<br />
Setzt man die Vezögerung vor dedizierte Treiber, müssen diese wiederum leistungsfähig genug zum Umladen der Gates sein und bis an die Versorgung heranreichen, weshalb man an diesem Punkt überlegen sollte, ob 95% duty cycle nicht auch reichen würden ''(Anmerkung: Bezug auf bootstrapping?)'' und man integrierte Treiber für reine N-Kanal-Bestückung einsetzen sollte - spart dann wieder etwas Verluste am Highside-Switch, weil N-Kanäler gleicher Generation und Leistungsklasse einen niedrigeren Rds(on) als ihre P-Pendants haben.<br />
<br />
{{Ausbauwunsch|Eine vernünftige diskrete Ansteuerung für eine H-Brücke.<br />
Korrektur auf Rechtschreibfehler, Zeichensetzung, Schreibstil, Fachausdrücke. Gibt's denn keinen der etwas verbessern möchte?}}<br />
==Ansteuerung mit einem LeistungsOPV==<br />
Die wohl preislich und platztechnisch günstigste Alternative zur Ansteuerung von Motoren in H-Brücken ist die Verwendung von (Leistungs-)Operationsverstärkern. <br />
===Heidingscher Motortreiber=== <br />
Bei dem Heidingschen Motortreiber wird jeder Anschluss des Motors mit einem Ausgang des Operationsverstärker verbunden, die Eingänge des OPVs selbst als Komparator. Diese Methode ist für kleine und mittlere Motoren(=< 1A) und mäßige PWM-Frequenzen(<10kHz) gut geeignet. Ein RB35 von Conrad kann damit problemlos angesteuert werden. Bei zu hohen PWM-Frequenzen ist die SlewRate von vielen OPVs zu gering und die entsprechenden OPVs sind dann viel zu teuer und man sollte eine Ansteuerung per Mosfet(s.o.) bevorzugen. Momentan hat sich der TCA 0372 DP1 (57ct bei Reichelt) Verwendung gefunden. <br />
Weitere Informationen sind in folgendem Forumsbeitrag zu finden:<br />
http://www.roboternetz.de/phpBB2/viewtopic.php?t=38412<br />
===Gleichstromansteuerung===<br />
Eine weitere Möglichkeit ist es, dem Operationsverstärker eine Gleichspannung vorzugeben, mit denen der OPV die Motoren ansteuert. Diese Methode eignet sich sehr gut für analoge Schaltkreise. Der Wirkungsgrad ist allerdings nicht der beste, da die restliche Spannung in Wärme umgesetzt wird. Zudem werden viele weitere komponenten benötigt, dass den Aufbau treuerer und fehleranfälliger macht.<br />
Der entsprechenden Schaltkreis ist im Datenblatt des TCA 0372 DP1 zu finden.<br />
<br />
==Ansteuerung mit Treiber IC L293 D==<br />
<br />
Dies ist ohne Zweifel die am häufigsten genutzte Ansteuerung bei Roboter-Bastlern: Man nimmt einfach das IC L293D, denn darin sind sogar zwei H-Brücken enthalten. Also mit einem IC lassen sich ohne weiteres externe Bauteile gleich zwei Motoren ansteuern. Zwar nur bis ca. 600mA, aber das reicht oft schon für kleinere bis mittlere Roboteranwendungen aus.<br />
<br />
[[Bild:L293Pinout.JPG|center]]<br />
<br />
<br />
[[Bild:hbrueckel293d.gif|center]]<br />
<br />
Wie aus dem Schaltbild zu ersehen ist, werden für die Ansteuerung jedes Motors 3 Ports benötigt. Die Enable-Leitung führt man oft auf einen PWM-Port welcher wie bei der MOS-FET Schaltung oben die Geschwindigkeit regelt. Die beiden anderen Ports geben die Drehrichtung an. Immer wenn die Ports unterschiedliche Polarität haben dreht der Motor in eine bestimmte Richtung, je nachdem wo Low und High anliegt. Das Besondere ist, dass wenn an beiden Ports der gleiche Pegel anliegt, also zweimal Low oder High, dann wird nämlich der Motor kurzgeschlossen - das fungiert als Bremse. Das Bremsen kann bei Robotern durchaus nützlich sein. Zudem ist bei schnellen Richtungswechseln immer zu empfehlen zuerst kurz zu bremsen, um nicht den Motor oder Motortreiber zu stark zu belasten.<br />
<br />
==Ansteuerung mit dem Schaltkreis L298==<br />
<br />
Der Schaltkreis L298 ist quasi der große Bruder des L293D. Er beinhaltet auch zwei komplette H-Brücken, kann also auch zwei Motoren ansteuern. Die Pinbelegung ist ebenfalls dem L293D sehr ähnlich, jedoch verfügt er über eine andere Bauform:<br />
<br />
<br />
[[Bild:L298Pinout.JPG|center]]<br />
<br />
<br />
Der wichtigste Unterschied besteht jedoch darin, dass jede H-Brücke bei L298 bis zu 2A belastet werden kann. Damit lassen sich also schon wesentlich größere Motoren ansteuern. Ein weiterer Vorzug sind die sogenannten SENSE-Ausgänge, über die der komplette Strom fließt. Oft wird hier ein Hochlastwiderstand angeschlossen, um aus der abfallenden Spannung den genauen Strom berechnen zu können. Dies machen sich Steuerungen wie [http://www.roboternetz.de/phpBB2/viewtopic.php?t=2741 RN-Motor] oder aber andere Schrittmotoransteuerungen zunutze, um den Strom genau zu regeln. Benötigt man keine Strommessung, so müssen die Sense-Ausgänge immer direkt mit GND verbunden werden. In diesem Fall muss allerdings eine andere Strombegrenzung eingeplant werden. Wird keine Strombegrenzung eingebaut, müssen diese Widerstände trotztem eingebaut werden, da der Treiber sonst heiss wird.<br />
<br />
<br />
[[Bild:hbrueckel298.gif|center]]<br />
<br />
<br />
Ein weiteres Schaltbild gibt es hier [http://www.roboternetz.de/bilder/schaltung298getriebe.gif]<br />
<br />
==Ansteuerung mit L6205==<br />
Der Schaltkreis L6205 stellt eine etwas modernere Alternative zur L298 Ansteuerung dar. Die Ansteuerung ist praktisch identisch, der Schaltungsaufbau in etwa gleich. Beim L6205 sind keine Freilaufdioden mehr notwendig, dafür ist ein Kondensator und zwei Dioden für die interne Spannungserzeugung notwendig.<br />
Ein großer Vorteil ist auch das kein extra Kühlkörper mehr notwendig ist. Viele integrierte Schutzfunktionen im L6205 sorgen dafür das der Chip nicht so einfach zerstört werden kann. In der Praxis sind die angegeben 2,8A jedoch mit Vorsicht zu geniesen. Bei Testlayouts erwärmten sich die IC´s bereits bei 2A Dauerstrom (PWM) oft so stark das die automatische Temperaturabschaltung reagierte, somit wird man vermutlich ohne Kühlung oder großes Kühllayout auf er Platine auch nicht mehr als beim L298 erreichen. <br />
<br />
[[Bild:l6205ic.gif]] [[Bild:l6205pinbelegung.gif]]<br />
<br />
<br />
[[Bild:l6205.gif|center]]<br />
<br />
==Noch mehr Power gewünscht?==<br />
<br />
Obwohl der L298 schon einiges abdeckt, so kommt er spätestens bei den Scheibenwischermotoren langsam an seine Grenzen. Bei starker Belastung können solche Motoren kurzzeitig bis ca. 10 A und mehr ziehen. Für solch starke Motoren gibt es jetzt einen ganz interessanten Motorchip aus dem KFZ-Bereich: vnh3sp (Datenblatt im Roboternetz Download-Bereich). <br />
Mit ihm lassen sich sogar recht große Motoren ansteuern; vorausgesetzt, man kühlt ihn entsprechend, so verträgt der Chip bis zu 30A. Aber selbst ohne Kühlung bietet er bedeutet mehr Leistung als der L298. Das Schöne, die Ansteuerung ist kaum anders als beim L298 und L293D.<br />
<br />
Kleiner Nachteil: Da es ein SMD-Chip mit 1mm Kontaktabstand ist, muss man schon eine geeignete Platine (spezielles Layout mit Kühlflächen) und etwas Löterfahrung besitzen. Inzwischen gibt es aber schon verschiedene RN-Projekte mit dem Chip (RN-Power, RN-Mini H-Bridge), Platinen und Chip können über den [http://www.shop.robotikhardware.de/shop/catalog/index.php Robotikhardware.de-Platinenservice] bezogen werden. <br />
<br />
<br />
[[Bild:minihbridge_ansteuerung.gif|center]]<br />
<br />
<br />
Alternativ zum [[SMD]]-Chip VNH3SP30 gibt es noch die Alternative VNH2SP30. Dieser Chip erlaubt zwar nur Motorspannungen zwischen 6 und 16 Volt, jedoch hat er einen wesentlich geringeren Innenwiderstand und wird deshalb nur etwa halb so warm wie der VNH3SP30. <br />
Aus diesem Grund eignet er sich auch ideal für kleine Doppelmotorsteuerungen.<br />
Natürlich gibt's auch hierfür ein Projekt und eine Bauanleitung, siehe [[RN-VNH2Dualmotor]]<br />
<br />
Das Schöne ist, dass es dieses RN-Projekt jetzt auch auch als Fertigmodul gibt!<br />
<br />
<br />
[[Bild:rndualmotoransteuerung.jpeg|center]]<br />
<br />
==Endstufen mit I2C-Bus / RS232==<br />
[[Bild:motctrl.png|thumb|Motoransteuerung über RS232, I2C, RC]]Verwendet man eine der oben vorgestellten H-Bridges, so wird immer vorausgesetzt das ein PWM-Signal und mehrere Ports zur Ansteuerung bereitstehen. Ist dies nicht der Fall weil diese vielleicht schon belegt sind, so lassen sich Endstufen durch einen zusätzlichen Microcontroller auch um beliebige Schnittstellen erweitern. Insbesondere über I2C lassen sich dadurch mehrere Motorboards über einen einzigen Bus ansteuern. Ein Beispiel ist der programmierte Controller MOTCTRL, der speziell für diese Aufgabe gedacht ist. Die Grundscháltung sieht man in der rechten Skizze.<br />
<br />
==Und nie vergessen Motoren zu entstören==<br />
<br />
Das Entstören dient dazu, das sogenannte "Bürstenfeuer" zu verhindern, wodurch Störungen hervorgerufen werden könnten. Und so wirds gemacht:<br />
<br />
<br />
[[Bild:entstoerung.gif|center]]<br />
<br />
==Siehe auch==<br />
* [[Getriebemotoren]]<br />
* [[RN-VNH2Dualmotor]]<br />
<br />
==Weblinks==<br />
* [http://www.roboternetz.de/phpBB2/motordrehmoment.php Drehmoment Berechnung]<br />
* [http://www.roboternetz.de/motoruebersicht.html Motoren Übersicht]<br />
* [http://www.shop.robotikhardware.de/shop/catalog/index.php?cPath=65 Bauteilesets]<br />
* [http://www.roboternetz.de/robotertutorial.html Roboter-Tutorial]<br />
* [http://www.roboternetz.de Roboternetz Forum]<br />
<br />
[[Category:Robotikeinstieg]]<br />
[[Category:Praxis]]<br />
[[Category:Grundlagen]]<br />
[[Category:Motoren]]<br />
[[Category:Elektronik]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Getriebemotoren_Ansteuerung&diff=13279Getriebemotoren Ansteuerung2008-03-15T12:09:21Z<p>Overthere: layout gefixed</p>
<hr />
<div>Hat man sich entschlossen, für seinen Roboter oder andere Konstruktion einen Getriebemotor zu verwenden, so muss man sich Gedanken machen, wie man ihn ansteuert. Gewöhnlich will man die Motoren ja sowohl in Bezug auf Drehrichtung und Geschwindigkeit über eine Programmiersprache steuern. Daher wird in der Regel erst mal ein Controllerboard benötigt. Leider kann man an die wenigsten Controllerboards einen Getriebemotor direkt anschließen, eine der wenigen Ausnahmen ist das [[RN-Control]]-Board und das RNBFRA-Board. Bei beiden Boards ist es einfach, dort müssen die Getriebemotoren einfach nur an die Schraubklemmen angeschlossen werden, danach kann man sofort mit der Programmierung loslegen.<br />
<br />
Ich möchte hier aber aufzeigen, wie man Motoren auch bei anderen Boards anschließen kann. Die gleiche Technik läßt sich natürlich auch nutzen, um z.B. mehr als zwei Motoren an [[RN-Control]] anzuschließen.<br />
<br />
==Ansteuerung mit Relais==<br />
<br />
Die einfachste Methode, um Motoren per [[Microcontroller|Controller]] anzusteuern, erreicht man durch die Verwendung von Relais. Mit einem Relais, das zwei Umschaltkontakte besitzt, lässt sich über einen einzelnen Controllerport bequem die Drehrichtung wechseln.<br />
<br />
[[Bild:hbrueckerelais.gif|center]]<br />
<br />
Da auch Relais wegen des Strombedarfes nicht direkt vom Controller geschaltet werden können, wurde in dem oberen Beispiel ein Transistor vorangestellt. Die Diode dient nur dazu, die Spannungen, die beim Ausschalten des Relais induziert werden, abzuleiten. Ohne Diode funktioniert das Ganze in der Regel auch, jedoch könnte der Transistor oder sogar der Controller durch die induzierte Spannung beschädigt werden. <br />
Die Schaltung ist also in der Lage, die Drehrichtung umzuschalten, jedoch nicht in der Lage, den Motor zu stoppen. Um den Motor ganz auszuschalten, müsste man noch ein weiteres Relais vorsehen, das die gesamte Motorspannung abschaltet. Ein Schaltbild können wir uns ersparen, da das Ganze recht ähnlich aussieht. <br />
Der große Nachteil von Relaisschaltungen ist, dass die Geschwindigkeit des Motors nicht geregelt werden kann, zudem haben Relais bei sehr vielen Schaltvorgängen einen gewissen Verschleiß. <br />
Vorteil der Schaltung ist jedoch, das man auch sehr große Lasten/Motoren schalten kann.<br />
<br />
==Ansteuerung mit MOS-FET==<br />
===Neufassung===<br />
{{Ausbauwunsch|Die Neufassung kann im momentanen Stand nur als Anregung verstanden werden.<br />
<br />
Insbesondere fehlen noch angepasste Schaltpläne.<br />
<br />
Einige der Anmerkungen aus dem Abschnitt "Kritik an der Schaltung" sind in der Neufassung noch nicht enthalten, die Beschreibung von Verzögerungsgliedern müsste auch eine Erklärung enthalten, welche Verzögerung mit welchen Werten erreicht wird.<br />
<br />
Wenn die Neufassung komplett fertig ist, sollten die alten Texte weg.<br />
}}<br />
====Grundprinzip====<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz.<br />
<br />
Die Grundschaltung besteht aus 2 N-Kanal-MOSFET (hier BUZ11) und zwei P-Kanal-MOSFET (hier IRF5305), mit denen die Motoranschlüsse nach GND bzw. UB geschaltet werden. Zusätzlich sind noch 4 Schottky-Dioden (z.B. SB530) erforderlich, um Induktionsströme des Motors abzuleiten. Die Dioden werden in Sperrichtung von den beiden Motoranschlüssen nach GND bzw. UB geschaltet.<br />
<br />
Grundsätzlich muss die Beschaltung der Gate-Eingänge so erfolgen, dass zum Starten des Motors die Transistoren einer Diagonale auf "leitend" und die der anderen auf "sperrend" geschaltet werden. Zum Anhalten des Motors werden z.B. die unteren auf leitend und die oberen auf sperrend geschaltet - Der Motor wird dadurch schnell abgebremst, denn durch einen Transistor und eine Freilaufdiode fließt ein nicht unerheblicher Bremsstrom.<br />
Alternativ kann man auch alle Transistoren auf sperrend schalten, der Motor läuft dann im Leerlauf aus.<br />
<br />
Die Transistoren einer Seite dürfen nicht dauerhaft gleichzeitig auf "leitend" geschaltet werden, da dies einen Kurzschluss verursacht.<br />
<br />
Hinweis: Zumindestens bei dem Transistor BUZ11 handelt es sich um ein veraltetes Modell. Wenn es auf hohe Leistung ankommt, sollte da ein anderer Transistor gewählt werden.<br />
<br />
====Elektrische Ansteuerung der Gates====<br />
Beim Umschalten der Transistoren entsteht eine erhöhte Verlustleistung - der Widerstand wechselt von sperrend (sehr großer Widerstand) nach leitend (sehr kleiner Widerstand) und umgekehrt.<br />
<br />
Zwischen beiden Enden des Schaltvorgangs befindet sich der Transistor in der "Widerstandsphase" (weder ganz leitend, noch ganz sperrend), die eine erhebliche Verlustleistung und damit Erwärmung mit sich bringt.<br />
<br />
Deshalb sollte der Schaltvorgang - insbesondere wenn für eine PWM-Gegelung sehr oft geschaltet werden soll - möglichst schnell erfolgen. Da zum Umschalten die durch den Aufbau des MOSFETs bedingte Gatekapazität umgeladen werden muss, ist hierzu (sehr kurzzeitig) ein hoher Stromfluss nötig.<br />
=====Schaltung direkt am Port=====<br />
Eine Ansteuerung unmittelbar über den Ausgang eines Mikrocontrollers (oder eines TTL-IC) ist schon wegen der benötigten Spannungen nicht möglich. <br />
<br />
Bei den N-FET könnte man sog. "Logik-MOSFET" nehmen, die bereits bei 5V ausreichend leitet. <br />
<br />
Bei den P-MOSFET bemisst sich die Schaltspannung gegen UB, mit einem 5V Port und UB=12V würde also zwischen -12V und -7V umgeschaltet, was einen P-MOSFET erfordern würde, der bereits bei -7V sperrt.<br />
<br />
Dass ein Portpin nur einen geringen Stromfluss (~20mA) zulässt, ist ein weiteres Problem und verhindert einen Schaltvorgang mit idealer steiler Flanke. Allerdings ist die Schaltungsvariante mit einem Transistor in diesem Punkt keinesfalls besser, wenn die Gatekapazität durch den PullUp-Widerstand umgeladen werden muss.<br />
=====Schaltung mit einem Transistor=====<br />
Eine einfache Steuerschaltung besteht aus einem Transistor-Schalter und einem Pull-Up-Widerstand. Als Schalter hab ich 1/7 eines ULN2003 IC verwendet, als PullUp 2200 Ohm. Ein diskreter Aufbau mit 1 Transistor und 2 Widerständen ist aber auch nicht komplizierter.<br />
<br />
Der Vorteil liegt in der Einfachheit, der Nachteil liegt darin, dass die Schaltung nicht sonderlich schnell vonstatten geht: Für die Schaltung des FET muss die Gate-Kapazität transferiert werden, was insbesondere beim Wechsel von 0V nach UB einen Moment dauert, da die Ladung durch den Widerstand hindurch muss.<br />
<br />
Ein kleinerer Widerstand könnte hier helfen, verursacht allerdings einen nicht unerheblichen Stromfluss im geschalteten Zustand (zulässige Verlustleistung beachten).<br />
=====Schaltung mit zwei Transistoren=====<br />
Eine bessere Ansteuerung sollte sich ergeben, wenn man zwei Transistoren zur Gate-Ansteuerung verwendet: Einer schaltet gegen 0V, der andere Gegen UC. So kann man erreichen, dass in beide Richtungen rasch umgeschaltet werden kann.<br />
=====Integrierte Gate-Treiber=====<br />
Statt der Beschaltung mit zwei Transistoren kann man auch einen integrierten MOSFET-Treiber verwenden. Mit derartige IC sind darauf ausgelegt, kurzfristig den für eine Umschaltung benötigten hohen Stromfluss zu ermöglichen.<br />
<br />
Es gibt auch Treiber-IC, die zur Ansteuerung der oberen Transistoren eine Spannung oberhalb von UB erzeugen. Mit solchen Highside-Treibern kann die H-Brücke auch aus 4 N-Kanal-Transistoren gebaut werden, was den Vorteil hat, dass N-Kanal-FET mit geringerem Schaltwiderstand zu bekommen sind.<br />
<br />
====Logische Ansteuerung der Gates====<br />
Nach der elektrischen Ansteuerung ist die logische Ansteuerung durch den Mikrocontroller zu überlegen.<br />
<br />
=====Mögliche Querströme=====<br />
In der H-Brücke sind zwei problematische Zustände zu berücksichtigen:<br />
<br />
1. Das offensichtliche Problem ist ein Kurzschluss: Wenn beide Transistoren einer Seite auf leitend geschaltet werden wird dadurch ein Kurzschluss erzeugt. Falls vorhanden brennt die Sicherung durch - ist keine Sicherung vorhanden, brennt was anderes durch.<br />
<br />
2. Ein nicht so offensichtliches Problem rührt daher, dass der Schaltvorgang nur mit endlicher Geschwindigkeit abläuft und der Transistor auch schon vor Erreichen des Zielwertes der Gate-Spannung erheblichen Strom leitet. Hierdurch kommt es zu einem Kurzschluss durch den nicht mehr richtig gesperrten und den noch nicht richtig gesperrten Transistor.<br />
<br />
Die Stromspitze selbst liegt noch im Rahmen der Spezifikationen der Transistoren. Sofern ein Messwiderstand von z.B. 0,1 Ohm da ist oder die Spannungsquelle einen vergleichbaren Innenwiderstand hat fließt ein Strom von weniger als 70A, die Transistoren sind jeweils für Spitzen von über 100A spezifiziert.<br />
<br />
Allerdings hat die Stromspitze drei Auswirkungen: <br />
<br />
# Die Transistoren erwärmen sich<br />
# Es kann an einem Messwiderstand zu einer Spannungsspitze kommen<br />
# Die Versorgungsspannung bricht kurzzeitig zusammen<br />
<br />
----<br />
<br />
Die Erwärmung des Transistors ist solange kein Problem, wie nur selten umgeschaltet wird. Bei einer Regelung per PWM könnten sich die kleinen Energiemengen zu einem relevanten Problem addieren. <br />
<br />
Da die Erwärmung - sofern sie relevant wird - leicht ohne Messinstrumente feststellbar ist, dürfte dieser Teil des Problems insofern handhabbar sein, als man leicht feststellen kann, ob das Problem relevant ist und das Problem auf die Transistoren beschränkt sind.<br />
<br />
Bei Leerlauf-Schaltvorgängen im Abstand von 1/15 Sekunden habe ich keine Erwärmung der Transistoren feststellen können, es wurden auch keine zusätzlichen Kühlkörper verwendet.<br />
<br />
----<br />
Die Spannungsspitze am Messwiderstand kann abgeleitet werden:<br />
Als weitere Vorsichtsmaßnahme habe ich den Messport des Controllers mit einem Widerstand und einer Z5.1 Diode abgesichert.<br />
<br />
----<br />
<br />
Die Störung der Versorgungsspannung lässt sich ohne Oszilloskop nicht messen. Insbesondere in umfangreicheren Schaltungen können Störungen an ganz anderen Stellen (z.B. bei Sensoren) auftreten, die man dann nicht gleich mit der Motorsteuerung in Verbindung bringt.<br />
<br />
Um die Störung vom Controller fernzuhalten habe ich dem Spannungswandler vorsichtshalber eine kleine Schottky-Diode (SB140) vorgeschaltet, um ein Entladen des Stützkondensators zu verhindern.<br />
<br />
=====softwaremäßige Ansteuerung=====<br />
Die einfachste Art der Ansteuerung besteht darin, die Schalter der 4 Gates mit 4 Ausgängen des Controllers zu verbinden.<br />
<br />
Die korrekte Ansteuerung muss dann durch die Software garantiert werden. <br />
<br />
Eine Fehlschaltung der Software z.B. bei einem Absturz kann allerdings zur Zerstörung der Schaltung führen, die Schaltung sollte also in jedem Fall eine Sicherung haben.<br />
<br />
=====Einfache Ansteuerung=====<br />
Etwas sicherer ist es, die Schaltung so aufzubauen, dass ein Kurzschluss nicht dauerhaft geschaltet werden kann.<br />
<br />
Hierzu habe ich die Schaltung so aufgebaut, dass die Gates einer Seite jeweils gemeinsam geschaltet werden. <br />
<br />
Bei einer Gate-Spannung von 0V sperrt der N-MOSFET (U<sub>GS</sub>=0V), der P-MOSFET leitet bei dieser Gate-Spannung, da hier U<sub>GS</sub>=-UB ist. <br />
<br />
Bei einer Gate-Spannung von UB verhält es sich genau umgekehrt: Der N-MOSFET leitet (U<sub>GS</sub>=UB) und der P-MOSFET sperrt (U<sub>GS</sub>=0V)<br />
<br />
Diese einfache Ansteuerung benötigt lediglich zwei Transistorschalter und auch nur 2 Port-Pins, hat jedoch den Nachteil, dass die oben beschriebenen Querströme auftreten.<br />
=====Verbesserungsmöglichkeiten=====<br />
Zur Lösung des Querstrom-Problems gibt es mehrere Ansatzmöglichkeiten, die ebenfalls mit zwei Controller-Ausgängen auskommen.<br />
----<br />
Mittels Logik-Bausteinen werden zwei Ausgänge des Controllers so umgesetzt, dass die folgenden Zustände geschaltet werden können:<br />
<br />
# Motor-Stop: untere Transistoren leitend, obere sperrend (oder umgekehrt)<br />
# Motor-Vorlauf: 1. Diagolale leitend<br />
# Motor-Rücklauf: 2. Diagonale leitend<br />
# Motor-Leerlauf: Alle Transistoren sperrend<br />
<br />
Die Querstrom-Problematik kann hierbei softwaremäßig gelöst werden, indem beim Umschalten jeweils kurz der Leerlauf geschaltet wird, damit alle Transistoren sperren.<br />
----<br />
Eine andere Möglichkeit besteht darin, das Umladen der Gate-Kapazität asymmetrisch zu gestalten, so dass die Transistoren schneller auf sperrend als auf leitend geschaltet werden. Eine einfache Möglichkeit ist die Parallelschaltung einer Diode und eines Widerstandes: In Sperr-Richtung fließt die Ladung langsamer als in die Durchlass-Richtung.<br />
===Heidingscher Encoder===<br />
Aufgrund der Kritik an der Schaltung entschied ich mich einen neuen, einfachen sowie preisgünstigen Encoder zu entwickeln, den man mit der 74series aufbauen kann. Als Treiber können sowohl Transistoren verwendet werden, dabei aber Vorwiderstände nicht vergessen! Die 74series sind mit 20mA Treiberstrom also natürlich nicht zum direkten Treiben geeignet.<br />
Die Logikanzeigen in den Grafiken sollen je einen Transistor bzw. Mosfet darstellen. Eventuelle Freilaufdioden müssen natürlich noch hinzugefügt werden.<br />
====PR Encoder====<br />
[[Bild:Prtreiber.png]]<br />
Der PR Encoder(PWM-Richtung Encoder) ist mit zwei NOR Gates sowie eines Inverters aufgebaut, d.h. man kann ihn mit nur einem IC(74HC(T)02) aufbauen. Will mein 2 Encoder verwenden, empfliehlt sich den Inverter auszulagern (74HC(T)04 oder 74HC(T)14 Sollte man keinen Schmitt-Trigger benötigen empfiehlt sich aus Schnelligkeitsgründen die 74HC(T)04 Variante). <br />
Alternativ ist es noch möglich sich den Inverter zu sparen, und die Ansteuerung für den P(WM) Kanal invertiert laufen zu lassen. <br />
====PRK Encoder===0<br />
[[Bild:Prktreiber.png]]<br />
Der Prk-Encoder(PWM-Richtung-Kurzschluss-Encoder) ist eine Erweiterung des PR-Encoders. Er erlaubt es zusätzlich, die Motoren durch einen Kurzschluss zu stoppen.<br />
Aufgebaut werden kann dieser aus 1 NOR und 1 Nand Gate. Dabei werden 3 Nand-Gates als Inverter beschaltet. (d.h. eine die Leitung die übrig bleibt auf Vcc).<br />
====Support====<br />
Fragen einfach in das Forum posten, oder mich anschreiben(User s.o.)<br />
===Alte Schaltungsbeschreibung===<br />
{{FarbigerRahmen|<br />
Achtung! Die Schaltung ist so nicht zu verwenden! Siehe unter '''Kritik an der Schaltung'''<br />
}}<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz. Eine der interessantesten Schaltungen, die im Roboternetz vorgestellt wurde, dürfte diese sein:<br />
<br />
<br />
[[Bild:hbrueckemosfet.gif|center]]<br />
<br />
<br />
Anmerkung: Den 74HC26N gibts wohl nicht , nur die TTL-Version 74LS26, die HC-Mos-Version lautet 74HC03.<br />
<br />
Eine sogenannte H-Brücke, die nur aus zwei MOSFETSs und einem Logik-IC besteht. Mit zwei Controllerports kann diese Schaltung sowohl Geschwindigkeit als auch Drehrichtung regeln. Für die Geschwindigkeit ist ein sogenannter [[PWM]]-Port notwendig. Also ein Port, der durch ein gepulstes Signal den Motor etlichemal innerhalb einer Sekunde ein- und ausschaltet und somit quasi die Leistung regelt (siehe [[PWM]]).<br />
Die Schaltung ist so konstruiert, dass immer nur zwei Transistoren durchschalten. Auf diese Weise fließt einmal der Strom von links oben nach rechts unten und einmal von rechts oben nach links unten, der Motor wird also ähnlich wie bei der Relaisschaltung umgepolt. <br />
Bei niedriger [[PWM]]_Frequenz sollte die Schaltung durchaus für einige Ampere geeignet sein, wobei ca. 8 bis 13V ideal sein sollten.<br />
<br />
Das Logic-IC wurde durch 3x BC547 Transitoren ersetzt.<br />
<br />
<br />
[[Bild:Hbrückenmosfet BD547.PNG|center|900px]]<br />
<br />
====Kritik an der Schaltung====<br />
<br />
Diese Schaltung wird im Forum von mehreren Leuten, u.A. Ratber, shaun, massiv kritisiert, z.B. hier: http://www.roboternetz.de/phpBB2/viewtopic.php?t=33067&sid=892e80c6cd2d003292e607bcd7a7123a .<br />
<br />
Ich habe leider nicht das Wissen eine bessere Lösung zu liefern. Das Problem sind die Querströme: Im Umschaltmoment sind highside und lowside switch für kurze Zeit beide leitend. Das entspricht einem Kurzschluss der Versorgungsleitung bei jedem Umschalten mit allen damit verbundenen Problemen (Erwärmung, Schwingung, Sicherungen, Reset). Aus diesem Grund sind NAND-Gatter nicht geeignet!<br />
<br />
Zum Umschalten muss man<br />
*den bisher leitenden Mosfet ausschalten,<br />
*dann etwas warten,<br />
*und schließlich den nächsten Mosfet schließen.<br />
<br />
Dies kann man erreichen, indem man den Einschaltmoment <br />
*durch RC-Glieder verzögert und <br />
*den Ausschaltmoment durch Dioden beschleunigt.<br />
Die entstehenden Schaltungen sind komplex, benötigen viele Bauteile und sind fehleranfällig.<br />
<br />
<br />
Am sinnvollsten sind integrierte Mosfet-Treiber. Diese haben oft eine einstellbare Tot-Zeit (''Dead-Time''), können hohe Leistungen zum Umladen der Gatekapazität liefern und beachten andere Effekte wie ''Propagation-Time'', Veränderung des Source Potentials beim Highside-switch, etc.<br />
<br />
'''Erklärung von shaun:'''<br />
<br />
die gezeigte Schaltung taugt auch nur als Prinzipschaltung bedingt, da man einen variierenden Aufwand in eine sichere Verriegelung investieren müsste. Bei fixer und nicht zu hoher Betriebsspannung könnte man mit RD-Kombinationen in den Gateleitungen das Ausschalten beschleunigen und das Einschalten verzögern, so dass die Querleitung wegfällt. Allerdings bewirkt diese simple R-Cg-Verzögerung größere Schaltverluste. <br />
<br />
Setzt man die Vezögerung vor dedizierte Treiber, müssen diese wiederum leistungsfähig genug zum Umladen der Gates sein und bis an die Versorgung heranreichen, weshalb man an diesem Punkt überlegen sollte, ob 95% duty cycle nicht auch reichen würden ''(Anmerkung: Bezug auf bootstrapping?)'' und man integrierte Treiber für reine N-Kanal-Bestückung einsetzen sollte - spart dann wieder etwas Verluste am Highside-Switch, weil N-Kanäler gleicher Generation und Leistungsklasse einen niedrigeren Rds(on) als ihre P-Pendants haben.<br />
<br />
{{Ausbauwunsch|Eine vernünftige diskrete Ansteuerung für eine H-Brücke.<br />
Korrektur auf Rechtschreibfehler, Zeichensetzung, Schreibstil, Fachausdrücke. Gibt's denn keinen der etwas verbessern möchte?}}<br />
==Ansteuerung mit einem LeistungsOPV==<br />
Die wohl preislich und platztechnisch günstigste Alternative zur Ansteuerung von Motoren in H-Brücken ist die Verwendung von (Leistungs-)Operationsverstärkern. <br />
===Heidingscher Motortreiber=== <br />
Bei dem Heidingschen Motortreiber wird jeder Anschluss des Motors mit einem Ausgang des Operationsverstärker verbunden, die Eingänge des OPVs selbst als Komparator. Diese Methode ist für kleine und mittlere Motoren(=< 1A) und mäßige PWM-Frequenzen(<10kHz) gut geeignet. Ein RB35 von Conrad kann damit problemlos angesteuert werden. Bei zu hohen PWM-Frequenzen ist die SlewRate von vielen OPVs zu gering und die entsprechenden OPVs sind dann viel zu teuer und man sollte eine Ansteuerung per Mosfet(s.o.) bevorzugen. Momentan hat sich der TCA 0372 DP1 (57ct bei Reichelt) Verwendung gefunden. <br />
Weitere Informationen sind in folgendem Forumsbeitrag zu finden:<br />
http://www.roboternetz.de/phpBB2/viewtopic.php?t=38412<br />
===Gleichstromansteuerung===<br />
Eine weitere Möglichkeit ist es, dem Operationsverstärker eine Gleichspannung vorzugeben, mit denen der OPV die Motoren ansteuert. Diese Methode eignet sich sehr gut für analoge Schaltkreise. Der Wirkungsgrad ist allerdings nicht der beste, da die restliche Spannung in Wärme umgesetzt wird. Zudem werden viele weitere komponenten benötigt, dass den Aufbau treuerer und fehleranfälliger macht.<br />
Der entsprechenden Schaltkreis ist im Datenblatt des TCA 0372 DP1 zu finden.<br />
<br />
==Ansteuerung mit Treiber IC L293 D==<br />
<br />
Dies ist ohne Zweifel die am häufigsten genutzte Ansteuerung bei Roboter-Bastlern: Man nimmt einfach das IC L293D, denn darin sind sogar zwei H-Brücken enthalten. Also mit einem IC lassen sich ohne weiteres externe Bauteile gleich zwei Motoren ansteuern. Zwar nur bis ca. 600mA, aber das reicht oft schon für kleinere bis mittlere Roboteranwendungen aus.<br />
<br />
[[Bild:L293Pinout.JPG|center]]<br />
<br />
<br />
[[Bild:hbrueckel293d.gif|center]]<br />
<br />
Wie aus dem Schaltbild zu ersehen ist, werden für die Ansteuerung jedes Motors 3 Ports benötigt. Die Enable-Leitung führt man oft auf einen PWM-Port welcher wie bei der MOS-FET Schaltung oben die Geschwindigkeit regelt. Die beiden anderen Ports geben die Drehrichtung an. Immer wenn die Ports unterschiedliche Polarität haben dreht der Motor in eine bestimmte Richtung, je nachdem wo Low und High anliegt. Das Besondere ist, dass wenn an beiden Ports der gleiche Pegel anliegt, also zweimal Low oder High, dann wird nämlich der Motor kurzgeschlossen - das fungiert als Bremse. Das Bremsen kann bei Robotern durchaus nützlich sein. Zudem ist bei schnellen Richtungswechseln immer zu empfehlen zuerst kurz zu bremsen, um nicht den Motor oder Motortreiber zu stark zu belasten.<br />
<br />
==Ansteuerung mit dem Schaltkreis L298==<br />
<br />
Der Schaltkreis L298 ist quasi der große Bruder des L293D. Er beinhaltet auch zwei komplette H-Brücken, kann also auch zwei Motoren ansteuern. Die Pinbelegung ist ebenfalls dem L293D sehr ähnlich, jedoch verfügt er über eine andere Bauform:<br />
<br />
<br />
[[Bild:L298Pinout.JPG|center]]<br />
<br />
<br />
Der wichtigste Unterschied besteht jedoch darin, dass jede H-Brücke bei L298 bis zu 2A belastet werden kann. Damit lassen sich also schon wesentlich größere Motoren ansteuern. Ein weiterer Vorzug sind die sogenannten SENSE-Ausgänge, über die der komplette Strom fließt. Oft wird hier ein Hochlastwiderstand angeschlossen, um aus der abfallenden Spannung den genauen Strom berechnen zu können. Dies machen sich Steuerungen wie [http://www.roboternetz.de/phpBB2/viewtopic.php?t=2741 RN-Motor] oder aber andere Schrittmotoransteuerungen zunutze, um den Strom genau zu regeln. Benötigt man keine Strommessung, so müssen die Sense-Ausgänge immer direkt mit GND verbunden werden. In diesem Fall muss allerdings eine andere Strombegrenzung eingeplant werden. Wird keine Strombegrenzung eingebaut, müssen diese Widerstände trotztem eingebaut werden, da der Treiber sonst heiss wird.<br />
<br />
<br />
[[Bild:hbrueckel298.gif|center]]<br />
<br />
<br />
Ein weiteres Schaltbild gibt es hier [http://www.roboternetz.de/bilder/schaltung298getriebe.gif]<br />
<br />
==Ansteuerung mit L6205==<br />
Der Schaltkreis L6205 stellt eine etwas modernere Alternative zur L298 Ansteuerung dar. Die Ansteuerung ist praktisch identisch, der Schaltungsaufbau in etwa gleich. Beim L6205 sind keine Freilaufdioden mehr notwendig, dafür ist ein Kondensator und zwei Dioden für die interne Spannungserzeugung notwendig.<br />
Ein großer Vorteil ist auch das kein extra Kühlkörper mehr notwendig ist. Viele integrierte Schutzfunktionen im L6205 sorgen dafür das der Chip nicht so einfach zerstört werden kann. In der Praxis sind die angegeben 2,8A jedoch mit Vorsicht zu geniesen. Bei Testlayouts erwärmten sich die IC´s bereits bei 2A Dauerstrom (PWM) oft so stark das die automatische Temperaturabschaltung reagierte, somit wird man vermutlich ohne Kühlung oder großes Kühllayout auf er Platine auch nicht mehr als beim L298 erreichen. <br />
<br />
[[Bild:l6205ic.gif]] [[Bild:l6205pinbelegung.gif]]<br />
<br />
<br />
[[Bild:l6205.gif|center]]<br />
<br />
==Noch mehr Power gewünscht?==<br />
<br />
Obwohl der L298 schon einiges abdeckt, so kommt er spätestens bei den Scheibenwischermotoren langsam an seine Grenzen. Bei starker Belastung können solche Motoren kurzzeitig bis ca. 10 A und mehr ziehen. Für solch starke Motoren gibt es jetzt einen ganz interessanten Motorchip aus dem KFZ-Bereich: vnh3sp (Datenblatt im Roboternetz Download-Bereich). <br />
Mit ihm lassen sich sogar recht große Motoren ansteuern; vorausgesetzt, man kühlt ihn entsprechend, so verträgt der Chip bis zu 30A. Aber selbst ohne Kühlung bietet er bedeutet mehr Leistung als der L298. Das Schöne, die Ansteuerung ist kaum anders als beim L298 und L293D.<br />
<br />
Kleiner Nachteil: Da es ein SMD-Chip mit 1mm Kontaktabstand ist, muss man schon eine geeignete Platine (spezielles Layout mit Kühlflächen) und etwas Löterfahrung besitzen. Inzwischen gibt es aber schon verschiedene RN-Projekte mit dem Chip (RN-Power, RN-Mini H-Bridge), Platinen und Chip können über den [http://www.shop.robotikhardware.de/shop/catalog/index.php Robotikhardware.de-Platinenservice] bezogen werden. <br />
<br />
<br />
[[Bild:minihbridge_ansteuerung.gif|center]]<br />
<br />
<br />
Alternativ zum [[SMD]]-Chip VNH3SP30 gibt es noch die Alternative VNH2SP30. Dieser Chip erlaubt zwar nur Motorspannungen zwischen 6 und 16 Volt, jedoch hat er einen wesentlich geringeren Innenwiderstand und wird deshalb nur etwa halb so warm wie der VNH3SP30. <br />
Aus diesem Grund eignet er sich auch ideal für kleine Doppelmotorsteuerungen.<br />
Natürlich gibt's auch hierfür ein Projekt und eine Bauanleitung, siehe [[RN-VNH2Dualmotor]]<br />
<br />
Das Schöne ist, dass es dieses RN-Projekt jetzt auch auch als Fertigmodul gibt!<br />
<br />
<br />
[[Bild:rndualmotoransteuerung.jpeg|center]]<br />
<br />
==Endstufen mit I2C-Bus / RS232==<br />
[[Bild:motctrl.png|thumb|Motoransteuerung über RS232, I2C, RC]]Verwendet man eine der oben vorgestellten H-Bridges, so wird immer vorausgesetzt das ein PWM-Signal und mehrere Ports zur Ansteuerung bereitstehen. Ist dies nicht der Fall weil diese vielleicht schon belegt sind, so lassen sich Endstufen durch einen zusätzlichen Microcontroller auch um beliebige Schnittstellen erweitern. Insbesondere über I2C lassen sich dadurch mehrere Motorboards über einen einzigen Bus ansteuern. Ein Beispiel ist der programmierte Controller MOTCTRL, der speziell für diese Aufgabe gedacht ist. Die Grundscháltung sieht man in der rechten Skizze.<br />
<br />
==Und nie vergessen Motoren zu entstören==<br />
<br />
Das Entstören dient dazu, das sogenannte "Bürstenfeuer" zu verhindern, wodurch Störungen hervorgerufen werden könnten. Und so wirds gemacht:<br />
<br />
<br />
[[Bild:entstoerung.gif|center]]<br />
<br />
==Siehe auch==<br />
* [[Getriebemotoren]]<br />
* [[RN-VNH2Dualmotor]]<br />
<br />
==Weblinks==<br />
* [http://www.roboternetz.de/phpBB2/motordrehmoment.php Drehmoment Berechnung]<br />
* [http://www.roboternetz.de/motoruebersicht.html Motoren Übersicht]<br />
* [http://www.shop.robotikhardware.de/shop/catalog/index.php?cPath=65 Bauteilesets]<br />
* [http://www.roboternetz.de/robotertutorial.html Roboter-Tutorial]<br />
* [http://www.roboternetz.de Roboternetz Forum]<br />
<br />
[[Category:Robotikeinstieg]]<br />
[[Category:Praxis]]<br />
[[Category:Grundlagen]]<br />
[[Category:Motoren]]<br />
[[Category:Elektronik]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Getriebemotoren_Ansteuerung&diff=13278Getriebemotoren Ansteuerung2008-03-15T12:07:33Z<p>Overthere: pr(k) encoder hinzugefügt</p>
<hr />
<div>Hat man sich entschlossen, für seinen Roboter oder andere Konstruktion einen Getriebemotor zu verwenden, so muss man sich Gedanken machen, wie man ihn ansteuert. Gewöhnlich will man die Motoren ja sowohl in Bezug auf Drehrichtung und Geschwindigkeit über eine Programmiersprache steuern. Daher wird in der Regel erst mal ein Controllerboard benötigt. Leider kann man an die wenigsten Controllerboards einen Getriebemotor direkt anschließen, eine der wenigen Ausnahmen ist das [[RN-Control]]-Board und das RNBFRA-Board. Bei beiden Boards ist es einfach, dort müssen die Getriebemotoren einfach nur an die Schraubklemmen angeschlossen werden, danach kann man sofort mit der Programmierung loslegen.<br />
<br />
Ich möchte hier aber aufzeigen, wie man Motoren auch bei anderen Boards anschließen kann. Die gleiche Technik läßt sich natürlich auch nutzen, um z.B. mehr als zwei Motoren an [[RN-Control]] anzuschließen.<br />
<br />
==Ansteuerung mit Relais==<br />
<br />
Die einfachste Methode, um Motoren per [[Microcontroller|Controller]] anzusteuern, erreicht man durch die Verwendung von Relais. Mit einem Relais, das zwei Umschaltkontakte besitzt, lässt sich über einen einzelnen Controllerport bequem die Drehrichtung wechseln.<br />
<br />
[[Bild:hbrueckerelais.gif|center]]<br />
<br />
Da auch Relais wegen des Strombedarfes nicht direkt vom Controller geschaltet werden können, wurde in dem oberen Beispiel ein Transistor vorangestellt. Die Diode dient nur dazu, die Spannungen, die beim Ausschalten des Relais induziert werden, abzuleiten. Ohne Diode funktioniert das Ganze in der Regel auch, jedoch könnte der Transistor oder sogar der Controller durch die induzierte Spannung beschädigt werden. <br />
Die Schaltung ist also in der Lage, die Drehrichtung umzuschalten, jedoch nicht in der Lage, den Motor zu stoppen. Um den Motor ganz auszuschalten, müsste man noch ein weiteres Relais vorsehen, das die gesamte Motorspannung abschaltet. Ein Schaltbild können wir uns ersparen, da das Ganze recht ähnlich aussieht. <br />
Der große Nachteil von Relaisschaltungen ist, dass die Geschwindigkeit des Motors nicht geregelt werden kann, zudem haben Relais bei sehr vielen Schaltvorgängen einen gewissen Verschleiß. <br />
Vorteil der Schaltung ist jedoch, das man auch sehr große Lasten/Motoren schalten kann.<br />
<br />
==Ansteuerung mit MOS-FET==<br />
===Neufassung===<br />
{{Ausbauwunsch|Die Neufassung kann im momentanen Stand nur als Anregung verstanden werden.<br />
<br />
Insbesondere fehlen noch angepasste Schaltpläne.<br />
<br />
Einige der Anmerkungen aus dem Abschnitt "Kritik an der Schaltung" sind in der Neufassung noch nicht enthalten, die Beschreibung von Verzögerungsgliedern müsste auch eine Erklärung enthalten, welche Verzögerung mit welchen Werten erreicht wird.<br />
<br />
Wenn die Neufassung komplett fertig ist, sollten die alten Texte weg.<br />
}}<br />
====Grundprinzip====<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz.<br />
<br />
Die Grundschaltung besteht aus 2 N-Kanal-MOSFET (hier BUZ11) und zwei P-Kanal-MOSFET (hier IRF5305), mit denen die Motoranschlüsse nach GND bzw. UB geschaltet werden. Zusätzlich sind noch 4 Schottky-Dioden (z.B. SB530) erforderlich, um Induktionsströme des Motors abzuleiten. Die Dioden werden in Sperrichtung von den beiden Motoranschlüssen nach GND bzw. UB geschaltet.<br />
<br />
Grundsätzlich muss die Beschaltung der Gate-Eingänge so erfolgen, dass zum Starten des Motors die Transistoren einer Diagonale auf "leitend" und die der anderen auf "sperrend" geschaltet werden. Zum Anhalten des Motors werden z.B. die unteren auf leitend und die oberen auf sperrend geschaltet - Der Motor wird dadurch schnell abgebremst, denn durch einen Transistor und eine Freilaufdiode fließt ein nicht unerheblicher Bremsstrom.<br />
Alternativ kann man auch alle Transistoren auf sperrend schalten, der Motor läuft dann im Leerlauf aus.<br />
<br />
Die Transistoren einer Seite dürfen nicht dauerhaft gleichzeitig auf "leitend" geschaltet werden, da dies einen Kurzschluss verursacht.<br />
<br />
Hinweis: Zumindestens bei dem Transistor BUZ11 handelt es sich um ein veraltetes Modell. Wenn es auf hohe Leistung ankommt, sollte da ein anderer Transistor gewählt werden.<br />
<br />
====Elektrische Ansteuerung der Gates====<br />
Beim Umschalten der Transistoren entsteht eine erhöhte Verlustleistung - der Widerstand wechselt von sperrend (sehr großer Widerstand) nach leitend (sehr kleiner Widerstand) und umgekehrt.<br />
<br />
Zwischen beiden Enden des Schaltvorgangs befindet sich der Transistor in der "Widerstandsphase" (weder ganz leitend, noch ganz sperrend), die eine erhebliche Verlustleistung und damit Erwärmung mit sich bringt.<br />
<br />
Deshalb sollte der Schaltvorgang - insbesondere wenn für eine PWM-Gegelung sehr oft geschaltet werden soll - möglichst schnell erfolgen. Da zum Umschalten die durch den Aufbau des MOSFETs bedingte Gatekapazität umgeladen werden muss, ist hierzu (sehr kurzzeitig) ein hoher Stromfluss nötig.<br />
=====Schaltung direkt am Port=====<br />
Eine Ansteuerung unmittelbar über den Ausgang eines Mikrocontrollers (oder eines TTL-IC) ist schon wegen der benötigten Spannungen nicht möglich. <br />
<br />
Bei den N-FET könnte man sog. "Logik-MOSFET" nehmen, die bereits bei 5V ausreichend leitet. <br />
<br />
Bei den P-MOSFET bemisst sich die Schaltspannung gegen UB, mit einem 5V Port und UB=12V würde also zwischen -12V und -7V umgeschaltet, was einen P-MOSFET erfordern würde, der bereits bei -7V sperrt.<br />
<br />
Dass ein Portpin nur einen geringen Stromfluss (~20mA) zulässt, ist ein weiteres Problem und verhindert einen Schaltvorgang mit idealer steiler Flanke. Allerdings ist die Schaltungsvariante mit einem Transistor in diesem Punkt keinesfalls besser, wenn die Gatekapazität durch den PullUp-Widerstand umgeladen werden muss.<br />
=====Schaltung mit einem Transistor=====<br />
Eine einfache Steuerschaltung besteht aus einem Transistor-Schalter und einem Pull-Up-Widerstand. Als Schalter hab ich 1/7 eines ULN2003 IC verwendet, als PullUp 2200 Ohm. Ein diskreter Aufbau mit 1 Transistor und 2 Widerständen ist aber auch nicht komplizierter.<br />
<br />
Der Vorteil liegt in der Einfachheit, der Nachteil liegt darin, dass die Schaltung nicht sonderlich schnell vonstatten geht: Für die Schaltung des FET muss die Gate-Kapazität transferiert werden, was insbesondere beim Wechsel von 0V nach UB einen Moment dauert, da die Ladung durch den Widerstand hindurch muss.<br />
<br />
Ein kleinerer Widerstand könnte hier helfen, verursacht allerdings einen nicht unerheblichen Stromfluss im geschalteten Zustand (zulässige Verlustleistung beachten).<br />
=====Schaltung mit zwei Transistoren=====<br />
Eine bessere Ansteuerung sollte sich ergeben, wenn man zwei Transistoren zur Gate-Ansteuerung verwendet: Einer schaltet gegen 0V, der andere Gegen UC. So kann man erreichen, dass in beide Richtungen rasch umgeschaltet werden kann.<br />
=====Integrierte Gate-Treiber=====<br />
Statt der Beschaltung mit zwei Transistoren kann man auch einen integrierten MOSFET-Treiber verwenden. Mit derartige IC sind darauf ausgelegt, kurzfristig den für eine Umschaltung benötigten hohen Stromfluss zu ermöglichen.<br />
<br />
Es gibt auch Treiber-IC, die zur Ansteuerung der oberen Transistoren eine Spannung oberhalb von UB erzeugen. Mit solchen Highside-Treibern kann die H-Brücke auch aus 4 N-Kanal-Transistoren gebaut werden, was den Vorteil hat, dass N-Kanal-FET mit geringerem Schaltwiderstand zu bekommen sind.<br />
<br />
====Logische Ansteuerung der Gates====<br />
Nach der elektrischen Ansteuerung ist die logische Ansteuerung durch den Mikrocontroller zu überlegen.<br />
<br />
=====Mögliche Querströme=====<br />
In der H-Brücke sind zwei problematische Zustände zu berücksichtigen:<br />
<br />
1. Das offensichtliche Problem ist ein Kurzschluss: Wenn beide Transistoren einer Seite auf leitend geschaltet werden wird dadurch ein Kurzschluss erzeugt. Falls vorhanden brennt die Sicherung durch - ist keine Sicherung vorhanden, brennt was anderes durch.<br />
<br />
2. Ein nicht so offensichtliches Problem rührt daher, dass der Schaltvorgang nur mit endlicher Geschwindigkeit abläuft und der Transistor auch schon vor Erreichen des Zielwertes der Gate-Spannung erheblichen Strom leitet. Hierdurch kommt es zu einem Kurzschluss durch den nicht mehr richtig gesperrten und den noch nicht richtig gesperrten Transistor.<br />
<br />
Die Stromspitze selbst liegt noch im Rahmen der Spezifikationen der Transistoren. Sofern ein Messwiderstand von z.B. 0,1 Ohm da ist oder die Spannungsquelle einen vergleichbaren Innenwiderstand hat fließt ein Strom von weniger als 70A, die Transistoren sind jeweils für Spitzen von über 100A spezifiziert.<br />
<br />
Allerdings hat die Stromspitze drei Auswirkungen: <br />
<br />
# Die Transistoren erwärmen sich<br />
# Es kann an einem Messwiderstand zu einer Spannungsspitze kommen<br />
# Die Versorgungsspannung bricht kurzzeitig zusammen<br />
<br />
----<br />
<br />
Die Erwärmung des Transistors ist solange kein Problem, wie nur selten umgeschaltet wird. Bei einer Regelung per PWM könnten sich die kleinen Energiemengen zu einem relevanten Problem addieren. <br />
<br />
Da die Erwärmung - sofern sie relevant wird - leicht ohne Messinstrumente feststellbar ist, dürfte dieser Teil des Problems insofern handhabbar sein, als man leicht feststellen kann, ob das Problem relevant ist und das Problem auf die Transistoren beschränkt sind.<br />
<br />
Bei Leerlauf-Schaltvorgängen im Abstand von 1/15 Sekunden habe ich keine Erwärmung der Transistoren feststellen können, es wurden auch keine zusätzlichen Kühlkörper verwendet.<br />
<br />
----<br />
Die Spannungsspitze am Messwiderstand kann abgeleitet werden:<br />
Als weitere Vorsichtsmaßnahme habe ich den Messport des Controllers mit einem Widerstand und einer Z5.1 Diode abgesichert.<br />
<br />
----<br />
<br />
Die Störung der Versorgungsspannung lässt sich ohne Oszilloskop nicht messen. Insbesondere in umfangreicheren Schaltungen können Störungen an ganz anderen Stellen (z.B. bei Sensoren) auftreten, die man dann nicht gleich mit der Motorsteuerung in Verbindung bringt.<br />
<br />
Um die Störung vom Controller fernzuhalten habe ich dem Spannungswandler vorsichtshalber eine kleine Schottky-Diode (SB140) vorgeschaltet, um ein Entladen des Stützkondensators zu verhindern.<br />
<br />
=====softwaremäßige Ansteuerung=====<br />
Die einfachste Art der Ansteuerung besteht darin, die Schalter der 4 Gates mit 4 Ausgängen des Controllers zu verbinden.<br />
<br />
Die korrekte Ansteuerung muss dann durch die Software garantiert werden. <br />
<br />
Eine Fehlschaltung der Software z.B. bei einem Absturz kann allerdings zur Zerstörung der Schaltung führen, die Schaltung sollte also in jedem Fall eine Sicherung haben.<br />
<br />
=====Einfache Ansteuerung=====<br />
Etwas sicherer ist es, die Schaltung so aufzubauen, dass ein Kurzschluss nicht dauerhaft geschaltet werden kann.<br />
<br />
Hierzu habe ich die Schaltung so aufgebaut, dass die Gates einer Seite jeweils gemeinsam geschaltet werden. <br />
<br />
Bei einer Gate-Spannung von 0V sperrt der N-MOSFET (U<sub>GS</sub>=0V), der P-MOSFET leitet bei dieser Gate-Spannung, da hier U<sub>GS</sub>=-UB ist. <br />
<br />
Bei einer Gate-Spannung von UB verhält es sich genau umgekehrt: Der N-MOSFET leitet (U<sub>GS</sub>=UB) und der P-MOSFET sperrt (U<sub>GS</sub>=0V)<br />
<br />
Diese einfache Ansteuerung benötigt lediglich zwei Transistorschalter und auch nur 2 Port-Pins, hat jedoch den Nachteil, dass die oben beschriebenen Querströme auftreten.<br />
=====Verbesserungsmöglichkeiten=====<br />
Zur Lösung des Querstrom-Problems gibt es mehrere Ansatzmöglichkeiten, die ebenfalls mit zwei Controller-Ausgängen auskommen.<br />
----<br />
Mittels Logik-Bausteinen werden zwei Ausgänge des Controllers so umgesetzt, dass die folgenden Zustände geschaltet werden können:<br />
<br />
# Motor-Stop: untere Transistoren leitend, obere sperrend (oder umgekehrt)<br />
# Motor-Vorlauf: 1. Diagolale leitend<br />
# Motor-Rücklauf: 2. Diagonale leitend<br />
# Motor-Leerlauf: Alle Transistoren sperrend<br />
<br />
Die Querstrom-Problematik kann hierbei softwaremäßig gelöst werden, indem beim Umschalten jeweils kurz der Leerlauf geschaltet wird, damit alle Transistoren sperren.<br />
----<br />
Eine andere Möglichkeit besteht darin, das Umladen der Gate-Kapazität asymmetrisch zu gestalten, so dass die Transistoren schneller auf sperrend als auf leitend geschaltet werden. Eine einfache Möglichkeit ist die Parallelschaltung einer Diode und eines Widerstandes: In Sperr-Richtung fließt die Ladung langsamer als in die Durchlass-Richtung.<br />
===Heidingscher Encoder===<br />
Aufgrund der Kritik an der Schaltung entschied ich mich einen neuen, einfachen sowie preisgünstigen Encoder zu entwickeln, den man mit der 74series aufbauen kann. Als Treiber können sowohl Transistoren verwendet werden, dabei aber Vorwiderstände nicht vergessen! Die 74series sind mit 20mA Treiberstrom also natürlich nicht zum direkten Treiben geeignet.<br />
Die Logikanzeigen in den Grafiken sollen je einen Transistor bzw. Mosfet darstellen.<br />
====PR Encoder===<br />
[[Bild:Prtreiber.png]]<br />
Der PR Encoder(PWM-Richtung Encoder) ist mit zwei NOR Gates sowie eines Inverters aufgebaut, d.h. man kann ihn mit nur einem IC(74HC(T)02) aufbauen. Will mein 2 Encoder verwenden, empfliehlt sich den Inverter auszulagern (74HC(T)04 oder 74HC(T)14 Sollte man keinen Schmitt-Trigger benötigen empfiehlt sich aus Schnelligkeitsgründen die 74HC(T)04 Variante). <br />
Alternativ ist es noch möglich sich den Inverter zu sparen, und die Ansteuerung für den P(WM) Kanal invertiert laufen zu lassen. <br />
====PRK Encoder===<br />
[[Bild:Prktreiber.png]]<br />
Der Prk-Encoder(PWM-Richtung-Kurzschluss-Treiber) ist eine Erweiterung des PR-Encoders. Er erlaubt es zusätzlich, die Motoren durch einen Kurzschluss zu stoppen.<br />
Aufgebaut werden kann dieser aus 1 NOR und 1 Nand Gate. Dabei werden 3 Nand-Gates als Inverter beschaltet. (d.h. eine die Leitung die übrig bleibt auf Vcc).<br />
====Support====<br />
Fragen einfach in das Forum posten, oder mich anschreiben(User s.o.)<br />
===Alte Schaltungsbeschreibung===<br />
{{FarbigerRahmen|<br />
Achtung! Die Schaltung ist so nicht zu verwenden! Siehe unter '''Kritik an der Schaltung'''<br />
}}<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz. Eine der interessantesten Schaltungen, die im Roboternetz vorgestellt wurde, dürfte diese sein:<br />
<br />
<br />
[[Bild:hbrueckemosfet.gif|center]]<br />
<br />
<br />
Anmerkung: Den 74HC26N gibts wohl nicht , nur die TTL-Version 74LS26, die HC-Mos-Version lautet 74HC03.<br />
<br />
Eine sogenannte H-Brücke, die nur aus zwei MOSFETSs und einem Logik-IC besteht. Mit zwei Controllerports kann diese Schaltung sowohl Geschwindigkeit als auch Drehrichtung regeln. Für die Geschwindigkeit ist ein sogenannter [[PWM]]-Port notwendig. Also ein Port, der durch ein gepulstes Signal den Motor etlichemal innerhalb einer Sekunde ein- und ausschaltet und somit quasi die Leistung regelt (siehe [[PWM]]).<br />
Die Schaltung ist so konstruiert, dass immer nur zwei Transistoren durchschalten. Auf diese Weise fließt einmal der Strom von links oben nach rechts unten und einmal von rechts oben nach links unten, der Motor wird also ähnlich wie bei der Relaisschaltung umgepolt. <br />
Bei niedriger [[PWM]]_Frequenz sollte die Schaltung durchaus für einige Ampere geeignet sein, wobei ca. 8 bis 13V ideal sein sollten.<br />
<br />
Das Logic-IC wurde durch 3x BC547 Transitoren ersetzt.<br />
<br />
<br />
[[Bild:Hbrückenmosfet BD547.PNG|center|900px]]<br />
<br />
====Kritik an der Schaltung====<br />
<br />
Diese Schaltung wird im Forum von mehreren Leuten, u.A. Ratber, shaun, massiv kritisiert, z.B. hier: http://www.roboternetz.de/phpBB2/viewtopic.php?t=33067&sid=892e80c6cd2d003292e607bcd7a7123a .<br />
<br />
Ich habe leider nicht das Wissen eine bessere Lösung zu liefern. Das Problem sind die Querströme: Im Umschaltmoment sind highside und lowside switch für kurze Zeit beide leitend. Das entspricht einem Kurzschluss der Versorgungsleitung bei jedem Umschalten mit allen damit verbundenen Problemen (Erwärmung, Schwingung, Sicherungen, Reset). Aus diesem Grund sind NAND-Gatter nicht geeignet!<br />
<br />
Zum Umschalten muss man<br />
*den bisher leitenden Mosfet ausschalten,<br />
*dann etwas warten,<br />
*und schließlich den nächsten Mosfet schließen.<br />
<br />
Dies kann man erreichen, indem man den Einschaltmoment <br />
*durch RC-Glieder verzögert und <br />
*den Ausschaltmoment durch Dioden beschleunigt.<br />
Die entstehenden Schaltungen sind komplex, benötigen viele Bauteile und sind fehleranfällig.<br />
<br />
<br />
Am sinnvollsten sind integrierte Mosfet-Treiber. Diese haben oft eine einstellbare Tot-Zeit (''Dead-Time''), können hohe Leistungen zum Umladen der Gatekapazität liefern und beachten andere Effekte wie ''Propagation-Time'', Veränderung des Source Potentials beim Highside-switch, etc.<br />
<br />
'''Erklärung von shaun:'''<br />
<br />
die gezeigte Schaltung taugt auch nur als Prinzipschaltung bedingt, da man einen variierenden Aufwand in eine sichere Verriegelung investieren müsste. Bei fixer und nicht zu hoher Betriebsspannung könnte man mit RD-Kombinationen in den Gateleitungen das Ausschalten beschleunigen und das Einschalten verzögern, so dass die Querleitung wegfällt. Allerdings bewirkt diese simple R-Cg-Verzögerung größere Schaltverluste. <br />
<br />
Setzt man die Vezögerung vor dedizierte Treiber, müssen diese wiederum leistungsfähig genug zum Umladen der Gates sein und bis an die Versorgung heranreichen, weshalb man an diesem Punkt überlegen sollte, ob 95% duty cycle nicht auch reichen würden ''(Anmerkung: Bezug auf bootstrapping?)'' und man integrierte Treiber für reine N-Kanal-Bestückung einsetzen sollte - spart dann wieder etwas Verluste am Highside-Switch, weil N-Kanäler gleicher Generation und Leistungsklasse einen niedrigeren Rds(on) als ihre P-Pendants haben.<br />
<br />
{{Ausbauwunsch|Eine vernünftige diskrete Ansteuerung für eine H-Brücke.<br />
Korrektur auf Rechtschreibfehler, Zeichensetzung, Schreibstil, Fachausdrücke. Gibt's denn keinen der etwas verbessern möchte?}}<br />
==Ansteuerung mit einem LeistungsOPV==<br />
Die wohl preislich und platztechnisch günstigste Alternative zur Ansteuerung von Motoren in H-Brücken ist die Verwendung von (Leistungs-)Operationsverstärkern. <br />
===Heidingscher Motortreiber=== <br />
Bei dem Heidingschen Motortreiber wird jeder Anschluss des Motors mit einem Ausgang des Operationsverstärker verbunden, die Eingänge des OPVs selbst als Komparator. Diese Methode ist für kleine und mittlere Motoren(=< 1A) und mäßige PWM-Frequenzen(<10kHz) gut geeignet. Ein RB35 von Conrad kann damit problemlos angesteuert werden. Bei zu hohen PWM-Frequenzen ist die SlewRate von vielen OPVs zu gering und die entsprechenden OPVs sind dann viel zu teuer und man sollte eine Ansteuerung per Mosfet(s.o.) bevorzugen. Momentan hat sich der TCA 0372 DP1 (57ct bei Reichelt) Verwendung gefunden. <br />
Weitere Informationen sind in folgendem Forumsbeitrag zu finden:<br />
http://www.roboternetz.de/phpBB2/viewtopic.php?t=38412<br />
===Gleichstromansteuerung===<br />
Eine weitere Möglichkeit ist es, dem Operationsverstärker eine Gleichspannung vorzugeben, mit denen der OPV die Motoren ansteuert. Diese Methode eignet sich sehr gut für analoge Schaltkreise. Der Wirkungsgrad ist allerdings nicht der beste, da die restliche Spannung in Wärme umgesetzt wird. Zudem werden viele weitere komponenten benötigt, dass den Aufbau treuerer und fehleranfälliger macht.<br />
Der entsprechenden Schaltkreis ist im Datenblatt des TCA 0372 DP1 zu finden.<br />
<br />
==Ansteuerung mit Treiber IC L293 D==<br />
<br />
Dies ist ohne Zweifel die am häufigsten genutzte Ansteuerung bei Roboter-Bastlern: Man nimmt einfach das IC L293D, denn darin sind sogar zwei H-Brücken enthalten. Also mit einem IC lassen sich ohne weiteres externe Bauteile gleich zwei Motoren ansteuern. Zwar nur bis ca. 600mA, aber das reicht oft schon für kleinere bis mittlere Roboteranwendungen aus.<br />
<br />
[[Bild:L293Pinout.JPG|center]]<br />
<br />
<br />
[[Bild:hbrueckel293d.gif|center]]<br />
<br />
Wie aus dem Schaltbild zu ersehen ist, werden für die Ansteuerung jedes Motors 3 Ports benötigt. Die Enable-Leitung führt man oft auf einen PWM-Port welcher wie bei der MOS-FET Schaltung oben die Geschwindigkeit regelt. Die beiden anderen Ports geben die Drehrichtung an. Immer wenn die Ports unterschiedliche Polarität haben dreht der Motor in eine bestimmte Richtung, je nachdem wo Low und High anliegt. Das Besondere ist, dass wenn an beiden Ports der gleiche Pegel anliegt, also zweimal Low oder High, dann wird nämlich der Motor kurzgeschlossen - das fungiert als Bremse. Das Bremsen kann bei Robotern durchaus nützlich sein. Zudem ist bei schnellen Richtungswechseln immer zu empfehlen zuerst kurz zu bremsen, um nicht den Motor oder Motortreiber zu stark zu belasten.<br />
<br />
==Ansteuerung mit dem Schaltkreis L298==<br />
<br />
Der Schaltkreis L298 ist quasi der große Bruder des L293D. Er beinhaltet auch zwei komplette H-Brücken, kann also auch zwei Motoren ansteuern. Die Pinbelegung ist ebenfalls dem L293D sehr ähnlich, jedoch verfügt er über eine andere Bauform:<br />
<br />
<br />
[[Bild:L298Pinout.JPG|center]]<br />
<br />
<br />
Der wichtigste Unterschied besteht jedoch darin, dass jede H-Brücke bei L298 bis zu 2A belastet werden kann. Damit lassen sich also schon wesentlich größere Motoren ansteuern. Ein weiterer Vorzug sind die sogenannten SENSE-Ausgänge, über die der komplette Strom fließt. Oft wird hier ein Hochlastwiderstand angeschlossen, um aus der abfallenden Spannung den genauen Strom berechnen zu können. Dies machen sich Steuerungen wie [http://www.roboternetz.de/phpBB2/viewtopic.php?t=2741 RN-Motor] oder aber andere Schrittmotoransteuerungen zunutze, um den Strom genau zu regeln. Benötigt man keine Strommessung, so müssen die Sense-Ausgänge immer direkt mit GND verbunden werden. In diesem Fall muss allerdings eine andere Strombegrenzung eingeplant werden. Wird keine Strombegrenzung eingebaut, müssen diese Widerstände trotztem eingebaut werden, da der Treiber sonst heiss wird.<br />
<br />
<br />
[[Bild:hbrueckel298.gif|center]]<br />
<br />
<br />
Ein weiteres Schaltbild gibt es hier [http://www.roboternetz.de/bilder/schaltung298getriebe.gif]<br />
<br />
==Ansteuerung mit L6205==<br />
Der Schaltkreis L6205 stellt eine etwas modernere Alternative zur L298 Ansteuerung dar. Die Ansteuerung ist praktisch identisch, der Schaltungsaufbau in etwa gleich. Beim L6205 sind keine Freilaufdioden mehr notwendig, dafür ist ein Kondensator und zwei Dioden für die interne Spannungserzeugung notwendig.<br />
Ein großer Vorteil ist auch das kein extra Kühlkörper mehr notwendig ist. Viele integrierte Schutzfunktionen im L6205 sorgen dafür das der Chip nicht so einfach zerstört werden kann. In der Praxis sind die angegeben 2,8A jedoch mit Vorsicht zu geniesen. Bei Testlayouts erwärmten sich die IC´s bereits bei 2A Dauerstrom (PWM) oft so stark das die automatische Temperaturabschaltung reagierte, somit wird man vermutlich ohne Kühlung oder großes Kühllayout auf er Platine auch nicht mehr als beim L298 erreichen. <br />
<br />
[[Bild:l6205ic.gif]] [[Bild:l6205pinbelegung.gif]]<br />
<br />
<br />
[[Bild:l6205.gif|center]]<br />
<br />
==Noch mehr Power gewünscht?==<br />
<br />
Obwohl der L298 schon einiges abdeckt, so kommt er spätestens bei den Scheibenwischermotoren langsam an seine Grenzen. Bei starker Belastung können solche Motoren kurzzeitig bis ca. 10 A und mehr ziehen. Für solch starke Motoren gibt es jetzt einen ganz interessanten Motorchip aus dem KFZ-Bereich: vnh3sp (Datenblatt im Roboternetz Download-Bereich). <br />
Mit ihm lassen sich sogar recht große Motoren ansteuern; vorausgesetzt, man kühlt ihn entsprechend, so verträgt der Chip bis zu 30A. Aber selbst ohne Kühlung bietet er bedeutet mehr Leistung als der L298. Das Schöne, die Ansteuerung ist kaum anders als beim L298 und L293D.<br />
<br />
Kleiner Nachteil: Da es ein SMD-Chip mit 1mm Kontaktabstand ist, muss man schon eine geeignete Platine (spezielles Layout mit Kühlflächen) und etwas Löterfahrung besitzen. Inzwischen gibt es aber schon verschiedene RN-Projekte mit dem Chip (RN-Power, RN-Mini H-Bridge), Platinen und Chip können über den [http://www.shop.robotikhardware.de/shop/catalog/index.php Robotikhardware.de-Platinenservice] bezogen werden. <br />
<br />
<br />
[[Bild:minihbridge_ansteuerung.gif|center]]<br />
<br />
<br />
Alternativ zum [[SMD]]-Chip VNH3SP30 gibt es noch die Alternative VNH2SP30. Dieser Chip erlaubt zwar nur Motorspannungen zwischen 6 und 16 Volt, jedoch hat er einen wesentlich geringeren Innenwiderstand und wird deshalb nur etwa halb so warm wie der VNH3SP30. <br />
Aus diesem Grund eignet er sich auch ideal für kleine Doppelmotorsteuerungen.<br />
Natürlich gibt's auch hierfür ein Projekt und eine Bauanleitung, siehe [[RN-VNH2Dualmotor]]<br />
<br />
Das Schöne ist, dass es dieses RN-Projekt jetzt auch auch als Fertigmodul gibt!<br />
<br />
<br />
[[Bild:rndualmotoransteuerung.jpeg|center]]<br />
<br />
==Endstufen mit I2C-Bus / RS232==<br />
[[Bild:motctrl.png|thumb|Motoransteuerung über RS232, I2C, RC]]Verwendet man eine der oben vorgestellten H-Bridges, so wird immer vorausgesetzt das ein PWM-Signal und mehrere Ports zur Ansteuerung bereitstehen. Ist dies nicht der Fall weil diese vielleicht schon belegt sind, so lassen sich Endstufen durch einen zusätzlichen Microcontroller auch um beliebige Schnittstellen erweitern. Insbesondere über I2C lassen sich dadurch mehrere Motorboards über einen einzigen Bus ansteuern. Ein Beispiel ist der programmierte Controller MOTCTRL, der speziell für diese Aufgabe gedacht ist. Die Grundscháltung sieht man in der rechten Skizze.<br />
<br />
==Und nie vergessen Motoren zu entstören==<br />
<br />
Das Entstören dient dazu, das sogenannte "Bürstenfeuer" zu verhindern, wodurch Störungen hervorgerufen werden könnten. Und so wirds gemacht:<br />
<br />
<br />
[[Bild:entstoerung.gif|center]]<br />
<br />
==Siehe auch==<br />
* [[Getriebemotoren]]<br />
* [[RN-VNH2Dualmotor]]<br />
<br />
==Weblinks==<br />
* [http://www.roboternetz.de/phpBB2/motordrehmoment.php Drehmoment Berechnung]<br />
* [http://www.roboternetz.de/motoruebersicht.html Motoren Übersicht]<br />
* [http://www.shop.robotikhardware.de/shop/catalog/index.php?cPath=65 Bauteilesets]<br />
* [http://www.roboternetz.de/robotertutorial.html Roboter-Tutorial]<br />
* [http://www.roboternetz.de Roboternetz Forum]<br />
<br />
[[Category:Robotikeinstieg]]<br />
[[Category:Praxis]]<br />
[[Category:Grundlagen]]<br />
[[Category:Motoren]]<br />
[[Category:Elektronik]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Datei:Prktreiber.png&diff=13277Datei:Prktreiber.png2008-03-15T12:03:32Z<p>Overthere: </p>
<hr />
<div></div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Datei:Prtreiber.png&diff=13276Datei:Prtreiber.png2008-03-15T11:51:19Z<p>Overthere: Heidingscher Encoder für P(WM) und R(richtungs)ansteuerung bei Mosfetansteuerung</p>
<hr />
<div>Heidingscher Encoder für P(WM) und R(richtungs)ansteuerung bei Mosfetansteuerung</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Getriebemotoren_Ansteuerung&diff=13219Getriebemotoren Ansteuerung2008-02-25T15:20:52Z<p>Overthere: </p>
<hr />
<div>Hat man sich entschlossen, für seinen Roboter oder andere Konstruktion einen Getriebemotor zu verwenden, so muss man sich Gedanken machen, wie man ihn ansteuert. Gewöhnlich will man die Motoren ja sowohl in Bezug auf Drehrichtung und Geschwindigkeit über eine Programmiersprache steuern. Daher wird in der Regel erst mal ein Controllerboard benötigt. Leider kann man an die wenigsten Controllerboards einen Getriebemotor direkt anschließen, eine der wenigen Ausnahmen ist das [[RN-Control]]-Board und das RNBFRA-Board. Bei beiden Boards ist es einfach, dort müssen die Getriebemotoren einfach nur an die Schraubklemmen angeschlossen werden, danach kann man sofort mit der Programmierung loslegen.<br />
<br />
Ich möchte hier aber aufzeigen, wie man Motoren auch bei anderen Boards anschließen kann. Die gleiche Technik läßt sich natürlich auch nutzen, um z.B. mehr als zwei Motoren an [[RN-Control]] anzuschließen.<br />
<br />
==Ansteuerung mit Relais==<br />
<br />
Die einfachste Methode, um Motoren per [[Microcontroller|Controller]] anzusteuern, erreicht man durch die Verwendung von Relais. Mit einem Relais, das zwei Umschaltkontakte besitzt, lässt sich über einen einzelnen Controllerport bequem die Drehrichtung wechseln.<br />
<br />
[[Bild:hbrueckerelais.gif|center]]<br />
<br />
Da auch Relais wegen des Strombedarfes nicht direkt vom Controller geschaltet werden können, wurde in dem oberen Beispiel ein Transistor vorangestellt. Die Diode dient nur dazu, die Spannungen, die beim Ausschalten des Relais induziert werden, abzuleiten. Ohne Diode funktioniert das Ganze in der Regel auch, jedoch könnte der Transistor oder sogar der Controller durch die induzierte Spannung beschädigt werden. <br />
Die Schaltung ist also in der Lage, die Drehrichtung umzuschalten, jedoch nicht in der Lage, den Motor zu stoppen. Um den Motor ganz auszuschalten, müsste man noch ein weiteres Relais vorsehen, das die gesamte Motorspannung abschaltet. Ein Schaltbild können wir uns ersparen, da das Ganze recht ähnlich aussieht. <br />
Der große Nachteil von Relaisschaltungen ist, dass die Geschwindigkeit des Motors nicht geregelt werden kann, zudem haben Relais bei sehr vielen Schaltvorgängen einen gewissen Verschleiß. <br />
Vorteil der Schaltung ist jedoch, das man auch sehr große Lasten/Motoren schalten kann.<br />
<br />
==Ansteuerung mit MOS-FET==<br />
===Neufassung===<br />
{{Ausbauwunsch|Die Neufassung kann im momentanen Stand nur als Anregung verstanden werden.<br />
<br />
Insbesondere fehlen noch angepasste Schaltpläne.<br />
<br />
Einige der Anmerkungen aus dem Abschnitt "Kritik an der Schaltung" sind in der Neufassung noch nicht enthalten, die Beschreibung von Verzögerungsgliedern müsste auch eine Erklärung enthalten, welche Verzögerung mit welchen Werten erreicht wird.<br />
<br />
Wenn die Neufassung komplett fertig ist, sollten die alten Texte weg.<br />
}}<br />
====Grundprinzip====<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz.<br />
<br />
Die Grundschaltung besteht aus 2 N-Kanal-MOSFET (hier BUZ11) und zwei P-Kanal-MOSFET (hier IRF5305), mit denen die Motoranschlüsse nach GND bzw. UB geschaltet werden. Zusätzlich sind noch 4 Schottky-Dioden (z.B. SB530) erforderlich, um Induktionsströme des Motors abzuleiten. Die Dioden werden in Sperrichtung von den beiden Motoranschlüssen nach GND bzw. UB geschaltet.<br />
<br />
Grundsätzlich muss die Beschaltung der Gate-Eingänge so erfolgen, dass zum Starten des Motors die Transistoren einer Diagonale auf "leitend" und die der anderen auf "sperrend" geschaltet werden. Zum Anhalten des Motors werden z.B. die unteren auf leitend und die oberen auf sperrend geschaltet - Der Motor wird dadurch schnell abgebremst, denn durch einen Transistor und eine Freilaufdiode fließt ein nicht unerheblicher Bremsstrom.<br />
Alternativ kann man auch alle Transistoren auf sperrend schalten, der Motor läuft dann im Leerlauf aus.<br />
<br />
Die Transistoren einer Seite dürfen nicht dauerhaft gleichzeitig auf "leitend" geschaltet werden, da dies einen Kurzschluss verursacht.<br />
<br />
Hinweis: Zumindestens bei dem Transistor BUZ11 handelt es sich um ein veraltetes Modell. Wenn es auf hohe Leistung ankommt, sollte da ein anderer Transistor gewählt werden.<br />
<br />
====Elektrische Ansteuerung der Gates====<br />
Beim Umschalten der Transistoren entsteht eine erhöhte Verlustleistung - der Widerstand wechselt von sperrend (sehr großer Widerstand) nach leitend (sehr kleiner Widerstand) und umgekehrt.<br />
<br />
Zwischen beiden Enden des Schaltvorgangs befindet sich der Transistor in der "Widerstandsphase" (weder ganz leitend, noch ganz sperrend), die eine erhebliche Verlustleistung und damit Erwärmung mit sich bringt.<br />
<br />
Deshalb sollte der Schaltvorgang - insbesondere wenn für eine PWM-Gegelung sehr oft geschaltet werden soll - möglichst schnell erfolgen. Da zum Umschalten die durch den Aufbau des MOSFETs bedingte Gatekapazität umgeladen werden muss, ist hierzu (sehr kurzzeitig) ein hoher Stromfluss nötig.<br />
=====Schaltung direkt am Port=====<br />
Eine Ansteuerung unmittelbar über den Ausgang eines Mikrocontrollers (oder eines TTL-IC) ist schon wegen der benötigten Spannungen nicht möglich. <br />
<br />
Bei den N-FET könnte man sog. "Logik-MOSFET" nehmen, die bereits bei 5V ausreichend leitet. <br />
<br />
Bei den P-MOSFET bemisst sich die Schaltspannung gegen UB, mit einem 5V Port und UB=12V würde also zwischen -12V und -7V umgeschaltet, was einen P-MOSFET erfordern würde, der bereits bei -7V sperrt.<br />
<br />
Dass ein Portpin nur einen geringen Stromfluss (~20mA) zulässt, ist ein weiteres Problem und verhindert einen Schaltvorgang mit idealer steiler Flanke. Allerdings ist die Schaltungsvariante mit einem Transistor in diesem Punkt keinesfalls besser, wenn die Gatekapazität durch den PullUp-Widerstand umgeladen werden muss.<br />
=====Schaltung mit einem Transistor=====<br />
Eine einfache Steuerschaltung besteht aus einem Transistor-Schalter und einem Pull-Up-Widerstand. Als Schalter hab ich 1/7 eines ULN2003 IC verwendet, als PullUp 2200 Ohm. Ein diskreter Aufbau mit 1 Transistor und 2 Widerständen ist aber auch nicht komplizierter.<br />
<br />
Der Vorteil liegt in der Einfachheit, der Nachteil liegt darin, dass die Schaltung nicht sonderlich schnell vonstatten geht: Für die Schaltung des FET muss die Gate-Kapazität transferiert werden, was insbesondere beim Wechsel von 0V nach UB einen Moment dauert, da die Ladung durch den Widerstand hindurch muss.<br />
<br />
Ein kleinerer Widerstand könnte hier helfen, verursacht allerdings einen nicht unerheblichen Stromfluss im geschalteten Zustand (zulässige Verlustleistung beachten).<br />
=====Schaltung mit zwei Transistoren=====<br />
Eine bessere Ansteuerung sollte sich ergeben, wenn man zwei Transistoren zur Gate-Ansteuerung verwendet: Einer schaltet gegen 0V, der andere Gegen UC. So kann man erreichen, dass in beide Richtungen rasch umgeschaltet werden kann.<br />
=====Integrierte Gate-Treiber=====<br />
Statt der Beschaltung mit zwei Transistoren kann man auch einen integrierten MOSFET-Treiber verwenden. Mit derartige IC sind darauf ausgelegt, kurzfristig den für eine Umschaltung benötigten hohen Stromfluss zu ermöglichen.<br />
<br />
Es gibt auch Treiber-IC, die zur Ansteuerung der oberen Transistoren eine Spannung oberhalb von UB erzeugen. Mit solchen Highside-Treibern kann die H-Brücke auch aus 4 N-Kanal-Transistoren gebaut werden, was den Vorteil hat, dass N-Kanal-FET mit geringerem Schaltwiderstand zu bekommen sind.<br />
<br />
====Logische Ansteuerung der Gates====<br />
Nach der elektrischen Ansteuerung ist die logische Ansteuerung durch den Mikrocontroller zu überlegen.<br />
<br />
=====Mögliche Querströme=====<br />
In der H-Brücke sind zwei problematische Zustände zu berücksichtigen:<br />
<br />
1. Das offensichtliche Problem ist ein Kurzschluss: Wenn beide Transistoren einer Seite auf leitend geschaltet werden wird dadurch ein Kurzschluss erzeugt. Falls vorhanden brennt die Sicherung durch - ist keine Sicherung vorhanden, brennt was anderes durch.<br />
<br />
2. Ein nicht so offensichtliches Problem rührt daher, dass der Schaltvorgang nur mit endlicher Geschwindigkeit abläuft und der Transistor auch schon vor Erreichen des Zielwertes der Gate-Spannung erheblichen Strom leitet. Hierdurch kommt es zu einem Kurzschluss durch den nicht mehr richtig gesperrten und den noch nicht richtig gesperrten Transistor.<br />
<br />
Die Stromspitze selbst liegt noch im Rahmen der Spezifikationen der Transistoren. Sofern ein Messwiderstand von z.B. 0,1 Ohm da ist oder die Spannungsquelle einen vergleichbaren Innenwiderstand hat fließt ein Strom von weniger als 70A, die Transistoren sind jeweils für Spitzen von über 100A spezifiziert.<br />
<br />
Allerdings hat die Stromspitze drei Auswirkungen: <br />
<br />
# Die Transistoren erwärmen sich<br />
# Es kann an einem Messwiderstand zu einer Spannungsspitze kommen<br />
# Die Versorgungsspannung bricht kurzzeitig zusammen<br />
<br />
----<br />
<br />
Die Erwärmung des Transistors ist solange kein Problem, wie nur selten umgeschaltet wird. Bei einer Regelung per PWM könnten sich die kleinen Energiemengen zu einem relevanten Problem addieren. <br />
<br />
Da die Erwärmung - sofern sie relevant wird - leicht ohne Messinstrumente feststellbar ist, dürfte dieser Teil des Problems insofern handhabbar sein, als man leicht feststellen kann, ob das Problem relevant ist und das Problem auf die Transistoren beschränkt sind.<br />
<br />
Bei Leerlauf-Schaltvorgängen im Abstand von 1/15 Sekunden habe ich keine Erwärmung der Transistoren feststellen können, es wurden auch keine zusätzlichen Kühlkörper verwendet.<br />
<br />
----<br />
Die Spannungsspitze am Messwiderstand kann abgeleitet werden:<br />
Als weitere Vorsichtsmaßnahme habe ich den Messport des Controllers mit einem Widerstand und einer Z5.1 Diode abgesichert.<br />
<br />
----<br />
<br />
Die Störung der Versorgungsspannung lässt sich ohne Oszilloskop nicht messen. Insbesondere in umfangreicheren Schaltungen können Störungen an ganz anderen Stellen (z.B. bei Sensoren) auftreten, die man dann nicht gleich mit der Motorsteuerung in Verbindung bringt.<br />
<br />
Um die Störung vom Controller fernzuhalten habe ich dem Spannungswandler vorsichtshalber eine kleine Schottky-Diode (SB140) vorgeschaltet, um ein Entladen des Stützkondensators zu verhindern.<br />
<br />
=====softwaremäßige Ansteuerung=====<br />
Die einfachste Art der Ansteuerung besteht darin, die Schalter der 4 Gates mit 4 Ausgängen des Controllers zu verbinden.<br />
<br />
Die korrekte Ansteuerung muss dann durch die Software garantiert werden. <br />
<br />
Eine Fehlschaltung der Software z.B. bei einem Absturz kann allerdings zur Zerstörung der Schaltung führen, die Schaltung sollte also in jedem Fall eine Sicherung haben.<br />
<br />
=====Einfache Ansteuerung=====<br />
Etwas sicherer ist es, die Schaltung so aufzubauen, dass ein Kurzschluss nicht dauerhaft geschaltet werden kann.<br />
<br />
Hierzu habe ich die Schaltung so aufgebaut, dass die Gates einer Seite jeweils gemeinsam geschaltet werden. <br />
<br />
Bei einer Gate-Spannung von 0V sperrt der N-MOSFET (U<sub>GS</sub>=0V), der P-MOSFET leitet bei dieser Gate-Spannung, da hier U<sub>GS</sub>=-UB ist. <br />
<br />
Bei einer Gate-Spannung von UB verhält es sich genau umgekehrt: Der N-MOSFET leitet (U<sub>GS</sub>=UB) und der P-MOSFET sperrt (U<sub>GS</sub>=0V)<br />
<br />
Diese einfache Ansteuerung benötigt lediglich zwei Transistorschalter und auch nur 2 Port-Pins, hat jedoch den Nachteil, dass die oben beschriebenen Querströme auftreten.<br />
=====Verbesserungsmöglichkeiten=====<br />
Zur Lösung des Querstrom-Problems gibt es mehrere Ansatzmöglichkeiten, die ebenfalls mit zwei Controller-Ausgängen auskommen.<br />
----<br />
Mittels Logik-Bausteinen werden zwei Ausgänge des Controllers so umgesetzt, dass die folgenden Zustände geschaltet werden können:<br />
<br />
# Motor-Stop: untere Transistoren leitend, obere sperrend (oder umgekehrt)<br />
# Motor-Vorlauf: 1. Diagolale leitend<br />
# Motor-Rücklauf: 2. Diagonale leitend<br />
# Motor-Leerlauf: Alle Transistoren sperrend<br />
<br />
Die Querstrom-Problematik kann hierbei softwaremäßig gelöst werden, indem beim Umschalten jeweils kurz der Leerlauf geschaltet wird, damit alle Transistoren sperren.<br />
----<br />
Eine andere Möglichkeit besteht darin, das Umladen der Gate-Kapazität asymmetrisch zu gestalten, so dass die Transistoren schneller auf sperrend als auf leitend geschaltet werden. Eine einfache Möglichkeit ist die Parallelschaltung einer Diode und eines Widerstandes: In Sperr-Richtung fließt die Ladung langsamer als in die Durchlass-Richtung.<br />
<br />
===Alte Schaltungsbeschreibung===<br />
{{FarbigerRahmen|<br />
Achtung! Die Schaltung ist so nicht zu verwenden! Siehe unter '''Kritik an der Schaltung'''<br />
}}<br />
Wesentlich günstiger und auch beliebter ist die Ansteuerung von Motoren mit MOS-FETs. Also Transistoren, die quasi leistungslos nur durch Spannungen geschaltet werden und extrem hohe Ströme verkraften. Zu diesem Thema findet man unzählige Beiträge im Roboternetz. Eine der interessantesten Schaltungen, die im Roboternetz vorgestellt wurde, dürfte diese sein:<br />
<br />
<br />
[[Bild:hbrueckemosfet.gif|center]]<br />
<br />
<br />
Anmerkung: Den 74HC26N gibts wohl nicht , nur die TTL-Version 74LS26, die HC-Mos-Version lautet 74HC03.<br />
<br />
Eine sogenannte H-Brücke, die nur aus zwei MOSFETSs und einem Logik-IC besteht. Mit zwei Controllerports kann diese Schaltung sowohl Geschwindigkeit als auch Drehrichtung regeln. Für die Geschwindigkeit ist ein sogenannter [[PWM]]-Port notwendig. Also ein Port, der durch ein gepulstes Signal den Motor etlichemal innerhalb einer Sekunde ein- und ausschaltet und somit quasi die Leistung regelt (siehe [[PWM]]).<br />
Die Schaltung ist so konstruiert, dass immer nur zwei Transistoren durchschalten. Auf diese Weise fließt einmal der Strom von links oben nach rechts unten und einmal von rechts oben nach links unten, der Motor wird also ähnlich wie bei der Relaisschaltung umgepolt. <br />
Bei niedriger [[PWM]]_Frequenz sollte die Schaltung durchaus für einige Ampere geeignet sein, wobei ca. 8 bis 13V ideal sein sollten.<br />
<br />
Das Logic-IC wurde durch 3x BC547 Transitoren ersetzt.<br />
<br />
<br />
[[Bild:Hbrückenmosfet BD547.PNG|center|900px]]<br />
<br />
====Kritik an der Schaltung====<br />
<br />
Diese Schaltung wird im Forum von mehreren Leuten, u.A. Ratber, shaun, massiv kritisiert, z.B. hier: http://www.roboternetz.de/phpBB2/viewtopic.php?t=33067&sid=892e80c6cd2d003292e607bcd7a7123a .<br />
<br />
Ich habe leider nicht das Wissen eine bessere Lösung zu liefern. Das Problem sind die Querströme: Im Umschaltmoment sind highside und lowside switch für kurze Zeit beide leitend. Das entspricht einem Kurzschluss der Versorgungsleitung bei jedem Umschalten mit allen damit verbundenen Problemen (Erwärmung, Schwingung, Sicherungen, Reset). Aus diesem Grund sind NAND-Gatter nicht geeignet!<br />
<br />
Zum Umschalten muss man<br />
*den bisher leitenden Mosfet ausschalten,<br />
*dann etwas warten,<br />
*und schließlich den nächsten Mosfet schließen.<br />
<br />
Dies kann man erreichen, indem man den Einschaltmoment <br />
*durch RC-Glieder verzögert und <br />
*den Ausschaltmoment durch Dioden beschleunigt.<br />
Die entstehenden Schaltungen sind komplex, benötigen viele Bauteile und sind fehleranfällig.<br />
<br />
<br />
Am sinnvollsten sind integrierte Mosfet-Treiber. Diese haben oft eine einstellbare Tot-Zeit (''Dead-Time''), können hohe Leistungen zum Umladen der Gatekapazität liefern und beachten andere Effekte wie ''Propagation-Time'', Veränderung des Source Potentials beim Highside-switch, etc.<br />
<br />
'''Erklärung von shaun:'''<br />
<br />
die gezeigte Schaltung taugt auch nur als Prinzipschaltung bedingt, da man einen variierenden Aufwand in eine sichere Verriegelung investieren müsste. Bei fixer und nicht zu hoher Betriebsspannung könnte man mit RD-Kombinationen in den Gateleitungen das Ausschalten beschleunigen und das Einschalten verzögern, so dass die Querleitung wegfällt. Allerdings bewirkt diese simple R-Cg-Verzögerung größere Schaltverluste. <br />
<br />
Setzt man die Vezögerung vor dedizierte Treiber, müssen diese wiederum leistungsfähig genug zum Umladen der Gates sein und bis an die Versorgung heranreichen, weshalb man an diesem Punkt überlegen sollte, ob 95% duty cycle nicht auch reichen würden ''(Anmerkung: Bezug auf bootstrapping?)'' und man integrierte Treiber für reine N-Kanal-Bestückung einsetzen sollte - spart dann wieder etwas Verluste am Highside-Switch, weil N-Kanäler gleicher Generation und Leistungsklasse einen niedrigeren Rds(on) als ihre P-Pendants haben.<br />
<br />
{{Ausbauwunsch|Eine vernünftige diskrete Ansteuerung für eine H-Brücke.<br />
Korrektur auf Rechtschreibfehler, Zeichensetzung, Schreibstil, Fachausdrücke. Gibt's denn keinen der etwas verbessern möchte?}}<br />
==Ansteuerung mit einem LeistungsOPV==<br />
Die wohl preislich und platztechnisch günstigste Alternative zur Ansteuerung von Motoren in H-Brücken ist die Verwendung von (Leistungs-)Operationsverstärkern. <br />
===Heidingscher Motortreiber=== <br />
Bei dem Heidingschen Motortreiber wird jeder Anschluss des Motors mit einem Ausgang des Operationsverstärker verbunden, die Eingänge des OPVs selbst als Komparator. Diese Methode ist für kleine und mittlere Motoren(=< 1A) und mäßige PWM-Frequenzen(<10kHz) gut geeignet. Ein RB35 von Conrad kann damit problemlos angesteuert werden. Bei zu hohen PWM-Frequenzen ist die SlewRate von vielen OPVs zu gering und die entsprechenden OPVs sind dann viel zu teuer und man sollte eine Ansteuerung per Mosfet(s.o.) bevorzugen. Momentan hat sich der TCA 0372 DP1 (57ct bei Reichelt) Verwendung gefunden. <br />
Weitere Informationen sind in folgendem Forumsbeitrag zu finden:<br />
http://www.roboternetz.de/phpBB2/viewtopic.php?t=38412<br />
===Gleichstromansteuerung===<br />
Eine weitere Möglichkeit ist es, dem Operationsverstärker eine Gleichspannung vorzugeben, mit denen der OPV die Motoren ansteuert. Diese Methode eignet sich sehr gut für analoge Schaltkreise. Der Wirkungsgrad ist allerdings nicht der beste, da die restliche Spannung in Wärme umgesetzt wird. Zudem werden viele weitere komponenten benötigt, dass den Aufbau treuerer und fehleranfälliger macht.<br />
Der entsprechenden Schaltkreis ist im Datenblatt des TCA 0372 DP1 zu finden.<br />
<br />
==Ansteuerung mit Treiber IC L293 D==<br />
<br />
Dies ist ohne Zweifel die am häufigsten genutzte Ansteuerung bei Roboter-Bastlern: Man nimmt einfach das IC L293D, denn darin sind sogar zwei H-Brücken enthalten. Also mit einem IC lassen sich ohne weiteres externe Bauteile gleich zwei Motoren ansteuern. Zwar nur bis ca. 600mA, aber das reicht oft schon für kleinere bis mittlere Roboteranwendungen aus.<br />
<br />
[[Bild:L293Pinout.JPG|center]]<br />
<br />
<br />
[[Bild:hbrueckel293d.gif|center]]<br />
<br />
Wie aus dem Schaltbild zu ersehen ist, werden für die Ansteuerung jedes Motors 3 Ports benötigt. Die Enable-Leitung führt man oft auf einen PWM-Port welcher wie bei der MOS-FET Schaltung oben die Geschwindigkeit regelt. Die beiden anderen Ports geben die Drehrichtung an. Immer wenn die Ports unterschiedliche Polarität haben dreht der Motor in eine bestimmte Richtung, je nachdem wo Low und High anliegt. Das Besondere ist, dass wenn an beiden Ports der gleiche Pegel anliegt, also zweimal Low oder High, dann wird nämlich der Motor kurzgeschlossen - das fungiert als Bremse. Das Bremsen kann bei Robotern durchaus nützlich sein. Zudem ist bei schnellen Richtungswechseln immer zu empfehlen zuerst kurz zu bremsen, um nicht den Motor oder Motortreiber zu stark zu belasten.<br />
<br />
==Ansteuerung mit dem Schaltkreis L298==<br />
<br />
Der Schaltkreis L298 ist quasi der große Bruder des L293D. Er beinhaltet auch zwei komplette H-Brücken, kann also auch zwei Motoren ansteuern. Die Pinbelegung ist ebenfalls dem L293D sehr ähnlich, jedoch verfügt er über eine andere Bauform:<br />
<br />
<br />
[[Bild:L298Pinout.JPG|center]]<br />
<br />
<br />
Der wichtigste Unterschied besteht jedoch darin, dass jede H-Brücke bei L298 bis zu 2A belastet werden kann. Damit lassen sich also schon wesentlich größere Motoren ansteuern. Ein weiterer Vorzug sind die sogenannten SENSE-Ausgänge, über die der komplette Strom fließt. Oft wird hier ein Hochlastwiderstand angeschlossen, um aus der abfallenden Spannung den genauen Strom berechnen zu können. Dies machen sich Steuerungen wie [http://www.roboternetz.de/phpBB2/viewtopic.php?t=2741 RN-Motor] oder aber andere Schrittmotoransteuerungen zunutze, um den Strom genau zu regeln. Benötigt man keine Strommessung, so müssen die Sense-Ausgänge immer direkt mit GND verbunden werden. In diesem Fall muss allerdings eine andere Strombegrenzung eingeplant werden. Wird keine Strombegrenzung eingebaut, müssen diese Widerstände trotztem eingebaut werden, da der Treiber sonst heiss wird.<br />
<br />
<br />
[[Bild:hbrueckel298.gif|center]]<br />
<br />
<br />
Ein weiteres Schaltbild gibt es hier [http://www.roboternetz.de/bilder/schaltung298getriebe.gif]<br />
<br />
==Ansteuerung mit L6205==<br />
Der Schaltkreis L6205 stellt eine etwas modernere Alternative zur L298 Ansteuerung dar. Die Ansteuerung ist praktisch identisch, der Schaltungsaufbau in etwa gleich. Beim L6205 sind keine Freilaufdioden mehr notwendig, dafür ist ein Kondensator und zwei Dioden für die interne Spannungserzeugung notwendig.<br />
Ein großer Vorteil ist auch das kein extra Kühlkörper mehr notwendig ist. Viele integrierte Schutzfunktionen im L6205 sorgen dafür das der Chip nicht so einfach zerstört werden kann. In der Praxis sind die angegeben 2,8A jedoch mit Vorsicht zu geniesen. Bei Testlayouts erwärmten sich die IC´s bereits bei 2A Dauerstrom (PWM) oft so stark das die automatische Temperaturabschaltung reagierte, somit wird man vermutlich ohne Kühlung oder großes Kühllayout auf er Platine auch nicht mehr als beim L298 erreichen. <br />
<br />
[[Bild:l6205ic.gif]] [[Bild:l6205pinbelegung.gif]]<br />
<br />
<br />
[[Bild:l6205.gif|center]]<br />
<br />
==Noch mehr Power gewünscht?==<br />
<br />
Obwohl der L298 schon einiges abdeckt, so kommt er spätestens bei den Scheibenwischermotoren langsam an seine Grenzen. Bei starker Belastung können solche Motoren kurzzeitig bis ca. 10 A und mehr ziehen. Für solch starke Motoren gibt es jetzt einen ganz interessanten Motorchip aus dem KFZ-Bereich: vnh3sp (Datenblatt im Roboternetz Download-Bereich). <br />
Mit ihm lassen sich sogar recht große Motoren ansteuern; vorausgesetzt, man kühlt ihn entsprechend, so verträgt der Chip bis zu 30A. Aber selbst ohne Kühlung bietet er bedeutet mehr Leistung als der L298. Das Schöne, die Ansteuerung ist kaum anders als beim L298 und L293D.<br />
<br />
Kleiner Nachteil: Da es ein SMD-Chip mit 1mm Kontaktabstand ist, muss man schon eine geeignete Platine (spezielles Layout mit Kühlflächen) und etwas Löterfahrung besitzen. Inzwischen gibt es aber schon verschiedene RN-Projekte mit dem Chip (RN-Power, RN-Mini H-Bridge), Platinen und Chip können über den [http://www.shop.robotikhardware.de/shop/catalog/index.php Robotikhardware.de-Platinenservice] bezogen werden. <br />
<br />
<br />
[[Bild:minihbridge_ansteuerung.gif|center]]<br />
<br />
<br />
Alternativ zum [[SMD]]-Chip VNH3SP30 gibt es noch die Alternative VNH2SP30. Dieser Chip erlaubt zwar nur Motorspannungen zwischen 6 und 16 Volt, jedoch hat er einen wesentlich geringeren Innenwiderstand und wird deshalb nur etwa halb so warm wie der VNH3SP30. <br />
Aus diesem Grund eignet er sich auch ideal für kleine Doppelmotorsteuerungen.<br />
Natürlich gibt's auch hierfür ein Projekt und eine Bauanleitung, siehe [[RN-VNH2Dualmotor]]<br />
<br />
Das Schöne ist, dass es dieses RN-Projekt jetzt auch auch als Fertigmodul gibt!<br />
<br />
<br />
[[Bild:rndualmotoransteuerung.jpeg|center]]<br />
<br />
==Endstufen mit I2C-Bus / RS232==<br />
[[Bild:motctrl.png|thumb|Motoransteuerung über RS232, I2C, RC]]Verwendet man eine der oben vorgestellten H-Bridges, so wird immer vorausgesetzt das ein PWM-Signal und mehrere Ports zur Ansteuerung bereitstehen. Ist dies nicht der Fall weil diese vielleicht schon belegt sind, so lassen sich Endstufen durch einen zusätzlichen Microcontroller auch um beliebige Schnittstellen erweitern. Insbesondere über I2C lassen sich dadurch mehrere Motorboards über einen einzigen Bus ansteuern. Ein Beispiel ist der programmierte Controller MOTCTRL, der speziell für diese Aufgabe gedacht ist. Die Grundscháltung sieht man in der rechten Skizze.<br />
<br />
==Und nie vergessen Motoren zu entstören==<br />
<br />
Das Entstören dient dazu, das sogenannte "Bürstenfeuer" zu verhindern, wodurch Störungen hervorgerufen werden könnten. Und so wirds gemacht:<br />
<br />
<br />
[[Bild:entstoerung.gif|center]]<br />
<br />
==Siehe auch==<br />
* [[Getriebemotoren]]<br />
* [[RN-VNH2Dualmotor]]<br />
<br />
==Weblinks==<br />
* [http://www.roboternetz.de/phpBB2/motordrehmoment.php Drehmoment Berechnung]<br />
* [http://www.roboternetz.de/motoruebersicht.html Motoren Übersicht]<br />
* [http://www.shop.robotikhardware.de/shop/catalog/index.php?cPath=65 Bauteilesets]<br />
* [http://www.roboternetz.de/robotertutorial.html Roboter-Tutorial]<br />
* [http://www.roboternetz.de Roboternetz Forum]<br />
<br />
[[Category:Robotikeinstieg]]<br />
[[Category:Praxis]]<br />
[[Category:Grundlagen]]<br />
[[Category:Motoren]]<br />
[[Category:Elektronik]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Avr-gcc_und_avrdude_installieren&diff=13120Avr-gcc und avrdude installieren2008-01-30T18:30:40Z<p>Overthere: </p>
<hr />
<div>Es gibt bereits eine sehr gute Anleitung für das Installieren vom [[avr-gcc]], aber sie ist etwas veraltet. Für den original Text siehe [http://www.tldp.org/linuxfocus/English/November2004/article352.shtml].<br />
Ich werde im folgenden nur das nötigste von diesem Artikel kopieren.<br />
<br />
Es gibt drei Teile. Im ersten Teil wird die Installation erklärt, im zweiten wird gezeigt, wie man damit denn nun seine Programme für den [[Microcontroller|MCU]] erstellt. Im dritten Teil stehen noch ein paar typische Fehlermeldungen und die Lösungen.<br />
<br />
=Installation=<br />
<br />
Also los. Wir brauchen folgende Software:<br />
<br />
* [ftp://ftp.gnu.org/gnu/binutils/ binutils-2.17.tar.bz2]<br />
* [ftp://ftp.gnu.org/gnu/gcc/gcc-4.1.2/ gcc-core-4.1.2.tar.bz2] <br />
* [http://savannah.nongnu.org/download/avr-libc/ avr-libc-1.4.5.tar.bz2] Dort findet ihr auch das Manual der avr-libc<br />
* [http://savannah.nongnu.org/download/avrdude/ avrdude-5.3.1.tar.gz] <br />
<br />
Als erstes erstellen wir das Verzeichnis, in das der avr-gcc installiert wird:<br />
<br />
* Als root:<br />
mkdir /usr/local/avr<br />
<br />
Und das Verzeichnis in dem die Programme liegen werden:<br />
<br />
* Als root:<br />
mkdir /usr/local/avr/bin<br />
<br />
Dieses Verzeichnis wird auch gleich in die <tt>PATH</tt>-Variable geschrieben:<br />
export PATH=$PATH:/usr/local/avr/bin<br />
<br />
Achtung, dieser Befehl ist nur in dieser eine Konsole in der ihr seid gültig und auch nur solange wie diese offen ist. Um die Änderung systemweit wirksam zu machen, müsst ihr in die Datei <tt>/etc/profile</tt> den <tt>PATH</tt> nachtragen. Bei mir sieht das z.B. so aus:<br />
<pre><br />
# Set the default system $PATH:<br />
PATH="/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games[b]:/usr/local/avr/bin[/b]"<br />
</pre><br />
<br />
==[[binutils]]==<br />
<br />
Mit den binutils bekommt ihr Programme wie z.b. <tt>avr-as</tt> (Assembler), <tt>avr-ld</tt> (Linker), <tt>avr-objcopy</tt> (Um die Intel-Hex-Files zu erstellen).<br />
<br />
Und so wird's gemacht (Das entpacken kann eine Weile dauern):<br />
<pre><br />
tar jxf binutils-2.17.tar.bz2<br />
cd binutils-2.17/<br />
mkdir obj-avr<br />
cd obj-avr<br />
../configure --target=avr --prefix=/usr/local/avr --disable-nls<br />
make<br />
</pre><br />
* Als root:<br />
make install<br />
<br />
==[[avr-gcc]]==<br />
<br />
avr-gcc ist unser eigentlicher Compiler. Er installiert sich wie folgt:<br />
<pre><br />
tar jxf gcc-core-4.1.2.tar.bz2<br />
cd gcc-4.1.2<br />
<br />
mkdir obj-avr<br />
cd obj-avr<br />
../configure --target=avr --prefix=/usr/local/avr --disable-nls --enable-languages=c --disable-libssp<br />
<br />
make<br />
</pre><br />
<br />
Hinweis: Falls ihr jetzt beim Installieren Fehler bekommt die sich z.B so äussern:<br />
make[2]: avr-ranlib: Command not found<br />
Dann liegt <tt>/usr/local/avr/bin</tt> wider erwarten nicht in <tt>PATH</tt>. Führt diesen Befehl als root nochmal aus, dann sollte es gehen:<br />
export PATH=$PATH:/usr/local/avr/bin<br />
<br />
* Als root:<br />
make install<br />
<br />
==avr C-library ([[avr-libc]])==<br />
<pre><br />
tar jxf avr-libc-1.4.5.tar.bz2<br />
cd avr-libc-1.4.5<br />
<br />
./configure --prefix=/usr/local/avr --build=`./config.guess` --host=avr<br />
<br />
make <br />
</pre><br />
* Als root:<br />
make install<br />
<br />
<br />
==[[avrdude]]==<br />
<br />
<pre><br />
tar xzf avrdude-5.3.1.tar.gz<br />
cd avrdude-5.3.1<br />
./configure --prefix=/usr/local/avr<br />
make<br />
</pre><br />
* Als root:<br />
make install<br />
<br />
Wer den avr910 Programmer benutzt, muss avrdude erst fit für einige neuere Controller machen.<br />
([[ATtiny2313]], [[ATmega162]], ...). Dazu müsst ihr die Configdatei von avrdude anpassen. Ihr findet sie unter <tt>/usr/local/avr/etc/avrdude.conf</tt><br />
<br />
Folgende Zeilen müssen ergänzt werden:<br />
<pre><br />
#------------------------------------------------------------<br />
# ATtiny2313<br />
#------------------------------------------------------------<br />
<br />
part<br />
id = "t2313";<br />
desc = "ATtiny2313";<br />
stk500_devcode = 0x23;<br />
## Try the STK500 devcode:<br />
[b]avr910_devcode = 0x23;[/b]<br />
.....<br />
<br />
#------------------------------------------------------------<br />
# ATmega8535<br />
#------------------------------------------------------------<br />
<br />
part<br />
id = "m8535";<br />
desc = "ATMEGA8535";<br />
stk500_devcode = 0x64;<br />
[b] avr910_devcode = 0x69;[/b]<br />
</pre><br />
Analog verfahren für [[ATmega64]], [[ATmega162]] und [[ATmega169]]. Die devicecodes hiefür sind:<br />
<pre><br />
m64: avr910_devcode = 0x45;<br />
m162: avr910_devcode = 0x62;<br />
m169: avr910_devcode = 0x78;<br />
</pre><br />
<br />
Wer sich einen eigenen avr910 Programmer bauen will, dem sei diese Seite ans Herz gelegt:<br />
[http://www.klaus-leidinger.de/mp/Mikrocontroller/AVR-Prog/AVR-Programmer.html].<br />
Ich habe die Version genommen und um ein Buffer erweitert. Die Bauanleitung dafür gibt es bald auf [http://www.amee-bot.de unserer Roboterseite]. <br />
<br />
Somit hätten wir nun alles was wir brauchen installiert.<br />
<br />
=Beispiel-Projekt=<br />
<br />
Hier erstmal ein winziges Beispielprogramm für den [[ATtiny2313]].<br />
<pre><br />
/*<br />
* blink.c<br />
* ATtiny2313 mit 1 MHz<br />
* PORTB wird ueber ein Timer alle 0.263s ein- und ausgeschaltet. Das entspricht 3.81Hz<br />
*/<br />
<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <avr/signal.h><br />
<br />
SIGNAL (SIG_TIMER0_OVF)<br />
{<br />
PORTB =~ PORTB; // PORTB inventieren<br />
}<br />
<br />
int main()<br />
{<br />
DDRB = 0xFF; // PORTB als Ausgang schalten<br />
PORTB = 0x00; // Alle Ausgaenge auf 0 schalten<br />
<br />
TCCR0B |= (1 << CS02) | (1 << CS00); //Prescaler auf 1024 stellen<br />
TIMSK |= (1 << TOIE0); // Timer 0 Overflow Interrupt enable<br />
<br />
sei(); // Interrupts einschalten<br />
<br />
for(;;); //ever<br />
}<br />
</pre><br />
Den Quelltext nehmt ihr und speichert ihn in die Datei <tt>blink.c</tt>.<br />
<br />
Jetzt kommt das [[make|Makefile]]. Ich habe schonmal ein einfaches vorbereitet:<br />
<pre><br />
TARGET = blink<br />
MCU = attiny2313<br />
CC = avr-gcc<br />
OBJCOPY=avr-objcopy<br />
CFLAGS =-g -mmcu=$(MCU) -Wall -Wstrict-prototypes -Os -mcall-prologues -save-temps -fno-common<br />
<br />
all: $(TARGET).hex<br />
<br />
$(TARGET).hex : $(TARGET).elf<br />
$(OBJCOPY) -j .data -j .text -O ihex $< $@<br />
<br />
$(TARGET).elf: $(TARGET).o<br />
$(CC) $(CFLAGS) -o $@ -Wl,-Map,$(TARGET).map $<<br />
<br />
$(TARGET).o : $(TARGET).c<br />
$(CC) $(CFLAGS) -c $<<br />
<br />
load: $(TARGET).hex<br />
avrdude -p t2313 -c avr910 -U flash:w:$(TARGET).hex -v<br />
<br />
clean:<br />
rm -f *.o *.map *.elf *.hex *.s *.i<br />
</pre><br />
Das speichert ihr in der Datei <tt>Makefile</tt> im selben Ordner, in der auch die Datei <tt>blink.c liegt</tt>. '''Unbedingt darauf achten, daß die Einrückungen durch TABs erfolgen und nicht durch Leerzeichen!'''<br />
<br />
Dann in der Konsole "<tt>[[make]]</tt>" tippen und es sollte compiliert werden. Mit "<tt>make load</tt>" wird das Hexfile dann in den MCU übertragen.<br />
<br />
'''Erklärung:'''<br />
<br />
;<tt>MCU=attiny2313</tt>: <tt>MCU</tt> ist eine Variable mit dem Inhalt <tt>attiny2313</tt>. Überall, wo jetzte <tt>$(MCU)</tt> steht, wird der Variabelninhalt benutzt. Genauso funktioniert das auch mit <tt>TARGET</tt>, <tt>CC</tt>, <tt>OBJCOPY</tt> und <tt>CFLAGS</tt>. <br />
<br />
Nachdem ihr <tt>make</tt> erfolgreich ausgeführt habt, liegen in dem Ordner die Hexfile und eine Datei mit der Endung<tt>&nbsp;.s</tt>. Darin sind die Assemblerbefehle und -direktiven, die der Compiler aus dem C-Code gemacht hat. Wer so etwas nicht braucht, der kann den Parameter <tt>-save-temps</tt> in der Variable <tt>CFLAGS</tt> getrost entfernen.<br />
<br />
Wenn ihr "<tt>make load</tt>" ausfürt, wird avrdude gestarte.<br />
;<tt>-p</tt>: gibt an, um welchen MCU es sich handelt<br />
;<tt>-c</tt>: gibt an, um welchen Programmer es sich handelt. Hier könnte z.B <tt>stk500</tt> stehen.<br />
;<tt><nowiki>-U flash:w:$(TARGET).hex</nowiki></tt>: bedeutet einfach, dass das Programm in den Flash geschrieben werden soll. <tt>w</tt> steht für Schreiben, <tt>r</tt> für Lesen und <tt>v</tt> für verify. Dann kommt die Variable <tt>$(TARGET)</tt>, die besagt, welche Datei genau übertragen werden soll. <br />
;<tt>-v</tt>: bedeutet ''"Verbose Output"'' und gibt euch mehr Informationen auf der Konsole aus.<br />
<br />
Mit <tt>make clean</tt> werden alle Object-Dateien etc. gelöscht.<br />
<br />
=Fehlermeldungen=<br />
<br />
sollten eigentlich keine vorkommen. Wenn doch, vergewissert euch, dass ihr euch genau an die<br />
Anleitung gehalten und nichts falsch abgeschrieben habt!<br />
<br />
Hier ein paar typische Fehlermeldungen und ihr Lösungen:<br />
<br />
;<tt>Permission denied</tt>: Ihr habt nicht die Rechte, um diesen Befehl auszuführen. Höchswahrscheinlich müsst ihr den Befehl als root ausführen.<br />
<br />
;<tt><nowiki>make[2]: avr-ranlib: Command not found</nowiki></tt>:<tt>/usr/local/avr/bin</tt> liegt nicht in <tt>$PATH</tt>. Folgendes Command ausführen:<br />
:<pre>export PATH=$PATH:/usr/local/avr/bin</pre><br />
<br />
;<tt>programmer is not responding</tt>: Es kann keine Verbindung zum Programmer aufgenommen werden: Defektes Kabel, Programmer an der falschen Schnittstelle angeschlossen (default: <tt>/dev/ttyS0</tt>), kein Strom am Programmer etc.<br />
<br />
;<tt><nowiki>can't open device "/dev/ttyS0": Permission denied</nowiki></tt>: Als normaler User darf man auf die serielle Schnittstelle nicht lesen oder schreiben. Folgenden Befehl als root ausführen:<br />
:<pre>chmod 666 /dev/ttyS0</pre><br />
:{|<br />
Zweite und bessere Möglichkeit, die Rechte zu ändern ist es, den Benutzer in die tty-Gruppe auzunehmen.<br />
Hier ein Beispiel für Gentoo.<br />
Die Gruppe kann bei anderen Distributionen auch anders heißen!<br />
<br />
Als root in die Konsole schreiben:<br />
<pre><br />
> ls -all /dev/ttyS0<br />
crw-rw---- 1 root tty 4, 64 25. Jun 02:12 /dev/ttyS0<br />
><br />
</pre><br />
Hier kann man schön erkennen, daß die serielle Schnittstelle dem Benutzer root gehört und die Gruppe <tt>tty</tt> darauf zugreifen darf. Mit einem einfachen<br />
> usermod -a -G tty sebastian<br />
wird der User <tt>sebastian</tt> in die tty-Gruppe aufgenommen.<br />
<br />
Noch ein Test, ob alles geklappt hat:<br />
<pre>> groups sebastian<br />
tty wheel audio cdrom dialout video games usb users portage scanner<br />
</pre><br />
Danach muss sich Benutzer <tt>sebastian</tt> neu einlogen und wir sind fertig.<br />
<br />
Der Vorteil hierbei ist, daß man Rechte für alle Geräte der Gruppe <tt>tty</tt> erlangt, also alle seriellen Schnittstellen sowie [[USB]]&nbsp;&harr;&nbsp;[[RS232]]-Adapter, und man braucht an den eigentlichen Rechten nichts zu verändern.<br />
|}<br />
<br />
=Web-Links=<br />
*[http://www.nongnu.org/avr-libc/user-manual/install_tools.html ''"Installing the GNU Tool Chain"''] Hilfe zum Build und Installation von GCC, binutils, etc unter Linux<br />
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml www.linuxfocus.org (Artikel)] - Tipps zu Build und Installation von avr-gcc, binutils und avr-libc unter Linux<br />
* [http://users.rcn.com/rneswold/avr/ Rich Neswold: ''A GNU Development Environment for the AVR Microcontroller'']<br />
* [http://www.mikrocontroller.net/topic/24166 www.mikrocontroller.net (Foren-Beitrag)] - Installation von GCC und Toolchain unter Mac OS X<br />
<br />
=Pakete=<br />
==Slackware==<br />
Ein Paket für Slackware ist für Zenwalk erhältlich. Mehr dazu siehe hier:<br />
http://support.zenwalk.org/index.php?topic=14131.<br />
=Siehe auch=<br />
* [[avr-gcc]]<br />
* [[WinAVR]]<br />
<br />
=Quelle=<br />
* [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=125603#125603 www.roboternetz.de (Foren-Beitrag)] ''avrgcc + avrdude installieren''<br />
<br />
=Autoren=<br />
*[[Benutzer:Kater|Kater]] (Manuscript)<br />
*[[Benutzer:SprinterSB|SprinterSB]] (Transcript und Typo)<br />
<br />
[[Kategorie:Grundlagen]]<br />
[[Kategorie:Microcontroller]]<br />
[[Kategorie:Quellcode C]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Avr-gcc_und_avrdude_installieren&diff=13119Avr-gcc und avrdude installieren2008-01-30T18:29:45Z<p>Overthere: </p>
<hr />
<div>Es gibt bereits eine sehr gute Anleitung für das Installieren vom [[avr-gcc]], aber sie ist etwas veraltet. Für den original Text siehe [http://www.tldp.org/linuxfocus/English/November2004/article352.shtml].<br />
Ich werde im folgenden nur das nötigste von diesem Artikel kopieren.<br />
<br />
Es gibt drei Teile. Im ersten Teil wird die Installation erklärt, im zweiten wird gezeigt, wie man damit denn nun seine Programme für den [[Microcontroller|MCU]] erstellt. Im dritten Teil stehen noch ein paar typische Fehlermeldungen und die Lösungen.<br />
<br />
=Installation=<br />
<br />
Also los. Wir brauchen folgende Software:<br />
<br />
* [ftp://ftp.gnu.org/gnu/binutils/ binutils-2.17.tar.bz2]<br />
* [ftp://ftp.gnu.org/gnu/gcc/gcc-4.1.2/ gcc-core-4.1.2.tar.bz2] <br />
* [http://savannah.nongnu.org/download/avr-libc/ avr-libc-1.4.5.tar.bz2] Dort findet ihr auch das Manual der avr-libc<br />
* [http://savannah.nongnu.org/download/avrdude/ avrdude-5.3.1.tar.gz] <br />
<br />
Als erstes erstellen wir das Verzeichnis, in das der avr-gcc installiert wird:<br />
<br />
* Als root:<br />
mkdir /usr/local/avr<br />
<br />
Und das Verzeichnis in dem die Programme liegen werden:<br />
<br />
* Als root:<br />
mkdir /usr/local/avr/bin<br />
<br />
Dieses Verzeichnis wird auch gleich in die <tt>PATH</tt>-Variable geschrieben:<br />
export PATH=$PATH:/usr/local/avr/bin<br />
<br />
Achtung, dieser Befehl ist nur in dieser eine Konsole in der ihr seid gültig und auch nur solange wie diese offen ist. Um die Änderung systemweit wirksam zu machen, müsst ihr in die Datei <tt>/etc/profile</tt> den <tt>PATH</tt> nachtragen. Bei mir sieht das z.B. so aus:<br />
<pre><br />
# Set the default system $PATH:<br />
PATH="/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games[b]:/usr/local/avr/bin[/b]"<br />
</pre><br />
<br />
==[[binutils]]==<br />
<br />
Mit den binutils bekommt ihr Programme wie z.b. <tt>avr-as</tt> (Assembler), <tt>avr-ld</tt> (Linker), <tt>avr-objcopy</tt> (Um die Intel-Hex-Files zu erstellen).<br />
<br />
Und so wird's gemacht (Das entpacken kann eine Weile dauern):<br />
<pre><br />
tar jxf binutils-2.17.tar.bz2<br />
cd binutils-2.17/<br />
mkdir obj-avr<br />
cd obj-avr<br />
../configure --target=avr --prefix=/usr/local/avr --disable-nls<br />
make<br />
</pre><br />
* Als root:<br />
make install<br />
<br />
==[[avr-gcc]]==<br />
<br />
avr-gcc ist unser eigentlicher Compiler. Er installiert sich wie folgt:<br />
<pre><br />
tar jxf gcc-core-4.1.2.tar.bz2<br />
cd gcc-4.1.2<br />
<br />
mkdir obj-avr<br />
cd obj-avr<br />
../configure --target=avr --prefix=/usr/local/avr --disable-nls --enable-languages=c --disable-libssp<br />
<br />
make<br />
</pre><br />
<br />
Hinweis: Falls ihr jetzt beim Installieren Fehler bekommt die sich z.B so äussern:<br />
make[2]: avr-ranlib: Command not found<br />
Dann liegt <tt>/usr/local/avr/bin</tt> wider erwarten nicht in <tt>PATH</tt>. Führt diesen Befehl als root nochmal aus, dann sollte es gehen:<br />
export PATH=$PATH:/usr/local/avr/bin<br />
<br />
* Als root:<br />
make install<br />
<br />
==avr C-library ([[avr-libc]])==<br />
<pre><br />
tar jxf avr-libc-1.4.5.tar.bz2<br />
cd avr-libc-1.4.5<br />
<br />
./configure --prefix=/usr/local/avr --build=`./config.guess` --host=avr<br />
<br />
make <br />
</pre><br />
* Als root:<br />
make install<br />
<br />
<br />
==[[avrdude]]==<br />
<br />
<pre><br />
tar xzf avrdude-5.3.1.tar.gz<br />
cd avrdude-5.3.1<br />
./configure --prefix=/usr/local/avr<br />
make<br />
</pre><br />
* Als root:<br />
make install<br />
<br />
Wer den avr910 Programmer benutzt, muss avrdude erst fit für einige neuere Controller machen.<br />
([[ATtiny2313]], [[ATmega162]], ...). Dazu müsst ihr die Configdatei von avrdude anpassen. Ihr findet sie unter <tt>/usr/local/avr/etc/avrdude.conf</tt><br />
<br />
Folgende Zeilen müssen ergänzt werden:<br />
<pre><br />
#------------------------------------------------------------<br />
# ATtiny2313<br />
#------------------------------------------------------------<br />
<br />
part<br />
id = "t2313";<br />
desc = "ATtiny2313";<br />
stk500_devcode = 0x23;<br />
## Try the STK500 devcode:<br />
[b]avr910_devcode = 0x23;[/b]<br />
.....<br />
<br />
#------------------------------------------------------------<br />
# ATmega8535<br />
#------------------------------------------------------------<br />
<br />
part<br />
id = "m8535";<br />
desc = "ATMEGA8535";<br />
stk500_devcode = 0x64;<br />
[b] avr910_devcode = 0x69;[/b]<br />
</pre><br />
Analog verfahren für [[ATmega64]], [[ATmega162]] und [[ATmega169]]. Die devicecodes hiefür sind:<br />
<pre><br />
m64: avr910_devcode = 0x45;<br />
m162: avr910_devcode = 0x62;<br />
m169: avr910_devcode = 0x78;<br />
</pre><br />
<br />
Wer sich einen eigenen avr910 Programmer bauen will, dem sei diese Seite ans Herz gelegt:<br />
[http://www.klaus-leidinger.de/mp/Mikrocontroller/AVR-Prog/AVR-Programmer.html].<br />
Ich habe die Version genommen und um ein Buffer erweitert. Die Bauanleitung dafür gibt es bald auf [http://www.amee-bot.de unserer Roboterseite]. <br />
<br />
Somit hätten wir nun alles was wir brauchen installiert.<br />
<br />
=Beispiel-Projekt=<br />
<br />
Hier erstmal ein winziges Beispielprogramm für den [[ATtiny2313]].<br />
<pre><br />
/*<br />
* blink.c<br />
* ATtiny2313 mit 1 MHz<br />
* PORTB wird ueber ein Timer alle 0.263s ein- und ausgeschaltet. Das entspricht 3.81Hz<br />
*/<br />
<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <avr/signal.h><br />
<br />
SIGNAL (SIG_TIMER0_OVF)<br />
{<br />
PORTB =~ PORTB; // PORTB inventieren<br />
}<br />
<br />
int main()<br />
{<br />
DDRB = 0xFF; // PORTB als Ausgang schalten<br />
PORTB = 0x00; // Alle Ausgaenge auf 0 schalten<br />
<br />
TCCR0B |= (1 << CS02) | (1 << CS00); //Prescaler auf 1024 stellen<br />
TIMSK |= (1 << TOIE0); // Timer 0 Overflow Interrupt enable<br />
<br />
sei(); // Interrupts einschalten<br />
<br />
for(;;); //ever<br />
}<br />
</pre><br />
Den Quelltext nehmt ihr und speichert ihn in die Datei <tt>blink.c</tt>.<br />
<br />
Jetzt kommt das [[make|Makefile]]. Ich habe schonmal ein einfaches vorbereitet:<br />
<pre><br />
TARGET = blink<br />
MCU = attiny2313<br />
CC = avr-gcc<br />
OBJCOPY=avr-objcopy<br />
CFLAGS =-g -mmcu=$(MCU) -Wall -Wstrict-prototypes -Os -mcall-prologues -save-temps -fno-common<br />
<br />
all: $(TARGET).hex<br />
<br />
$(TARGET).hex : $(TARGET).elf<br />
$(OBJCOPY) -j .data -j .text -O ihex $< $@<br />
<br />
$(TARGET).elf: $(TARGET).o<br />
$(CC) $(CFLAGS) -o $@ -Wl,-Map,$(TARGET).map $<<br />
<br />
$(TARGET).o : $(TARGET).c<br />
$(CC) $(CFLAGS) -c $<<br />
<br />
load: $(TARGET).hex<br />
avrdude -p t2313 -c avr910 -U flash:w:$(TARGET).hex -v<br />
<br />
clean:<br />
rm -f *.o *.map *.elf *.hex *.s *.i<br />
</pre><br />
Das speichert ihr in der Datei <tt>Makefile</tt> im selben Ordner, in der auch die Datei <tt>blink.c liegt</tt>. '''Unbedingt darauf achten, daß die Einrückungen durch TABs erfolgen und nicht durch Leerzeichen!'''<br />
<br />
Dann in der Konsole "<tt>[[make]]</tt>" tippen und es sollte compiliert werden. Mit "<tt>make load</tt>" wird das Hexfile dann in den MCU übertragen.<br />
<br />
'''Erklärung:'''<br />
<br />
;<tt>MCU=attiny2313</tt>: <tt>MCU</tt> ist eine Variable mit dem Inhalt <tt>attiny2313</tt>. Überall, wo jetzte <tt>$(MCU)</tt> steht, wird der Variabelninhalt benutzt. Genauso funktioniert das auch mit <tt>TARGET</tt>, <tt>CC</tt>, <tt>OBJCOPY</tt> und <tt>CFLAGS</tt>. <br />
<br />
Nachdem ihr <tt>make</tt> erfolgreich ausgeführt habt, liegen in dem Ordner die Hexfile und eine Datei mit der Endung<tt>&nbsp;.s</tt>. Darin sind die Assemblerbefehle und -direktiven, die der Compiler aus dem C-Code gemacht hat. Wer so etwas nicht braucht, der kann den Parameter <tt>-save-temps</tt> in der Variable <tt>CFLAGS</tt> getrost entfernen.<br />
<br />
Wenn ihr "<tt>make load</tt>" ausfürt, wird avrdude gestarte.<br />
;<tt>-p</tt>: gibt an, um welchen MCU es sich handelt<br />
;<tt>-c</tt>: gibt an, um welchen Programmer es sich handelt. Hier könnte z.B <tt>stk500</tt> stehen.<br />
;<tt><nowiki>-U flash:w:$(TARGET).hex</nowiki></tt>: bedeutet einfach, dass das Programm in den Flash geschrieben werden soll. <tt>w</tt> steht für Schreiben, <tt>r</tt> für Lesen und <tt>v</tt> für verify. Dann kommt die Variable <tt>$(TARGET)</tt>, die besagt, welche Datei genau übertragen werden soll. <br />
;<tt>-v</tt>: bedeutet ''"Verbose Output"'' und gibt euch mehr Informationen auf der Konsole aus.<br />
<br />
Mit <tt>make clean</tt> werden alle Object-Dateien etc. gelöscht.<br />
<br />
=Fehlermeldungen=<br />
<br />
sollten eigentlich keine vorkommen. Wenn doch, vergewissert euch, dass ihr euch genau an die<br />
Anleitung gehalten und nichts falsch abgeschrieben habt!<br />
<br />
Hier ein paar typische Fehlermeldungen und ihr Lösungen:<br />
<br />
;<tt>Permission denied</tt>: Ihr habt nicht die Rechte, um diesen Befehl auszuführen. Höchswahrscheinlich müsst ihr den Befehl als root ausführen.<br />
<br />
;<tt><nowiki>make[2]: avr-ranlib: Command not found</nowiki></tt>:<tt>/usr/local/avr/bin</tt> liegt nicht in <tt>$PATH</tt>. Folgendes Command ausführen:<br />
:<pre>export PATH=$PATH:/usr/local/avr/bin</pre><br />
<br />
;<tt>programmer is not responding</tt>: Es kann keine Verbindung zum Programmer aufgenommen werden: Defektes Kabel, Programmer an der falschen Schnittstelle angeschlossen (default: <tt>/dev/ttyS0</tt>), kein Strom am Programmer etc.<br />
<br />
;<tt><nowiki>can't open device "/dev/ttyS0": Permission denied</nowiki></tt>: Als normaler User darf man auf die serielle Schnittstelle nicht lesen oder schreiben. Folgenden Befehl als root ausführen:<br />
:<pre>chmod 666 /dev/ttyS0</pre><br />
:{|<br />
Zweite und bessere Möglichkeit, die Rechte zu ändern ist es, den Benutzer in die tty-Gruppe auzunehmen.<br />
Hier ein Beispiel für Gentoo.<br />
Die Gruppe kann bei anderen Distributionen auch anders heißen!<br />
<br />
Als root in die Konsole schreiben:<br />
<pre><br />
> ls -all /dev/ttyS0<br />
crw-rw---- 1 root tty 4, 64 25. Jun 02:12 /dev/ttyS0<br />
><br />
</pre><br />
Hier kann man schön erkennen, daß die serielle Schnittstelle dem Benutzer root gehört und die Gruppe <tt>tty</tt> darauf zugreifen darf. Mit einem einfachen<br />
> usermod -a -G tty sebastian<br />
wird der User <tt>sebastian</tt> in die tty-Gruppe aufgenommen.<br />
<br />
Noch ein Test, ob alles geklappt hat:<br />
<pre>> groups sebastian<br />
tty wheel audio cdrom dialout video games usb users portage scanner<br />
</pre><br />
Danach muss sich Benutzer <tt>sebastian</tt> neu einlogen und wir sind fertig.<br />
<br />
Der Vorteil hierbei ist, daß man Rechte für alle Geräte der Gruppe <tt>tty</tt> erlangt, also alle seriellen Schnittstellen sowie [[USB]]&nbsp;&harr;&nbsp;[[RS232]]-Adapter, und man braucht an den eigentlichen Rechten nichts zu verändern.<br />
|}<br />
<br />
=Web-Links=<br />
*[http://www.nongnu.org/avr-libc/user-manual/install_tools.html ''"Installing the GNU Tool Chain"''] Hilfe zum Build und Installation von GCC, binutils, etc unter Linux<br />
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml www.linuxfocus.org (Artikel)] - Tipps zu Build und Installation von avr-gcc, binutils und avr-libc unter Linux<br />
* [http://users.rcn.com/rneswold/avr/ Rich Neswold: ''A GNU Development Environment for the AVR Microcontroller'']<br />
* [http://www.mikrocontroller.net/topic/24166 www.mikrocontroller.net (Foren-Beitrag)] - Installation von GCC und Toolchain unter Mac OS X<br />
<br />
=Pakete=<br />
==Slackware==<br />
Ein Paket für Slackware ist für Zenwalk erhältlich. Mehr dazu siehe hier:<br />
http://support.zenwalk.org/index.php?topic=14131.[http://support.zenwalk.org/index.php?topic=14131]<br />
<br />
=Siehe auch=<br />
* [[avr-gcc]]<br />
* [[WinAVR]]<br />
<br />
=Quelle=<br />
* [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=125603#125603 www.roboternetz.de (Foren-Beitrag)] ''avrgcc + avrdude installieren''<br />
<br />
=Autoren=<br />
*[[Benutzer:Kater|Kater]] (Manuscript)<br />
*[[Benutzer:SprinterSB|SprinterSB]] (Transcript und Typo)<br />
<br />
[[Kategorie:Grundlagen]]<br />
[[Kategorie:Microcontroller]]<br />
[[Kategorie:Quellcode C]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Avr-gcc_und_avrdude_installieren&diff=13118Avr-gcc und avrdude installieren2008-01-30T18:28:42Z<p>Overthere: Pakete hinzugefügt</p>
<hr />
<div>Es gibt bereits eine sehr gute Anleitung für das Installieren vom [[avr-gcc]], aber sie ist etwas veraltet. Für den original Text siehe [http://www.tldp.org/linuxfocus/English/November2004/article352.shtml].<br />
Ich werde im folgenden nur das nötigste von diesem Artikel kopieren.<br />
<br />
Es gibt drei Teile. Im ersten Teil wird die Installation erklärt, im zweiten wird gezeigt, wie man damit denn nun seine Programme für den [[Microcontroller|MCU]] erstellt. Im dritten Teil stehen noch ein paar typische Fehlermeldungen und die Lösungen.<br />
<br />
=Installation=<br />
<br />
Also los. Wir brauchen folgende Software:<br />
<br />
* [ftp://ftp.gnu.org/gnu/binutils/ binutils-2.17.tar.bz2]<br />
* [ftp://ftp.gnu.org/gnu/gcc/gcc-4.1.2/ gcc-core-4.1.2.tar.bz2] <br />
* [http://savannah.nongnu.org/download/avr-libc/ avr-libc-1.4.5.tar.bz2] Dort findet ihr auch das Manual der avr-libc<br />
* [http://savannah.nongnu.org/download/avrdude/ avrdude-5.3.1.tar.gz] <br />
<br />
Als erstes erstellen wir das Verzeichnis, in das der avr-gcc installiert wird:<br />
<br />
* Als root:<br />
mkdir /usr/local/avr<br />
<br />
Und das Verzeichnis in dem die Programme liegen werden:<br />
<br />
* Als root:<br />
mkdir /usr/local/avr/bin<br />
<br />
Dieses Verzeichnis wird auch gleich in die <tt>PATH</tt>-Variable geschrieben:<br />
export PATH=$PATH:/usr/local/avr/bin<br />
<br />
Achtung, dieser Befehl ist nur in dieser eine Konsole in der ihr seid gültig und auch nur solange wie diese offen ist. Um die Änderung systemweit wirksam zu machen, müsst ihr in die Datei <tt>/etc/profile</tt> den <tt>PATH</tt> nachtragen. Bei mir sieht das z.B. so aus:<br />
<pre><br />
# Set the default system $PATH:<br />
PATH="/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games[b]:/usr/local/avr/bin[/b]"<br />
</pre><br />
<br />
==[[binutils]]==<br />
<br />
Mit den binutils bekommt ihr Programme wie z.b. <tt>avr-as</tt> (Assembler), <tt>avr-ld</tt> (Linker), <tt>avr-objcopy</tt> (Um die Intel-Hex-Files zu erstellen).<br />
<br />
Und so wird's gemacht (Das entpacken kann eine Weile dauern):<br />
<pre><br />
tar jxf binutils-2.17.tar.bz2<br />
cd binutils-2.17/<br />
mkdir obj-avr<br />
cd obj-avr<br />
../configure --target=avr --prefix=/usr/local/avr --disable-nls<br />
make<br />
</pre><br />
* Als root:<br />
make install<br />
<br />
==[[avr-gcc]]==<br />
<br />
avr-gcc ist unser eigentlicher Compiler. Er installiert sich wie folgt:<br />
<pre><br />
tar jxf gcc-core-4.1.2.tar.bz2<br />
cd gcc-4.1.2<br />
<br />
mkdir obj-avr<br />
cd obj-avr<br />
../configure --target=avr --prefix=/usr/local/avr --disable-nls --enable-languages=c --disable-libssp<br />
<br />
make<br />
</pre><br />
<br />
Hinweis: Falls ihr jetzt beim Installieren Fehler bekommt die sich z.B so äussern:<br />
make[2]: avr-ranlib: Command not found<br />
Dann liegt <tt>/usr/local/avr/bin</tt> wider erwarten nicht in <tt>PATH</tt>. Führt diesen Befehl als root nochmal aus, dann sollte es gehen:<br />
export PATH=$PATH:/usr/local/avr/bin<br />
<br />
* Als root:<br />
make install<br />
<br />
==avr C-library ([[avr-libc]])==<br />
<pre><br />
tar jxf avr-libc-1.4.5.tar.bz2<br />
cd avr-libc-1.4.5<br />
<br />
./configure --prefix=/usr/local/avr --build=`./config.guess` --host=avr<br />
<br />
make <br />
</pre><br />
* Als root:<br />
make install<br />
<br />
<br />
==[[avrdude]]==<br />
<br />
<pre><br />
tar xzf avrdude-5.3.1.tar.gz<br />
cd avrdude-5.3.1<br />
./configure --prefix=/usr/local/avr<br />
make<br />
</pre><br />
* Als root:<br />
make install<br />
<br />
Wer den avr910 Programmer benutzt, muss avrdude erst fit für einige neuere Controller machen.<br />
([[ATtiny2313]], [[ATmega162]], ...). Dazu müsst ihr die Configdatei von avrdude anpassen. Ihr findet sie unter <tt>/usr/local/avr/etc/avrdude.conf</tt><br />
<br />
Folgende Zeilen müssen ergänzt werden:<br />
<pre><br />
#------------------------------------------------------------<br />
# ATtiny2313<br />
#------------------------------------------------------------<br />
<br />
part<br />
id = "t2313";<br />
desc = "ATtiny2313";<br />
stk500_devcode = 0x23;<br />
## Try the STK500 devcode:<br />
[b]avr910_devcode = 0x23;[/b]<br />
.....<br />
<br />
#------------------------------------------------------------<br />
# ATmega8535<br />
#------------------------------------------------------------<br />
<br />
part<br />
id = "m8535";<br />
desc = "ATMEGA8535";<br />
stk500_devcode = 0x64;<br />
[b] avr910_devcode = 0x69;[/b]<br />
</pre><br />
Analog verfahren für [[ATmega64]], [[ATmega162]] und [[ATmega169]]. Die devicecodes hiefür sind:<br />
<pre><br />
m64: avr910_devcode = 0x45;<br />
m162: avr910_devcode = 0x62;<br />
m169: avr910_devcode = 0x78;<br />
</pre><br />
<br />
Wer sich einen eigenen avr910 Programmer bauen will, dem sei diese Seite ans Herz gelegt:<br />
[http://www.klaus-leidinger.de/mp/Mikrocontroller/AVR-Prog/AVR-Programmer.html].<br />
Ich habe die Version genommen und um ein Buffer erweitert. Die Bauanleitung dafür gibt es bald auf [http://www.amee-bot.de unserer Roboterseite]. <br />
<br />
Somit hätten wir nun alles was wir brauchen installiert.<br />
<br />
=Beispiel-Projekt=<br />
<br />
Hier erstmal ein winziges Beispielprogramm für den [[ATtiny2313]].<br />
<pre><br />
/*<br />
* blink.c<br />
* ATtiny2313 mit 1 MHz<br />
* PORTB wird ueber ein Timer alle 0.263s ein- und ausgeschaltet. Das entspricht 3.81Hz<br />
*/<br />
<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <avr/signal.h><br />
<br />
SIGNAL (SIG_TIMER0_OVF)<br />
{<br />
PORTB =~ PORTB; // PORTB inventieren<br />
}<br />
<br />
int main()<br />
{<br />
DDRB = 0xFF; // PORTB als Ausgang schalten<br />
PORTB = 0x00; // Alle Ausgaenge auf 0 schalten<br />
<br />
TCCR0B |= (1 << CS02) | (1 << CS00); //Prescaler auf 1024 stellen<br />
TIMSK |= (1 << TOIE0); // Timer 0 Overflow Interrupt enable<br />
<br />
sei(); // Interrupts einschalten<br />
<br />
for(;;); //ever<br />
}<br />
</pre><br />
Den Quelltext nehmt ihr und speichert ihn in die Datei <tt>blink.c</tt>.<br />
<br />
Jetzt kommt das [[make|Makefile]]. Ich habe schonmal ein einfaches vorbereitet:<br />
<pre><br />
TARGET = blink<br />
MCU = attiny2313<br />
CC = avr-gcc<br />
OBJCOPY=avr-objcopy<br />
CFLAGS =-g -mmcu=$(MCU) -Wall -Wstrict-prototypes -Os -mcall-prologues -save-temps -fno-common<br />
<br />
all: $(TARGET).hex<br />
<br />
$(TARGET).hex : $(TARGET).elf<br />
$(OBJCOPY) -j .data -j .text -O ihex $< $@<br />
<br />
$(TARGET).elf: $(TARGET).o<br />
$(CC) $(CFLAGS) -o $@ -Wl,-Map,$(TARGET).map $<<br />
<br />
$(TARGET).o : $(TARGET).c<br />
$(CC) $(CFLAGS) -c $<<br />
<br />
load: $(TARGET).hex<br />
avrdude -p t2313 -c avr910 -U flash:w:$(TARGET).hex -v<br />
<br />
clean:<br />
rm -f *.o *.map *.elf *.hex *.s *.i<br />
</pre><br />
Das speichert ihr in der Datei <tt>Makefile</tt> im selben Ordner, in der auch die Datei <tt>blink.c liegt</tt>. '''Unbedingt darauf achten, daß die Einrückungen durch TABs erfolgen und nicht durch Leerzeichen!'''<br />
<br />
Dann in der Konsole "<tt>[[make]]</tt>" tippen und es sollte compiliert werden. Mit "<tt>make load</tt>" wird das Hexfile dann in den MCU übertragen.<br />
<br />
'''Erklärung:'''<br />
<br />
;<tt>MCU=attiny2313</tt>: <tt>MCU</tt> ist eine Variable mit dem Inhalt <tt>attiny2313</tt>. Überall, wo jetzte <tt>$(MCU)</tt> steht, wird der Variabelninhalt benutzt. Genauso funktioniert das auch mit <tt>TARGET</tt>, <tt>CC</tt>, <tt>OBJCOPY</tt> und <tt>CFLAGS</tt>. <br />
<br />
Nachdem ihr <tt>make</tt> erfolgreich ausgeführt habt, liegen in dem Ordner die Hexfile und eine Datei mit der Endung<tt>&nbsp;.s</tt>. Darin sind die Assemblerbefehle und -direktiven, die der Compiler aus dem C-Code gemacht hat. Wer so etwas nicht braucht, der kann den Parameter <tt>-save-temps</tt> in der Variable <tt>CFLAGS</tt> getrost entfernen.<br />
<br />
Wenn ihr "<tt>make load</tt>" ausfürt, wird avrdude gestarte.<br />
;<tt>-p</tt>: gibt an, um welchen MCU es sich handelt<br />
;<tt>-c</tt>: gibt an, um welchen Programmer es sich handelt. Hier könnte z.B <tt>stk500</tt> stehen.<br />
;<tt><nowiki>-U flash:w:$(TARGET).hex</nowiki></tt>: bedeutet einfach, dass das Programm in den Flash geschrieben werden soll. <tt>w</tt> steht für Schreiben, <tt>r</tt> für Lesen und <tt>v</tt> für verify. Dann kommt die Variable <tt>$(TARGET)</tt>, die besagt, welche Datei genau übertragen werden soll. <br />
;<tt>-v</tt>: bedeutet ''"Verbose Output"'' und gibt euch mehr Informationen auf der Konsole aus.<br />
<br />
Mit <tt>make clean</tt> werden alle Object-Dateien etc. gelöscht.<br />
<br />
=Fehlermeldungen=<br />
<br />
sollten eigentlich keine vorkommen. Wenn doch, vergewissert euch, dass ihr euch genau an die<br />
Anleitung gehalten und nichts falsch abgeschrieben habt!<br />
<br />
Hier ein paar typische Fehlermeldungen und ihr Lösungen:<br />
<br />
;<tt>Permission denied</tt>: Ihr habt nicht die Rechte, um diesen Befehl auszuführen. Höchswahrscheinlich müsst ihr den Befehl als root ausführen.<br />
<br />
;<tt><nowiki>make[2]: avr-ranlib: Command not found</nowiki></tt>:<tt>/usr/local/avr/bin</tt> liegt nicht in <tt>$PATH</tt>. Folgendes Command ausführen:<br />
:<pre>export PATH=$PATH:/usr/local/avr/bin</pre><br />
<br />
;<tt>programmer is not responding</tt>: Es kann keine Verbindung zum Programmer aufgenommen werden: Defektes Kabel, Programmer an der falschen Schnittstelle angeschlossen (default: <tt>/dev/ttyS0</tt>), kein Strom am Programmer etc.<br />
<br />
;<tt><nowiki>can't open device "/dev/ttyS0": Permission denied</nowiki></tt>: Als normaler User darf man auf die serielle Schnittstelle nicht lesen oder schreiben. Folgenden Befehl als root ausführen:<br />
:<pre>chmod 666 /dev/ttyS0</pre><br />
:{|<br />
Zweite und bessere Möglichkeit, die Rechte zu ändern ist es, den Benutzer in die tty-Gruppe auzunehmen.<br />
Hier ein Beispiel für Gentoo.<br />
Die Gruppe kann bei anderen Distributionen auch anders heißen!<br />
<br />
Als root in die Konsole schreiben:<br />
<pre><br />
> ls -all /dev/ttyS0<br />
crw-rw---- 1 root tty 4, 64 25. Jun 02:12 /dev/ttyS0<br />
><br />
</pre><br />
Hier kann man schön erkennen, daß die serielle Schnittstelle dem Benutzer root gehört und die Gruppe <tt>tty</tt> darauf zugreifen darf. Mit einem einfachen<br />
> usermod -a -G tty sebastian<br />
wird der User <tt>sebastian</tt> in die tty-Gruppe aufgenommen.<br />
<br />
Noch ein Test, ob alles geklappt hat:<br />
<pre>> groups sebastian<br />
tty wheel audio cdrom dialout video games usb users portage scanner<br />
</pre><br />
Danach muss sich Benutzer <tt>sebastian</tt> neu einlogen und wir sind fertig.<br />
<br />
Der Vorteil hierbei ist, daß man Rechte für alle Geräte der Gruppe <tt>tty</tt> erlangt, also alle seriellen Schnittstellen sowie [[USB]]&nbsp;&harr;&nbsp;[[RS232]]-Adapter, und man braucht an den eigentlichen Rechten nichts zu verändern.<br />
|}<br />
<br />
=Web-Links=<br />
*[http://www.nongnu.org/avr-libc/user-manual/install_tools.html ''"Installing the GNU Tool Chain"''] Hilfe zum Build und Installation von GCC, binutils, etc unter Linux<br />
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml www.linuxfocus.org (Artikel)] - Tipps zu Build und Installation von avr-gcc, binutils und avr-libc unter Linux<br />
* [http://users.rcn.com/rneswold/avr/ Rich Neswold: ''A GNU Development Environment for the AVR Microcontroller'']<br />
* [http://www.mikrocontroller.net/topic/24166 www.mikrocontroller.net (Foren-Beitrag)] - Installation von GCC und Toolchain unter Mac OS X<br />
<br />
=Pakete=<br />
==Slackware==<br />
Ein Paket für Slackware ist für Zenwalk erhältlich. Mehr dazu siehe hier:<br />
http://support.zenwalk.org/index.php?topic=14131.[http://support.zenwalk.org/index.php?topic=14131 http://support.zenwalk.org/index.php?topic=14131]<br />
<br />
=Siehe auch=<br />
* [[avr-gcc]]<br />
* [[WinAVR]]<br />
<br />
=Quelle=<br />
* [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=125603#125603 www.roboternetz.de (Foren-Beitrag)] ''avrgcc + avrdude installieren''<br />
<br />
=Autoren=<br />
*[[Benutzer:Kater|Kater]] (Manuscript)<br />
*[[Benutzer:SprinterSB|SprinterSB]] (Transcript und Typo)<br />
<br />
[[Kategorie:Grundlagen]]<br />
[[Kategorie:Microcontroller]]<br />
[[Kategorie:Quellcode C]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=12487Linuxdistribution Avr-live-cd DISCONTINUED2007-07-26T07:48:29Z<p>Overthere: </p>
<hr />
<div>Die Avr-live-CD hat die Zielsetzung, ein komfortables und kostenloses Betriebsystem bereitstellen, das <br />
möglichst viele Funktionen für das Programmieren von [[AVR]]s zur Verfügung stellt. <br />
[[Bild:Avrlivecd_screen1.png|thumb|Desktop]]<br />
== Grundlagen ==<br />
[[Bild:Avrlivecd_screen2.png|thumb|Kontrollerlab]]<br />
Die Avr-live-CD basiert auf Slax. Slax basiert auf der Linuxdistribution Slackware und hieß Ursprünglich "Linux Live CD". <br />
Für das Compilieren des Quelltextes wird [[avr-gcc]] verwendet. Der Binärcode in Hex-Form wird mittels avrdude auf den AVR geladen. Kontrollerlab wird als Interface und Programmierumgebung genutzt. <br />
<br />
Diese CD bietet dem Nutzer somit eine kostenlose Softwarelösung, die auf fast jedem PC lauffähig ist. Es werden durch avrdude und avr-gcc viele Programmierkabel, AVRs und Programmiersprachen untersützt. Eine komfortable Bedienung vereinfacht das Entwickeln. Bald wird auch ein Simulator folgen. Diese CD ist nicht nur für Linuxprofis geeignet, sondern wurde auf eine einfache Bedienung ausgelegt. Es sind die schnelleren, aber umständlicheren Konsolenprogramme vorhanden, jedoch lassen sich alle Entwicklungsaufgaben auch über grafische Benutzeroberflächen erledigen. Die CD wurde speziell für diese Aufgaben entwickelt und hat die benötigten Anwendungen schon vorinstalliert.<br />
<br />
== Installation ==<br />
Um die Avr-live-CD zu verwenden, entpacke man das RAR-Verzeichnis und brenne die ISO Datei. <br />
Der Computer wird nun neu gestartet, dann ruft man das Bios auf. Hier muss man die Bootreihenfolge<br />
ändern. Die CD muss hierbei von höherer Priorität sein als die Harddisk. Nach einem Neustart des Computers started die Avr-Live-CD.<br />
<br />
=== Hinweise zur Benutzung/Eigenarten ===<br />
Im Moment ist es nötig in das Verzeichnis, in der sich der Quelltext befindet, eine Datei zu kopieren. Diese Datei heist "crt[avrtyp].o". Diese Dateien sind unter "Avrlibs" auf dem Destop verlinkt. In der neuen Version der AvrLiveCD ist dieser Bug behoben.<br />
<br />
== Relases ==<br />
=== Alpha (relased) ===<br />
Die AvrLiveCD hatte mitte Dezember 2006 das 1. Relase. Erhaten sind die Grundlegenden AVR-Tools wie [[avr-gcc]] und [[avrdude]].<br />
=== Betha (released)===<br />
Die neue Version wurde abgespeckt, sodass nurnoch die Notwendigen Funktionen enthalten sind. Die neue Version von Kontrollerlab ist installiert. Für gute Codeoptimierung sorgt jetzt der Gcc 4.1.2.<br />
<br />
<br />
== Feedback ==<br />
Hier werden alle Feedbacks über die AvrLiveCD gelistet.<br />
<br />
<pre>Außerdem wollt ich Dir noch zu Deinem großartigen Projekt gratulieren. Ich denke, dass <br />
speziell viele Windows-Leute genau auf sowas gewartet haben, und dass sie dann damit<br />
vielleicht auch in die Linux-Community gelockt werden.</pre><br />
* 7. Jan. 2007<br />
== Mitarbeit ==<br />
Jeder kann bei der Avr-live-CD mitarbeiten. Jeder kann die Versionen nach belieben modifizieren, verändern, etc. Nun nurnoch hochladen und hier publizieren.<br />
<br />
<br />
<br />
<br />
{{Ausbauwunsch|Diesen Artikel bitte noch erweitern. Dabei eventuell die Installation und eine Benutzertutorial erstellen.}}<br />
<br />
== Autoren ==<br />
--[[Benutzer:Overthere|Overthere]] 08:12, 15. Dez 2006 (CET)<br />
<br />
==Siehe auch==<br />
* [[AVR]]<br />
<br />
==Weblinks==<br />
* [http://www.avrlivecd.umfragen-service.de/ Projekthomepage]<br />
* [http://www.slax.org Slax]<br />
* [http://www.cadmaniac.org Kontrollerlab] <br />
* [http://www.roboternetz.de/phpBB2/viewtopic.php?t=25912 Forumbeitrag]<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] <br />
* [http://www.xfuture-media.de Xfuture-Media(Hoster der Avr-Live-CD)]<br />
<br />
=== Sponsoring ===<br />
Die Avr-live-CD [http://www.xfuture-media.de Xfuture-Media] hat sich bereiterklärt die Avr-Live-CD zu hosten. Herzlichen Dank!<br />
<br />
=== Download ===<br />
* [http://www.avrlivecd.umfragen-service.de/ Projekthomepage]<br />
* [http://avrlivecd.xfuture-server.de/ AvrLiveCD-Slaxmodule(21 Mb) (Qt-Lib noch notwendig)]<br />
* Version auswählen und .mo Datei downloaden.<br />
* [http://www.slax.org/modules.php?category=libraries&id=1422&name=Qt+Libraries Qt-Lib]<br />
<br />
<br />
<br />
[[Kategorie:Software]]<br />
[[Kategorie:Microcontroller]]<br />
[[Kategorie:Robotikeinstieg]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=12486Linuxdistribution Avr-live-cd DISCONTINUED2007-07-26T07:47:01Z<p>Overthere: </p>
<hr />
<div>Die Avr-live-CD hat die Zielsetzung, ein komfortables und kostenloses Betriebsystem bereitstellen, das <br />
möglichst viele Funktionen für das Programmieren von [[AVR]]s zur Verfügung stellt. <br />
[[Bild:Avrlivecd_screen1.png|thumb|Desktop]]<br />
== Grundlagen ==<br />
[[Bild:Avrlivecd_screen2.png|thumb|Kontrollerlab]]<br />
Die Avr-live-CD basiert auf Slax. Slax basiert auf der Linuxdistribution Slackware und hieß Ursprünglich "Linux Live CD". <br />
Für das Compilieren des Quelltextes wird [[avr-gcc]] verwendet. Der Binärcode in Hex-Form wird mittels avrdude auf den AVR geladen. Kontrollerlab wird als Interface und Programmierumgebung genutzt. <br />
<br />
Diese CD bietet dem Nutzer somit eine kostenlose Softwarelösung, die auf fast jedem PC lauffähig ist. Es werden durch avrdude und avr-gcc viele Programmierkabel, AVRs und Programmiersprachen untersützt. Eine komfortable Bedienung vereinfacht das Entwickeln. Bald wird auch ein Simulator folgen. Diese CD ist nicht nur für Linuxprofis geeignet, sondern wurde auf eine einfache Bedienung ausgelegt. Es sind die schnelleren, aber umständlicheren Konsolenprogramme vorhanden, jedoch lassen sich alle Entwicklungsaufgaben auch über grafische Benutzeroberflächen erledigen. Die CD wurde speziell für diese Aufgaben entwickelt und hat die benötigten Anwendungen schon vorinstalliert.<br />
<br />
== Installation ==<br />
Um die Avr-live-CD zu verwenden, entpacke man das RAR-Verzeichnis und brenne die ISO Datei. <br />
Der Computer wird nun neu gestartet, dann ruft man das Bios auf. Hier muss man die Bootreihenfolge<br />
ändern. Die CD muss hierbei von höherer Priorität sein als die Harddisk. Nach einem Neustart des Computers started die Avr-Live-CD.<br />
<br />
=== Hinweise zur Benutzung/Eigenarten ===<br />
Im Moment ist es nötig in das Verzeichnis, in der sich der Quelltext befindet, eine Datei zu kopieren. Diese Datei heist "crt[avrtyp].o". Diese Dateien sind unter "Avrlibs" auf dem Destop verlinkt. In der neuen Version der AvrLiveCD ist dieser Bug behoben.<br />
<br />
== Relases ==<br />
=== Alpha (relased) ===<br />
Die AvrLiveCD hatte mitte Dezember 2006 das 1. Relase. Erhaten sind die Grundlegenden AVR-Tools wie [[avr-gcc]] und [[avrdude]].<br />
=== Betha (released)===<br />
Die neue Version wurde abgespeckt, sodass nurnoch die Notwendigen Funktionen enthalten sind. Die neue Version von Kontrollerlab ist installiert. Für gute Codeoptimierung sorgt jetzt der Gcc 4.1.2.<br />
<br />
<br />
== Feedback ==<br />
Hier werden alle Feedbacks über die AvrLiveCD gelistet.<br />
<br />
<pre>Außerdem wollt ich Dir noch zu Deinem großartigen Projekt gratulieren. Ich denke, dass <br />
speziell viele Windows-Leute genau auf sowas gewartet haben, und dass sie dann damit<br />
vielleicht auch in die Linux-Community gelockt werden.</pre><br />
* 7. Jan. 2007<br />
== Mitarbeit ==<br />
Jeder kann bei der Avr-live-CD mitarbeiten. Jeder kann die Versionen nach belieben modifizieren, verändern, etc. Nun nurnoch hochladen und hier publizieren.<br />
<br />
<br />
<br />
<br />
{{Ausbauwunsch|Diesen Artikel bitte noch erweitern. Dabei eventuell die Installation und eine Benutzertutorial erstellen.}}<br />
<br />
== Autoren ==<br />
--[[Benutzer:Overthere|Overthere]] 08:12, 15. Dez 2006 (CET)<br />
<br />
==Siehe auch==<br />
* [[AVR]]<br />
<br />
==Weblinks==<br />
* [http://www.avrlivecd.umfragen-service.de/ Projekthomepage]<br />
* [http://www.slax.org Slax]<br />
* [http://www.cadmaniac.org Kontrollerlab] <br />
* [http://www.roboternetz.de/phpBB2/viewtopic.php?t=25912 Forumbeitrag]<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] <br />
* [http://www.xfuture-media.de Xfuture-Media(Hoster der Avr-Live-CD)]<br />
<br />
=== Sponsoring ===<br />
Die Avr-live-CD [http://www.xfuture-media.de Xfuture-Media] hat sich bereiterklärt die Avr-Live-CD zu hosten. Herzlichen Dank!<br />
<br />
=== Download ===<br />
* [http://www.avrlivecd.umfragen-service.de/ Projekthomepage]<br />
* [http://avrlivecd.xfuture-server.de/ AvrLiveCD-Slaxmodule(21 Mb) (Qt-Lib noch notwendig)]<br />
* Version auswählen und .mo Datei downloaden.<br />
* [http://www.slax.org/modules.php?category=libraries&id=1422&name=Qt+Libraries Qt-Lib]<br />
<br />
<br />
<br />
[[Kategorie:Software]]<br />
[[Kategorie:Microcontroller]]<br />
[[Kategorie:Robotereinstieg]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=12485Linuxdistribution Avr-live-cd DISCONTINUED2007-07-26T07:46:15Z<p>Overthere: </p>
<hr />
<div>Die Avr-live-CD hat die Zielsetzung, ein komfortables und kostenloses Betriebsystem bereitstellen, das <br />
möglichst viele Funktionen für das Programmieren von [[AVR]]s zur Verfügung stellt. <br />
[[Bild:Avrlivecd_screen1.png|thumb|Desktop]]<br />
== Grundlagen ==<br />
[[Bild:Avrlivecd_screen2.png|thumb|Kontrollerlab]]<br />
Die Avr-live-CD basiert auf Slax. Slax basiert auf der Linuxdistribution Slackware und hieß Ursprünglich "Linux Live CD". <br />
Für das Compilieren des Quelltextes wird [[avr-gcc]] verwendet. Der Binärcode in Hex-Form wird mittels avrdude auf den AVR geladen. Kontrollerlab wird als Interface und Programmierumgebung genutzt. <br />
<br />
Diese CD bietet dem Nutzer somit eine kostenlose Softwarelösung, die auf fast jedem PC lauffähig ist. Es werden durch avrdude und avr-gcc viele Programmierkabel, AVRs und Programmiersprachen untersützt. Eine komfortable Bedienung vereinfacht das Entwickeln. Bald wird auch ein Simulator folgen. Diese CD ist nicht nur für Linuxprofis geeignet, sondern wurde auf eine einfache Bedienung ausgelegt. Es sind die schnelleren, aber umständlicheren Konsolenprogramme vorhanden, jedoch lassen sich alle Entwicklungsaufgaben auch über grafische Benutzeroberflächen erledigen. Die CD wurde speziell für diese Aufgaben entwickelt und hat die benötigten Anwendungen schon vorinstalliert.<br />
<br />
== Installation ==<br />
Um die Avr-live-CD zu verwenden, entpacke man das RAR-Verzeichnis und brenne die ISO Datei. <br />
Der Computer wird nun neu gestartet, dann ruft man das Bios auf. Hier muss man die Bootreihenfolge<br />
ändern. Die CD muss hierbei von höherer Priorität sein als die Harddisk. Nach einem Neustart des Computers started die Avr-Live-CD.<br />
<br />
=== Hinweise zur Benutzung/Eigenarten ===<br />
Im Moment ist es nötig in das Verzeichnis, in der sich der Quelltext befindet, eine Datei zu kopieren. Diese Datei heist "crt[avrtyp].o". Diese Dateien sind unter "Avrlibs" auf dem Destop verlinkt. In der neuen Version der AvrLiveCD ist dieser Bug behoben.<br />
<br />
== Relases ==<br />
=== Alpha (relased) ===<br />
Die AvrLiveCD hatte mitte Dezember 2006 das 1. Relase. Erhaten sind die Grundlegenden AVR-Tools wie [[avr-gcc]] und [[avrdude]].<br />
=== Betha (released)===<br />
Die neue Version wurde abgespeckt, sodass nurnoch die Notwendigen Funktionen enthalten sind. Die neue Version von Kontrollerlab ist installiert. Für gute Codeoptimierung sorgt jetzt der Gcc 4.1.2.<br />
<br />
<br />
== Feedback ==<br />
Hier werden alle Feedbacks über die AvrLiveCD gelistet.<br />
<br />
<pre>Außerdem wollt ich Dir noch zu Deinem großartigen Projekt gratulieren. Ich denke, dass <br />
speziell viele Windows-Leute genau auf sowas gewartet haben, und dass sie dann damit<br />
vielleicht auch in die Linux-Community gelockt werden.</pre><br />
* 7. Jan. 2007<br />
== Mitarbeit ==<br />
Jeder kann bei der Avr-live-CD mitarbeiten. Jeder kann die Versionen nach belieben modifizieren, verändern, etc. Nun nurnoch hochladen und hier publizieren.<br />
<br />
<br />
<br />
<br />
{{Ausbauwunsch|Diesen Artikel bitte noch erweitern. Dabei eventuell die Installation und eine Benutzertutorial erstellen.}}<br />
<br />
== Autoren ==<br />
--[[Benutzer:Overthere|Overthere]] 08:12, 15. Dez 2006 (CET)<br />
<br />
==Siehe auch==<br />
* [[AVR]]<br />
<br />
==Weblinks==<br />
* [http://www.avrlivecd.umfragen-service.de/ Projekthomepage]<br />
* [http://www.slax.org Slax]<br />
* [http://www.cadmaniac.org Kontrollerlab] <br />
* [http://www.roboternetz.de/phpBB2/viewtopic.php?t=25912 Forumbeitrag]<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] <br />
* [http://www.xfuture-media.de Xfuture-Media(Hoster der Avr-Live-CD)]<br />
<br />
=== Sponsoring ===<br />
Die Avr-live-CD [http://www.xfuture-media.de Xfuture-Media] hat sich bereiterklärt die Avr-Live-CD zu hosten. Herzlichen Dank!<br />
<br />
=== Download ===<br />
* [http://www.avrlivecd.umfragen-service.de/ Projekthomepage]<br />
* [http://avrlivecd.xfuture-server.de/ AvrLiveCD-Slaxmodule(21 Mb) (Qt-Lib noch notwendig)]<br />
* Version auswählen und .mo Datei downloaden.<br />
* [http://www.slax.org/modules.php?category=libraries&id=1422&name=Qt+Libraries Qt-Lib]<br />
<br />
<br />
<br />
[[Kategorie:Software]]<br />
[[Kategorie:Microcontroller]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=12484Linuxdistribution Avr-live-cd DISCONTINUED2007-07-26T07:44:01Z<p>Overthere: </p>
<hr />
<div>Die Avr-live-CD hat die Zielsetzung, ein komfortables und kostenloses Betriebsystem bereitstellen, das <br />
möglichst viele Funktionen für das Programmieren von [[AVR]]s zur Verfügung stellt. <br />
[[Bild:Avrlivecd_screen1.png|thumb|Desktop]]<br />
== Grundlagen ==<br />
[[Bild:Avrlivecd_screen2.png|thumb|Kontrollerlab]]<br />
Die Avr-live-CD basiert auf Slax. Slax basiert auf der Linuxdistribution Slackware und hieß Ursprünglich "Linux Live CD". <br />
Für das Compilieren des Quelltextes wird [[avr-gcc]] verwendet. Der Binärcode in Hex-Form wird mittels avrdude auf den AVR geladen. Kontrollerlab wird als Interface und Programmierumgebung genutzt. <br />
<br />
Diese CD bietet dem Nutzer somit eine kostenlose Softwarelösung, die auf fast jedem PC lauffähig ist. Es werden durch avrdude und avr-gcc viele Programmierkabel, AVRs und Programmiersprachen untersützt. Eine komfortable Bedienung vereinfacht das Entwickeln. Bald wird auch ein Simulator folgen. Diese CD ist nicht nur für Linuxprofis geeignet, sondern wurde auf eine einfache Bedienung ausgelegt. Es sind die schnelleren, aber umständlicheren Konsolenprogramme vorhanden, jedoch lassen sich alle Entwicklungsaufgaben auch über grafische Benutzeroberflächen erledigen. Die CD wurde speziell für diese Aufgaben entwickelt und hat die benötigten Anwendungen schon vorinstalliert.<br />
<br />
== Installation ==<br />
Um die Avr-live-CD zu verwenden, entpacke man das RAR-Verzeichnis und brenne die ISO Datei. <br />
Der Computer wird nun neu gestartet, dann ruft man das Bios auf. Hier muss man die Bootreihenfolge<br />
ändern. Die CD muss hierbei von höherer Priorität sein als die Harddisk. Nach einem Neustart des Computers started die Avr-Live-CD.<br />
<br />
=== Hinweise zur Benutzung/Eigenarten ===<br />
Im Moment ist es nötig in das Verzeichnis, in der sich der Quelltext befindet, eine Datei zu kopieren. Diese Datei heist "crt[avrtyp].o". Diese Dateien sind unter "Avrlibs" auf dem Destop verlinkt. In der neuen Version der AvrLiveCD ist dieser Bug behoben.<br />
<br />
== Relases ==<br />
=== Alpha (relased) ===<br />
Die AvrLiveCD hatte mitte Dezember 2006 das 1. Relase. Erhaten sind die Grundlegenden AVR-Tools wie [[avr-gcc]] und [[avrdude]].<br />
=== Betha (scheduled)===<br />
Das nächste Relase der AvrLiveCD wird mitte Juli 2007 erwarted. Geplant sind hier KiCad sowie die 0.8 Version von Kontrollerlab einzubinden. Avr-Gcc wird auf die neueste Version upgedated, sowie die make-Eigenart wird behen sein.<br />
<br />
<br />
== Feedback ==<br />
Hier werden alle Feedbacks über die AvrLiveCD gelistet.<br />
<br />
<pre>Außerdem wollt ich Dir noch zu Deinem großartigen Projekt gratulieren. Ich denke, dass <br />
speziell viele Windows-Leute genau auf sowas gewartet haben, und dass sie dann damit<br />
vielleicht auch in die Linux-Community gelockt werden.</pre><br />
* 7. Jan. 2007<br />
== Mitarbeit ==<br />
Jeder kann bei der Avr-live-CD mitarbeiten. Jeder kann die Versionen nach belieben modifizieren, verändern, etc. Nun nurnoch hochladen und hier publizieren.<br />
<br />
<br />
<br />
<br />
{{Ausbauwunsch|Diesen Artikel bitte noch erweitern. Dabei eventuell die Installation und eine Benutzertutorial erstellen.}}<br />
<br />
== Autoren ==<br />
--[[Benutzer:Overthere|Overthere]] 08:12, 15. Dez 2006 (CET)<br />
<br />
==Siehe auch==<br />
* [[AVR]]<br />
<br />
==Weblinks==<br />
* [http://www.avrlivecd.umfragen-service.de/ Projekthomepage]<br />
* [http://www.slax.org Slax]<br />
* [http://www.cadmaniac.org Kontrollerlab] <br />
* [http://www.roboternetz.de/phpBB2/viewtopic.php?t=25912 Forumbeitrag]<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] <br />
* [http://www.xfuture-media.de Xfuture-Media(Hoster der Avr-Live-CD)]<br />
<br />
=== Sponsoring ===<br />
Die Avr-live-CD [http://www.xfuture-media.de Xfuture-Media] hat sich bereiterklärt die Avr-Live-CD zu hosten. Herzlichen Dank!<br />
<br />
=== Download ===<br />
* [http://www.avrlivecd.umfragen-service.de/ Projekthomepage]<br />
* [http://avrlivecd.xfuture-server.de/ AvrLiveCD-Slaxmodule(21 Mb) (Qt-Lib noch notwendig)]<br />
* Version auswählen und .mo Datei downloaden.<br />
* [http://www.slax.org/modules.php?category=libraries&id=1422&name=Qt+Libraries Qt-Lib]<br />
<br />
<br />
<br />
[[Kategorie:Software]]<br />
[[Kategorie:Microcontroller]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=12483Linuxdistribution Avr-live-cd DISCONTINUED2007-07-26T07:43:28Z<p>Overthere: </p>
<hr />
<div>Die Avr-live-CD hat die Zielsetzung, ein komfortables und kostenloses Betriebsystem bereitstellen, das <br />
möglichst viele Funktionen für das Programmieren von [[AVR]]s zur Verfügung stellt. <br />
[[Bild:Avrlivecd_screen1.png|thumb|Desktop]]<br />
== Grundlagen ==<br />
[[Bild:Avrlivecd_screen2.png|thumb|Kontrollerlab]]<br />
Die Avr-live-CD basiert auf Slax. Slax basiert auf der Linuxdistribution Slackware und hieß Ursprünglich "Linux Live CD". <br />
Für das Compilieren des Quelltextes wird [[avr-gcc]] verwendet. Der Binärcode in Hex-Form wird mittels avrdude auf den AVR geladen. Kontrollerlab wird als Interface und Programmierumgebung genutzt. <br />
<br />
Diese CD bietet dem Nutzer somit eine kostenlose Softwarelösung, die auf fast jedem PC lauffähig ist. Es werden durch avrdude und avr-gcc viele Programmierkabel, AVRs und Programmiersprachen untersützt. Eine komfortable Bedienung vereinfacht das Entwickeln. Bald wird auch ein Simulator folgen. Diese CD ist nicht nur für Linuxprofis geeignet, sondern wurde auf eine einfache Bedienung ausgelegt. Es sind die schnelleren, aber umständlicheren Konsolenprogramme vorhanden, jedoch lassen sich alle Entwicklungsaufgaben auch über grafische Benutzeroberflächen erledigen. Die CD wurde speziell für diese Aufgaben entwickelt und hat die benötigten Anwendungen schon vorinstalliert.<br />
<br />
== Installation ==<br />
Um die Avr-live-CD zu verwenden, entpacke man das RAR-Verzeichnis und brenne die ISO Datei. <br />
Der Computer wird nun neu gestartet, dann ruft man das Bios auf. Hier muss man die Bootreihenfolge<br />
ändern. Die CD muss hierbei von höherer Priorität sein als die Harddisk. Nach einem Neustart des Computers started die Avr-Live-CD.<br />
<br />
=== Hinweise zur Benutzung/Eigenarten ===<br />
Im Moment ist es nötig in das Verzeichnis, in der sich der Quelltext befindet, eine Datei zu kopieren. Diese Datei heist "crt[avrtyp].o". Diese Dateien sind unter "Avrlibs" auf dem Destop verlinkt. In der neuen Version der AvrLiveCD ist dieser Bug behoben.<br />
<br />
== Relases ==<br />
=== Alpha (relased) ===<br />
Die AvrLiveCD hatte mitte Dezember 2006 das 1. Relase. Erhaten sind die Grundlegenden AVR-Tools wie [[avr-gcc]] und [[avrdude]].<br />
=== Betha (scheduled)===<br />
Das nächste Relase der AvrLiveCD wird mitte Juli 2007 erwarted. Geplant sind hier KiCad sowie die 0.8 Version von Kontrollerlab einzubinden. Avr-Gcc wird auf die neueste Version upgedated, sowie die make-Eigenart wird behen sein.<br />
<br />
<br />
== Feedback ==<br />
Hier werden alle Feedbacks über die AvrLiveCD gelistet.<br />
<br />
<pre>Außerdem wollt ich Dir noch zu Deinem großartigen Projekt gratulieren. Ich denke, dass <br />
speziell viele Windows-Leute genau auf sowas gewartet haben, und dass sie dann damit<br />
vielleicht auch in die Linux-Community gelockt werden.</pre><br />
* 7. Jan. 2007<br />
== Mitarbeit ==<br />
Jeder kann bei der Avr-live-CD mitarbeiten. Jeder kann die Versionen nach belieben modifizieren, verändern, etc. Nun nurnoch hochladen und hier publizieren.<br />
<br />
<br />
<br />
<br />
{{Ausbauwunsch|Diesen Artikel bitte noch erweitern. Dabei eventuell die Installation und eine Benutzertutorial erstellen.}}<br />
<br />
== Autoren ==<br />
--[[Benutzer:Overthere|Overthere]] 08:12, 15. Dez 2006 (CET)<br />
<br />
==Siehe auch==<br />
* [[AVR]]<br />
<br />
==Weblinks==<br />
* [http://www.avrlivecd.umfragen-service.de/ Projekthomepage]<br />
* [http://www.slax.org Slax]<br />
* [http://www.cadmaniac.org Kontrollerlab] <br />
* [http://www.roboternetz.de/phpBB2/viewtopic.php?t=25912 Forumbeitrag]<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] <br />
* [http://www.xfuture-media.de Xfuture-Media(Hoster der Avr-Live-CD)]<br />
<br />
=== Sponsoring ===<br />
Die Avr-live-CD [http://www.xfuture-media.de Xfuture-Media] hat sich bereiterklärt die Avr-Live-CD zu hosten. Herzlichen Dank!<br />
<br />
=== Download ===<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] Version auswählen und .rar Datei downloaden. ''Achtung 256 MegaByte''<br />
* [http://livecd.ff-aulendorf.de/avr.rar Mirror1]<br />
Alternativ, wenn man schon Slax hat:<br />
* [http://avrlivecd.xfuture-server.de/ AvrLiveCD-Slaxmodule(21 Mb) (Qt-Lib noch notwendig)]<br />
* Version auswählen und .mo Datei downloaden.<br />
* [http://www.slax.org/modules.php?category=libraries&id=1422&name=Qt+Libraries Qt-Lib]<br />
<br />
<br />
<br />
[[Kategorie:Software]]<br />
[[Kategorie:Microcontroller]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=12482Linuxdistribution Avr-live-cd DISCONTINUED2007-07-26T07:42:43Z<p>Overthere: </p>
<hr />
<div>Die Avr-live-CD hat die Zielsetzung, ein komfortables und kostenloses Betriebsystem bereitstellen, das <br />
möglichst viele Funktionen für das Programmieren von [[AVR]]s zur Verfügung stellt. <br />
[[Bild:Avrlivecd_screen1.png|thumb|Desktop]]<br />
== Grundlagen ==<br />
[[Bild:Avrlivecd_screen2.png|thumb|Kontrollerlab]]<br />
Die Avr-live-CD basiert auf Slax. Slax basiert auf der Linuxdistribution Slackware und hieß Ursprünglich "Linux Live CD". <br />
Für das Compilieren des Quelltextes wird [[avr-gcc]] verwendet. Der Binärcode in Hex-Form wird mittels avrdude auf den AVR geladen. Kontrollerlab wird als Interface und Programmierumgebung genutzt. <br />
<br />
Diese CD bietet dem Nutzer somit eine kostenlose Softwarelösung, die auf fast jedem PC lauffähig ist. Es werden durch avrdude und avr-gcc viele Programmierkabel, AVRs und Programmiersprachen untersützt. Eine komfortable Bedienung vereinfacht das Entwickeln. Bald wird auch ein Simulator folgen. Diese CD ist nicht nur für Linuxprofis geeignet, sondern wurde auf eine einfache Bedienung ausgelegt. Es sind die schnelleren, aber umständlicheren Konsolenprogramme vorhanden, jedoch lassen sich alle Entwicklungsaufgaben auch über grafische Benutzeroberflächen erledigen. Die CD wurde speziell für diese Aufgaben entwickelt und hat die benötigten Anwendungen schon vorinstalliert.<br />
<br />
== Installation ==<br />
Um die Avr-live-CD zu verwenden, entpacke man das RAR-Verzeichnis und brenne die ISO Datei. <br />
Der Computer wird nun neu gestartet, dann ruft man das Bios auf. Hier muss man die Bootreihenfolge<br />
ändern. Die CD muss hierbei von höherer Priorität sein als die Harddisk. Nach einem Neustart des Computers started die Avr-Live-CD.<br />
<br />
=== Hinweise zur Benutzung/Eigenarten ===<br />
Im Moment ist es nötig in das Verzeichnis, in der sich der Quelltext befindet, eine Datei zu kopieren. Diese Datei heist "crt[avrtyp].o". Diese Dateien sind unter "Avrlibs" auf dem Destop verlinkt. In der nächsten Version wird verucht diese Eigenart zu beheben.<br />
<br />
== Relases ==<br />
=== Alpha (relased) ===<br />
Die AvrLiveCD hatte mitte Dezember 2006 das 1. Relase. Erhaten sind die Grundlegenden AVR-Tools wie [[avr-gcc]] und [[avrdude]].<br />
=== Betha (scheduled)===<br />
Das nächste Relase der AvrLiveCD wird mitte Juli 2007 erwarted. Geplant sind hier KiCad sowie die 0.8 Version von Kontrollerlab einzubinden. Avr-Gcc wird auf die neueste Version upgedated, sowie die make-Eigenart wird behen sein.<br />
<br />
<br />
== Feedback ==<br />
Hier werden alle Feedbacks über die AvrLiveCD gelistet.<br />
<br />
<pre>Außerdem wollt ich Dir noch zu Deinem großartigen Projekt gratulieren. Ich denke, dass <br />
speziell viele Windows-Leute genau auf sowas gewartet haben, und dass sie dann damit<br />
vielleicht auch in die Linux-Community gelockt werden.</pre><br />
* 7. Jan. 2007<br />
== Mitarbeit ==<br />
Jeder kann bei der Avr-live-CD mitarbeiten. Jeder kann die Versionen nach belieben modifizieren, verändern, etc. Nun nurnoch hochladen und hier publizieren.<br />
<br />
<br />
<br />
<br />
{{Ausbauwunsch|Diesen Artikel bitte noch erweitern. Dabei eventuell die Installation und eine Benutzertutorial erstellen.}}<br />
<br />
== Autoren ==<br />
--[[Benutzer:Overthere|Overthere]] 08:12, 15. Dez 2006 (CET)<br />
<br />
==Siehe auch==<br />
* [[AVR]]<br />
<br />
==Weblinks==<br />
* [http://www.avrlivecd.umfragen-service.de/ Projekthomepage]<br />
* [http://www.slax.org Slax]<br />
* [http://www.cadmaniac.org Kontrollerlab] <br />
* [http://www.roboternetz.de/phpBB2/viewtopic.php?t=25912 Forumbeitrag]<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] <br />
* [http://www.xfuture-media.de Xfuture-Media(Hoster der Avr-Live-CD)]<br />
<br />
=== Sponsoring ===<br />
Die Avr-live-CD [http://www.xfuture-media.de Xfuture-Media] hat sich bereiterklärt die Avr-Live-CD zu hosten. Herzlichen Dank!<br />
<br />
=== Download ===<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] Version auswählen und .rar Datei downloaden. ''Achtung 256 MegaByte''<br />
* [http://livecd.ff-aulendorf.de/avr.rar Mirror1]<br />
Alternativ, wenn man schon Slax hat:<br />
* [http://avrlivecd.xfuture-server.de/ AvrLiveCD-Slaxmodule(21 Mb) (Qt-Lib noch notwendig)]<br />
* Version auswählen und .mo Datei downloaden.<br />
* [http://www.slax.org/modules.php?category=libraries&id=1422&name=Qt+Libraries Qt-Lib]<br />
<br />
<br />
<br />
[[Kategorie:Software]]<br />
[[Kategorie:Microcontroller]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=12481Linuxdistribution Avr-live-cd DISCONTINUED2007-07-26T07:42:17Z<p>Overthere: </p>
<hr />
<div>Die Avr-live-CD hat die Zielsetzung, ein komfortables und kostenloses Betriebsystem bereitstellen, das <br />
möglichst viele Funktionen für das Programmieren von [[AVR]]s zur Verfügung stellt. <br />
[[Bild:Avrlivecd_screen1.png|thumb|Desktop]]<br />
== Grundlagen ==<br />
[[Bild:Avrlivecd_screen2.png|thumb|Kontrollerlab]]<br />
Die Avr-live-CD basiert auf Slax. Slax basiert auf der Linuxdistribution Slackware und hieß Ursprünglich "Linux Live CD". <br />
Für das Compilieren des Quelltextes wird [[avr-gcc]] verwendet. Der Binärcode in Hex-Form wird mittels avrdude auf den AVR geladen. Kontrollerlab wird als Interface und Programmierumgebung genutzt. <br />
<br />
Diese CD bietet dem Nutzer somit eine kostenlose Softwarelösung, die auf fast jedem PC lauffähig ist. Es werden durch avrdude und avr-gcc viele Programmierkabel, AVRs und Programmiersprachen untersützt. Eine komfortable Bedienung vereinfacht das Entwickeln. Bald wird auch ein Simulator folgen. Diese CD ist nicht nur für Linuxprofis geeignet, sondern wurde auf eine einfache Bedienung ausgelegt. Es sind die schnelleren, aber umständlicheren Konsolenprogramme vorhanden, jedoch lassen sich alle Entwicklungsaufgaben auch über grafische Benutzeroberflächen erledigen. Die CD wurde speziell für diese Aufgaben entwickelt und hat die benötigten Anwendungen schon vorinstalliert.<br />
<br />
== Installation ==<br />
Um die Avr-live-CD zu verwenden, entpacke man das RAR-Verzeichnis und brenne die ISO Datei. <br />
Der Computer wird nun neu gestartet, dann ruft man das Bios auf. Hier muss man die Bootreihenfolge<br />
ändern. Die CD muss hierbei von höherer Priorität sein als die Harddisk. Nach einem Neustart des Computers started die Avr-Live-CD.<br />
<br />
=== Hinweise zur Benutzung/Eigenarten ===<br />
Im Moment ist es nötig in das Verzeichnis, in der sich der Quelltext befindet, eine Datei zu kopieren. Diese Datei heist "crt[avrtyp].o". Diese Dateien sind unter "Avrlibs" auf dem Destop verlinkt. In der nächsten Version wird verucht diese Eigenart zu beheben.<br />
<br />
== Relases ==<br />
=== Alpha (relased) ===<br />
Die AvrLiveCD hatte mitte Dezember 2006 das 1. Relase. Erhaten sind die Grundlegenden AVR-Tools wie [[avr-gcc]] und [[avrdude]].<br />
=== Betha (scheduled)===<br />
Das nächste Relase der AvrLiveCD wird mitte Juli 2007 erwarted. Geplant sind hier KiCad sowie die 0.8 Version von Kontrollerlab einzubinden. Avr-Gcc wird auf die neueste Version upgedated, sowie die make-Eigenart wird behen sein.<br />
<br />
<br />
== Feedback ==<br />
Hier werden alle Feedbacks über die AvrLiveCD gelistet.<br />
<br />
<pre>Außerdem wollt ich Dir noch zu Deinem großartigen Projekt gratulieren. Ich denke, dass <br />
speziell viele Windows-Leute genau auf sowas gewartet haben, und dass sie dann damit<br />
vielleicht auch in die Linux-Community gelockt werden.</pre><br />
* 7. Jan. 2007<br />
== Mitarbeit ==<br />
Jeder kann bei der Avr-live-CD mitarbeiten. Jeder kann die Versionen nach belieben modifizieren, verändern, etc. Nun nurnoch hochladen und hier publizieren.<br />
<br />
<br />
<br />
<br />
{{Ausbauwunsch|Diesen Artikel bitte noch erweitern. Dabei eventuell die Installation und eine Benutzertutorial erstellen.}}<br />
<br />
== Autoren ==<br />
--[[Benutzer:Overthere|Overthere]] 08:12, 15. Dez 2006 (CET)<br />
<br />
==Siehe auch==<br />
* [[AVR]]<br />
<br />
==Weblinks==<br />
* [http://www.avrlivecd.umfragen-service.de/ Slax]<br />
* [http://www.slax.org Slax]<br />
* [http://www.cadmaniac.org Kontrollerlab] <br />
* [http://www.roboternetz.de/phpBB2/viewtopic.php?t=25912 Forumbeitrag]<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] <br />
* [http://www.xfuture-media.de Xfuture-Media(Hoster der Avr-Live-CD)]<br />
<br />
=== Sponsoring ===<br />
Die Avr-live-CD [http://www.xfuture-media.de Xfuture-Media] hat sich bereiterklärt die Avr-Live-CD zu hosten. Herzlichen Dank!<br />
<br />
=== Download ===<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] Version auswählen und .rar Datei downloaden. ''Achtung 256 MegaByte''<br />
* [http://livecd.ff-aulendorf.de/avr.rar Mirror1]<br />
Alternativ, wenn man schon Slax hat:<br />
* [http://avrlivecd.xfuture-server.de/ AvrLiveCD-Slaxmodule(21 Mb) (Qt-Lib noch notwendig)]<br />
* Version auswählen und .mo Datei downloaden.<br />
* [http://www.slax.org/modules.php?category=libraries&id=1422&name=Qt+Libraries Qt-Lib]<br />
<br />
<br />
<br />
[[Kategorie:Software]]<br />
[[Kategorie:Microcontroller]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=12258Linuxdistribution Avr-live-cd DISCONTINUED2007-06-13T12:53:02Z<p>Overthere: </p>
<hr />
<div>Die Avr-live-CD hat die Zielsetzung, ein komfortables und kostenloses Betriebsystem bereitstellen, das <br />
möglichst viele Funktionen für das Programmieren von [[AVR]]s zur Verfügung stellt. <br />
[[Bild:Avrlivecd_screen1.png|thumb|Desktop]]<br />
== Grundlagen ==<br />
[[Bild:Avrlivecd_screen2.png|thumb|Kontrollerlab]]<br />
Die Avr-live-CD basiert auf Slax. Slax basiert auf der Linuxdistribution Slackware und hieß Ursprünglich "Linux Live CD". <br />
Für das Compilieren des Quelltextes wird [[avr-gcc]] verwendet. Der Binärcode in Hex-Form wird mittels avrdude auf den AVR geladen. Kontrollerlab wird als Interface und Programmierumgebung genutzt. <br />
<br />
Diese CD bietet dem Nutzer somit eine kostenlose Softwarelösung, die auf fast jedem PC lauffähig ist. Es werden durch avrdude und avr-gcc viele Programmierkabel, AVRs und Programmiersprachen untersützt. Eine komfortable Bedienung vereinfacht das Entwickeln. Bald wird auch ein Simulator folgen. Diese CD ist nicht nur für Linuxprofis geeignet, sondern wurde auf eine einfache Bedienung ausgelegt. Es sind die schnelleren, aber umständlicheren Konsolenprogramme vorhanden, jedoch lassen sich alle Entwicklungsaufgaben auch über grafische Benutzeroberflächen erledigen. Die CD wurde speziell für diese Aufgaben entwickelt und hat die benötigten Anwendungen schon vorinstalliert.<br />
<br />
== Installation ==<br />
Um die Avr-live-CD zu verwenden, entpacke man das RAR-Verzeichnis und brenne die ISO Datei. <br />
Der Computer wird nun neu gestartet, dann ruft man das Bios auf. Hier muss man die Bootreihenfolge<br />
ändern. Die CD muss hierbei von höherer Priorität sein als die Harddisk. Nach einem Neustart des Computers started die Avr-Live-CD.<br />
<br />
=== Hinweise zur Benutzung/Eigenarten ===<br />
Im Moment ist es nötig in das Verzeichnis, in der sich der Quelltext befindet, eine Datei zu kopieren. Diese Datei heist "crt[avrtyp].o". Diese Dateien sind unter "Avrlibs" auf dem Destop verlinkt. In der nächsten Version wird verucht diese Eigenart zu beheben.<br />
<br />
== Relases ==<br />
=== Alpha (relased) ===<br />
Die AvrLiveCD hatte mitte Dezember 2006 das 1. Relase. Erhaten sind die Grundlegenden AVR-Tools wie [[avr-gcc]] und [[avrdude]].<br />
=== Betha (scheduled)===<br />
Das nächste Relase der AvrLiveCD wird mitte Juli 2007 erwarted. Geplant sind hier KiCad sowie die 0.8 Version von Kontrollerlab einzubinden. Avr-Gcc wird auf die neueste Version upgedated, sowie die make-Eigenart wird behen sein.<br />
<br />
<br />
== Feedback ==<br />
Hier werden alle Feedbacks über die AvrLiveCD gelistet.<br />
<br />
<pre>Außerdem wollt ich Dir noch zu Deinem großartigen Projekt gratulieren. Ich denke, dass <br />
speziell viele Windows-Leute genau auf sowas gewartet haben, und dass sie dann damit<br />
vielleicht auch in die Linux-Community gelockt werden.</pre><br />
* 7. Jan. 2007<br />
== Mitarbeit ==<br />
Jeder kann bei der Avr-live-CD mitarbeiten. Jeder kann die Versionen nach belieben modifizieren, verändern, etc. Nun nurnoch hochladen und hier publizieren.<br />
<br />
<br />
<br />
<br />
{{Ausbauwunsch|Diesen Artikel bitte noch erweitern. Dabei eventuell die Installation und eine Benutzertutorial erstellen.}}<br />
<br />
== Autoren ==<br />
--[[Benutzer:Overthere|Overthere]] 08:12, 15. Dez 2006 (CET)<br />
<br />
==Siehe auch==<br />
* [[AVR]]<br />
<br />
==Weblinks==<br />
* [http://www.slax.org Slax]<br />
* [http://www.cadmaniac.org Kontrollerlab] <br />
* [http://www.roboternetz.de/phpBB2/viewtopic.php?t=25912 Forumbeitrag]<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] <br />
* [http://www.xfuture-media.de Xfuture-Media(Hoster der Avr-Live-CD)]<br />
<br />
=== Sponsoring ===<br />
Die Avr-live-CD [http://www.xfuture-media.de Xfuture-Media] hat sich bereiterklärt die Avr-Live-CD zu hosten. Herzlichen Dank!<br />
<br />
=== Download ===<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] Version auswählen und .rar Datei downloaden. ''Achtung 256 MegaByte''<br />
* [http://livecd.ff-aulendorf.de/avr.rar Mirror1]<br />
Alternativ, wenn man schon Slax hat:<br />
* [http://avrlivecd.xfuture-server.de/ AvrLiveCD-Slaxmodule(21 Mb) (Qt-Lib noch notwendig)]<br />
* Version auswählen und .mo Datei downloaden.<br />
* [http://www.slax.org/modules.php?category=libraries&id=1422&name=Qt+Libraries Qt-Lib]<br />
<br />
<br />
<br />
[[Kategorie:Software]]<br />
[[Kategorie:Microcontroller]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Diskussion:Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=12257Diskussion:Linuxdistribution Avr-live-cd DISCONTINUED2007-06-13T12:50:55Z<p>Overthere: </p>
<hr />
<div>Daß die crt*.o nicht gefunden wird deutet auf eine fehlerhaft Installation/Built von avr-gcc/avr-binutils hin.<br />
Sinnvoll wäre auch ein pdf-Reader nebst den AVR-Datenblättern, da man beim Entwickeln gerne darauf zurückgreift. --[[Benutzer:SprinterSB|SprinterSB]] 19:42, 23. Dez 2006 (CET)<br />
<br />
----<br />
<br />
Hallo.<br />
Ich habe das CRT*.o problem durch die makefile in der neueren Version gelöst. Hier muss man die CRTM-File zusätzlich noch angeben. Ein Avr-reader ist schon installiert, der von KDE. Nennt sicht KPDF.<br />
<br />
Bis die nächste Version rauskommt, wird noch auf das neue Release von Kontrollerlab gewartet.<br />
<br />
Viele Grüße<br />
--[[Benutzer:Overthere|Overthere]] 20:22, 2. Feb 2007 (CET)<br />
<br />
<br />
== Bascom ==<br />
<br />
Ich Programmiere in BASCOM und habe deswegen extra ein Windows installiert und jetzt habe ich erst einen Thread gesehen, wie jemand beschreibt, wie er BASCOM mithilfe von Wine auf Linux zum laufen bekommt. Das wäre doch sicher auch etwas für deine Live-CD.<br />
Als WM für wirklich kleine Rechner würde ich auf die CD noch IceWM packen, das rennt dann auch auf einem P90 (mein BASCOM Rechner z.B., hat im Moment Win98).<br />
Und als PDF-Reader dann noch XPDF, als Grafikviewer XZGV. Vielleicht kann man ja noch Eagle (existiert ja nativ für Linux) und Ponyprog draufpacken. <br />
<br />
Viele Grüsse und noch viel Erfolg :)<br />
oiermann<br />
<br />
PS: Wenn es bei Eagle und BASCOM Probleme mit den Lizenzen geben sollte (natürlich nur, falls du das machen solltest), dann würde ich mich bereiterklären, Scripts zu schreiben, die das ganze in eine Ramdisk installieren, also ziehen und dann installieren. Bei Bascom wäre das dann ja auch nur die DEMO-Version.<br />
----<br />
Hallo,<br />
<br />
Bascom wird es auf dieser CD niemals geben, da Bascom ein sehr niederes Ansehen bei mir hat. Tut mir leid für den Korb. <br />
<br />
Viele Grüße<br />
<br />
--[[Benutzer:Overthere|Overthere]] 14:50, 13. Jun 2007 (CEST)</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Getriebemotoren&diff=11718Getriebemotoren2007-04-28T06:27:43Z<p>Overthere: </p>
<hr />
<div>Wenn man in Bezug auf unser Robotik-Hobby von Getriebemotoren spricht, meint man in erster Linie Gleichstrom-Getriebemotoren (DC-Motoren) wie sie zum Teil auch im Modellbau verwendet werden. Da die meisten Bastler doch kleinere Roboter konstruieren, die oft zwischen 2 und 10 kg wiegen, werden oft DC-Motoren im Spannungsbereich von 6 bis 12 V verwendet. In diesem Bereich gibt es natürlich unzählige Motoren aller Preisklassen und Hersteller. Da aber die Robotik-Bastelei nicht erst gestern erfunden wurde, haben sich bestimmte Motoren schon einen Namen gemacht. Sehr beliebte Typen sind zum Beispiel der Motor RB35 und Motoren von Bühler und Igarashi.<br />
<br />
http://www.roboternetz.de/wiki/uploads/Main/rb35.jpg<br />
<br />
http://www.roboternetz.de/wiki/uploads/Main/igarashi.jpg<br />
<br />
Diese Motoren bekommt man mit unterschiedlichen Zahnrad-Untersetzungen, so dass man sowohl sehr flinke Roboter als auch recht starke aber langsame Roboter konstruieren kann. Durch die Wahl der Untersetzung kann auch eine optimale Anpassung an den geplanten Raddurchmesser erfolgen. <br />
<br />
In diesem Zusammenhang empfehle ich folgende Berechnungsseite:<br />
http://www.roboternetz.de/phpBB2/motordrehmoment.php<br />
<br />
Über diese Webseite kann man in etwa berechnen wie stark ein Motor sein muss und welche Geschwindigkeit bei unterschiedlichem Raddurchmesser und Untersetzung zu erwarten sind. Es ist ratsam vor der Konstruktion und vor dem Kauf des Motors ein wenig dort zu rechnen, ansonsten wundert man sich nachher vielleicht, wenn der Roboter kaum schneller als eine Schnecke ist oder aber wegen zu hoher Geschwindigkeit kaum noch steuerbar ist. Als Anhaltspunkt sei gesagt, dass Roboter-Motoren oft zwischen 5 und 50 Umdrehungen pro Minute schaffen, je nachdem wie groß das Rad ist. Je größer das Rad, desto weniger schnell muss sich der Motor drehen, versteht sich.<br />
<br />
==Das Drehmoment==<br />
<br />
Die Kraft eines Motors wird durch das sogenannte Drehmoment angegeben. Beim Kauf sollte immer auf diese Angabe geachtet werden. Die Einheit Newtonmeter wird mit Nm bzw. mNm (milliNewtonmeter) bzw. Ncm (Newtonzentimeter) abgekürzt. <br />
100 Ncm entsprechen 1 Nm. Leider wird das Drehmoment von einigen Anbietern auch in ganz anderen Einheiten angegeben, was den Vergleich nicht immer einfach macht. Ein wenig habe ich den Verdacht, dass dies so mancher Anbieter auch deshalb so macht. Standard ist jedenfalls eindeutig Newton.<br />
<br />
Das Drehmoment ist die Kraft mal den Weg. Ich möchte nun niemanden mit der ganzen Mathematik von meiner Webseite verscheuchen (ich mag die auch nicht), daher nur ein paar Beispiele:<br />
<br />
Wenn man an den Zeiger einer Turmuhr in der Stellung auf 3 Uhr ein Gewicht von 10 kg hängt, wirkt auf die Achse ein Drehmoment von 100 Nm (also 10000 Ncm).<br />
Ein Getriebemotor mit 100 Ncm könnte beispielsweise bei einem Hebel von 1 cm (an der Achse) noch 10 kg heben. Eine ganz schöne Leistung, nicht wahr?<br />
<br />
[[Bild:kirchturmuhr_150dpi.jpeg|center]]<br />
<br />
Kleinere Getriebemotoren (3-10 cm Länge) haben oft eine maximale Kraft von 5–60 Ncm hinter dem Getriebe. Vor einem Getriebe sind es je nach Untersetzungsfaktor oft nur 0,5 bis 3 Ncm. Die Hersteller geben manchmal das Drehmoment vor und manchmal nach dem Getriebe an. Hier kommt es daher immer wieder zu Verwechslungen, also immer gut aufpassen.<br />
In der Regel reicht ein Getriebemotor wie der RB-35 mit ca. 0,6 Ncm (vor Getriebe mit großer Untersetzung z.B. 1:100 oder 1:200) für kleine Roboter fast immer aus. Bei einer Untersetzung 1:100 sind das immerhin fast 40 Ncm. <br />
Noch kleinere Roboter können auch mit Servos angetrieben werden. Einige Bastler haben herausgefunden, dass man Servos mit etwas Geschick auseinandernehmen kann und mit wenig Aufwand so austricksen kann, dass diese als ganz normale Motoren arbeiten (also 360 Grad Volldrehungen machen können). Allerdings reichen Servos aufgrund der Plastikzahnräder wirklich nur für Kleinstroboter (siehe auch unter [[Servos]]).<br />
<br />
http://www.roboternetz.de/wiki/uploads/Main/servo.jpg<br />
<br />
Seit kurzem gibt es für kleinere Roboter auch eine Alternative zu Servos, nämlich einen Modellbau-Twin-Motor. Eigentlich sind es zwei getrennte Motoren mit zwei Getrieben. Jedoch sind diese sehr kompakt zu einem leicht montierbaren Modul zusammengefasst worden. Dadurch lassen sich sehr einfach sehr schmale Roboter konstruieren. <br />
<br />
http://www.roboternetz.de/bilder/twinmotor.gif<br />
<br />
Für größere Roboter ab 5 kg aufwärts braucht man schon recht starke Getriebemotoren. Hier bieten sich dann als preiswerte Lösung auch Scheibenwischermotoren vom Schrotthandel an. Diese können dann auch Roboter über 10 oder 20 kg problemlos bewegen. Allerdings sollte man immer auch den Strombedarf im Auge haben! Keine Sorge, auch Scheibenwischermotoren drehen sich wie normale Motoren um 360 Grad. Die Hin- und Herbewegung der Scheibenwischer wird in der Regel über ein Gestänge erreicht und hat nichts mit dem Motor zu tun.<br />
<br />
http://www.roboternetz.de/bilder/G310233.jpg<br />
<br />
==Vor- und Nachteile von Getriebemotoren==<br />
<br />
Getriebemotoren haben zwar den Vorteil, dass sie recht günstig, recht klein und recht einfach anzusteuern sind. Die Richtungsumkehr ist durch einfaches Umpolen ebenfalls kein Problem. <br />
Aber sie haben auch Nachteile. Ein Roboter, der sich in einer Umgebung haargenau zurecht finden soll, muss kerzengerade und auch Kurven in genau definiertem Winkel fahren können. Dies ist mit Getriebemotoren nicht so einfach, denn die Motoren bleiben ja nicht sofort stehen, wenn die Spannung abgeschaltet wird. Je kleiner die Untersetzung, desto mehr laufen die Roboter nach dem Ausschalten noch nach. Zudem drehen sie sich je nach Bodenbeschaffenheit mal langsamer und mal schneller. Der Roboter weiss also nie genau wieviel Umdrehungen das Rad nun eigentlich wirklich gemacht hat. <br />
Diesen Nachteil muss man mit Sensoren (Drehgeber, Gabellichtschranken etc.) ausgleichen. Am Rad muss also ein Sensor angebracht werden, welcher bei Bewegung des Rades Impulse an den Microcontroller sendet. Der Microcontroller muss also ständig prüfen, wie weit sich ein Rad bewegt hat. Schon die Geradeausfahrt wird ein extrem kompliziertes Steuerungsproblem. Denn alle Motoren unterliegen ja Toleranzen und drehen bei gleicher Spannung nie genauso schnell. Um geradeaus zu fahren, muss also immer ein Motor gebremst und ein anderer beschleunigt werden. Das Ganze muss so schnell kontrolliert und gesteuert werden, dass es dem Beobachter gar nicht auffällt. Zwar lässt sich dies alles mit Software oder auch mit Hardware regeln, aber es ist doch ein ganz schöner Aufwand, insbesondere für Einsteiger.<br />
Daher bin ich kein großer Freund von Getriebemotoren als Roboter-Antrieb, wenn es wirklich um sehr genaue Positionierung geht. Ich favorisiere die sogenannten [[Schrittmotoren]]. [[Schrittmotoren]] gelten als recht kompliziert in der Ansteuerung und recht schwach. Das dies nicht der Fall ist, erläutere ich auf der Seite [[Schrittmotoren]]. <br />
<br />
Ist eine 100% genaue Positionierung aber gar nicht so wichtig, dann ist man ohne Frage mit den Getriebemotoren sehr schnell am Ziel. Die meisten Roboter werden mit 2 Getriebemotoren und eine Art drehbarem Möbelrad konstruiert. Es gibt aber auch Allrad-Fahrzeuge, die gleich auf 4 Motoren setzen. Wie gesagt, im Auge sollte man immer auch den Strombedarf und das Akkugewicht haben. <br />
<br />
Im Roboternetz gibt es eine Übersicht von besonders preiswerten und immer wieder verwendeten Getriebemotoren: http://www.roboternetz.de/motoruebersicht.html Diese Liste wird immer ergänzt, wenn es irgendwo wieder besondere Schnäppchen gibt.<br />
<br />
<br />
==Siehe auch==<br />
* [[Motorkraft_berechnen]]<br />
* [[Getriebemotoren Ansteuerung]]<br />
* [[Servos]]<br />
<br />
==Weblinks==<br />
* [http://www.roboternetz.de/phpBB2/motordrehmoment.php Stärke des Motors online berechnen lassen]<br />
<br />
[[Category:Robotikeinstieg]]<br />
[[Category:Praxis]]<br />
[[Category:Grundlagen]]<br />
[[Category:Motoren]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Avr-gcc&diff=10344Avr-gcc2007-03-03T06:43:01Z<p>Overthere: </p>
<hr />
<div>'''avr-gcc''' ist ein freier C-[[Compiler]], mit dem man C-Programme zu ausführbaren Programmen übersetzen kann, die auf [[Microcontroller]]n der [[AVR]]-Familie lauffähig sind. <br />
An Sprachen versteht avr-gcc sowohl C als auch [[#C%2b%2b|C++]]. <br />
Neben Standard-C bzw. ANSI-C versteht avr-gcc auch GNU-C, das etwas mehr Möglichkeiten und kleinere Spracherweiterungen bietet.<br />
<br />
avr-gcc kann auch dazu verwendet werden, um C/C++ Programme nach Assembler zu übersetzen oder um Bibliotheken zu erstellen, die später in unterschiedlichen Projekten verwendet werden können.<br />
<br />
Wie bei allen aus der UNIX-Welt kommenden Programmen ist das Kommando-Interface von avr-gcc die Shell bzw. die Kommandozeile, über die Optionen, Parameter, Einstellungen und die Namen der zu übersetzenden Dateien angegeben werden. <br />
<br />
=How to Read=<br />
<br />
Dieser Artikel bespricht avr-gcc Version 3.x. Er ist kein C-Tutorial und kein AVR-Handbuch &ndash; das würde den Umfang des Artikels bei weitem sprengen. <br />
<br />
Der Artikel ist ein Handbuch zu avr-gcc. Er bespricht zum Beispiel, wie man avr-gcc anwendet und Besonderheiten von avr-gcc-C,<br />
die nicht zum Sprachumfang von C gehören.<br />
Dazu zählen die Definition von [[#Interrupts|Interrupt]] Service Routinen ([[ISR|ISRs]]) <br />
oder wie man Daten ins [[EEPROM]] legt.<br />
<br />
Es wird also besprochen, ''wie'' eine ISR zu definieren ist, aber nicht,<br />
''warum'' das gegebenenfalls notwendig oder nicht notwendig ist. <br />
''Warum'' etwas gemacht wird, ist abhängig von der gestellten Aufgabe,<br />
etwa ''"Initialisiere den [[UART]] zur Benutzung mit 9600 Baud"''.<br />
Dafür enthält dieser Artikel zusammen mit dem AVR-Handbuch das Rüstzeug, <br />
bietet aber keine Lösungen für konkrete Aufgaben.<br />
<br />
Neben diesem Artikel gibt es den Unterartikel [[avr-gcc/Interna|Interna von avr-gcc]] wo Dinge wie die Registerverwendung, Attribute, Builtins und Sections von avr-gcc dargestellt werden. Zudem findet sich dort ein Überblick über die Arbeitsweise von gcc mit den Schritten<br />
* Precompilieren<br />
* Compilieren<br />
* Assemblieren<br />
* Linken<br />
Ein weiterer Unterartikel widmet sich dem Thema [[Inline-Assembler in avr-gcc]].<br />
<br />
In den [[:Kategorie:Quellcode C|C-Codebeispielen]]<br />
befindet sich das ausführlichere Beispiel "[[Hallo Welt für AVR (LED blinken)]]",<br />
das nur eine [[Diode#Lumineszenzdiode|LED]] blinkt und zeigt, <br />
wie ein kleines Projekt mit avr-gcc compiliert werden kann.<br />
<br />
Es gibt ein [[C-Tutorial]], das jedoch noch unvollständig und teilweise feherhaft ist (Stand 02/2006). Darüber hinaus gibt es ein [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial C-Tutorial bei www.mikrocontroller.net].<br />
<br />
=Benutzer-Schnittstelle=<br />
<br />
Die Benutzer-Schnittstelle von avr-gcc ist &ndash; wie für alle Programme, die aus der UNIX-Welt kommen &ndash; die Kommandozeile einer Shell, Console bzw. Eingabeaufforderung. <br />
<br />
Im einfachsten Fall sieht ein Aufruf von avr-gcc also so aus:<br />
> avr-gcc<br />
Dabei das '<tt>></tt>' nicht mittippen, und ein ENTER am Ende der Zeile drücken.<br />
Die Antwort bei korrekter Installation ist dann<br />
avr-gcc: no input files<br />
Was bedeutet: das Programm avr-gcc wurde vom Betriebssystem gefunden und konnte/durfte gestartet werden. Dann gibt avr-gcc eine Fehlermeldung aus und beendet die Ausführung, weil er keine Eingabedatei(en) bekommen hat &#150; was ja auch stimmt. Soweit ist also alles in Butter.<br />
<br />
Um eine C-Datei <tt>foo.c</tt> mir avr-gcc optimiert zu einem lauffähigen elf-Programm <tt>foo.elf</tt> für einen [[ATmega32]] zu compileren, würde man angeben<br />
> avr-gcc -O2 -mmcu=atmega32 foo.c -o foo.elf<br />
Hat man seine Quellen auf zwei oder mehre Dateien verteilt, geht es analog:<br />
> avr-gcc -O2 -mmcu=atmega32 foo.c foo2.c -o foo.elf<br />
<br />
Will man nur eine Objekt-Datei erstellen (nur compilieren, nicht linken), dann geht das wie folgt. Das kann günstig sein bei grösseren Projekten, wenn man das Projekt neu erzeugen will, aber nur in einer Quelldatei was geändert hat. Oder wenn das Objekt in einer Bibliothek landen soll.<br />
> avr-gcc -O2 -c -mmcu=atmega32 foo.c -o foo.o<br />
<br />
Die ausführbare Gesamtdatei <tt>foo_all.elf</tt> erhält man dann, indem alle Objekte zusammenlinkt:<br />
> avr-gcc -mmcu=atmega32 foo.o foo2.o foo3.o -o foo_all.elf<br />
<br />
Um die ausführbare Datei in das oft verwendete Intex-HEX-Format umzuwandeln (einmal fürs Programm, einmal für ein Abbild des [[EEPROM]]s) gibt man an:<br />
> avr-objcopy -O ihex -j .text -j .data foo_all.elf foo_all.hex<br />
> avr-objcopy -O ihex -j .eeprom --change-section-lma .eeprom=0 foo_all.elf foo_all_eeprom.hex<br />
<br />
----<br />
<br />
[[GCC]] war immer Kommandozeilen-orientiert und wird es auch immer bleiben, denn das hat gute Gründe:<br />
* ein Compiler ist ein Compiler ist ein Compiler (und keine grafische Bedienschnittstelle)<br />
* die Plattformabhängigkeit wird auf ein Minimum reduziert<br />
* es gibt die Möglichkeit, avr-gcc per Skript oder [[make]] zu starten<br />
* avr-gcc kann durchaus in eine Umgebung integriert werden: in einen Editor oder in eine GUI wie neuere Versionen von AVR-Studio erfolgreich beweisen, etc. Der avr-gcc-Aufruf kann sogar von einem Server-Socket oder einer Web-Application heraus erfolgen, welche ein C-Programm empfängt, es von avr-gcc übersetzen lässt, und das Resultat zurückschickt oder sonst was damit anstellt.<br />
* Lizenzgründe: eine Umgebung, die avr-gcc integriert, kann durchaus proprietär oder nicht quelloffen sein und muss nicht der [[Freie Software|GPL]] unterliegen. Wieder ist AVR-Studio ein Beispiel.<br />
<br />
<br />
<br />
<br />
<br />
= Unterstützte AVR-Derivate=<br />
;Classic AVR&#58;: [[AT90S1200]], [[AT90S2313]], [[AT90S8515]], [[AT90S8535]], [[AT90S4433]], [[AT90S4414]], [[AT90S4434]], [[AT90S2323]], [[AT90S2333]], [[AT90S2343]], <br />
<br />
;tinyAVR&#58;: [[ATtiny10]], [[ATtiny11]], [[ATtiny12]], [[ATtiny15]], [[ATtiny28]], [[ATtiny22]], [[ATtiny26]], [[AT90C8534]], [[AT86rf401]], [[ATtiny13]], [[ATtiny2313]], [[ATtiny261]], [[ATtiny461]], [[ATtiny861]], [[ATtiny24]], [[ATtiny44]], [[ATtiny84]], [[ATtiny25]], [[ATtiny45]], [[ATtiny85]]<br />
<br />
;megaAVR&#58;: [[ATmega603]], [[ATmega103]], [[AT76C711]], [[ATmega48]], [[ATmega8]], [[ATmega83]], [[ATmega85]], [[ATmega88]], [[ATmega8515]], [[ATmega8535]], [[ATmega16]], [[ATmega161]], [[ATmega162]], [[ATmega163]], [[ATmega164p]], [[ATmega165]], [[ATmega165P]], [[ATmega168]], [[ATmega32]], [[ATmega323]], [[ATmega324P]], [[ATmega325]], [[ATmega3250]], [[ATmega64]], [[ATmega640]], [[ATmega644]], [[ATmega644P]], [[ATmega128]], [[ATmega1280]], [[ATmega1281]], [[ATmega645]], [[ATmega6450]], [[AT94K]]<br />
<br />
; [[LCD]] AVR&#58;: [[ATmega169]], [[ATmega169P]], [[ATmega329]], [[ATmega3290]], [[ATmega649]], [[ATmega6490]],<br />
; Lightning AVR&#58;: [[AT90PWM2]], [[AT90PWM3]]<br />
; [[CAN]] AVR&#58;: [[AT90CAN32]], [[AT90CAN64]], [[AT90CAN128]]<br />
; Smart Battery&#58;: [[ATmega406]]<br />
; [[USB]] AVR&#58;: [[AT43USB320]], [[AT43USB355]], [[AT90USB646]], [[AT90USB647]], [[AT90USB1286]], [[AT90USB1287]]<br />
;<br />
<br />
Diese Liste kann man avr-gcc anzeigen lassen mit<br />
> avr-gcc --target-help<br />
<br />
=Kommandozeilen-Optionen=<br />
Die Codegenerierung bei avr-gcc wird über Kommandozeilen-Optionen gesteuert. Diese legen fest, für welchen Controller Code zu erzeugen ist, wie stark optimiert wird, ob Debug-Informationen erzeugt werden, etc. Die Optionen teilen sich in zwei Gruppen: Optionen, die für alle GCC-Ports verfürgbar sind und maschinenspezifische Optionen, die nur für AVR verfügbar sind.<br />
<br />
Aus der Masse an GCC-Optionen kann hier nur ein kleiner Auszug der wichtigsten und am häufigsten verwendeten Optionen vorgestellt werden. Eine Auflistung aller GCC-Optionen mit Kurzbeschreibung umfasst knapp 1000 Zeilen &#150; ohne undokumentierte Optionen, versteht sich.<br />
<br />
==Allgemeine Optionen für GCC==<br />
; <tt>--help</tt>: Anzeige der wichtigsten Optionen<br />
; <tt>--help -v</tt>: Überschüttet einen mit Optionen<br />
; <tt>--target-help</tt>: Anzeige der wichtigsten maschinenspezifischen Optionen und der unterstützten AVR-Derivate<br />
; <tt>-O0</tt>: keine Optimierung<br />
; <tt>-O1</tt>: Optimierung<br />
; <tt>-Os</tt>: optimiert für Code-Größe<br />
; <tt>-O2</tt>: stärkere Optimierung für bessere Laufzeit<br />
; <tt>-g</tt>: erzeugt Debug-Informationen<br />
; <tt>-c</tt>: (pre)compilert und assembliert nur bis zum Objekt (<tt>*.o</tt>), kein Link-Lauf<br />
; <tt>-S</tt>: (pre)compilert nur und erzeugt Assembler-Ausgabe (*.s)<br />
; <tt>-E</tt>: nur Precompilat (<tt>*.i</tt>) erzeugen, kein Compilieren, kein Assemblieren, kein Linken<br />
; <tt>-o <filename></tt>: legt den Name der Ausgabedatei fest<br />
; <tt>-v</tt>: zeigt Versionsinformationen an und ist geschwätzig (verbose): Anzeige der aufgerufenen tools<br />
; <tt>-I<path></tt>: Angabe eines weiteren Include-Pfads, in dem Dateien mit <tt>#include <...></tt> gesucht werden<br />
; <tt>-E -dM <filename></tt>: Anzeige aller Defines<br />
; <tt>-MM</tt>: Für die angegebenen Eingabe-Dateien wird eine Ausgabe erzeugt, die als [[make|Makefile]]-Fragment dienen kann und die Anhängigkeiten (dependencies) der Objekte von den Quellen/Headern beschreibt.<br />
; <tt>-D<name></tt>: Definiert Makro <tt><name></tt><br />
; <tt>-D<name>=<wert></tt>: Definiert Makro <tt><name></tt> zu <tt><wert></tt><br />
; <tt>-U<name></tt>: Undefiniert Makro <tt><name></tt><br />
; <tt>-save-temps</tt>: Temporäre Dateien (<tt>*.i</tt>, <tt>*.s</tt>) werden nicht gelöscht. Teilweise fehlerhaft zusammen mit <tt>-c</tt><br />
; <tt>-Wa,<options></tt>: übergibt Komma-getrennte Liste <tt><options></tt> an den Assembler (<tt>avr-as</tt>)<br />
:;<tt>-Wa,-a=<filename></tt>: Assembler erzeugt ein Listing mit Name <tt><filename></tt><br />
; <tt>-Wp,<options></tt>: übergibt Komma-getrennte Liste <tt><options></tt> an den Preprozessor<br />
; <tt>-Wl,<options></tt>: übergibt Komma-getrennte Liste <tt><options></tt> an den Linker (<tt>avr-ld</tt>)<br />
:;<tt>-Wl,-Map=<filename></tt>: Linker erzeugt ein Map-File mit Name <tt><filename></tt><br />
:;<tt>-Wl,--oformat=<format></tt>: Linker erzeugt Ausgabe im Format <tt><format></tt>, z.b. <tt>ihex</tt> für Intel-HEX-File<br />
:;<tt>-Wl,--section-start=<section>=<address></tt>: Linker legt die [[avr-gcc/Interna#Sections|Section]] <tt><section></tt> ab Adresse <tt><address></tt>, z.B: <tt>.eeprom=0x810001</tt><br />
; <tt>-Wall</tt>: gibt mehr Warnungen, aber immer noch nicht alle<br />
; <tt>-pedantic</tt>: geht besonders pedantisch mit Code um<br />
; <tt>-std=c89<br/>-ansi</tt>: bricht mit einer Fehlermeldung ab, wenn kein ANSI-C (ISO C89) verwendet wurde<br />
; <tt>-std=c99</tt>: bricht mit einer Fehlermeldung ab, wenn kein ISO C99 verwendet wurde<br />
; <tt>-ffreestanding</tt>: Das erzeugte Programm läuft nicht in einer Umgebung wie einer Shell. Der Prototyp von <tt>main</tt> ist<br />
:<pre>void main (void);</pre><br />
<br />
==Maschinenspezifische Optionen für avr-gcc==<br />
Maschinenabhängige Optionen beginnen immer mit '''-m'''<br />
;-mmcu=xxx: Festlegen des Targets (Zielsystem/Controller), für das Code generiert werden soll. Je nach Target muss avr-gcc unterschiedliche Instruktionen verwenden und andere Startup-Dateien (<tt>crtxxx.o</tt>) einbinden. avr-gcc setzt spezielle Defines, um auch in der Quelle zwischen den Targets unterscheiden zu können, falls das notwendig sein sollte: <br />
:{| border="0" cellpadding="0" cellspacing="0"<br />
|<br />
<pre><br />
#ifdef __AVR_AT90S2313__<br />
/* Code fuer AT90S2313 */<br />
#elif defined (__AVR_ATmega8__) || defined (__AVR_ATmega32__)<br />
/* Code fuer Mega8 und Mega32 */ <br />
#else<br />
#error Das ist noch nicht implementiert für diesen Controller!<br />
#endif<br />
</pre><br />
|}<br />
<br />
Zwar gibt es für alle AVR-Derivate die <tt>avr/io.h</tt>, aber die AVR-Familien unterscheiden sich in ihrer Hardware; z.B. darin, wie I/O-Register heissen oder wie Hardware zu initialisieren ist. Diese Abhängigkeit kann man in unterschiedlichen Codestücken aufteilen und wie oben gezeigt bedingt übersetzen. Dadurch hat man Funktionalitäten wie <tt>uart_init</tt> auf unterschiedlichen Controllern und wahrt den Überblick, weil nicht für jede Controller-Familie eine extra Datei notwendig ist.<br />
{| <br />
|- valign="top" <br />
| <br />
:{| {{Blauetabelle}}<br />
|+ '''AVR classic, &lt;= 8 kByte'''<br />
|- {{Hintergrund1}}<br />
!|mcu || Builtin define<br />
|- <br />
|avr2 ||<tt>__AVR_ARCH__=2</tt><br />
|-<br />
|[[AT90S2313|at90s2313]] ||<tt>__AVR_AT90S2313__</tt><br />
|-<br />
|at90s2323 ||<tt>__AVR_AT90S2323__</tt><br />
|-<br />
|at90s2333 ||<tt>__AVR_AT90S2333__</tt><br />
|-<br />
|at90s2343 ||<tt>__AVR_AT90S2343__</tt><br />
|-<br />
|attiny22 ||<tt>__AVR_ATtiny22__</tt><br />
|-<br />
|attiny26 ||<tt>__AVR_ATtiny26__</tt><br />
|-<br />
|at90s4414 ||<tt>__AVR_AT90S4414__</tt><br />
|-<br />
|at90s4433 ||<tt>__AVR_AT90S4433__</tt><br />
|-<br />
|at90s4434 ||<tt>__AVR_AT90S4434__</tt><br />
|-<br />
|at90s8515 ||<tt>__AVR_AT90S8515__</tt><br />
|-<br />
|at90c8534 ||<tt>__AVR_AT90C8534__</tt><br />
|-<br />
|at90s8535 ||<tt>__AVR_AT90S8535__</tt><br />
|-<br />
|at86rf401 ||<tt>__AVR_AT86RF401__</tt><br />
|}<br />
| <!-----------------------------------------------------------><br />
:{| {{Blauetabelle}}<br />
|+ '''AVR classic, &gt; 8 kByte'''<br />
|- bgcolor="#ccccff"<br />
! |mcu ||Builtin define<br />
|- <br />
|avr3 ||<tt>__AVR_ARCH__=3</tt><br />
|-<br />
|atmega103 ||<tt>__AVR_ATmega103__</tt><br />
|-<br />
|atmega603 ||<tt>__AVR_ATmega603__</tt><br />
|-<br />
|at43usb320 ||<tt>__AVR_AT43USB320__</tt><br />
|-<br />
|at43usb355 ||<tt>__AVR_AT43USB355__</tt><br />
|-<br />
|at76c711 ||<tt>__AVR_AT76C711__</tt><br />
|}<br />
|}<br />
<br />
----<!-----------------------------------------------------------><br />
<br />
{| <br />
|- valign="top"<br />
|<br />
:{| {{Blauetabelle}}<br />
|+ '''AVR enhanced, &lt;= 8 kByte'''<br />
|- bgcolor="#ccccff"<br />
!|mcu || Builtin define<br />
|- <br />
|avr4 ||<tt>__AVR_ARCH__=4</tt><br />
|-<br />
|[[Atmel Controller Mega8|atmega8]] ||<tt>__AVR_ATmega8__</tt><br />
|-<br />
|atmega8515 ||<tt>__AVR_ATmega8515__</tt><br />
|-<br />
|atmega8535 ||<tt>__AVR_ATmega8535__</tt><br />
|}<br />
|<!-----------------------------------------------------------><br />
:{| {{Blauetabelle}}<br />
|+ '''AVR enhanced, &gt; 8 kByte'''<br />
|- bgcolor="#ccccff"<br />
!|mcu ||Builtin define<br />
|- <br />
|avr5 ||<tt>__AVR_ARCH__=5</tt> <br />
|-<br />
|[[Atmel Controller Mega16 und Mega32|atmega16]] ||<tt>__AVR_ATmega16__</tt><br />
|-<br />
|atmega161 ||<tt>__AVR_ATmega161__</tt><br />
|-<br />
|atmega162 ||<tt>__AVR_ATmega162__</tt><br />
|-<br />
|atmega163 ||<tt>__AVR_ATmega163__</tt><br />
|-<br />
|atmega169 ||<tt>__AVR_ATmega169__</tt><br />
|-<br />
|[[Atmel Controller Mega16 und Mega32|atmega32]] ||<tt>__AVR_ATmega32__</tt><br />
|-<br />
|atmega323 ||<tt>__AVR_ATmega323__</tt><br />
|-<br />
|[[ATMega64|atmega64]] ||<tt>__AVR_ATmega64__</tt><br />
|-<br />
|[[Atmel Controller Mega128|atmega128]] ||<tt>__AVR_ATmega128__</tt><br />
|-<br />
|at94k ||<tt>__AVR_AT94K__</tt><br />
|}<br />
|}<br />
<br />
----<!-----------------------------------------------------------><br />
<br />
<br />
:{| {{Blauetabelle}}<br />
|+ '''AVR, nur Assembler'''<br />
|- bgcolor="#ccccff"<br />
! |mcu ||Builtin define<br />
|- <br />
|avr1 ||<tt>__AVR_ARCH__=1</tt><br />
|-<br />
|at90s1200 ||<tt>__AVR_AT90S1200__</tt><br />
|-<br />
|attiny11 ||<tt>__AVR_ATtiny11__</tt><br />
|-<br />
|attiny12 ||<tt>__AVR_ATtiny12__</tt><br />
|-<br />
|attiny15 ||<tt>__AVR_ATtiny15__</tt><br />
|-<br />
|attiny28 ||<tt>__AVR_ATtiny28__</tt><br />
|}<br />
<br />
----<br />
<br />
; -minit-stack=xxx: Festlegen der Stack-Adresse<br />
; -mint8: Datentyp <tt>int</tt> ist nur 8 Bit breit, anstatt 16 Bit. Datentypen mit 32 Bit wie <tt>long</tt> sind nicht verfügbar<br />
; -mno-interrupts: Ändert den Stackpointer ohne Interrupts zu deaktivieren<br />
; -mcall-prologues: Funktions-Prolog und -Epilog werden als Unterroutinen umgesetzt, um die Codegröße zu verkleinern<br />
; -mtiny-stack: Nur die unteren 8 Bit des Stackpointers werden verändert<br />
; -mno-tablejump: Für ein <tt>switch</tt>-Statement werden keine Sprungtabellen angelegt<br />
; -mshort-calls: Verwendet <tt>rjmp</tt>/<tt>rcall</tt> (begrenzte Sprungweite) auf Devices mit mehr als 8 kByte Flash<br />
; -msize: Ausgabe der Instruktonslängen im asm-File<br />
; -mdeb: (undokumentiert) Ausgabe von Debug-Informationen für GCC-Entwickler<br />
; -morder1: (undokumentiert) andere Register-Allokierung<br />
; -morder2: (undokumentiert) andere Register-Allokierung<br />
<br />
<br />
<br />
=C++=<br />
<br />
:''"C++ is a complex language and an evolving one, and its standard definition (the ISO C++ standard) was only recently completed. As a result, your C++ compiler may occasionally surprise you, even when its behavior is correct."''<br />
<br />
Zudem sollte der Einsatz von C++ aus Effizienzgründen sehr kritisch betrachtet werden:<br />
:''"When programming C++ in space- and runtime-sensitive environments like microcontrollers, extra care should be taken to avoid unwanted side effects of the C++ calling conventions like implied copy constructors that could be called upon function invocation etc. These things could easily add up into a considerable amount of time and program memory wasted. Thus, casual inspection of the generated assembler code (using the <tt>-S</tt> compiler option) seems to be warranted."''<br />
<br />
Weiterhin unterliegt der Einsatz von C++ je nach Compiler/Lib-Version bestimmten Einschränkungen:<br />
*Einer kompletten C++ Implementierung fehlt die Unterstützung durch die <tt>libstdc++</tt>, dadurch fehlen Standardfunktionen, -Klassen und -Templates<br />
* Die Operatoren <tt>new</tt> und <tt>delete</tt> sind nicht implementiert, ihre Verwendung führt zu unauflösbaren externen Referenzen (Linker-Fehler)<br />
*Nicht alle Header sind C++-sicher und müssen in <tt>extern "C" {...}</tt> eingeschlossen werden.<br />
*Exceptions werden nicht unterstützt und müssen via <tt>-fno-exceptions</tt> abgeschaltet werden, oder der Linker beschwert sich über eine unauflösbare externe Referenz zu <tt>__gxx_personality_sj0</tt>.<br />
<br />
Als Treiber verwendet man wie immer avr-gcc. Standard-Endungen für C++ sind <tt>.c++</tt> und <tt>.cpp</tt>. Bei anderen Endungen teilt man mit <tt>-x c++</tt> mit, daß es sich um C++ Dateien handelt, oder ruft <tt>avr-c++</tt> direkt auf.<br />
<br />
Interrupt-Service-Routinen (ISRs) sind C-Funktionen und werden definiert wie gehabt. Siehe auch [[#Interrupts|Interrupts]].<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
<br />
#if defined (__cplusplus)<br />
extern "C" {<br />
#endif {{comment|__cplusplus}}<br />
<br />
SIGNAL (SIG_NAME)<br />
{<br />
{{comment|machwas}}<br />
}<br />
<br />
INTERRUPT (SIG_NAME)<br />
{<br />
{{comment|mach was}}<br />
}<br />
<br />
#if defined (__cplusplus)<br />
}<br />
#endif {{comment|__cplusplus}}<br />
<tt>__cplusplus</tt> ist ein Standard [[avr-gcc/Interna#Builtin Defines|GCC-Builtin-Define]].<br />
<br />
Globale Konstruktoren werden in [[avr-gcc/Interna#Sections|Section]] <tt>.init6</tt> ausgeführt, die Destruktoren in <tt>.fini6</tt>.<br />
<br />
=Code-Beispiele=<br />
Dieser Abschnitt enthält Code-Schnippsel für avr-gcc. Es werden Besonderheiten besprochen, die für avr-gcc zu beachten sind. <br />
<br />
Dieser Abschnitt ist ''kein'' [[C-Tutorial|Tutorial zur C-Programmierung]] und ''keine'' Einführung in die Programmiersprache C im allgemeinen. Dafür sei auf einschlägige Tutorials/Bücher verwiesen.<br />
<br />
==Zugriff auf Special Function Registers (SFRs)==<br />
<br />
===Zugiff auf Bytes und Worte===<br />
For den Zugriff auf die SFRs gibt es Defines über den Include<br />
#include <avr/io.h><br />
Abhängig vom eingestellten Controller werden denn Defines eingebunden, über die auf SFRs wie auf normale Variablen zugegriffen werden kann. Die Namen der Defines sind i.d.R. die gleichen wie im AVR-Manual, also z.b. <tt>SREG</tt> für das Prozessorstatus-Register SREG:<br />
#include <avr/io.h><br />
<br />
...<br />
{{ccomment|SREG lesen}}<br />
uint8_t sreg = SREG;<br />
...<br />
{{ccomment|SREG schreiben}}<br />
SREG = sreg;<br />
<!-- <br />
Auf SFRs wird generell über deren Adresse zugegriffen:<br />
{{ccomment|Liest den Inhalt von SREG an Adresse 0x5f}}<br />
unsigned char sreg = *((unsigned char volatile*) 0x5f);<br />
Das bedeutet in etwa: "Lies ein flüchtiges (<tt>volatile</tt>) Byte (<tt>unsigned char</tt>) von Adresse <tt>0x5f</tt>". Der Speicherinhalt von SFRs ist flüchtig, denn er kann sich ändern, ohne daß avr-gcc dies mitbekommt. Daher muss bei jedem C-Zugriff auf ein SFR dieses wirklich gelesen/geschrieben werden, was der Qualifier <tt>volatile</tt> sicherstellt. Ansonst geht der Compiler u.U. davon aus, daß der Inhalt bekannt ist und verwendet einen alten, in einem GPR befindlichen Wert.<br />
<br />
Um lesbaren, weniger fehleranfälligen und unter AVRs halbwegs portierbaren Code zu erhalten, gibt es Makrodefinitionen im Controller-spezifischen Header <tt>ioxxxx.h</tt>, der neben anderen Dingen mit <tt>avr/io.h</tt> includet wird:<br />
Die Bezeichner der SFRs sind die gleichen wie im Manual.<br />
--><br />
Für einen Überblick über die eingebundenen Defines und kann ein Blick in den Controller-spezifischen Header hilfreich sein. Dieser befindet sich in<br />
:<tt> &lt;GCC_HOME&gt;/avr/include/avr/io****.h</tt><br />
z.B. <tt>iom32.h</tt> für einen [[ATmega32]].<br />
<br />
Dieser Zugriff geht auch für 16-Bit Register wie <tt>TCNT1</tt>, für die eine bestimmte Reihenfolge für den Zugriff auf Low- und High-Teil eingehalten werden muss: avr-gcc generiert die Zugriffe in der richtigen Reihenfolge.<br />
uint16_t tcnt1 = TCNT1;<br />
<br />
{{FarbigerRahmen|<br />
Zu beachten ist, daß dieser Zugriff nicht atomar erfolgt. Das Lesen/Schreiben mehrbytiger Werte muss vom Compiler in mehrere Byte-Zugriffe zerlegt werden. Zwischen diesen Zugriffen kann ein [[Interrupt]] auftreten, wenn Interrupts aktiviert sind. Je nach Programm und welche Aufgaben eine [[ISR]] erledigt, kann dies zu Fehlfunktion führen. In dem Fall müssen diese Code-Stücke atomar gemacht werden, damit sie nicht durch einen [[IRQ]] unterbrochen werden können!<br />
}}<br />
<br />
===Zugriff auf einzelne Bits===<br />
Zugriff auf Bits geht wie gewohnt mit den Bitoperationen <br />
<tt>&amp;</tt> (and),<br />
<tt>|</tt> (or),<br />
<tt>^</tt> (xor) und<br />
<tt>~</tt> (not)<br />
<br />
Wieder gibt es Defines in den AVR-Headern, mit denen man Masken für den Zugriff erhalten kann, etwa:<br />
<pre><br />
/* GIMSK / GICR */<br />
#define INT1 7<br />
#define INT0 6<br />
#define IVSEL 1<br />
#define IVCE 0<br />
</pre><br />
<br />
<br />
Masken ergeben sich durch Schieben von <tt>1</tt> an die richtige Position:<br />
<pre><br />
// Ports B_0 und B_1 als Ausgang<br />
DDRB |= (1&lt;&lt;PB0) | (1&lt;&lt;PB1);<br />
</pre><br />
erzeugt<br />
<pre><br />
87 b3 in r24, 0x17<br />
83 60 ori r24, 0x03<br />
87 bb out 0x17, r24<br />
</pre><br />
<br />
Etwas anders sieht der Code aus, wenn die Bits einzeln gesetzt werden und das Register im bitadressierbaren Bereich liegt (SRAM <tt>0x20</tt> bis <tt>0x3f</tt> resp. I/O <tt>0x0</tt> bis <tt>0x1f</tt>):<br />
<pre><br />
// Ports B_0 und B_1 als Ausgang<br />
DDRB |= (1&lt;&lt;PB0);<br />
DDRB |= (1&lt;&lt;PB1);<br />
</pre><br />
erzeugt<br />
<pre><br />
b8 9a sbi 0x17, 0<br />
b9 9a sbi 0x17, 1<br />
</pre><br />
<br />
Um Bits zu löschen, erzeugt man eine Maske, die an der betreffenden Stelle eine &nbsp;0 hat:<br />
<pre><br />
// Ports B_2 als Eingang<br />
DDRB &= ~(1&lt;&lt;PB2);<br />
</pre><br />
<br />
{{FarbigerRahmen| <br />
Auch hier ist zu beachten, daß es Probleme geben kann, wenn nicht atomarer Code erzeugt wird, weil der AVR-Befehlssatz nicht mehr hergibt:<br />
<pre><br />
// toggle PORT B_0: wechseln 0 &lt;--&gt; 1 <br />
PORTB ^= (1&lt;&lt;PB0);<br />
</pre><br />
ergibt<br />
<pre><br />
88 b3 in r24, 0x18<br />
; Wenn hier ein Interrupt auftritt, in dessen ISR PORTB verändert wird,<br />
; dann wird die Änderung durch die letzte Instruktion wieder überschrieben!<br />
91 e0 ldi r25, 0x01<br />
; dito<br />
89 27 eor r24, r25<br />
; dito<br />
88 bb out 0x18, r24<br />
</pre><br />
}} <!-- /FarbigerRahmen --><br />
<br />
<br />
Auch das Lesen einzelner Port-Pins geht über das Maskieren von SFRs:<br />
<pre><br />
DDRB &= ~(1 << PB2); // PortB.2 als INPUT <br />
<br />
if (PINB & (1 << PB2))<br />
// PortB.2 ist HIGH<br />
else<br />
// PortB.2 ist LOW<br />
<br />
<br />
if (!(PINB & (1 << PB2)))<br />
// PortB.2 ist LOW<br />
else<br />
// PortB.2 ist HIGH<br />
</pre><br />
<br />
==Interrupts==<br />
<br />
Um zu kennzeichnen, daß es sich bei einer Funktion um eine Interrupt Sevice Routine (ISR) handelt, gibt es spezielle Attribute. Diese brauchen nicht explizit hingeschrieben zu werden, ebensowenig wie die genaue Nummer des Interrupt Requests (IRQ). Dafür gibt es Includes und die folgenden Makros.<br />
<br />
Bitte beachte auch die Hinweise zu den [[#Inkompatibilität|Inkompatibilität]]en von avr-gcc!<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
<br />
{{ccomment|Eine nichtunterbrachbare Interrupt-Service-Routine}}<br />
SIGNAL (SIG_OUTPUT_COMPARE1A)<br />
{<br />
{{ccomment|ISR-Code}}<br />
}<br />
<br />
{{ccomment|Eine unterbrachbare Interrupt-Service-Routine}}<br />
INTERRUPT (SIG_OUTPUT_COMPARE1B)<br />
{<br />
{{ccomment|ISR-Code}}<br />
}<br />
<br />
Dadurch wird die Funktion mit dem richtigen Prolog/Epilog erzeugt, und es wird ein Eintrag in die Interrupt-Vektortabelle gemacht &#150; bei obigem Beispiel also zwei Einträge.<br />
<br />
{{FarbigerRahmen|<br />
Die Schreibweise des Signal-Names muss genau die sein wie im Header, das schliesst auch Leerzeichen ein! Nicht alle GCC-Versionen bringen Fehler/Warnung, wenn die Schreibweise nicht stimmt.<br />
SIGNAL (SIG_OUTPUT_COMPARE1A ) // !!! Macht NICHT das, was man will (Blank am Ende)!!!<br />
}}<br />
<br />
;<tt>SIGNAL</tt>: Mit Ausführung einer ISR deaktiviert die AVR-Hardware die Interrupts, so daß die ISR nicht durch andere Interrupt-Anforderungen unterbrochen wird. Beim Verlassen der ISR werden Interrupts wieder automatisch aktiviert. Tritt während der ISR ein IRQ auf, wird diese erst nach Beenden des ISR-Codes ausgeführt. Der Interrupt geht also nicht verloren. Zwischen zwei ISRs wird zusätzlich mindestens ein Befehl des normalen Programm-Codes abgearbeitet.<br />
;<tt>INTERRUPT</tt>: Früh im ISR-Prolog werden mit <tt>sei</tt> die von der AVR-Hardware temporär deaktivierten Interrupts reaktiviert. Dadurch kann die ISR von einer IRQ unterbrochen werden. Das bietet die Möglichkeit, so etwas wie Interrupt-Priorisierung nachzubilden, was AVRs selbst nicht können. Weiterhin kann man schneller auf bestimmte Ereignisse reagieren. Tritt während der ISR ein anderer IRQ auf, der schnell bedient werden muss, kann sofort der dringende ISR-Code ausgeführt werden. Ansonsten (Verwendung von <tt>SIGNAL</tt>) würde der Code erst ausgeführt werden, nachdem die aktuelle ISR beendet ist.<br />
<br />
{{FarbigerRahmen|Dauert die ISR zu lange und wird sie nochmals von ihrem eigenen IRQ unterbrochen, stürzt man ab.}} <br />
<br />
Nachschlagen kann man den Namen in<br />
:<tt>&lt;GCC_HOME&gt;/avr/include/avr/ioxxxx.h</tt><br />
<br />
===Interrupts aktivieren===<br />
<br />
Damit eine ISR überhaupt zur Ausführung kommt, müssen drei Bedingungen erfüllt sein<br />
* Interrupts müssen global aktiviert sein<br />
* Der entsprechen IRQ muss aktiviert worden sein<br />
* Das zum IRQ gehörende Ereignis muss eintreten<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
<br />
...<br />
{{ccomment|enable OutputCompareA Interrupt für Timer1}}<br />
TIMSK |= (1 << OCIE1A);<br />
<br />
{{ccomment|disable OutputCompareA Interrupt für Timer1}}<br />
TIMSK &= ~(1 << OCIE1A);<br />
<br />
{{ccomment|Interrupts aktivieren}}<br />
sei();<br />
<br />
{{ccomment|Interrupts abschalten}}<br />
cli();<br />
Sperrt man eine Code-Sequenz durch Einschachteln in ein <tt>cli</tt>/<tt>sei</tt> Paar (man macht das Codestück "atomar", also ununterbrechbar), gehen währenddessen keine Interrupt-Anforderungen verloren. Die entsprechenden IRQ-Flags bleiben gesetzt, und nach dem <tt>sei</tt> werden die IRQs in der Reihenfolge ihrer Prioritäten abgearbeitet. Ausnahme ist, wenn in einem atomaren Block der selbe IRQ mehrfach auftritt. Der ISR-Code wird dann trotzdem nur einmal ausgeführt.<br />
<br />
===default Interrupt===<br />
<br />
Für nicht implementierte Interrupts macht avr-gcc in die Vektortabelle einen Eintrag,<br />
der zu <tt>__bad_interrupt</tt> (definiert im Startup-Code <tt>crt*.o</tt>) springt<br />
und von dort aus weiter zu Adresse&nbsp;0. <br />
Dadurch läuft der AVR wieder von neuem los, wenn ein Interrupt auftritt, <br />
zu dem man keine ISR definiert hat <br />
&#150; allerdings ohne die Hardware zurückzusetzen wie bei einem echten Reset.<br />
<br />
Möchte man diesen Fall abfangen, dann geht das über eine globale Funktion <br />
namens <tt>__vector_default</tt>:<br />
<pre><br />
#include <avr/interrupt.h><br />
<br />
SIGNAL (__vector_default)<br />
...<br />
</pre><br />
Damit wird von <tt>__bad_interrupt</tt> aus nicht nach Adresse&nbsp;0 gesprungen,<br />
sondern weiter zu <tt>__vector_default</tt>, welches durch <tt>SIGNAL</tt> oder<br />
<tt>INTERRUPT</tt> den üblichen ISR-Prolog/Epilog bekommt.<br />
<br />
So kann man z.B. eine Meldung ausgeben, eine Warnlampe blinken, in einer Endlosschleife landen, oder über den [[Watchdog]] einen richtigen Hardware-Reset auslösen, siehe auch Abschnitt "[[#Reset auslösen|Reset auslösen]]".<br />
<br />
===ISR mit eigenem Prolog/Epilog===<br />
<br />
Wenn man in einer ISR komplett eigenes Zeug machen will, <br />
dann definiert man eine nackte Funktion.<br />
Mit <tt>naked</tt> befreit man die Routine vom Standard-Prolog/Epilog.<br />
{{FarbigerRahmen|<br />
Dabei ist darauf zu achten, daß die ISR mit <tt>reti</tt> (return from interrupt) <br />
zurückkehrt und evtl. verwendete Register und den Status (<tt>SREG</tt>) sichert.<br />
}}<br />
#include <avr/io.h><br />
<br />
void __attribute__ ((naked)) <br />
SIG_OVERFLOW0 (void)<br />
{<br />
{{ccomment|Port B.6 &#61; 0}}<br />
{{ccomment|Diese Instruktion verändert nicht das SREG und kein anderes Register}}<br />
{{ccomment|so daß der eigentliche Code nur 1 Befehl lang ist}}<br />
__asm__ __volatile (<br />
"cbi %0, %1" "\n\t"<br />
"reti"<br />
: <br />
: "M" (_SFR_IO_ADDR (PORTB)), "i" (6)<br />
);<br />
}<br />
<br />
Siehe auch [[Inline-Assembler in avr-gcc]].<br />
Die ISR sieht dann so aus:<br />
<pre><br />
__vector_9:<br />
c6 98 cbi 0x18, 6<br />
18 95 reti<br />
</pre><br />
<br />
Wiederum kann man als Funktionsname <tt>__vector_default</tt> nehmen,<br />
um nicht-implementierte IRQs abzufangen:<br />
<pre><br />
void __attribute__ ((naked)) <br />
__vector_default (void)<br />
...<br />
</pre><br />
<br />
==SRAM, Flash, EEPROM: Datenablage am Beispiel Strings==<br />
Die Programmiersprache C kennt selber keine Strings; das einzige, was C bekannt ist, ist der Datentyp <tt>char</tt>, der ein einzelnes Zeichen repräsentiert. <br />
===Darstellung in C===<br />
Ein String im Sinne von C ist ein Array von Charactern bzw. ein Zeiger auf den Anfang des Arrays. Die einzelnen Zeichen folgen im Speicher direkt aufeinander und werden in aufsteigenden Adressen gespeichert. Am String-Ende folgt als Abschluss der Character <tt>'\0'</tt>, um das Ende zu kennzeichnen. Dies ist besonders bei der Berechnung des Speicherplatzes für Strings zu berücksichtigen, denn für die 0 muss auch Platz reserviert werden.<br />
<br />
===Bestimmen der Stringlänge===<br />
<pre><br />
/* Bestimmt die Laenge des Strings ohne die abschliessende '\0' zu zaehlen */<br />
unsigned int strlength (const char *str)<br />
{<br />
unsigned int len = 0;<br />
<br />
while (*str++)<br />
len++;<br />
<br />
return len;<br />
}<br />
</pre><br />
<br />
Die Stringlänge kann auch mit der Standard-Funktion <tt>strlen</tt> bestimmt werden, deren Prototyp sich in <tt>string.h</tt> befindet:<br />
<pre><br />
#include <string.h><br />
size_t strlen (const char*);<br />
</pre><br />
<br />
===String im Flash belassen===<br />
Oftmals werden Strings nur zu Ausgabezwecken verwendet und nicht verändert. Verwendet man Sequenzen der Gestalt<br />
<pre><br />
char *str1 = "Hallo Welt!";<br />
char str2[] = "Hallo Welt!";<br />
</pre><br />
dann werden die Strings im SRAM abgelegt. Im Startup-Code werden die Strings vom Flash ins SRAM kopiert und belegen daher sowohl Platz im SRAM als auch im Flash. Wird ein String nicht verändert, braucht er nicht ins SRAM kopiert zu werden. Das spart Platz im knapp bemessenen SRAM. Allerdings muss anders auf den String zugegriffen werden, denn wegen der Harvard-Architektur des AVR-Kerns kann avr-gcc anhand der Adresse nicht unterscheiden, ob diese ins SRAM, ins Flash oder ins EEPROM zeigt.<br />
<pre><br />
#include <avr/pgmspace.h><br />
<br />
const prog_char str3[] = "Hallo Welt!";<br />
<br />
unsigned int strlen_P (const prog_char *str)<br />
{<br />
unsigned int len = 0;<br />
<br />
while (1)<br />
{<br />
char c = (char) pgm_read_byte (str);<br />
if ('\0' == c)<br />
return len;<br />
len++;<br />
str++; <br />
}<br />
}<br />
<br />
void foo()<br />
{<br />
unsigned int len;<br />
len = strlen_P (str3);<br />
len = strlen_P (PSTR("String im Flash"));<br />
}<br />
</pre><br />
<br />
===String ins EEPROM legen===<br />
Dies geht nach dem gleichen Muster, nach dem Strings ins Flash gelegt werden. Der Zugriff wird vergleichsweise langsam, denn der EEPROM ist langsamer als SRAM bzw. Flash.<br />
<pre><br />
#include <avr/eeprom.h><br />
<br />
const char str4[] __attribute__ ((section(".eeprom"))) = "Hallo Welt!";<br />
<br />
unsigned int strlen_EE (const char *str)<br />
{<br />
unsigned int len = 0;<br />
<br />
while (1)<br />
{<br />
char c = (char) eeprom_read_byte (str);<br />
if ('\0' == c)<br />
return len;<br />
len++;<br />
str++; <br />
}<br />
}<br />
</pre><br />
<br />
==Reset auslösen==<br />
Falls ein Reset per Software ausgelöst werden soll, dann geht das am besten über den [[Watchdog]].<br />
Einfach nur an den RESET-Punkt an Adresse&nbsp;0 zu springen mit<br />
goto *((void**) 0);<br />
initialisiert zwar den Controller von neuem, aber es macht keinen wirkliches RESET mit Zurücksetzen der Hardware und allen I/O-Registern. <br />
<br />
Durch den Watchdog kann man ein 'richtiges' RESET-Signal erzeugen lassen, so daß die AVR-Hardware genau so initialisiert ist, wie nach einem externen RESET. So kann man z.B. via [[UART]] ein RESET-Kommando schicken. Allerdings lässt sich der Watchdog nur minimal auf 15ms einstellen:<br />
<br />
#include <avr/wdt.h><br />
#include <avr/interrupt.h><br />
... <br />
cli(); {{ccomment|Interrupts global abschalten}}<br />
wdt_enable (WDTO_15MS); {{ccomment|Watchdog aufziehen auf 15ms}}<br />
while (1); {{ccomment|warten, bis er zubeisst...}}<br />
<br />
Welches Ereignis einen RESET ausgelöst hat, kann man im Register '''MCUCSR''' (''MCU Control and Status Register'') erfahren. Es gibt 4 mögliche RESET-Quellen:<br />
* Power-On Reset<br />
* External Reset<br />
* Brown-Out Reset<br />
* Watchdog Reset<br />
<br />
Soll der Inhalt von Variablen einen Reset überleben &ndash; eine Variable also nicht initialisiert werden &ndash; dann geht das so:<br />
#include <avr/io.h><br />
<br />
{{ccomment| status informiert z.B. darüber, ob wir selber den Watchdog ausgelöst haben }}<br />
{{ccomment| oder nicht, oder andere Informationen }}<br />
unsigned char status __attribute__ ((section (".noinit")));<br />
<br />
void main (void)<br />
{<br />
{{ccomment|Wert von MCUSCR merken, möglichst früh im Programm }}<br />
unsigned char mcucsr = MCUCSR;<br />
<br />
{{ccomment|MCUCSR zurücksetzen }}<br />
MCUCSR = 0;<br />
<br />
{{ccomment|Watchdog-Reset }}<br />
if (mcuscr & (1 << WDRF))<br />
{<br />
{{ccomment|status auswerten }}<br />
}<br />
<br />
{{ccomment|Power-On Reset: status auf definierten Wert setzen }}<br />
if (mcuscr & (1 << PORF))<br />
{<br />
status = 0;<br />
}<br />
<br />
{{ccomment|status auswerten }}<br />
...<br />
}<br />
<br />
<br />
<br />
=Includes=<br />
<br />
Die mit<br />
#include <...><br />
angegebenen Includes werden von avr-gcc in den <br />
mit der Option '<tt>-I</tt>' anegegenen Pfaden gesucht. <br />
Dem Compiler bekannt sind die Pfade <br />
<GCC_HOME>/avr/include Standard (stdio.h, ...)<br />
<GCC_HOME>/avr/include/avr AVR-spezifisch (avr/io.h, ...)<br />
<GCC_HOME>/lib/gcc/avr/<GCC_VERSION>/include Standard, compilerabh. (limits.h, ...)<br />
<br />
Gibt man z.B. an <br />
#include <stdio.h><br />
dann wird automatisch in diesem Verzeichnis nach <tt>stdio.h</tt> gesucht.<br />
In den Verzeichnissen stehen Standard-Includes, die benötigt werden, wenn man libc-Funktionen <br />
oder mathematische Funktionen etc. verwendet. <br />
AVR-spezifische Dinge stehen im Unterverzeichnis <tt>avr</tt>, etwa:<br />
#include <avr/io.h><br />
{{FarbigerRahmen|<br />
Als Pfad-Separator wird immer ein '''<tt>/</tt>''' verwendet, auch auf Windows-Betriebssystemen! Also kein '''<tt>\</tt>'''&nbsp;!<br />
}}<br />
<br />
==Standard==<br />
<br />
ctype.h Zeichen-Umwandlungs-Makros und ctype Makros<br />
errno.h Symbolische Namen für Fehlercodes<br />
inttypes.h Definiert [u]intN_t wenn man genau N [un]signed Bits <br />
braucht, ISO C99.<br />
math.h Mathematische Funktionen: sin, cos, log, gamma, bessel, ...<br />
setjmp.h libc unterstützt setjmp() und longjmp(), um direkt in eine<br />
andere (nicht-lokale) Funktion zu springen. <br />
stdio.h Standard I/O-Funktionen (printf, ...).<br />
stdlib.h Deklariert grundlegende ISO C-Makros und -Funktionen <br />
sowie einige AVR-spezifische Erweiterungen<br />
string.h Stringoperationen auf NULL-terminierten Strings. (strlen, ...)<br />
stdarg.h Funktionen mit variabler Argumenanzahl<br />
limits.h Min- und Max-Werte von Skalaren (UCHAR_MAX, LONG_MIN, ...)<br />
<br />
==AVR-spezifisch==<br />
<br />
Die AVR-spezifischen Includes finden sich wie gesagt im Unterverzeichnis <tt>avr</tt>.<br />
Die meisten dort befindlichen Header wird man nie direkt durch Angabe im C-File erhalten,<br />
sondern durch Angabe von<br />
#include <avr/io.h><br />
Dadurch werden z.B. genau die I/O-Header eingebunden, die zum AVR-Modell passen, also<br />
*<tt>avr/iom8.h</tt> für [[ATmega8]], <br />
*<tt>avr/iotn2313.h</tt> für [[ATtiny2313]], <br />
*<tt>avr/io2313.h</tt> für [[AT90S2313]], etc. <br />
<br />
Verantwortlich dafür ist der Schalter '<tt>-mmcu=xxx</tt>'.<br />
<br />
Obwohl diese Header nicht explizit angegeben werden müssen, <br />
kann ein Blick dorthin hilfreich sein, um die Namen von [[SFR|SFRs]] <br />
oder Signals nachzuschlagen. <br />
Diese Header werden im folgenden nicht alle einzeln aufgelistet. <br />
Ihre Namen sind immer <tt>avr/io*.h</tt>.<br />
* für ATmega: <tt>avr/iom*.h</tt> <br />
* für ATtiny: <tt>avr/iotn*.h</tt><br />
<pre><br />
avr/boot.h Bootloader Support<br />
avr/crc16.h [*] Prüfsumme CRC16<br />
avr/delay.h [*] Verzögerungsschleifen für kurze, exakte Verzögerungen<br />
avr/eeprom.h EEPROM-Routinen<br />
avr/ina90.h Kompatibilität mit IAR-AVR-Compiler<br />
avr/interrupt.h sei(), cli(), ...<br />
avr/io.h --> inttypes.h, io*.h<br />
avr/io*.h SFRs, SIG_****, SPM_PAGESIZE, RAMEND, XRAMEND, E2END, FLASHEND<br />
avr/parity.h [*] Parität<br />
avr/pgmspace.h Zugriff aufs Flash: Byte lesen, PROGMEM, prog_char, prog_uint8_t, ...<br />
avr/portpins.h Makros für Port-Pins<br />
avr/signal.h [**] Makros SIGNAL() und INTERRUPT(), ...<br />
avr/sleep.h Power-Safe<br />
avr/twi.h [*] I2C<br />
avr/wdt.h Watchdog<br />
<br />
util/crc16.h Prüfsumme CRC16<br />
util/delay.h Verzögerungsschleifen für kurze, exakte Verzögerungen <br />
util/parity.h Parität<br />
util/twi.h I2C<br />
<br />
[*] bei neueren avr-gcc-Versionen in util<br />
[**] entfällt bei neueren avr-gcc-Versionen. Stattdessen avr/interrupt.h verwenden<br />
</pre><br />
<br />
==Anwendungs-spezifisch==<br />
Eigene Header, die nur innerhalb eigener Projekte gebraucht werden, includet man mit<br />
#include "..."<br />
Auch hier darf man Unterverzeichnisse angeben oder ins übergeordnete Verzeichnis:<br />
#include "../../mein-zeug.h"<br />
<br />
=Optimierungen, Tipps & Tricks=<br />
<br />
Beim Programmieren in C möchte man sich möglichst wenig mit der Codeerzeugung selbst auseinandersetzen. Man verwendet ja gerade deshalb einen Compiler und programmiert nicht in Assembler, weil man sich nicht um Register-Belegungen o.ä. kümmern will, sondern nur um die zu lösende Aufgabe.<br />
<br />
GCC erzeugt zwar recht guten Code, aber er ist nicht perfekt. Gerade auf Systemen wie AVR mit nur sehr begrenzten Resourcen muss man daher dem Compiler hilfreich zur Seite stehen, wenn man noch dichteren/schnelleren Code erhalten möchte.<br />
<br />
:''"Unlike most other C compilers, GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.''<br />
<br />
:''Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs."''<br />
<br />
Um das Ergebnis zu beurteilen, hilft ein Blick ins Listfile. <br />
Siehe dazu auch die Abschnitte <br />
"[[Hallo Welt für AVR (LED blinken)#Listfile erstellen|Listfile erstellen]]" <br />
und<br />
"[[Hallo Welt für AVR (LED blinken)#Die Größe ermitteln|Die Größe ermitteln]]" <br />
im [[Hallo Welt für AVR (LED blinken)|Hallo Welt für AVR]].<br />
<br />
==Optimierungsgrad==<br />
Als Optimierungsgrad erweist sich <tt>-Os</tt> (Optimize for Size) als der beste, evtl. noch <tt>-O2</tt>. Ohne Angabe eines Optimierungsgrades wird nicht optimiert, was gleichbedeutend mit der Option <tt>-O0</tt> ist. Abzuraten ist von der maximalen Optimierung <tt>-O3</tt>, die wegen function inlining und loop unrolling zu sehr breitem Code führt und für AVR absolut nicht angesagt ist.<br />
<br />
==Vermeide printf, scanf, malloc==<br />
Funktionen von diesem Kaliber sind die absoluten Platz- und Zeitfresser. <br />
<br />
Alternativen findet man reichlich in der <tt>avr-libc</tt> wie <tt>itoa</tt> und <tt>atoi</tt>.<br />
Und für <tt>malloc</tt> und Konsorten sind dynamische Arrays und das Compiler-Builtin <tt>__builtin_alloca</tt> effizientere Alternativen, siehe auch im Abschnitt "[[avr-gcc#Dynamische Speicherallokierung|Dynamische Speicherallokierung]]".<br />
<br />
==Konstante Strings ins Flash== <br />
Konstante Strings, wie sie zu Ausgabezwecken Verwendung finden, werden im Programm oft nicht verändert und brauchen nicht SRAM zu belegen (und damit auch Flash, von wo aus sie vom Startup-Code ins SRAM kopiert werden), sondern gehören ins Flash! <br />
<br />
Entsprechende Routinen, um auf Strings im Flash zuzugreifen, tragen die Suffix <tt>_P</tt>, wie z.B. <tt>strcmp_P</tt> mit dem Prototyp<br />
extern int *strcmp_P (char *, const prog_char *)<br />
Die Implementierungen befinden sich in der <tt>avr-libc</tt>.<br />
<br />
'''Anwendung:'''<br />
#include <avr/pgmspace.h><br />
<br />
const prog_char str_p[] = "Ein String im Flash";<br />
const char str2_p[] PROGMEM = "Noch ein String im Flash";<br />
...<br />
{{ccomment|String im SRAM mit String im Flash vergleichen}}<br />
if (!strcmp_P (str_sram, str_p))<br />
{<br />
{{ccomment|mach was bei Gleichheit}}<br />
}<br />
<br />
{{ccomment|"foo" wird im RAM angelegt. Ineffizient für konstante Strings!}} <br />
{{ccomment|Beachte, daß damit strcmp (nicht strcmp_P) benutzt werden muss.}} <br />
if (!strcmp (str_sram, "foo"))<br />
{<br />
{{ccomment|mach was bei Gleichheit}}<br />
}<br />
<br />
{{ccomment|PSTR bewirkt, daß die String-Konstante "foo"}}<br />
{{ccomment|im Flash angelegt wird}}<br />
if (!strcmp_P (str_sram, PSTR ("foo"))<br />
{<br />
{{ccomment|mach was bei Gleichheit}}<br />
}<br />
...<br />
}<br />
<br />
===Sprungtabelle===<br />
Genauso macht man auch eine Sprungtabelle, um anhand von Kommando-Strings dazugehörige Funktionen ausführen zu lassen:<br />
#include <avr/pgmspace.h><br />
<br />
int func1 (int arg)<br />
{<br />
...<br />
}<br />
<br />
#define TEXT_LEN 15<br />
<br />
{{ccomment|Die Kommandostruktur}}<br />
typedef struct <br />
{<br />
int (*func)(int); {{ccomment|Zeiger auf die auszuführende Funktion}}<br />
int arg; {{ccomment|das Argument, das mitübergeben wird}}<br />
char text[1+TEXT_LEN]; {{ccomment|Text, maximal TEXT_LEN Zeichen lang}}<br />
} command_t;<br />
<br />
{{ccomment|Das Array mit den Kommandos.}}<br />
{{ccomment|Die funcx sind vom Prototyp (z.B. func1 oben)}}<br />
{{ccomment|int funcx (int arg);}}<br />
const command_t commands[] PROGMEM =<br />
{<br />
{ func1, 0, "Befehl 1" },<br />
{ func2, 3, "Befehl für func2" }<br />
};<br />
<br />
{{ccomment|Sucht in commands[] nach text und führt gegebenenfalls}}<br />
{{ccomment|die dazugehörige Funktion funcx mit Argument arg aus.}}<br />
{{ccomment|Liefert den Rückgabewert von funcx}}<br />
{{ccomment|oder -1, falls text nicht gefunden wurde.}}<br />
int execute (const char *text)<br />
{<br />
{{ccomment|Schleifenvariable}}<br />
unsigned char i;<br />
<br />
{{ccomment|Wandert durch das Array mit Kommando-Strukturen}}<br />
const command_t * cmd = commands;<br />
<br />
{{ccomment|sizeof wird von gcc ausgewertet und ist wie eine Konstante,}}<br />
{{ccomment|denn beide sizeofs sind zur Compilezeit bekannt}}<br />
for (i=0; i < sizeof(commands) / sizeof(command_t); i++)<br />
{<br />
{{ccomment|Ist das der gesuchte String?}} <br />
if (strcmp_P (text, cmd->text))<br />
{<br />
{{ccomment|Nein, dann weitersuchen}}<br />
cmd++;<br />
continue;<br />
}<br />
<br />
{{ccomment|Ja}}<br />
int (*func)(int), arg;<br />
<br />
{{ccomment|Dann Funktionszeiger und Argument besorgen,}}<br />
func = (int(*)(int)) pgm_read_word (& cmd->func);<br />
arg = (int) pgm_read_word (& cmd->arg);<br />
<br />
{{ccomment|Funktion ausführen und deren Wert zurückliefern}} <br />
return func (arg);<br />
}<br />
<br />
{{ccomment|text ist nicht in commands}}<br />
return -1;<br />
}<br />
<br />
Nachteil dabei ist, daß jeder String den maximalen Platz von <tt>TEXT_LEN+1</tt> Zeichen belegt.<br />
Falls man da noch weiter sparen will, dann kann man die Strings wieder ins Flash legen und ihre Adresse in der Struktur merken. Dadurch belegt ein String nur noch Länge+3 Zeichen (+3 wegen 1 Endezeichen und 2 Bytes für seine in der Struktur gemerkte Adresse). Die Definition der Tabelle wird aber umständlicher, weil jeder String einzeln angegeben werden muss:<br />
#include <avr/pgmspace.h><br />
<br />
{{ccomment|Die Kommandostruktur}}<br />
typedef struct <br />
{<br />
...<br />
char * text; {{ccomment|Zeiger auf Text}}<br />
} command_t;<br />
<br />
const prog_char str_1[] = "Befehl 1";<br />
const prog_char str_2[] = "Befehl für func2";<br />
<br />
const command_t commands[] PROGMEM =<br />
{<br />
{ func1, 0, str_1 },<br />
{ func2, 3, str_2 }<br />
};<br />
<br />
{{ccomment|Sucht in commands[] nach text und führt gegebenenfalls}}<br />
{{ccomment|die dazugehörige Funktion funcx mit Argument arg aus.}}<br />
{{ccomment|Liefert den Rückgabewert von funcx}}<br />
{{ccomment|oder -1, falls text nicht gefunden wurde.}}<br />
int execute (const char *text)<br />
{<br />
{{ccomment|Schleifenvariable}}<br />
unsigned char i;<br />
<br />
{{ccomment|Wandert durch das Array mit Kommando-Strukturen}}<br />
const command_t * cmd = commands;<br />
<br />
{{ccomment|sizeof wird von gcc ausgewertet und ist wie eine Konstante,}}<br />
{{ccomment|denn beide sizeofs sind zur Compilezeit bekannt}}<br />
for (i=0; i < sizeof(commands) / sizeof (command_t); i++)<br />
{<br />
const prog_char * text_P;<br />
<br />
{{ccomment|Liest die Startadresse von str_x}}<br />
text_P = (const prog_char *) pgm_read_word (& cmd->text);<br />
<br />
{{ccomment|Ist das der gesuchte String?}} <br />
if (strcmp_P (text, text_P))<br />
{<br />
...<br />
<br />
==Lokale Variablen verwenden==<br />
<br />
Beim Manipulieren globaler Variablen kann es günstig sein, diese in eine lokale Variable zu kopieren, dort zu verändern, und sie danach wieder zu schreiben <br />
<pre><br />
char var;<br />
<br />
void foo1()<br />
{<br />
var++;<br />
if (var > 10)<br />
var = 1;<br />
} <br />
</pre><br />
Dadurch wird einmal unnötig gespeichert (der dritte Befehl kann vermieden werden).<br />
<pre><br />
foo1:<br />
lds r24,var ; *movqi/4 [length = 2]<br />
subi r24,lo8(-(1)) ; addqi3/2 [length = 1]<br />
sts var,r24 ; *movqi/3 [length = 2]<br />
cpi r24,lo8(11) ; cmpqi/2 [length = 1]<br />
brlt .L3 ; branch [length = 1]<br />
ldi r24,lo8(1) ; *movqi/2 [length = 1]<br />
sts var,r24 ; *movqi/3 [length = 2]<br />
.L3:<br />
ret <br />
</pre><br />
Indem man eine lokale Variable (<tt>var2</tt>) verwendet für die Änderung von <tt>var</tt> vermeidet man dies:<br />
<pre><br />
char var;<br />
<br />
void foo2()<br />
{<br />
char var2 = var;<br />
<br />
var2++;<br />
if (var2 > 10)<br />
var2 = 1;<br />
<br />
var = var2;<br />
} <br />
</pre><br />
Dadurch wird erst am Ende gespeichert. <tt>var2</tt> lebt in Register <tt>r24</tt>.<br />
<pre><br />
foo2:<br />
lds r24, var ; *movqi/4 [length = 2]<br />
subi r24,lo8(-(1)) ; addqi3/2 [length = 1]<br />
cpi r24,lo8(11) ; cmpqi/2 [length = 1]<br />
brlt .L2 ; branch [length = 1]<br />
ldi r24,lo8(1) ; *movqi/2 [length = 1]<br />
.L2:<br />
sts var, r24 ; *movqi/3 [length = 2]<br />
ret<br />
</pre><br />
<br />
Bei diesem einfachen Beispiel spart man lediglich eine Instruktion. Bei komplexeren Rechnungen oder längeren Datentypen kann es aber durchaus lohnender sein, in lokale Register zu kopieren.<br />
<br />
==Arithmetik==<br />
<br />
=== Daten zerlegen/zusammensetzen ===<br />
<br />
In systemnahen Programmen hat man oft was Problem, auf die einzelnen Bytes oder Bitfelder einer grösseren Datenstruktur zuzugreifen. Indem man sich ein Komposit baut, das die gewünschten Strukturen überlagert, kann man effizient z.B. auf Bytes zugreifen. Ausnahme sind Bitfelder, deren Verwendung etwas breiten Code ergibt. Bitfelder "von Hand" zu manipulieren, ist da manchmal effizienter, führt jedoch zu schlecht lesbarem Code.<br />
<br />
Oft benötigt wird der Zugriff auf die einzelnen Bytes eines <tt>int</tt>, also der Zugriff auf die Bytes eines 16-Bit-Wertes:<br />
<br />
typedef union<br />
{<br />
unsigned char asByte[2];<br />
unsigned short asWord;<br />
int asInt;<br />
} data16_t;<br />
<br />
data16_t data;<br />
...<br />
int foo;<br />
uint8_t wert;<br />
<br />
data.asInt = foo;<br />
wert = data.asByte[1]; {{ccomment|die oberen 8 Bits von foo}}<br />
<br />
Ein komplexeres Beispiel, das noch mehr Datentypen überlagert:<br />
typedef ... foo_t;<br />
<br />
typedef union<br />
{<br />
unsigned char byte[4]; {{ccomment| Zugriff als Bytes (8 Bit) }}<br />
unsigned short word[2]; {{ccomment| Zugriff als Words (16 Bit) }}<br />
signed long slong; {{ccomment| Zugriff als signed long (32 Bit) }}<br />
<br />
struct {{ccomment| Zugriff auf einzelne Bitgruppen }}<br />
{<br />
unsigned bit_0_3 : 4; {{ccomment| 4 Bits (0..3) }}<br />
unsigned bit_4_8 : 5; {{ccomment| 5 Bits (4..8) }}<br />
unsigned bit_9_21 : 13; {{ccomment| 13 Bits (9..21) }}<br />
unsigned bit_22_31: 10; {{ccomment| 10 Bits (22..31) }}<br />
};<br />
<br />
foo_t foo; {{ccomment| Zugriff als foo-Struktur }}<br />
} data_t;<br />
<br />
...<br />
{<br />
data_t data;<br />
<br />
data.byte[2] = 12; {{ccomment| setzt byte 2 auf 12 }}<br />
data.bit_4_8 = 0x1f; {{ccomment| setzt bits 4..8 (5 Stück) alle auf 1 }}<br />
<br />
int anInt = data.foo.anInt; {{ccomment| liest ein Feld von foo (hier ein int) }}<br />
...<br />
}<br />
<br />
===libgcc2 verwenden===<br />
<br />
In der libgcc2 sind einige Arithmetik-Routinen in Assembler implementiert. Dazu gehören ein paar Algorithmen zu Division (mit Rest) und Multiplikation. <br />
<br />
Von diesen Algorithmen werden durch die avr-libc jedoch nur zwei Strukturen und Funktionen veröffentlicht: <tt>div_t</tt> und <tt>ldiv_t</tt> resp. die Funktionen <tt>div()</tt> und <tt>ldiv()</tt>. Siehe dazu deine Dokumentation zur avr-libc. Damit kann man Quotient und zusätzlich den Rest bei einer Division 16/16 bzw. 32/32 berechnen lassen; den Rest bekommt man quasi kostenlos als Nebenprodukt. Das ist praktisch, wenn man z.b. eine Zahl in Dezimaldarstellung umwandeln möchte oder von/nach [[BCD]].<br />
<br />
Zusätzlich zu den via avr-libc veröffentlichten Funktionen gibt es aber noch Routinen, die z.B. auf 8-Bit-Werten operieren oder mit <tt>unsigned</tt> Typen und dementsprechend effizienter sind.<br />
<br />
'''Beispiel: Umwandeln nach Dezimalstring'''<br />
<br />
Hier ein Beispiel, das Division mit Rest für <tt>unsigned short</tt> verwendet, um eine 16-Bit-Zahl in Dezimaldarstellung zu wandeln:<br />
<br />
{{ccomment| Struktur definieren und Funktion bekannt machen }}<br />
typedef struct<br />
{<br />
unsigned short quot;<br />
unsigned short rem;<br />
} udiv_t;<br />
<br />
extern udiv_t udiv (unsigned short, unsigned short) __asm__("__udivmodhi4");<br />
<br />
{{ccomment| 5 Ziffern (0...65535) und evtl. noch eine führende 0 }}<br />
#define DIGITS 6<br />
<br />
{{ccomment| +1 wegen String-Ende (wird im Startup auf 0 gesetzt) }}<br />
char string[DIGITS+1];<br />
<br />
{{ccomment| Wandelt zahl in Dezimaldarstellung um. }}<br />
{{ccomment| Der return-Wert zeigt irgendwo ins string[]-Array. }}<br />
{{ccomment| string[] wird verändert. }}<br />
char* toString (unsigned short zahl)<br />
{<br />
{{ccomment| s zeigt auf das Ende von string }}<br />
{{ccomment| string wird von hinten nach vorne gefüllt }}<br />
char *s = string + DIGITS;<br />
<br />
{{ccomment| qrem enthält Quotient (quot) und Rest (rem) der Divisionen }}<br />
udiv_t qrem = {.quot = zahl}; <br />
<br />
do<br />
{<br />
{{ccomment| Division mit Rest durch 10 }}<br />
{{ccomment| quot: Ergebnis für den nächsten Durchlauf }}<br />
{{ccomment| rem: Rest ist die Ziffer im 10er-System }}<br />
qrem = udiv (qrem.quot, 10);<br />
<br />
{{ccomment| Ziffer in Zeichen wandeln und speichern }}<br />
*(--s) = '0' + qrem.rem;<br />
} <br />
while (0 != qrem.quot);<br />
<br />
{{ccomment| Falls eine führende '0' gespeichert wurde: weg damit }}<br />
{{ccomment| ausser zahl war selbst schon 0 }}<br />
if (*s == '0' && *(s+1) != '\0')<br />
s++;<br />
<br />
return s;<br />
}<br />
<br />
Falls man eine Division und/oder Rest für 8-Bit braucht, dann geht für <tt>unsigned</tt> analog. <br />
<br />
'''Beispiel: BCD-Umrechnung'''<br />
<br />
Wandeln einer 8-Bit-Zahl <tt>0 &lt;= num &lt; 100</tt> nach [[BCD]]<br />
<br />
typedef struct<br />
{<br />
unsigned char quot; {{ccomment| Quotient }}<br />
unsigned char rem; {{ccomment| Rest (remainder) }}<br />
} udiv8_t;<br />
<br />
extern udiv8_t udiv8 (unsigned char, unsigned char) __asm__ ("__udivmodqi4");<br />
<br />
{{ccomment| Wandelt num nach BCD um, 0 <&#61; num <&#61; 99 }}<br />
{{ccomment| return-Wert ist dann 0x0 <&#61; return <&#61; 0x99 }}<br />
unsigned char to_bcd (unsigned char num)<br />
{<br />
udiv8_t qrem = udiv8 (num, 10);<br />
<br />
return (unsigned char) (qrem.quot << 4) | qrem.rem;<br />
}<br />
<br />
===Division durch Multiplikation===<br />
===Vermeiden von float und double===<br />
<br />
=Inkompatibilität=<br />
<br />
[[GCC]] &ndash; und somit auch avr-gcc &ndash; werden ständig weiter entwickelt. Dies betrifft das Beheben von Fehlern, die Unterstützung neuer Architekturen/Sprachen/Betriebssysteme, Implementierung neuer Optimierungsalgorithmen, Vereinheitlichungen, etc.<br />
<br />
Leider führt dies auch zu Inkompatibilitäten verschiedener avr-gcc-Versionen untereinander, und eine C-Quelle, die mit einer Version von avr-gcc fehler- und warnungsfrei übersetzt werden kann, ist mit einer anderen Version möglicherweise nicht compilierbar.<br />
<br />
Die avr-gcc Version kann man anzeigen lassen, indem man in einer Shell/Eingabeaufforderung eintippt<br />
avr-gcc -v<br />
<br />
;<tt>#include <avr/signal.h></tt>: In Versionen bis 3.4.4 werden in dieser Header-Datei u.a. die Makros <tt>SIGNAL()</tt> und <tt>INTERRUPT()</tt> definiert, die man braucht, wenn man eine C-Funktion als Interrupt-Routine ([[ISR]]) kennzeichnen will. In neueren Versionen ab 3.4.5 sind diese Definitionen in den Header <tt>avr/interrupt.h</tt> gewandert, wo auch Makros wie <tt>sei()</tt> und <tt>cli()</tt> definiert werden. Die Inkludierung von <tt>avr/signal.h</tt> in den neueren avg-gcc Versionen führt zu einer Warnung, irgendwann vielleicht sogar zu einem Fehler, weil die Datei nicht mehr bei avr-gcc dabei ist und daher nicht mehr gefunden wird.<br />
: '''Verwendet man bei einer älteren avr-gcc-Version <tt>SIGNAL</tt> bzw. <tt>INTERRUPT</tt> ohne <tt>avr/signal.h</tt> zu includen, wird u.U. stillschweigend falscher Code erzeugt.'''<br />
<br />
;<tt>#include <util/...h></tt>: In <tt>util</tt> stehen jetzt Header wie <tt>util/parity.h</tt> oder das vielverwendete <tt>util/delay.h</tt>, die vormals im Include-Unterverzeichnis <tt>avr</tt> zu finden waren.<br />
<br />
;Interrupt Service Routinen: Auch die API zur Definition von [[ISR]]s hat sich von avr-gcc Version 3.x zur Version 4.x geändert:<br />
:'''avr-gcc 3.x'''<br />
::{|<br />
<pre><br />
SIGNAL (SIG_INTERRUPT0)<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
INTERRUPT (SIG_OVERFLOW0)<br />
{<br />
/* Interrupt Code */<br />
}<br />
</pre><br />
|}<br />
<br />
:'''avr-gcc 4.x'''<br />
::{|<br />
<pre><br />
ISR (INT0_vect)<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
void TIMER0_OVF_vect (void) __attribute__((interrupt));<br />
void TIMER0_OVF_vect (void)<br />
{<br />
/* Interrupt Code */<br />
}<br />
</pre><br />
|}<br />
<br />
=Bugs=<br />
<br />
==== Bit 7 bei SFR-Zugriff ====<br />
<br />
Bei Sequenzen wie<br />
PORTB &= ~ (1 << 7);<br />
PORTD &= ~ (1 << 7);<br />
<br />
macht avr-gcc eine CSE-Optimierung (common subexpression elimination). Er legt die Konstante 127 (<tt>~(1 << 7)</tt>) in ein Register und verwendet den Registerinhalt, anstatt die Konstante direkt zu verwenden.<br />
<br />
Das führt dazu, daß statt der gewünschten Befehlsfolge<br />
; Sequenz 1<br />
cbi 37-0x20, 7 <br />
cbi 43-0x20, 7<br />
Sequenzen folgender Gestalt erzeugt werden:<br />
; Sequenz 2<br />
ldi r18, lo8(127) ; 127 nach R18<br />
<br />
in r19, 37-0x20 ; PORTB nach R19 lesen<br />
; Wird hier eine ISR ausgeführt, die PORTB verändert, dann wird die<br />
; Änderung mit dem folgenden OUT überschrieben<br />
and r19, r18 ; oberstes Bit löschen<br />
; dito<br />
out 37-0x20, r19 ; PORTB schreiben<br />
<br />
in r19, 43-0x20 ; analog<br />
and r19, r18 <br />
out 43-0x20, r19 <br />
<br />
Abgesehen davon, daß Sequenz&nbsp;2 deutlich mehr Programmspeicher und Laufzeit benötigt als Sequenz&nbsp;1, kann es zu folgendem Fehler kommen:<br />
<br />
Bei der zweiten Codesequenz erfolgt der Zugriff auf die SFRs nicht atomar. Wird der C-Code in einem Programm ausgeführt, das in einer [[ISR]] zB Port B3 verändert und wird diese ISR zwischen dem IN und dem OUT Befehl ausgeführt, dann überschreibt der OUT-Befehl den Wert von PORTB und die Aktion für Port B3 in der ISR wird wieder rückgängig gemacht. Das ist dann ein Programmfehler.<br />
<br />
Damit das Problem zum Tragen kommt, müssen mehrere Bedingungen erfüllt sein:<br />
* Bei mindestens zwei C-Befehlen wird der Wert 127 als 8-Bit-Wert benötigt. Das ist zB auch der Fall, wenn dieser Wert nur gespeichert wird oder modulo 0x80 gerechnet wird.<br />
* Mindestens einer dieser Befehle löscht Bit 7 eines SFR aus dem bitadressierbaren I/O-Bereich. (Ausser PORTx oder DDRx sind in diesem Bereich noch weitere SFR untergebracht.)<br />
* Im Programm wird auf unterschiedlichen [[Interrupt]]-Ebenen auf dieses SFR zugegriffen und die oben gezeigt Stelle kann von der ISR unterbrochen werden.<br />
* Die beiden C-Befehle müssen nicht unmittelbar aufeinander folgen. Es können auch andere C-Befehle dazwischen stehen. <br />
<br />
Bei den meisten Programmen wird das angesprochene Problem nicht zu einem Fehler führen. Falls doch, kann man dem begegnen mit folgenden <br />
<br />
;Workarounds:<br />
* Die C-Stelle wird in CLI/SEI eingeschlossen und kann damit nicht mehr von einer ISR unterbrochen werden.<br />
* Alternativ schreibt man vor und nach jedem problematischen SFR-Zugriff folgendes Kommando:<br />
:{|<br />
|-<br />
|<br />
__asm volatile (""::);<br />
|}<br />
:Dieses Kommando erzeugt keine Assembler-Instruktionen, vermeidet aber die unerwünschte "Optimierung" im gcc, und es entsteht Code gemäß Sequenz&nbsp;1.<br />
* Alternativ definiert man sich ein Makro, mit dem man die Portzugriffe tätigt:<br />
:{|<br />
|-<br />
|<br />
#define CBI(A,B) __asm volatile ("cbi\t%0, %1" :: "M" (_SFR_IO_ADDR(A)), "M" (B))<br />
|}<br />
:Und löscht das Bit mit<br />
:{|<br />
|-<br />
|<br />
CBI (PORTB, 7);<br />
|}<br />
<br />
==== <tt>__builtin_return_address(0)</tt> ====<br />
ist entgegen der Spezifikation nicht implementiert und liefert in der Regel ein falsches Ergebnis.<br />
<br />
;Workaround:<br />
<br />
(hier für eine ISR):<br />
#include <stdarg.h><br />
#include <avr/interrupt.h><br />
<br />
{{ccomment|The return address}}<br />
unsigned short volatile return_addr;<br />
<br />
{{ccomment|Define our special SIGNAL (INTERRUPT analoguous)}}<br />
#define SIGNAL_BRA(signame,var) \<br />
void signame (unsigned short var, ...) __attribute__ ((signal)); \<br />
void signame (unsigned short var, ...)<br />
<br />
#define SWAP_BYTES(x) (((x) >> 8) | ((x) << 8))<br />
<br />
SIGNAL_BRA (SIG_OUTPUT_COMPARE1A, dummy)<br />
{<br />
{<br />
va_list vlist;<br />
va_start (vlist, dummy);<br />
<br />
{{ccomment|Get the return address from the stack}}<br />
dummy = va_arg (vlist, unsigned short);<br />
<br />
{{ccomment|Convert stack address to code location}}<br />
addr = SWAP_BYTES(dummy) << 1;<br />
va_end (vlist);<br />
}<br />
{{ccomment|ISR Code}}<br />
}<br />
<br />
<br />
==== gcc 4.x ==== <br />
<br />
In der 4er-Version gab es tiefgreifende interne Änderungen im Compiler; er ist noch instabil und kann momentan nicht für den Produktiv-Einsatz empfohlen werden (Stand 02/2006). <br />
<br />
Die Auswirkungen der Optimierungen auf das Zielsystem <tt>avr</tt> bleibt abzuwarten, dürfte aber nicht wesentlich sein. Die neue 4-er Version wurde u.a. deshalb aufgelegt, um mit dem Intel-Compiler gleichzuziehen &ndash; also im Hinblick auf das Zielsystem <tt>i386</tt>) gemacht. <br />
<br />
Auch nach dem Release der 4-er Version wird die 3-er Version weiterentwickelt, da erst nach 1-2 Jahren nach Release einer neuer Major-Version ein Umstieg anzuraten ist und auch erst dann getätigt wird (zumindest im professionellen Bereich).<br />
<br />
=Abkürzungen und Bezeichnungen=<br />
; [[GCC]]: GNU Compiler Collection<br />
; gcc: GNU C-Compiler<br />
; GPR: '''G'''eneral '''P'''urpose '''R'''egister<br />
; [[ISR]]: [[Interrupt|'''I'''nterrupt]] '''S'''ervice '''R'''outine<br />
; [[IRQ]]: '''I'''nterrupt '''R'''e'''q'''uest<br />
; Prolog/Epilog: Code am Anfang/Ende jeder Funktionen/ISR, der dazu dient, verwendete Register zu sichern, den Stack-Frame für lokale [[Variable|Variablen]] anzulegen (falls benötigt), Stackpointer zu setzen, zurück zu springen (<tt>ret</tt>, <tt>reti</tt>), etc.<br />
; SFR: '''S'''pecial '''F'''unction '''R'''egister<br />
; Target: Zielsystem, in unserem Falle avr<br />
<br />
=Siehe auch=<br />
* [[C-Tutorial]]<br />
'''Code-Beispiele'''<br />
* [[Hallo Welt für AVR (LED blinken)]] - ein erstes Beispiel für avr-gcc<br />
*[[:Kategorie:Quellcode_C|C-Codebeispiele]]<br />
* [[Fallstricke bei der C-Programmierung]]<br />
<br />
'''Details'''<br />
* [[Inline-Assembler in avr-gcc|Inline-Assembler]]<br />
* [[avr-gcc/Interna|Interna von avr-gcc]]<br />
<br />
'''Installation (Linux)'''<br />
* [[Linuxdistribution_Avr-live-cd]]<br />
* [[avr-gcc und avrdude installieren]]<br />
'''Sonstiges'''<br />
* [[WinAVR]]<br />
* [[Speicherverbrauch bestimmen mit avr-gcc]]<br />
* [[Compiler]]<br />
* [[Dev-Cpp IDE]]<br />
* [[AVR]]<br />
----<br />
* [[Sourcevergleich]]<br />
* [[Codevergleich AVR-Compiler]]<br />
<br />
=Weblinks=<br />
==Dokumentation==<br />
* [http://gcc.gnu.org/onlinedocs/ GCC online documentation (en)] Offline findest du die Doku für gcc, cpp (Präprozessor) und avr-libc bei [[WinAVR]] in<br />
:<pre><GCC_HOME>/doc/gcc/</pre><br />
: bzw.<br />
:<pre><GCC_HOME>/doc/avr-libc/</pre><br />
:Online finden sich die Dokumente in<br />
* [http://gcc.gnu.org/onlinedocs/gcc.pdf gcc.pdf (1900 kByte)] - Dokumentation des C/C++/Java-Compilers GCC (en)<br />
* [http://gcc.gnu.org/onlinedocs/cpp.pdf cpp.pdf (470 kByte)] - Dokumentation des C-Präprozessors (en)<br />
* [http://www.nongnu.org/avr-libc/user-manual/modules.html http://www.nongnu.org/avr-libc/user-manual] - Dokumentation zur avr-libc.<br />
<br />
== Downloads==<br />
* [http://sourceforge.net/projects/winavr/ WinAVR-Projekt bei sourceforge.net (en)]<br />
* [http://cdk4avr.sourceforge.net/ avr-gcc und toolchain als Linux-Paket bei sourceforge.net (en)]<br />
* [[Linuxdistribution_Avr-live-cd]]<br />
== Tipps, Installation ==<br />
*[http://www.nongnu.org/avr-libc/user-manual/install_tools.html ''"Installing the GNU Tool Chain"''] Hilfe zum Build und Installation von GCC, binutils, etc unter Linux<br />
* Im GCC-Handbuch, siehe [[#Dokumentation|Dokumentation]].<br />
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml www.linuxfocus.org (Artikel)] - Tipps zu Build und Installation von avr-gcc, binutils und avr-libc unter Linux<br />
* [http://users.rcn.com/rneswold/avr/ Rich Neswold: ''A GNU Development Environment for the AVR Microcontroller'']<br />
* [http://www.mikrocontroller.net/topic/24166 www.mikrocontroller.net (Foren-Beitrag)] - Installation von GCC und Toolchain unter Mac OS X<br />
* [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=125603#125603 www.roboternetz.de (Foren-Beitrag)] ''avrgcc + avrdude installieren''<br />
<br />
== Sonstiges ==<br />
* [http://gcc.gnu.org/ Offizielle Homepage von GCC (en)]<br />
* [http://de.wikipedia.org/wiki/GNU_Compiler_Collection GCC in der deutschen Wikipedia]<br />
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial avr-gcc-Tutorial auf mikrocontroller.net]<br />
* [http://www.avrfreaks.net/AVRGCC/ avr-gcc bei avrfreaks.net (en)]<br />
* [http://savannah.nongnu.org/projects/avr-libc/ Nützliche GCC Runtime-Libary]<br />
<br />
=Autor=<br />
<br />
--[[Benutzer:SprinterSB|SprinterSB]] 11:27, 7. Dez 2005 (CET)<br />
<br />
[[Kategorie:Grundlagen]]<br />
[[Kategorie:Microcontroller]]<br />
[[Kategorie:Praxis]]<br />
[[Kategorie:Quellcode C|!]]<br />
[[Kategorie:Software]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Avr&diff=10343Avr2007-03-03T06:40:59Z<p>Overthere: </p>
<hr />
<div>[[Bild:AtmelController.jpg|thumb|Beispiel eines AVR Controllers]]<br />
'''AVR''' ist eine 8-Bit [[Microcontroller]]-Familie mit RISC-Architektur.<br />
Im Gegensatz zu vielen anderen Microcontroller-Architekturen hat die AVR-Architektur keine Vorgänger. Sie ist ein komplettes Neudesign, das Anfang der 90-Jahre an der Universität von Trondheim/Norwegen entwickelt und vom (bis heute einzigen) Hersteller [[Atmel]] aufgekauft wurde. Es gibt eine ganze Serie von AVR-Controllern. Sie alle werden ähnlich programmiert, haben vergleichbaren Befehlssatz und physikalische Eigenschaften, bieten jedoch unterschiedliche Features und Peripherie. <br />
<br />
Es gibt zahlreiche und kostenlose Entwicklungssysteme in den Sprachen Basic, C/C++, Pascal und Assembler für diese Controller-Familie. <br />
<br />
== Wofür steht AVR? ==<br />
"AVR" steht angeblich für ''Advanced Virtual RISC'' (in einem Paper der Entwickler des AVR-Kerns Alf Egin Bogen und Vegard Wollan). Laut [[Atmel]] bedeutet es nichts.<br />
<br />
== Hardware ==<br />
AVR-Controller besitzen eine zweistufige Pipeline (fetch and execute), die es ermöglicht, die meisten Befehle innerhalb eines einzigen Prozessortaktes auszuführen. Dadurch ist ein AVR wesentlich schneller als etwa 8051-Controller, bei denen der Prozessortakt intern noch durch 12 geteilt wird.<br />
<br />
*AVR-Kern<br />
** Harvard-Architektur (getrennter Befehls- und Datenspeicher) <br />
** 32 Register, kein Akkumulator, 3 Pointerregister <br />
** EEPROM-Datenspeicher<br />
** [[Watchdog]], [[Bootloader]]-Support, verschiedene Stromspar-Modi, Brownout-Erkennung, Interner Oszillator<br />
** Lineares Speichermodell (keine Segmentierung)<br />
** 8-Bit Architektur ist für Hochsprachen (C) optimiert <br />
* In-System programmierbar: die Controller können sehr einfach über ein Programmierkabel (oft ISP-Kabel genannt), das mit dem PC verbunden wird, programmiert werden &ndash; auch dann, wenn sie sich nicht in einer Schaltung befindet.<br />
* umfangreiche Peripherie<br />
** 8- und 16-Bit-Timer/Counter mit [[PWM]], Capture/Compare, externe Betaktung, asynchrone Operation<br />
** Kommunikation: [[UART|USART]], [[SPI]], [[I2C]] ([[TWI]])<br />
** Analog-Comparator, Analog-Digital-Wandler <br />
** unterschiedlichste externe und interne Interrupt-Quellen (UART, SPI, Timer, A/D-Wandler, Analog-Comparator, ...)<br />
** JTAG (Debugerinterface)<br />
* AVR Typen (AT90 "Classic AVR", ATtiny, ATmega) <br />
* erhältlich in unterschiedlichen Gehäusen, idR Durchsteck und als [[SMD]]<br />
* Viele Entwicklungsboards erhältlich, z.B. das Roboternetzboard [[RN-Control]]<br />
<br />
==Einige Pinbelegungen der populärsten AVR-Controller==<br />
(in etwa nach Leistungsfähigkeit sortiert)<br />
<br />
* [[AT90S2313]]<br />
<br />
[[Bild:at90s2313tiny.png|center]]<br />
<br />
<br />
* [[Atmel Controller Mega8]]<br />
* [[Atmel Controller Mega48 Mega88 Mega168]]<br />
<br />
[[Bild:mega8kompatibel.png|center]]<br />
<br />
* [[Atmel Controller Mega16 und Mega32]]<br />
<br />
[[Bild:Mega1632.gif|center]]<br />
<br />
<br />
* [[Atmel Controller Mega128]] ([[SMD]]-Chip)<br />
<br />
[[Bild:mega128pin.gif|center]]<br />
<br />
<br />
----<br />
<br />
=== Die AVR-Pin-Bezeichnungen und deren Funktion ===<br />
Die meisten Ports sind doppelt belegt und besitzen neben der normalen Port-Funktion noch eine Sonderfunktion. Die verschiedenen Pinbezeichnungen und Sonderfunktionen werden hier beschrieben:<br />
<br />
{| {{Blauetabelle}}<br />
|+ '''Tabelle: Die AVR-Pin-Bezeichnungen und deren Funktion'''<br />
<!-------------------------------------------------------------------------------------><br />
|- {{Hintergrund1}}<br />
! colspan="2"| Versorgungs- und Referenzpins, Reset<br />
|-<br />
|'''[[VCC]]''' <br />
| Versorgungsspannung von 2,7 Volt bis 6 V bei den L-Varianten (low power), ansonsten 4,5V bis 6V. Die nächste AVR-Generation soll ab 1,8 Volt funktionieren.<br />
|-<br />
|'''[[GND]]''' <br />
|Masse <br />
|-<br />
|'''AREF''' <br />
|Referenzspannung für den Analog-Digital-Wandler (kann auf 5V gesetzt werden). Auch die interne Bandgap-Referenzspannung kann über diesen Pin entstört werden (dann KEINE externe Spannung an diesen Pin geben (Kurzschluss)!). <br />
|-<br />
|'''AGND''' <br />
|Alternative Masse, etwa um ein Verbindungspunkt mit GND zu haben und bei empfindlichen Messungen Masseschleifen zu vermeiden.<br />
|-<br />
|'''AVCC''' <br />
| <br />
Die Betriebsspannung für den Analog-Digital-Wandler (siehe Beschaltungsskizze). Die Pins AVCC, AGND und AREF sollten immer beschaltet werden, da es sonst passieren kann, dass Port A nicht richtig funktioniert, selbst wenn man den AD-Wandler nicht benutzt. <br />
|-<br />
|'''RESET''' <br />
|Rücksetz-Eingang, intern über einen [[Pullup]] mit VCC verbunden. Ein LOW–Pegel an diesem Pin für die Dauer von mindestens zwei Zyklen des Systemtaktes bei aktivem Oszillator setzt den Controller zurück. Rücksetzen der Ports erfolgt unabhängig von einem evtl. anliegenden Systemtakt.<br />
|-<br />
|'''PEN'''<br />
|Programming Enable - Diesen Pin gibt es nur beim Mega128/64 u.ä. Wird dieser Pin beim Power-On Reset nach Masse gezogen, geht der Controller in den [[ISP]] Programmiermodus. Man kann ihn also alternativ zu Reset verwenden. In der Regel verwendet man aber die Reset-Leitung und PEN sollte man direkt mit VCC verbinden.<br />
<!-------------------------------------------------------------------------------------><br />
|- {{Hintergrund1}}<br />
! colspan="2"| System-Takt<br />
|-<br />
|'''XTAL1''' <br />
|Eingang des internen Oszillators zur Erzeugung des Systemtaktes bzw. Eingang für ein externes Taktsignal, wenn der interne Oszillator nicht verwendet werden soll bzw. Anschluss von Quarz/Keramik-Resonator/RC-Glied.<br />
|-<br />
|'''XTAL2''' <br />
|Anschluss von Quarz oder Keramik-Resonator oder Ausgang des integrierten Oszillators zur Nutzung als Systemtakt (Je nach Fuse-Einstellungen). <br />
<!-------------------------------------------------------------------------------------><br />
|- {{Hintergrund1}}<br />
! colspan="2"| Digitale bidirektionale I/O-Ports<br />
|- <br />
| colspan="2"| Jeder Pin der Ports kann individuell als Eingang oder Ausgang konfiguriert werden. Die I/O-Ports sind maximal 8 Bit breit und verfügen ja nach AVR-Typ über eine unterschiedliche Anzahl von Pins. An jedem als Eingang (Input) geschalteten Pin gibt es zuschaltbare [[Pullup]]-Widerstände, die teilweise auch bei aktivierter Sonderfunkton verfügbar sind.<br />
<br />
Bei eingeschalteten Sonderfunktionen wie UART, SPI, ADC, etc. sind die entsprechenden Pins nicht als "normale" digitale I/O verwendbar, sondern dienen der Sonderfunktion. Die Anzahl der als I/O verwendbaren Pins ist auch abhängig von den Fuse-Einstellungen (Vorsicht beim Umstellen, Handbuch GENAU lesen!).<br />
|-<br />
|'''PA 0 – 7''' || Port A <br />
|-<br />
|'''PB 0 – 7''' || Port B <br />
|-<br />
|'''PC 0 – 7''' || Port C <br />
|-<br />
|'''PD 0 – 7''' || Port D <br />
|-<br />
|'''PE 0 – 7''' || Port E <br />
|-<br />
|'''PF 0 – 7''' || Port F <br />
|-<br />
|'''PG 0 – 7''' || Port G <br />
<!-------------------------------------------------------------------------------------><br />
|- {{Hintergrund1}}<br />
! colspan="2"| Externe Interrupts<br />
|- <br />
| colspan="2"| Die PCINT-Interrupts gibt es nur für neuere AVRs wie den [[ATmega88]]. Falls die Anzahl an externen Interrupts nicht ausreicht, kann evtl. auch andere Hardware dafür eingesetzt werden, etwa der Analog-Comparator mit interner Bandgap-Referenz, falls er anderwärtig nicht gebraucht wird.<br />
|-<br />
|'''INT0''' ||Externer Interrupt 0<br />
|-<br />
|'''INT1''' ||Externer Interrupt 1<br />
|-<br />
|'''INT2''' ||Externer Interrupt 2 <br />
|-<br />
|'''PCINTx''' ||Pin-Change Interrupt<br />
<!-------------------------------------------------------------------------------------><br />
|- {{Hintergrund1}}<br />
! colspan="2"| [[Timer]] und [[PWM]]<br />
|-<br />
|'''T0''' <br />
|Timer-Eingang. Timer kann gestartet, gestoppt oder getaktet werden <br />
|-<br />
|'''T1''' <br />
|Timer-Eingang. Timer kann gestartet, gestoppt oder getaktet werden <br />
|-<br />
|'''OC0''' <br />
|PWM bzw. Output Compare Ausgang des Timers 0 <br />
|-<br />
|'''OC1A''' <br />
|Ausgang für die Compare-Funktion des integrierten Zeitgeber- / Zählerbausteines <br />
Der erste PWM-Ausgang des Timers1. Er kann zum Regeln der Bot-Motogeschwindigkeit benutzt werden. <br />
|-<br />
|'''OC1B''' <br />
|Ausgang für die Compare-Funktion des integrierten Zeitgeber- / Zählerbausteines <br />
Der zweite PWM-Ausgang des Timers1. Er kann zum Regeln der Bot-Motogeschwindigkeit benutzt werden. <br />
|-<br />
|'''ICP1''' <br />
|Eingang für die Capture-Funktion des integrierten Zeitgebers / Zählerbausteines <br />
|-<br />
|'''OC2''' <br />
|[[Pwm]] bzw. Output Compare Ausgang des Timers2. Er kann zum Regeln der Bot-Motogeschwindigkeit benutzt werden. <br />
|-<br />
|'''TOSC1, TOSC2''' <br />
|TOSC1 und TOSC2 sind Eingänge für den asynchronen Modus von Timer2. Sie sind vorgesehen für den Anschluss eines externen Uhrenquarzes ( 32.768 kHz ). Damit lassen sich zum Beispiel sehr genaue Ein-Sekunden-Impulse für eine Uhr generien. <br />
<!-------------------------------------------------------------------------------------><br />
|- {{Hintergrund1}}<br />
! colspan="2"| Analog-Digital-Wandler<br />
|-<br />
|'''ADC0''' bis '''ADC7''' <br />
|Eingänge des AD-Wandlers. Spannungen können hier gemessen werden oder an den Analog-Komparator weiter geleitet werden. <br />
<!-------------------------------------------------------------------------------------><br />
|- {{Hintergrund1}}<br />
! colspan="2"| Analog-Komparator<br />
|-<br />
|'''AIN0, AIN1''' <br />
|Die beiden externen Eingänge des Analog-Komparators. <br />
Mit AIN0(+) und AIN1(-) kann man zwei Spannungen miteinander vergleichen. Wenn die Spannung an AIN0 höher als bei AIN1 ist, liefert der Komparator "High", ansonsten ein "Low". Als interne Eingänge des Komparators können die Interne Bandgap-Referenzspannung oder Ausgänge des ADC-Multiplexers dienen.<br />
<!-------------------------------------------------------------------------------------><br />
|- {{Hintergrund1}}<br />
! colspan="2"| Serielle Schnittstelle ([[UART|USART]])<br />
|-<br />
|'''RXD''' <br />
|Eingang der Seriellen Schnittstelle (Receive Data), TTL-Pegel <br />
|-<br />
|'''TXD''' <br />
|Ausgang Serielle Schnittstelle (Transmit Data), TTL-Pegel <br />
|-<br />
|'''XCK''' <br />
|Externe Takt für den USART. Wird nur in Sonderfällen für den Takt benötigt. <br />
USART ("Universal Synchronous/Asynchronous Receiver and Transmitter"). Das ist die serielle Schnittstelle, die zur Datenübertragung zwischen Mikrocontroller und PC genutzt wird. Zur bidirektionalen Übertragung werden zwei Pins am Controller benötigt: TXD und RXD. Über TXD ("Transmit Data") werden Daten gesendet, RXD ("Receive Data") dient zum Empfang. <br />
<!-------------------------------------------------------------------------------------><br />
|- {{Hintergrund1}}<br />
! colspan="2"| [[SPI]]-Schnittstelle<br />
|-<br />
|'''SS''' <br />
|SPI-Interface – wird beneötigt um den richtigen Slave am Bus zu wählen <br />
|-<br />
|'''MOSI''' <br />
|SPI-Interface – Datenausgang (als Master) oder Dateneingang (als Slave), verwendet bei ISP (In-System-Programmierung)<br />
|-<br />
|'''MISO''' <br />
|SPI-Interface – Dateneingang (als Master) oder Datenausgang (als Slave), verwendet bei ISP (In-System-Programmierung)<br />
|-<br />
|'''SCK''' <br />
|SPI-Interface – Bustakt vom Master, verwendet bei ISP (In-System-Programmierung)<br />
<!-------------------------------------------------------------------------------------><br />
|- {{Hintergrund1}}<br />
! colspan="2"| [[I2C|I<sup>2</sup>C]]-Schnittstelle ([[TWI]])<br />
|-<br />
|'''SDA''' <br />
|I2C-Schnittstelle (Bus aus 2 Leitungen) Datenleitung <br />
|-<br />
|'''SCL''' <br />
|I2C-Schnittstelle (Bus aus 2 Leitungen) Clockleitung <br />
<!-------------------------------------------------------------------------------------><br />
|- {{Hintergrund1}}<br />
! colspan="2"| [[JTAG]]-Interface<br />
|-<br />
|'''TDI''' <br />
|JTAG-Debug Interface - Über dieses Interface kann man den AVR programmieren und debuggen. Die Schnittstelle ist ähnlich wie die SPI Schnittstelle und hat getrennte Dateneingangs- und Datenausgangsleitungen sowie eine Taktleitung. TDI ist die Dateneingangsleitung<br />
|-<br />
|'''TDO''' <br />
|JTAG-Debug Interface - TDO ist die Datenausgangsleitung des JTAG Interface<br />
|-<br />
|'''TMS''' <br />
|JTAG-Debug Interface<br />
|-<br />
|'''TCK''' <br />
|JTAG-Debug Interface <br />
|}<br />
<br />
== Timer/Counter ==<br />
Für Infos zu Timer und Counter siehe Artikel [[Timer/Counter (Avr)]].<br />
<br />
== Analog-Digital-Wandler ==<br />
Für Infos zu Analog-Digital-Wandler siehe Artikel [[ADC (Avr)]].<br />
<br />
== Analog-Komparator ==<br />
Für Infos zu Analog-Komparator siehe Artikel [[Analog Komparator (Avr)]].<br />
<br />
== TWI/I2C ==<br />
Für Details über das Two-wire Serial Interface (kurz [[TWI]]) siehe Artikel [[TWI]].<br />
<br />
== UART/USART ==<br />
Für Details über den UART/USART siehe Artikel [[UART]].<br />
<br />
== SPI - Serial Peripheral Interface ==<br />
Für Details über SPI siehe Artikel [[SPI]].<br />
<br />
Näheres zu SPI beim AVR siehe [[SPI (AVR)]].<br />
<br />
== USI - Universal Serial Interface ==<br />
Für Infos zu USI (Universal Serial Interface) siehe Artikel [[USI (Avr)]].<br />
<br />
== Die Fusebits ==<br />
Fusebits nennt man bestimmte Bits zur Konfigurierung eines AVR-Controllers. Bei der Auslieferung neuer AVR Controller sind die Fusebits bereits vorkonfiguriert. In vielen Fällen kann man die Konfiguration unverändert belassen, je nach Controllertyp. Bei den Typen Mega xxx bestimmen einige Fusebits beispielsweise, dass der interne Taktgeber aktiviert ist. Möchte man dagegen einen externen Quarz anschließen oder die Taktfrequenz ändern, so müssen auch die Fusebits geändert werden. Auch das Deaktivieren des "[[On Chip Debugging]]" Modus ist oft notwendig, wenn man alle Ports ausnutzen möchte. <br />
<br />
Die Fusebits werden in der Regel über die Software eingestellt, welche auch für das Übertragen des Programmcodes zuständig ist. Besonders einfach geht dies beispielsweise mit der Entwicklungsumgebung [[Bascom]]. Aber auch andere Programme wie [[PonyProg]] können für die Umstellung der Fusebits genutzt werden. Einmal eingestellte Fusebits bleiben bis zur erneuten Fusebit-Änderung erhalten. Der normale Programmiermodus verändert die Fusebits nicht. <br />
<br />
Je nach AVR Controllertyp sind unterschiedliche Fusebits (Einstellungen) vorhanden. Die genaue Beschreibung findet man im jeweiligen Datenblatt. Da aber falsch gesetzte Fusebit-Einstellungen zu den häufigsten Problemen gehören, liste ich hier die Funktion der üblichen Fusebits nochmals genauer auf:<br />
<br />
{| {{Blauetabelle}}<br />
|'''CKSEL0, CKSEL1, CKSEL2, CKSEL3'''<br />
|Die Kombination dieser 4 Fusebits bestimmt die Taktquelle des Controllers. Das kann eine interner Taktgenerator, ein Quarz, Quarzoszillator, RC-Glied und ähnliches sein.<br />
|-<br />
|'''JTAGEN'''<br />
|Hiermit wird die "[[On Chip Debugging]]" Schnittstelle aktiviert bzw. deaktiviert. Das sind die Bits mit den Bezeichnungen TDI, TDO, TMS und TCK. Möchte man diese Pins als normalen Port nutzen, so muss diese Schnittstelle immer deaktiviert werden. <br />
|-<br />
|'''SUT0, SUT1'''<br />
|Die sogenannte StartUp-Zeit (PowerOn delay). Diese Einstellung muss abhängig von der Art des Taktgenerators eingestellt werden, genaueres im jeweiligen Datenblatt. <br />
|-<br />
|'''SPIEN'''<br />
|Hiermit kann die serielle [[AVR-ISP Programmierkabel|ISP-Programmierung]], welche die meisten Programmierkabel nutzen, deaktiviert werden. Dies sollte man lieber vermeiden, denn wenn dieser Programmiermodus deaktiviert wurde, kann nur noch der Parallel-Programmiermodus genutzt werden. Der Parallel-Programmiermodus benötigt jedoch ein spezielles Programmiergerät, das die wenigsten Bastler besitzen. ''Also Vorsicht!''<br />
|-<br />
|'''BODEN'''<br />
|Über dieses Bit wird der '''Brown-out Detector''' aktiviert bzw. deaktiviert. Dies ist eine Überwachung der Betriebsspannung. Diese Überwachung soll dafür sorgen, dass bei Spannungseinbrüchen ein ordentlicher RESET durchgeführt wird. Dadurch wird verhindert, dass ein Controller in einen undefinierten Zustand gerät (hängen bleibt).<br />
|-<br />
|'''BOOTLEVEL'''<br />
|Über dieses Bit kann die Spannung festgelegt werden, ab welcher der '''Brown-out Detector''' den Controller neu startet (also RESET ausführt). <br />
|-<br />
|'''BOOTRST'''<br />
|Gewöhnlich startet ein Programm im Controller nach einem RESET ab Adresse 0. Durch dieses Fusebit kann der Controller jedoch veranlasst werden, nach einem Reset einen sogenannten Bootloader-Bereich auszuführen. Ein [[Bootloader]] kann genutzt werden, um Controller über andere Schnittstellen (z.B. RS232) zu programmieren.<br />
|-<br />
|'''BOOTSZ0, BOOTSZ1'''<br />
|Der zuvor genannte Bootloaderbereich kann bei AVR-Controllern verschieden groß sein. Über diese beiden Bits können vier verschiedene Größen eingestellt werden. Siehe unter [[Bootloader]].<br />
|-<br />
|'''EESAVE'''<br />
|Dieses Bit legt fest, ob beim Programmieren des Controllers (man nennt es auch brennen) immer das EEPROM gelöscht werden soll.<br />
|-<br />
|'''CKOPT'''<br />
|Abhängig von den Einstellungen von CKSEL kann hier dir Oszillator-Verstärkung eingestellt werden. Genaueres im Datenblatt des jeweiligen Controllers.<br />
|-<br />
|'''WDTON'''<br />
|Schaltet den WatchDog-Timer beim Booten ein/aus. Dies ist auch per Software möglich<br />
|-<br />
|'''RSTDISBL'''<br />
|Durch dieses Bit kann man den RESET-Pin deaktivieren und dann als normalen I/O-Port nutzen. Aber Vorsicht! Da die RESET-Leitung beim Programmieren (Brennen) des Chips genutzt wird, kann man nach dessen Deaktivierung den Controller mit den üblichen [[AVR-ISP Programmierkabel|ISP-Adaptern]] nicht mehr programmieren. In diesem Fall könnte man zwar den Controlle noch mit speziellen Programmiergeräten im Parallelmodus programmieren, aber in der Praxis verfügen nur wenige Bastler über ein Programmiergerät, das dies leistet.<br />
|-<br />
|'''LB1, LB2'''<br />
|Das sind die sogenannten Lockbits, mit denen sich das Auslesen des Flash- als auch EEPROM-Speichers verhindern läßt. Zwar können andere Anwender immer noch Daten lesen, allerdings handelt es sich dabei nicht mehr um den wirklichen Inhalt sondern lediglich um wirre Datenbytefolgen. Programmierer, die den erarbeiteten Code vor Raubkopierern schützen wollen, nutzen diese Lockbits. Das Programmieren ist auch bei gesetzen Lockbits noch möglich. Der Bootloader-Bereich wird nicht durch die Lockbits geschützt.<br />
|-<br />
|'''BLB01, BLB02'''<br />
|Durch diese Bits kann der Code sogar vor dem Zugriff durch den Bootloader geschützt werden<br />
|-<br />
|'''BLB11, BLB12'''<br />
|Diese Bits schützen den Bootloaderbereich selbst<br />
|}<br />
<br />
Wie man die Fusebits mit [[Bascom]] einstellt, wird im Beitrag [[Bascom - Erstes Programm in den AVR Controller übertragen]] erläutert.<br />
<br />
''Autoren des Artikels: Frank, Luma'' <br />
<br />
<br />
== Siehe auch ==<br />
* [[AVR-Einstieg leicht gemacht]]<br />
===Entwicklungsumgebungen===<br />
* [[Bascom]] - Basic-Entwicklungssystem<br />
* [[Bascom - Erstes Programm in den AVR Controller übertragen]]<br />
* [[Avr-gcc|avr-gcc]] - Leistungsfähiger AVR-Port des freien Compilers GCC<br />
* [[WinAVR]] - Freies, kostenloses Werkzeugpaket mit avr-gcc, binutils, tools ([[make]], [[Programmer's Notepad]], [[avrdude]], etc.) für MS-Windows.<br />
* [[Linuxdistribution_Avr-live-cd]]<br />
* [[AVR_Assembler_Einf%C3%BChrung|AVR Assembler Einführung (AvrStudio)]]<br />
=== Hardware ===<br />
* [[AVR-ISP Programmierkabel]] - Bauanleitung für die AVR Controller Programmierkabel<br />
* [[RN-Control]] - Eines der beliebtestet AVR-Boards im Roboternetz<br />
* [[RNBFRA-Board]] - Größeres Board mit zwei Atmel Controllern<br />
===Sonstiges===<br />
* [[Atmel]]<br />
* [[HEX Beispiel-Dateien für AVR]]<br />
* [[Bootloader]]<br />
* [[On Chip Debugging]]<br />
<br />
== Weblinks ==<br />
* [http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC Aktuelle AVR Vergleichstabelle]<br />
* [http://www.atmel.com/dyn/products/devices.asp?family_id=607 Die Datenblätter zu Atmel Controllern]<br />
* [https://mpg.dnsalias.com/~magerlu/rn-wiki/avrtimer_applet Java Applet Timer Berechnung] <br />
* [http://www.roboternetz.de/phpBB2/dload.php?action=file&file_id=169 AvrTimer Windows Berechnungstool (für Bascom, nur nach Anmeldung)]<br />
* [http://people.freenet.de/gjl/helferlein/avr-uart-rechner.html AVR-Baudraten-Rechner (JavaScript)]<br />
<br />
[[Kategorie:Microcontroller]]<br />
[[Kategorie:Grundlagen]]<br />
[[Kategorie:Elektronik]]<br />
[[Kategorie:Abkürzung|AVR]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Leiterplatten_Entwicklung_-_Programme&diff=10137Leiterplatten Entwicklung - Programme2007-02-07T13:29:44Z<p>Overthere: </p>
<hr />
<div>== Vorwort ==<br />
Leiterplatten Entwicklung war früher ein, für den Hobbyanwender, rechr mühsames unterfangen.<br />
Entweder wurden die Leitebahnen und "Pad's" direkt auf die Kupferschicht, mit einem Ätzfesten Stift gezeichnet oder zunächst auf Folie/Papier gezeichnet und dann mittels Fototransfer auf die Platine übertragen.<br />
<br />
Heute stehen hierfür sehr umfangreiche aber dennoch mehr oder weniger leicht bedienbare Programme zur verfügung, welche einen Entwurf von Leiterplatten erleichtern.<br />
<br />
Oft stehen verschiedene Versionen z.T. auch kostenlose Testversionen oder Versionen für den Hobby-Anwender zur Verfügung.<br />
<br />
Hier eine Liste von freien und kommerziellen Programmen welche es erlauben Leiterpaltten mit dem Computer zu designen.<br />
<br />
----<br />
<br />
: '''Hier soll nicht der Umgang (Bedienungsanleitung) mit den beschriebenen Programmen sondern die Verfügbarkeit von verschiedenen Programmen und deren Usability im Vordergrund stehen.'''<br />
<br />
----<br />
<br />
<br />
== Die wohl bekanntesten PCB Programme: ==<br />
:* EAGLE<br />
:* TARGET<br />
:* Sprint-Layout<br />
:* PCB-POOL®Edition<br />
:* ORCAD<br />
:* KiCAD<br />
=== Weitere Programme ===<br />
'''z.T. kommerzielle, limitierte, freie und z.T nicht mehr verfügbare Cad Programme'''<br />
:* Protel <br />
:: nicht mehr verfügbar (jetzt Altium)<br />
:* Altium Designer<br />
:* PROTEUS<br />
:* ULTIBOARD<br />
:* EASY PC<br />
:* EDWIN<br />
:* QUICK ROUTE<br />
:* ARIADNE<br />
:* AUTOENGINEER<br />
:* BPECS32<br />
:* CADSTAR<br />
:* CADint<br />
:* CIRCUIT LAYOUT<br />
:* CIRCUIT CREATOR<br />
:* CIRCAD<br />
<br />
Diese Liste kann noch weitergeführt werden, was allerdings leicht dazu führt den überblichk zu verlieren.<br />
Diese Liste wird/kann im Laufe der Zeit mit Kommentaren und erfahrungswerten versehen bzw. aktualisiert werden.<br />
Auch Streichungen und Erweiterungen sind gestattet (bitte nicht übertreiben).<br />
<br />
<br />
== AddOns für diese Programme ==<br />
:* Eagle3D<br />
:: eine kostenloses 3D Zusatzprogramm für Eagle<br />
<br />
== Bewertungen und Infos zu den gelisteten Programmen ==<br />
''Info, Empfehlungen und Kritik zu den vorgestellten Programmen''<br />
<br />
::* EAGLE<br />
::** Dieses Programm kann man hier im Roboternetz wohl als 1. Wahl bezeichnen, da die meisten Anwender hier hiermit arbeiten. Die Kostenlose Version erlaubt Platinen bis zu 80mm x 100mm mit Schaltplan und Autorouter auf zwei Signal-Ebenen (Dual-Layer) zu erstellen. Auch eine sog. Studenten-Version (aber nicht nur für diese) ist zu sehr guten Konditionen zu erwerben.<br />
::** Nachdem die Einarbeitungsphase überwunden wurde, sehr gut zu bedienendes Tool<br />
::** Der Autorouter liefert (wie viele andere Programme auch) nur teilweise brauchbare Ergebnisse.<br />
::* Eagle3D<br />
::** bereits in der Entwurfsphase kann einem dieses Tool bei Design-Fehlern (LookOut) gute Dienste leisten<br />
::** leider ist das erstellen von eigenen Bauteilen (noch) etwas aufwendig.<br />
::** Auch eine Animation (Flug über die Platte) soll möglich sein...<br />
::** Sieht einfach klasse aus und macht auch Spass damit zu 'Spielen'<br />
::: '''INFO:''' Benötigt weitere Zusatzsoftware (auch als Freeware/GNU), mehr dazu auf der Homepage<br />
<br />
== Weblinks ==<br />
'''Programme'''<br />
* [http://www.cadsoft.de/ Eagle Homepage von CadSoft]<br />
* [http://www.ibfriedrich.com/home.htm Target 3001 Homepage von Ing.-Büro FRIEDRICH]<br />
* [http://www.abacom-online.de/html/demoversionen.html Sprint-Layout Homepage von ABACOM Ingenieurbüro GbR]<br />
* [http://www.pcb-pool.de/html_de/de_service_1.htm free PCB-POOL Homepage von Beta LAYOUT GmbH]<br />
* [http://www.altium.com/Products/AltiumDesigner/ AltiumDesigner Homepage von Altium Limited.]<br />
* [http://www.lis.inpg.fr/realise_au_lis/kicad/ KiCAD-Homepage]<br />
'''AddOn's'''<br />
* [http://www.matwei.de/doku.php?id=de:eagle3d:eagle3d Eagle3D Homepage von Matthias Weißer]<br />
<br />
<br />
<!-- unsichtbarer Kommentar: http://www.pcb-pool.de/html_de/de_service_1.htm --><br />
--[[Benutzer:Darwin.nuernberg|Darwin.nuernberg]] 12:39, 3. Feb 2007 (CET)<br />
{{Ausbauwunsch|Was Euch noch dazu einfällt, erfahrungen mit diesen Programmen usw., Kommentare}}<br />
<br />
<br />
==Siehe auch==<br />
* [[Leiterplatten herstellen]]<br />
* [[CAD]]<br />
* [[PCB]]<br />
<br />
[[Kategorie:Grundlagen]]<br />
[[Kategorie:Praxis]]<br />
[[Kategorie:Software]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10136Motorkraft berechnen2007-02-06T16:07:02Z<p>Overthere: </p>
<hr />
<div><br />
== Vorwort ==<br />
=== Allgemein ===<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. Es gibt zwar etliche Überschlagsrechnungen, doch leider blieb dem Roboterbauer bisjetzt eine genaue Berechnung vorenthalten. Desshalb '''hat dieser Artikel die Bemühung das Problem möglichst genau zu behandeln.'''<br />
=== Technische Informationen ===<br />
Zum Berechnen der Motorkraft muss man erst einige Reibungen und Widerstände kennenlernen. Diese werden nun im folgenden beschrieben. Man muss nicht jede Kraft berechnen, einige Kräfte kann man auch mit einem Pauschalzuschlag unter den Tisch fallen lassen. Ein Beispiel: ''Luftwiderstand von einer Schnecke.'' Sicherlich darf man aber den Luftwiderstand bei einem Rennwagen nicht unterschlagen. Ich hoffe Ihr versteht was ich sagen will.<br />
== Bewegungseibungen ==<br />
Darunter fallen Haft-,Gleit- und Rollreibung. Diese sind von der Geschwindigkeit unanabhängig. '''Wichtig:''' Sollte der Roboter an einer Schränge sich befinden, berechnet sich die Reibung noch mit dem Koeffizienten cos(alpha). Alpha ist hierbei der Steigungswinken. Mehr siehe dazu bitte Steigung/Gefälle.<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss diese Kraft über die Motoren aufwenden um loszufahren. Sie berechnet sich aus:<br />
<math>F=fh*m*g</math><br />
*F: Kraft in N<br />
*fh: Reibungskoeffizient (Haftreibung)<br />
*m: Masse des Roboters in Kg<br />
*g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<br />
<math>F=fg*m*g</math><br />
<br />
*fg: Reibungskoeffizient (Gleitreibung)<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<math>F=fr*m*g</math><br />
*fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Beschleunigung ==<br />
=== Benötigte Beschleunigung berechnen ===<br />
Für das Anfahren muss man die benötigte Beschleunigung wissen. Die Beschleunigung wird mit a (engl.: ''Beschleunigung'') bezeichnet. Sie hat die Einheit m/(sec^2). Diese muss man zuerst ermitteln. <br />
<br />
Man kann diese anhand der Geschwindigkeit erechnen. Dabei gilt <math>v=a*t</math>. <br />
*v: Geschwindigkeit in m/sec<br />
*t: die Zeit in sec. <br />
Auch kann man diese anhand der zurückgelegten Strecke ermitteln. Dabei gilt: s=0.5*t^2*a. <br />
*s ist die Strecke in m <br />
*t die Zeit in Sekunden.<br />
<br />
=== Kraftberechnung ===<br />
Hat man nun die Beschleunigung a ermittelt, kann man die benötigte Kraft mithilfe F=m*a errechnen. Vorraussetzung hierbei ist, dass die Masse konstant bleibt. Das würde also nicht für Roboter mit Raketenantrieb funktionieren.<br />
=== Bremskraft ===<br />
Das gleiche gilt auch für das Bremsen, nur das hier Energie freigesetzt wird. Wenn die Reifen darf man nicht zu sehr blockieren. Sonst überschreitet man die [#Haftreibung] und der Roboter rutscht. <br />
Der die Kraft F kann man in diesem Fall durch <math>F=p/t</math> nehmen. P ist der Impuls und die t die Zeit.<br />
Einen Impuls ist das Produkt aus Masse mal Geschwindigkeit. Also: <math>P=m*v</math>. Das setzt man nun in die Gleichung ein und erhält: <math>F=(m*v)/t</math>. Alternativ kann man die Bremskraft aus <math>F=m*a</math> errechnen. <br />
Überschreitet nur die Errechnete Kraft F die Haftreibung rutscht euer Roboter garantiert.<br />
<br />
== Steigung/Gefälle ==<br />
=== Steigung ===<br />
Wenn man einen Berg hochfährt muss man neben der Reibung auch noch die Erdanziehungskraft überwinden. Bei Steigungen gibt es grundlegend 2 Kräfte. <br />
* Normalkraft: Kraft die auf den Boden wirkt und aus der die (Haft/Gleit/Roll)reibung berechnet wird. Diese berechnet sich aus <math>Fn=m*g*cos(alpha)</math>. Alpha ist hierbei der Steigung. Sollte man den Berg mit dem Roboter also eine Steigung überwinden, hat man eine geringere (Haft/Gleit/Roll)reibung zu überwinden.<br />
* Hang(auf|ab)triebskraft: Kraft die der Roboter überwinden muss um den Berg hinaufzufahren. Diese Kraft kann man aus <math>Fh=m*g*sin(alpha)</math> errechen. <br />
=== Gefälle ===<br />
Bei Gefällen gilt das gleiche wie bei Steigungen, nur dass hier die Hangabtriebskraft wirkt. Diese berechnet sich wie die Hangauftriebskraft. Die Berechnung der Normalkraft ist identisch wie die Berechnung der benötigten Kraft für die Steigung.<br />
==Luftwiderstand ==<br />
Der Luftwiderstand betrifft eigentlich nur schnelle Roboter. Hierzu braucht man eine Latte koeffizienten: Luftdichte ld, Reibungskoeffizient cw und die "Luftaufprallfläche" A.<br />
<math>F=0.5v^2*cw*ld*A</math>. Die Luftdichte von ist Standartgemäß 1.1. cw muss man nach koeffizienten suchen. A ist die Aufprallfäche, das ist die Seite die mit dem Fahrtfind konfrontiert wird. Mehr dieser Koeffizenten findet man unter Weblinks.<br />
== Errechnung der Motorkraft ==<br />
Hat man nun alle (nötigen) Kräfte errechechnet, dann nimmt man den schlechtesten Wert und rechnet 10-20%(geschätzt) Verluste durch Getriebe etc. hinzu.<br />
Hat man die benötigte Kraft errechnet gilt:<br />
<math>Mmotor=Ftotal*Reifenradius</math>. Nun hat man einen Anhaltspunkt welche Leistung der Roboter benötigt.<br />
=== Getriebe ===<br />
Ein Getriebe hat die Aufgabe Geschwindigkeit in Kraft oder Kraft in Geschwindigkeit umzuwandeln. Setzt man nun ein Getriebe mit 1:200 ein, wird die Kraft 200fach stärker, die Geschwindigkeit 200fach langsamer. Ein Getriebe ist auf jeden Fall sinnvoll und zu empfehlen. <br />
=== Geschwindigkeit ===<br />
Die Geschwindkeit des Roboters ist das Produkt aus 2pi, dem Reifenradius und der Umdrehungszahl. Als Formel: <math>V=2pi*r*u</math>. Ein eventuell vorhandenes Getriebe ist natürlich zu miteinzubeziehen.<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
=== Bitte noch ergänzen ===<br />
Jeder ist herzlich willkommen diesen Artikel zu erweitern oder zu verbessern.<br />
== Weblinks ==<br />
*[http://de.wikipedia.org/wiki/Haftreibung Haftreibung]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[http://de.wikipedia.org/wiki/Rollreibung Rollreibung]<br />
*[http://de.wikipedia.org/wiki/Luftwiderstand Luftriebungskoeffizenten]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Diskussion:Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=10093Diskussion:Linuxdistribution Avr-live-cd DISCONTINUED2007-02-02T19:23:57Z<p>Overthere: </p>
<hr />
<div>Daß die crt*.o nicht gefunden wird deutet auf eine fehlerhaft Installation/Built von avr-gcc/avr-binutils hin.<br />
Sinnvoll wäre auch ein pdf-Reader nebst den AVR-Datenblättern, da man beim Entwickeln gerne darauf zurückgreift. --[[Benutzer:SprinterSB|SprinterSB]] 19:42, 23. Dez 2006 (CET)<br />
<br />
----<br />
<br />
Hallo.<br />
Ich habe das CRT*.o problem durch die makefile in der neueren Version gelöst. Hier muss man die CRTM-File zusätzlich noch angeben. Ein Avr-reader ist schon installiert, der von KDE. Nennt sicht KPDF.<br />
<br />
Bis die nächste Version rauskommt, wird noch auf das neue Release von Kontrollerlab gewartet.<br />
<br />
Viele Grüße<br />
--[[Benutzer:Overthere|Overthere]] 20:22, 2. Feb 2007 (CET)</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Diskussion:Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=10092Diskussion:Linuxdistribution Avr-live-cd DISCONTINUED2007-02-02T19:22:59Z<p>Overthere: </p>
<hr />
<div>Daß die crt*.o nicht gefunden wird deutet auf eine fehlerhaft Installation/Built von avr-gcc/avr-binutils hin.<br />
Sinnvoll wäre auch ein pdf-Reader nebst den AVR-Datenblättern, da man beim Entwickeln gerne darauf zurückgreift. --[[Benutzer:SprinterSB|SprinterSB]] 19:42, 23. Dez 2006 (CET)<br />
<br />
----<br />
<br />
Hallo.<br />
Ich habe das CRT*.o problem durch die makefile in der neueren Version gelöst. Hier muss man die CRTM-File zusätzlich noch angeben. Ein Avr-reader ist schon installiert, der von KDE. Nennt sicht KPDF.<br />
<br />
Viele Grüße<br />
--[[Benutzer:Overthere|Overthere]] 20:22, 2. Feb 2007 (CET)</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Diskussion:Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=10091Diskussion:Linuxdistribution Avr-live-cd DISCONTINUED2007-02-02T19:22:39Z<p>Overthere: </p>
<hr />
<div>Daß die crt*.o nicht gefunden wird deutet auf eine fehlerhaft Installation/Built von avr-gcc/avr-binutils hin.<br />
Sinnvoll wäre auch ein pdf-Reader nebst den AVR-Datenblättern, da man beim Entwickeln gerne darauf zurückgreift. --[[Benutzer:SprinterSB|SprinterSB]] 19:42, 23. Dez 2006 (CET)<br />
Hallo.<br />
Ich habe das CRT*.o problem durch die makefile in der neueren Version gelöst. Hier muss man die CRTM-File zusätzlich noch angeben. Ein Avr-reader ist schon installiert, der von KDE. Nennt sicht KPDF.<br />
<br />
Viele Grüße<br />
--[[Benutzer:Overthere|Overthere]] 20:22, 2. Feb 2007 (CET)</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10089Motorkraft berechnen2007-02-02T12:58:24Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben. Sollte es unklarheiten geben, bitte die Diskusion nutzen.'''<br />
<br />
<br />
<br />
== Vorwort ==<br />
=== Allgemein ===<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. Es gibt zwar etliche Überschlagsrechnungen, doch leider blieb dem Roboterbauer bisjetzt eine genaue Berechnung vorenthalten. Desshalb '''hat dieser Artikel die Bemühung das Problem möglichst genau zu behandeln.'''<br />
=== Technische Informationen ===<br />
Zum Berechnen der Motorkraft muss man erst einige Reibungen und Widerstände kennenlernen. Diese werden nun im folgenden beschrieben. Man muss nicht jede Kraft berechnen, einige Kräfte kann man auch mit einem Pauschalzuschlag unter den Tisch fallen lassen. Ein Beispiel: ''Luftwiderstand von einer Schnecke.'' Sicherlich darf man aber den Luftwiderstand bei einem Rennwagen nicht unterschlagen. Ich hoffe Ihr versteht was ich sagen will.<br />
== Bewegungseibungen ==<br />
Darunter fallen Haft-,Gleit- und Rollreibung. Diese sind von der Geschwindigkeit unanabhängig. '''Wichtig:''' Sollte der Roboter an einer Schränge sich befinden, berechnet sich die Reibung noch mit dem Koeffizienten cos(alpha). Alpha ist hierbei der Steigungswinken. Mehr siehe dazu bitte Steigung/Gefälle.<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss diese Kraft über die Motoren aufwenden um loszufahren. Sie berechnet sich aus:<br />
<math>F=fh*m*g</math><br />
*F: Kraft in N<br />
*fh: Reibungskoeffizient (Haftreibung)<br />
*m: Masse des Roboters in Kg<br />
*g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<br />
<math>F=fg*m*g</math><br />
<br />
*fg: Reibungskoeffizient (Gleitreibung)<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<math>F=fr*m*g</math><br />
*fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Beschleunigung ==<br />
=== Benötigte Beschleunigung berechnen ===<br />
Für das Anfahren muss man die benötigte Beschleunigung wissen. Die Beschleunigung wird mit a (engl.: ''Beschleunigung'') bezeichnet. Sie hat die Einheit m/(sec^2). Diese muss man zuerst ermitteln. <br />
<br />
Man kann diese anhand der Geschwindigkeit erechnen. Dabei gilt <math>v=a*t</math>. <br />
*v: Geschwindigkeit in m/sec<br />
*t: die Zeit in sec. <br />
Auch kann man diese anhand der zurückgelegten Strecke ermitteln. Dabei gilt: s=0.5*t^2*a. <br />
*s ist die Strecke in m <br />
*t die Zeit in Sekunden.<br />
<br />
=== Kraftberechnung ===<br />
Hat man nun die Beschleunigung a ermittelt, kann man die benötigte Kraft mithilfe F=m*a errechnen. Vorraussetzung hierbei ist, dass die Masse konstant bleibt. Das würde also nicht für Roboter mit Raketenantrieb funktionieren.<br />
=== Bremskraft ===<br />
Das gleiche gilt auch für das Bremsen, nur das hier Energie freigesetzt wird. Wenn die Reifen darf man nicht zu sehr blockieren. Sonst überschreitet man die [#Haftreibung] und der Roboter rutscht. <br />
Der die Kraft F kann man in diesem Fall durch <math>F=p/t</math> nehmen. P ist der Impuls und die t die Zeit.<br />
Einen Impuls ist das Produkt aus Masse mal Geschwindigkeit. Also: <math>P=m*v</math>. Das setzt man nun in die Gleichung ein und erhält: <math>F=(m*v)/t</math>. Alternativ kann man die Bremskraft aus <math>F=m*a</math> errechnen. <br />
Überschreitet nur die Errechnete Kraft F die Haftreibung rutscht euer Roboter garantiert.<br />
<br />
== Steigung/Gefälle ==<br />
=== Steigung ===<br />
Wenn man einen Berg hochfährt muss man neben der Reibung auch noch die Erdanziehungskraft überwinden. Bei Steigungen gibt es grundlegend 2 Kräfte. <br />
* Normalkraft: Kraft die auf den Boden wirkt und aus der die (Haft/Gleit/Roll)reibung berechnet wird. Diese berechnet sich aus <math>Fn=m*g*cos(alpha)</math>. Alpha ist hierbei der Steigung. Sollte man den Berg mit dem Roboter also eine Steigung überwinden, hat man eine geringere (Haft/Gleit/Roll)reibung zu überwinden.<br />
* Hang(auf|ab)triebskraft: Kraft die der Roboter überwinden muss um den Berg hinaufzufahren. Diese Kraft kann man aus <math>Fh=m*g*sin(alpha)</math> errechen. <br />
=== Gefälle ===<br />
Bei Gefällen gilt das gleiche wie bei Steigungen, nur dass hier die Hangabtriebskraft wirkt. Diese berechnet sich wie die Hangauftriebskraft. Die Berechnung der Normalkraft ist identisch wie die Berechnung der benötigten Kraft für die Steigung.<br />
==Luftwiderstand ==<br />
Der Luftwiderstand betrifft eigentlich nur schnelle Roboter. Hierzu braucht man eine Latte koeffizienten: Luftdichte ld, Reibungskoeffizient cw und die "Luftaufprallfläche" A.<br />
<math>F=0.5v^2*cw*ld*A</math>. Die Luftdichte von ist Standartgemäß 1.1. cw muss man nach koeffizienten suchen. A ist die Aufprallfäche, das ist die Seite die mit dem Fahrtfind konfrontiert wird. Mehr dieser Koeffizenten findet man unter Weblinks.<br />
== Errechnung der Motorkraft ==<br />
Hat man nun alle (nötigen) Kräfte errechechnet, dann nimmt man den schlechtesten Wert und rechnet 10-20%(geschätzt) Verluste durch Getriebe etc. hinzu.<br />
Hat man die benötigte Kraft errechnet gilt:<br />
<math>Mmotor=Ftotal*Reifenradius</math>. Nun hat man einen Anhaltspunkt welche Leistung der Roboter benötigt.<br />
=== Getriebe ===<br />
Ein Getriebe hat die Aufgabe Geschwindigkeit in Kraft oder Kraft in Geschwindigkeit umzuwandeln. Setzt man nun ein Getriebe mit 1:200 ein, wird die Kraft 200fach stärker, die Geschwindigkeit 200fach langsamer. Ein Getriebe ist auf jeden Fall sinnvoll und zu empfehlen. <br />
=== Geschwindigkeit ===<br />
Die Geschwindkeit des Roboters ist das Produkt aus 2pi, dem Reifenradius und der Umdrehungszahl. Als Formel: <math>V=2pi*r*u</math>. Ein eventuell vorhandenes Getriebe ist natürlich zu miteinzubeziehen.<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
=== Bitte noch ergänzen ===<br />
Jeder ist herzlich willkommen diesen Artikel zu erweitern oder zu verbessern.<br />
== Weblinks ==<br />
*[http://de.wikipedia.org/wiki/Haftreibung Haftreibung]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[http://de.wikipedia.org/wiki/Rollreibung Rollreibung]<br />
*[http://de.wikipedia.org/wiki/Luftwiderstand Luftriebungskoeffizenten]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10088Motorkraft berechnen2007-02-02T12:50:24Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben. Sollte es unklarheiten geben, bitte die Diskusion nutzen.'''<br />
<br />
<br />
<br />
== Vorwort ==<br />
=== Allgemein ===<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. Es gibt zwar etliche Überschlagsrechnungen, doch leider blieb dem Roboterbauer bisjetzt eine genaue Berechnung vorenthalten. Desshalb '''hat dieser Artikel die Bemühung das Problem möglichst genau zu behandeln.'''<br />
=== Technische Informationen ===<br />
Zum Berechnen der Motorkraft muss man erst einige Reibungen und wiederstände kennenlernen. Diese werden nun im folgenden beschrieben. Man muss nicht jede Kraft berechnen, einige Kräfte kann man auch mit einem Pauschalzuschlag unter den Tisch fallen lassen. Ein Beispiel: ''Luftwiderstand von einer Schnecke.'' Sicherlich darf man aber den Luftwiderstand bei einem Rennwagen nicht unterschlagen. Ich hoffe Ihr versteht was ich sagen will.<br />
== Bewegungseibungen ==<br />
Darunter fallen Haft-,Gleit- und Rollreibung. Diese sind von der Geschwindigkeit unanabhängig. '''Wichtig:''' Sollte der Roboter an einer schränge sich befinden, berechnet sich die Reibung noch mit dem Koeffizienten cos(alpha). Alpha ist hierbei der Steigungswinken. Mehr siehe dazu bitte Steigung/Gefälle.<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss diese Kraft über die Motoren aufwenden um loszufahren. Sie berechnet sich aus:<br />
<math>F=fh*m*g</math><br />
*F: Kraft in N<br />
*fh: Reibungskoeffizient (Haftreibung)<br />
*m: Masse des Roboters in Kg<br />
*g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
<br />
<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<br />
<math>F=fg*m*g</math><br />
<br />
fg: Reibungskoeffizient (Gleitreibung)<br />
<br />
<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<br />
<math>F=fr*m*g</math><br />
<br />
fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Beschleunigung ==<br />
=== Benötigte Beschleunigung berechnen ===<br />
Für das Anfahren muss man die benötigte Beschleunigung wissen. Die Beschleunigung wird mit a (engl.: ''Beschleunigung'') bezeichnet. Sie hat die Einheit m/(sec^2). Diese muss man zuerst ermitteln. <br />
<br />
Man kann diese anhand der Geschwindigkeit erechnen. Dabei gilt v=a*t. v ist die Geschwindigkeit in m/sec und t die Zeit in sec. <br />
Auch kann man diese anhand der zurückgelegten Strecke ermitteln. Dabei gilt: s=0.5*t^2*a. s ist die Strecke in m und t die Zeit in Sekunden.<br />
<br />
=== Kraftberechnung ===<br />
Hat man nun die Beschleunigung a ermittelt, kann man die benötigte Kraft mithilfe F=m*a errechnen. Vorraussetzung hierbei ist, dass die Masse konstant bleibt. Das würde also nicht für Roboter mit Raketenantrieb gehen.<br />
=== Bremskraft ===<br />
Das gleiche gilt auch für das Bremsen, nur das hier Energie freigesetzt wird. Wenn die Reifen darf man nicht zu sehr blockieren. Sonst überschreitet man die [#Haftreibung] und der Roboter rutscht. <br />
Der die Kraft F kann man in diesem Fall durch <math>F=p/t</math> nehmen. P ist der Impuls und die t die Zeit.<br />
Einen Impuls ist das Produkt aus Masse mal Geschwindigkeit. Also: <math>P=m*v</math>. Das setzt man nun in die Gleichung ein und erhält: <math>F=(m*v)/t</math>. Alternativ kann man die Bremskraft aus <math>F=m*a</math> errechnen. <br />
Überschreitet nur die Errechnete Kraft F die Haftreibung rutscht euer Roboter garantiert.<br />
Anmerkung: Dieser Artikel wird noch erweitert.<br />
== Steigung/Gefälle ==<br />
=== Steigung ===<br />
Wenn man einen Berg hochfährt muss man neben der Reibung auch noch die Erdanziehungskraft überwinden. Bei Steigungen gibt es grundlegend 2 Kräfte. <br />
* Normalkraft: Kraft die auf den Boden wirkt und aus der die (Haft/Gleit/Roll)reibung berechnet wird. Diese berechnet sich aus <math>Fn=m*g*cos(alpha)</math>. Alpha ist hierbei der Steigung. Sollte man den Berg mit dem Roboter also eine Steigung überwinden, hat man eine geringere (Haft/Gleit/Roll)reibung zu überwinden.<br />
* Hang(auf|ab)triebskraft: Kraft die der Roboter überwinden muss um den Berg hinaufzufahren. Diese Kraft kann man aus <math>Fh=m*g*sin(alpha)</math> errechen. <br />
=== Gefälle ===<br />
Bei geflällen gilt das gleiche wie bei Steigungen, nur dass hier die Hangabtriebskraft wirkt. Diese berechnet sich wie die Hangauftriebskraft. Die Berechnung der Normalkraft ist identisch wie die Berechnung der benötigten Kraft für die Steigung.<br />
==Luftwiderstand ==<br />
Der Luftwiderstand betrifft eigentlich nur schnelle Roboter die schnell fahren. Hierzu braucht man eine Latte koeffizienten: Luftdichte ld, Reibungskoeffizient cw und die "Luftaufprallfläche" A.<br />
<math>F=0.5v^2*cw*ld*A</math>. Die Luftdichte von ist Standartgemäß 1.1. cw muss man nach koeffizienten suchen. A ist die Aufprallfäche, das ist die Seite die mit dem Fahrtfind konfrontiert wird. <br />
== Errechnung der Motorkraft ==<br />
Hat man nun alle (nötigen) Kräfte errechechnet, dann nimmt man den schlechtesten Wert und rechnet 10-20%(geschätzt) Verluste durch Getriebe etc. hinzu.<br />
Hat man die benötigte Kraft errechnet gilt:<br />
<math>Mmotor=Ftotal*Reifenradius</math>. Nun hat man einen Anhaltspunkt welche Leistung der Roboter benötigt.<br />
=== Getriebe ===<br />
Ein Getriebe hat die Aufgabe Geschwindigkeit in Kraft oder Kraft in Geschwindigkeit umzuwandeln. Setzt man nun ein Getriebe mit 1:200 ein, wird die Kraft 200fach stärker, die Geschwindigkeit 200fach langsamer. Ein Getriebe ist auf jeden Fall sinnvoll und zu empfehlen. <br />
=== Geschwindigkeit ===<br />
Die Geschwindkeit des Roboters ist das Produkt aus 2pi, dem Reifenradius und der Umdrehungszahl. Als Formel: <math>V=2pi*r*u</math>. Ein eventuell vorhandenes Getriebe ist natürlich zu miteinzubeziehen.<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
=== Bitte noch ergänzen ===<br />
Jeder ist herzlich willkommen diesen Artikel zu erweitern oder zu verbessern.<br />
== Weblinks ==<br />
*[http://de.wikipedia.org/wiki/Haftreibung Haftreibung]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[http://de.wikipedia.org/wiki/Rollreibung Rollreibung]<br />
*[http://de.wikipedia.org/wiki/Luftwiderstand Luftriebungskoeffizenten]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10087Motorkraft berechnen2007-02-02T12:43:36Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben. Sollte es unklarheiten geben, bitte die Diskusion nutzen.'''<br />
<br />
<br />
<br />
== Vorwort ==<br />
=== Allgemein ===<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. Es gibt zwar etliche Überschlagsrechnungen, doch leider blieb dem Roboterbauer bisjetzt eine genaue Berechnung vorenthalten. Desshalb '''hat dieser Artikel die Bemühung das Problem möglichst genau zu behandeln.'''<br />
=== Technische Informationen ===<br />
Zum Berechnen der Motorkraft muss man erst einige Reibungen und wiederstände kennenlernen. Diese werden nun im folgenden beschrieben. Man muss nicht jede Kraft berechnen, einige Kräfte kann man auch mit einem Pauschalzuschlag unter den Tisch fallen lassen. Ein Beispiel: ''Luftwiderstand von einer Schnecke.'' Sicherlich darf man aber den Luftwiderstand bei einem Rennwagen nicht unterschlagen. Ich hoffe Ihr versteht was ich sagen will.<br />
== Bewegungseibungen ==<br />
Darunter fallen Haft-,Gleit- und Rollreibung. Diese sind von der Geschwindigkeit unanabhängig. '''Wichtig:''' Sollte der Roboter an einer schränge sich befinden, berechnet sich die Reibung noch mit dem Koeffizienten cos(alpha). Alpha ist hierbei der Steigungswinken. Mehr siehe dazu bitte Steigung/Gefälle.<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss diese Kraft über die Motoren aufwenden um loszufahren. Sie berechnet sich aus:<br />
<math>F=fh*m*g</math><br />
*F: Kraft in N<br />
*fh: Reibungskoeffizient (Haftreibung)<br />
*m: Masse des Roboters in Kg<br />
*g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
<br />
<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<br />
<math>F=fg*m*g</math><br />
<br />
fg: Reibungskoeffizient (Gleitreibung)<br />
<br />
<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<br />
<math>F=fr*m*g</math><br />
<br />
fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Beschleunigung ==<br />
=== Benötigte Beschleunigung berechnen ===<br />
Für das Anfahren muss man die benötigte Beschleunigung wissen. Die Beschleunigung wird mit a (engl.: ''Beschleunigung'') bezeichnet. Sie hat die Einheit m/(sec^2). Diese muss man zuerst ermitteln. <br />
<br />
Man kann diese anhand der Geschwindigkeit erechnen. Dabei gilt v=a*t. v ist die Geschwindigkeit in m/sec und t die Zeit in sec. <br />
Auch kann man diese anhand der zurückgelegten Strecke ermitteln. Dabei gilt: s=0.5*t^2*a. s ist die Strecke in m und t die Zeit in Sekunden.<br />
<br />
=== Kraftberechnung ===<br />
Hat man nun die Beschleunigung a ermittelt, kann man die benötigte Kraft mithilfe F=m*a errechnen. Vorraussetzung hierbei ist, dass die Masse konstant bleibt. Das würde also nicht für Roboter mit Raketenantrieb gehen.<br />
=== Bremskraft ===<br />
Das gleiche gilt auch für das Bremsen, nur das hier Energie freigesetzt wird. Wenn die Reifen darf man nicht zu sehr blockieren. Sonst überschreitet man die [#Haftreibung] und der Roboter rutscht. <br />
Der die Kraft F kann man in diesem Fall durch <math>F=p/t</math> nehmen. P ist der Impuls und die t die Zeit.<br />
Einen Impuls ist das Produkt aus Masse mal Geschwindigkeit. Also: <math>P=m*v</math>. Das setzt man nun in die Gleichung ein und erhält: <math>F=(m*v)/t</math>. Alternativ kann man die Bremskraft aus <math>F=m*a</math> errechnen. <br />
Überschreitet nur die Errechnete Kraft F die Haftreibung rutscht euer Roboter garantiert.<br />
Anmerkung: Dieser Artikel wird noch erweitert.<br />
== Steigung/Gefälle ==<br />
=== Steigung ===<br />
Wenn man einen Berg hochfährt muss man neben der Reibung auch noch die Erdanziehungskraft überwinden. Bei Steigungen gibt es grundlegend 2 Kräfte. <br />
* Normalkraft: Kraft die auf den Boden wirkt und aus der die (Haft/Gleit/Roll)reibung berechnet wird. Diese berechnet sich aus <math>Fn=m*g*cos(alpha)</math>. Alpha ist hierbei der Steigung. Sollte man den Berg mit dem Roboter also eine Steigung überwinden, hat man eine geringere (Haft/Gleit/Roll)reibung zu überwinden.<br />
* Hang(auf|ab)triebskraft: Kraft die der Roboter überwinden muss um den Berg hinaufzufahren. Diese Kraft kann man aus <math>Fh=m*g*sin(alpha)</math> errechen. <br />
=== Gefälle ===<br />
Bei geflällen gilt das gleiche wie bei Steigungen, nur dass hier die Hangabtriebskraft wirkt. Diese berechnet sich wie die Hangauftriebskraft. Die Berechnung der Normalkraft ist identisch wie die Berechnung der benötigten Kraft für die Steigung.<br />
==Luftwiderstand ==<br />
Der Luftwiderstand betrifft eigentlich nur schnelle Roboter die schnell fahren. Hierzu braucht man eine Latte koeffizienten: Luftdichte ld, Reibungskoeffizient cw und die "Luftaufprallfläche" A.<br />
<math>F=0.5v^2*cw*ld*A</math>. Die Luftdichte von ist Standartgemäß 1.1. cw muss man nach koeffizienten suchen. A ist die Aufprallfäche, das ist die Seite die mit dem Fahrtfind konfrontiert wird. <br />
== Errechnung der Motorkraft ==<br />
Hat man nun alle (nötigen) Kräfte errechechnet, dann nimmt man den schlechtesten Wert und rechnet 10-20%(geschätzt) Verluste durch Getriebe etc. hinzu.<br />
Hat man die benötigte Kraft errechnet gilt:<br />
<math>Mmotor=Ftotal*Reifenradius</math>. Nun hat man einen Anhaltspunkt welche Leistung der Roboter benötigt.<br />
<br />
<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
== Weblinks ==<br />
*[[http://de.wikipedia.org/wiki/Haftreibung| Haftreibung]]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[[http://de.wikipedia.org/wiki/Rollreibung| Rollreibung]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10086Motorkraft berechnen2007-02-02T12:03:03Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben. Sollte es unklarheiten geben, bitte die Diskusion nutzen.'''<br />
<br />
<br />
<br />
== Vorwort ==<br />
=== Allgemein ===<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. Es gibt zwar etliche Überschlagsrechnungen, doch leider blieb dem Roboterbauer bisjetzt eine genaue Berechnung vorenthalten. Desshalb '''hat dieser Artikel die Bemühung das Problem möglichst genau zu behandeln.'''<br />
=== Technische Informationen ===<br />
Zum Berechnen der Motorkraft muss man erst einige Reibungen und wiederstände kennenlernen. Diese werden nun im folgenden beschrieben. Man muss nicht jede Kraft berechnen, einige Kräfte kann man auch mit einem Pauschalzuschlag unter den Tisch fallen lassen. Ein Beispiel: ''Luftwiderstand von einer Schnecke.'' Sicherlich darf man aber den Luftwiderstand bei einem Rennwagen nicht unterschlagen. Ich hoffe Ihr versteht was ich sagen will.<br />
== Bewegungseibungen ==<br />
Darunter fallen Haft-,Gleit- und Rollreibung. Diese sind von der Geschwindigkeit unanabhängig.<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss diese Kraft über die Motoren aufwenden um loszufahren. Sie berechnet sich aus:<br />
<br />
<math>F=fh*m*g</math><br />
<br />
F: Kraft in N<br />
<br />
fh: Reibungskoeffizient (Haftreibung)<br />
<br />
m: Masse des Roboters in Kg<br />
<br />
g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<br />
<math>F=fg*m*g</math><br />
<br />
fg: Reibungskoeffizient (Gleitreibung)<br />
<br />
<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<br />
<math>F=fr*m*g</math><br />
<br />
fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Beschleunigung ==<br />
=== Benötigte Beschleunigung berechnen ===<br />
Für das Anfahren muss man die benötigte Beschleunigung wissen. Die Beschleunigung wird mit a (engl.: ''Beschleunigung'') bezeichnet. Sie hat die Einheit m/(sec^2). Diese muss man zuerst ermitteln. <br />
<br />
Man kann diese anhand der Geschwindigkeit erechnen. Dabei gilt v=a*t. v ist die Geschwindigkeit in m/sec und t die Zeit in sec. <br />
Auch kann man diese anhand der zurückgelegten Strecke ermitteln. Dabei gilt: s=0.5*t^2*a. s ist die Strecke in m und t die Zeit in Sekunden.<br />
<br />
=== Kraftberechnung ===<br />
Hat man nun die Beschleunigung a ermittelt, kann man die benötigte Kraft mithilfe F=m*a errechnen. Vorraussetzung hierbei ist, dass die Masse konstant bleibt. Das würde also nicht für Roboter mit Raketenantrieb gehen.<br />
=== Bremskraft ===<br />
Das gleiche gilt auch für das Bremsen, nur das hier Energie freigesetzt wird. Wenn die Reifen darf man nicht zu sehr blockieren. Sonst überschreitet man die [#Haftreibung] und der Roboter rutscht. <br />
<br />
Anmerkung: Dieser Artikel wird noch erweitert.<br />
== Steigung/Gefälle ==<br />
''' Folgt noch '''<br />
=== Steigung ===<br />
Wenn man einen Berg hochfährt muss man neben der Reibung auch noch die Erdanziehungskraft überwinden. Bei Steigungen gibt es grundlegend 2 Kräfte. <br />
* Normalkraft: Kraft die auf den Boden wirkt und aus der die (Haft/Gleit/Roll)reibung berechnet wird. Diese berechnet sich aus <math>Fn=m*g*cos(alpha)</math>. Alpha ist hierbei der Steigung. Sollte man den Berg mit dem Roboter also eine Steigung überwinden, hat man eine geringere (Haft/Gleit/Roll)reibung zu überwinden.<br />
* Hang(auf|ab)triebskraft: Kraft die der Roboter überwinden muss um den Berg hinaufzufahren. Diese Kraft kann man aus <math>Fh=m*g*sin(alpha)</math> errechen. <br />
=== Gefälle ===<br />
Bei geflällen gilt das gleiche wie bei Steigungen, nur dass hier die Hangabtriebskraft wirkt. Diese berechnet sich wie die Hangauftriebskraft. Die Berechnung der Normalkraft ist identisch wie die Berechnung der benötigten Kraft für die Steigung.<br />
==Luftwiderstand ==<br />
<br />
== Errechnung der Motorkraft ==<br />
''' Folgt noch '''<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
== Weblinks ==<br />
*[[http://de.wikipedia.org/wiki/Haftreibung| Haftreibung]]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[[http://de.wikipedia.org/wiki/Rollreibung| Rollreibung]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10083Motorkraft berechnen2007-02-01T21:47:15Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben. Sollte es unklarheiten geben, bitte die Diskusion nutzen.'''<br />
<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. Es gibt zwar etliche Überschlagsrechnungen, doch leider blieb dem Roboterbauer bisjetzt eine genaue Berechnung vorenthalten. Desshalb '''hat dieser Artikel die Bemühung das Problem möglichst genau zu behandeln.'''<br />
<br />
== Vorwort ==<br />
''' Folgt noch.. '''<br />
== Bewegungseibungen ==<br />
Darunter fallen Haft-,Gleit- und Rollreibung. Diese sind von der Geschwindigkeit unanabhängig.<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss diese Kraft über die Motoren aufwenden um loszufahren. Sie berechnet sich aus:<br />
<br />
<math>F=fh*m*g</math><br />
<br />
F: Kraft in N<br />
<br />
fh: Reibungskoeffizient (Haftreibung)<br />
<br />
m: Masse des Roboters in Kg<br />
<br />
g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<br />
<math>F=fg*m*g</math><br />
<br />
fg: Reibungskoeffizient (Gleitreibung)<br />
<br />
<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<br />
<math>F=fr*m*g</math><br />
<br />
fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Beschleunigen ==<br />
''' Folgt noch'''<br />
=== Benötigte Beschleunigung berechnen ===<br />
Für das Anfahren muss man die benötigte Beschleunigung wissen. Die Beschleunigung wird mit a (engl.: ''Beschleunigung'') bezeichnet. Sie hat die Einheit m/(sec^2). Diese muss man zuerst ermitteln. <br />
<br />
Man kann diese anhand der Geschwindigkeit erechnen. Dabei gilt v=a*t. v ist die Geschwindigkeit in m/sec und t die Zeit in sec. <br />
Auch kann man diese anhand der zurückgelegten Strecke ermitteln. Dabei gilt: s=0.5*t^2*a. s ist die Strecke in m und t die Zeit in Sekunden.<br />
<br />
=== Kraftberechnung ===<br />
Hat man nun die Beschleunigung a ermittelt, kann man die benötigte Kraft mithilfe F=m*a errechnen. Vorraussetzung hierbei ist, dass die Masse konstant bleibt. Das würde also nicht für Roboter mit Raketenantrieb gehen. <br />
<br />
== Bergauf fahren ==<br />
''' Folgt noch '''<br />
==Luftwiderstand ==<br />
''' Folgt noch '''<br />
== Errechnung der Motorkraft ==<br />
''' Folgt noch '''<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
== Weblinks ==<br />
*[[http://de.wikipedia.org/wiki/Haftreibung| Haftreibung]]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[[http://de.wikipedia.org/wiki/Rollreibung| Rollreibung]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10082Motorkraft berechnen2007-02-01T21:45:49Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben. Sollte es unklarheiten geben, bitte die Diskusion nutzen.'''<br />
<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. Es gibt zwar etliche Überschlagsrechnungen, doch leider blieb dem Roboterbauer bisjetzt eine genaue Berechnung vorenthalten. Desshalb '''hat dieser Artikel die Bemühung das Problem möglichst genau zu behandeln.'''<br />
== Bewegungseibungen ==<br />
Darunter fallen Haft-,Gleit- und Rollreibung. Diese sind von der Geschwindigkeit unanabhängig.<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss diese Kraft über die Motoren aufwenden um loszufahren. Sie berechnet sich aus:<br />
<br />
<math>F=fh*m*g</math><br />
<br />
F: Kraft in N<br />
<br />
fh: Reibungskoeffizient (Haftreibung)<br />
<br />
m: Masse des Roboters in Kg<br />
<br />
g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<br />
<math>F=fg*m*g</math><br />
<br />
fg: Reibungskoeffizient (Gleitreibung)<br />
<br />
<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<br />
<math>F=fr*m*g</math><br />
<br />
fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Beschleunigen ==<br />
''' Folgt noch'''<br />
=== Benötigte Beschleunigung berechnen ===<br />
Für das Anfahren muss man die benötigte Beschleunigung wissen. Die Beschleunigung wird mit a (engl.: ''Beschleunigung'') bezeichnet. Sie hat die Einheit m/(sec^2). Diese muss man zuerst ermitteln. <br />
<br />
Man kann diese anhand der Geschwindigkeit erechnen. Dabei gilt v=a*t. v ist die Geschwindigkeit in m/sec und t die Zeit in sec. <br />
Auch kann man diese anhand der zurückgelegten Strecke ermitteln. Dabei gilt: s=0.5*t^2*a. s ist die Strecke in m und t die Zeit in Sekunden.<br />
<br />
=== Kraftberechnung ===<br />
Hat man nun die Beschleunigung a ermittelt, kann man die benötigte Kraft mithilfe F=m*a errechnen. Vorraussetzung hierbei ist, dass die Masse konstant bleibt. Das würde also nicht für Roboter mit Raketenantrieb gehen. <br />
<br />
== Bergauf fahren ==<br />
''' Folgt noch '''<br />
==Luftwiderstand ==<br />
''' Folgt noch '''<br />
== Errechnung der Motorkraft ==<br />
''' Folgt noch '''<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
== Weblinks ==<br />
*[[http://de.wikipedia.org/wiki/Haftreibung| Haftreibung]]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[[http://de.wikipedia.org/wiki/Rollreibung| Rollreibung]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10081Motorkraft berechnen2007-02-01T21:31:27Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben'''<br />
<br />
<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. Es gibt zwar etliche Überschlagsrechnungen, doch leider blieb dem Roboterbauer bisjetzt eine genaue Berechnung vorenthalten. Desshalb '''hat dieser Artikel die Bemühung das Problem möglichst genau zu behandeln.'''<br />
== Reibungen ==<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss diese Kraft über die Motoren aufwenden um loszufahren. Sie berechnet sich aus:<br />
<br />
<math>F=fh*m*g</math><br />
<br />
F: Kraft in N<br />
<br />
fh: Reibungskoeffizient (Haftreibung)<br />
<br />
m: Masse des Roboters in Kg<br />
<br />
g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<br />
<math>F=fg*m*g</math><br />
<br />
fg: Reibungskoeffizient (Gleitreibung)<br />
<br />
<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<br />
<math>F=fr*m*g</math><br />
<br />
fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Anfahren ==<br />
''' Folgt noch'''<br />
== Bergauf fahren ==<br />
''' Folgt noch '''<br />
==Luftwiderstand ==<br />
''' Folgt noch '''<br />
== Errechnung der Motorkraft ==<br />
''' Folgt noch '''<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
== Weblinks ==<br />
*[[http://de.wikipedia.org/wiki/Haftreibung| Haftreibung]]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[[http://de.wikipedia.org/wiki/Rollreibung| Rollreibung]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10080Motorkraft berechnen2007-02-01T21:30:05Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben'''<br />
<br />
<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. Es gibt zwar etliche Überschlagsrechnungen, doch leider blieb dem Roboterbauer bisjetzt eine genaue Berechnung vorenthalten. Desshalb '''hat dieser Artikel hat die Bemühung das Problem möglichst genau zu behandeln.'''<br />
== Reibungen ==<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss über die Motoren diese Kraft aufwenden um loszufahren. Sie berechnet sich aus:<br />
<math>F=fh*m*g</math><br />
F: Kraft in N<br />
<br />
fh: Reibungskoeffizient (Haftreibung)<br />
<br />
m: Masse des Roboters in Kg<br />
<br />
g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<br />
<math>F=fg*m*g</math><br />
<br />
fg: Reibungskoeffizient (Gleitreibung)<br />
<br />
<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<br />
<math>F=fr*m*g</math><br />
<br />
fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Anfahren ==<br />
''' Folgt noch'''<br />
== Bergauf fahren ==<br />
''' Folgt noch '''<br />
==Luftwiderstand ==<br />
''' Folgt noch '''<br />
== Errechnung der Motorkraft ==<br />
''' Folgt noch '''<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
== Weblinks ==<br />
*[[http://de.wikipedia.org/wiki/Haftreibung| Haftreibung]]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[[http://de.wikipedia.org/wiki/Rollreibung| Rollreibung]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10079Motorkraft berechnen2007-02-01T21:27:09Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben'''<br />
<br />
<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. '''Dieser Artikel hat die Bemühung das Problem möglichst genau zu behandeln.'''<br />
== Reibungen ==<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss über die Motoren diese Kraft aufwenden um loszufahren. Sie berechnet sich aus:<br />
<math>F=fh*m*g</math><br />
F: Kraft in N<br />
<br />
fh: Reibungskoeffizient (Haftreibung)<br />
<br />
m: Masse des Roboters in Kg<br />
<br />
g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<br />
<math>F=fg*m*g</math><br />
<br />
fg: Reibungskoeffizient (Gleitreibung)<br />
<br />
<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<br />
<math>F=fr*m*g</math><br />
<br />
fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Anfahren ==<br />
''' Folgt noch'''<br />
== Bergauf fahren ==<br />
''' Folgt noch '''<br />
==Luftwiderstand ==<br />
''' Folgt noch '''<br />
== Errechnung der Motorkraft ==<br />
''' Folgt noch '''<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
== Weblinks ==<br />
*[[http://de.wikipedia.org/wiki/Haftreibung| Haftreibung]]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[[http://de.wikipedia.org/wiki/Rollreibung| Rollreibung]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10078Motorkraft berechnen2007-02-01T21:26:31Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben'''<br />
<br />
<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. '''Dieser Artikel hat die Bemühung das Problem möglichst genau zu behandeln.'''<br />
== Reibungen ==<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss über die Motoren diese Kraft aufwenden um loszufahren. Sie berechnet sich aus:<br />
<math>F=fh*m*g</math><br />
F: Kraft in N<br />
fh: Reibungskoeffizient (Haftreibung)<br />
m: Masse des Roboters in Kg<br />
g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<math>F=fg*m*g</math><br />
fg: Reibungskoeffizient (Gleitreibung)<br />
<br />
<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<math>F=fr*m*g</math><br />
fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Anfahren ==<br />
''' Folgt noch'''<br />
== Bergauf fahren ==<br />
''' Folgt noch '''<br />
==Luftwiderstand ==<br />
''' Folgt noch '''<br />
== Errechnung der Motorkraft ==<br />
''' Folgt noch '''<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
== Weblinks ==<br />
*[[http://de.wikipedia.org/wiki/Haftreibung| Haftreibung]]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[[http://de.wikipedia.org/wiki/Rollreibung| Rollreibung]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10077Motorkraft berechnen2007-02-01T21:26:13Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben'''<br />
<br />
<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. '''Dieser Artikel hat die Bemühung das Problem möglichst genau zu behandeln.'''<br />
== Reibungen ===<br />
=== Haftreibung ===<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss über die Motoren diese Kraft aufwenden um loszufahren. Sie berechnet sich aus:<br />
<math>F=fh*m*g</math><br />
F: Kraft in N<br />
fh: Reibungskoeffizient (Haftreibung)<br />
m: Masse des Roboters in Kg<br />
g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
=== Gleitreibung ===<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<math>F=fg*m*g</math><br />
fg: Reibungskoeffizient (Gleitreibung)<br />
<br />
<br />
=== Rollreibung ===<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<math>F=fr*m*g</math><br />
fr: Reibungskoeffizient (Rollreibung)<br />
<br />
== Anfahren ==<br />
''' Folgt noch'''<br />
== Bergauf fahren ==<br />
''' Folgt noch '''<br />
==Luftwiderstand ==<br />
''' Folgt noch '''<br />
== Errechnung der Motorkraft ==<br />
''' Folgt noch '''<br />
== Autoren ==<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
== Weblinks ==<br />
*[[http://de.wikipedia.org/wiki/Haftreibung| Haftreibung]]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[[http://de.wikipedia.org/wiki/Rollreibung| Rollreibung]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Motorkraft_berechnen&diff=10076Motorkraft berechnen2007-02-01T21:24:52Z<p>Overthere: </p>
<hr />
<div>'''Wichtig: Im Moment wird dieser Artikel noch geschrieben'''<br />
Wenn man einen Roboter plant, stellt man sich häufig die Frage, wie stark die Motoren sein müssen. Sind sie zu schwach kommt der Roboter nicht von der Stelle. Sind sie sie jedoch zu stark verpulvert man unötig Energie und verringert dadurch die Fahrzeit. '''Dieser Artikel hat die Bemühung das Problem möglichst genau zu behandeln.'''<br />
=== Reibungen ===<br />
== Haftreibung ==<br />
Die Reibung die Auftritt wenn der Roboter steht. Der Roboter muss über die Motoren diese Kraft aufwenden um loszufahren. Sie berechnet sich aus:<br />
<math>F=fh*m*g</math><br />
F: Kraft in N<br />
fh: Reibungskoeffizient (Haftreibung)<br />
m: Masse des Roboters in Kg<br />
g: Ortsfaktor (10N/kg bzw. 10m/(sec^2))<br />
'' Die Koeffizienten sind unter den Weblinks verlinkt. ''<br />
== Gleitreibung ==<br />
Wird beim Roboter eigentlich nicht benötigt da dieser nicht gleiten sollte. Jedoch will ich diese hier kurz anschneiden.<br />
<math>F=fg*m*g</math><br />
fg: Reibungskoeffizient (Gleitreibung)<br />
<br />
<br />
== Rollreibung ==<br />
Wie der Name schon sagt tritt diese Kraft beim Fahren auf. Diese errechnet sich folgendermaßen.<br />
<math>F=fr*m*g</math><br />
fr: Reibungskoeffizient (Rollreibung)<br />
<br />
=== Anfahren ===<br />
''' Folgt noch'''<br />
=== Bergauf fahren ===<br />
''' Folgt noch '''<br />
=== Luftwiderstand ===<br />
''' Folgt noch '''<br />
=== Errechnung der Motorkraft ===<br />
''' Folgt noch '''<br />
=== Autoren ===<br />
*--[[Benutzer:Overthere|Overthere]] 22:24, 1. Feb 2007 (CET)<br />
=== Weblinks ==<br />
*[[http://de.wikipedia.org/wiki/Haftreibung| Haftreibung]]<br />
*'' Koeffizienten für Gleitreibugng werden noch gesucht ''<br />
*[[http://de.wikipedia.org/wiki/Rollreibung| Rollreibung]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Kleinsignalverst%C3%A4rker&diff=10051Kleinsignalverstärker2007-01-23T07:43:28Z<p>Overthere: </p>
<hr />
<div>Schaltung für einen Ultraschallsignal-Verstärker<br />
<br />
<br />
'''Verstärkung von Signalen.'''<br />
<br />
Analoge Signale, wie sie beim Messen mit Sensoren vorkommen, werden meistens mit Operationsverstärkerschaltungen verarbeitet, die das Signal nach Möglichkeit über einen großen Bereich linear umsetzen. In speziellen Fällen wie beim Ultraschallempfänger, bei dem ein 40kHz-Signal verstärkt werden soll, kommt es aber auch vor, dass die Wirkungsweise einer Transistorschaltung äußerst zweckmäßig ist. Eine solche Verstärkerstufe mit einem Transistor, bei der die Verstärkung einstellbar ist, wird hier behandelt. Die Arbeitspunktgrößen beispielsweise für Spannung und Widerstand werden mit großen Buchstaben (U, R) benannt und die Signalgrößen mit kleinen Buchstaben (u, r).<br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild1.jpg]]<br />
<br />
<br />
'''Operationsverstärker:'''Bei der Operationsverstärkerschaltung links gilt U2 / U1 = -R2 / R1. Bei der Transistorschaltung in der Mitte gilt für relativ kleine AC-Signale in gewisser Näherung das gleiche u2 / u1 = -r2 / r1. <br />
<br />
'''Transistorenverstärker:'''<br />
Bei einer hohen Stromverstärkung ß >= 300 ist der Kollektorstrom etwa genauso groß wie der Emitterstrom und durch die Widerstände R1 und R2 fließt der gleiche Strom. Da sich die Spannung an Ub und GND nicht ändert, sind die Änderungen an R1 und R2 proportional der Widerstände und unterschiedlich gerichtet. <br />
<br />
Soweit besteht auch noch kein Unterschied zwischen R und r. Für R1 ist bei genauerer Betrachtung der Widerstand der Basis Emitter Diode mit zu berücksichtigen.<br />
<br />
<br />
Zur genaueren Betrachtung wird auf eine Schaltung ohne den Widerstand R1 übergegangen, die Schaltung rechts. Auch hier steigt der Emitterstrom bei einem Anstieg der Basisspannung nicht beliebig steil an. Der Emitterstrom ist durch die Diodengleichung ([[#Weblinks|siehe WikiPedia unter Weblinks]]) beschrieben.<br />
<br />
<math>I_e = I_s * ( e^{\frac{U1}{n*u_t}}- 1 )</math> <br />
<br />
mit ut = 26mV und n = 1...2<br />
<br />
Der differenzielle Widerstand r1 ist n * ut / Ie. Bei n = 1,2 ist n * ut = 30mV. <br />
<br />
Der Stromanstieg pro Spannungsanstieg an der Basis-Emitter-Diode wird auch die Steilheit S des Transistors genannt, der differenzielle Widerstand r1 ist damit 1/S. <br />
<br />
Damit gilt r1 = 1 / S = 30mV / Ie. <br />
<br />
<br />
Dazu kommt dann noch der Widerstand zwischen Emitter und GND, der hier aber weggelassen wurde. Man erhält damit einen Verstärker, dessen Verstärkung über den Emitterstrom steuerbar ist. <br />
<br />
Die Verstärkung ist u2 / u1:<br />
<br />
v = -R2 * Ie / 30mV<br />
<br />
Für R2 = 3kOhm gilt damit:<br />
<br />
v ( Ie = 10 µA ) = -1<br />
<br />
v ( Ie = 100µA) = -10<br />
<br />
v ( Ie = 1 mA ) = -100<br />
<br />
Bei R2 = 3kOhm kommt es damit schon zu einer deutlichen Arbeitspunktverschiebung und die Kollektorspannung wird je nach Versorgungsspannung bald zu gering. <br />
<br />
<br />
'''Schmalbandverstärker'''<br />
<br />
Für Wechselspannungssignale geht es aber weiter. Ein Parallelschwingkreis hat einen kleinen Widerstand für Gleichstrom und einen relativ hohen Widerstand für Wechselstrom. <br />
<br />
Der Gleichstromwiderstand ist etwa der Widerstand der Spule. Der Betrag des Wechselstromwiderstands ist relativ leicht in guter Näherung zu berechnen. Es sind die drei Leitwerte 1/R2, 1/jwL und -jwC zu addieren. <br />
<br />
Für den Leitwert ergibt das zusammen 1/R2 + j( 1/wl – wC ) mit dem Betrag <br />
<math>\sqrt{\left( \frac{1}{R_2} \right)^2 + \left( \frac{1}{wL}- wC \right)^2}</math><br />
<br />
<br />
Der Betrag des Widerstandes über der Frequenz ist im Bild aufgetragen, für die Widerstandswerte von R2 = 1,0k 1,5k 2,2k (grau) 3,3k 4,7k 6,8k (rot) 10k 15k 22k (blau)<br />
<br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild2.jpg]]<br />
<br />
<br />
Mit L = 4,7mH und C = 3,3nF ergibt sich eine Resonanzfrequenz von 40,4kHz und ein Betrag des Widerstands der etwa so groß ist wie der Parallelwiderstand R2. Bis zu einem Grenzwert der durch die Spulengüte gegeben ist der etwa bei 30-50 liegt und den Widerstand auf 30-50kOhm begrenzt. <br />
Damit lässt sich dann bei 1mA Emitterstrom mit dem Widerstand im Emitterzweig von 1/S = 30Ohm eine Verstärkung von v = –1000 erreichen. <br />
<br />
<br />
'''Frequenzabgleich'''<br />
<br />
Bei einer hohen Güte erkennt man die Empfindlichkeit des Resonanzkreises gegen Toleranzen der Bauelemente. Eine Abweichung von 10 Prozent führt im Beispiel schon zu einem Abfall der Verstärkung um den Faktor 4 (oberste blaue Kurve). <br />
<br />
Bei Nutzung der hohen Verstärkung ist deshalb eine Abgleichmöglichkeit von Vorteil. <br />
Den Kondensator kann man nicht abstimmen, doch die Spule ist als offener Zylinderkern ausgeführt und lässt damit einen Abgleich bei gleichzeitiger Verbesserung der Güte zu. <br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild3.jpg]] <br />
<br />
<br />
Die radialen Zylinderspulen gestatten (ähnlich wie die axialen Zylinderspulen) bei paarweisem Einsatz einen Abstimmbereich von etwa dem 2-fachen Wert (keine oder geringe Kopplung) bis zum 3-fachen Wert (relativ enge Kopplung). <br />
<br />
Eine Induktivität von 4,7mH kann damit aus 2 Induktivitäten von 1,8mH zusammengesetzt werden, die einen Abstimmbereich von 3,6mH bis 5,4mH haben. <br />
Zusammen mit einer Kapazität von 3,3nF ergibt sich ein Abstimmbereich von 36kHz bis 44kHz. Sie sind hierfür nicht zu kurz einzubauen und nach dem Abgleich mit etwas Heisskleber zu fixieren.<br />
<br />
Manfred<br />
<br />
<br />
==Siehe auch==<br />
* [[Operationsverstärker]]<br />
* [[Ultraschall Interface]] <br />
<br />
==Weblinks==<br />
* http://de.wikipedia.org/wiki/Diode<br />
<br />
[[Kategorie:Elektronik]]<br />
[[Kategorie:Projekte]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Kleinsignalverst%C3%A4rker&diff=10050Kleinsignalverstärker2007-01-23T07:43:11Z<p>Overthere: </p>
<hr />
<div>Schaltung für einen Ultraschallsignal-Verstärker<br />
<br />
<br />
'''Verstärkung von Signalen.'''<br />
<br />
Analoge Signale, wie sie beim Messen mit Sensoren vorkommen, werden meistens mit Operationsverstärkerschaltungen verarbeitet, die das Signal nach Möglichkeit über einen großen Bereich linear umsetzen. In speziellen Fällen wie beim Ultraschallempfänger, bei dem ein 40kHz-Signal verstärkt werden soll, kommt es aber auch vor, dass die Wirkungsweise einer Transistorschaltung äußerst zweckmäßig ist. Eine solche Verstärkerstufe mit einem Transistor, bei der die Verstärkung einstellbar ist, wird hier behandelt. Die Arbeitspunktgrößen beispielsweise für Spannung und Widerstand werden mit großen Buchstaben (U, R) benannt und die Signalgrößen mit kleinen Buchstaben (u, r).<br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild1.jpg]]<br />
<br />
<br />
'''Verstärkungsfaktor'''<br />
'''Operationsverstärker:'''Bei der Operationsverstärkerschaltung links gilt U2 / U1 = -R2 / R1. Bei der Transistorschaltung in der Mitte gilt für relativ kleine AC-Signale in gewisser Näherung das gleiche u2 / u1 = -r2 / r1. <br />
<br />
'''Transistorenverstärker:'''<br />
Bei einer hohen Stromverstärkung ß >= 300 ist der Kollektorstrom etwa genauso groß wie der Emitterstrom und durch die Widerstände R1 und R2 fließt der gleiche Strom. Da sich die Spannung an Ub und GND nicht ändert, sind die Änderungen an R1 und R2 proportional der Widerstände und unterschiedlich gerichtet. <br />
<br />
Soweit besteht auch noch kein Unterschied zwischen R und r. Für R1 ist bei genauerer Betrachtung der Widerstand der Basis Emitter Diode mit zu berücksichtigen.<br />
<br />
<br />
Zur genaueren Betrachtung wird auf eine Schaltung ohne den Widerstand R1 übergegangen, die Schaltung rechts. Auch hier steigt der Emitterstrom bei einem Anstieg der Basisspannung nicht beliebig steil an. Der Emitterstrom ist durch die Diodengleichung ([[#Weblinks|siehe WikiPedia unter Weblinks]]) beschrieben.<br />
<br />
<math>I_e = I_s * ( e^{\frac{U1}{n*u_t}}- 1 )</math> <br />
<br />
mit ut = 26mV und n = 1...2<br />
<br />
Der differenzielle Widerstand r1 ist n * ut / Ie. Bei n = 1,2 ist n * ut = 30mV. <br />
<br />
Der Stromanstieg pro Spannungsanstieg an der Basis-Emitter-Diode wird auch die Steilheit S des Transistors genannt, der differenzielle Widerstand r1 ist damit 1/S. <br />
<br />
Damit gilt r1 = 1 / S = 30mV / Ie. <br />
<br />
<br />
Dazu kommt dann noch der Widerstand zwischen Emitter und GND, der hier aber weggelassen wurde. Man erhält damit einen Verstärker, dessen Verstärkung über den Emitterstrom steuerbar ist. <br />
<br />
Die Verstärkung ist u2 / u1:<br />
<br />
v = -R2 * Ie / 30mV<br />
<br />
Für R2 = 3kOhm gilt damit:<br />
<br />
v ( Ie = 10 µA ) = -1<br />
<br />
v ( Ie = 100µA) = -10<br />
<br />
v ( Ie = 1 mA ) = -100<br />
<br />
Bei R2 = 3kOhm kommt es damit schon zu einer deutlichen Arbeitspunktverschiebung und die Kollektorspannung wird je nach Versorgungsspannung bald zu gering. <br />
<br />
<br />
'''Schmalbandverstärker'''<br />
<br />
Für Wechselspannungssignale geht es aber weiter. Ein Parallelschwingkreis hat einen kleinen Widerstand für Gleichstrom und einen relativ hohen Widerstand für Wechselstrom. <br />
<br />
Der Gleichstromwiderstand ist etwa der Widerstand der Spule. Der Betrag des Wechselstromwiderstands ist relativ leicht in guter Näherung zu berechnen. Es sind die drei Leitwerte 1/R2, 1/jwL und -jwC zu addieren. <br />
<br />
Für den Leitwert ergibt das zusammen 1/R2 + j( 1/wl – wC ) mit dem Betrag <br />
<math>\sqrt{\left( \frac{1}{R_2} \right)^2 + \left( \frac{1}{wL}- wC \right)^2}</math><br />
<br />
<br />
Der Betrag des Widerstandes über der Frequenz ist im Bild aufgetragen, für die Widerstandswerte von R2 = 1,0k 1,5k 2,2k (grau) 3,3k 4,7k 6,8k (rot) 10k 15k 22k (blau)<br />
<br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild2.jpg]]<br />
<br />
<br />
Mit L = 4,7mH und C = 3,3nF ergibt sich eine Resonanzfrequenz von 40,4kHz und ein Betrag des Widerstands der etwa so groß ist wie der Parallelwiderstand R2. Bis zu einem Grenzwert der durch die Spulengüte gegeben ist der etwa bei 30-50 liegt und den Widerstand auf 30-50kOhm begrenzt. <br />
Damit lässt sich dann bei 1mA Emitterstrom mit dem Widerstand im Emitterzweig von 1/S = 30Ohm eine Verstärkung von v = –1000 erreichen. <br />
<br />
<br />
'''Frequenzabgleich'''<br />
<br />
Bei einer hohen Güte erkennt man die Empfindlichkeit des Resonanzkreises gegen Toleranzen der Bauelemente. Eine Abweichung von 10 Prozent führt im Beispiel schon zu einem Abfall der Verstärkung um den Faktor 4 (oberste blaue Kurve). <br />
<br />
Bei Nutzung der hohen Verstärkung ist deshalb eine Abgleichmöglichkeit von Vorteil. <br />
Den Kondensator kann man nicht abstimmen, doch die Spule ist als offener Zylinderkern ausgeführt und lässt damit einen Abgleich bei gleichzeitiger Verbesserung der Güte zu. <br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild3.jpg]] <br />
<br />
<br />
Die radialen Zylinderspulen gestatten (ähnlich wie die axialen Zylinderspulen) bei paarweisem Einsatz einen Abstimmbereich von etwa dem 2-fachen Wert (keine oder geringe Kopplung) bis zum 3-fachen Wert (relativ enge Kopplung). <br />
<br />
Eine Induktivität von 4,7mH kann damit aus 2 Induktivitäten von 1,8mH zusammengesetzt werden, die einen Abstimmbereich von 3,6mH bis 5,4mH haben. <br />
Zusammen mit einer Kapazität von 3,3nF ergibt sich ein Abstimmbereich von 36kHz bis 44kHz. Sie sind hierfür nicht zu kurz einzubauen und nach dem Abgleich mit etwas Heisskleber zu fixieren.<br />
<br />
Manfred<br />
<br />
<br />
==Siehe auch==<br />
* [[Operationsverstärker]]<br />
* [[Ultraschall Interface]] <br />
<br />
==Weblinks==<br />
* http://de.wikipedia.org/wiki/Diode<br />
<br />
[[Kategorie:Elektronik]]<br />
[[Kategorie:Projekte]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Kleinsignalverst%C3%A4rker&diff=10049Kleinsignalverstärker2007-01-23T07:42:47Z<p>Overthere: </p>
<hr />
<div>Schaltung für einen Ultraschallsignal-Verstärker<br />
<br />
<br />
'''Verstärkung von Signalen.'''<br />
<br />
Analoge Signale, wie sie beim Messen mit Sensoren vorkommen, werden meistens mit Operationsverstärkerschaltungen verarbeitet, die das Signal nach Möglichkeit über einen großen Bereich linear umsetzen. In speziellen Fällen wie beim Ultraschallempfänger, bei dem ein 40kHz-Signal verstärkt werden soll, kommt es aber auch vor, dass die Wirkungsweise einer Transistorschaltung äußerst zweckmäßig ist. Eine solche Verstärkerstufe mit einem Transistor, bei der die Verstärkung einstellbar ist, wird hier behandelt. Die Arbeitspunktgrößen beispielsweise für Spannung und Widerstand werden mit großen Buchstaben (U, R) benannt und die Signalgrößen mit kleinen Buchstaben (u, r).<br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild1.jpg]]<br />
<br />
<br />
'''Verstärkungsfaktor'''<br />
<br />
'''Operationsverstärker:'''<br />
<br />
Bei der Operationsverstärkerschaltung links gilt U2 / U1 = -R2 / R1. Bei der Transistorschaltung in der Mitte gilt für relativ kleine AC-Signale in gewisser Näherung das gleiche u2 / u1 = -r2 / r1. <br />
<br />
'''Transistorenverstärker:'''<br />
Bei einer hohen Stromverstärkung ß >= 300 ist der Kollektorstrom etwa genauso groß wie der Emitterstrom und durch die Widerstände R1 und R2 fließt der gleiche Strom. Da sich die Spannung an Ub und GND nicht ändert, sind die Änderungen an R1 und R2 proportional der Widerstände und unterschiedlich gerichtet. <br />
<br />
Soweit besteht auch noch kein Unterschied zwischen R und r. Für R1 ist bei genauerer Betrachtung der Widerstand der Basis Emitter Diode mit zu berücksichtigen.<br />
<br />
<br />
Zur genaueren Betrachtung wird auf eine Schaltung ohne den Widerstand R1 übergegangen, die Schaltung rechts. Auch hier steigt der Emitterstrom bei einem Anstieg der Basisspannung nicht beliebig steil an. Der Emitterstrom ist durch die Diodengleichung ([[#Weblinks|siehe WikiPedia unter Weblinks]]) beschrieben.<br />
<br />
<math>I_e = I_s * ( e^{\frac{U1}{n*u_t}}- 1 )</math> <br />
<br />
mit ut = 26mV und n = 1...2<br />
<br />
Der differenzielle Widerstand r1 ist n * ut / Ie. Bei n = 1,2 ist n * ut = 30mV. <br />
<br />
Der Stromanstieg pro Spannungsanstieg an der Basis-Emitter-Diode wird auch die Steilheit S des Transistors genannt, der differenzielle Widerstand r1 ist damit 1/S. <br />
<br />
Damit gilt r1 = 1 / S = 30mV / Ie. <br />
<br />
<br />
Dazu kommt dann noch der Widerstand zwischen Emitter und GND, der hier aber weggelassen wurde. Man erhält damit einen Verstärker, dessen Verstärkung über den Emitterstrom steuerbar ist. <br />
<br />
Die Verstärkung ist u2 / u1:<br />
<br />
v = -R2 * Ie / 30mV<br />
<br />
Für R2 = 3kOhm gilt damit:<br />
<br />
v ( Ie = 10 µA ) = -1<br />
<br />
v ( Ie = 100µA) = -10<br />
<br />
v ( Ie = 1 mA ) = -100<br />
<br />
Bei R2 = 3kOhm kommt es damit schon zu einer deutlichen Arbeitspunktverschiebung und die Kollektorspannung wird je nach Versorgungsspannung bald zu gering. <br />
<br />
<br />
'''Schmalbandverstärker'''<br />
<br />
Für Wechselspannungssignale geht es aber weiter. Ein Parallelschwingkreis hat einen kleinen Widerstand für Gleichstrom und einen relativ hohen Widerstand für Wechselstrom. <br />
<br />
Der Gleichstromwiderstand ist etwa der Widerstand der Spule. Der Betrag des Wechselstromwiderstands ist relativ leicht in guter Näherung zu berechnen. Es sind die drei Leitwerte 1/R2, 1/jwL und -jwC zu addieren. <br />
<br />
Für den Leitwert ergibt das zusammen 1/R2 + j( 1/wl – wC ) mit dem Betrag <br />
<math>\sqrt{\left( \frac{1}{R_2} \right)^2 + \left( \frac{1}{wL}- wC \right)^2}</math><br />
<br />
<br />
Der Betrag des Widerstandes über der Frequenz ist im Bild aufgetragen, für die Widerstandswerte von R2 = 1,0k 1,5k 2,2k (grau) 3,3k 4,7k 6,8k (rot) 10k 15k 22k (blau)<br />
<br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild2.jpg]]<br />
<br />
<br />
Mit L = 4,7mH und C = 3,3nF ergibt sich eine Resonanzfrequenz von 40,4kHz und ein Betrag des Widerstands der etwa so groß ist wie der Parallelwiderstand R2. Bis zu einem Grenzwert der durch die Spulengüte gegeben ist der etwa bei 30-50 liegt und den Widerstand auf 30-50kOhm begrenzt. <br />
Damit lässt sich dann bei 1mA Emitterstrom mit dem Widerstand im Emitterzweig von 1/S = 30Ohm eine Verstärkung von v = –1000 erreichen. <br />
<br />
<br />
'''Frequenzabgleich'''<br />
<br />
Bei einer hohen Güte erkennt man die Empfindlichkeit des Resonanzkreises gegen Toleranzen der Bauelemente. Eine Abweichung von 10 Prozent führt im Beispiel schon zu einem Abfall der Verstärkung um den Faktor 4 (oberste blaue Kurve). <br />
<br />
Bei Nutzung der hohen Verstärkung ist deshalb eine Abgleichmöglichkeit von Vorteil. <br />
Den Kondensator kann man nicht abstimmen, doch die Spule ist als offener Zylinderkern ausgeführt und lässt damit einen Abgleich bei gleichzeitiger Verbesserung der Güte zu. <br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild3.jpg]] <br />
<br />
<br />
Die radialen Zylinderspulen gestatten (ähnlich wie die axialen Zylinderspulen) bei paarweisem Einsatz einen Abstimmbereich von etwa dem 2-fachen Wert (keine oder geringe Kopplung) bis zum 3-fachen Wert (relativ enge Kopplung). <br />
<br />
Eine Induktivität von 4,7mH kann damit aus 2 Induktivitäten von 1,8mH zusammengesetzt werden, die einen Abstimmbereich von 3,6mH bis 5,4mH haben. <br />
Zusammen mit einer Kapazität von 3,3nF ergibt sich ein Abstimmbereich von 36kHz bis 44kHz. Sie sind hierfür nicht zu kurz einzubauen und nach dem Abgleich mit etwas Heisskleber zu fixieren.<br />
<br />
Manfred<br />
<br />
<br />
==Siehe auch==<br />
* [[Operationsverstärker]]<br />
* [[Ultraschall Interface]] <br />
<br />
==Weblinks==<br />
* http://de.wikipedia.org/wiki/Diode<br />
<br />
[[Kategorie:Elektronik]]<br />
[[Kategorie:Projekte]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Kleinsignalverst%C3%A4rker&diff=10048Kleinsignalverstärker2007-01-23T07:42:14Z<p>Overthere: </p>
<hr />
<div>Schaltung für einen Ultraschallsignal-Verstärker<br />
<br />
<br />
'''Verstärkung von Signalen.'''<br />
<br />
Analoge Signale, wie sie beim Messen mit Sensoren vorkommen, werden meistens mit Operationsverstärkerschaltungen verarbeitet, die das Signal nach Möglichkeit über einen großen Bereich linear umsetzen. In speziellen Fällen wie beim Ultraschallempfänger, bei dem ein 40kHz-Signal verstärkt werden soll, kommt es aber auch vor, dass die Wirkungsweise einer Transistorschaltung äußerst zweckmäßig ist. Eine solche Verstärkerstufe mit einem Transistor, bei der die Verstärkung einstellbar ist, wird hier behandelt. Die Arbeitspunktgrößen beispielsweise für Spannung und Widerstand werden mit großen Buchstaben (U, R) benannt und die Signalgrößen mit kleinen Buchstaben (u, r).<br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild1.jpg]]<br />
<br />
<br />
'''Verstärkungsfaktor'''<br />
<br />
''Operationsverstärker''<br />
Bei der Operationsverstärkerschaltung links gilt U2 / U1 = -R2 / R1. Bei der Transistorschaltung in der Mitte gilt für relativ kleine AC-Signale in gewisser Näherung das gleiche u2 / u1 = -r2 / r1. <br />
<br />
''Transistorenverstärker''<br />
Bei einer hohen Stromverstärkung ß >= 300 ist der Kollektorstrom etwa genauso groß wie der Emitterstrom und durch die Widerstände R1 und R2 fließt der gleiche Strom. Da sich die Spannung an Ub und GND nicht ändert, sind die Änderungen an R1 und R2 proportional der Widerstände und unterschiedlich gerichtet. <br />
<br />
Soweit besteht auch noch kein Unterschied zwischen R und r. Für R1 ist bei genauerer Betrachtung der Widerstand der Basis Emitter Diode mit zu berücksichtigen.<br />
<br />
<br />
Zur genaueren Betrachtung wird auf eine Schaltung ohne den Widerstand R1 übergegangen, die Schaltung rechts. Auch hier steigt der Emitterstrom bei einem Anstieg der Basisspannung nicht beliebig steil an. Der Emitterstrom ist durch die Diodengleichung ([[#Weblinks|siehe WikiPedia unter Weblinks]]) beschrieben.<br />
<br />
<math>I_e = I_s * ( e^{\frac{U1}{n*u_t}}- 1 )</math> <br />
<br />
mit ut = 26mV und n = 1...2<br />
<br />
Der differenzielle Widerstand r1 ist n * ut / Ie. Bei n = 1,2 ist n * ut = 30mV. <br />
<br />
Der Stromanstieg pro Spannungsanstieg an der Basis-Emitter-Diode wird auch die Steilheit S des Transistors genannt, der differenzielle Widerstand r1 ist damit 1/S. <br />
<br />
Damit gilt r1 = 1 / S = 30mV / Ie. <br />
<br />
<br />
Dazu kommt dann noch der Widerstand zwischen Emitter und GND, der hier aber weggelassen wurde. Man erhält damit einen Verstärker, dessen Verstärkung über den Emitterstrom steuerbar ist. <br />
<br />
Die Verstärkung ist u2 / u1:<br />
<br />
v = -R2 * Ie / 30mV<br />
<br />
Für R2 = 3kOhm gilt damit:<br />
<br />
v ( Ie = 10 µA ) = -1<br />
<br />
v ( Ie = 100µA) = -10<br />
<br />
v ( Ie = 1 mA ) = -100<br />
<br />
Bei R2 = 3kOhm kommt es damit schon zu einer deutlichen Arbeitspunktverschiebung und die Kollektorspannung wird je nach Versorgungsspannung bald zu gering. <br />
<br />
<br />
'''Schmalbandverstärker'''<br />
<br />
Für Wechselspannungssignale geht es aber weiter. Ein Parallelschwingkreis hat einen kleinen Widerstand für Gleichstrom und einen relativ hohen Widerstand für Wechselstrom. <br />
<br />
Der Gleichstromwiderstand ist etwa der Widerstand der Spule. Der Betrag des Wechselstromwiderstands ist relativ leicht in guter Näherung zu berechnen. Es sind die drei Leitwerte 1/R2, 1/jwL und -jwC zu addieren. <br />
<br />
Für den Leitwert ergibt das zusammen 1/R2 + j( 1/wl – wC ) mit dem Betrag <br />
<math>\sqrt{\left( \frac{1}{R_2} \right)^2 + \left( \frac{1}{wL}- wC \right)^2}</math><br />
<br />
<br />
Der Betrag des Widerstandes über der Frequenz ist im Bild aufgetragen, für die Widerstandswerte von R2 = 1,0k 1,5k 2,2k (grau) 3,3k 4,7k 6,8k (rot) 10k 15k 22k (blau)<br />
<br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild2.jpg]]<br />
<br />
<br />
Mit L = 4,7mH und C = 3,3nF ergibt sich eine Resonanzfrequenz von 40,4kHz und ein Betrag des Widerstands der etwa so groß ist wie der Parallelwiderstand R2. Bis zu einem Grenzwert der durch die Spulengüte gegeben ist der etwa bei 30-50 liegt und den Widerstand auf 30-50kOhm begrenzt. <br />
Damit lässt sich dann bei 1mA Emitterstrom mit dem Widerstand im Emitterzweig von 1/S = 30Ohm eine Verstärkung von v = –1000 erreichen. <br />
<br />
<br />
'''Frequenzabgleich'''<br />
<br />
Bei einer hohen Güte erkennt man die Empfindlichkeit des Resonanzkreises gegen Toleranzen der Bauelemente. Eine Abweichung von 10 Prozent führt im Beispiel schon zu einem Abfall der Verstärkung um den Faktor 4 (oberste blaue Kurve). <br />
<br />
Bei Nutzung der hohen Verstärkung ist deshalb eine Abgleichmöglichkeit von Vorteil. <br />
Den Kondensator kann man nicht abstimmen, doch die Spule ist als offener Zylinderkern ausgeführt und lässt damit einen Abgleich bei gleichzeitiger Verbesserung der Güte zu. <br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild3.jpg]] <br />
<br />
<br />
Die radialen Zylinderspulen gestatten (ähnlich wie die axialen Zylinderspulen) bei paarweisem Einsatz einen Abstimmbereich von etwa dem 2-fachen Wert (keine oder geringe Kopplung) bis zum 3-fachen Wert (relativ enge Kopplung). <br />
<br />
Eine Induktivität von 4,7mH kann damit aus 2 Induktivitäten von 1,8mH zusammengesetzt werden, die einen Abstimmbereich von 3,6mH bis 5,4mH haben. <br />
Zusammen mit einer Kapazität von 3,3nF ergibt sich ein Abstimmbereich von 36kHz bis 44kHz. Sie sind hierfür nicht zu kurz einzubauen und nach dem Abgleich mit etwas Heisskleber zu fixieren.<br />
<br />
Manfred<br />
<br />
<br />
==Siehe auch==<br />
* [[Operationsverstärker]]<br />
* [[Ultraschall Interface]] <br />
<br />
==Weblinks==<br />
* http://de.wikipedia.org/wiki/Diode<br />
<br />
[[Kategorie:Elektronik]]<br />
[[Kategorie:Projekte]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Kleinsignalverst%C3%A4rker&diff=10047Kleinsignalverstärker2007-01-23T07:41:33Z<p>Overthere: </p>
<hr />
<div>Schaltung für einen Ultraschallsignal-Verstärker<br />
<br />
<br />
'''Verstärkung von Signalen.'''<br />
<br />
Analoge Signale, wie sie beim Messen mit Sensoren vorkommen, werden meistens mit Operationsverstärkerschaltungen verarbeitet, die das Signal nach Möglichkeit über einen großen Bereich linear umsetzen. In speziellen Fällen wie beim Ultraschallempfänger, bei dem ein 40kHz-Signal verstärkt werden soll, kommt es aber auch vor, dass die Wirkungsweise einer Transistorschaltung äußerst zweckmäßig ist. Eine solche Verstärkerstufe mit einem Transistor, bei der die Verstärkung einstellbar ist, wird hier behandelt. Die Arbeitspunktgrößen beispielsweise für Spannung und Widerstand werden mit großen Buchstaben (U, R) benannt und die Signalgrößen mit kleinen Buchstaben (u, r).<br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild1.jpg]]<br />
<br />
<br />
'''Verstärkungsfaktor'''<br />
'Operationsverstärker'<br />
Bei der Operationsverstärkerschaltung links gilt U2 / U1 = -R2 / R1. Bei der Transistorschaltung in der Mitte gilt für relativ kleine AC-Signale in gewisser Näherung das gleiche u2 / u1 = -r2 / r1. <br />
<br />
'Transistorenverstärker'<br />
Bei einer hohen Stromverstärkung ß >= 300 ist der Kollektorstrom etwa genauso groß wie der Emitterstrom und durch die Widerstände R1 und R2 fließt der gleiche Strom. Da sich die Spannung an Ub und GND nicht ändert, sind die Änderungen an R1 und R2 proportional der Widerstände und unterschiedlich gerichtet. <br />
<br />
Soweit besteht auch noch kein Unterschied zwischen R und r. Für R1 ist bei genauerer Betrachtung der Widerstand der Basis Emitter Diode mit zu berücksichtigen.<br />
<br />
<br />
Zur genaueren Betrachtung wird auf eine Schaltung ohne den Widerstand R1 übergegangen, die Schaltung rechts. Auch hier steigt der Emitterstrom bei einem Anstieg der Basisspannung nicht beliebig steil an. Der Emitterstrom ist durch die Diodengleichung ([[#Weblinks|siehe WikiPedia unter Weblinks]]) beschrieben.<br />
<br />
<math>I_e = I_s * ( e^{\frac{U1}{n*u_t}}- 1 )</math> <br />
<br />
mit ut = 26mV und n = 1...2<br />
<br />
Der differenzielle Widerstand r1 ist n * ut / Ie. Bei n = 1,2 ist n * ut = 30mV. <br />
<br />
Der Stromanstieg pro Spannungsanstieg an der Basis-Emitter-Diode wird auch die Steilheit S des Transistors genannt, der differenzielle Widerstand r1 ist damit 1/S. <br />
<br />
Damit gilt r1 = 1 / S = 30mV / Ie. <br />
<br />
<br />
Dazu kommt dann noch der Widerstand zwischen Emitter und GND, der hier aber weggelassen wurde. Man erhält damit einen Verstärker, dessen Verstärkung über den Emitterstrom steuerbar ist. <br />
<br />
Die Verstärkung ist u2 / u1:<br />
<br />
v = -R2 * Ie / 30mV<br />
<br />
Für R2 = 3kOhm gilt damit:<br />
<br />
v ( Ie = 10 µA ) = -1<br />
<br />
v ( Ie = 100µA) = -10<br />
<br />
v ( Ie = 1 mA ) = -100<br />
<br />
Bei R2 = 3kOhm kommt es damit schon zu einer deutlichen Arbeitspunktverschiebung und die Kollektorspannung wird je nach Versorgungsspannung bald zu gering. <br />
<br />
<br />
'''Schmalbandverstärker'''<br />
<br />
Für Wechselspannungssignale geht es aber weiter. Ein Parallelschwingkreis hat einen kleinen Widerstand für Gleichstrom und einen relativ hohen Widerstand für Wechselstrom. <br />
<br />
Der Gleichstromwiderstand ist etwa der Widerstand der Spule. Der Betrag des Wechselstromwiderstands ist relativ leicht in guter Näherung zu berechnen. Es sind die drei Leitwerte 1/R2, 1/jwL und -jwC zu addieren. <br />
<br />
Für den Leitwert ergibt das zusammen 1/R2 + j( 1/wl – wC ) mit dem Betrag <br />
<math>\sqrt{\left( \frac{1}{R_2} \right)^2 + \left( \frac{1}{wL}- wC \right)^2}</math><br />
<br />
<br />
Der Betrag des Widerstandes über der Frequenz ist im Bild aufgetragen, für die Widerstandswerte von R2 = 1,0k 1,5k 2,2k (grau) 3,3k 4,7k 6,8k (rot) 10k 15k 22k (blau)<br />
<br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild2.jpg]]<br />
<br />
<br />
Mit L = 4,7mH und C = 3,3nF ergibt sich eine Resonanzfrequenz von 40,4kHz und ein Betrag des Widerstands der etwa so groß ist wie der Parallelwiderstand R2. Bis zu einem Grenzwert der durch die Spulengüte gegeben ist der etwa bei 30-50 liegt und den Widerstand auf 30-50kOhm begrenzt. <br />
Damit lässt sich dann bei 1mA Emitterstrom mit dem Widerstand im Emitterzweig von 1/S = 30Ohm eine Verstärkung von v = –1000 erreichen. <br />
<br />
<br />
'''Frequenzabgleich'''<br />
<br />
Bei einer hohen Güte erkennt man die Empfindlichkeit des Resonanzkreises gegen Toleranzen der Bauelemente. Eine Abweichung von 10 Prozent führt im Beispiel schon zu einem Abfall der Verstärkung um den Faktor 4 (oberste blaue Kurve). <br />
<br />
Bei Nutzung der hohen Verstärkung ist deshalb eine Abgleichmöglichkeit von Vorteil. <br />
Den Kondensator kann man nicht abstimmen, doch die Spule ist als offener Zylinderkern ausgeführt und lässt damit einen Abgleich bei gleichzeitiger Verbesserung der Güte zu. <br />
<br />
[[Bild:Kleinsignalverst%C3%A4rker_Bild3.jpg]] <br />
<br />
<br />
Die radialen Zylinderspulen gestatten (ähnlich wie die axialen Zylinderspulen) bei paarweisem Einsatz einen Abstimmbereich von etwa dem 2-fachen Wert (keine oder geringe Kopplung) bis zum 3-fachen Wert (relativ enge Kopplung). <br />
<br />
Eine Induktivität von 4,7mH kann damit aus 2 Induktivitäten von 1,8mH zusammengesetzt werden, die einen Abstimmbereich von 3,6mH bis 5,4mH haben. <br />
Zusammen mit einer Kapazität von 3,3nF ergibt sich ein Abstimmbereich von 36kHz bis 44kHz. Sie sind hierfür nicht zu kurz einzubauen und nach dem Abgleich mit etwas Heisskleber zu fixieren.<br />
<br />
Manfred<br />
<br />
<br />
==Siehe auch==<br />
* [[Operationsverstärker]]<br />
* [[Ultraschall Interface]] <br />
<br />
==Weblinks==<br />
* http://de.wikipedia.org/wiki/Diode<br />
<br />
[[Kategorie:Elektronik]]<br />
[[Kategorie:Projekte]]</div>Overtherehttps://rn-wissen.de/wiki/index.php?title=Linuxdistribution_Avr-live-cd_DISCONTINUED&diff=9960Linuxdistribution Avr-live-cd DISCONTINUED2007-01-07T10:24:38Z<p>Overthere: </p>
<hr />
<div>Die Avr-live-CD hat die Zielsetzung, ein komfortables und kostenloses Betriebsystem bereitstellen, das <br />
möglichst viele Funktionen für das Programmieren von [[AVR]]s zur Verfügung stellt. <br />
[[Bild:Avrlivecd_screen1.png|thumb|Desktop]]<br />
== Grundlagen ==<br />
[[Bild:Avrlivecd_screen2.png|thumb|Kontrollerlab]]<br />
Die Avr-live-CD basiert auf Slax. Slax basiert auf der Linuxdistribution Slackware und hieß Ursprünglich "Linux Live CD". <br />
Für das Compilieren des Quelltextes wird [[avr-gcc]] verwendet. Der Binärcode in Hex-Form wird mittels avrdude auf den AVR geladen. Kontrollerlab wird als Interface und Programmierumgebung genutzt. <br />
<br />
Diese CD bietet dem Nutzer somit eine kostenlose Softwarelösung, die auf fast jedem PC lauffähig ist. Es werden durch avrdude und avr-gcc viele Programmierkabel, AVRs und Programmiersprachen untersützt. Eine komfortable Bedienung vereinfacht das Entwickeln. Bald wird auch ein Simulator folgen. Diese CD ist nicht nur für Linuxprofis geeignet, sondern wurde auf eine einfache Bedienung ausgelegt. Es sind die schnelleren, aber umständlicheren Konsolenprogramme vorhanden, jedoch lassen sich alle Entwicklungsaufgaben auch über grafische Benutzeroberflächen erledigen. Die CD wurde speziell für diese Aufgaben entwickelt und hat die benötigten Anwendungen schon vorinstalliert.<br />
<br />
== Installation ==<br />
Um die Avr-live-CD zu verwenden, entpacke man das RAR-Verzeichnis und brenne die ISO Datei. <br />
Der Computer wird nun neu gestartet, dann ruft man das Bios auf. Hier muss man die Bootreihenfolge<br />
ändern. Die CD muss hierbei von höherer Priorität sein als die Harddisk. Nach einem Neustart des Computers started die Avr-Live-CD.<br />
<br />
=== Hinweise zur Benutzung/Eigenarten ===<br />
Im Moment ist es nötig in das Verzeichnis, in der sich der Quelltext befindet, eine Datei zu kopieren. Diese Datei heist "crt[avrtyp].o". Diese Dateien sind unter "Avrlibs" auf dem Destop verlinkt. In der nächsten Version wird verucht diese Eigenart zu beheben.<br />
<br />
== Relases ==<br />
=== Alpha (relased) ===<br />
Die AvrLiveCD hatte mitte Dezember 2006 das 1. Relase. Erhaten sind die Grundlegenden AVR-Tools wie [[avr-gcc]] und [[avrdude]].<br />
=== Betha (scheduled)===<br />
Das nächste Relase der AvrLiveCD wird mitte Januar 2007 erwarted. Geplant sind hier KiCad sowie die 0.8 Version von Kontrollerlab einzubinden. Ebenfalls wird warscheinlich ein EEPROM-Programmer vorhanden sein.<br />
<br />
== Feedback ==<br />
Hier werden alle Feedbacks über die AvrLiveCD gelistet.<br />
<br />
<pre>Außerdem wollt ich Dir noch zu Deinem großartigen Projekt gratulieren. Ich denke, dass <br />
speziell viele Windows-Leute genau auf sowas gewartet haben, und dass sie dann damit<br />
vielleicht auch in die Linux-Community gelockt werden.</pre><br />
* 7. Jan. 2007<br />
== Mitarbeit ==<br />
Jeder kann bei der Avr-live-CD mitarbeiten. Jeder kann die Versionen nach belieben modifizieren, verändern, etc. Nun nurnoch hochladen und hier publizieren.<br />
<br />
<br />
<br />
<br />
{{Ausbauwunsch|Diesen Artikel bitte noch erweitern. Dabei eventuell die Installation und eine Benutzertutorial erstellen.}}<br />
<br />
== Autoren ==<br />
--[[Benutzer:Overthere|Overthere]] 08:12, 15. Dez 2006 (CET)<br />
<br />
==Siehe auch==<br />
* [[AVR]]<br />
<br />
==Weblinks==<br />
* [http://www.slax.org Slax]<br />
* [http://www.cadmaniac.org Kontrollerlab] <br />
* [http://www.roboternetz.de/phpBB2/viewtopic.php?t=25912 Forumbeitrag]<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] <br />
* [http://www.xfuture-media.de Xfuture-Media(Hoster der Avr-Live-CD)]<br />
<br />
=== Sponsoring ===<br />
Die Avr-live-CD [http://www.xfuture-media.de Xfuture-Media] hat sich bereiterklärt die Avr-Live-CD zu hosten. Herzlichen Dank!<br />
<br />
=== Download ===<br />
* [http://avrlivecd.xfuture-server.de/ Avr-Live-CD] Version auswählen und .rar Datei downloaden. ''Achtung 256 MegaByte''<br />
* [http://livecd.ff-aulendorf.de/avr.rar Mirror1]<br />
Alternativ, wenn man schon Slax hat:<br />
* [http://avrlivecd.xfuture-server.de/ AvrLiveCD-Slaxmodule(21 Mb) (Qt-Lib noch notwendig)]<br />
* Version auswählen und .mo Datei downloaden.<br />
* [http://www.slax.org/modules.php?category=libraries&id=1422&name=Qt+Libraries Qt-Lib]<br />
<br />
<br />
<br />
[[Kategorie:Software]]<br />
[[Kategorie:Microcontroller]]</div>Overthere