Mikrocontroller.net - Benutzerbeiträge [de]

Infineon XMC 2Go

2020-04-25T12:48:19Z

Longri:

Das Infineon XMC 2GO ist ein Entwicklungsboard für den ARM Cortex M0-basierten Mikrocontroller [https://www.mikrocontroller.net/part/XMC1100 XMC1100] (64 kB Flash, 16 kB RAM). Auf dem Board ist ein weiterer Controller der über USB Programmierung & Debugging ermöglicht, und die serielle UART-Schnittstelle des XMC1100 als virtuellen COM Port bereitstellt.

Das XMC 2Go eignet sich besonders für Ein- und Umsteiger von 8-Bit-Controllern, da die Hardware sehr übersichtlich ist, Kommunikation mit dem PC auf einfache Weise über ein UART stattfinden kann, und es durch seine geringe Größe gut zum Einsatz auf einem [[Breadboard]] geeignet ist.

<gallery>
Datei:XMC 2Go mediu 002.jpg|Das Board im Detail
Datei:XMC 2Go hand.jpeg|Größenvergleich
Datei:XMC 2Go breadboard-1.jpeg|Anwendungsbeispiel mit [[Breadboard]]
Datei:XMC2GO.PNG|Komponenten und Abmessungen
Datei:XMC 2Go Schematic.svg|Schaltplan
</gallery>

Den einfachsten Einstieg bietet die Entwicklungsumgebung [http://www.infineon.com/cms/en/product/microcontrollers/development-tools,-software-and-kits/dave-tm-3-%2013-auto-code-generation-and-free-tools/channel.html?channel=db3a30433580b37101359f8ee6963814 DAVE]. DAVE basiert auf Eclipse CDT, und enthält neben dem GNU C Compiler (GCC) die für das Flashen und Debuggen des Mikrocontrollers nötigen Tools. Grundsätzlich lässt sich allerdings auch jede andere Entwicklungsumgebung (bzw. jeder Compiler verwenden), die Code für Cortex M0 erzeugen kann.

Von Keil gibt es kostenlos eine spezielle Version der Entwicklungsumgebung MDK für XMC1000-Controller, welche im Gegensatz zur normalen MDK Lite-Version bis zu 128 kB Code unterstützt [http://www2.keil.com/infineon/mdk/].

Die Fa. iSYSTEM stellt neben einem Debug-plugin für Dave mit winIDEAOpen eine kostenlose Entwicklungsumgebung für Cortex-M MCU's zur Verfügung[http://www.isystem.com/download/winideaopen]. Diese arbeitet unlimitiert mit dem GCC und für die Keil bzw. IAR Compiler bis zu 32K Code. Auf der winIDEAOpen Seite steht auch ein Beispielpaket für die XMC1000 und XMC4000 Familien zum Download bereit. Neben den Infineon EasyStart und RunningLEDs Beispielen beinhaltet dies auch bereits ein FreeRTOS Projekt. winIDEAOpen enthält einen Kernel plugin für FreeRTOS.

== Dokumentation ==
* [http://www.infineon.com/dgdl/xmc1100_ds_v1.2_2013_12.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a30433d1d0bbe013d256b60160b7f&ack=t XMC1100 Datenblatt]
* [http://www.infineon.com/dgdl/xmc1100_rm_v1+0_2013_03.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a30433cfb5caa013d1600856033eb&ack=t XMC1100 Reference Manual]
* [http://www.infineon.com/dgdl/Board_Users_Manual_XMC_2Go_Kit_with_XMC1100_R1.0.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a3043444ee5dc014453d6c75078c6&ack=t XMC 2Go Manual]

== Bezugsquellen ==
* [http://www.ehitex.de/application-kits/infineon/471/xmc-2go Hitex (5.00€)]
* [http://shop.myavr.de/Aktionen/XMC%202Go.htm?sp=article.sp.php&artID=200128 MyAVR (6€)]

== Weblinks ==
* [https://mikrocontroller.bplaced.net/wordpress/?page_id=580 Schritt-für-Schritt-Anleitung und Beispielprojekt für Keil µVision]
* [https://www.longrisoft.de/ucontroller-technik/infinion-xmc/xmc2go Eine weitere Seite zur Entwicklung mit dem XMC 2Go unter Keil µVison]
* [http://eleceng.dit.ie/frank/arm/BareMetalXMC2Go/index.html Programmierung des XMC 2Go unter Linux ohne IDE mittels Makefile und Seggers JLink für Linux]
[[Category:ARM]]
[[Category:Infineon XMC]]

Mcruler

2014-08-18T12:16:07Z

Longri: /* Vorbestellungen */

== Infos ==

Hier soll eine Community Variante eines Lineals entstehen, nach Vorbild des µRuler von EEVBlog/Dave Jones:

[[Datei:uRuler.jpg|1200px]]

'''Aktueller Stand:'''

[https://raw.github.com/maugsburger/ucruler/master/ucruler_top.png Top]

[https://raw.github.com/maugsburger/ucruler/master/ucruler_bot.png Bottom]

'''Thread im Forum:''' http://www.mikrocontroller.net/topic/313642

'''Projekt-Seite auf GitHub:''' https://github.com/maugsburger/ucruler

== Spezifikationen ==

{| class="wikitable"
|-
| Maße || 200 x 32 mm
|-
| PCB || 0.5mm oder 0.8mm FR4 '''1-Layer''' 35µ (TBD)
|-
| Oberfläche || gold (ENIG)
|-
| Lötstop || beidseitig, Farbe TBD
|-
| Bestückungsdruck || beidseitig, weiß
|-
| '''Preise''' || ca. 2 € / MOQ: 5 Stück oder vielfaches von 3 (TBD)
|}

== Farbe des Lötstopplackes ==
<pre>
grün |
gelb |
schwarz |24
weiß |1
rot |10
blau |5
</pre>

einfach bitte die Zahl hinter die Farbe, die euch als Lötstopplack am besten gefallen würde, erhöhen.

== minimale Schriftgröße ==

http://www.mikrocontroller.net/attachment/196856/ucruler.pdf ausdrucken und die eigenen Augen testen.

Dann bitte eintragen, welche Größe gerade noch lesbar ist. Die normale Schrift wird eins größer werden, aber falls mal wirklich kein Platz mehr sein sollte würde ich darauf zurückgreifen.

<pre>
1,8 |
1,6 |
1,4 |
1,2 | 6
1,0 | 6
0,8 |
</pre>

== Anpassungen/Ergänzungen ==

Bitte einfach die Zahl bei + oder - erhöhen oder gar nichts eintragen (wichtig, brauch ich nicht, egal), so dass am Ende ein Stimmungsbild entsteht. Daraus ergeben sich dann Prioritäten, in deren Reihenfolge der Platz aufgefüllt wird.

{| class="wikitable"

|-
! Name !! Wertung !! Beschreibung

|-
| Formelsamlung
||
<pre>
+| 5
-| 8
</pre>
||
Vielleicht könnte man auch ein paar Formeln unterbringen die oft verwendet werden und trotzdem gerne vergessen werden.

Vorschläge [[Mcnet-ruler#Vorschl.C3.A4ge_f.C3.BCr_Formelsammlung|siehe unten]].

|-
| ✓ Leiterbahnstärken
||
<pre>
1| 1
2| 21
3|
4|
5|
</pre>
||
Bitte genau eine Möglichkeit mit + wählen:
# Bahnen in mm und mil, beschriftet in mm und mil
# Bahnen in mm, beschriftet in mm und mil
# Bahnen in mil, beschriftet in mm und mil
# Bahnen in mm, beschriftet in mm
# Bahnen in mil, beschriftet in mil

|-
| ✓ Inches in mm
||
<pre>
+| 20
-| 1
</pre>
||
Bitte generell Inches in mm umrechnen.

|-
| Isolationsabstände
||
<pre>
+| 29
-|
</pre>
||
Die Tabelle für Isolationsabstände (Luft-/Kriechstrecken) ggf. an in Deutschland geltende Normen anpassen.

|-
| Kabel-Widerstände
||
<pre>
+| 15
-| 7
</pre>
||
Wenn noch Platz ist, wäre eine Tabelle für Kabel-Widerstände gut (sortiert nach gängigen Querschnitten, pro m oder 10m Kabellänge).

|-
| Widerstands-Farbcode-Tabelle
||
<pre>
+| 16
-| 18
</pre>
||
Rückseite Widerstands-Farbcode-Tabelle

|-
| LM317
||
<pre>
+| 5
-| 23
</pre>
||
Tabelle für LM317-Widerstandswerte

|-
| Kapazitäts-/Induktivitätsbelag
||
<pre>
+| 9
-| 3
</pre>
||
Tabellen zum Kapazitäts-/Induktivitätsbelag von Leiterbahnen

|-
| Wellenwiderstände
||
<pre>
+| 9
-| 4
</pre>
||
Richtwerttabellen für Wellenwiderstände, Micro Striplines (insbes. für USB/Ethernet Routing), etc. auf gängigen PCBs

|-
| Wechselstrom Ueff, Upp
||
<pre>
+| 3
-| 20
</pre>
||
Wenn immer noch Platz ist: Tabelle zur Umrechnung von Wechselstromgrößen (Ueff, Upp für gängige Trafowicklungen, 110V, 230V, 240V, 400V, 600V)

Anm.: Sinnvoll für gängige Elko-Spannungen 16VDC, 25VDC, 50VDC, 63VDC, 80VDC.

|-
| f/T-Umrechnung
||
<pre>
+| 4
-| 19
</pre>
||
Und wenn dann noch Platz wäre: Tabelle mit f und T für gängige µC-Frequenzen und Samplingraten

Anm.: Sinnvoll und platzsparend, wenn wie vorgeschlagen für einige wenige gängige Werte (z.B. "8 MHz / 125 ns" und "48 kHz / 20,8 µs").

|-
| PCB-Kühlkörper
||
<pre>
+| 20
-| 2
</pre>
||
Was auch interessant wäre, ist eine Tabelle für Leiterplattenkühlkoerper. K/W pro cm² für div. Kupferstärken!

|-
| ✓ SMD-Footprints R
||
<pre>
+| 30
-| 1
</pre>
||
Die Idee mit den SMD Footprints auf der Rückseite finde ich auch sehr gut.

|-
| ✓ SMD-Größen R
||
<pre>
+| 19
-| 2
</pre>
||
Eine Tabelle mit den Größen (im Sinne von Maßen) von SMD Widerständen ist auch manchmal ganz gut.

|-
| ✓ SMD-Footprints ElKo
||
<pre>
+| 25
-| 1
</pre>
||
Zudem wäre der Footprint von SMD Elkos wenn möglich auf der Rückseite auch ganz praktisch.

|-
| ✓ SMD-Größen Elko
||
<pre>
+| 22
-| 1
</pre>
||
Eine Tabelle mit den Größen (im Sinne von Maßen) von SMD Elkos ist auch manchmal ganz gut.

|-
| E-Reihen
||
<pre>
+| 14
-| 8
</pre>
||
Abdruck der E24-Reihe mit Markierungen für E12, E6.

|-
| TQFP, SOP und SOT Footprint
||
<pre>
+| 21
-| 1
</pre>
||
Der Footprint von TQFP, SOT und SOP Bauteilen auf der Rückseite könnte sich auch als nützlich erweisen

Vorschläge für Footprints [[Mcnet-ruler#Vorschl.C3.A4ge_f.C3.BCr_Footprints|siehe unten]].

|-
| ✓ THT Lochreihe
||
<pre>
+| 12
-| 5
</pre>
||
Ebenso eine kurze Lochreihe im 2,54mm-Raster für THT.

Anm.: Bitte eine lange Lochreihe ähnlich wie von [http://www.mikrocontroller.net/topic/313642#3389830 Chris gezeigt].

|-
| ✓ Kleines Namensfeld
||
<pre>
+| 22
-| 3
</pre>
||
Damit die Lineale nicht "verschwinden", zum selbst beschriften.

|-
| Tabelle Leitfähigkeit/spezifischer Widerstand
||
<pre>
+| 5
-| 7
</pre>
||
Eine Tabelle mit der Leitfähigkeit/spezifischer Widerstand von z.B. Kupfer, Aluminium, Eisen ...

|-
| Temperaturkoeffizent
||
<pre>
+| 4
-| 7
</pre>
||
Eine Tabelle mit den Temperaturkoeffizenten (alpha in 1/k) von z.B. Kupfer, Aluminium, Eisen ...

|-
| ✓ Transistor-Schaltungssymbole
||
<pre>
+| 10
-| 3
</pre>
||
Aufdruck von Transistor-Schaltungssymbolen (bipolar/FET) und THT-LEDs, [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg siehe hier]

|-
| Pin-Beschriftung für einige Footprints
||
<pre>
+| 8
-|
</pre>
||
Einige Footprints (z.B. TO-92, SOT-23 etc.) sollten Beschriftungen für BCE/GDS für gängige Transistortypen bekommen, siehe [http://dmohankumar.files.wordpress.com/2011/05/table-showing-the-pins-of-common-transistors.pdf hier] und [http://www.radiomuseum.org/forum/transistor_connections.html hier]

|-
| Kabelschablone
||
<pre>
+| 6
-|
</pre>
||
Ähnlich dem [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg Adafruit Ruler], aber als Tabelle in AWG und mm.

|-
| Seitenansicht bedrahtetes LED Gehäuse
||
<pre>
+| 2
-| 1
</pre>
||
Somit kann man auch bei einer verbauten LED (oder entlöteten LED) mit einem Blick von der Seite erkennen, welcher Pin Anode und welche Kathode ist
Ähnlich dem [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg Adafruit Ruler], unter "AWG 13".

|}

== Vorschläge für Formelsammlung ==

{| class="wikitable"

|-
! Name !! Wertung !! Beschreibung

|-
| C/L
||
<pre>
+| 1
-| 1
</pre>
||
http://upload.wikimedia.org/math/d/5/5/d550b39c146790974bae8a9a2e1830fb.png

http://upload.wikimedia.org/math/0/9/a/09ab806c34320b749ddadca35a32fc8a.png

http://de.wikipedia.org/wiki/Elektrische_Kapazit%C3%A4t#Kapazit.C3.A4t_bestimmter_Leiteranordnungen

http://de.wikipedia.org/wiki/Induktivit%C3%A4t#Induktivit.C3.A4t_einer_Zylinderspule

|-
| Eckfrequenz RC-Glied HP/LP
||
<pre>
+| 1
-| 2
</pre>
||
http://upload.wikimedia.org/math/5/d/1/5d1295e236a3c860416fbdb9940fb043.png

http://de.wikipedia.org/wiki/RC-Glied#Tiefpass

|-
| I(t) / U(t) für C/L
||
<pre>
+| 2
-| 1
</pre>
||
http://upload.wikimedia.org/math/0/b/9/0b93b4a1ce2832629d42509b43184894.png

http://upload.wikimedia.org/math/9/e/6/9e6ea02a73a08f263454786c1c9d7e44.png

http://de.wikipedia.org/wiki/Zeitkonstante#Kondensator

|-
| Wärmewiderstand
||
<pre>
+| 1
-| 1
</pre>
||
http://upload.wikimedia.org/math/8/7/b/87b98460f0867373471f540167591ebb.png

http://de.wikipedia.org/wiki/W%C3%A4rmewiderstand#Definition

|}

== Vorschläge für Footprints ==

Vorschläge für Footprints auf der Rückseite. Es werden die Pads in Kupfer ausgeführt (also theoretisch lötbar), der Rand des Bauteils im Bestückungsdruck.

* http://www.fairchildsemi.com/package/
* http://www.maximintegrated.com/design/packaging/
* http://www.infineon.com/cms/de/product/technology/packages/index.html
* http://www.nxp.com/packages
* http://www.topline.tv/Drawings/PDF/QFP/TQFP_Library.pdf
* http://www.linear.com/designtools/packaging/
* http://ww1.microchip.com/downloads/en/PackagingSpec/00049AR.pdf

=== Standardisierungen ===
* http://www.jedec.org/category/technology-focus-area/registered-outlines-jep95

=== Inspirationen ===

Siehe auch [http://www.adafruit.com/blog/2013/10/11/new-product-adafruit-pcb-ruler-6/ Adafruit Ruler].

http://www.adafruit.com/images/large/1554bottom_LRG.jpg

=== Widerstände & Kondensatoren ===
Maße siehe z.B. http://www.panasonic.com/industrial/components/pdf/AOA0000CE1.pdf

* ✓ 0201 (wenn der Fertiger des Lineal das kann...)
* ✓ 0402
* ✓ 0603
* ✓ 0805
* ✓ 1206
* ✓ 1210
* 1812 (wenn noch Platz ist)
* 2010 (wenn noch Platz ist)
* 2512 (wenn noch Platz ist)

=== Transistoren & ICs ===

* ✓ SC-70
* ✓ SOT-23
* ✓ SOT-23-6
* ✓ SOT-89
* ✓ SOT-223
* ✓ TO-252 / DPAK http://www.fairchildsemi.com/dwg/TO/TO252A03.pdf
* ✓ TO-263 / D2PAK http://www.fairchildsemi.com/dwg/TO/TO263A02.pdf

=== Dioden & LEDs ===

* ✓ SMA / DO-214AC http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ SMB / DO-214AA http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ SMC / DO-214AB http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ Melf http://www.cdil.com/package/do213ab_dwng.pdf
* ✓ MiniMelf http://www.cdil.com/package/sod_80c.pdf
* ✓ MicroMelf http://www.vishay.com/docs/20003/smm0102.pdf
* ✓ PLCC-4 / 3528 http://catalog.osram-os.com/media/_en/Graphics/00042269_0.pdf
* ✓ PLCC-6 / 5050 http://ledversand24.de/media/pdf/ws2812preliminary51337f1c83131.pdf
* ✓ SOD323/SC76 http://www.infineon.com/dgdl/SOD323-Package_Overview.pdf?folderId=db3a30431936bc4b011952aab84f3bbe&fileId=db3a30431936bc4b011952beed653be3

=== ICs ===

* ✓ SOIC-24, 3.9mm-Body, ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24 Pins anzeichen, Pinzahl ranschreiben
* ✓ SOIC-24, 7.5mm-Body, ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24 Pins anzeichen, Pinzahl ranschreiben
Diese beiden SOIC-Breiten wenn möglich in einem Footprint zusammenfassen, also z.B. die linken Pins gemeinsam verwenden. Die beiden
Breiten dann über Bestückungsdruck-Linien kennzeichnen.

* ✓ SSOP-28, 5,3mm-Body, 0,65mm Pitch. Das ist die gängigste Variante, es gibt aber leider auch einige Abweichler mit anderem Pitch und Bodybreite die sich auch SSOP nennen :(
* TSSOP-28, 4,4mm-Body, 0,65mm Pitch
Auch bei diesen beiden: ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24,28 Pins anzeichen, Pinzahl ranschreiben

Für die Maße: http://www.microchip.com/stellent/groups/techpub_sg/documents/packagingspec/en012702.pdf

Wenn noch Platz:
* TQFP32, 0.8mm Pitch http://www.microchip.com/stellent/groups/techpub_sg/documents/packagingspec/en012702.pdf
* TQFP48 / LQFP48, 0.5mm Pitch http://www.nxp.com/documents/outline_drawing/sot313-2_po.pdf
* ✓ QFN32, 0.5mm Pitch http://www.linear.com/docs/38749

== Vorbestellungen ==
Interessenten tragen sich bitte '''am Ende der Liste ein und aktualisieren den Zwischenstand'''!

Mindestbestellmenge ist nach aktuellem Stand 5 Stück.

<pre>
10 Dominik S. (dasd)
5 Dennis X. (debegr92)
2 Arne M. (armut)
3 Benedikt K. (benek)
10 avr avr (colombo010)
5 Jürgen (Gast)
5 Uwe ... (uwegw)
15 Rene H. (promeus)
5 hum (Gast)
3 Werner A. (homebrew)
2 Frank Werner (wesoft)
5 Jan B. (diphthong)
5 Thomas J. (tom16)
15 Felix Schulze (pepe)
3 Patrick Berninghaus (patricck)
5 B. B. (morgenmuffel)
5 Bernd D. (bernd_d56)
5 Daniel (Gast)
5 Jan Dressler (keyman)
3 Gerd E. (robberknight)
10 Ralf Engelhardt (r_e)
5 D. S. (compuvidy)
5 Michael R. (elektr-hobbyist)
10 Samuel Hildebrandt (musicsammy)
5 Martin H. (marrtn)
5 Michael Becker (mich_at_el)
5 Marco André (marphy)
5 Chris (Gast)
5 mr. mo (Gast)
5 Martin R. (martin84)
3 J. S. (voochee)
5 Andreas H. (ahz)
5 Ronny Spiegel (duselbaer)
10 G. L. (lele)
3 Axel Jäger (axeljaeger)
5 Stephan G. (stephan_g35)
5 Gibts Ne (schneeblau)
5 Sascha G. (sascha-g)
5 Richard Zink (Gast)
5 Stephan K. (nightowl)
5 Martin Wende (Firma: fritzler-avr.de) (fritzler)
5 Jörg S. (Gast)
10 J. L. (lindenbaum)
10 Jan M. (mueschel)
5 Bad Urban (bad_urban)
5 Daniel M. (amad)
5 Sascha S. (dec)
5 A. S. (rava)
10 Jens M. (jens-m)
5 Sascha E. (baracuss)
5 avr avr (colombo010)
5 Michael B. (michael_b25)
10 Thomas Sch. (doschi_)
10 K. J. (theborg0815)
5 Daniel C. (cecky)
3 Philipp E. (erlang)
5 Thorsten Ostermann (Firma: mechapro GmbH) (ostermann)
10 vophatec (Manuel Z.)
3 Carsten Peschke
2 J.O. (Gast)
5 D. Braun (garag)
5 Michael.S. (michael0307)
5 Didi S. (kokisan2000)
5 Thomas L. (ics1702)
5 Sebastian Engel (s-engel)
5 Peter Sieg (petersieg)
5 Martin S. (martin_s91)
5 Manuel Steiner (steinerhippo)
5 Nico B. (vegetico)
5 Axel P. (axel_p)
5 Mh. M. (mhm)
5 Friedrich K (*)
5 O.Hagendorf (ohagendorf)
10 Jonas K. (jonas k)
5 Sam .. (sam1994)
10 Jens A. (Nepi) (erhöht von 5 auf 10 am 15.1.2014)
5 Tom Z. (tom_z)
5 Sven K. (herbivore)
5 Steffen A (*)
3 Stephan Henning (stephan-) notfalls auch 5
5 Benjamin Jung (benjamin_j)
5 Kai D. (kai1972)
5 Gerd B. (bertr2d2)
5 Martin G. (magoe)
5 Stefan K. (oxid)
5 S. Q. (frido2001)
5 D. K. (elektricar)
5 Markus C. (ljmarkus)
5 Alexander K. (minjaman)
10 Dominic A. (neo123)
3 Oliver S. (Oliver_S) notfalls auch 5
5 Tobias S. (x12z34)
5 Frank F. (frohf)
5 Kalle S. (kallebmw)
5 Bjoern G. (tueftler)
5 Akif D. (adnc)
5 Rico T. (tyrann410)
5 Axel (axelg)
10 Elmar N. (zulue)
5 Frank G. (frank_g53)
15 pko pprasch (pkopprasch)
5 Alexander D. (Gast)
5 Marius B. (majus)
20 F.FO (foldi)
5 Stefan P. (nett_flanders)
5 Carsten Wille (eagle38106)
5 Steffen Schröter (stesch99)
5 Guido C. (guidoanalog)
5 Yann L. (ylere)
5 Benedikt R. (da_miez)
5 Thorsten F. (tfol)
3 Oliver H. (oliver h) notfalls auch 5
2 Zoidberg (Gast) 5 nur extrem ungern
5 Markus M (mmax)
10 Maik Fox (sabuty)
5 DL9RDW (Bernhard Schröcker)
10 Fer T. (fer_t)
5 Einhart (einhart)
5 Teo Derix (teoderix)
3 Volker R. (Pcl86) wenn's nicht anders geht auch 5
5 John (karabka)
5 Matthias N. (nippey)
5 David Z. (hawk_2k)
5 Volker G. (voga2073)
20 Stefan Wagner (dl6dx)
20 Tobias Hochgürtel (tobias_h94)
10 Matthias H. (kaplic)
5 Juli V. (torten_juli)
5 Edu B. (edu)
5 Joe G. (Feinmechaniker)
10 Peter (elektronik24)
10 Nico S. (longri)
-------------------------------------
789 ZWISCHENSTAND
</pre>

Mcruler

2014-08-18T12:14:47Z

Longri: /* Anpassungen/Ergänzungen */

== Infos ==

Hier soll eine Community Variante eines Lineals entstehen, nach Vorbild des µRuler von EEVBlog/Dave Jones:

[[Datei:uRuler.jpg|1200px]]

'''Aktueller Stand:'''

[https://raw.github.com/maugsburger/ucruler/master/ucruler_top.png Top]

[https://raw.github.com/maugsburger/ucruler/master/ucruler_bot.png Bottom]

'''Thread im Forum:''' http://www.mikrocontroller.net/topic/313642

'''Projekt-Seite auf GitHub:''' https://github.com/maugsburger/ucruler

== Spezifikationen ==

{| class="wikitable"
|-
| Maße || 200 x 32 mm
|-
| PCB || 0.5mm oder 0.8mm FR4 '''1-Layer''' 35µ (TBD)
|-
| Oberfläche || gold (ENIG)
|-
| Lötstop || beidseitig, Farbe TBD
|-
| Bestückungsdruck || beidseitig, weiß
|-
| '''Preise''' || ca. 2 € / MOQ: 5 Stück oder vielfaches von 3 (TBD)
|}

== Farbe des Lötstopplackes ==
<pre>
grün |
gelb |
schwarz |24
weiß |1
rot |10
blau |5
</pre>

einfach bitte die Zahl hinter die Farbe, die euch als Lötstopplack am besten gefallen würde, erhöhen.

== minimale Schriftgröße ==

http://www.mikrocontroller.net/attachment/196856/ucruler.pdf ausdrucken und die eigenen Augen testen.

Dann bitte eintragen, welche Größe gerade noch lesbar ist. Die normale Schrift wird eins größer werden, aber falls mal wirklich kein Platz mehr sein sollte würde ich darauf zurückgreifen.

<pre>
1,8 |
1,6 |
1,4 |
1,2 | 6
1,0 | 6
0,8 |
</pre>

== Anpassungen/Ergänzungen ==

Bitte einfach die Zahl bei + oder - erhöhen oder gar nichts eintragen (wichtig, brauch ich nicht, egal), so dass am Ende ein Stimmungsbild entsteht. Daraus ergeben sich dann Prioritäten, in deren Reihenfolge der Platz aufgefüllt wird.

{| class="wikitable"

|-
! Name !! Wertung !! Beschreibung

|-
| Formelsamlung
||
<pre>
+| 5
-| 8
</pre>
||
Vielleicht könnte man auch ein paar Formeln unterbringen die oft verwendet werden und trotzdem gerne vergessen werden.

Vorschläge [[Mcnet-ruler#Vorschl.C3.A4ge_f.C3.BCr_Formelsammlung|siehe unten]].

|-
| ✓ Leiterbahnstärken
||
<pre>
1| 1
2| 21
3|
4|
5|
</pre>
||
Bitte genau eine Möglichkeit mit + wählen:
# Bahnen in mm und mil, beschriftet in mm und mil
# Bahnen in mm, beschriftet in mm und mil
# Bahnen in mil, beschriftet in mm und mil
# Bahnen in mm, beschriftet in mm
# Bahnen in mil, beschriftet in mil

|-
| ✓ Inches in mm
||
<pre>
+| 20
-| 1
</pre>
||
Bitte generell Inches in mm umrechnen.

|-
| Isolationsabstände
||
<pre>
+| 29
-|
</pre>
||
Die Tabelle für Isolationsabstände (Luft-/Kriechstrecken) ggf. an in Deutschland geltende Normen anpassen.

|-
| Kabel-Widerstände
||
<pre>
+| 15
-| 7
</pre>
||
Wenn noch Platz ist, wäre eine Tabelle für Kabel-Widerstände gut (sortiert nach gängigen Querschnitten, pro m oder 10m Kabellänge).

|-
| Widerstands-Farbcode-Tabelle
||
<pre>
+| 16
-| 18
</pre>
||
Rückseite Widerstands-Farbcode-Tabelle

|-
| LM317
||
<pre>
+| 5
-| 23
</pre>
||
Tabelle für LM317-Widerstandswerte

|-
| Kapazitäts-/Induktivitätsbelag
||
<pre>
+| 9
-| 3
</pre>
||
Tabellen zum Kapazitäts-/Induktivitätsbelag von Leiterbahnen

|-
| Wellenwiderstände
||
<pre>
+| 9
-| 4
</pre>
||
Richtwerttabellen für Wellenwiderstände, Micro Striplines (insbes. für USB/Ethernet Routing), etc. auf gängigen PCBs

|-
| Wechselstrom Ueff, Upp
||
<pre>
+| 3
-| 20
</pre>
||
Wenn immer noch Platz ist: Tabelle zur Umrechnung von Wechselstromgrößen (Ueff, Upp für gängige Trafowicklungen, 110V, 230V, 240V, 400V, 600V)

Anm.: Sinnvoll für gängige Elko-Spannungen 16VDC, 25VDC, 50VDC, 63VDC, 80VDC.

|-
| f/T-Umrechnung
||
<pre>
+| 4
-| 19
</pre>
||
Und wenn dann noch Platz wäre: Tabelle mit f und T für gängige µC-Frequenzen und Samplingraten

Anm.: Sinnvoll und platzsparend, wenn wie vorgeschlagen für einige wenige gängige Werte (z.B. "8 MHz / 125 ns" und "48 kHz / 20,8 µs").

|-
| PCB-Kühlkörper
||
<pre>
+| 20
-| 2
</pre>
||
Was auch interessant wäre, ist eine Tabelle für Leiterplattenkühlkoerper. K/W pro cm² für div. Kupferstärken!

|-
| ✓ SMD-Footprints R
||
<pre>
+| 30
-| 1
</pre>
||
Die Idee mit den SMD Footprints auf der Rückseite finde ich auch sehr gut.

|-
| ✓ SMD-Größen R
||
<pre>
+| 19
-| 2
</pre>
||
Eine Tabelle mit den Größen (im Sinne von Maßen) von SMD Widerständen ist auch manchmal ganz gut.

|-
| ✓ SMD-Footprints ElKo
||
<pre>
+| 25
-| 1
</pre>
||
Zudem wäre der Footprint von SMD Elkos wenn möglich auf der Rückseite auch ganz praktisch.

|-
| ✓ SMD-Größen Elko
||
<pre>
+| 22
-| 1
</pre>
||
Eine Tabelle mit den Größen (im Sinne von Maßen) von SMD Elkos ist auch manchmal ganz gut.

|-
| E-Reihen
||
<pre>
+| 14
-| 8
</pre>
||
Abdruck der E24-Reihe mit Markierungen für E12, E6.

|-
| TQFP, SOP und SOT Footprint
||
<pre>
+| 21
-| 1
</pre>
||
Der Footprint von TQFP, SOT und SOP Bauteilen auf der Rückseite könnte sich auch als nützlich erweisen

Vorschläge für Footprints [[Mcnet-ruler#Vorschl.C3.A4ge_f.C3.BCr_Footprints|siehe unten]].

|-
| ✓ THT Lochreihe
||
<pre>
+| 12
-| 5
</pre>
||
Ebenso eine kurze Lochreihe im 2,54mm-Raster für THT.

Anm.: Bitte eine lange Lochreihe ähnlich wie von [http://www.mikrocontroller.net/topic/313642#3389830 Chris gezeigt].

|-
| ✓ Kleines Namensfeld
||
<pre>
+| 22
-| 3
</pre>
||
Damit die Lineale nicht "verschwinden", zum selbst beschriften.

|-
| Tabelle Leitfähigkeit/spezifischer Widerstand
||
<pre>
+| 5
-| 7
</pre>
||
Eine Tabelle mit der Leitfähigkeit/spezifischer Widerstand von z.B. Kupfer, Aluminium, Eisen ...

|-
| Temperaturkoeffizent
||
<pre>
+| 4
-| 7
</pre>
||
Eine Tabelle mit den Temperaturkoeffizenten (alpha in 1/k) von z.B. Kupfer, Aluminium, Eisen ...

|-
| ✓ Transistor-Schaltungssymbole
||
<pre>
+| 10
-| 3
</pre>
||
Aufdruck von Transistor-Schaltungssymbolen (bipolar/FET) und THT-LEDs, [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg siehe hier]

|-
| Pin-Beschriftung für einige Footprints
||
<pre>
+| 8
-|
</pre>
||
Einige Footprints (z.B. TO-92, SOT-23 etc.) sollten Beschriftungen für BCE/GDS für gängige Transistortypen bekommen, siehe [http://dmohankumar.files.wordpress.com/2011/05/table-showing-the-pins-of-common-transistors.pdf hier] und [http://www.radiomuseum.org/forum/transistor_connections.html hier]

|-
| Kabelschablone
||
<pre>
+| 6
-|
</pre>
||
Ähnlich dem [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg Adafruit Ruler], aber als Tabelle in AWG und mm.

|-
| Seitenansicht bedrahtetes LED Gehäuse
||
<pre>
+| 2
-| 1
</pre>
||
Somit kann man auch bei einer verbauten LED (oder entlöteten LED) mit einem Blick von der Seite erkennen, welcher Pin Anode und welche Kathode ist
Ähnlich dem [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg Adafruit Ruler], unter "AWG 13".

|}

== Vorschläge für Formelsammlung ==

{| class="wikitable"

|-
! Name !! Wertung !! Beschreibung

|-
| C/L
||
<pre>
+| 1
-| 1
</pre>
||
http://upload.wikimedia.org/math/d/5/5/d550b39c146790974bae8a9a2e1830fb.png

http://upload.wikimedia.org/math/0/9/a/09ab806c34320b749ddadca35a32fc8a.png

http://de.wikipedia.org/wiki/Elektrische_Kapazit%C3%A4t#Kapazit.C3.A4t_bestimmter_Leiteranordnungen

http://de.wikipedia.org/wiki/Induktivit%C3%A4t#Induktivit.C3.A4t_einer_Zylinderspule

|-
| Eckfrequenz RC-Glied HP/LP
||
<pre>
+| 1
-| 2
</pre>
||
http://upload.wikimedia.org/math/5/d/1/5d1295e236a3c860416fbdb9940fb043.png

http://de.wikipedia.org/wiki/RC-Glied#Tiefpass

|-
| I(t) / U(t) für C/L
||
<pre>
+| 2
-| 1
</pre>
||
http://upload.wikimedia.org/math/0/b/9/0b93b4a1ce2832629d42509b43184894.png

http://upload.wikimedia.org/math/9/e/6/9e6ea02a73a08f263454786c1c9d7e44.png

http://de.wikipedia.org/wiki/Zeitkonstante#Kondensator

|-
| Wärmewiderstand
||
<pre>
+| 1
-| 1
</pre>
||
http://upload.wikimedia.org/math/8/7/b/87b98460f0867373471f540167591ebb.png

http://de.wikipedia.org/wiki/W%C3%A4rmewiderstand#Definition

|}

== Vorschläge für Footprints ==

Vorschläge für Footprints auf der Rückseite. Es werden die Pads in Kupfer ausgeführt (also theoretisch lötbar), der Rand des Bauteils im Bestückungsdruck.

* http://www.fairchildsemi.com/package/
* http://www.maximintegrated.com/design/packaging/
* http://www.infineon.com/cms/de/product/technology/packages/index.html
* http://www.nxp.com/packages
* http://www.topline.tv/Drawings/PDF/QFP/TQFP_Library.pdf
* http://www.linear.com/designtools/packaging/
* http://ww1.microchip.com/downloads/en/PackagingSpec/00049AR.pdf

=== Standardisierungen ===
* http://www.jedec.org/category/technology-focus-area/registered-outlines-jep95

=== Inspirationen ===

Siehe auch [http://www.adafruit.com/blog/2013/10/11/new-product-adafruit-pcb-ruler-6/ Adafruit Ruler].

http://www.adafruit.com/images/large/1554bottom_LRG.jpg

=== Widerstände & Kondensatoren ===
Maße siehe z.B. http://www.panasonic.com/industrial/components/pdf/AOA0000CE1.pdf

* ✓ 0201 (wenn der Fertiger des Lineal das kann...)
* ✓ 0402
* ✓ 0603
* ✓ 0805
* ✓ 1206
* ✓ 1210
* 1812 (wenn noch Platz ist)
* 2010 (wenn noch Platz ist)
* 2512 (wenn noch Platz ist)

=== Transistoren & ICs ===

* ✓ SC-70
* ✓ SOT-23
* ✓ SOT-23-6
* ✓ SOT-89
* ✓ SOT-223
* ✓ TO-252 / DPAK http://www.fairchildsemi.com/dwg/TO/TO252A03.pdf
* ✓ TO-263 / D2PAK http://www.fairchildsemi.com/dwg/TO/TO263A02.pdf

=== Dioden & LEDs ===

* ✓ SMA / DO-214AC http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ SMB / DO-214AA http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ SMC / DO-214AB http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ Melf http://www.cdil.com/package/do213ab_dwng.pdf
* ✓ MiniMelf http://www.cdil.com/package/sod_80c.pdf
* ✓ MicroMelf http://www.vishay.com/docs/20003/smm0102.pdf
* ✓ PLCC-4 / 3528 http://catalog.osram-os.com/media/_en/Graphics/00042269_0.pdf
* ✓ PLCC-6 / 5050 http://ledversand24.de/media/pdf/ws2812preliminary51337f1c83131.pdf
* ✓ SOD323/SC76 http://www.infineon.com/dgdl/SOD323-Package_Overview.pdf?folderId=db3a30431936bc4b011952aab84f3bbe&fileId=db3a30431936bc4b011952beed653be3

=== ICs ===

* ✓ SOIC-24, 3.9mm-Body, ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24 Pins anzeichen, Pinzahl ranschreiben
* ✓ SOIC-24, 7.5mm-Body, ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24 Pins anzeichen, Pinzahl ranschreiben
Diese beiden SOIC-Breiten wenn möglich in einem Footprint zusammenfassen, also z.B. die linken Pins gemeinsam verwenden. Die beiden
Breiten dann über Bestückungsdruck-Linien kennzeichnen.

* ✓ SSOP-28, 5,3mm-Body, 0,65mm Pitch. Das ist die gängigste Variante, es gibt aber leider auch einige Abweichler mit anderem Pitch und Bodybreite die sich auch SSOP nennen :(
* TSSOP-28, 4,4mm-Body, 0,65mm Pitch
Auch bei diesen beiden: ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24,28 Pins anzeichen, Pinzahl ranschreiben

Für die Maße: http://www.microchip.com/stellent/groups/techpub_sg/documents/packagingspec/en012702.pdf

Wenn noch Platz:
* TQFP32, 0.8mm Pitch http://www.microchip.com/stellent/groups/techpub_sg/documents/packagingspec/en012702.pdf
* TQFP48 / LQFP48, 0.5mm Pitch http://www.nxp.com/documents/outline_drawing/sot313-2_po.pdf
* ✓ QFN32, 0.5mm Pitch http://www.linear.com/docs/38749

== Vorbestellungen ==
Interessenten tragen sich bitte '''am Ende der Liste ein und aktualisieren den Zwischenstand'''!

Mindestbestellmenge ist nach aktuellem Stand 5 Stück.

<pre>
10 Dominik S. (dasd)
5 Dennis X. (debegr92)
2 Arne M. (armut)
3 Benedikt K. (benek)
10 avr avr (colombo010)
5 Jürgen (Gast)
5 Uwe ... (uwegw)
15 Rene H. (promeus)
5 hum (Gast)
3 Werner A. (homebrew)
2 Frank Werner (wesoft)
5 Jan B. (diphthong)
5 Thomas J. (tom16)
15 Felix Schulze (pepe)
3 Patrick Berninghaus (patricck)
5 B. B. (morgenmuffel)
5 Bernd D. (bernd_d56)
5 Daniel (Gast)
5 Jan Dressler (keyman)
3 Gerd E. (robberknight)
10 Ralf Engelhardt (r_e)
5 D. S. (compuvidy)
5 Michael R. (elektr-hobbyist)
10 Samuel Hildebrandt (musicsammy)
5 Martin H. (marrtn)
5 Michael Becker (mich_at_el)
5 Marco André (marphy)
5 Chris (Gast)
5 mr. mo (Gast)
5 Martin R. (martin84)
3 J. S. (voochee)
5 Andreas H. (ahz)
5 Ronny Spiegel (duselbaer)
10 G. L. (lele)
3 Axel Jäger (axeljaeger)
5 Stephan G. (stephan_g35)
5 Gibts Ne (schneeblau)
5 Sascha G. (sascha-g)
5 Richard Zink (Gast)
5 Stephan K. (nightowl)
5 Martin Wende (Firma: fritzler-avr.de) (fritzler)
5 Jörg S. (Gast)
10 J. L. (lindenbaum)
10 Jan M. (mueschel)
5 Bad Urban (bad_urban)
5 Daniel M. (amad)
5 Sascha S. (dec)
5 A. S. (rava)
10 Jens M. (jens-m)
5 Sascha E. (baracuss)
5 avr avr (colombo010)
5 Michael B. (michael_b25)
10 Thomas Sch. (doschi_)
10 K. J. (theborg0815)
5 Daniel C. (cecky)
3 Philipp E. (erlang)
5 Thorsten Ostermann (Firma: mechapro GmbH) (ostermann)
10 vophatec (Manuel Z.)
3 Carsten Peschke
2 J.O. (Gast)
5 D. Braun (garag)
5 Michael.S. (michael0307)
5 Didi S. (kokisan2000)
5 Thomas L. (ics1702)
5 Sebastian Engel (s-engel)
5 Peter Sieg (petersieg)
5 Martin S. (martin_s91)
5 Manuel Steiner (steinerhippo)
5 Nico B. (vegetico)
5 Axel P. (axel_p)
5 Mh. M. (mhm)
5 Friedrich K (*)
5 O.Hagendorf (ohagendorf)
10 Jonas K. (jonas k)
5 Sam .. (sam1994)
10 Jens A. (Nepi) (erhöht von 5 auf 10 am 15.1.2014)
5 Tom Z. (tom_z)
5 Sven K. (herbivore)
5 Steffen A (*)
3 Stephan Henning (stephan-) notfalls auch 5
5 Benjamin Jung (benjamin_j)
5 Kai D. (kai1972)
5 Gerd B. (bertr2d2)
5 Martin G. (magoe)
5 Stefan K. (oxid)
5 S. Q. (frido2001)
5 D. K. (elektricar)
5 Markus C. (ljmarkus)
5 Alexander K. (minjaman)
10 Dominic A. (neo123)
3 Oliver S. (Oliver_S) notfalls auch 5
5 Tobias S. (x12z34)
5 Frank F. (frohf)
5 Kalle S. (kallebmw)
5 Bjoern G. (tueftler)
5 Akif D. (adnc)
5 Rico T. (tyrann410)
5 Axel (axelg)
10 Elmar N. (zulue)
5 Frank G. (frank_g53)
15 pko pprasch (pkopprasch)
5 Alexander D. (Gast)
5 Marius B. (majus)
20 F.FO (foldi)
5 Stefan P. (nett_flanders)
5 Carsten Wille (eagle38106)
5 Steffen Schröter (stesch99)
5 Guido C. (guidoanalog)
5 Yann L. (ylere)
5 Benedikt R. (da_miez)
5 Thorsten F. (tfol)
3 Oliver H. (oliver h) notfalls auch 5
2 Zoidberg (Gast) 5 nur extrem ungern
5 Markus M (mmax)
10 Maik Fox (sabuty)
5 DL9RDW (Bernhard Schröcker)
10 Fer T. (fer_t)
5 Einhart (einhart)
5 Teo Derix (teoderix)
3 Volker R. (Pcl86) wenn's nicht anders geht auch 5
5 John (karabka)
5 Matthias N. (nippey)
5 David Z. (hawk_2k)
5 Volker G. (voga2073)
20 Stefan Wagner (dl6dx)
20 Tobias Hochgürtel (tobias_h94)
10 Matthias H. (kaplic)
5 Juli V. (torten_juli)
5 Edu B. (edu)
5 Joe G. (Feinmechaniker)
10 Peter (elektronik24)
-------------------------------------
779 ZWISCHENSTAND
</pre>

Mcruler

2014-08-18T12:13:01Z

Longri:

== Infos ==

Hier soll eine Community Variante eines Lineals entstehen, nach Vorbild des µRuler von EEVBlog/Dave Jones:

[[Datei:uRuler.jpg|1200px]]

'''Aktueller Stand:'''

[https://raw.github.com/maugsburger/ucruler/master/ucruler_top.png Top]

[https://raw.github.com/maugsburger/ucruler/master/ucruler_bot.png Bottom]

'''Thread im Forum:''' http://www.mikrocontroller.net/topic/313642

'''Projekt-Seite auf GitHub:''' https://github.com/maugsburger/ucruler

== Spezifikationen ==

{| class="wikitable"
|-
| Maße || 200 x 32 mm
|-
| PCB || 0.5mm oder 0.8mm FR4 '''1-Layer''' 35µ (TBD)
|-
| Oberfläche || gold (ENIG)
|-
| Lötstop || beidseitig, Farbe TBD
|-
| Bestückungsdruck || beidseitig, weiß
|-
| '''Preise''' || ca. 2 € / MOQ: 5 Stück oder vielfaches von 3 (TBD)
|}

== Farbe des Lötstopplackes ==
<pre>
grün |
gelb |
schwarz |24
weiß |1
rot |10
blau |5
</pre>

einfach bitte die Zahl hinter die Farbe, die euch als Lötstopplack am besten gefallen würde, erhöhen.

== minimale Schriftgröße ==

http://www.mikrocontroller.net/attachment/196856/ucruler.pdf ausdrucken und die eigenen Augen testen.

Dann bitte eintragen, welche Größe gerade noch lesbar ist. Die normale Schrift wird eins größer werden, aber falls mal wirklich kein Platz mehr sein sollte würde ich darauf zurückgreifen.

<pre>
1,8 |
1,6 |
1,4 |
1,2 | 6
1,0 | 6
0,8 |
</pre>

== Anpassungen/Ergänzungen ==

Bitte einfach die Zahl bei + oder - erhöhen oder gar nichts eintragen (wichtig, brauch ich nicht, egal), so dass am Ende ein Stimmungsbild entsteht. Daraus ergeben sich dann Prioritäten, in deren Reihenfolge der Platz aufgefüllt wird.

{| class="wikitable"

|-
! Name !! Wertung !! Beschreibung

|-
| Formelsamlung
||
<pre>
+| 5
-| 8
</pre>
||
Vielleicht könnte man auch ein paar Formeln unterbringen die oft verwendet werden und trotzdem gerne vergessen werden.

Vorschläge [[Mcnet-ruler#Vorschl.C3.A4ge_f.C3.BCr_Formelsammlung|siehe unten]].

|-
| ✓ Leiterbahnstärken
||
<pre>
1| 1
2| 21
3|
4|
5|
</pre>
||
Bitte genau eine Möglichkeit mit + wählen:
# Bahnen in mm und mil, beschriftet in mm und mil
# Bahnen in mm, beschriftet in mm und mil
# Bahnen in mil, beschriftet in mm und mil
# Bahnen in mm, beschriftet in mm
# Bahnen in mil, beschriftet in mil

|-
| ✓ Inches in mm
||
<pre>
+| 20
-| 1
</pre>
||
Bitte generell Inches in mm umrechnen.

|-
| Isolationsabstände
||
<pre>
+| 28
-|
</pre>
||
Die Tabelle für Isolationsabstände (Luft-/Kriechstrecken) ggf. an in Deutschland geltende Normen anpassen.

|-
| Kabel-Widerstände
||
<pre>
+| 15
-| 7
</pre>
||
Wenn noch Platz ist, wäre eine Tabelle für Kabel-Widerstände gut (sortiert nach gängigen Querschnitten, pro m oder 10m Kabellänge).

|-
| Widerstands-Farbcode-Tabelle
||
<pre>
+| 15
-| 18
</pre>
||
Rückseite Widerstands-Farbcode-Tabelle

|-
| LM317
||
<pre>
+| 5
-| 22
</pre>
||
Tabelle für LM317-Widerstandswerte

|-
| Kapazitäts-/Induktivitätsbelag
||
<pre>
+| 9
-| 3
</pre>
||
Tabellen zum Kapazitäts-/Induktivitätsbelag von Leiterbahnen

|-
| Wellenwiderstände
||
<pre>
+| 9
-| 4
</pre>
||
Richtwerttabellen für Wellenwiderstände, Micro Striplines (insbes. für USB/Ethernet Routing), etc. auf gängigen PCBs

|-
| Wechselstrom Ueff, Upp
||
<pre>
+| 3
-| 20
</pre>
||
Wenn immer noch Platz ist: Tabelle zur Umrechnung von Wechselstromgrößen (Ueff, Upp für gängige Trafowicklungen, 110V, 230V, 240V, 400V, 600V)

Anm.: Sinnvoll für gängige Elko-Spannungen 16VDC, 25VDC, 50VDC, 63VDC, 80VDC.

|-
| f/T-Umrechnung
||
<pre>
+| 4
-| 19
</pre>
||
Und wenn dann noch Platz wäre: Tabelle mit f und T für gängige µC-Frequenzen und Samplingraten

Anm.: Sinnvoll und platzsparend, wenn wie vorgeschlagen für einige wenige gängige Werte (z.B. "8 MHz / 125 ns" und "48 kHz / 20,8 µs").

|-
| PCB-Kühlkörper
||
<pre>
+| 20
-| 2
</pre>
||
Was auch interessant wäre, ist eine Tabelle für Leiterplattenkühlkoerper. K/W pro cm² für div. Kupferstärken!

|-
| ✓ SMD-Footprints R
||
<pre>
+| 30
-| 1
</pre>
||
Die Idee mit den SMD Footprints auf der Rückseite finde ich auch sehr gut.

|-
| ✓ SMD-Größen R
||
<pre>
+| 19
-| 2
</pre>
||
Eine Tabelle mit den Größen (im Sinne von Maßen) von SMD Widerständen ist auch manchmal ganz gut.

|-
| ✓ SMD-Footprints ElKo
||
<pre>
+| 25
-| 1
</pre>
||
Zudem wäre der Footprint von SMD Elkos wenn möglich auf der Rückseite auch ganz praktisch.

|-
| ✓ SMD-Größen Elko
||
<pre>
+| 22
-| 1
</pre>
||
Eine Tabelle mit den Größen (im Sinne von Maßen) von SMD Elkos ist auch manchmal ganz gut.

|-
| E-Reihen
||
<pre>
+| 14
-| 8
</pre>
||
Abdruck der E24-Reihe mit Markierungen für E12, E6.

|-
| TQFP, SOP und SOT Footprint
||
<pre>
+| 20
-| 1
</pre>
||
Der Footprint von TQFP, SOT und SOP Bauteilen auf der Rückseite könnte sich auch als nützlich erweisen

Vorschläge für Footprints [[Mcnet-ruler#Vorschl.C3.A4ge_f.C3.BCr_Footprints|siehe unten]].

|-
| ✓ THT Lochreihe
||
<pre>
+| 11
-| 5
</pre>
||
Ebenso eine kurze Lochreihe im 2,54mm-Raster für THT.

Anm.: Bitte eine lange Lochreihe ähnlich wie von [http://www.mikrocontroller.net/topic/313642#3389830 Chris gezeigt].

|-
| ✓ Kleines Namensfeld
||
<pre>
+| 22
-| 3
</pre>
||
Damit die Lineale nicht "verschwinden", zum selbst beschriften.

|-
| Tabelle Leitfähigkeit/spezifischer Widerstand
||
<pre>
+| 5
-| 7
</pre>
||
Eine Tabelle mit der Leitfähigkeit/spezifischer Widerstand von z.B. Kupfer, Aluminium, Eisen ...

|-
| Temperaturkoeffizent
||
<pre>
+| 4
-| 7
</pre>
||
Eine Tabelle mit den Temperaturkoeffizenten (alpha in 1/k) von z.B. Kupfer, Aluminium, Eisen ...

|-
| ✓ Transistor-Schaltungssymbole
||
<pre>
+| 10
-| 3
</pre>
||
Aufdruck von Transistor-Schaltungssymbolen (bipolar/FET) und THT-LEDs, [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg siehe hier]

|-
| Pin-Beschriftung für einige Footprints
||
<pre>
+| 8
-|
</pre>
||
Einige Footprints (z.B. TO-92, SOT-23 etc.) sollten Beschriftungen für BCE/GDS für gängige Transistortypen bekommen, siehe [http://dmohankumar.files.wordpress.com/2011/05/table-showing-the-pins-of-common-transistors.pdf hier] und [http://www.radiomuseum.org/forum/transistor_connections.html hier]

|-
| Kabelschablone
||
<pre>
+| 6
-|
</pre>
||
Ähnlich dem [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg Adafruit Ruler], aber als Tabelle in AWG und mm.

|-
| Seitenansicht bedrahtetes LED Gehäuse
||
<pre>
+| 1
-| 1
</pre>
||
Somit kann man auch bei einer verbauten LED (oder entlöteten LED) mit einem Blick von der Seite erkennen, welcher Pin Anode und welche Kathode ist
Ähnlich dem [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg Adafruit Ruler], unter "AWG 13".

|}

== Vorschläge für Formelsammlung ==

{| class="wikitable"

|-
! Name !! Wertung !! Beschreibung

|-
| C/L
||
<pre>
+| 1
-| 1
</pre>
||
http://upload.wikimedia.org/math/d/5/5/d550b39c146790974bae8a9a2e1830fb.png

http://upload.wikimedia.org/math/0/9/a/09ab806c34320b749ddadca35a32fc8a.png

http://de.wikipedia.org/wiki/Elektrische_Kapazit%C3%A4t#Kapazit.C3.A4t_bestimmter_Leiteranordnungen

http://de.wikipedia.org/wiki/Induktivit%C3%A4t#Induktivit.C3.A4t_einer_Zylinderspule

|-
| Eckfrequenz RC-Glied HP/LP
||
<pre>
+| 1
-| 2
</pre>
||
http://upload.wikimedia.org/math/5/d/1/5d1295e236a3c860416fbdb9940fb043.png

http://de.wikipedia.org/wiki/RC-Glied#Tiefpass

|-
| I(t) / U(t) für C/L
||
<pre>
+| 2
-| 1
</pre>
||
http://upload.wikimedia.org/math/0/b/9/0b93b4a1ce2832629d42509b43184894.png

http://upload.wikimedia.org/math/9/e/6/9e6ea02a73a08f263454786c1c9d7e44.png

http://de.wikipedia.org/wiki/Zeitkonstante#Kondensator

|-
| Wärmewiderstand
||
<pre>
+| 1
-| 1
</pre>
||
http://upload.wikimedia.org/math/8/7/b/87b98460f0867373471f540167591ebb.png

http://de.wikipedia.org/wiki/W%C3%A4rmewiderstand#Definition

|}

== Vorschläge für Footprints ==

Vorschläge für Footprints auf der Rückseite. Es werden die Pads in Kupfer ausgeführt (also theoretisch lötbar), der Rand des Bauteils im Bestückungsdruck.

* http://www.fairchildsemi.com/package/
* http://www.maximintegrated.com/design/packaging/
* http://www.infineon.com/cms/de/product/technology/packages/index.html
* http://www.nxp.com/packages
* http://www.topline.tv/Drawings/PDF/QFP/TQFP_Library.pdf
* http://www.linear.com/designtools/packaging/
* http://ww1.microchip.com/downloads/en/PackagingSpec/00049AR.pdf

=== Standardisierungen ===
* http://www.jedec.org/category/technology-focus-area/registered-outlines-jep95

=== Inspirationen ===

Siehe auch [http://www.adafruit.com/blog/2013/10/11/new-product-adafruit-pcb-ruler-6/ Adafruit Ruler].

http://www.adafruit.com/images/large/1554bottom_LRG.jpg

=== Widerstände & Kondensatoren ===
Maße siehe z.B. http://www.panasonic.com/industrial/components/pdf/AOA0000CE1.pdf

* ✓ 0201 (wenn der Fertiger des Lineal das kann...)
* ✓ 0402
* ✓ 0603
* ✓ 0805
* ✓ 1206
* ✓ 1210
* 1812 (wenn noch Platz ist)
* 2010 (wenn noch Platz ist)
* 2512 (wenn noch Platz ist)

=== Transistoren & ICs ===

* ✓ SC-70
* ✓ SOT-23
* ✓ SOT-23-6
* ✓ SOT-89
* ✓ SOT-223
* ✓ TO-252 / DPAK http://www.fairchildsemi.com/dwg/TO/TO252A03.pdf
* ✓ TO-263 / D2PAK http://www.fairchildsemi.com/dwg/TO/TO263A02.pdf

=== Dioden & LEDs ===

* ✓ SMA / DO-214AC http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ SMB / DO-214AA http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ SMC / DO-214AB http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ Melf http://www.cdil.com/package/do213ab_dwng.pdf
* ✓ MiniMelf http://www.cdil.com/package/sod_80c.pdf
* ✓ MicroMelf http://www.vishay.com/docs/20003/smm0102.pdf
* ✓ PLCC-4 / 3528 http://catalog.osram-os.com/media/_en/Graphics/00042269_0.pdf
* ✓ PLCC-6 / 5050 http://ledversand24.de/media/pdf/ws2812preliminary51337f1c83131.pdf
* ✓ SOD323/SC76 http://www.infineon.com/dgdl/SOD323-Package_Overview.pdf?folderId=db3a30431936bc4b011952aab84f3bbe&fileId=db3a30431936bc4b011952beed653be3

=== ICs ===

* ✓ SOIC-24, 3.9mm-Body, ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24 Pins anzeichen, Pinzahl ranschreiben
* ✓ SOIC-24, 7.5mm-Body, ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24 Pins anzeichen, Pinzahl ranschreiben
Diese beiden SOIC-Breiten wenn möglich in einem Footprint zusammenfassen, also z.B. die linken Pins gemeinsam verwenden. Die beiden
Breiten dann über Bestückungsdruck-Linien kennzeichnen.

* ✓ SSOP-28, 5,3mm-Body, 0,65mm Pitch. Das ist die gängigste Variante, es gibt aber leider auch einige Abweichler mit anderem Pitch und Bodybreite die sich auch SSOP nennen :(
* TSSOP-28, 4,4mm-Body, 0,65mm Pitch
Auch bei diesen beiden: ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24,28 Pins anzeichen, Pinzahl ranschreiben

Für die Maße: http://www.microchip.com/stellent/groups/techpub_sg/documents/packagingspec/en012702.pdf

Wenn noch Platz:
* TQFP32, 0.8mm Pitch http://www.microchip.com/stellent/groups/techpub_sg/documents/packagingspec/en012702.pdf
* TQFP48 / LQFP48, 0.5mm Pitch http://www.nxp.com/documents/outline_drawing/sot313-2_po.pdf
* ✓ QFN32, 0.5mm Pitch http://www.linear.com/docs/38749

== Vorbestellungen ==
Interessenten tragen sich bitte '''am Ende der Liste ein und aktualisieren den Zwischenstand'''!

Mindestbestellmenge ist nach aktuellem Stand 5 Stück.

<pre>
10 Dominik S. (dasd)
5 Dennis X. (debegr92)
2 Arne M. (armut)
3 Benedikt K. (benek)
10 avr avr (colombo010)
5 Jürgen (Gast)
5 Uwe ... (uwegw)
15 Rene H. (promeus)
5 hum (Gast)
3 Werner A. (homebrew)
2 Frank Werner (wesoft)
5 Jan B. (diphthong)
5 Thomas J. (tom16)
15 Felix Schulze (pepe)
3 Patrick Berninghaus (patricck)
5 B. B. (morgenmuffel)
5 Bernd D. (bernd_d56)
5 Daniel (Gast)
5 Jan Dressler (keyman)
3 Gerd E. (robberknight)
10 Ralf Engelhardt (r_e)
5 D. S. (compuvidy)
5 Michael R. (elektr-hobbyist)
10 Samuel Hildebrandt (musicsammy)
5 Martin H. (marrtn)
5 Michael Becker (mich_at_el)
5 Marco André (marphy)
5 Chris (Gast)
5 mr. mo (Gast)
5 Martin R. (martin84)
3 J. S. (voochee)
5 Andreas H. (ahz)
5 Ronny Spiegel (duselbaer)
10 G. L. (lele)
3 Axel Jäger (axeljaeger)
5 Stephan G. (stephan_g35)
5 Gibts Ne (schneeblau)
5 Sascha G. (sascha-g)
5 Richard Zink (Gast)
5 Stephan K. (nightowl)
5 Martin Wende (Firma: fritzler-avr.de) (fritzler)
5 Jörg S. (Gast)
10 J. L. (lindenbaum)
10 Jan M. (mueschel)
5 Bad Urban (bad_urban)
5 Daniel M. (amad)
5 Sascha S. (dec)
5 A. S. (rava)
10 Jens M. (jens-m)
5 Sascha E. (baracuss)
5 avr avr (colombo010)
5 Michael B. (michael_b25)
10 Thomas Sch. (doschi_)
10 K. J. (theborg0815)
5 Daniel C. (cecky)
3 Philipp E. (erlang)
5 Thorsten Ostermann (Firma: mechapro GmbH) (ostermann)
10 vophatec (Manuel Z.)
3 Carsten Peschke
2 J.O. (Gast)
5 D. Braun (garag)
5 Michael.S. (michael0307)
5 Didi S. (kokisan2000)
5 Thomas L. (ics1702)
5 Sebastian Engel (s-engel)
5 Peter Sieg (petersieg)
5 Martin S. (martin_s91)
5 Manuel Steiner (steinerhippo)
5 Nico B. (vegetico)
5 Axel P. (axel_p)
5 Mh. M. (mhm)
5 Friedrich K (*)
5 O.Hagendorf (ohagendorf)
10 Jonas K. (jonas k)
5 Sam .. (sam1994)
10 Jens A. (Nepi) (erhöht von 5 auf 10 am 15.1.2014)
5 Tom Z. (tom_z)
5 Sven K. (herbivore)
5 Steffen A (*)
3 Stephan Henning (stephan-) notfalls auch 5
5 Benjamin Jung (benjamin_j)
5 Kai D. (kai1972)
5 Gerd B. (bertr2d2)
5 Martin G. (magoe)
5 Stefan K. (oxid)
5 S. Q. (frido2001)
5 D. K. (elektricar)
5 Markus C. (ljmarkus)
5 Alexander K. (minjaman)
10 Dominic A. (neo123)
3 Oliver S. (Oliver_S) notfalls auch 5
5 Tobias S. (x12z34)
5 Frank F. (frohf)
5 Kalle S. (kallebmw)
5 Bjoern G. (tueftler)
5 Akif D. (adnc)
5 Rico T. (tyrann410)
5 Axel (axelg)
10 Elmar N. (zulue)
5 Frank G. (frank_g53)
15 pko pprasch (pkopprasch)
5 Alexander D. (Gast)
5 Marius B. (majus)
20 F.FO (foldi)
5 Stefan P. (nett_flanders)
5 Carsten Wille (eagle38106)
5 Steffen Schröter (stesch99)
5 Guido C. (guidoanalog)
5 Yann L. (ylere)
5 Benedikt R. (da_miez)
5 Thorsten F. (tfol)
3 Oliver H. (oliver h) notfalls auch 5
2 Zoidberg (Gast) 5 nur extrem ungern
5 Markus M (mmax)
10 Maik Fox (sabuty)
5 DL9RDW (Bernhard Schröcker)
10 Fer T. (fer_t)
5 Einhart (einhart)
5 Teo Derix (teoderix)
3 Volker R. (Pcl86) wenn's nicht anders geht auch 5
5 John (karabka)
5 Matthias N. (nippey)
5 David Z. (hawk_2k)
5 Volker G. (voga2073)
20 Stefan Wagner (dl6dx)
20 Tobias Hochgürtel (tobias_h94)
10 Matthias H. (kaplic)
5 Juli V. (torten_juli)
5 Edu B. (edu)
5 Joe G. (Feinmechaniker)
10 Peter (elektronik24)
-------------------------------------
779 ZWISCHENSTAND
</pre>

Mcruler

2014-08-18T12:12:28Z

Longri:

== Infos ==

Hier soll eine Community Variante eines Lineals entstehen, nach Vorbild des µRuler von EEVBlog/Dave Jones:

[[Datei:uRuler.jpg|1200px]]

'''Aktueller Stand:'''

[https://raw.github.com/maugsburger/ucruler/master/ucruler_top.png Top]

[https://raw.github.com/maugsburger/ucruler/master/ucruler_bot.png Bottom]

'''Thread im Forum:''' http://www.mikrocontroller.net/topic/313642

'''Projekt-Seite auf GitHub:''' https://github.com/maugsburger/ucruler

== Spezifikationen ==

{| class="wikitable"
|-
| Maße || 200 x 32 mm
|-
| PCB || 0.5mm oder 0.8mm FR4 '''1-Layer''' 35µ (TBD)
|-
| Oberfläche || gold (ENIG)
|-
| Lötstop || beidseitig, Farbe TBD
|-
| Bestückungsdruck || beidseitig, weiß
|-
| '''Preise''' || ca. 2 € / MOQ: 5 Stück oder vielfaches von 3 (TBD)
|}

== Farbe des Lötstopplackes ==
<pre>
grün |
gelb |
schwarz |24
weiß |1
rot |10
blau |5
</pre>

einfach bitte die Zahl hinter die Farbe, die euch als Lötstopplack am besten gefallen würde, erhöhen.

== minimale Schriftgröße ==

http://www.mikrocontroller.net/attachment/196856/ucruler.pdf ausdrucken und die eigenen Augen testen.

Dann bitte eintragen, welche Größe gerade noch lesbar ist. Die normale Schrift wird eins größer werden, aber falls mal wirklich kein Platz mehr sein sollte würde ich darauf zurückgreifen.

<pre>
1,8 |
1,6 |
1,4 |
1,2 | 6
1,0 | 6
0,8 |
</pre>

== Anpassungen/Ergänzungen ==

Bitte einfach die Zahl bei + oder - erhöhen oder gar nichts eintragen (wichtig, brauch ich nicht, egal), so dass am Ende ein Stimmungsbild entsteht. Daraus ergeben sich dann Prioritäten, in deren Reihenfolge der Platz aufgefüllt wird.

{| class="wikitable"

|-
! Name !! Wertung !! Beschreibung

|-
| Formelsamlung
||
<pre>
+| 5
-| 7
</pre>
||
Vielleicht könnte man auch ein paar Formeln unterbringen die oft verwendet werden und trotzdem gerne vergessen werden.

Vorschläge [[Mcnet-ruler#Vorschl.C3.A4ge_f.C3.BCr_Formelsammlung|siehe unten]].

|-
| ✓ Leiterbahnstärken
||
<pre>
1| 1
2| 20
3|
4|
5|
</pre>
||
Bitte genau eine Möglichkeit mit + wählen:
# Bahnen in mm und mil, beschriftet in mm und mil
# Bahnen in mm, beschriftet in mm und mil
# Bahnen in mil, beschriftet in mm und mil
# Bahnen in mm, beschriftet in mm
# Bahnen in mil, beschriftet in mil

|-
| ✓ Inches in mm
||
<pre>
+| 20
-| 1
</pre>
||
Bitte generell Inches in mm umrechnen.

|-
| Isolationsabstände
||
<pre>
+| 28
-|
</pre>
||
Die Tabelle für Isolationsabstände (Luft-/Kriechstrecken) ggf. an in Deutschland geltende Normen anpassen.

|-
| Kabel-Widerstände
||
<pre>
+| 15
-| 7
</pre>
||
Wenn noch Platz ist, wäre eine Tabelle für Kabel-Widerstände gut (sortiert nach gängigen Querschnitten, pro m oder 10m Kabellänge).

|-
| Widerstands-Farbcode-Tabelle
||
<pre>
+| 15
-| 18
</pre>
||
Rückseite Widerstands-Farbcode-Tabelle

|-
| LM317
||
<pre>
+| 5
-| 22
</pre>
||
Tabelle für LM317-Widerstandswerte

|-
| Kapazitäts-/Induktivitätsbelag
||
<pre>
+| 9
-| 3
</pre>
||
Tabellen zum Kapazitäts-/Induktivitätsbelag von Leiterbahnen

|-
| Wellenwiderstände
||
<pre>
+| 9
-| 4
</pre>
||
Richtwerttabellen für Wellenwiderstände, Micro Striplines (insbes. für USB/Ethernet Routing), etc. auf gängigen PCBs

|-
| Wechselstrom Ueff, Upp
||
<pre>
+| 3
-| 20
</pre>
||
Wenn immer noch Platz ist: Tabelle zur Umrechnung von Wechselstromgrößen (Ueff, Upp für gängige Trafowicklungen, 110V, 230V, 240V, 400V, 600V)

Anm.: Sinnvoll für gängige Elko-Spannungen 16VDC, 25VDC, 50VDC, 63VDC, 80VDC.

|-
| f/T-Umrechnung
||
<pre>
+| 4
-| 19
</pre>
||
Und wenn dann noch Platz wäre: Tabelle mit f und T für gängige µC-Frequenzen und Samplingraten

Anm.: Sinnvoll und platzsparend, wenn wie vorgeschlagen für einige wenige gängige Werte (z.B. "8 MHz / 125 ns" und "48 kHz / 20,8 µs").

|-
| PCB-Kühlkörper
||
<pre>
+| 20
-| 2
</pre>
||
Was auch interessant wäre, ist eine Tabelle für Leiterplattenkühlkoerper. K/W pro cm² für div. Kupferstärken!

|-
| ✓ SMD-Footprints R
||
<pre>
+| 30
-| 1
</pre>
||
Die Idee mit den SMD Footprints auf der Rückseite finde ich auch sehr gut.

|-
| ✓ SMD-Größen R
||
<pre>
+| 19
-| 2
</pre>
||
Eine Tabelle mit den Größen (im Sinne von Maßen) von SMD Widerständen ist auch manchmal ganz gut.

|-
| ✓ SMD-Footprints ElKo
||
<pre>
+| 25
-| 1
</pre>
||
Zudem wäre der Footprint von SMD Elkos wenn möglich auf der Rückseite auch ganz praktisch.

|-
| ✓ SMD-Größen Elko
||
<pre>
+| 22
-| 1
</pre>
||
Eine Tabelle mit den Größen (im Sinne von Maßen) von SMD Elkos ist auch manchmal ganz gut.

|-
| E-Reihen
||
<pre>
+| 14
-| 8
</pre>
||
Abdruck der E24-Reihe mit Markierungen für E12, E6.

|-
| TQFP, SOP und SOT Footprint
||
<pre>
+| 20
-| 1
</pre>
||
Der Footprint von TQFP, SOT und SOP Bauteilen auf der Rückseite könnte sich auch als nützlich erweisen

Vorschläge für Footprints [[Mcnet-ruler#Vorschl.C3.A4ge_f.C3.BCr_Footprints|siehe unten]].

|-
| ✓ THT Lochreihe
||
<pre>
+| 11
-| 5
</pre>
||
Ebenso eine kurze Lochreihe im 2,54mm-Raster für THT.

Anm.: Bitte eine lange Lochreihe ähnlich wie von [http://www.mikrocontroller.net/topic/313642#3389830 Chris gezeigt].

|-
| ✓ Kleines Namensfeld
||
<pre>
+| 22
-| 3
</pre>
||
Damit die Lineale nicht "verschwinden", zum selbst beschriften.

|-
| Tabelle Leitfähigkeit/spezifischer Widerstand
||
<pre>
+| 5
-| 7
</pre>
||
Eine Tabelle mit der Leitfähigkeit/spezifischer Widerstand von z.B. Kupfer, Aluminium, Eisen ...

|-
| Temperaturkoeffizent
||
<pre>
+| 4
-| 7
</pre>
||
Eine Tabelle mit den Temperaturkoeffizenten (alpha in 1/k) von z.B. Kupfer, Aluminium, Eisen ...

|-
| ✓ Transistor-Schaltungssymbole
||
<pre>
+| 10
-| 3
</pre>
||
Aufdruck von Transistor-Schaltungssymbolen (bipolar/FET) und THT-LEDs, [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg siehe hier]

|-
| Pin-Beschriftung für einige Footprints
||
<pre>
+| 8
-|
</pre>
||
Einige Footprints (z.B. TO-92, SOT-23 etc.) sollten Beschriftungen für BCE/GDS für gängige Transistortypen bekommen, siehe [http://dmohankumar.files.wordpress.com/2011/05/table-showing-the-pins-of-common-transistors.pdf hier] und [http://www.radiomuseum.org/forum/transistor_connections.html hier]

|-
| Kabelschablone
||
<pre>
+| 6
-|
</pre>
||
Ähnlich dem [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg Adafruit Ruler], aber als Tabelle in AWG und mm.

|-
| Seitenansicht bedrahtetes LED Gehäuse
||
<pre>
+| 1
-| 1
</pre>
||
Somit kann man auch bei einer verbauten LED (oder entlöteten LED) mit einem Blick von der Seite erkennen, welcher Pin Anode und welche Kathode ist
Ähnlich dem [http://www.adafruit.com/index.php?main_page=popup_image_additional&pID=1554&pic=1&products_image_large_additional=images/large/1554bottom_LRG.jpg Adafruit Ruler], unter "AWG 13".

|}

== Vorschläge für Formelsammlung ==

{| class="wikitable"

|-
! Name !! Wertung !! Beschreibung

|-
| C/L
||
<pre>
+| 1
-| 1
</pre>
||
http://upload.wikimedia.org/math/d/5/5/d550b39c146790974bae8a9a2e1830fb.png

http://upload.wikimedia.org/math/0/9/a/09ab806c34320b749ddadca35a32fc8a.png

http://de.wikipedia.org/wiki/Elektrische_Kapazit%C3%A4t#Kapazit.C3.A4t_bestimmter_Leiteranordnungen

http://de.wikipedia.org/wiki/Induktivit%C3%A4t#Induktivit.C3.A4t_einer_Zylinderspule

|-
| Eckfrequenz RC-Glied HP/LP
||
<pre>
+| 1
-| 2
</pre>
||
http://upload.wikimedia.org/math/5/d/1/5d1295e236a3c860416fbdb9940fb043.png

http://de.wikipedia.org/wiki/RC-Glied#Tiefpass

|-
| I(t) / U(t) für C/L
||
<pre>
+| 2
-| 1
</pre>
||
http://upload.wikimedia.org/math/0/b/9/0b93b4a1ce2832629d42509b43184894.png

http://upload.wikimedia.org/math/9/e/6/9e6ea02a73a08f263454786c1c9d7e44.png

http://de.wikipedia.org/wiki/Zeitkonstante#Kondensator

|-
| Wärmewiderstand
||
<pre>
+| 1
-| 1
</pre>
||
http://upload.wikimedia.org/math/8/7/b/87b98460f0867373471f540167591ebb.png

http://de.wikipedia.org/wiki/W%C3%A4rmewiderstand#Definition

|}

== Vorschläge für Footprints ==

Vorschläge für Footprints auf der Rückseite. Es werden die Pads in Kupfer ausgeführt (also theoretisch lötbar), der Rand des Bauteils im Bestückungsdruck.

* http://www.fairchildsemi.com/package/
* http://www.maximintegrated.com/design/packaging/
* http://www.infineon.com/cms/de/product/technology/packages/index.html
* http://www.nxp.com/packages
* http://www.topline.tv/Drawings/PDF/QFP/TQFP_Library.pdf
* http://www.linear.com/designtools/packaging/
* http://ww1.microchip.com/downloads/en/PackagingSpec/00049AR.pdf

=== Standardisierungen ===
* http://www.jedec.org/category/technology-focus-area/registered-outlines-jep95

=== Inspirationen ===

Siehe auch [http://www.adafruit.com/blog/2013/10/11/new-product-adafruit-pcb-ruler-6/ Adafruit Ruler].

http://www.adafruit.com/images/large/1554bottom_LRG.jpg

=== Widerstände & Kondensatoren ===
Maße siehe z.B. http://www.panasonic.com/industrial/components/pdf/AOA0000CE1.pdf

* ✓ 0201 (wenn der Fertiger des Lineal das kann...)
* ✓ 0402
* ✓ 0603
* ✓ 0805
* ✓ 1206
* ✓ 1210
* 1812 (wenn noch Platz ist)
* 2010 (wenn noch Platz ist)
* 2512 (wenn noch Platz ist)

=== Transistoren & ICs ===

* ✓ SC-70
* ✓ SOT-23
* ✓ SOT-23-6
* ✓ SOT-89
* ✓ SOT-223
* ✓ TO-252 / DPAK http://www.fairchildsemi.com/dwg/TO/TO252A03.pdf
* ✓ TO-263 / D2PAK http://www.fairchildsemi.com/dwg/TO/TO263A02.pdf

=== Dioden & LEDs ===

* ✓ SMA / DO-214AC http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ SMB / DO-214AA http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ SMC / DO-214AB http://www.jedec.org/sites/default/files/docs/DO-214D.PDF
* ✓ Melf http://www.cdil.com/package/do213ab_dwng.pdf
* ✓ MiniMelf http://www.cdil.com/package/sod_80c.pdf
* ✓ MicroMelf http://www.vishay.com/docs/20003/smm0102.pdf
* ✓ PLCC-4 / 3528 http://catalog.osram-os.com/media/_en/Graphics/00042269_0.pdf
* ✓ PLCC-6 / 5050 http://ledversand24.de/media/pdf/ws2812preliminary51337f1c83131.pdf
* ✓ SOD323/SC76 http://www.infineon.com/dgdl/SOD323-Package_Overview.pdf?folderId=db3a30431936bc4b011952aab84f3bbe&fileId=db3a30431936bc4b011952beed653be3

=== ICs ===

* ✓ SOIC-24, 3.9mm-Body, ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24 Pins anzeichen, Pinzahl ranschreiben
* ✓ SOIC-24, 7.5mm-Body, ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24 Pins anzeichen, Pinzahl ranschreiben
Diese beiden SOIC-Breiten wenn möglich in einem Footprint zusammenfassen, also z.B. die linken Pins gemeinsam verwenden. Die beiden
Breiten dann über Bestückungsdruck-Linien kennzeichnen.

* ✓ SSOP-28, 5,3mm-Body, 0,65mm Pitch. Das ist die gängigste Variante, es gibt aber leider auch einige Abweichler mit anderem Pitch und Bodybreite die sich auch SSOP nennen :(
* TSSOP-28, 4,4mm-Body, 0,65mm Pitch
Auch bei diesen beiden: ein Footprint, aber mit Bestückungsdruck-Linien die kleineren Varianten für 8,14,16,20,24,28 Pins anzeichen, Pinzahl ranschreiben

Für die Maße: http://www.microchip.com/stellent/groups/techpub_sg/documents/packagingspec/en012702.pdf

Wenn noch Platz:
* TQFP32, 0.8mm Pitch http://www.microchip.com/stellent/groups/techpub_sg/documents/packagingspec/en012702.pdf
* TQFP48 / LQFP48, 0.5mm Pitch http://www.nxp.com/documents/outline_drawing/sot313-2_po.pdf
* ✓ QFN32, 0.5mm Pitch http://www.linear.com/docs/38749

== Vorbestellungen ==
Interessenten tragen sich bitte '''am Ende der Liste ein und aktualisieren den Zwischenstand'''!

Mindestbestellmenge ist nach aktuellem Stand 5 Stück.

<pre>
10 Dominik S. (dasd)
5 Dennis X. (debegr92)
2 Arne M. (armut)
3 Benedikt K. (benek)
10 avr avr (colombo010)
5 Jürgen (Gast)
5 Uwe ... (uwegw)
15 Rene H. (promeus)
5 hum (Gast)
3 Werner A. (homebrew)
2 Frank Werner (wesoft)
5 Jan B. (diphthong)
5 Thomas J. (tom16)
15 Felix Schulze (pepe)
3 Patrick Berninghaus (patricck)
5 B. B. (morgenmuffel)
5 Bernd D. (bernd_d56)
5 Daniel (Gast)
5 Jan Dressler (keyman)
3 Gerd E. (robberknight)
10 Ralf Engelhardt (r_e)
5 D. S. (compuvidy)
5 Michael R. (elektr-hobbyist)
10 Samuel Hildebrandt (musicsammy)
5 Martin H. (marrtn)
5 Michael Becker (mich_at_el)
5 Marco André (marphy)
5 Chris (Gast)
5 mr. mo (Gast)
5 Martin R. (martin84)
3 J. S. (voochee)
5 Andreas H. (ahz)
5 Ronny Spiegel (duselbaer)
10 G. L. (lele)
3 Axel Jäger (axeljaeger)
5 Stephan G. (stephan_g35)
5 Gibts Ne (schneeblau)
5 Sascha G. (sascha-g)
5 Richard Zink (Gast)
5 Stephan K. (nightowl)
5 Martin Wende (Firma: fritzler-avr.de) (fritzler)
5 Jörg S. (Gast)
10 J. L. (lindenbaum)
10 Jan M. (mueschel)
5 Bad Urban (bad_urban)
5 Daniel M. (amad)
5 Sascha S. (dec)
5 A. S. (rava)
10 Jens M. (jens-m)
5 Sascha E. (baracuss)
5 avr avr (colombo010)
5 Michael B. (michael_b25)
10 Thomas Sch. (doschi_)
10 K. J. (theborg0815)
5 Daniel C. (cecky)
3 Philipp E. (erlang)
5 Thorsten Ostermann (Firma: mechapro GmbH) (ostermann)
10 vophatec (Manuel Z.)
3 Carsten Peschke
2 J.O. (Gast)
5 D. Braun (garag)
5 Michael.S. (michael0307)
5 Didi S. (kokisan2000)
5 Thomas L. (ics1702)
5 Sebastian Engel (s-engel)
5 Peter Sieg (petersieg)
5 Martin S. (martin_s91)
5 Manuel Steiner (steinerhippo)
5 Nico B. (vegetico)
5 Axel P. (axel_p)
5 Mh. M. (mhm)
5 Friedrich K (*)
5 O.Hagendorf (ohagendorf)
10 Jonas K. (jonas k)
5 Sam .. (sam1994)
10 Jens A. (Nepi) (erhöht von 5 auf 10 am 15.1.2014)
5 Tom Z. (tom_z)
5 Sven K. (herbivore)
5 Steffen A (*)
3 Stephan Henning (stephan-) notfalls auch 5
5 Benjamin Jung (benjamin_j)
5 Kai D. (kai1972)
5 Gerd B. (bertr2d2)
5 Martin G. (magoe)
5 Stefan K. (oxid)
5 S. Q. (frido2001)
5 D. K. (elektricar)
5 Markus C. (ljmarkus)
5 Alexander K. (minjaman)
10 Dominic A. (neo123)
3 Oliver S. (Oliver_S) notfalls auch 5
5 Tobias S. (x12z34)
5 Frank F. (frohf)
5 Kalle S. (kallebmw)
5 Bjoern G. (tueftler)
5 Akif D. (adnc)
5 Rico T. (tyrann410)
5 Axel (axelg)
10 Elmar N. (zulue)
5 Frank G. (frank_g53)
15 pko pprasch (pkopprasch)
5 Alexander D. (Gast)
5 Marius B. (majus)
20 F.FO (foldi)
5 Stefan P. (nett_flanders)
5 Carsten Wille (eagle38106)
5 Steffen Schröter (stesch99)
5 Guido C. (guidoanalog)
5 Yann L. (ylere)
5 Benedikt R. (da_miez)
5 Thorsten F. (tfol)
3 Oliver H. (oliver h) notfalls auch 5
2 Zoidberg (Gast) 5 nur extrem ungern
5 Markus M (mmax)
10 Maik Fox (sabuty)
5 DL9RDW (Bernhard Schröcker)
10 Fer T. (fer_t)
5 Einhart (einhart)
5 Teo Derix (teoderix)
3 Volker R. (Pcl86) wenn's nicht anders geht auch 5
5 John (karabka)
5 Matthias N. (nippey)
5 David Z. (hawk_2k)
5 Volker G. (voga2073)
20 Stefan Wagner (dl6dx)
20 Tobias Hochgürtel (tobias_h94)
10 Matthias H. (kaplic)
5 Juli V. (torten_juli)
5 Edu B. (edu)
5 Joe G. (Feinmechaniker)
10 Peter (elektronik24)
-------------------------------------
779 ZWISCHENSTAND
</pre>

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-08-05T13:22:29Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.

== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt. Die Schaltung und das Layout für Hardware wurde mit der Software Eagle 6.4 in der Freeware-Version erstellt. Das übertragen des Layouts auf die Leiterplatten erfolgte im Tonertransfer-Verfahren, geätzt wurde mit CuCl2
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ham-radio/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

<gallery>
Datei:Messkoppler.JPG|SWR-Messkoppler
Datei:Prozessorboard.jpg|Prozessorboard
Datei:Motoransteuerung.jpg|Motoransteuerung
Datei:RS-232_Schnittstelle.jpg|RS-232 Schittstelle
Datei:Prototyp.jpg|Prototyp
Datei:DAVE3.jpg|DAVE3-Apps
</gallery>

[[Medium:Hardware.zip|Schaltungsunterlagen]]

[[Medium:Software.zip|Software]]

== Weblinks ==
*[http://www.mikrocontroller.net/user/show/longri Kontakt zum Autor hier im Forum]
*[http://longrisoft.de/ Homepage des Autors]
*[http://www.infineonforums.com/forums/8-XMC-Forum XMC-Forum] (englisch)
*[http://www.keil.com/pack/doc/cmsis_rtx/index.html CMSIS-RTX Dokumentation]
*[http://www.infineon.com/cms/en/product/promopages/aim-mc/dave_downloads.html Beispielprojekte von Infineon]

[[Kategorie:Infineon_XMC_Design_Contest_2014]]
[[Kategorie:Projekte]]
[[Kategorie:ARM]]

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T15:51:18Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.

== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt. Die Schaltung und das Layout für Hardware wurde mit der Software Eagle 6.4 in der Freeware-Version erstellt. Das übertragen des Layouts auf die Leiterplatten erfolgte im Tonertransfer-Verfahren, geätzt wurde mit CuCl2
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

<gallery>
Datei:Messkoppler.JPG|SWR-Messkoppler
Datei:Prozessorboard.jpg|Prozessorboard
Datei:Motoransteuerung.jpg|Motoransteuerung
Datei:RS-232_Schnittstelle.jpg|RS-232 Schittstelle
Datei:Prototyp.jpg|Prototyp
Datei:DAVE3.jpg|DAVE3-Apps
</gallery>

[[Medium:Hardware.zip|Schaltungsunterlagen]]

[[Medium:Software.zip|Software]]

== Weblinks ==
*[http://www.mikrocontroller.net/user/show/longri Kontakt zum Autor hier im Forum]
*[http://longrisoft.de/ Homepage des Autors]
*[http://www.infineonforums.com/forums/8-XMC-Forum XMC-Forum] (englisch)
*[http://www.keil.com/pack/doc/cmsis_rtx/index.html CMSIS-RTX Dokumentation]
*[http://www.infineon.com/cms/en/product/promopages/aim-mc/dave_downloads.html Beispielprojekte von Infineon]

[[Kategorie:Infineon_XMC_Design_Contest_2014]]
[[Kategorie:Projekte]]
[[Kategorie:ARM]]

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T15:19:07Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
<gallery>

</gallery>
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

<gallery>
Datei:Messkoppler.JPG|SWR-Messkoppler
Datei:Prozessorboard.jpg|Prozessorboard
Datei:Motoransteuerung.jpg|Motoransteuerung
Datei:RS-232_Schnittstelle.jpg|RS-232 Schittstelle
Datei:Prototyp.jpg|Prototyp
Datei:DAVE3.jpg|DAVE3-Apps
</gallery>

[[Medium:Hardware.zip|Schaltungsunterlagen]]

[[Medium:Software.zip|Software]]

== Weblinks ==
*[http://www.mikrocontroller.net/user/show/longri Kontakt zum Autor hier im Forum]
*[http://longrisoft.de/ Homepage des Autors]
*[http://www.infineonforums.com/forums/8-XMC-Forum XMC-Forum] (englisch)
*[http://www.keil.com/pack/doc/cmsis_rtx/index.html CMSIS-RTX Dokumentation]
*[http://www.infineon.com/cms/en/product/promopages/aim-mc/dave_downloads.html Beispielprojekte von Infineon]

[[Kategorie:Infineon_XMC_Design_Contest_2014]]
[[Kategorie:Projekte]]
[[Kategorie:ARM]]

Datei:Hardware.zip

2014-07-20T15:17:58Z

Longri: Longri lud eine neue Version von „Datei:Hardware.zip“ hoch

Datei:Hardware.zip

2014-07-20T15:17:41Z

Longri: Longri lud eine neue Version von „Datei:Hardware.zip“ hoch

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T15:10:17Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
<gallery>

</gallery>
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

<gallery>
Datei:Messkoppler.JPG|SWR-Messkoppler
Datei:Prozessorboard.jpg|Prozessorboard
Datei:Motoransteuerung.jpg|Motoransteuerung
Datei:RS-232_Schnittstelle.jpg|RS-232 Schittstelle
Datei:Prototyp.jpg|Prototyp
Datei:DAVE3.jpg|DAVE3-Apps
</gallery>

[[Datei:Hardware.zip|Schaltungsunterlagen]]

[[Datei:Software.zip|Software]]

== Weblinks ==
*[http://www.mikrocontroller.net/user/show/longri Kontakt zum Autor hier im Forum]
*[http://longrisoft.de/ Homepage des Autors]
*[http://www.infineonforums.com/forums/8-XMC-Forum XMC-Forum] (englisch)
*[http://www.keil.com/pack/doc/cmsis_rtx/index.html CMSIS-RTX Dokumentation]
*[http://www.infineon.com/cms/en/product/promopages/aim-mc/dave_downloads.html Beispielprojekte von Infineon]

[[Kategorie:Infineon_XMC_Design_Contest_2014]]
[[Kategorie:Projekte]]
[[Kategorie:ARM]]

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T15:08:28Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
<gallery>

</gallery>
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

<gallery>
Datei:Messkoppler.JPG|SWR-Messkoppler
Datei:Prozessorboard.jpg|Prozessorboard
Datei:Motoransteuerung.jpg|Motoransteuerung
Datei:RS-232_Schnittstelle.jpg|RS-232 Schittstelle
Datei:Prototyp.jpg|Prototyp
Datei:DAVE3.jpg|DAVE3-Apps
</gallery>

[[Datei:Hardware.zip|Schaltungsunterlagen]]

[[Datei:Software.zip|Software]]

== Weblinks ==
*[http://www.mikrocontroller.net/user/show/longri Kontakt zum Autor hier im Forum]
*[http://longrisoft.de/ Homepage des Autors]
*[http://www.infineonforums.com/forums/8-XMC-Forum XMC-Forum] (englisch)
*[http://www.keil.com/pack/doc/cmsis_rtx/index.html CMSIS-RTX Dokumentation]
*[http://www.infineon.com/cms/en/product/promopages/aim-mc/dave_downloads.html Beispielprojekte von Infineon]

[[Kategorie:Infineon_XMC_Design_Contest_2014]]
[[Kategorie:Projekte]]
[[Kategorie:ARM]]

Datei:Software.zip

2014-07-20T15:03:55Z

Longri:

Datei:Hardware.zip

2014-07-20T14:59:21Z

Longri:

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T14:58:55Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
<gallery>

</gallery>
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

<gallery>
Datei:Messkoppler.JPG|SWR-Messkoppler
Datei:Prozessorboard.jpg|Prozessorboard
Datei:Motoransteuerung.jpg|Motoransteuerung
Datei:RS-232_Schnittstelle.jpg|RS-232 Schittstelle
Datei:Prototyp.jpg|Prototyp
Datei:DAVE3.jpg|DAVE3-Apps
</gallery>

[[Datei:Hardware.zip|Schaltungsunterlagen]]

[[Datei:Software.zip|Software]]

== Weblinks ==
*[http://www.mikrocontroller.net/user/show/longri Kontakt zum Autor hier im Forum]
*[http://longrisoft.de/ Homepage des Autors]
*[http://www.infineonforums.com/forums/8-XMC-Forum XMC-Forum] (englisch)
*[http://www.keil.com/pack/doc/cmsis_rtx/index.html CMSIS-RTX Dokumentation]
*[http://www.infineon.com/cms/en/product/promopages/aim-mc/dave_downloads.html Beispielprojekte von Infineon]

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T14:48:32Z

Longri: Weitere Vervollständigung der Seite

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
<gallery>

</gallery>
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

{| class="wikitable"
|-
|
[[Datei:Messkoppler.JPG|miniatur|zentriert|SWR-Messkoppler]]
||
[[Datei:Prozessorboard.jpg|miniatur|zentriert|Prozessorboard]]
||
[[Datei:Motoransteuerung.jpg|miniatur|zentriert|Motoransteuerung]]
|-
||
[[Datei:RS-232_Schnittstelle.jpg|miniatur|zentriert|RS-232 Schittstelle]]
||
[[Datei:Prototyp.jpg|miniatur|zentriert|Prototyp]]
||
[[Datei:DAVE3.jpg|miniatur|zentriert|DAVE3-Apps]]
|}

[[Hardware.zip|Schaltungsunterlagen]]

[[Software.zip|Software]]

== Weblinks ==
*[http://www.mikrocontroller.net/user/show/longri Kontakt zum Autor hier im Forum]
*[http://longrisoft.de/ Homepage des Autors]
*[http://www.infineonforums.com/forums/8-XMC-Forum XMC-Forum] (englisch)
*[http://www.keil.com/pack/doc/cmsis_rtx/index.html CMSIS-RTX Dokumentation]
*[http://www.infineon.com/cms/en/product/promopages/aim-mc/dave_downloads.html Beispielprojekte von Infineon]

Datei:DAVE3.jpg

2014-07-20T14:32:43Z

Longri:

Datei:Prototyp.jpg

2014-07-20T14:32:27Z

Longri:

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T14:32:11Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
<gallery>

</gallery>
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

{| class="wikitable"
|-
|
[[Datei:Messkoppler.JPG|miniatur|zentriert|SWR-Messkoppler]]
||
[[Datei:Prozessorboard.jpg|miniatur|zentriert|Prozessorboard]]
||
[[Datei:Motoransteuerung.jpg|miniatur|zentriert|Motoransteuerung]]
|-
||
[[Datei:RS-232_Schnittstelle.jpg|miniatur|zentriert|RS-232 Schittstelle]]
||
[[Datei:Prototyp.jpg|miniatur|zentriert|Prototyp]]
||
[[Datei:DAVE3.jpg|miniatur|zentriert|DAVE3-Apps]]
|}

[[Kategorie:Infineon_XMC_Design_Contest_2014]]

[http://www.mikrocontroller.net/user/show/longri Kontakt]

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T14:30:41Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
<gallery>

</gallery>
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

{| class="wikitable"
|-
|
[[Datei:Messkoppler.JPG|miniatur|zentriert|SWR-Messkoppler]]
||
[[Datei:Prozessorboard.jpg|miniatur|zentriert|Prozessorboard]]
||
[[Datei:Motoransteuerung1.jpg|miniatur|zentriert|Motoransteuerung]]
|-
||
[[Datei:RS-232_Schnittstelle.jpg|miniatur|zentriert|RS-232 Schittstelle]]
||
[[Datei:Prototyp.jpg|miniatur|zentriert|Prototyp]]
||
[[Datei:DAVE3.jpg|miniatur|zentriert|DAVE3-Apps]]
|}

[[Kategorie:Infineon_XMC_Design_Contest_2014]]

[http://www.mikrocontroller.net/user/show/longri Kontakt]

Datei:RS-232 Schnittstelle.jpg

2014-07-20T14:30:02Z

Longri:

Datei:Motoransteuerung.jpg

2014-07-20T14:29:32Z

Longri:

Datei:Prozessorboard.jpg

2014-07-20T14:29:11Z

Longri:

Datei:Messkoppler.JPG

2014-07-20T14:28:39Z

Longri:

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T14:28:08Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
<gallery>

</gallery>
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

{| class="wikitable"
|-
|
[[Datei:Messkoppler.JPG|miniatur|zentriert|SWR-Messkoppler]]
||
[[Datei:Prozessorboard.jpg|miniatur|zentriert|Prozessorboard]]
||
[[Datei:Motoransteuerung.jpg|miniatur|zentriert|Motoransteuerung]]
|-
||
[[Datei:RS-232_Schnittstelle.jpg|miniatur|zentriert|RS-232 Schittstelle]]
||
[[Datei:Prototyp.jpg|miniatur|zentriert|Prototyp]]
||
[[Datei:DAVE3.jpg|miniatur|zentriert|DAVE3-Apps]]
|}

[[Kategorie:Infineon_XMC_Design_Contest_2014]]

[http://www.mikrocontroller.net/user/show/longri Kontakt]

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T14:15:46Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
<gallery>

</gallery>
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

{| class="wikitable"
|-
|[[Datei:Messkoppler.jpg|miniatur]]
|}

[[Kategorie:Infineon_XMC_Design_Contest_2014]]

[http://www.mikrocontroller.net/user/show/longri Kontakt]

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T14:05:20Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
<gallery>

</gallery>
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
[[Datei:Messkoppler.jpg|miniatur|SWR-Messkoppler]]
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

[[Kategorie:Infineon_XMC_Design_Contest_2014]]

[http://www.mikrocontroller.net/user/show/longri Kontakt]

Datei:Messkoppler.jpg

2014-07-20T14:04:04Z

Longri:

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-20T14:00:43Z

Longri:

''von Nico Schmidt DD6VFS''
{| class="wikitable"
|-
| <center>''Dieser Artikel nimmt am Artikelwettbewerb [http://www.mikrocontroller.net/topic/infineon-xmc-design-contest-2014 Infineon XMC Design Contest 2014] teil.''</center>
|}

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
<gallery>

</gallery>
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.
=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMSIS RTOS RTX ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 500ms warten
}
}
</syntaxhighlight>

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

<syntaxhighlight lang="c">
#include <DAVE3.h>

typedef struct // Struktur der Mailbox festlegen
{
char Message[16];
uint8_t Lenght;
} Mail_Queue_struct;

osMailQId Mail_Queue; // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
...
Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen

osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

}
</syntaxhighlight>

Die Mailboxen können dann mit ''osMailPut()'' gefüllt werden. Mit ''osMailGet()'' können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der [http://www.keil.com/pack/doc/cmsis_rtx/group___c_m_s_i_s___r_t_o_s___mail.html Dokumentation] und in meinem Quelltext.

=== Thread ''system_running()'' ===

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein ''Lock'' aufgetreten ist.

=== Thread ''uart_transmit()'' ===

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

=== Thread ''swr_messung()'' ===

Im Thread ''swr-messung()'' werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

<math>\text{SWR} = \frac{V+R}{V-R}</math>

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread ''control()'' gesendet.

=== Thread ''control()'' ===

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

== Fazit ==

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner [http://longrisoft.de/index.php/ucontroller-technik/steuergeraet-fuer-antennen Homepage] zu finden.
Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker [http://elektronikbasteln.pl7.de/ SM5ZBS] und mein Vater.

[[Kategorie:Infineon_XMC_Design_Contest_2014]]

[http://www.mikrocontroller.net/user/show/longri Kontakt]

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-19T14:34:11Z

Longri:

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-19T02:25:29Z

Longri:

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-19T02:24:50Z

Longri:

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-19T02:17:18Z

Longri:

Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

2014-07-19T02:09:51Z

Longri: Die Seite wurde neu angelegt: „''von Nico Schmidt DD6VFS'' Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört …“

''von Nico Schmidt DD6VFS''

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist das die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.
== Einleitung ==
Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben([http://de.wikipedia.org/wiki/Leistungsanpassung Leistungsanpassung]). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio SWR) ermittelt.
== Hardware ==
Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt.
=== SWR-Messkoppler ===
Der SWR-Messkoppler basiert auf einer Standartschaltung, zu finden bei Volker, [http://elektronikbasteln.pl7.de/umbau-eines-swr-meters.html SM5ZBS], und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.
=== Prozessorboard ===
Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente.
Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf.
Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.
=== Motoransteuerung ===
Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.
=== RS232 Schnittstelle ===
Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.
=== SPI-Schnittstelle ===
Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.
=== Netzteil ===
Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standartbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.
== Software ==
Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.
=== CMX-RTOS ===
Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird.
Einen neuen Thread anzulegen ist relativ einfach
<syntaxhighlight lang="c">
#include <DAVE3.h> // für DAVE3-Funktionen

void test(void const *arg); // Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0); // Definition von Thread "test"

int main(void)
{
DAVE_Init(); // Initialisation der DAVE Apps

osThreadCreate (osThread (test), NULL); // Anlegen von Thread "test"
osKernelInitialize(); // RTX-Kernel initialisieren
osKernelStart (); // RTX-Kernel starten

while(1); // Endlosschleife
}

void test(void const *arg) // Thread „test“
{
}
</syntaxhighlight>
Dieser Thread kann dann wie gewohnt mit unser ''while(1)''-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer ''wait''-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen ''wait''-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

<syntaxhighlight lang="c">
void test(void const *arg)
{
while(1) // Endlosschleife
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 1000ms warten
}
}
</syntaxhighlight>

Fortsetzung folgt ...

Infineon XMC 2Go

2014-05-16T06:27:13Z

Longri: /* Weblinks */

Das Infineon XMC 2GO ist ein Entwicklungsboard für den ARM Cortex M0-basierten Mikrocontroller [https://www.mikrocontroller.net/part/XMC1100 XMC1100] (64 kB Flash, 16 kB RAM). Auf dem Board ist ein weiterer Controller der über USB Programmierung & Debugging ermöglicht, und die serielle UART-Schnittstelle des XMC1100 als virtuellen COM Port bereitstellt.

Das XMC 2Go eignet sich besonders für Ein- und Umsteiger von 8-Bit-Controllern, da die Hardware sehr übersichtlich ist, Kommunikation mit dem PC auf einfache Weise über ein UART stattfinden kann, und es durch seine geringe Größe gut zum Einsatz auf einem [[Breadboard]] geeignet ist.

<gallery>
Datei:XMC 2Go mediu 002.jpg|Das Board im Detail
Datei:XMC 2Go hand.jpeg|Größenvergleich
Datei:XMC 2Go breadboard-1.jpeg|Anwendungsbeispiel mit [[Breadboard]]
Datei:XMC2GO.PNG|Komponenten und Abmessungen
Datei:XMC 2Go Schematic.svg|Schaltplan
</gallery>

Den einfachsten Einstieg bietet die Entwicklungsumgebung [http://www.infineon.com/cms/en/product/microcontrollers/development-tools,-software-and-kits/dave-tm-3-%2013-auto-code-generation-and-free-tools/channel.html?channel=db3a30433580b37101359f8ee6963814 DAVE]. DAVE basiert auf Eclipse CDT, und enthält neben dem GNU C Compiler (GCC) die für das Flashen und Debuggen des Mikrocontrollers nötigen Tools. Grundsätzlich lässt sich allerdings auch jede andere Entwicklungsumgebung (bzw. jeder Compiler verwenden), die Code für Cortex M0 erzeugen kann.

Von Keil gibt es kostenlos eine spezielle Version der Entwicklungsumgebung MDK für XMC1000-Controller, welche im Gegensatz zur normalen MDK Lite-Version bis zu 128 kB Code unterstützt [http://www2.keil.com/infineon/mdk/].

Die Fa. iSYSTEM stellt neben einem Debug-plugin für Dave mit winIDEAOpen eine kostenlose Entwicklungsumgebung für Cortex-M MCU's zur Verfügung[http://www.isystem.com/download/winideaopen]. Diese arbeitet unlimitiert mit dem GCC und für die Keil bzw. IAR Compiler bis zu 32K Code. Auf der winIDEAOpen Seite steht auch ein Beispielpaket für die XMC1000 und XMC4000 Familien zum Download bereit. Neben den Infineon EasyStart und RunningLEDs Beispielen beinhaltet dies auch bereits ein FreeRTOS Projekt. winIDEAOpen enthält einen Kernel plugin für FreeRTOS.

== Dokumentation ==
* [http://www.infineon.com/dgdl/xmc1100_ds_v1.2_2013_12.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a30433d1d0bbe013d256b60160b7f&ack=t XMC1100 Datenblatt]
* [http://www.infineon.com/dgdl/xmc1100_rm_v1+0_2013_03.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a30433cfb5caa013d1600856033eb&ack=t XMC1100 Reference Manual]
* [http://www.infineon.com/dgdl/Board_Users_Manual_XMC_2Go_Kit_with_XMC1100_R1.0.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a3043444ee5dc014453d6c75078c6&ack=t XMC 2Go Manual]

== Bezugsquellen ==
* [http://www.ehitex.de/application-kits/infineon/471/xmc-2go Hitex (5€)]
* [http://shop.myavr.de/Aktionen/XMC%202Go.htm?sp=article.sp.php&artID=200128 MyAVR (6€)]
* [http://www.digikey.de/product-search/de?x=0&y=0&lang=de&site=de&KeyWords=xmc2go Digikey (~8€)]

== Weblinks ==
* [http://mikrocontroller.bplaced.net/wordpress/?page_id=3834 Schritt-für-Schritt-Anleitung und Beispielprojekt für Keil µVision]
* [http://longrisoft.de/index.php/ucontroller-technik/xmc2go Eine weitere Seite zur Entwicklung mit dem XMC 2Go unter Keil µVison]

[[Category:ARM]]
[[Category:Infineon XMC]]

Infineon XMC 2Go

2014-05-13T17:18:18Z

Longri: /* Weblinks */

Das Infineon XMC 2GO ist ein Entwicklungsboard für den ARM Cortex M0-basierten Mikrocontroller [https://www.mikrocontroller.net/part/XMC1100 XMC1100] (64 kB Flash, 16 kB RAM). Auf dem Board ist ein weiterer Controller der über USB Programmierung & Debugging ermöglicht, und die serielle UART-Schnittstelle des XMC1100 als virtuellen COM Port bereitstellt.

Das XMC 2Go eignet sich besonders für Ein- und Umsteiger von 8-Bit-Controllern, da die Hardware sehr übersichtlich ist, Kommunikation mit dem PC auf einfache Weise über ein UART stattfinden kann, und es durch seine geringe Größe gut zum Einsatz auf einem [[Breadboard]] geeignet ist.

<gallery>
Datei:XMC 2Go mediu 002.jpg|Das Board im Detail
Datei:XMC 2Go hand.jpeg|Größenvergleich
Datei:XMC 2Go breadboard-1.jpeg|Anwendungsbeispiel mit [[Breadboard]]
Datei:XMC2GO.PNG|Komponenten und Abmessungen
Datei:XMC 2Go Schematic.svg|Schaltplan
</gallery>

Den einfachsten Einstieg bietet die Entwicklungsumgebung [http://www.infineon.com/cms/en/product/microcontrollers/development-tools,-software-and-kits/dave-tm-3-%2013-auto-code-generation-and-free-tools/channel.html?channel=db3a30433580b37101359f8ee6963814 DAVE]. DAVE basiert auf Eclipse CDT, und enthält neben dem GNU C Compiler (GCC) die für das Flashen und Debuggen des Mikrocontrollers nötigen Tools. Grundsätzlich lässt sich allerdings auch jede andere Entwicklungsumgebung (bzw. jeder Compiler verwenden), die Code für Cortex M0 erzeugen kann.

Von Keil gibt es kostenlos eine spezielle Version der Entwicklungsumgebung MDK für XMC1000-Controller, welche im Gegensatz zur normalen MDK Lite-Version bis zu 128 kB Code unterstützt [http://www2.keil.com/infineon/mdk/].

Die Fa. iSYSTEM stellt neben einem Debug-plugin für Dave mit winIDEAOpen eine kostenlose Entwicklungsumgebung für Cortex-M MCU's zur Verfügung[http://www.isystem.com/download/winideaopen]. Diese arbeitet unlimitiert mit dem GCC und für die Keil bzw. IAR Compiler bis zu 32K Code. Auf der winIDEAOpen Seite steht auch ein Beispielpaket für die XMC1000 und XMC4000 Familien zum Download bereit. Neben den Infineon EasyStart und RunningLEDs Beispielen beinhaltet dies auch bereits ein FreeRTOS Projekt. winIDEAOpen enthält einen Kernel plugin für FreeRTOS.

== Dokumentation ==
* [http://www.infineon.com/dgdl/xmc1100_ds_v1.2_2013_12.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a30433d1d0bbe013d256b60160b7f&ack=t XMC1100 Datenblatt]
* [http://www.infineon.com/dgdl/xmc1100_rm_v1+0_2013_03.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a30433cfb5caa013d1600856033eb&ack=t XMC1100 Reference Manual]
* [http://www.infineon.com/dgdl/Board_Users_Manual_XMC_2Go_Kit_with_XMC1100_R1.0.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a3043444ee5dc014453d6c75078c6&ack=t XMC 2Go Manual]

== Bezugsquellen ==
* [http://www.ehitex.de/application-kits/infineon/471/xmc-2go Hitex (5€)]
* [http://shop.myavr.de/Aktionen/XMC%202Go.htm?sp=article.sp.php&artID=200128 MyAVR (6€)]
* [http://www.digikey.de/product-search/de?x=0&y=0&lang=de&site=de&KeyWords=xmc2go Digikey (~8€)]

== Weblinks ==
* [http://mikrocontroller.bplaced.net/wordpress/?page_id=3834 Schritt-für-Schritt-Anleitung und Beispielprojekt für Keil µVision]
* [http://longrisoft.de/index.php/elektronik/ucontroller-technik/xmc2go Eine weitere Seite zur Entwicklung mit dem XMC 2Go unter Keil µVison]

[[Category:ARM]]
[[Category:Infineon XMC]]

Infineon XMC 2Go

2014-05-13T17:16:49Z

Longri: /* Weblinks */

Das Infineon XMC 2GO ist ein Entwicklungsboard für den ARM Cortex M0-basierten Mikrocontroller [https://www.mikrocontroller.net/part/XMC1100 XMC1100] (64 kB Flash, 16 kB RAM). Auf dem Board ist ein weiterer Controller der über USB Programmierung & Debugging ermöglicht, und die serielle UART-Schnittstelle des XMC1100 als virtuellen COM Port bereitstellt.

Das XMC 2Go eignet sich besonders für Ein- und Umsteiger von 8-Bit-Controllern, da die Hardware sehr übersichtlich ist, Kommunikation mit dem PC auf einfache Weise über ein UART stattfinden kann, und es durch seine geringe Größe gut zum Einsatz auf einem [[Breadboard]] geeignet ist.

<gallery>
Datei:XMC 2Go mediu 002.jpg|Das Board im Detail
Datei:XMC 2Go hand.jpeg|Größenvergleich
Datei:XMC 2Go breadboard-1.jpeg|Anwendungsbeispiel mit [[Breadboard]]
Datei:XMC2GO.PNG|Komponenten und Abmessungen
Datei:XMC 2Go Schematic.svg|Schaltplan
</gallery>

Den einfachsten Einstieg bietet die Entwicklungsumgebung [http://www.infineon.com/cms/en/product/microcontrollers/development-tools,-software-and-kits/dave-tm-3-%2013-auto-code-generation-and-free-tools/channel.html?channel=db3a30433580b37101359f8ee6963814 DAVE]. DAVE basiert auf Eclipse CDT, und enthält neben dem GNU C Compiler (GCC) die für das Flashen und Debuggen des Mikrocontrollers nötigen Tools. Grundsätzlich lässt sich allerdings auch jede andere Entwicklungsumgebung (bzw. jeder Compiler verwenden), die Code für Cortex M0 erzeugen kann.

Von Keil gibt es kostenlos eine spezielle Version der Entwicklungsumgebung MDK für XMC1000-Controller, welche im Gegensatz zur normalen MDK Lite-Version bis zu 128 kB Code unterstützt [http://www2.keil.com/infineon/mdk/].

Die Fa. iSYSTEM stellt neben einem Debug-plugin für Dave mit winIDEAOpen eine kostenlose Entwicklungsumgebung für Cortex-M MCU's zur Verfügung[http://www.isystem.com/download/winideaopen]. Diese arbeitet unlimitiert mit dem GCC und für die Keil bzw. IAR Compiler bis zu 32K Code. Auf der winIDEAOpen Seite steht auch ein Beispielpaket für die XMC1000 und XMC4000 Familien zum Download bereit. Neben den Infineon EasyStart und RunningLEDs Beispielen beinhaltet dies auch bereits ein FreeRTOS Projekt. winIDEAOpen enthält einen Kernel plugin für FreeRTOS.

== Dokumentation ==
* [http://www.infineon.com/dgdl/xmc1100_ds_v1.2_2013_12.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a30433d1d0bbe013d256b60160b7f&ack=t XMC1100 Datenblatt]
* [http://www.infineon.com/dgdl/xmc1100_rm_v1+0_2013_03.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a30433cfb5caa013d1600856033eb&ack=t XMC1100 Reference Manual]
* [http://www.infineon.com/dgdl/Board_Users_Manual_XMC_2Go_Kit_with_XMC1100_R1.0.pdf?folderId=db3a30433580b3710135a47f3eb76c98&fileId=db3a3043444ee5dc014453d6c75078c6&ack=t XMC 2Go Manual]

== Bezugsquellen ==
* [http://www.ehitex.de/application-kits/infineon/471/xmc-2go Hitex (5€)]
* [http://shop.myavr.de/Aktionen/XMC%202Go.htm?sp=article.sp.php&artID=200128 MyAVR (6€)]
* [http://www.digikey.de/product-search/de?x=0&y=0&lang=de&site=de&KeyWords=xmc2go Digikey (~8€)]

== Weblinks ==
* [http://mikrocontroller.bplaced.net/wordpress/?page_id=3834 Schritt-für-Schritt-Anleitung und Beispielprojekt für Keil µVision]
* [http://longrisoft.de/index.php/elektronik/ucontroller-technik/xmc2go Eine weitere Seite zur Entwicklung mit dem XMC 2Go unter Keil µVison]
[[Category:ARM]]
[[Category:Infineon XMC]]

Eagle-Wishlist

2014-02-26T20:57:03Z

Longri: Wünsche zugefügt

Auf dieser Seite können Wünsche zur Erweiterung der Funktionen des Leiterplatten CAD Programms Cadsoft EAGLE eingetragen werden. Es ist keine offizelle Wunschliste von Cadsoft und es ist nicht bekannt, ob Cadsoft-Mitarbeiter diese Seite regelmässig sichten. Cadsoft sollte sicherheitshalber regelmäßig angeschrieben werden, damit diese Liste nicht in Vergessenheit gerät.

Damit sich die beliebtesten Wünsche herauskristallisieren, macht jeder einfach einen virtuellen Strich dahinter: | (Windows: ALT-GR Taste und < Taste drücken, Mac OS X: Alt-Taste und 7 Taste drücken). Alle fünf Striche (|||||) bitte immer ein Leerzeichen einfügen.

Neue Wünsche einfügen darf und soll natürlich auch jeder. Einfach ganz viele Striche auf einmal hinter einem Wunsch einzufügen ist zwecklos. Das erkennt man in der History, und es gibt viele Leute, die diese Seite überwachen...

Ja, die Einleitung ist von der Reichelt-Wishlist geklaut. Existenzberechtigung für diese Seite: Farnell will Eagle verbessern. Siehe [http://de.farnell.com/jsp/bespoke/bespoke2.jsp?ICID=i-7706-00001001&bespokepage=farnell/de/design-link/cadsoft.jsp]

== Programmfunktionen ==

=== Control Panel ===

* In Bibliothek: Bei Klick auf ein Device soll das Fenster an der aktuellen Position stehenbleiben ||
* In Bibliothek: Bildposition vom Symbol und Package soll fixed sein (mitscrollen), bei großen Device-Kollektionen vorteilhaft ||
* Backupdateien in Unterverzeichnisse packen ||||| ||||
* Raster-/Grid-Größe für X und Y Achse getrennt angeben |
* Möglichkeit einbauen um alle Bibliotheken INKL. Unterverzeichnisse zuladen.

=== Schaltplan-Editor ===
* Bibliotheken aus dem Download Bereich in die Releases mit aufnehmen ||||| || | 8
* Richtungsabhängige Labels: (3erlei) verschiedene Labels mit denen zusätzlich zum Netznamen die Signalrichtung (Eingang, Ausgang, Bidirektional) visualisiert werden kann ||||| ||||| || 12
* Farbige XREFs → Das Netz dazu in der gleichen Farbe ||||| 5
* Eigenen 'Lagerbestand' mitverwalten, sodass beim Zeichnen von Plänen direkt nur Lagerteile verbaut werden (nützlich bei diesen ganzen SMD-Varianten) ||||| |||| 9
* "hierarchisches Design" von identisch aufgebauten Unterbaugruppen, sprich Subcomponenten mit definierten Input/Output-Signalen aus z.B. einer speziellen hierarchy.lib. Diese kann dann ja im gleichen Verzeichnis wieder als Schematic abgelegt werden. Mit dazugehöriger Board-Datei läßt sich dann auch das Layout clonen. ||||| ||||| ||||| |||| 19
* Drucken: neue Option "Automatisch drehen", um bei mehrseitigen Plänen mit wechselnder Seitenorientierung automatisch auszurichten ||||| 5
* Tastatur-/Maus-Bedienkonzept: z.B. Move, Copy etc. alle auf Tasten der linken Tastaturhälfte (bzw. auf der rechten für Linkshänder) und zwar ohne Ctrl/Shift etc. so daß man zügig arbeiten kann, ohne ständig mit der Maus umschalten zu müssen. ||||| |||| 9
* Der relative, beliebig setzbare Ursprung sollte vom absoluten zu unterscheiden sein (andere Farbe...) ||| 3
* Bauteilwerte direkt im ADD-Befehl festlegbar machen (-> Standardbauteile im Textmenü) |||| 4
* Der "Gruppenauswahlrahmen" sollte sich bei gedrückter Maustaste immer aufziehen lassen, nicht erst nach Druck auf Group. (Im Board auch) ||||| || 7
* Ein markiertes Bauteil/e sollte sich einfach mit Druck auf ENTF löschen lassen. ||||| 5
* Beim Herstellen elektrischer Verbindungen(net), an den der Maus am nächsten liegenden Pin kontaktieren (Fangen). Beim verwenden von Bibliotheken die in anderem Raster erstellt wurden, ist es teilweise nicht möglich eine Schaltung zu zeichen, weil man die Pins nicht trifft.

=== Board-Editor ===
* MOVE mit einstellbaren Freiheitsgraden. Beispielsweise, um parallel (nur horizontal/vertikal) oder diagonal zu verschieben | 1
* Mathematik-Funktionen in Eingabefeldern (+ plus, - minus, * mal, / geteilt und () Klammern) z.B.: 375mil+(13,6mm/2) || 2
* Kacheln-Funktion im Drucken Dialog ||||| ||||| | 11
* Netznamen in verlegten Leiterbahnen einblenden<ref>Wird z. B. im AltiumDesigner so gemacht. Abstand und Größe der Beschriftung erfolgt je nach Zoom-Stufe.</ref> ||||| ||||| 10
* Die Auswahl von Bauteilen sperren, die mit dem aktuellen Werkzeug nicht bearbeitet können<ref>Wenn zB eine Leiterbahn durch einen Bauteilmittelpunkt läuft und man mit Ripup auf den Mittelpunkt klickt, will man natürlich die Leiterbahn auflösen. Ripup lässt sich ja nicht auf Bauteile anwenden. Warum muss man also mit linker Maustaste wählen, auf was man Ripup anwenden will?</ref> ||||| || 7
* Routing mit Walkaround/Push/Hug&Push Funktionen (Hindernisse automatisch umrouten beim FollowMe) ||||| || 7
* Parameter eines Objektes (Via, Track,..) per Doppelklick-Option bearbeitbar ||||| ||||| ||||| 15
* Thermal Vias für unterschiedliche Gehäuse einzeln anpassbar machen ||||| 5
* Padstack frei definierbar || 2
* Direkte Implementierung von EAGLE 3D ||||| ||||| ||||| ||||| ||||| ||||| 29
* Messung der Leiterbahnlänge <ref>Die Messung der Länge einer Leiterbahn sollte zwischen zwei beliebigen Segmenten möglich sein. Man könnte dafür Start- und Endsegment markieren.</ref> ||||| ||||| ||||| ||||| ||||| ||||| 30
* Weitere Standardgeometrien (Spiralen, Heaxagon u.ä.) ||||| ||||| || 12
* Andere Farben für Versorgungsspannungen definierbar machen ||||| ||||| |||| |||| 19
* Impedanzkontrolle von Leiterbahnen ||||| ||||| ||||| ||||| || 22
* Board im Editor drehen (90°-Schritte) und Umdrehen (Oberseite/Unterseite) ||||| ||||| ||||| ||| 18
* Kopieren von Leiterbahnen/Gruppen ||||| ||||| | 11
* Online (Echtzeit) DRC ||||| ||||| ||||| | 16
* Direkte Integration von Teardrops bzw SnowMans ||||| || 7
* Chamfered edge (Anfasungen bei T-Leiterbahnverbindungen) | 1
* selektives Ratsnest (nicht mit dem Bauteil verbundene Luftlinien beim Plazieren ausblenden) ||||| || 7
* dynamisches Ratsnest (Luftlinien des Bauteils beim Plazieren zum nächstgelegenen Pin verbinden) ||||| ||||| ||||| | 16
* Benannte Gruppen in Editor und Schaltplan z. B. analog1 oder power zum einfachen plazieren || 2
* Dxf Drag and Drop Mechanische Teile direkt in eagle boards und libs ziehen | 1
* Parametrische Library-Erstellung über Textfile | 1
* Iges / Step Export. 3D Darstellung für Mcad exportieren |||| 4
* 3DScanner Import. Da eine fertige Leiterplatte die Lageinformationen aller Bauteile hat, wird über einen 3D-Scanner die Höheninformationen der Bauteile eingelesen und in die Bibliothek übertragen. || 2
* Direkte, einfache Nutzung von Layout- und Schaltplanmodulen | 1
* Im Layouteditor Bauteile konsistent platzieren sowie kopieren können || 2
* DRC: Bestückungsdruck auf PADs, SMDs oder VIAs ||| 3
* DRC: Warnung / Meldung über nicht geroutete Netze / bestehende Luftlinien ||||| ||||| ||||| ||||| || 22
* Layer werden sofort aktiviert/deaktiviert ohne erst "Übernehmen" anklicken zu müssen ||||| ||||| 10
* Wert von "Alle Packages anzeigen" im change technology-Dialog merken | 1
* Busse werden automatisch umbenannt falls Nets umbenannt werden |||| 4
* Unrouted Layer nur für aktivertes Bauteil (oder Bereich) anzeigen lassen | 1
* Schrift-Ausrichtung: alle vier Richtungen zulassen, anstatt nur nach rechts oder oben. Dafür Ausrichtungen links/zentriert/rechts zulassen || 2
* unsplit-Funktion: einen Knick aus einem Wire löschen (z.B. als Shift-optimize) ||||| ||||| 10
* Busse (oder mehrere parallele Leitungen gleichzeitig) verlegen (wo es Sinn macht) ||||| | 6
* "clonen" von Leiterbahnen-Routings von einer Baugruppe zu einer anderen ||||| 5
* Ausblenden von Bauelementen im Layouteditor. Beispielsweise nach einer bestimmten Buchse Stecker Kombination im Schaltplan. Wäre hilfreich um Bauelemente im Gehäuse darzustelle | 1
* "Lochrastermodus" um noch einfacher Pläne für Lochrasterplatinen zu erstellen ||||| 5
* Symmetrierfunktion, um Bauteile automatisch symmetrisch um eine Achse oder Punkt anordnen zu können || 2
* automatische Platzierung von Bauteilen im Board ||||| ||| 8
* Der relative, beliebig setzbare Ursprung sollte vom absoluten zu unterscheiden sein (ander Farbe...) ||| 3
* Offset Routing - Gleichzeitiges verlegen von paralell verlaufenden Leiterbahnen || 2
* Polygone gegen Verschieben schützen können (lock) || 2
* In Bauteilinfo die zugehörige Schaltplanseitennummer anzeigen || 2
* In Bauteilinfo die auch das DEVICE anzeigen (wie im Schaltplan) | 1
* Beim DRC einen Hinweis geben, wenn der Fehler durch Netzklassenregeln bedingt ist || 2
* Über Rechtsklickmenü eine ausgewählte Gruppe ins Raster setzen || 2
* die Airwires zeigen auf das Zentrum eines SMD Pads, das meist nicht auf dem raster liegt. Besser währe, wenn ein Bereich innerhalb des Pads als zulässiges Airwire-Ziel akzeptiert wird. Oft sind kleine Leiterbahnschnippsel übrig, mit denen man kämpfen muss. Pad ist eigentlich kontaktiert, aber man hat das zentrum wieder nicht getroffen. || 2
* invertierter Text einfach über Textbefehl einfügen zu können | 1

=== Autorouter ===

* Ausführungen des Autorouters zurücksetzen (z. B. mit Ctrl + Z) ||||| ||||| ||||| ||||| ||||| |||| 29
* Autorouter um Autoplacer von nicht gelockten Bauteilen ergänzen ||||| | 6

=== Bibiliotheks-Editor ===

* Alle Packages zentral speichern, zB in ref-packages. Andere Libs laden dann von da das Package und verbinden das mit ihren Symbols ||||| ||||| ||||| |||| |20
* Verschiedene Symbole für ein Bauteil (Auswählbar im Schaltplaneditor) ||||| |6
* Möglichkeit Symbole einzeln zu kopieren und nicht nur als Device inkl. allen Varianten/ Packages ||||| 5
* Pin-Namen und Nummern per Smash-Befehl verschiebbar und drehbar ||| 3
* Pin-Namen und Nummern auch in Schriftgröße einstellbar || 2
* Bibliotheken ausblenden oder Favoritenliste | 1
* Pin-Namen im Symbol mit auswählbaren Alternativen versehen (bei MCUs teilweise 8fach belegt) ||| 3
* Bauteile im Device als optional kennzeichnen, damit z.B. für MCUs unterschiedliche Packages als Varianten ausgewählt werden können | 1

== Preispolitik/Sonstiges ==
* Funktionsumfang der Non-Profit Version auf Schaltplan+Board mit 2 Layern reduzieren (Autorouter und 2 Innenlagen fallen weg), dafür max. Leiterplattengröße auf Doppel-Euro erhöhen. Besser noch 320cm2 in beliebigem Format. ||||| ||||| ||||| ||||| ||||| ||||| ||| 32
* Kostenlose Studentenversion ||||| ||||| ||||| ||||| ||||| | 26
* max. Leiterplattengröße der Light-Version auf 160x100mm erhöhen. Dafür den Autorouter weglassen. ||||| ||||| ||||| ||||| ||||| ||||| | 30
* Light Version auf 2 Signal + 2 Power Lagen anheben. 2 Lagen ist nicht mehr Zeitgemäß ||||| ||||| | 11
* Generell eine ordentlicher strukturierte Bibliothek. Beispielsweise Widerstandsgehäuse in unterschiedlichen Rastern ("lange Beinchen"), einheitliches Bezeichnungsschema usw. ||||| ||||| | 11
* Bibliotheken mit Sammlungen der Bestände verschiedener Lieferanten (Reichelt, Segor, Farnell) ||||| ||||| | 11

== Erledigte Punkte ==
* Mehrzeilige Texte (Mehrzeilige Texte sind ab Version 6.3 möglich) |||| 4
* Neben Ckeckbox "Smds" neue Checkbox "bedrahtet", sodass diese ausgeschaltet werden können, wenn nur mit SMDs gearbeitet wird (wurde nun in die Suchfunktion übernommen) ||||| |||| 9
* Meanderstrukturen für Leiterbahnlängenausgleich ||||| ||| 8
* Standardbauteile oder Makros in "Schnellzugriff" (Symbolleiste) für den Schnellzugriff (Mit dem ''MENU''-Befehl lässt sich eine Symbolleiste erzeugen, deren Knöpfe wiederum mit beliebigen Befehlen belegt werden können, einschließlich ''ADD'' --[[Benutzer:Haku|Haku]] 08:47, 21. Feb. 2010 (UTC)) oder ''RUN''/''SCRIPT'' für Makros. |||
* 2-3 frei definierbare Layerauswahlen, die sofort per Klick bzw. Shortcut übernommen und angezeigt werden (Es gibt die ALIAS-Option für den DISPLAY-Befehl. Shortcut dann wieder mit MENU oder direkt in den Einstellungen eine Tastenkombination festlegen) || 2
* Auswahlmenü beim Kopieren von Bauteilen, damit nur einzelne Packages (z. B. nur SO16) kopiert werden können und nicht zusätzlich alle anderen Varianten (z. B. DIL16, TSSOP16, usw.) (spätestens ab 6.5.0) |||| 4
* Zusätzliches Flag für Bauteile (Bestückt / Unbestückt), damit Bestückungsvarianten erstellt werden können (Bestückungsvarianten, spätestens ab 6.5.0 verfügbar) ||||| 5
* Einem Pin im Symbol können mehrere Pins eines Packages zugewiesen werden ||||| ||| 8 - gibt es ab 6.xx
* Polygone (mit Pad-Namen) zulassen für PAD-Sonderformen ||||| ||| 8 - gibt es indirekt ab 6.x
* Aktualisierung der Programmdateien statt jedes mal im neuen Ordner zu installieren <ref>''Nichts'' anderes passiert bei Installation im ''gleichen'' Ordner. Lesen lernen... → Diskussion --[[Benutzer:Hownottobeseen|Hownottobeseen]]</ref> ||||| | 6
* Abstandsmessung (Wie in Sprint-Layout: Mit Maustaste auf Startpunk klicken, gedrückt halten und zum Endpunkt ziehen. Länge und Winkel der Strecke werden in Echtzeit angezeigt.) (Dazu benutzt man en MARK-Befehl, um den Startpunkt zu setzen. Dann werden Winkel, Abstand und x/y-Offset in Echtzeit angezeigt) ||||| ||||| ||||| ||||| ||| 23
* Suche im Bauteilkatalog nach Lieferanten-Artikelnummer (sofern gepflegt) (spätestens ab 6.5.0 kann man nach Attributen und Attributwerten suchen) ||| 3
* Routen von LVDS-Leitungspaaren (Mäander) ||||| ||||| 10
* Möglichkeit, für unterschiedliche Programmversionen auch unterschiedliche Projektverzeichnisse zu verwenden. (Ab Version 5.11 gibt es die Kommandozeilen-Option -U) |

== Anmerkungen ==
Diskussion im Forum: http://www.mikrocontroller.net/topic/169171

<references/>

[[Kategorie:Eagle]]