Mikrocontroller.net - Benutzerbeiträge [de]

Feuchtesensor

2008-04-11T14:40:36Z

84.156.75.65: kat.

Feuchtigkeitssensoren bzw. Feuchtesensoren arbeiten meist nach dem Prinzip eines feuchtigkeitsabhängigen Kondensators. 

==Typen==

===Philips H1 2322 691 90001===
vom Reichelt (Datenblatt dort downloaden): 
jetzt von vishay hergestellt: http://www.vishay.com/docs/29001/23226919.pdf 
Applikation von Valvo dazu:
http://docs.poulter.de/Elektronik/Sensoren/Luftfeuchtesensor%20VALVO.pdf 
FEUCHTESENSOR Sensor für Feuchtigkeit € 10.00 
Feuchtesensor zur Messung und Regelung der relativen Luftfeuchte 
Kapazität: 122pF +/-15%
Empf.(Frel=43%): 0,4pF/%Frel 
Meßfrequenz: 1kHz...1MHz
Meßbereich: 10%...90% 
Top: 0°C...+85°C
Vmax: 15V 
Weitere Informationen zu diesem Artikel finden Sie in den Datenblättern

Auswerten z.B. mit einem Oszillator muss man selbst!

===KM33 von Innovative Computer===
ab € 43,00 
Schuricht 115-245057 
vermutlich auch nur ein variabler Kondensator

===HIH-3610, HIH3610===
von Honeywell (sehr linear, aber über € 23,00) 
analoger Ausgang 0..4V 
Versionen:
* -001 RM 2,54 unkalibriert
* -002 RM 1,27 unkalibriert
* -003 RM 2,54 kalibriert
* -004 RM 1,27 kalibriert
Nachtrag: sind abgekündigt, Nachfolger: 
HIH-4000-001, HIH4000-001 und HIH-4000-003, HIH4000-003 
http://catalog.sensing.honeywell.com/ss.asp?FAM=humiditymoisture 

===H25K5A===
von Sencera (<4€ bei CSD) 
Variabler Widerstand bei Wechselspannung. 
Bereich 0..+60°C, 20..90%RH. Achtung: auch Lagerung nur bis 90%RH 
Temperaturkompensierte Messung über Spannungsteiler mit handelsüblichem NTC.
 

===HS1101===
von Humirel (~14€ bei CSD) 
Variable Kapazität, 164..200pF. 
Temperaturbereich -40..+100°C. 
Temperaturkompensierter Oszillator mit CMOS-Timer 555 im Datasheet.
 

===INSED===
* HIH3602A Feuchtigkeit und Temperatur (ab € 79,00) bei RS-Components
* HIH3602C Feuchtigkeit und Temperatur (ab € 82,00) bei RS-Components

Bezugsquellen: 
INSED GmbH + Co KG Sensoren für die Industrie Kronenstr 10 70794 Filderstadt 0711-9972758 Fax 9972762 
IBA GmbH Ingenieurbüro für Sensorik
Am Sandborn 14 63500 Seligenstadt 06182 95980 
Schuricht RS-Components Farnell 

===www.vaisala.be===
* 17204HM-humichip- mit Temp-Sensor KTY85-110 (special selection), analog 0..1V 
* 17205HM ohne Temp-Sensor analog 0..1V 

Datenblatt fand ich nicht auf deren Homepage, aber im Forum: 
http://www.mikrocontroller.net/forum/read-1-15717.html#48616 

Vermutlich verkaufen sie lieber fertige Module: 
http://www.vaisala.com/businessareas/instruments/products/humidity 
http://www.vaisala.com/businessareas/instruments/products/humidity/modules/oemmodules

