RN-Wissen.de - Benutzerbeiträge [de]

PTC/NTC

2007-06-28T12:49:35Z

Pummelpete:

NTCs (''Negative Temperature Coefficient'')oder Heißleiter sind stromleitende Materialien, die bei hohen Temperaturen Strom besser leiten als bei tiefen, das heißt, mit steigender Temperatur sinkt ihr elektrischer Widerstand.

Anders gesagt: sie haben einen negativen Temperaturkoeffizienten. Davon leitet sich auch ihr zweiter Name ab: NTC steht für (engl.) ''negative temperature coefficient''.

Unter anderem gibt es auch PTC's (''positive temperature coeffiecient'') diese leiten den Strom besser umso kälter es wird. Sie haben einen positiven Temperaturkoeffizienten.

[[Bild:ntc.gif]]

Ein NTC-Widerstand ändert seinen Widerstand meist nicht linear. Hier ein Beispieldiagramm eines typischen NTC-Widerstandes:

[[Bild:ntcdiagramm.gif]]

==Typische NTCs/PTCs==
===PTCs:===
Recht beliebt sind die PTCs der KTY-Reihe z.B KTY81-110. Sie sind sehr günstig (ca. 0,50€) und bieten für die meisten Anwendungen ausreichende Genauigkeit.
Wenn höhere Anforderungen an Genauigkeit und Linearität gestellt werden, eignen sich die PT100/PT1000 Sensoren. Jedoch sind diese auch erheblich teurer.

===NTCs:===
-?

==Siehe auch==
*[[Sensorarten]]

[[Kategorie:Elektronik]]
[[Kategorie:Sensoren]]

PTC/NTC

2007-06-28T12:45:52Z

Pummelpete:

NTCs (''Negative Temperature Coefficient'')oder Heißleiter sind stromleitende Materialien, die bei hohen Temperaturen Strom besser leiten als bei tiefen, das heißt, mit steigender Temperatur sinkt ihr elektrischer Widerstand.

Anders gesagt: sie haben einen negativen Temperaturkoeffizienten. Davon leitet sich auch ihr zweiter Name ab: NTC steht für (engl.) ''negative temperature coefficient''.

Unter anderem gibt es auch PTC's (''positive temperature coeffiecient'') diese leiten den Strom besser umso kälter es wird. Sie haben einen positiven Temperaturkoeffizienten.

[[Bild:ntc.gif]]

Ein NTC-Widerstand ändert seinen Widerstand meist nicht linear. Hier ein Beispieldiagramm eines typischen NTC-Widerstandes:

[[Bild:ntcdiagramm.gif]]

==Typische NTCs/PTCs==
PTCs: </n>
Recht beliebt sind die PTCs der KTY-Reihe z.B KTY81-110. Sie sind sehr günstig (ca. 0,50€) und bieten für die meisten Anwendungen ausreichende Genauigkeit.
Wenn höhere Anforderungen an Genauigkeit und Linearität gestellt werden, eignen sich die PT100/PT1000 Sensoren.

NTCs:
-?

==Siehe auch==
*[[Sensorarten]]

[[Kategorie:Elektronik]]
[[Kategorie:Sensoren]]

PTC/NTC

2007-06-28T12:43:26Z

Pummelpete:

NTCs (''Negative Temperature Coefficient'')oder Heißleiter sind stromleitende Materialien, die bei hohen Temperaturen Strom besser leiten als bei tiefen, das heißt, mit steigender Temperatur sinkt ihr elektrischer Widerstand.

Anders gesagt: sie haben einen negativen Temperaturkoeffizienten. Davon leitet sich auch ihr zweiter Name ab: NTC steht für (engl.) ''negative temperature coefficient''.

Unter anderem gibt es auch PTC's (''positive temperature coeffiecient'') diese leiten den Strom besser umso kälter es wird. Sie haben einen positiven Temperaturkoeffizienten.

[[Bild:ntc.gif]]

Ein NTC-Widerstand ändert seinen Widerstand meist nicht linear. Hier ein Beispieldiagramm eines typischen NTC-Widerstandes:

[[Bild:ntcdiagramm.gif]]

