Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung: Unterschied zwischen den Versionen

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche
KKeine Bearbeitungszusammenfassung
KKeine Bearbeitungszusammenfassung
Zeile 59: Zeile 59:
{
{
IO004_TogglePin(IO004_Handle0); // Pin umschalten
IO004_TogglePin(IO004_Handle0); // Pin umschalten
osDelay(500); // 1000ms warten
osDelay(500); // 500ms warten
}
}
}
}
Zeile 65: Zeile 65:


Fortsetzung folgt ...
Fortsetzung folgt ...
[[Kategorie:Infineon_XMC_Design_Contest_2014]]
[[Kategorie:Infineon_XMC_Design_Contest_2014]]
[http://www.mikrocontroller.net/user/show/longri Kontakt]

Version vom 19. Juli 2014, 02:24 Uhr

von Nico Schmidt DD6VFS

Dieser Artikel nimmt am Artikelwettbewerb Infineon XMC Design Contest 2014 teil.

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(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, 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

#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“
{
}

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.

void test(void const *arg)
{
	while(1)					// Endlosschleife	
	{	
		IO004_TogglePin(IO004_Handle0); 	// Pin umschalten
		osDelay(500);				// 500ms warten
	}
}

Fortsetzung folgt ... Kontakt