===Sensirion===
Von [http://www.sensirion.com Sensirion] gibt es eine ganze Latte digitaler (I2C-ähnlich, digital 2-wire output): SHT10 SHT11 SHT15 SF1 SHT71 SHT75 EvaKit EK-H2 EK-H3
* Bezugsquellen: http://www.micromaus.de, http://www.driesen-kern.de/ und CSD (SHT11, 20€)
* [http://www.mikrocontroller.net/topic/48590#372123 C-Bibliothek] von Timo Dittmar im Forum
* Applikationnotes (PDF) [http://www.sensirion.com/images/getFile?id=91 #91] und [http://www.sensirion.com/images/getFile?id=95 #95] mit C-Beispielen

[[Kategorie:Bauteile]]

Digitaltechnik

2008-04-11T14:39:52Z

84.156.75.65: kat.

==Bit==

Abkürzung für '''Bi'''nary digi'''t'''

Ein Bit ist die kleinste digitale Einheit und kann die Werte 0 und 1 annehmen.

Siehe auch
* [[Bitmanipulation]]

==Nibble==

Nibble ist eine weniger gebräuchliche Bezeichnung für ein halbes Byte (4 Bit). In diesem Zusammenhang spricht man häufig von HIGH- und LOW-Nibble. Ein Nibble entspricht auch jeweils einem Zeichen der hexadezimalen Darstellung.

==Byte==

Abkürzung für '''B'''inar'''y''' '''Te'''rm.

Ein Byte besteht aus 8 Bits und kann damit 2^8 = 256 verschiedene Werte annehmen.

http://www.mikrocontroller.net/images/bits.gif

In der üblichen Schreibweise (INTEL) werden die einzelnen Bits von rechts nach links abgezählt. "MSB" nennt man das höchstwertige Bit (ganz links, Bit 7), "LSB" das niederwertigste (ganz rechts, Bit 0).

Auf dem PowerPC ist es umgekehrt, dort ist Bit #0 das MSB (links) und Bit 7/15/31/63 ganz rechts das LSB.

==Word==

Ein Word besteht aus zwei oder mehr (2^N) aufeinanderfolgenden Bytes. Im Falle von zwei Bytes kann es somit 256*256 = 65536 Werte annehmen.

Prozessoren mit mehr als 16 Bits "natürlicher" Breite bezeichnen oft ihre natürliche Breite als Word (also ein 32-bit-Prozessor 4 aufeinanderfolgende Bytes, ein 64-bit-Prozessor 8 aufeinanderfolgende Bytes). Allerdings wird dies nicht mehr durchweg einheitlich gehandhabt. Auf einer [[X86]]-Architektur ist es oft unter MS Windows aufgrund seiner Abstammung von einem 16-Bit-Betriebssystem üblich, zwei Bytes als Word zu bezeichnen. Wird der gleiche Prozessor unter [[Unix]] betrieben, bezeichnet ein Word dagegen 4 aufeinanderfolgende Bytes, da das Betriebssystem als 32-Bit System auf diesen Prozessor portiert worden ist (zu Zeiten, da die X86-Architektur bereits eine natürliche Wortbreite von 32 Bit hatte, also i386 und höher).

=== Endianness ===

In Verbindung mit einem 16, 32 oder 64 Bit [[Prozessor]] ist das Problem interessant, in welcher Reihenfolge die Bytes im Speicher angeordnet sind, also das höherwertige Byte an vorderer oder hinterer Stelle. Die unterschiedliche Art der Darstellung z.B. zwischen den x86- und PowerPC Prozessoren nennt man "Little Endian" und "Big Endian". Diese kuriose Bezeichnung lehnt an das Problem an, von welchem Ende man ein Ei aufschlagen sollte.

Beispiel:

Little Endian Hex Dump:

00000000 20 8F 04 08 23 00 00 00 12 00 00 00 1E 00 00 00 | ...#...........|
00000010 94 8D 04 08 00 00 00 00 12 00 08 00 '''E6 01''' 00 00 |................|

Der markierte Bereich auf Adresse 0x1C zeigt das 16-bit Word mit dem Wert

0xE6 + (256 * 0x01) = 0x01E6 = 486

Die jeweils größeren Adressen enthalten dabei die höherwertigen Bytes des Word.

Auf einer Big-Endian Maschine würde der Hexdump so aussehen:

00000000 8F 20 08 04 00 23 00 00 00 12 00 00 00 1E 00 00 |. ...#..........|
00000010 8D 94 08 04 00 00 00 00 00 12 00 08 '''01 E6''' 00 00 |................|

Die höheren Adressen enthalten hier die niederwertigen Bytes. Das erscheint auf den ersten Blick unlogisch, hat aber andererseits den Vorteil, daß man die Zahl (0x01E6) "auf den ersten Blick" im Hexdump erkennen kann.

Mikroprozessoren wurden von Intel zunächst in Little-Endian Byteorder eingeführt, worauf Motorola mit Big-Endian Byteorder reagierte. Viele [[RISC]]-Prozessoren kann man theoretisch per Hardwarebit in ihrer Byteorder umschalten, wobei dies praktisch so früh erfolgen muß, daß die gesamte Maschine (einschließlich [[BIOS]] etc.) darauf eingerichtet sein muß.

Big-Endian ist auch die sogenannte ''Network Byte Order'', d.h. insbesondere im IP-Bereich werden alle Daten "auf dem Draht" in dieser Anordnung übertragen. Entsprechend müssen Little-endian Maschinen in ihren Netzwerkprotokollen sehr viel zwischen beiden Anordnungen übersetzen, so daß es z.B. beim Intel Pentium einen eigenen Prozessorbefehl für diese Operation gibt.

* Typische Vertreter für Little-Endian sind:
** [[X86]]
** Zilog [[Z80]], da er vom Intel 8080 abstammt
** DEC Alpha
** [[AVR]] mit [[AVR-GCC]]

* Typische Vertreter für Big-Endian sind:
** Motorola [[MC68000]]
** [[PowerPC]]
** [[SPARC]]
** Zilog [[Z8]] und Z8000

Mit der Endianess in Verbindung steht die Frage der Bitnummerierung. Wenn man bei Big-Endian die Bits von rechts nach links nummeriert, bekommt man spätestens bei Bitfeldern Probleme. 68020 nummeriert deshalb Einzelbits von rechts nach links, die später hinzugekommenden Bitfelder von links nach rechts. Weshalb solche Prozessoren die Bits manchmal konsequent von links nach rechts nummerieren (z.B. PowerPC), was jene irritiert, die in der Bitnummer auch die Wertigkeit des Bits sehen.

=== Alignment auf größeren Prozessoren ===

Damit wird die Ausrichtung (engl. Alignment) von Daten mit mehr als ein Byte Länge beschrieben. Manche Prozessoren benötigen bei Zugriffen auf ein Word eine Adresse, die mit der Wortgröße ausgerichtet ist, besonders [[RISC]]-[[Prozessor]]en. Soll beispielsweise auf ein 32-Bit Word zugegriffen werden, so muß die Adresse dann ebenfalls durch 4 teilbar sein (32 Bit = 4 Byte). Dies wird erforderlich, da der gesamte Prozessor- und Speicherbus in dieser Wortgröße organisiert ist, so daß ein ''unaligned access'' (Zugriff auf nicht teilbare Adresse) mehr als einen Buszyklus verursachen würde. Ein solcher Zugriff generiert auf diesen Prozessoren dann einen [[Trap]]. Andere Prozessoren (z.B. [[X86]]) können diesen ''unaligned access'' zwar ausführen, indem sie die Ergebnisse von zwei Speicherzyklen zum gewünschten Word kombinieren, jedoch ist dieser Mehrfachzugriff uneffektiv, so daß [[Compiler]] sich trotzdem gern an die Ausrichtung auf ganze Wortgrenzen halten, beispielsweise beim Ausrichten von [[struct]] Elementen durch Einfügen von Füllbytes (padding bytes), oder durch Einfügen von [[NOP]]s vor Beginn einer neuen Funktion.

[[Kategorie:Grundlagen]]

DebugWIRE

2008-04-11T14:39:07Z

84.156.75.65: kat.

'''debugWIRE''' ist die Bezeichnung einer Debug-Schnittstelle, die
Atmel für die kleineren Mitglieder seiner [[AVR]]-Controllerfamilie
entwickelt hat, die nicht über [[JTAG]] verfügen. Es wurde vor allem
konzipiert für Controller mit wenigen Pins, bei denen der für JTAG
notwendige Aufwand von 4 separaten Leitungen die möglichen
Applikationen zu stark einschränken würde. Daher ist es bei allen
moderneren ATtiny-Controllern anzutreffen, aber auch bei einigen
kleinen ATmega-Typen (ATmega48/88/168/328 bzw. deren
Picopower-Versionen).

==Physik==

debugWIRE ist als sogenannter Eindrahtbus konzipiert, ähnlich wie der
Dallas (jetzt Maxim) [[Bus#1-Wire][1-wire-Bus]]. Es erfolgt eine bidirektionale
Datenübertragung über nur einen einzigen Draht (und Masse als
Rückleitung). Um die Applikation in den ihr zur Verfügung stehenden
Pins möglichst wenig einzuschränken, wurde die /RESET-Leitung für
debugWIRE doppelt belegt.

Die Realisierung als Eindrahtbus stellt einen Kompromiss dar, der bei
der Gestaltung des Zielsystems berücksichtigt werden muss. Um den
bidirektionalen Datentransfer ohne Schaden an Ausgangstreibern bei
möglichen Bus-Kollisionen zu realisieren, arbeiten lediglich zwei
Open-Drain-Ausgänge (einer im Emulator und einer im AVR) auf den Bus
und können ihn nach ''low'' ziehen. In Richtung ''high'' wird er
durch einen integrierten Widerstand gegen VCC (pull-up) gezogen, was
naturgemäß in einer Spannungs-Zeit-Kurve in Form einer
Exponentialfunktion resultiert. Die RC-Zeitkonstante des gesamten
Eindrahtbusses (bei der der genaue Wert für C abhängig ist vom Aufbau
des Zielsystems) limitiert die mögliche Datenübertragungsrate.

Beim Aufbau muss aus diesem Grunde darauf geachtet werden, dass die
/RESET-Leitung keine zusätzliche kapazitive Last erhält und dass ein
eventuell vorhandener externer Pullup-Widerstand nach VCC nicht
kleiner als 10 kΩ dimensioniert ist. (Auf eine Anfrage bei einem
Problem hat die Atmel-Hotline jedoch auch teilweise bereits ein
Minimum von 4,7 kΩ empfohlen.) Zwar ist dieser Widerstand laut
Dokumentation nicht erforderlich, aber er kann u. U. die
Übertragungsqualität des Busses verbessern helfen.

Da eine derartige Beschaltung der /RESET-Leitung den Richtlinien zum
EMV-festen Schaltungsentwurf entsprechend
[http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf Appnote AVR040]
widerspricht, sollte man bei einer Platinenentwicklung die
EMV-Schutzbeschaltung vorsehen aber für das Debuggen mittels debugWIRE
nicht bestücken.

==Protokoll==

Das eigentliche debugWIRE-Protokoll wird von Atmel als Firmengeheimnis
betrachtet und ist nicht veröffentlicht. Der einzige Weg, dieses zu
nutzen ist durch den Einsatz eines entsprechenden Emulators. Derzeit
stehen dafür das
[http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 JTAG ICE mkII]
und der
[http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon]
zur Verfügung.

Die im [[AVR]] untergebrachte debugWIRE-Maschine ist weniger mächtig
als bei [[JTAG]]. Im Wesentlichen kann sie nur solche Tätigkeiten
erledigen, die auch die CPU des Controllers im normalen Betrieb
erledigen kann (einschließlich der Abarbeitung von SPM-Befehlen zum
Ändern des Flash-ROMs). Damit lassen sich entsprechend keine Fuses
und Lockbits lesen oder setzen. Anders als [[JTAG]] besitzt debugWIRE
keine Breakpoint-Möglichkeiten in der CPU-Hardware, damit können
Breakpoints nur über das Einfügen von BREAK-Befehlen in den
Flash-ROM-Inhalt realisiert werden (Software-Breakpoint). Dies
erfolgt transparent durch die Firmware des JTAG ICE, die nach dem
Erreichen des Breakpoints den ursprünglichen Inhalt der entsprechenden
Seite im Flash-ROM wieder herstellt. Daten-Breakpoints sind nicht
möglich.

Das entsprechende häufige Umprogrammieren des Flash-ROM-Inhaltes trägt
zur Abnutzung desselben bei. Dies sollte berücksichtigt werden, wenn
man in Erwägung zieht, Geräte nach dem Debuggen noch ihrer
tatsächlichen Nutzung zuzuführen.

Insgesamt abstrahiert das JTAG ICE mkII (bzw. der AVR Dragon) die
Details des Protokolls auf eine Schnittstelle, die im Wesentlichen
komplett der bei einer Emulation über [[JTAG]] entspricht.

Die Aktivierung des debugWIRE-Modus erfolgt durch das Setzen (also
Programmieren auf den Bitwert 0) der DWEN-Fuse, die normalerweise im
''high fuse byte'' zu finden ist. Ab diesem Moment steht der
/RESET-Pin nicht mehr für seine normale Reset-Funktion zur Verfügung,
daher lässt sich dann auch das [[ISP]]-Protokoll nicht mehr nutzen.

Das Abschalten des debugWIRE-Modus erfolgt in zwei Stufen. In einer
ersten Stufe wird mit einem speziellen Befehl an das JTAG ICE mkII ein
CPU-Reset ausgeführt, der die debugWIRE-Einheit vorübergehend
deaktiviert und damit die normale /RESET-Funktion wiederherstellt.
Damit lässt sich nachfolgend normales [[ISP]]-Protokoll anwenden, um
die DWEN-Fuse wieder zurückzusetzen (debugWIRE selbst kann keine Fuses
ändern). Dieser vorübergehende Zustand dauert an bis zum nächsten
Aus- und Einschalten des [[AVR]], in diesem Moment wird dann die
DWEN-Fuse neu bewertet. Technisch ist es ebenso möglich, die
DWEN-Fuse einfach aktiviert zu lassen und den [[ISP]]-Modus nur
temporär für andere Aufgaben zu nutzen. Nach dem erneuten Einschalten
ist der [[AVR]] dann wieder im debugWIRE-Modus.

=Software=

[[AVR-Studio]] kann mit den entsprechenden Emulatoren umgehen und
bietet die debugWIRE-Schnittstelle automatisch als Debugmöglichkeit
für alle AVRs an, bei denen sie vorhanden ist. (Genauer: bei denen
sie im sogenannten ''part description file'' aufgeführt worden ist.)

[[AVRDUDE]] kann debugWIRE über die Manipulation der Fuses zuschalten
und kann im debugWIRE-Modus den Inhalt von Flash-ROM oder EEPROM lesen
oder schreiben. Das Rückschalten aus dem debugWIRE-Modus erfolgt
zweistufig so, wie es von der Hardware vorgegeben ist. Dazu aktiviert
man ein entsprechendes Kommando für eine ISP-Programmierung mittels
JTAG ICE mkII (''-c jtag2isp'') oder mittels AVR Dragon (''-c dragon_isp'').
Wenn dieses Kommando fehlschlägt, versucht [[AVRDUDE]]
anschließend das temporäre Abschalten des debugWIRE-Modus und trennt
sich vom Emulator. Ein erneutes Absetzen des gleichen Kommandos
sollte dann im [[ISP]]-Modus ganz normal funktionieren.

[http://avarice.sourceforge.net/ AVaRICE] kann mit der Option -w über
debugWIRE sowohl das JTAG ICE mkII als auch den AVR Dragon bedienen.
Es dient dabei als Bindeglied zum [[GDB]], der die eigentlichen
Debugger-Aufgaben erledigt.

[[Kategorie:AVR]]

433 MHz Funkübertragung

2008-04-11T14:37:03Z

84.156.75.65: kat.

== Funkmodule ==

Maximale Sendeleistung üblicher Funkmodule: 10 mW. Bekannter Hersteller: Aurel (http://www.aurel.it), Bezugsquellen: Conrad und funkmodul.com. Sehr beliebt ist auch das [[RFM12]] von Pollin.

=== AM ===

Arbeiten mit On-Off-Keying, d.h. das HF-Signal wird zur Übertragung von 1/0 einfach an/abgeschaltet. Dies ist die einfachste (billigste) Lösung.

Statt AM wird dafür auch die Abkürzung ASK benutzt. Sie steht für "amplitude shift keying".

Dieses Verfahren wird gern in Funksteckdosen angewandt. Der Sender ist dabei ein Oszillator mit einem SAW-Resonator. Die Anschwingzeit liegt bei ca. 30µs.
Um diese Zeit wird ein "1"-Impuls verkürzt. Die Sendefrequenz hat eine Toleranz von ca. +/- 100 kHz. Ein Vorteil für den Batteriebetrieb besteht darin, dass der Sender nur beim Senden der Impulse Energie benötigt. In den Pausen ist der Sender abgeschaltet und spart Strom.
Der Empfänger ist als Pendelaudion aufgebaut. Dazu sind nur wenige Bauteile erforderlich. Die entstehende Störstrahlung erzwingt einen Mindestabstand von ca. 1 m zwischen zwei Empfängern.
Das Pendelaudion arbeitet als relativ breitbandiger Empfänger und verträgt sich deshalb gut mit dem SAW-Resonator, der relativ große Toleranzen der Sendefrequenz mit sich bringt.
Die Kombination beider Techniken bietet dann eine Reichweite von bis zu 30m innerhalb von Gebäuden, bzw. bis zu 300m außerhalb.

=== FM (FSK) ===

Teurer, und besser.

Besser bedeutet hier eine höhere Datenrate und eine größere Reichweite bei gleicher Sendeleistung. Der Bauteilaufwand und die Kosten sind jedoch größer als bei den einfachen AM-Baugruppen. Der Energiebedarf ist ebenfalls höher.

Der Grund liegt in der geringeren Bandbreite, auf die die Sendeenergie konzentriert wird. Der Sender arbeitet jedoch im Dauerbetrieb und benötigt deshalb zur Datenübertragung mehr Energie. Der Empfänger ist prinzipiell schmalbandiger und deshalb störunempfindlicher. Letztlich sorgt das für eine höhere Reichweite.

== Antennen und Antennenanpassung ==

Die einfachste Antenne ist ein Draht der Länge <math>\lambda/4</math> (bei 433 MHz entspricht das 17 cm).

Allgemeine Hinweise zur Anpassung, Vergleichstabellen verschiedener Antennenformen bei 433 MHz, ...:
* http://www.mikrocontroller.net/topic/41515
* http://www.mikrocontroller.net/topic/90702

== Codierung ==

Bei kurzen Reichweiten und geringen Datenraten kann man oft ohne Fehlerkorrektur auskommen. Um Fehler bei der Übertragung in gewissen Grenzen reparieren zu können verwendet man Kanalcodierung. Dabei wird in das Sendesignal Redundanz eingefügt, die am Empfänger zur Korrektur von Bitfehlern genutzt werden kann. Also: Nutzdatenrate wird kleiner, Zuverlässigkeit wird größer. Einfache und beliebte Codierungsverfahren sind z.B. BCH-Codes. Um darüber hinaus Fehler zuverlässig '''erkennen''' zu können, verwendet man eine Prüfsumme (z.B. [[CRC]]). Eine einfache Variante ist, die Übertragung einfach mehrmals zu wiederholen.

Durch lange Codes (>100 Bit für ein Datenbit) lassen sich auch mit billigen Funkmodulen große Reichweiten auf Kosten der Übertragungsrate erreichen, siehe Artikel [[Codierte Übertragung]].

[[Kategorie:Bauteile]]

ARM GCC toolchain for Linux and Mac OS X

2008-04-11T14:35:11Z

84.156.75.65: kat.

'''Update (2007-04-20): added Mac OS X Intel version'''

This package is intended for and was tested with small ARM microcontrollers like LPC21xx, AT91SAM7, ST7, ADuC7000, but should work for any system supported by arm-elf. Take a look at the configuration of the components below to find out whether it suits your application.

== Content (Build 2) ==

This build is similar to Martin Thomas' WinARM package. The main difference to GNUARM is that in WinARM and this build Newlib is compiled with the option -DREENTRANT_SYSCALLS_PROVIDED, as recommended in Bill Gatliff's article "Porting and Using Newlib in Embedded Systems".

* Binutils 2.16.1 configured with <code>--target=arm-elf --enable-interwork --enable-multilib</code>
* GCC 4.1.0 with patched t-arm-elf, configured with <code>--target=arm-elf --enable-interwork --enable-multilib --enable-languages="c,c++" --with-newlib</code>
* Newlib 1.14.0 configured with <code>--target=arm-elf --enable-interwork --enable-multilib</code> and <code>-DREENTRANT_SYSCALLS_PROVIDED</code>
* GDB 6.4 configured with <code>--target=arm-elf --enable-interwork --enable-multilib</code>

Everything is built with <code>--prefix=/usr/local/arm</code>. The Linux version is compiled with Debian Sarge, the Mac OS X PPC version with 10.3 (Panther), the Mac OS Intel Version with 10.4 (Tiger). All binaries are stripped. The build process on Linux and Mac OS X is identical.

== Download ==

* [http://www.mikrocontroller.net/download/arm-toolchain-macosx-2.tar.bz2 Build 2 - Mac OS X PPC (23 MB)]
* [http://www.mikrocontroller.net/download/arm-toolchain-macosx-intel-2.tar.bz2 Build 2 - Mac OS X Intel (32 MB)] ([http://en.mikrocontroller.net/topic/104901 compiled by Darrik Spaude])
* [http://www.mikrocontroller.net/download/arm-toolchain-linux-2.tar.bz2 Build 2 - Linux (23 MB)]

== Installation ==

cd /tmp
# download
curl -O -C - http://www.mikrocontroller.net/download/arm-toolchain-macosx-2.tar.bz2
# extract
tar xjvf arm-toolchain-macosx-2.tar.bz2
# install
sudo mv arm /usr/local/
# add /usr/local/arm/bin to your path permanently
echo 'export PATH=/usr/local/arm/bin:$PATH' >> ~/.profile

== Support forum ==

If you have any questions regarding this toolchain build or want to discuss ARM-GCC programming in general, please visit [http://en.mikrocontroller.net/ the forum].

== Related websites ==

* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ WinARM, ARM projects]
* [http://www.gnuarm.com GNUARM]: Linux, Windows and outdated Mac OS X builds of GCC+Newlib+GDB

[[Kategorie:ARM]]

ARM Selektor

2008-04-11T14:30:56Z

84.156.75.65: formatfix

== Motivation ==

Da ich gerne mit '''ARMs''' arbeite, ich aber meist nur die Typen einsetzte, mit denen ich schon Erfahrungen gesammelt habe, denke ich, ist es auch für unser Mitmenschen/Entwickler interessant diverse Chips, diverser Hersteller anhand ihrer Daten zu vergleichen und so eventuell mal über den Tellerrand hinaus zu schauen. Etwas vergleichbares habe ich trotz ausgiebiger googlelei nicht gefunden. Bitte ergänzt die Tabelle mit Typen die Ihr kennt.

== Typenvielfalt ==

{| border="1" class="sortable" id="ARM Typen"
|-
! Name
! Core
! MHz
! RAM(kB)
! Flash(kB)
! Bauform
! 3,3V Supply
! 1,8V Supply
! ext. Bus
! I/O`s
! ADC
! DAC
! RS232
! SPI
! I²C
! I²S
! MMC
! CAN
! USB
! ETH
! Timer
! PWM
! RTC
! ser. Bootloader
! Hersteller
|-
| LPC2101
| ARM7TDMI-S
| 70
| 2
| 8
| LQFP48
| ja
| ja
| nein
| 32
| 8x10bit
| 0
| 2
| 2
| 2
| 0
| 0
| 0
| 0
| 0
| 2(32Bit) + 2(16bit)
| 6
| ja
| ja
| NXP
|-
| LPC2103
| ARM7TDMI-S
| 70
| 8
| 32
| LQFP48
| ja
| ja
| nein
| 32
| 8x10bit
| 0
| 2
| 2
| 2
| 0
| 0
| 0
| 0
| 0
| 2(32Bit) + 2(16bit)
| 6
| ja
| ja
| NXP
|-
| LPC2119
| ARM7TDMI-S
| 60
| 16
| 128
| LQFP64
| ja
| ja
| nein
| 45
| 4x10bit
| 0
| 2
| 2
| 2
| 0
| 0
| 0
| 0
| 0
| 2
| 6
| ja
| ja
| NXP
|-
| LPC2148
| ARM7TDMI-S
| 60
| 40
| 512
| LQFP64
| ja
| nein
| nein
| 45
| 14x10bit
| 1x10bit
| 2
| 2
| 2
| 0
| 0
| 0
| 0
| 0
| 2
| 6
| ja
| ja
| NXP
|-
| LPC2368
| ARM7TDMI-S
| 72
| 32+16+8+2
| 512
| LQFP100
| ja
| nein
| nein
|
| 6x10bit
| 1x10bit
| 4
| 2
| 3
| 2
| 1
| 1
| 1
| 1
| 4
| 6
| ja
| ja
| NXP
|-
| LPC2378
| ARM7TDMI-S
| 72
| 32+16+8+2
| 512
| LQFP144
| ja
| nein
| ja
|
| 6x10bit
| 1x10bit
| 4
| 2
| 3
| 2
| 1
| 1
| 1
| 1
| 4
| 6
| ja
| ja
| NXP
|-
|}

== Weblinks ==
* [http://www.nxp.com/acrobat_download/literature/9397/75016140.pdf NXP-Übersichtstabelle 6 Seiten, ARM7 auf Seite 2-3]
* [http://www.atmel.com/dyn/products/param_table.asp?family_id=605&OrderBy=part_no&Direction=ASC Atmel Übersicht AT91SAM-Reihe]
* [http://www.st.com/mcu/pfinder-ARM7.html ST-ARM7 Familie STR7xx]
* [http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?&showAllResults=true&totalCount=23&showAllResultStatus=true&familyId=1299&uiTemplateId=PT-GSA&techFamId=null&sectionId=95&tabId=1930&appId=null&viewDeviceCallingPage=null&totalCount=23&showAdditionalParameters=no&lc=2000062&lc=2000121&lc=2000607&lc=2000886&lc=2001201&lc=2001227&lc=2001219&lc=2001220&lc=2001202&lc=2001203&lc=2000565&lc=2000825&lc=2000299&compare=yes&download=yes&sort=yes&customize=yes&paramResults=yes&paramCriteria=yes&familyTree=yes&military=no&baSystem=yes&paramTable=no&sortOption=PA_PART_NUMBER&sortMode=DESC&searchPaths=1001299&pageId=1299&templateId=0&navigationId=0&family=mcu&paramTable=no&military=no&ul=TMS470R1VF689&ul=TMS470R1VF67A&ul=TMS470R1VF55BA&ul=TMS470R1VF4B8&ul=TMS470R1VF48C&ul=TMS470R1VF478&ul=TMS470R1VF45BA&ul=TMS470R1VF45AA&ul=TMS470R1VF448&ul=TMS470R1VF356&&uiTemplateId=PT-GSA&techFamId=null&sectionId=95&tabId=1930&appId=null&viewDeviceCallingPage=null#rt Texas Instruments TMS470 automotive ARM7 Übersicht]
* [http://www.micronas.com/products/by_function/cdc_3207g/related_products/index.html Micronas ARM7-Controller]
* [http://www.luminarymicro.com/products/product_selector_guide.html Luminary Micro ARM Cortex-M3 Selector Guide]

[[Kategorie:ARM]]

ARM Selektor

2008-04-11T14:30:08Z

84.156.75.65: kat.

== Motivation ==

Da ich gerne mit '''ARMs''' arbeite, ich aber meist nur die Typen einsetzte, mit denen ich schon Erfahrungen gesammelt habe, denke ich, ist es auch für unser Mitmenschen/Entwickler interessant diverse Chips, diverser Hersteller anhand ihrer Daten zu vergleichen und so eventuell mal über den Tellerrand hinaus zu schauen. Etwas vergleichbares habe ich trotz ausgiebiger googlelei nicht gefunden. Bitte ergänzt die Tabelle mit Typen die Ihr kennt.

== Typenvielfalt ==

{| border="1" class="sortable" id="ARM Typen"
|-
! Name
! Core
! MHz
! RAM(kB)
! Flash(kB)
! Bauform
! 3,3V Supply
! 1,8V Supply
! ext. Bus
! I/O`s
! ADC
! DAC
! RS232
! SPI
! I²C
! I²S
! MMC
! CAN
! USB
! ETH
! Timer
! PWM
! RTC
! ser. Bootloader
! Hersteller
|-
| LPC2101
| ARM7TDMI-S
| 70
| 2
| 8
| LQFP48
| ja
| ja
| nein
| 32
| 8x10bit
| 0
| 2
| 2
| 2
| 0
| 0
| 0
| 0
| 0
| 2(32Bit) + 2(16bit)
| 6
| ja
| ja
| NXP
|-
| LPC2103
| ARM7TDMI-S
| 70
| 8
| 32
| LQFP48
| ja
| ja
| nein
| 32
| 8x10bit
| 0
| 2
| 2
| 2
| 0
| 0
| 0
| 0
| 0
| 2(32Bit) + 2(16bit)
| 6
| ja
| ja
| NXP
|-
| LPC2119
| ARM7TDMI-S
| 60
| 16
| 128
| LQFP64
| ja
| ja
| nein
| 45
| 4x10bit
| 0
| 2
| 2
| 2
| 0
| 0
| 0
| 0
| 0
| 2
| 6
| ja
| ja
| NXP
|-
| LPC2148
| ARM7TDMI-S
| 60
| 40
| 512
| LQFP64
| ja
| nein
| nein
| 45
| 14x10bit
| 1x10bit
| 2
| 2
| 2
| 0
| 0
| 0
| 0
| 0
| 2
| 6
| ja
| ja
| NXP
|-
| LPC2368
| ARM7TDMI-S
| 72
| 32+16+8+2
| 512
| LQFP100
| ja
| nein
| nein
|
| 6x10bit
| 1x10bit
| 4
| 2
| 3
| 2
| 1
| 1
| 1
| 1
| 4
| 6
| ja
| ja
| NXP
|-
| LPC2378
| ARM7TDMI-S
| 72
| 32+16+8+2
| 512
| LQFP144
| ja
| nein
| ja
|
| 6x10bit
| 1x10bit
| 4
| 2
| 3
| 2
| 1
| 1
| 1
| 1
| 4
| 6
| ja
| ja
| NXP
|-
|}

== Weblinks ==
[http://www.nxp.com/acrobat_download/literature/9397/75016140.pdf NXP-Übersichtstabelle 6 Seiten, ARM7 auf Seite 2-3]

[http://www.atmel.com/dyn/products/param_table.asp?family_id=605&OrderBy=part_no&Direction=ASC Atmel Übersicht AT91SAM-Reihe]

[http://www.st.com/mcu/pfinder-ARM7.html ST-ARM7 Familie STR7xx]

[http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?&showAllResults=true&totalCount=23&showAllResultStatus=true&familyId=1299&uiTemplateId=PT-GSA&techFamId=null&sectionId=95&tabId=1930&appId=null&viewDeviceCallingPage=null&totalCount=23&showAdditionalParameters=no&lc=2000062&lc=2000121&lc=2000607&lc=2000886&lc=2001201&lc=2001227&lc=2001219&lc=2001220&lc=2001202&lc=2001203&lc=2000565&lc=2000825&lc=2000299&compare=yes&download=yes&sort=yes&customize=yes&paramResults=yes&paramCriteria=yes&familyTree=yes&military=no&baSystem=yes&paramTable=no&sortOption=PA_PART_NUMBER&sortMode=DESC&searchPaths=1001299&pageId=1299&templateId=0&navigationId=0&family=mcu&paramTable=no&military=no&ul=TMS470R1VF689&ul=TMS470R1VF67A&ul=TMS470R1VF55BA&ul=TMS470R1VF4B8&ul=TMS470R1VF48C&ul=TMS470R1VF478&ul=TMS470R1VF45BA&ul=TMS470R1VF45AA&ul=TMS470R1VF448&ul=TMS470R1VF356&&uiTemplateId=PT-GSA&techFamId=null&sectionId=95&tabId=1930&appId=null&viewDeviceCallingPage=null#rt Texas Instruments TMS470 automotive ARM7 Übersicht]

[http://www.micronas.com/products/by_function/cdc_3207g/related_products/index.html Micronas ARM7-Controller]

[http://www.luminarymicro.com/products/product_selector_guide.html Luminary Micro ARM Cortex-M3 Selector Guide]

[[Kategorie:ARM]]

230V Schalter und Dimmer

2008-04-11T14:29:43Z

84.156.75.65: formatfix

==Warnung, Lebensgefahr!==

230V aus der Steckdose können tödlich sein!
http://de.wikipedia.org/wiki/Stromunfall

http://de.wikipedia.org/wiki/Stromnetz
http://de.wikipedia.org/wiki/Wechselstrom

==Relais==
Schalten ist elektromechanisch mit einem

http://de.wikipedia.org/wiki/Relais

einfach möglich. Ein Relais ist eine induktive Last. Freilaufdiode benutzen!

==Halbleiterbauelemente==
Es geht aber auch mit Halbleitern.
Z.B. indem man die gleichgerichtete Spannung mit einem FET kurzschließt, wie in diesem Bausatz von ELV (Phasenabschnittsdimmer DI 300):

www.elv-downloads.de/service/manuals/DI300/37378-DI300.pdf

Man kann aber auch Wechselspannung direkt mit einem Halbleiterbauelement schalten, dem Thyristor.

http://de.wikipedia.org/wiki/Thyristor

Verwandt sind DIAC

http://de.wikipedia.org/wiki/Diac

und

===TRIAC===

http://de.wikipedia.org/wiki/Triac

Ein Triac ist eine steuerbare Wechselspannungsdiode, die im Nulldurchgang der Wechselspannung von selbst sperrend wird.

Das Ding kann man super als Wechselspannungsschalter einsetzen, es gibt aber einiges zu berücksichtigen.

Der Triac muss immer im Nulldurchgang wieder eingeschaltet ("gezündet") werden, da er von selbst sperrt (Nulldurchgangserkennung / Zero-crossing detection, ZD). Andernfalls schneidet man die Phase an, was z.B. in Dimmern gewünscht ist.

Bauteile heißen z.B.

TIC 2xyz

xy: ??
z: Spannungsfestigkeit D 400V, M 600V, S 700V, N 800V

===OPTOTRIAC===
* http://www.mikrocontroller.net/articles/Optokoppler
Die sind dafür gemacht, den Triac galvanisch getrennt zu zünden. Teilweise ist dort auch die Nulldurchgangserkennung integriert, d.h. es kann einfach mit einem Pin vom µC geschaltet werden.

* MOC302x Typen ohne Nulldurchgangserkennung
* MOC304x Typen mit Nulldurchgangserkennung
letzte Ziffer x:
Sie unterscheiden sich in I_FT (LED Trigger Current, Current Required to Latch Output). Größeres x, kleinerer Strom.

Preis ca. 0,50 Euro.

===Solid-State-Relais===

Sog. Solid-State-Relais bzw. Halbleiterrelais kombinieren Triac, Optotriac und ggf. Nulldurchgangserkennung (ZD) sowie Schutzschaltung (Snubber) in kompakten Modulen (3-8 Euro)

==Nulldurchgangserkennung==

==Triac-Schutzschaltung==

* http://www.mikrocontroller.net/articles/Snubber, Häufig auch im Datenblatt erwähnt.

==Triac und Kondensatornetzteil==

Man benötigt nicht unbeding einen Optotriac, um den Triac zu zünden. Speziell wenn die galvanische Trennung durch Einsatz eine Kondensatornetzteil ohnehin aus Sicherheitsgründen überflüssig ist, kann ein Triac auch direkt angesteuert werden..

==Dimmen==

Ist nicht so einfach wie z.B. das Dimmen einer Last an Gleichspannung durch Pulsweitenmodulation (PWM).

Besonders beim Dimmen werden Störungen erzeugt, die gefiltert werden müssen.

Trafos lassen sich nur dimmen, wenn man den Strom misst.

Elektronische Trafos lassen sich nur mit Phasenabschnittsteuerung dimmen.

http://de.wikipedia.org/wiki/Phasenanschnittsteuerung
===PhasenANschnitt===
====Entstören====
===PhasenABschnitt===

==Forensuche==

* http://www.mikrocontroller.net/search

==Informative Dokumente==
* http://www.mikrocontroller.net/topic/66703
* Triac enstören, Triac vs. MosFET vs. IGBT: http://www.mikrocontroller.net/topic/20368
* http://www.mikrocontroller.net/articles/I2C-Schaltmodul
* http://www.nxp.com/acrobat_download/applicationnotes/APPCHP6.pdf

Bsp software Pulsuhr

2008-04-11T14:24:55Z

84.156.75.65: formatfix

:->[[Pulsuhrempfänger mit AVR Butterfly]]
;Source Code
<c>
/*

*/
char PROG_NAME[] = "Handy Board HRM ";
char PROG_DATE[] = "29-Jan-2003";

/*
Handy Board HRM was created to demonstrate how to
interface my HRM receiver circuit to a microcontroller.
This code requires the receiver to be connected to the
Handy Board's analog port 0. The algorithm used is
simplistic, but is sufficient to show how to detect the
transmitted heart beat signal and calculate a heart
rate. There are, however, some important limitations
to the algorithm and the code implementing it. Here
are some particular limitations you should be aware of
and some experiments you might try to better understand
their consequences:

1) Heart beats are detected with a simple fixed
trigger level. Consequently, magnetic noise in the
environment can cause erroneously high heart rates
to be calculated. Try this experiment, hold the
HRM receiver up to a computer CRT or even up close
to the Handy Board's own LCD. What happens to the
displayed heart rate? Try changing the DEAD_TIME
parameter in the code, now what heart rate is
displayed when you hold the HRM receiver up to the
Handy Board LCD?

2) The heart rate is recalculated at each heart
beat, so the displayed heart rate can vary
considerably with each beat. Try this experiment,
watch your heart beat displayed on the Handy Board
LCD as you slowly breath in and out. Is there a
pattern? Set a commercial HRM wrist style receiver
next to the Handy Board, how often is the
commercial unit's display being updated -- what
algorithm does the commercial unit seem to be
using?

3) The magnetic pulses generated by the HRM chest
strap transmitters are fairly short, typically
around 5 milliseconds. Since the algorithm is
implemented in a fairly high level language, the
code loop which waits for the next heart beat to be
triggered must be carefully crafted to ensure that
it runs fast enough and doesn't miss any beats.
Try this experiment, add some more code to this
loop, say a call to msleep(). What happens? Can
you suggest a way to measure the frequency at which
this loop runs? Can you suggest a better method
for implementing the algorithm?
*/

/*
Algorithm Parameters
*/
int TRIGGER_LEVEL = 80;
long DEAD_TIME = 100L;/* milliseconds */
long MAX_BEAT_WAIT = 5000L;/* milliseconds */

void
main()
{
/*
State Variables
state: 0 -> no signal detected
1 -> 1 heart beat detected
2 -> 2 or more heart beats detected
*/
int state;
long this_time;
long last_time;

/*
Temporary Variables
*/
long wait_time;
int heart_rate;/* beats/minute */

/*
Turn off all system interrupt features,
except LCD printfs.
*/
poke( 0x39, 1 );

/*
Flash the program name and date on the LCD.
*/
printf("%s%s\n", PROG_NAME, PROG_DATE);
msleep(3000L);

/*
Loop forever, waiting for heart beat signals
and updating the LCD.
*/
state = 0;
for (;;) {

/*
Update LCD to display current state.
*/
if (state > 1) {
/*
beats/min
= (60,000 msecs/min) / (msecs/beat)
= (30,000 msecs/min) / ((msecs/beat)/2)
*/
heart_rate =
30000 / ((int)(this_time-last_time)/2);
printf("hr: %d\n", heart_rate);
} else if (state > 0) {
printf("signal found\n");
} else {
printf("no signal\n");
}

/*
Previous this_time becomes last_time.
*/
last_time = this_time;

/*
If we detected a heart beat last time,
delay for DEAD_TIME milliseconds so that
we don't redetect the same beat.
*/
if (state > 0)
for (;;) {
wait_time = mseconds()-last_time;
if (wait_time > DEAD_TIME)
break;
}

/*
Loop for up to MAX_BEAT_WAIT milliseconds
while looking for the next heart beat signal.
*/
for (;;) {

/*
If we detect a heart beat, update the
state variables to show that we got a
beat and break to update LCD.
*/
if (_raw_analog(0) < TRIGGER_LEVEL) {
this_time = mseconds();
if (state < 2)
state++;
break;
}

/*
If we've waited for MAX_BEAT_WAIT
milliseconds, update the state variables
to show we no longer detect a signal
and break to update LCD.
*/
wait_time = mseconds()-last_time;
if (wait_time > MAX_BEAT_WAIT) {
this_time = mseconds();
state = 0;
break;
}
}
}
}
</c>

Bluetooth

2008-04-11T14:22:01Z

84.156.75.65: kat.

== Bluetooth Module ==

{| border="1" cellpadding="2" cellspacing="2" bgcolor="#EFEFEF" class="sortable" id="bluetoothmodule"
|-----
| '''NAME''' || '''HERSTELLER''' || '''KLASSE''' || '''MAX REICHWEITE [m]''' || '''DATENRATE [kbps]''' || '''PROFILE''' || '''ANTENNE INTEGRIERT''' || '''Vss [V]''' || '''PREIS [EUR]+VERSAND''' || '''DATASHEET'''
|-----
|[http://www.reimesch.de/arf32.html ARF32]|| Reimesch || 2 || 15 || 723 || GAP, SDAP, SPP Bluetooth-Standard V1.1
|| Y || 3,3 || 55,00-61,80 || [http://www.reimesch.de/download/arf32_mn.pdf datasheet]
|-----
|[http://www.ezurio.com/products/bism/ TRBLU23]|| EZURIO || 1 || 300 || 300 || GAP, SDAP, SPP Bluetooth 2.0
|| Y || 3,3 || ?? || [http://www.ezurio.com/dl/?id=88 datasheet]
|-----
|[http://www.amber-wireless.de/produkte/bluetooth/index.php BlueNiceCom 3]|| Amber || 2 || 10 || 921 || SPP Bluetooth 1.1
|| Y || 3,3 || [http://www.spoerle.de/ 37,40] || [http://www.amber-wireless.de/pdf/OPC1601_HB.pdf datasheet]
|-----
|[http://www.amber-wireless.de/produkte/bluetooth/index.php BlueNiceCom 4]|| Amber || 2 || 10 || 921 || SPP,GAP,SDAP (DUN, FAX, FTP, HSP, HFP, OPP, SYNC, BIP, BPP) Bluetooth 2.0
|| Y || 3,3 || [http://www.spoerle.de/ 37,40] || [http://www.spoerle.com/binaries/1150190971661-16.pdf datasheet]
|-----
|[http://www.lemosint.com/scripts/bluetooth_promiesd.asp Parani-ESD100]|| SENA || 1 || 100 || 921 || SPP GAP| Bluetooth 1.2
|| Y || 3,3 || 53,25$-62,95$ ||
[http://www.sena.com/download/datasheet/ds_parani_esd.pdf datasheet]
|-----
|[http://www.lemosint.com/scripts/bluetooth_promiesd.asp Parani-ESD200]|| SENA || 2 || 10 || 230? || SPP GAP Bluetooth 1.2
|| Y || 3,3 || 52,95$-63,95$ || [http://www.lemosint.com/bluetooth_specs/Promi-ESD_manual.pdf datasheet]
|-----
|[http://www.lemosint.com/scripts/bluetooth_promiesd_02.asp Parani-ESD-02]|| SENA || 2 || 30 || 230kB? || SPP GAP Bluetooth 1.1
|| Y || 3,3 || ca. 50$ ||
[http://www.lemosint.com/bluetooth_specs/Promi-ESD-02_manual.pdf datasheet]
|-----
|[http://cgi.segor.de/user-cgi-bin/sidestep2.pl?foto=1&Q=WML&M=1 WML-C20]|| Mitsumi || 1 || 100 || 721 || kein SPP..+? Bluetooth 1.1
|| Y || 3,3 || 78,00 || [http://www.mitsumi-components.com/Catalog/hifreq/commun/wml/c20/text01e.pdf datasheet]
|-----
|[http://www.free2move.se/products.shtml F2M03C1]|| Free2Move || 1 || 100 || 721 || SPP..+? Bluetooth 1.1
|| [http://www.datasoft.se/documents/InfoBTOEMBoardC1-ver1.2.pdf N] || 3,3 || 41,00 || [http://www.datasoft.se/documents/DatasheetF2M03C1DSS4.pdf datasheet]
|-----
|[http://www.free2move.se/products.shtml F2M03AC2]|| Free2Move || 2 || 20 || 721 || SPP..+? Bluetooth 1.1
|| Y || 3,3 || 41,00 || [http://www.datasoft.se/documents/DatasheetF2M03AC2DSS4_000.pdf datasheet]
|-----
|[http://www.ecom.panasonic.de/index.cfm?UUID=20D65392D3924DFDAFDBAB3651BF30F5&and_uuid=83EFD98252104F74B01DFCDD23162396&obj_ID=102 PAN1540]|| Panasonic || 2 || 10 || 600 || SPP GAP SDAP Bluetooth 1.2
|| Y || 3,3 || ? || [http://www.ecom.panasonic.de/pdf/102Datasheet.pdf datasheet]
|-----
|BlueCore-2 || http://www.csrsupport.com || 2 || 10 || 721? || SPP ? || Y || 3,3 || eBay: Bluetooth Gamepad ab 13,00 || [http://www.csrsupport.com/download/83/BC212015-ds-001Pj%20BlueCore2-External%20Data%20Sheet%20AUG06.pdf datasheet]
|-----
|[http://www.modulestek.com/BT-Module.php MB-C04 ((bas. auf BlueCore-04 Chip)]|| Modulestek || 2 || ? || 9600bps || SPP Bluetooth 2.0
|| N || 3,3 || ca. 20€ ||
[http://www.modulestek.com/DOC/MB-C04.pdf datasheet]
|-----
|[http://www.modulestek.com/BT-Module.php MB-C041 ((bas. auf BlueCore-04 Chip)]|| Modulestek || 1 || ? || 9600bps || SPP HCI Bluetooth 2.0
|| N || 3,3 || ? ||
[http://www.modulestek.com/DOC/MB-C04.pdf datasheet]
|-----
|}

== Versionen ==

[http://de.wikipedia.org/wiki/Bluetooth Quelle]

Eine Auswahl wichtiger Eigenschaften der bisherigen Bluetooth-Versionen sind:

* '''Bluetooth 1.0 und 1.0B'''
:: enthielt Sicherheitsprobleme durch ''Bluetooth Hardware Device Address Transmission (BD_ADDR)''
:: maximale Datenübertragungsrate von 723,2 kbit/s
* '''Bluetooth 1.1'''
:: Indikator für die Signalstärke hinzugefügt ''Received Signal Strength Indicator (RSSI)''
:: maximale Datenübertragungsrate von 723,2 kbit/s
* '''Bluetooth 1.2'''
:: weniger empfindlich gegen statische Störer (z.B. WLAN) durch ''Adaptive Frequency-Hopping spread spectrum (AFH)''
:: maximale Datenübertragungsrate von 723,2 kbit/s
* '''Bluetooth 2.0'''
:: etwa dreifache Datenübertragungsgeschwindigkeit durch ''Enhanced Data Rate (EDR)'' mit maximal 2,1 Mbit/s

== Bluetooth-Profile ==

[http://de.wikipedia.org/wiki/Bluetooth Quelle]

Daten zwischen Bluetooth Geräten werden durch so genannte Profile ausgetauscht, die für bestimmte Anwendungsbereiche festgelegt sind. Wenn eine Bluetooth Verbindung aufgebaut wird, tauschen die Geräte ihre Profile aus und legen damit fest, welche Dienste sie für die jeweiligen anderen Partner zur Verfügung stellen können und welche Daten oder Befehle sie dazu benötigen. Ein Headset fordert beispielsweise von einem Bluetooth kompatiblen Mobiltelefon einen Audiokanal an und steuert über zusätzliche Datenkanäle die Lautstärkeregelung.

Unten eine Auswahl einiger Profile, die für Bluetooth implementiert sind. Es kommen ständig neue Profile hinzu, da Bluetooth somit sehr flexibel auf neue Geräteanforderungen reagieren kann.

{| border="0" cellpadding="3" cellspacing="1" bgcolor="#EFEFEF"
|-----
| '''ABKÜRZUNG''' || '''BEDEUTUNG''' || '''VERWENDET FÜR'''
|-----
| A2DP || Advanced Audio Distribution Profile || Übermittlung von Audiodaten
|-----
| AVRCP || Audio Video Remote Control Profile || Fernbedienung für Audio/Video
|-----
| BIP || Basic Imaging Profile || Übertragung von Bilddaten
|-----
| BPP || Basic Printing Profile || Drucken
|-----
| CIP || Common ISDN Access Profile || ISDN Verbindungen über CAPI
|-----
| CTP || Cordless Telephony Profile || Schnurlose Telefonie
|-----
| DUN || Dial-up Networking Profile || Internet-Einwahlverbindung
|-----
| ESDP || Extended Service Discovery Profile || Erweiterte Diensteerkennung
|-----
| FAXP || FAX Profile || Faxen
|-----
| FTP || File Transfer Profile || Dateiübertragung
|-----
| GAP || Generic Access Profile || Zugriffsregelung
|-----
| GAVDP || Generic AV Distribution Profile || Übertragung von Audio-/Videodaten
|-----
| GOEP || Generic Object Exchange Profile || Objektaustausch
|-----
| HCRP || Hardcopy Cable Replacement Profile || Druckanwendung
|-----
| HSP || Headset Profile || Sprachausgabe per Headset
|-----
| HFP || Hands Free Profile || Schnurlose Telefonie im Auto
|-----
| HID || Human Interface Device Profile || Eingabe
|-----
| INTP || Intercom Profile || Sprechfunk
|-----
| LAP || LAN Access Profile (nur Version < 1.2) || PPP Netzwerkverbindung
|-----
| OPP || Object Push Profile || Visitenkarten-/Terminaustausch
|-----
| PAN || Personal Area Networking Profile || Netzwerkverbindungen
|-----
| SAP || SIM Access Profile || Zugriff auf SIM-Karte
|-----
| SDAP || Service Discovery Application Profile || Geräteauffindung
|-----
| SPP || Serial Port Profile || Serielle Datenübertragung
|-----
| SYNCH || Synchronisation Profile || Datenabgleich
|-----
|}

== Links ==
* LMX9820 Bluetooth Designer Guide (nicht downloaden->speichern unter) [http://www.iis.ee.ethz.ch/~felber/DataSheets/Bluetooth/LMX9820_bluetooth_designer_guide.pdf LMX9820_bluetooth_designer_guide.pdf]
* Broschüre SmartModules [http://www.baracoda.com/oem/librairie-doc/SmartModules-Datasheet_7.pdf SmartModules ]
* ATMEGA128 Blue Board von Peter Zirngibl [http://clipswitch.de/progs/blue-trx.pdf blue-trx.pdf]
* LMX9820 Bluetooth Serial Port Module [http://www.reimesch.de/download/LMX9820.pdf LMX9820.pdf]
* LMX9820A Datenblat [http://cache.national.com/ds/LM/LMX9820A.pdf LMX9820A.pdf]
* LMX9820 Schaltung [http://www.mikrocontroller.net/attachment.php/383426/LMX9820A_REF_SCH.pdf LMX9820A_REF_SCH]
* C-Kode Schnipsel 1 [http://www.mikrocontroller.net/attachment.php/297268/LMX9820.C LMX9820.C]
* C-Kode Schnipsel 2 [http://www.mikrocontroller.net/attachment.php/331646/BNC+III+-+set+name.txt BNC III - set name.txt]
* BlueNiceComII Handbuch [http://www.amber-wireless.de/pdf/OPC1650_HB.pdf OPC1650_HB.pdf]
* Panasonic BlueRS SPP Manual [http://www.ecom.panasonic.de/pdf/102ext.pdf SPP Manual]

* Blue Nice Module Amber [http://www.mikrocontroller.net/forum/read-1-274425.html#277468 Forum-Link]
* BlueNiceComIII + Ansteuerung [http://www.mikrocontroller.net/forum/read-1-331309.html#331309 Forum-Link]

[[Kategorie:Bauteile]]

Drucksensor

2008-04-11T14:21:06Z

84.156.75.65: kat.

Drucksensoren sind oft in Mikromechanik-Technik auf Siliziumchips ausgeführt.
*Differenzdruck-Sensoren
messen den Druckunterschied zwischen zwei Anschlußstutzen
* Absolutdrucksensoren
messen den Druck im Vergleich zu einem abgeschlossenen Hohlraum

Hersteller:
* Siemens, Philips "KPY..."
* Motorola / SenSym "SX...", "SCX..."
früher auch mal
* National Semiconductor ( Datenbuch 1974 ) "LX..."
Oft findet man Bauanleitungen mit Drucksensoren aus der Kraftfahrzeugelektronik:
* Bosch-Sensoren

Da diese Sensoren sehr temperaturabhängig sind, muß der Temperaturgang kompensiert werden.
Eine kompensierte Schaltung mit einem KP100 von Philips, der auch einen Temperatursensor auf dem Chip enthält, kann Höhenunterschiede von 10 cm im Luftdruck anzeigen. Armbanduhren mit integriertem Drucksensor zeigen die Höhe mit 5m Auflösung an.
Eine weitere Anwendung sind Einbruchsalarmanlagen, die auf die Druckschwankung beim Türöffnen reagieren.
Der Überschallknall der Concorde beim Beschleunigen über dem Atlantik konnte mit empfindlichen Drucksensor-Mikrophonen in Bayern nachgewiesen werden - mit entsprechender Zeitverzögerung.

[[Kategorie:Bauteile]]

AVR-CORDIC

2008-04-11T14:20:35Z

84.156.75.65: kat.

=AVR-Arithmetik mit dem CORDIC-Algorithmus=

Der Cordic-Algorithmus bietet eine ganze Reihe mathematischer Funktionen. Er wird seit den ersten Taschenrechnern bis zu den mathematischen Befehlen der Pentium-Prozessoren oder in FPGAs verwendet.

Hier soll nur die praktische Anwendung in Mikrocontrollern der AVR-Reihe besprochen werden. Er arbeitet iterativ, ähnlich der sukzessiven Approximation in Analog-Digital-Wandlern. Es werden nur Additionen und Schiebeoperationen benötigt.

Es gibt sechs verschiedene CORDIC-Versionen, die für unterschiedliche mathematische Funktionen benutzt werden:

"circular", "linear", "hyperbolic", und diese jeweils "vectoring" oder "rotation".

===circular vectoring===
[http://de.wikipedia.org/wiki/Kartesisches_Koordinatensystem Kartesische] --> [http://de.wikipedia.org/wiki/Polarkoordinaten Polarkoordinaten], [http://de.wikipedia.org/wiki/Arcsin arcsin, arccos], [http://de.wikipedia.org/wiki/Arctan arctan, arccot]

===circular rotation===
[http://de.wikipedia.org/wiki/Polarkoordinaten Polare] --> [http://de.wikipedia.org/wiki/Kartesisches_Koordinatensystem Kartesische Koordinaten], [http://de.wikipedia.org/wiki/Sinus sin, cos], [http://de.wikipedia.org/wiki/Tangens tan, cot]

Der CORDIC kann so auch als Alternative zum [http://www.mikrocontroller.net/articles/DDS DDS] Sinusgenerator verwendet werden. Er braucht keine Tabelle, daher ist eine höhere Amplitudenauflösung von z.B. 16 Bit möglich. Es entsteht gleichzeitig eine Sinus- und Cosinusschwingung.

===linear vectoring===
Division y/x

===linear rotation===
Multiplikation y*x

===hyperbolic vectoring===
[http://de.wikipedia.org/wiki/Arsinh arsinh, arcosh], [http://de.wikipedia.org/wiki/Artanh artanh, arcoth], [http://de.wikipedia.org/wiki/Logarithmus#Natürlicher_Logarithmus_und_andere_spezielle_Logarithmen ln], [http://de.wikipedia.org/wiki/Dekadischer_Logarithmus log10], [http://de.wikipedia.org/wiki/Quadratwurzel Quadratwurzel]

===hyperbolic rotation===
[http://de.wikipedia.org/wiki/Sinh sinh, cosh], [http://de.wikipedia.org/wiki/Tanh tanh, coth], [http://de.wikipedia.org/wiki/Exponentialfunktion e-Funktion]
==Die avrfix - Festkommabibliothek==
Entstand im Rahmen einer Baccalaureus-Arbeit an der TU Wien und ist auf [https://sourceforge.net/projects/avrfix/ Sourceforge] frei verfügbar.
Sie bietet neben den Grundrechenarten und einigen Hilfsroutinen zur Rundung und Überlaufbehandlung vor allem zwei CORDIC - Routinen, siehe [http://mesh.dl.sourceforge.net/sourceforge/avrfix/avrfix.pdf Handbuch avrlib.pdf Seite 126]:
* "CORDICCK" circular
* "CORDICHK" hyperbolic
der lineare Modus ist nicht vorhanden.

Mit dem Parameter "mode" wird die Transformationsrichtung übergeben:
* mode = 0 entspricht rotation
* mode = 1 entspricht vectoring

Mit dem Parameter "iterations" wird einer von zwei möglichen 32-Bit Festkomma-Datentypen ausgewählt:
* _Akkum hat 1 Vorzeichenbit, 15 Vorkomma- und 16 Nachkommabits, iterations=16
* _lAkkum hat 1 Vorzeichenbit, 7 Vorkomma- und 24 Nachkommabits, iterations=24

==CORDIC im Diskussionsforum==
*[http://www.mikrocontroller.net/topic/58111 "echter" double mit AVR-GCC]
*[http://www.mikrocontroller.net/topic/39891 Cordic-Algorithmus, FPGA]
*[http://www.mikrocontroller.net/topic/69575 CORDIC-Core Xilinx]
*[http://www.mikrocontroller.net/topic/69573 Mischung mit sin/cos in VHDL]
*[http://www.mikrocontroller.net/topic/84685 Genauigkeitsproblem, FFT im FPGA]
*[http://www.mikrocontroller.net/topic/88563 Wurzel mit Cordic auf Spartan3E]

==Bücher & Artikel==
* DSP with FPGAs U.Meyer-Baese Kap.2.8 ISBN 3-540-21119-5
* [http://www.ddj.com/184408428 Implementing Cordic Algorithms] by Pitts Jarvis, DDJ Oktober 01, 1990
* [http://www.ddj.com/cpp/184402614 The CORDIC Method for Faster sin and cos Calculations] by Michael Bertrand, DDJ November 01, 1992
* [http://www.ddj.com/184404244 Microcontrollers & CORDIC Methods] by Michael Pashea, DDJ September 01, 2000
* [http://www.ddj.com/embedded/193300128 Implementing Matrix Inversions in Fixed-point Hardware] by Ramon Uribe and Tom Cesear, DDJ Oktober 12, 2006
* [http://www.ddj.com/architect/196700769 Software Implementation of Trigonometric Functions Using CORDIC Algorithm] by Christober Rayappan, DDJ Dezember 19, 2006

==Weblinks==
*[http://de.wikipedia.org/wiki/CORDIC Wikipedia zu Cordic, dort weitere Links]
*[http://www.jacques-laporte.org/digit_by_digit.htm Historisches, u.a. Originalliteratur ab 1959 als PDF]
*[http://avrfix.sourceforge.net/ avrfix Festkommabibliothek für AVR in C] und [https://sourceforge.net/projects/avrfix/ Downloadseite]
*[http://www.andreadrian.de/oldcpu/Z80_number_cruncher.html CORDIC sin/cos in C und Z80-Assembler]
*[http://www.restena.lu/convict/Jeunes/Math/Fast_operations2.htm schnelle Division mit CORDIC in PIC-Assembler]
*[http://www.ddj.com/184408428 CORDIC-C-Routinen aus Dr.Dobbs Journal 1990] und hier [http://people.csail.mit.edu/hqm/imode/fplib/cordic_code.html Converted to ANSI-C]
*[http://www.emesys.com/BS2mathC.htm Cordic sin/cos und kart./polar auf Basic-Stamp]
*[http://www.restena.lu/convict/Jeunes/Math/arctan.htm CORDIC-Arcustangens für Lego/Renesas H8]
*[http://www.xilinx.com/bvdocs/ipcenter/data_sheet/cordic.pdf Xilinx Cordic IP-Block mit ausführlicher Beschreibung]

[[Kategorie:AVR]]

6502

2008-04-11T14:19:27Z

84.156.75.65: kat.

Der 6502 - Prozessor war einer der ersten Prozessoren, die in Heimcomputern verwendet wurden, und existiert seit dem Jahr 1976 (?)

Er wurde eingesetzt in:
* KIM-1 (MOS technology)
* AIM-65 (Rockwell)
* EMUF Einplatinencomputer mit universeller Festprogrammierung mit 6504 (Franzis-Verlag "mc")
* Elektor Junior Computer
* Apple II
* Commodore PET und folgende
* Atari 400 /800
* Atari 2600
* Atari 7800
* Nintendo Entertainment System - beste Spielekonsole aller Zeiten

auch der Prozessor im VIC20 und C64 gehört zur 6502-Familie.

Es gibt heute noch Mikrocontroller mit 6502 Kern.

[[Kategorie:Mikrocontroller]]

ADuC7xxx

2008-04-11T14:18:07Z

84.156.75.65: kat.

Analog Devices ARM7TDMI-based Precision Analog Microconverters

Besonderheiten:
* 12-Bit 1 MSPS Analog-Digital/Digital-Analog-Wandler
* Einige mit 12-Bit Digital-Analog-Wandler
* Programmable Logic Array (PLA)
* Teilweise nur 32 kHz Quarz als Takteingang notwendig (per PLL auf bis zu 45 MHz)
* Serieller Bootloader oder I²C-Bootloader vorprogrammiert
* (Zumindest einige) ohne Interrupt-Controller (kein AIC oder VIC)

Gemacht für Embedded Sensor-/Control-Loop-, oder bei den größeren Derivaten mit 3-Phasen PWM, für Motor-Control-Applikationen.

Von ADI gibt es eine recht brauchbare Sammlung an [ftp://ftp.analog.com/pub/www/technology/dataConverters/microconverter/source_code.zip Beispielcode] in C (wird auf der Website (11/2006) irrtümlich als Assembler-Code ausgewiesen). Der Beispielcode ist auch für die GNU-Toolchain vorbereitet.

== Siehe auch ==
* [[Linksammlung#ARM|Linksammlung Abschnitt ARM]]

== Weblinks ==
* [http://www.analog.com/en/content/0,2886,762%255F%252D1%255F31068,00.html Analog Devices ADUC7000-Series "Homepage"]

* [http://tech.groups.yahoo.com/group/lpc21isp/ lpc21isp] "Multiplattform" Programmiersoftware für den seriellen Bootloader

[[Kategorie:Bauteile]]

ARM-MP3-Player

2008-04-11T14:17:22Z

84.156.75.65: kat.

von [[Benutzer:Andreas]]

Jeder Mikrocontroller-Bastler der was auf sich hält baut irgend wann mal einen [[MP3]]-Player. Das hier ist meiner.

'''Diese Seite ist veraltet! Eine ausführlichere Beschreibung (auf Englisch) gibt es auf der Seite [[ARM MP3/AAC Player]]'''.

== Status (28.05.06) ==

* [http://shop.mikrocontroller.net/ AT91SAM7S64-Dev-Board], SAM7S64 gegen SAM7S256 ausgetauscht
* MP3- und AAC-Decoder: https://datatype.helixcommunity.org/
* Datenspeicher: SD-Karte, Ansteuerung über die FAT-Bibliothek von http://elm-chan.org/fsw/ff/00index_e.html
* DAC: CS4331 (auf MP3-Player-Platine "Pump" aus der c't), Fütterung über SSC mit DMA
* [http://www.mikrocontroller.net/attachment.php/343708/IMG_3779.JPG Bild des Hardwareaufbaus]
* Abspielen von WAV-, MP3- und AAC-Dateien (im ADTS-Format) von SD-Karte funktioniert einwandfrei
* VBR-MP3 mit durchschnittlich 195 kbit/s (128-320) problemlos abspielbar
* AAC über ca. 140 kBit/s mit Aussetzern, sollte kein Problem mehr sein wenn das Verhältnis CPU-Takt/Samplerate etwas erhöht wird (sobald der TLV320-DAC dran ist)

=== Noch zu tun ===

* ID3v2-Tags auslesen
* Playlists (m3u)
* neuen DAC einbauen
* OLED-Display anschließen
* AAC im MP4-Container abspielen

== Überlegungen zum DA-Wandler ==

=== Taktversorgung ===

Soll-Werte:
* Samplerate (word clock, LRCLK): <math>f_s = 44\,100 \mathrm{Hz}</math>
* Bittakt: <math>f_b = f_s \cdot 2 \cdot 16 = 1\,411\,200 \mathrm{Hz}</math>

Samplerate und Bittakt werden normalerweise synchron vom I2S-Interface erzeugt.

* Master-Clock (MCLK): Fast alle DACs benötigen zusätzlich einen Takt mit dem 256-fachen der Samplerate, der exakt synchron zu den anderen Takten sein muss. In diesem Fall kann der DAC den Bittakt aus MCLK und LRCLK intern selbst erzeugen, so dass man den Bittakt nicht anzuschließen braucht.

Um halbwegs zur üblichen Samplerate passende Takte zu erzeugen muss der Controller mit einer "krummen" Frequenz laufen (z.B. MCLK * 4 = 45.16 MHz). Das sollte sich mit der PLL hinbekommen lassen.

Eine bessere Alternative sind DACs die intern einen sinnvollen Takt erzeugen und ausgeben können, so dass man das SSC peripheral des Controllers damit betreiben kann. Der Vorteil ist dass der Controller mit einer beliebigen Frequenz laufen kann.

=== Erster Prototyp: CS4331 ===

Für den ersten Prototypen verwende ich einen CS4331. Hier wird der PWM-Controller für die MCLK-Erzeugung verwendet, SCLK wird vom Wandler intern aus MLCK und LRCLK abgeleitet (siehe "Taktversorgung").

[[Bild:ARM-MP3-Blockschaltbild.png]]

Der Prozessortakt ist hier auf 48.05 MHz eingestellt. Geteilt durch 4 gibt das einen etwas unpassenden Wert für den DAC (Soll: 256 * 44.1 kHz = 11.29 MHz, Ist: 12 MHz), somit hört sich alles etwas zu hoch an.

Code zur Initialisierung:

<c>
/************ PWM ***********/
/* PWM0 = MAINCK/4 */
*AT91C_PMC_PCER = (1 << AT91C_ID_PWMC); // Enable Clock for PWM controller
*AT91C_PWMC_CH0_CPRDR = 2; // channel period = 2
*AT91C_PWMC_CH0_CMR = 1; // prescaler = 2
pPIO->PIO_PDR = AT91C_PA0_PWM0; // enable pin
*AT91C_PWMC_CH0_CUPDR = 1;
*AT91C_PWMC_ENA = AT91C_PWMC_CHID0; // enable channel 0 output

/************ SSC ***********/
*AT91C_PMC_PCER = (1 << AT91C_ID_SSC); // Enable Clock for SSC controller
*AT91C_SSC_CR = AT91C_SSC_SWRST; // reset
*AT91C_SSC_CMR = 16;
*AT91C_SSC_TCMR = AT91C_SSC_CKS_DIV | AT91C_SSC_CKO_CONTINOUS |
AT91C_SSC_START_FALL_RF |
(1 << 16) | // STTDLY = 1
(15 << 24); // PERIOD = 15
pPIO->PIO_PDR = AT91C_PA16_TK | AT91C_PA15_TF | AT91C_PA17_TD; // enable pins
*AT91C_SSC_TFMR = (15) | // 16 bit word length
(1 << 8) | // DATNB = 1 => 2 words per frame
(15 << 16) | // FSLEN = 15
AT91C_SSC_MSBF | AT91C_SSC_FSOS_NEGATIVE;
*AT91C_SSC_CR = AT91C_SSC_TXEN; // enable TX
</c>

Fazit: CS4331 ist brauchbar zum Testen, mehr nicht.

=== Zweite Version: TLV320AIC23BPW ===

Geplant ist den TLV320AIC23BPW erst mal mit einer [[IC-Gehäuseformen#Adapterplatinen für SMD-ICs|Adapterplatine]] ans SAM7-Board anzuschließen.

=== Auflistung interessanter DACs ===

==== TLV320AIC23B ====

* http://focus.ti.com/docs/prod/folders/print/tlv320aic23b.html
* Kopfhörer-Verstärker
* Line- und Mikrofoneingang
* 28 TSSOP
* läuft auch mit 12 MHz
* gibt's bei Digikey
* -> perfekt!

==== MAX9850 ====
* 28 PIN (aber nur im bastlerunfreundlichen TQFN-Package erhältlich!)
* mit Kopfhörer-Amp. u.a.
* Keine großen Entkoppelkondensatoren notwendig
* relativ aufwendige Beschaltung und Konfiguration
* auch krumme MCLK erlaubt:
* Anforderung im Integer mode: Takt ganzzahliges Vielfaches der 16fachen Samplerate => nur bei PLL-Multiplikator von 4 möglich
* Anforderung im Noninteger mode: Takt fast beliebig, somit 44.1 kHz kein Problem, auch mit 18.432 MHz-Quarz
* nur als Sample beschaffbar? -> scheidet aus

==== Wolfson WM8727 ====

http://www.wolfson.co.uk/products/digital_audio/dacs/WM8727/

* 8-pin SOIC
* keine Konfiguration
* nicht sehr weit verbreitet

==== CS4331 ====

http://joule.bu.edu/~hazen/DataSheets/Cirrus_Crystal/4330.pdf

* 8 pin SOIC
* keine Konfiguration
* nicht mehr hergestellt

==== CS4334 ====

* 8-pin SOIC
* keine Konfiguration
* nur 5V-Betrieb

==== WM8731 ====

* The WM8731 is a very low power, high quality audio codec with integrated headphone driver, designed for portable digital audio applications.
* Integrierte PLL-Takterzeugung aus z.B. 12 MHz
* Aufnahmefunktion möglich
* Mikro-Vorverstärker und Kopfhörer-Verstärker eingebaut
* Nur in 100er-Stückzahlen erhältlich -> scheidet aus

==== TDA1543 ====

* kein MCLK nötig
* DIP-8
* gibt's bei Segor für 2 Euro, bei Reichelt für 0,75 Euro
* qualitätsmäßig eher Low-End
* -> perfekt zum Testen!
* Datenblatt: http://www.docethifi.com/TDA1543_.PDF

[[Kategorie:Projekte]]

Beispiel Makefile

2008-04-11T14:16:43Z

84.156.75.65: kat.

= Beispiel-Makefile =

== Allgemeines ==
makefiles sind Steuerdateien für ein Programm, das "make" "/bin/make" oder make.exe heißt. Mit dem WinAVR kommt C:\WINAVR\utils\bin\make.exe

Um ein Makefile zu benutzen, muss man in dem Verzeichnis, in dem sich das makefile befindet, "make" aufrufen. Wenn man das von der DOS-Box aus tut, dann sieht man auch die Fehlerausgaben.

== Beispiel 1 ==

Dies ist ein Beispiel-Makefile für Programmieranfänger:

*AVR: Mega16
*Programmer: Pony-Stk200
*CPU-Frequenz: 1 Mhz
*C-Datei: main.c

Hier gibt es das Beispiel-Makefile zum [[Media:makefile | Herunterladen]].

<div class="code"><pre>
# Hey Emacs, this is a -*- makefile -*-
#----------------------------------------------------------------------------
# WinAVR Makefile Template written by Eric B. Weddington, Jörg Wunsch, et al.
#
# Released to the Public Domain
#
# Additional material for this makefile was written by:
# Peter Fleury
# Tim Henigan
# Colin O'Flynn
# Reiner Patommel
# Markus Pfaff
# Sander Pool
# Frederik Rouleau
# Carlos Lamas
#
#----------------------------------------------------------------------------
# On command line:
#
# make all = Make software.
#
# make clean = Clean out built project files.
#
# make coff = Convert ELF to AVR COFF.
#
# make extcoff = Convert ELF to AVR Extended COFF.
#
# make program = Download the hex file to the device, using avrdude.
# Please customize the avrdude settings below first!
#
# make debug = Start either simulavr or avarice as specified for debugging,
# with avr-gdb or avr-insight as the front end for debugging.
#
# make filename.s = Just compile filename.c into the assembler code only.
#
# make filename.i = Create a preprocessed source file for use in submitting
# bug reports to the GCC project.
#
# To rebuild project do "make clean" then "make all".
#----------------------------------------------------------------------------

# MCU name
MCU = atmega16

# Processor frequency.
# This will define a symbol, F_CPU, in all source code files equal to the
# processor frequency. You can then use this symbol in your source code to
# calculate timings. Do NOT tack on a 'UL' at the end, this will be done
# automatically to create a 32-bit value in your source code.
# Typical values are:
F_CPU = 1000000
# F_CPU = 1843200
# F_CPU = 2000000
# F_CPU = 3686400
# F_CPU = 4000000
# F_CPU = 7372800
# F_CPU = 8000000
# F_CPU = 11059200
# F_CPU = 14745600
# F_CPU = 16000000
# F_CPU = 18432000
# F_CPU = 20000000
# F_CPU = 8000000

# Output format. (can be srec, ihex, binary)
FORMAT = ihex

# Target file name (without extension).
TARGET = main

# Object files directory
OBJDIR = obj

# List C source files here. (C dependencies are automatically generated.)
SRC = $(TARGET).c

# List C++ source files here. (C dependencies are automatically generated.)
CPPSRC =

# List Assembler source files here.
# Make them always end in a capital .S. Files ending in a lowercase .s
# will not be considered source files but generated files (assembler
# output from the compiler), and will be deleted upon "make clean"!
# Even though the DOS/Win* filesystem matches both .s and .S the same,
# it will preserve the spelling of the filenames, and gcc itself does
# care about how the name is spelled on its command-line.
ASRC =

# Optimization level, can be [0, 1, 2, 3, s].
# 0 = turn off optimization. s = optimize for size.
# (Note: 3 is not always the best optimization level. See avr-libc FAQ.)
OPT = s

# Debugging format.
# Native formats for AVR-GCC's -g are dwarf-2 [default] or stabs.
# AVR Studio 4.10 requires dwarf-2.
# AVR [Extended] COFF format requires stabs, plus an avr-objcopy run.
DEBUG = dwarf-2

# List any extra directories to look for include files here.
# Each directory must be seperated by a space.
# Use forward slashes for directory separators.
# For a directory that has spaces, enclose it in quotes.
EXTRAINCDIRS =

# Compiler flag to set the C Standard level.
# c89 = "ANSI" C
# gnu89 = c89 plus GCC extensions
# c99 = ISO C99 standard (not yet fully implemented)
# gnu99 = c99 plus GCC extensions
CSTANDARD = -std=gnu99

# Place -D or -U options here for C sources
CDEFS = -DF_CPU=$(F_CPU)UL

# Place -D or -U options here for C++ sources
CPPDEFS = -DF_CPU=$(F_CPU)UL
#CPPDEFS += -D__STDC_LIMIT_MACROS
#CPPDEFS += -D__STDC_CONSTANT_MACROS

#---------------- Compiler Options C ----------------
# -g*: generate debugging information
# -O*: optimization level
# -f...: tuning, see GCC manual and avr-libc documentation
# -Wall...: warning level
# -Wa,...: tell GCC to pass this to the assembler.
# -adhlns...: create assembler listing
CFLAGS = -g$(DEBUG)
CFLAGS += $(CDEFS)
CFLAGS += -O$(OPT)
#CFLAGS += -mint8
#CFLAGS += -mshort-calls
CFLAGS += -funsigned-char
CFLAGS += -funsigned-bitfields
CFLAGS += -fpack-struct
CFLAGS += -fshort-enums
#CFLAGS += -fno-unit-at-a-time
CFLAGS += -Wall
CFLAGS += -Wstrict-prototypes
CFLAGS += -Wundef
#CFLAGS += -Wunreachable-code
#CFLAGS += -Wsign-compare
CFLAGS += -Wa,-adhlns=$(<:%.c=$(OBJDIR)/%.lst)
CFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS))
CFLAGS += $(CSTANDARD)

#---------------- Compiler Options C++ ----------------
# -g*: generate debugging information
# -O*: optimization level
# -f...: tuning, see GCC manual and avr-libc documentation
# -Wall...: warning level
# -Wa,...: tell GCC to pass this to the assembler.
# -adhlns...: create assembler listing
CPPFLAGS = -g$(DEBUG)
CPPFLAGS += $(CPPDEFS)
CPPFLAGS += -O$(OPT)
#CPPFLAGS += -mint8
#CPPFLAGS += -mshort-calls
CPPFLAGS += -funsigned-char
CPPFLAGS += -funsigned-bitfields
CPPFLAGS += -fpack-struct
CPPFLAGS += -fshort-enums
CPPFLAGS += -fno-exceptions
#CPPFLAGS += -fno-unit-at-a-time
CPPFLAGS += -Wall
#CPPFLAGS += -Wstrict-prototypes
CFLAGS += -Wundef
#CPPFLAGS += -Wunreachable-code
#CPPFLAGS += -Wsign-compare
CPPFLAGS += -Wa,-adhlns=$(<:%.cpp=$(OBJDIR)/%.lst)
CPPFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS))
#CPPFLAGS += $(CSTANDARD)

#---------------- Assembler Options ----------------
# -Wa,...: tell GCC to pass this to the assembler.
# -ahlms: create listing
# -gstabs: have the assembler create line number information; note that
# for use in COFF files, additional information about filenames
# and function names needs to be present in the assembler source
# files -- see avr-libc docs [FIXME: not yet described there]
ASFLAGS = -Wa,-adhlns=$(<:%.S=$(OBJDIR)/%.lst),-gstabs

#---------------- Library Options ----------------
# Minimalistic printf version
PRINTF_LIB_MIN = -Wl,-u,vfprintf -lprintf_min

# Floating point printf version (requires MATH_LIB = -lm below)
PRINTF_LIB_FLOAT = -Wl,-u,vfprintf -lprintf_flt

# If this is left blank, then it will use the Standard printf version.
PRINTF_LIB =
#PRINTF_LIB = $(PRINTF_LIB_MIN)
#PRINTF_LIB = $(PRINTF_LIB_FLOAT)

# Minimalistic scanf version
SCANF_LIB_MIN = -Wl,-u,vfscanf -lscanf_min

# Floating point + %[ scanf version (requires MATH_LIB = -lm below)
SCANF_LIB_FLOAT = -Wl,-u,vfscanf -lscanf_flt

# If this is left blank, then it will use the Standard scanf version.
SCANF_LIB =
#SCANF_LIB = $(SCANF_LIB_MIN)
#SCANF_LIB = $(SCANF_LIB_FLOAT)

MATH_LIB = -lm

#---------------- External Memory Options ----------------

# 64 KB of external RAM, starting after internal RAM (ATmega128!),
# used for variables (.data/.bss) and heap (malloc()).
#EXTMEMOPTS = -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff

# 64 KB of external RAM, starting after internal RAM (ATmega128!),
# only used for heap (malloc()).
#EXTMEMOPTS = -Wl,--defsym=__heap_start=0x801100,--defsym=__heap_end=0x80ffff

EXTMEMOPTS =

#---------------- Linker Options ----------------
# -Wl,...: tell GCC to pass this to linker.
# -Map: create map file
# --cref: add cross reference to map file
LDFLAGS = -Wl,-Map=$(TARGET).map,--cref
LDFLAGS += $(EXTMEMOPTS)
LDFLAGS += $(PRINTF_LIB) $(SCANF_LIB) $(MATH_LIB)
#LDFLAGS += -T linker_script.x

#---------------- Programming Options (avrdude) ----------------

# Programming hardware: alf avr910 avrisp bascom bsd
# dt006 pavr picoweb pony-stk200 sp12 stk200 stk500
#
# Type: avrdude -c ?
# to get a full listing.
#
AVRDUDE_PROGRAMMER = pony-stk200

# com1 = serial port. Use lpt1 to connect to parallel port.
AVRDUDE_PORT = lpt1

AVRDUDE_WRITE_FLASH = -U flash:w:$(TARGET).hex
#AVRDUDE_WRITE_EEPROM = -U eeprom:w:$(TARGET).eep

# Uncomment the following if you want avrdude's erase cycle counter.
# Note that this counter needs to be initialized first using -Yn,
# see avrdude manual.
#AVRDUDE_ERASE_COUNTER = -y

# Uncomment the following if you do /not/ wish a verification to be
# performed after programming the device.
#AVRDUDE_NO_VERIFY = -V

# Increase verbosity level. Please use this when submitting bug
# reports about avrdude. See <http://savannah.nongnu.org/projects/avrdude>
# to submit bug reports.
#AVRDUDE_VERBOSE = -v -v

AVRDUDE_FLAGS = -p $(MCU) -P $(AVRDUDE_PORT) -c $(AVRDUDE_PROGRAMMER)
AVRDUDE_FLAGS += $(AVRDUDE_NO_VERIFY)
AVRDUDE_FLAGS += $(AVRDUDE_VERBOSE)
AVRDUDE_FLAGS += $(AVRDUDE_ERASE_COUNTER)

#---------------- Debugging Options ----------------

# For simulavr only - target MCU frequency.
DEBUG_MFREQ = $(F_CPU)

# Set the DEBUG_UI to either gdb or insight.
DEBUG_UI = gdb
# DEBUG_UI = insight

# Set the debugging back-end to either avarice, simulavr.
#DEBUG_BACKEND = avarice
DEBUG_BACKEND = simulavr

# GDB Init Filename.
GDBINIT_FILE = __avr_gdbinit

# When using avarice settings for the JTAG
JTAG_DEV = /dev/com1

# Debugging port used to communicate between GDB / avarice / simulavr.
DEBUG_PORT = 4242

# Debugging host used to communicate between GDB / avarice / simulavr, normally
# just set to localhost unless doing some sort of crazy debugging when
# avarice is running on a different computer.
DEBUG_HOST = localhost

#============================================================================

# Define programs and commands.
SHELL = sh
CC = avr-gcc
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump
SIZE = avr-size
NM = avr-nm
AVRDUDE = avrdude
REMOVE = rm -f
REMOVEDIR = rm -rf
COPY = cp
WINSHELL = cmd

# Define Messages
# English
MSG_ERRORS_NONE = Errors: none
MSG_BEGIN = -------- begin --------
MSG_END = -------- end --------
MSG_SIZE_BEFORE = Size before:
MSG_SIZE_AFTER = Size after:
MSG_COFF = Converting to AVR COFF:
MSG_EXTENDED_COFF = Converting to AVR Extended COFF:
MSG_FLASH = Creating load file for Flash:
MSG_EEPROM = Creating load file for EEPROM:
MSG_EXTENDED_LISTING = Creating Extended Listing:
MSG_SYMBOL_TABLE = Creating Symbol Table:
MSG_LINKING = Linking:
MSG_COMPILING = Compiling C:
MSG_COMPILING_CPP = Compiling C++:
MSG_ASSEMBLING = Assembling:
MSG_CLEANING = Cleaning project:
MSG_CREATING_LIBRARY = Creating library:

# Define all object files.
OBJ = $(SRC:%.c=$(OBJDIR)/%.o) $(CPPSRC:%.cpp=$(OBJDIR)/%.o) $(ASRC:%.S=$(OBJDIR)/%.o)

# Define all listing files.
LST = $(SRC:%.c=$(OBJDIR)/%.lst) $(CPPSRC:%.cpp=$(OBJDIR)/%.lst) $(ASRC:%.S=$(OBJDIR)/%.lst)

# Compiler flags to generate dependency files.
GENDEPFLAGS = -MD -MP -MF .dep/$(@F).d

# Combine all necessary flags and optional flags.
# Add target processor to flags.
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)

# Default target.
all: begin gccversion sizebefore build sizeafter end

# Change the build target to build a HEX file or a library.
build: elf hex eep lss sym
#build: lib

elf: $(TARGET).elf
hex: $(TARGET).hex
eep: $(TARGET).eep
lss: $(TARGET).lss
sym: $(TARGET).sym
LIBNAME=lib$(TARGET).a
lib: $(LIBNAME)

# Eye candy.
# AVR Studio 3.x does not check make's exit code but relies on
# the following magic strings to be generated by the compile job.

begin:
@echo
@echo $(MSG_BEGIN)

end:
@echo $(MSG_END)
@echo

# Display size of file.
HEXSIZE = $(SIZE) --target=$(FORMAT) $(TARGET).hex
ELFSIZE = $(SIZE) -A $(TARGET).elf
AVRMEM = avr-mem.sh $(TARGET).elf $(MCU)

sizebefore:
@if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_BEFORE); $(ELFSIZE); \
$(AVRMEM) 2>/dev/null; echo; fi

sizeafter:
@if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_AFTER); $(ELFSIZE); \
$(AVRMEM) 2>/dev/null; echo; fi

# Display compiler version information.
gccversion :
@$(CC) --version

# Program the device.
program: $(TARGET).hex $(TARGET).eep
$(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH)
$(AVRDUDE_WRITE_EEPROM)

# Generate avr-gdb config/init file which does the following:
# define the reset signal, load the target file, connect to target, and set
# a breakpoint at main().
gdb-config:
@$(REMOVE) $(GDBINIT_FILE)
@echo define reset >> $(GDBINIT_FILE)
@echo SIGNAL SIGHUP >> $(GDBINIT_FILE)
@echo end >> $(GDBINIT_FILE)
@echo file $(TARGET).elf >> $(GDBINIT_FILE)
@echo target remote $(DEBUG_HOST):$(DEBUG_PORT) >> $(GDBINIT_FILE)
ifeq ($(DEBUG_BACKEND),simulavr)
@echo load >> $(GDBINIT_FILE)
endif
@echo break main >> $(GDBINIT_FILE)

debug: gdb-config $(TARGET).elf
ifeq ($(DEBUG_BACKEND), avarice)
@echo Starting AVaRICE - Press enter when "waiting to connect" message displays.
@$(WINSHELL) /c start avarice --jtag $(JTAG_DEV) --erase --program --file \
$(TARGET).elf $(DEBUG_HOST):$(DEBUG_PORT)
@$(WINSHELL) /c pause

else
@$(WINSHELL) /c start simulavr --gdbserver --device $(MCU) --clock-freq \
$(DEBUG_MFREQ) --port $(DEBUG_PORT)
endif
@$(WINSHELL) /c start avr-$(DEBUG_UI) --command=$(GDBINIT_FILE)

# Convert ELF to COFF for use in debugging / simulating in AVR Studio or VMLAB.
COFFCONVERT = $(OBJCOPY) --debugging
COFFCONVERT += --change-section-address .data-0x800000
COFFCONVERT += --change-section-address .bss-0x800000
COFFCONVERT += --change-section-address .noinit-0x800000
COFFCONVERT += --change-section-address .eeprom-0x810000

coff: $(TARGET).elf
@echo
@echo $(MSG_COFF) $(TARGET).cof
$(COFFCONVERT) -O coff-avr $< $(TARGET).cof

extcoff: $(TARGET).elf
@echo
@echo $(MSG_EXTENDED_COFF) $(TARGET).cof
$(COFFCONVERT) -O coff-ext-avr $< $(TARGET).cof

# Create final output files (.hex, .eep) from ELF output file.
%.hex: %.elf
@echo
@echo $(MSG_FLASH) $@
$(OBJCOPY) -O $(FORMAT) -R .eeprom $< $@

%.eep: %.elf
@echo
@echo $(MSG_EEPROM) $@
-$(OBJCOPY) -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O $(FORMAT) $< $@

# Create extended listing file from ELF output file.
%.lss: %.elf
@echo
@echo $(MSG_EXTENDED_LISTING) $@
$(OBJDUMP) -h -S $< > $@

# Create a symbol table from ELF output file.
%.sym: %.elf
@echo
@echo $(MSG_SYMBOL_TABLE) $@
$(NM) -n $< > $@

# Create library from object files.
.SECONDARY : $(TARGET).a
.PRECIOUS : $(OBJ)
%.a: $(OBJ)
@echo
@echo $(MSG_CREATING_LIBRARY) $@
$(AR) $@ $(OBJ)

# Link: create ELF output file from object files.
.SECONDARY : $(TARGET).elf
.PRECIOUS : $(OBJ)
%.elf: $(OBJ)
@echo
@echo $(MSG_LINKING) $@
$(CC) $(ALL_CFLAGS) $^ --output $@ $(LDFLAGS)

# Compile: create object files from C source files.
$(OBJDIR)/%.o : %.c
@echo
@echo $(MSG_COMPILING) $<
$(CC) -c $(ALL_CFLAGS) $< -o $@

# Compile: create object files from C++ source files.
$(OBJDIR)/%.o : %.cpp
@echo
@echo $(MSG_COMPILING_CPP) $<
$(CC) -c $(ALL_CPPFLAGS) $< -o $@

# Compile: create assembler files from C source files.
%.s : %.c
$(CC) -S $(ALL_CFLAGS) $< -o $@

# Compile: create assembler files from C++ source files.
%.s : %.cpp
$(CC) -S $(ALL_CPPFLAGS) $< -o $@

# Assemble: create object files from assembler source files.
$(OBJDIR)/%.o : %.S
@echo
@echo $(MSG_ASSEMBLING) $<
$(CC) -c $(ALL_ASFLAGS) $< -o $@

# Create preprocessed source for use in sending a bug report.
%.i : %.c
$(CC) -E -mmcu=$(MCU) -I. $(CFLAGS) $< -o $@

# Target: clean project.
clean: begin clean_list end

clean_list :
@echo
@echo $(MSG_CLEANING)
$(REMOVE) $(TARGET).hex
$(REMOVE) $(TARGET).eep
$(REMOVE) $(TARGET).cof
$(REMOVE) $(TARGET).elf
$(REMOVE) $(TARGET).map
$(REMOVE) $(TARGET).sym
$(REMOVE) $(TARGET).lss
$(REMOVEDIR) $(OBJDIR)
$(REMOVE) $(SRC:.c=.s)
$(REMOVE) $(SRC:.c=.d)
$(REMOVEDIR) .dep

# Create object files directory
$(shell mkdir $(OBJDIR) 2>/dev/null)

# Include the dependency files.
-include $(shell mkdir .dep 2>/dev/null) $(wildcard .dep/*)

# Listing of phony targets.
.PHONY : all begin finish end sizebefore sizeafter gccversion \
build elf hex eep lss sym coff extcoff \
clean clean_list program debug gdb-config
</pre></div>

== Beispiel 2 ==
Wenn man mehrere Projekte aus mehreren Mikroprozessoren ausprobieren will, muss man pro Projekt ein Unterverzeichnis und darin ein Makefile haben.

Wenn wegen neuer Erkenntnisse etwas am Kompilieren geändert werden soll, dann müssen alle diese makefiles angepasst werden. Das kann umgangen werden, wenn man "include" im Makefile benutzt.

Das hier vorgestellte Beispiel geht davon aus, dass im Windows-Rechner die Quellen der Unterprogramme, Hauptprogramme und Header so geordnet sind:
<pre>
C:\home\cc\include - Alle Header
C:\home\cc\lq - Alle Unterprogramme
C:\home\cc\ts - Alle Hauptprogramme fixapfel.cpp tsadc.cpp
C:\home\cc\ts\avr\tsadc - Der makefile und die astudio tsadc.apf-Datei
und die pnproj-Datei
C:\home\cc\ts\avr\fixapfel - Der makefile und die astudio fixapfel.apf-Datei
C:\home\cc\avrinc - Da habe ich eine Kopie der Header von WinAVR
c:\home\cc\avrbat - makedefs
</pre>

Die beiden Dateien benutze ich sowohl beim Kompilieren mit Windows und WinAVR als auch beim Kompilieren mit Linux. Dann muss ich nur die jeweils andere Zeile "HOME=" auskommentieren.

=== Die Datei C:\home\cc\ts\avr\tsadc\makefile ===
<div class="code"><pre>
PRG = tsadc

# all objects required to link this project
OBJ = $(PRG).o adc.o asctohw.o asctouc.o getticks.o inhex16.o \
inline.o inuint8.o mul_uw_uw.o mul_sw_sw.o othex1.o othex2.o \
othex4.o otint16.o otnl.o otputs.o otuint16.o otuint32.o otuint8.o \
tsdaytim.o tshar.o tsser.o

NPRGPATH = 3

include ../../../avrbat/makedefs
</pre></div>
=== Die Datei C:\home\cc\avrbat\makedefs ===
<div class="code"><pre>
# Select here which processor

#MCU = atmega8535
#F_CPU = 16000000L
#BAUD = 9600L

MCU = atmega32
F_CPU = 1008136L
BAUD = 4800L

# When using WINAVR
HOME=C:

# when using Linux
# HOME=/home/hjh

# Always in $(HOME)/home/cc/include are my headers
# Always in $(HOME)/home/cc/avrinc are the avr-gcc headers
# Always in $(HOME)/home/cc/lq are my sources (.cpp and .s)

# Because I copied the headers from C:\winavr here, I use this path
# Then I do not need to adapt this part of the make file if I compile with Linux
# instead with Windows WinAVR
HJH_IDIR = -I $(HOME)/home/cc/include -I $(HOME)/home/cc/avrinc

# predefinitons:
# NPRGPATH : the amount of timesharing parallel functions, including
# the main loop in main()
# F_CPU : The CPU frequency, may be long or float. The compiler converts
# it to the used type
# BAUD : The baud rate, used in tsser.cpp
DEFS = -DNPRGPATH=$(NPRGPATH) -DF_CPU=$(F_CPU) -DBAUD=$(BAUD)

CC = avr-gcc

ASFLAGS = -g -mmcu=$(MCU) $(DEFS)
CFLAGS = -g -mmcu=$(MCU) -Wall -Os -DAVR $(DEFS)
LDFLAGS = -g -mmcu=$(MCU) -Wall -Wl,-Map,$(PRG).map -L $(HOME)home/cc/lq/avr/$(MCU) -l c

all: $(PRG).elf lst text
echo Makefile of $(PRG) all done

$(PRG).elf: $(OBJ)
$(CC) $(LDFLAGS) -o $@ $^ $(LIBS)

clean:
rm -rf *.o $(PRG).elf *.eps *.png *.pdf *.bak
rm -rf *.lst *.map *.tmp

lst: $(PRG).lst

%.lst: %.elf
avr-objdump -h -S $< > $@

# Rules for building the .text rom images

text: hex

hex: $(PRG).hex

%.hex: %.elf
avr-objcopy -j .text -j .data -O ihex $< $@

# Compile the main program
$(PRG).o : ../../$(PRG).cpp
@echo compiling special input=$< output=$@
$(CC) -S -c $(HJH_IDIR) $(CFLAGS) $< -o $@.tmp
$(CC) -c $(HJH_IDIR) $(CFLAGS) $< -o $@

# Warning for Windows Users:
# For the %s, %S and %.cpp to work, all files in the ../../../lq directory
# must have lower case file names (use total commander to do this)
#
# Compile one of the programs of the library
%.o : ../../../lq/%.s
@echo compiling special input=$< output=$@
$(CC) -c $(HJH_IDIR) $(ASFLAGS) $< -o $@

%.o : ../../../lq/%.S
@echo compiling special input=$< output=$@
$(CC) -c $(HJH_IDIR) $(ASFLAGS) $< -o $@

%.o : ../../../lq/%.cpp
@echo compiling special input=$< output=$@
$(CC) -c $(HJH_IDIR) $(CFLAGS) $< -o $@

</pre></div>

== Siehe auch ==
http://www.gnu.org/software/make/ - Die GNU-Make Homepage

[[Kategorie:AVR]]

Baudratenquarz

2008-04-11T14:12:16Z

84.156.75.65: kat.

== Einleitung==

'''Baudratenquarze''' sind handelsübliche Quarze aus deren Frequenz sich durch ganzzahlige Teilung die Baudrate einer seriellen Schnittstelle ergibt. Wenn sich die Baudrate nicht durch ganzzahlige Teilung aus der Quarzfrequenz ableiten läßt ergibt sich ein Fehler, der zu Fehlabtastungen des seriellen Signals führt. Bei der Verwendung von Baudratenquarzen wird dieser Fehler nur durch die Toleranz des Quarzes bestimmt (+/-100ppm = +/-0,01% !).

=== Wofür steht der Begriff "baud" ? ===
Die Einheit Baud wurde nach dem Franzosen Baudot benannt und wird mit bd abgekürzt.

=== Was versteht man unter der Baudrate ? ===
Unter Baudrate versteht man die Schrittfrequenz eines Datensignals.
Unter einem Schritt versteht man in der Datenübertragung das kürzeste Datensignal. Dieses Datensignal enthält mindestens ein Bit. Je nach Modulationsverfahren können aber auch wesentlich mehr Bits in einem Schritt übertragen werden.

=== Was hat es mit der "Abtastung" auf sich ? ===
Bei der asynchronen Übertragung ist der Zeichenbeginn für den Empänger nicht vorhersehbar. Mit dem "Startbit" wird das Zeichen begonnen. Nach dem Startbit weiß der Empfänger, dass er eine halbe Bitlänge später das erste Datenbit abtasten kann. Eine weitere Bitlänge später das zweite Bit u.s.w..

Wenn nun die Abtastung schneller oder langsamer als die Datenübertragung stattfindet, weil der Abtasttakt mit zu grossem Fehler erzeugt wird, dann verschieben sich die Daten gegenüber dem Abtastsignal um einen geringen Zeitbetrag. Um das Datensignal möglichst fehlerfrei immer in der Bitmitte abtasten zu können, benötigt man deshalb einen stabilen und genauen Abtasttakt, der idealerweise von einem Baudratenquarz abgeleitet wird. Wenn die Frequenz um einige % daneben liegt wird die Verschiebung zwischen Datensignal und Abtastung nach wenigen Bits so gross, dass die Abtastung zu einem falschen Zeitpunkt stattfindet und ein Übertragungsfehler entsteht. Eine Beispielrechnung wurde vom Hersteller [http://www.maxim-ic.com MAXIM] schon einmal sehr ausführlich in einer [http://pdfserv.maxim-ic.com/en/an/AN2141.pdf Application Note (englisch)] durchgeführt. Als theoretische Obergrenze sind 3% Frequenzversatz zwischen Sender und Empfänger möglich. Praktisch sollte man diese Grenze jedoch nicht ausreizen und sich auf Fehler kleiner gleich 1% beschränken, um die Übertragungssicherheit und Fehlertoleranz zu erhöhen.

Zu dem vorstehend beschriebenen Abtasteffekt kommen noch die Fehler aus der Signalverzerrung auf dem Übertragungsweg. Die Verzerrung ist von der Leitungslänge und dem Übertragungsmedium abhängig. Eine präzise Abtastung des Signals im Empfänger ermöglicht einen höheren "Verzerrungsspielraum" auf dem Übertragungsweg. Deshalb ist es immer angeraten die Abtastfrequenz mit einem Baudratenquarz zu erzeugen.

== Berechnung von Baudratenquarzen ==

Da die integrierten UART-Bausteine das serielle Signal oftmals mit der acht- oder 16-fachen Frequenz abtasten, muß nach Teilung der Quarzfrequenz ein Takt entstehen, dessen Frequenz das acht- bzw. 16-fache der gewünschten Baudrate beträgt.

== Mathematische Betrachtung ==
Vor über 50 Jahren hat man mechanische Fernschreibsysteme mit 50 bd, 75 bd und 100 bd benutzt. Die ersten Akustikkoppler wurden dann mit 300 bd betrieben. Man erkennt leicht, dass alle diese Werte ganzzahlige Vielfache von 25 sind.

Die niedrigste "übliche" Baudrate liegt bei 300 bd. Durch Primfaktorzerlegung ergibt sich:
* 300 = 5 * 5 * 3 * 2 * 2.

Die Zahl 16 hat als Zweierpotenz die Primfaktoren

* 16 = 2 * 2 * 2 * 2 = 2^4

Alle Baudratenquarze müssen deshalb mindestens diese Primfaktoren enthalten.

Höhere Datenraten, wie z.B. 9600 bd liegen oftmals um einen aus einigen Zweierpotenzen bestehenden Faktor darüber.
* 9600 = 5 * 5 * 3 * 2 * 2 * 2 * 2 * 2 * 2 * 2 oder kurz 5^2 * 3^1 * 2^7

Ein Quarz mit der Frequenz 77,5 kHz ist nicht als Baudratenquarz brauchbar.
Die Primfaktorzerlegung ergibt:
* 77500 = 2 * 2 * 5 * 5 * 5 * 5 * 31

Es fehlt der Primfaktor 3. Deshalb ist die Baudrate von 300 bd nicht durch Teilung zu Erreichen. Das bedeutet wiederum, dass auch Vielfache wie z. B. 1200 baud, 9600 baud etc. nicht ohne Fehler erzeugt werden können.
Der Primfaktor 31 zeigt, dass eine ganzzahlige Teilung nicht ohne weiteres möglich ist. Wenn die Sendefrequenz des Senders DCF 77 mit einem 1 MHz Oszillator synchronisiert werden soll, geht das nur mit aufwendigen Auslaßteilern.

== Beispiele für Baudratenfrequenzen ==

* 1,8432 MHz (das ist die klassische Frequenz des PC-Baudratengenerators)
* 3,6864 MHz
* 4,9152 MHz
* 6,1440 MHz
* 7,3728 MHz
* 9,8304 MHz
* 11,0592 MHz
* 12,2880 MHz
* 14,7456 MHz
* 18,4320 MHz
* 19,6608 MHz
* 22,1184 MHz

Viele Frequenzen sind Vielfache zueinander. Die Basisfrequenz 1,8432 MHz ist so z.B. auch als 2-fache, 3-fache, 4-fache, 5- und 6-fache Frequenz üblich.
Hier einige solcher "Familien"
*1.) 1,8432 MHz; 3,6864 MHz; 7,3728 MHz; 11,0592 MHz; 14,7456 MHz; 18,432 MHz; 22,1184 MHz
*2.) 2,4567 MHz; 4,9152 MHz; 9,8304 MHz; 14,7456 MHz; 19,6608 MHz
*3.) 6,144 MHz; 12,288 MHz; 18,432 MHz

[[Kategorie:Bauteile]]

Brownout

2008-04-11T14:03:08Z

84.156.75.65: kat.

In Anlehnung an Blackout (= Stromausfall) ist ein Brownout eine zu geringe Spannung.

Jeder [[Mikrocontroller]] hat einen angegebenen Versorgungsspannungsbereich, z.B. 4,5 - 5,5V. Unterschreitet man diesen, dann hört er aber nicht einfach auf zu funktionieren, sondern nach und nach fallen einzelne Komponenten aus oder werden unzuverlässig. Die CPU "spielt verrückt".

Die üblichen Ursachen für einen Brownout sind leer werdende Batterien und der normale Ausschaltvorgang, wenn in der Stromversorgung ein größerer Kondensator ist (was bei Netzteilen normalerweise der Fall ist). Anders ausgedrückt: Ein Brownout ist kein exotischer Sonderfall, sondern man muss immer mit ihm rechnen.

Ob man etwas gegen einen Brownout tun muss, hängt von der Anwendung ab. Zeigt ein elektronisches Thermometer beim Ausschalten noch kurz wirre Zeichen an, dann ist das ziemlich egal; macht eine elektronische Steuerung aber dabei z.B. ein Ventil auf, dann könnte das unangenehme bis fatale Folgen haben.

Zur Lösung des Problems kann man über eine externe Schaltung am Prozessor das Reset-Signal aktivieren (solange läuft der Prozessor nämlich nicht). Dafür gibts auch fertige ICs, sogenannte Reset-Controller.

Immer wieder gerne genommene '''Reset-Controller''':

* TL7705 ([http://www.ti.com Ti])
* MCP100 ([http://www.microchip.com Microchip])
* MAX809 im sehr kleinen SC70 oder SOT23 Gehäuse zu haben ([http://www.maxim-ic.com Maxim])
* MAX6864 mit [[Watchdog]]

Neuere [[Mikrocontroller]] haben oft auch schon eine Brownout-Detection eingebaut, man muss sie dann nur noch aktivieren. Bedenken sollte man dabei, dass so eine Schaltung zusätzlich Strom benötigt. Bei den AVR-Prozessoren sind das 10-30 µA, was bei langlaufenden Batteriegeräten nicht mehr zu vernachlässigen ist (ca. 300 mAh pro Jahr).

[[Kategorie:Bauteile]]