==Typische NTCs/PTCs==
PTCs:
Recht beliebt sind die PTCs der KTY-Reihe z.B KTY81-110. Sie sind sehr günstig (ca. 0,50€) und bieten für die meisten Anwendungen ausreichende Genauigkeit.
Wenn höhere Anforderungen an Genauigkeit und Linearität gestellt werden, eignen sich die PT100/PT1000 Sensoren.

NTCs:
-?

==Siehe auch==
*[[Sensorarten]]

[[Kategorie:Elektronik]]
[[Kategorie:Sensoren]]

PTC/NTC

2007-06-28T12:27:35Z

Pummelpete: NTC wurde nach PTC/NTC verschoben

NTC

2007-06-28T12:27:35Z

Pummelpete: NTC wurde nach PTC/NTC verschoben: NTC und PTC werden erwähnt bzw. sollten zusammen behandelt werden.

#redirect [[PTC/NTC]]

Warteschleife

2007-06-28T12:08:56Z

Pummelpete: Link hinzugefügt

Oft sieht man den Versuch, Warteschleifen in C durch Zählschleifen zu realisieren:
<pre>
void wait ()
{
int i;

for (i=0; i<50; i++);
}
</pre>

[[avr-gcc]] mit Optimierung erzeugt daraus
<pre>
wait:
ret
</pre>
und das ist auch völlig in Ordnung, wenn man ein Blick in die C-Spezifikation wagt.
Die Schleife hat ''keine'' Wirkung auf die Welt! Sie sagt:
:''"Führe 50 mal ''<tt>;</tt>'' aus"''
Und 50 mal Nichtstun ist eben nichts Tun...

Falls man wirklich auf diese Art warten möchte, hilft folgendes: Man gaukelt dem Compiler vor, es gäbe etwas unheimlich wichtiges in der Schleife zu tun, von dem er nichts mitbekommt.
<pre>
void wait ()
{
int i;

for (i=0; i<50; i++)
__asm__ __volatile ("; nur ein asm-Kommentar");
}
</pre>
daraus entsteht
<pre>
wait:
ldi r24,lo8(49)
ldi r25,hi8(49)
.L5:
/* #APP */
; nur ein asm-Kommentar
/* #NOAPP */
sbiw r24,1
sbrs r25,7
rjmp .L5
ret
</pre>
Die Schleife wird nun 50 mal durchlaufen.

Wir bemerken, daß das inline Assembler nicht in Code resultiert
und daß die Schleifenvariable nicht hochzählt, sondern hinunter.
Auch diese Optimierung ist ok, denn <tt>i</tt> wird nirgends verwendet.

Daß bei dem Beispiel der gewünschte Code erzeugt wird, ist mehr oder weniger Glückssache.
Ein Compiler transformiert seine Eingabe in ein Assembler- oder Maschinenprogramm, das die gleiche Wirkung hat. ''Wie'' dies genau geschieht, ist in aller Regel nicht festgelegt,
sondern nur, ''daß'' es passiert
 ansonsten ist der Compiler selbst fehlerhaft oder implementiert kein C.

In dem lezten Beispiel der Warteschleife ist die Bedeutung des C-Codes etwa
:''"führe 50 mal das Inline-Assembler-Muster ''<tt>"; nur ein asm-Kommentar"</tt>'' in den Code ein"''
Dies wäre auch möglich komplett ohne Schleife(nvariable), indem der Compiler diese wegoptimiert und nur das Inline Assembler 50 mal hintereinander ausgibt.
Das Resultat wäre im Maschinencode dann wiederum absolut ohne Effekt.
Bei gcc geschieht dies aber bestenfalls mit der Optimierungsstufe <tt>-O3</tt>, die für
AVR absolut nicht zu empfehlen ist. (Oder indem man von Hand die Optionen setzt, die diese
Optimierungsstrategie nach sich zieht.)

