Mikrocontroller.net - Benutzerbeiträge [de]

Mikrocontroller.net:Lizenzbestimmungen

2004-06-19T00:10:48Z

80.140.66.5:

Alle Texte sind unter der [http://www.gnu.org/copyleft/fdl.html GNU Free Documentation License] verfügbar.

Hilfe:Bearbeitungshilfe

2004-06-19T00:08:23Z

80.140.66.5:

== Formatierung ==
Eine ausführliche Beschreibung der Gliederungs- und Formatierungsmöglichkeiten findet sich im Wikipedia Online-Lexikon: http://de.wikipedia.org/wiki/Wikipedia:Seite_bearbeiten

== Richtlinien ==

=== Verwandte Seiten ===

Für '''interne''' Links zu verwandten Artikeln legt man einen Bereich nach dem folgenden Muster an:

<pre>
== Siehe auch ==
* [[Test]]
* [[Foobar]]
</pre>

Ähnlich bei '''externen''' Links:

<pre>
== Weblinks ==
* http://url1/
* http://url2/
* [http://url3/ Seite 3 hat einen Linktext]
</pre>

C++

2004-06-19T00:03:54Z

80.140.66.5:

Umfassende Erweiterung der Programmiersprache [[C]]; kompatibel in der Hinsicht, dass C als Teilmenge in C++ enthalten ist. Dadurch ist C++ ebenso wie C zur hardwarenahen Programmierung geeignet.

(Ein detaillierter Vergleich von C und C++ unter besonderer Berücksichtigung der für die Programmierung von Mikrocontrollern relevanten Aspekte findet sich unter [[C vs C-Plusplus]].)

== Weblinks ==
* [http://de.wikipedia.org/wiki/C_Plusplus "C++" bei Wikipedia]

DsPIC

2004-06-19T00:02:59Z

80.140.66.5:

* Hersteller: Microchip
* 24 Bit Programm- / 16 Bit Daten-[[Bus]]
* hat nichts mit dem klassischen 8 Bit-[[PIC]] zu tun
* [[DSP]]-Funktionen mit 2 getrennten 40 Bit [[Akkumulator|Akkumulatoren]]
* [[Harvard-Architektur]] (getrennter Befehls- und Datenspeicher)
* [[RISC]], 84 Basis-Befehle (Hardware-Multiplikation)
* bis 144 kB [[Flash-ROM]] als Programmspeicher
* bis 8 kB internes [[RAM]]
* bis 4 kB internes [[EEPROM]]
* Versionen mit internem 12 Bit [[AD-Wandler]], [[I2S]], [[AC97]] und [[CAN]]

LTC1257

2004-06-19T00:01:18Z

80.140.66.5:

Der LTC1257 ist ein 12 Bit [[DA-Wandler]] mit serieller Ansteuerung.

== Weblinks ==
* [http://www.mikrocontroller.net/forum/read-4-66518.html C-Routinen zur Ansteuerung]

WinAVR

2004-06-18T23:59:37Z

80.140.66.5:

WinAVR ist die Windows-Distribution des [[C]]-[[Compiler]]s [[AVR-GCC]] für [[AVR]]-[[Mikrocontroller]]. WinAVR enthält neben dem Compiler noch einige andere Pakete, z.B. die C-Standardbibliothek avr-libc (inkl. Dokumentation) und die Programmiersoftware AVRDUDE.

Aktuelle Version: 20040404

http://winavr.sourceforge.net/

== Siehe auch ==
* [[WinAVR: Code-Größe anzeigen]]

Editoren/IDEs

2004-06-18T23:56:34Z

80.140.66.5:

== Texteditoren für Programmierer ==

=== Windows ===

* [http://www.ultraedit.com UltraEdit (Shareware)]
* [http://www.pnotepad.org/ Programmers Notepad (Freeware, in WinAVR enthalten)]
* [http://www.atmel.com AVR-Studio (für AVR-Assembler/C)]
* [http://ftp.gnu.org/gnu/emacs/windows/ Emacs]
* [http://www.vim.org Vim]

=== Unix/Linux ===

* [http://ftp.gnu.org/gnu/emacs/ Emacs]
* [http://www.vim.org Vim]

=== Mac OS X ===

* [http://www.codingmonkeys.de/subethaedit/ SubEthaEdit] (frei für nichtkommerzielle Nutzung, erlaubt das gemeinsame Bearbeiten einer Datei von mehreren Personen gleichzeitig)

Editoren/IDEs

2004-06-18T23:55:26Z

80.140.66.5:

AVR-Studio

2004-06-18T23:49:47Z

80.140.66.5:

Das '''AVR-Studio''' ist eine kostenlose Entwicklungsumgebung ([[IDE]]) für die [[AVR]]-[[Mikrocontroller]] von Atmel. Sie besteht aus einer Projektverwaltung, einem [[Texteditor|Editor]] und einem [[Debugger]], der mit dem integrierten [[Simulator]], einem [[JTAG]]-Adapter oder einem [[In Circuit Emulator]] genutzt werden kann.

* [[AVR-Studio Bugs]]

AVR-Studio

2004-06-18T23:46:19Z

80.140.66.5:

Das '''AVR-Studio''' ist eine kostenlose Entwicklungsumgebung ([[IDE]]) für die [[AVR]]-[[Mikrocontroller]] von Atmel. Sie besteht aus einer Projektverwaltung, einem [[Editor]] und einem [[Debugger]], der mit dem integrierten [[Simulator]], einem [[JTAG]]-Adapter oder einem [[In Circuit Emulator]] genutzt werden kann.

* [[AVR-Studio Bugs]]

LCD

2004-06-18T23:42:01Z

80.140.66.5:

"Liquid Crystal Display". Große Fläche von Flüssigkristallen, die unter Einwirkung eines elektrischen Feldes die Polarisationsebene des Lichts drehen. Wird ein solches Display von bereits polarisiertem Licht durchleuchtet, dann erscheinen diese Kristalle mehr oder weniger hell oder dunkel.
Die Angelegte Spannung ist sehr gering, es muss sich aber um eine Wechselspannung handeln, da eine Gleichspannung die Kristalle zersetzt. Zur Ansteuerung gibt es spezielle LCD Controller, fertige Module mit Controller und einige Prozessoren mit integrierter Ansteuerung (z.B. aus der [[MSP430]]-Serie).

LCD-Module mit eingebautem Controller lassen sich meist einfach mit einem [[Mikrocontroller]] ansteuern. Bei LCDs ohne eigenen Controller (Laptop-LCDs z.B.) ist die direkte Ansteuerung sehr schwierig (weil zeitkritisch), allerdings läßt sich in manchen Fällen ein Standard-Controller nachrüsten.

Text-LCDs verwenden meistens den [[HD44780]] oder einen kompatiblen Controller, Grafik-LCDs z.B. den [[T6963]] oder den [[SED1330]].

Eine bei Handybastlern bekannte Spielerei ist das abziehen der Polarisationsfolie vom LCD und dem um 90° gedrehten aufkleben der alten oder einer neuen Folie. Dies führt zu einem hardwaremäßigen Invertieren der LCD Anzeige.

ISP

2004-06-18T23:39:30Z

80.140.66.5:

'''I'''n '''S'''ystem '''P'''rogramming. Ein "In System" programmierbarer [[Mikrocontroller]] kann programmiert werden, ohne dass er dazu aus der Umgebungsschaltung entfernt werden muss. Die Vorraussetzung dafür ist ein als [[Flash-ROM]] ausgeführter [[Programmspeicher]]. Die Kommunikation mit dem ISP-Adapter erfolgt in der Regel über ein serielles Protokoll.

ISP

2004-06-18T23:38:42Z

80.140.66.5:

I²C

2004-06-18T23:38:02Z

80.140.66.5:

'''I2C''' ist ein synchroner serieller Zweidraht-[[Bus]] (eine Daten- und eine Taktleitung), der für die Kommunikation zwischen [[IC]]s über kleine Distanzen geeignet ist. Entwickelt wurde er vor ca. 20 Jahren von Philips.
Gesprochen "I quadrat C" steht für IIC = Inter [[IC]] Bus. Aus Lizenzgünden heißt der I²C Bus bei manchen Herstellern auch [[TWI]].

In einem I2C-Bus gibt es mindestens einen Master und eine beliebige Anzahl Slaves (max. 128). Ein I2C-Bus mit mehreren Mastern wird als "Multi-Master-Bus" bezeichnet.
Der (oder die) Master sprechen die Slaves an; ein Slave kann NIE selbstständig Daten senden. Dazu übernimmt der Master, der Daten senden oder empfangen möchte, den Bus und gibt die (7-bit-)Adresse des Slaves aus, mit dem er kommunizieren möchte. Nach der Adresse teilt der Master dem entsprechenden Slave mit, ob er Daten senden oder empfangen möchte. Danach werden die eigentlichen Daten (entweder vom Master oder Slave) auf den Bus gelegt. Hat der Master den Lese- oder Schreibvorgang abgeschlossen, so gibt er den Bus wieder frei.
Sofern mehrere Master vorhanden sind, stellt ein Protokoll sicher, dass sich diese nicht gegenseitig stören.

[http://www.semiconductors.philips.com/buses/i2c/ Philips Produktseite]

Include-Files (C)

2004-06-18T23:35:51Z

80.140.66.5: /* Verwendung von Include-Files */

Include-Files in C/C++ enthalten typischerweise Informationen, die im Rahmen der Kompilierung verschiedener anderer Quelltexte (mehrfach) benötigt werden.

Wer bisher hauptsächlich kleinere (Assembler-) Programme für Mikrocontroller realisiert hat und sich nun langsam an größere Projekte heranwagt und deshalb auf C umsteigt, ist gut beraten, die Möglichkeiten sinnvoll einzusetzen, die Include-Files in C bieten. Dabei gilt es allerdings auch, einige Fallgruben zu vermeiden - mehr dazu in diesem Artikel.

== Verwendung von Include-Files ==

Die Verwendung von Include-Files in [[C]] und [[C-Plusplus|C++]] führt in der Regel zu besser strukturierten und damit besser wartbaren Programmen. Indem bestimmte, zentrale Informationen nur ein einziges Mal hinterlegt werden, fällt insbesondere bei Änderungen weniger Aufwand an.

Der übliche Suffix für Include-Files ist "<tt>.h</tt>", manchmal auch "<tt>.hpp</tt>" (für C++), und die ''Verwendung'' eines Include-Files ist sehr einfach:
#include "xyz.h"

Wird der Dateiname in eckige Klammern gesetzt, dann sucht der Präprozessor die Datei nicht im aktuellen Verzeichnis, sondern im Standard-Include-Pfad des Compilers:
#include <io.h>

Dabei sind auch relative Verzeichnisangaben erlaubt:
#include <avr/timer.h>

== Probleme bei Include-Files ==
In Include-Files werden mitunter Informationen aus anderen Include-Files benötigt und es ist an der Verwendungsstelle eines Include-Files oft nicht das Wissen über die möglicherweise sehr komplexen Abhängigkeiten vorhanden. Nachfolgend wird ausgehend von einer typischen Problemstellung eine Standardtechnik erläutert, die hilft, das Wissen um Abhängigkeiten an der Verwendungsstelle überflüssig zu machen:

Angenommen, es existieren zwei Datenstrukturen für die es die Typdefinitionen <tt>s1_t</tt> und <tt>s2_t</tt> gibt, die jeweils entsprechenden Include-Files hinterlegt sind, also
<tt>s1.h</tt>:
<pre>
/* Definition der Datenstruktur s1 */
struct s1 {
...
};
typedef struct s1 s1_t;
...
/* Funktions-Deklarationen */
void foo(s1_t);
...
</pre>

Die Datei <tt>s2.h</tt> sieht so aus:
<pre>
/* Definition der Datenstruktur s2 */
struct s2 {
...
};
typedef struct s2 s2_t;
...
/* Funktions-Deklarationen */
s2_t *bar();
...
</pre>

Eine bestimmte Applikation benötigt nun beide Struktur- und Funktions-Definitionen und inkludiert entsprechend beide Dateien, es gibt also eine kompilierbare Datei (z.B. <tt>main.c</tt>) die wie folgt aussieht:
<pre>
#include "s1.h"
#include "s2.h"
...
int main() {
s1_t a;
s2_t *b;
...
foo(a);
b = bar();
...
}
</pre>
So weit, so gut.

Nun kommt es eines Tages zu einer Änderung, die darauf hinausläuft, dass die erste Struktur die zweite als Element enthält. Das heißt die Datei <tt>s1.h</tt> sieht nun wie folgt aus:
<pre>
struct s1 {
s2_t x;
...
}
...
/* Funktions-Deklarationen */
void foo(s2_t);
...
</pre>
Daraufhin wird sich <tt>main.c</tt>(!) nicht mehr kompilieren lassen, da bei der Verarbeitung von <tt>s1.h</tt> (noch) nicht bekannt ist, worum es sich um bei <tt>s2_t</tt> handelt. (Es könnte ja auch einfach nur ein Tippfehler sein!)

Da es in der Praxis einen immensen Pflegeaufwand auslösen kann, wenn Änderungen in Include-Files Änderungen in vielen weiteren Dateien erfordern (dem Wesen nach soll ja eine Include-Dateien eine Information zentral für viele andere Dateien bereitstellen), muss nach einem Ausweg gesucht werden.

Dieser könnte so aussehen, dass man "vorsorglich" die Beschreibung der verwendeten Datenstruktur in <tt>s1.h</tt> inkludiert:
<pre>
#include "s2.h"
struct s1 {
s2_t x;
...
};
...
/* Funktions-Deklarationen */
void foo(s2_t);
...
</pre>

Inkludiert das Hauptprogramm lediglich <tt>s1.h</tt>, wäre nun alles in Ordnung, wenn aber beide Dateien inkludiert werden, beschwert sich der Compiler über die doppelte Definition der Datentypen. (Die doppelte Deklaration von Funktionen ist kein Fehler, wenn sie übereinstimmend erfolgt.)

== Problemlösung mit Makros ==
Die übliche und - fast - perfekte Lösung des Problems besteht darin, den eigentlichen Inhalt eines Include-Files vor einer zweiten Verarbeitung durch eine ''bedingte Kompilierung'' zu schützen.
Bei der bedingten Kopilierung handelt es sich ebenfalls um ein Feature des [[C-Präprozessors]] und es wird hier wie folgt auf die Datei <tt>s2.h</tt> angewendet:
<pre>
#ifndef S2_h
#define S2_h
struct s2 {
...
};
...
/* Funktions-Deklarationen */
s2_t *bar();
...
#endif
</pre>
Da das beschriebene Problem in größeren Programmsystemen auch in Bezug auf die andere Struktur auftreten könnte, sollte man die Datei <tt>s1.h</tt> vorsorglich mit einem ähnlichen Schutz ausstatten:
<pre>
#ifndef S1_h
#define S1_h
#include "s2.h"
struct s1 {
s2_t x;
...
};
...
/* Funktions-Deklarationen */
void foo(s2_t);
...
#endif
</pre>
Der nette Nebeneffekt ist, dass es damit auch keine Rolle spielt, in welcher Reihenfolge beide Dateien in <tt>main.cpp</tt>inkludiert werden.

== Zusammenfassung der Regeln ==
Kochrezeptartig kann man beim Schreiben und Verwenden von Include-Files auch einfach die folgenden Regeln anwenden:
* Wird die externe Schnittstelle (Datenstrukturen, Funktions-Deklarationen) eines Moduls ''XYZ'' in einem Include-File <tt>xyz.h</tt> beschrieben, so sollte ein bestimmter Makroname (z.B. <tt>XYZ_h</tt>) für die Steuerung der tatsächlichen Verarbeitung des Include-Files reserviert werden(*1).
* Der Include-File selbst testet (und definiert anschließend) diesen Makro, um so eine doppelte Verarbeitung zu vermeiden.
* Wird in einer Kompilierung das Modul ''XYZ'' verwendet (= eine seiner Datenstrukturen oder Funktionen), wird auch der Include-File <tt>xyz.h</tt> in diese Kompilierung eingeschlossen.
* Verwendet das Modul ''XYZ'' '''intern''' ein weiteres Modul ''UVW'', so wird '''dessen''' Include-File <tt>uvw.h</tt> im Include-File <tt>xyz.h</tt> eingeschlossen.

Die beschriebenen Regeln funktionieren zufriedenstellend und entlasten vor allem Programm-Code, welcher Include-Files lediglich einschließt, vom Wissen über komplexe Zusammenhänge zwischen einzelnen Modulen. Ferner spielt die Reihenfolge, in der man Include-Files verwendet, keine Rolle und man kann sie beliebig gruppieren und ordnen, so wie es am übersichtlichsten ist(*2).

== Gegenseitige Bezugnahme ==
Eine Ausnahme von der allgemeinen Regel liegt vor, wenn sich zwei Datenstrukturen gegenseitig verwenden (was nur über Zeiger der Fall sein kann).
Alle wie auch immer gearteten Versuche, diese beiden Strukturdefinitionen und Funktionsprototypen in zwei verschiedene Include-Files aufzuteilen, also z.B. <tt>s1.h</tt>
<pre>
#ifndef S1_h
#define S1_h
#include "s2.h"
struct s1 {
struct s2 *px;
...
};
typedef struct s1 s1_t;
...
s2_t *bar(s1_t);
#endif
</pre>
und <tt>s2.h</tt>
<pre>
#ifndef S2_h
#define S2_h
#include "s1.h"
struct s2 {
struct s1 *yp;
....
};
...
void foo(s2_t);
#endif
</pre>
werden scheitern - mit und ohne dem beschriebenen Schutz vor doppelter Verarbeitung!

Die pragmatische Lösung ist hier, alles in einem '''gemeinsamen''' Include-File <tt>s1_s2.h</tt>zu hinterlegen:
<pre>
#ifndef S1_S2_h
#define S1_S2_h
struct s1 {
struct s2 *px;
....
};
typedef struct s1 s1_t;

struct s2 {
struct s1 *yp;
....
};
typedef struct s2 s2_t;
...
void foo(s2_t);
s2_t *bar(s1_t);
#endif
</pre>
Das ist insofern sinnvoll, als ein Programm, welches die eine Struktur kennen muss, stets auch die andere benötigt. Die Aufteilung in zwei Include-Files würde also keinen echten Vorteil bringen.

Eine Ausnahme kann lediglich gemacht werden, wenn auf die jeweils andere Struktur ausschließlich über Zeiger(*3) zugegriffen wird, dann sind auch zwei Include-Files möglich, nämlich <tt>s1.h</tt>
<pre>
#ifndef S1_h
#define S1_h
struct s2; /* Vorausdeklaration */
struct s1 {
struct s2 *px;
...
};
typdef struct s1 s1_t;
...
struct s2 *bar(s1_t);
</pre>
und <tt>s2.h</tt>
<pre>
#ifndef S2_h
#define S2_h
struct s1; /* Vorausdeklaration */
struct s2 {
struct s1 *py;
...
};
typdef struct s2 s2_t;
...
void bar(struct s1 *);
</pre>
Anstatt den jeweils anderen Include-File einzuschließen, sind nun die oben gezeigten Vorausdeklarationen vorzumehmen. (Allerdings sind damit die Typdefinitionen <tt>s1_t</tt> und <tt>s2_t</tt> nicht verfügbar, die Bezugnahme auf die jeweils andere Struktur kann nur über <tt>struct s1</tt> und <tt>struct s2</tt> erfolgen.)

----
* 1: Die genaue Beziehung zwischen dem Makro-Namen und dem Modul- (oder Struktur-) Namen ist dabei nicht so bedeutend. Die übliche Konvention, solche "Steuer-Makros" mit "<tt>_h</tt>" oder "<tt>_H</tt>" zu beenden, soll nur helfen, "zufällige" Kollissionen mit Makros zu vermeiden, die einen anderen Zweck haben.
* 2: Eine alphabetische Sortierung ist z.B. hilfreich, um bei einem Kompilierfehler schnell überprüfen zu können, ob vielleicht nur ein bestimmter Include-File vergessen wurde.
* 3: Bei der Verwendunng von C++ gilt das zusätzlich für die Bezugnahme über Referenzen.

Watchdog

2004-06-18T23:32:10Z

80.140.66.5:

Ein Watchdog ist eine Schaltung (extern oder im [[Mikrocontroller]] integriert), die bei einem Programmabsturz einen [[Reset]] auslöst, damit der Microcontroller seine Aufgabe wieder erledigen kann.

Technisch wird das so realisiert, daß es einen Zeitgeber (z.B. Kondensator oder [[Timer]]) gibt, den man regelmäßig zurücksetzen muß. Ist der Mikrocontroller abgestürzt, dann kann er das nicht mehr tun und der Watchdog löst den Reset aus.

Testseite

2004-06-18T23:30:44Z

80.140.66.5: /* Kleiner Test */

huhuhuhuhuhuhu

[http://www.google.de googletest]

[[Bild:Qfp.jpg]] --[[Benutzer:Andreas|Andreas]] 16:41, 8. Jun 2004 (CEST)

=ist das jetzt das level oder die fontart oder beides=
naja. hängt das ding an einem globalen wiki mit dran?
oder gibts dann hundert wikis zum gleichen thema?

== Ein kleiner Test mit den Formeln ==

=== Kreisgleichung ===
<math>r^2=(x-x_0)^2+(y-y_0)^2</math>
<math>Formel hier einfügen</math>--[[Benutzer:62.47.196.18|62.47.196.18]] 20:32, 12. Jun 2004 (CEST)[[Link-Text]]

=== Irgendein Schwachsinn ===
<math>a=\sqrt{\frac{mc^2}{E}}</math>

'''Eigentlich schade, daß die Schriftart gewechselt wird. Dies sieht ja bescheiden aus.'''
Hallo??
=Kleiner Test=
[[Bild:http://www.google.ch/images/hp0.gif]]
ach menno...wie macht man denn da ein Bild rein, wenns gar nicht aufm Server ist?...gar nich?

http://www.google.ch/images/hp0.gif

Hilfe:Bearbeitungshilfe

2004-06-18T16:40:23Z

80.140.66.5:

Eine ausführliche Beschreibung der Gliederungs- und Formatierungsmöglichkeiten findet sich im Wikipedia Online-Lexikon: http://de.wikipedia.org/wiki/Wikipedia:Seite_bearbeiten