Eine Möglichkeit, dem auf C-Ebene zu begegnen, ist die Schleifenvariable <tt>i</tt>
als volatile zu deklarieren, so daß sie angelegt werden und genau so wie codiert verwendet werden muss:
<pre>
void wait ()
{
int volatile i;

for (i=0; i<50; i++)
;
}
</pre>
Das hat allerdings noch andere Konsequenzen, nämlich das Erzwingen des Framepointers
(bei avr-gcc im Y-Register r28:r29),
denn <tt>i</tt> lebt jetzt nicht mehr in einem Register, sondern im Frame und wird wirklich jedesmal von dort gelesen und geschrieben, was recht breiten Code ergibt:
<pre>
wait:
/* prologue: frame size=2 */
push r28
push r29
in r28,__SP_L__
in r29,__SP_H__
sbiw r28,2
in __tmp_reg__,__SREG__
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
/* prologue end (size=10) */
std Y+1,__zero_reg__
std Y+2,__zero_reg__
ldd r24,Y+1
ldd r25,Y+2
sbiw r24,50
brge .L7
.L5:
ldd r24,Y+1
ldd r25,Y+2
adiw r24,1
std Y+1,r24
std Y+2,r25
ldd r24,Y+1
ldd r25,Y+2
sbiw r24,50
brlt .L5
.L7:
/* epilogue: frame size=2 */
adiw r28,2
in __tmp_reg__,__SREG__
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
pop r29
pop r28
ret
</pre>
Das ist der totale Overkill.
Inakzeptabel breiter Code und ein einzelner Schleifendurchlauf dauert viele Instruktionen,
so dass die verstrichene Zeit nur recht grobkörnig eingestellt werden kann, denn ein Durchlauf dauert 18 Zyklen.



Eine weitere reine C-Variante, die näher am Ziel liegt, könnte so aussehen. Das <tt>(void)</tt> vermeidet eine Warnung, weil <tt>dummy</tt> nicht verwendet wird:
<pre>
void wait ()
{
int i;

for (i=0; i<50; i++)
{
static unsigned char volatile dummy;
(void) (dummy = i);
}
}
</pre>
Was zu diesem Code führt:
<pre>
wait:
ldi r24,lo8(0)
ldi r25,hi8(0)
.L5:
sts dummy.0,r24
adiw r24,1
cpi r24,50
cpc r25,__zero_reg__
brlt .L5
ret
</pre>
oder so was
<pre>
void wait ()
{
int i;

for (i=0; i<50; i++)
(void) (int * volatile) &i;
}
</pre>
was wieder den minimalen Code ergibt wie beim erzwungenen Reload:
<pre>
wait:
ldi r24,lo8(0)
ldi r25,hi8(0)
.L5:
adiw r24,1
cpi r24,50
cpc r25,__zero_reg__
brlt .L5
ret
</pre>

=Fazit=

{{FarbigerRahmen|
Die einzig sichere Lösung, einen bestimmten Code generieren zu lassen, ist und bleibt das Gewünschte komplett in (Inline) Assembler auszudrücken.
}}


=delay.h=
Durch den Header (Include-Datei) <tt>avr/delay.h</tt> werden zwei Funktionen (als <tt>static inline</tt> implementiert) zur Verfügung gestellt, die mit minimalem Overhead eine bestimmte Anzahl von Maschinenzyklen verstreichen lassen:
;<tt>void _delay_loop_1 (uint8_t count)</tt>: Dauert <tt>3·count-1</tt> Zyklen
;<tt>void _delay_loop_2 (uint16_t count)</tt>: Dauert <tt>4·count-1</tt> Zyklen
Dabei wird <tt>count=0</tt> wie 256 (<math>2^8</math>) bzw. 65536 (<math>2^{16}</math>) genommen. Zyklen für den Funktionsaufruf müssen keine zugerechnet werden, da es Inline-Funktionen sind. Jedoch muss die Schleifenvariable vorgeladen werden und wenn [[Interrupt]]s aktiv sind, kommen deren Zeiten hinzu, falls in der Schleife ne [[IRQ]] auftritt. Jede Inline-Funktion ist 4 Bytes lang.

=Tip: Nützliches Tool=
Ein sehr praktisches Tool, um Schleifen von beliebiger Dauer zu erzeugen, kann man hier herunterladen: http://www.home.unix-ag.org/tjabo/avr/AVRdelayloop.html.
Man gibt einfach die Taktfrequenz, die gewünschte Zeit und drei Register ein und das Programm erzeugt einen passenden Assembler Code.

=Siehe auch=
* [[avr-gcc]]
* [[Inline-Assembler in avr-gcc|Inline-Assembler]]

[[Kategorie:Grundlagen]]
[[Kategorie:Quellcode C]]
[[Kategorie:Quellcode Assembler AVR]]
[[Kategorie:Software]]