Forum: Mikrocontroller und Digitale Elektronik PIN vs PORT beim OUTPUT


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von D a v i d K. (oekel) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi,

kann mir Jemand erläutern, wieso meine Status-Funktion "allways TRUE" 
zurück liefert?
1
DDRC |= ((1 << PC3) | (1 << PC4) | (1 << PC5) | (1 << PC6) | (1 << PC7)); /* Ausgaenge */
2
3
void heater_ON() {
4
  if (!blockedOutputs) {
5
    PORTC |= (1 << PC7);
6
  }
7
  virtualTankUp = true;
8
}
9
void heater_OFF() {
10
  PORTC &= ~(1 << PC7);
11
}
12
bool heater_STATUS(){
13
  return (PINC & (1 << PC7));
14
        //return (PORTC & (1 << PC7));
15
}

Also an dem PIN hängt ein OptoCoupler, der richtig angesprochen wird.

Grüße Oekel

von D a v i d K. (oekel) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ok, der Code ist 100% korrekt. Ich hatte lediglich vergessen den Header 
des obigen Schnipsels einzubinden.

Daher die neue Frage:

Wieso ist bool test = heater_STATUS();
immer TRUE, wenn heater_STATUS() extern definiert wurde und er es nicht 
finden kann?

Grüße Oekel

von Lieba Gedichte (Gast)


Bewertung
0 lesenswert
nicht lesenswert
D a v i d K. schrieb:
> Also an dem PIN hängt ein OptoCoupler, der richtig angesprochen wird.

Damit ist wirklich alles erschöpfend erklärt.

Ich liebe sie, diese Prosa-Schaltpläne.

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
Lieba Gedichte schrieb:
> Ich liebe sie, diese Prosa-Schaltpläne.

nicht nur prosa Schaltpläne. Auch Prosa Fehlermeldungen
D a v i d K. schrieb:
> wenn heater_STATUS() extern definiert wurde und er es nicht
> finden kann

Und zu PINC gibt es nicht mal Prosa.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Möglicherweise hast du den Optokoppler ohen Vorwiderstand zwischen den 
PIN und VCC angeschlossen. Dadurch liegt der PIN immer auf High.

Das PIN Register liest den aktuellen Zustand des PIN ein.
Das PORT Regsietr kannst du benutzen, um abzufragen, welchen Pegel der 
Ausgang eigentlich haben sollte.

Zwischen beiden besteht ein Unterschied, wenn der Ausgang 
kurzgeschlkossen wird.

von isimmerso (Gast)


Bewertung
1 lesenswert
nicht lesenswert
D a v i d K. schrieb:
> Wieso ist bool test = heater_STATUS();
> immer TRUE, wenn heater_STATUS() extern definiert wurde und er es nicht
> finden kann?

Weil er sich für etwas entscheiden muß und ahnt, daß es extern mit TRUE 
intitialisiert wurde.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Ich würde zuallererst mal nachmessen, welcher Pegel bzw. welche 
Spannung denn tatsächlich am Pin 7 vom Port C liegt. Dieses 
Messergebnis könnte bedeutend für den Programmverlauf sein...

: Bearbeitet durch Moderator
von Rene K. (xdraconix)


Bewertung
2 lesenswert
nicht lesenswert
isimmerso schrieb:
> D a v i d K. schrieb:
>> Wieso ist bool test = heater_STATUS();
>> immer TRUE, wenn heater_STATUS() extern definiert wurde und er es nicht
>> finden kann?
>
> Weil er sich für etwas entscheiden muß und ahnt, daß es extern mit TRUE
> intitialisiert wurde.

Naja, er dürfte es nicht einmal compilieren. Deswegen wundert es mich 
gerade das er überhaupt einen Status annehmen kann ;-)

von D a v i d K. (oekel) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Ich würde zuallererst mal nachmessen, welcher Pegel bzw. welche
> Spannung denn tatsächlich am Pin 7 vom Port C liegt. Dieses
> Messergebnis könnte bedeutend für den Programmverlauf sein...

Wie ich oben bereits geschrieben habe ist der Code richtig. Und 
selbstverständlich habe ich einige Iterationen durch, in denen ich 
validiert habe, dass die Ausgänge richtig schalten.
Hinzu kam lediglich die Statusabfrage, die ich an anderer Stelle im 
Programcode benötigte.

Rene K. schrieb:
> isimmerso schrieb:
>> D a v i d K. schrieb:
>>> Wieso ist bool test = heater_STATUS();
>>> immer TRUE, wenn heater_STATUS() extern definiert wurde und er es nicht
>>> finden kann?
>>
>> Weil er sich für etwas entscheiden muß und ahnt, daß es extern mit TRUE
>> intitialisiert wurde.
>
> Naja, er dürfte es nicht einmal compilieren. Deswegen wundert es mich
> gerade das er überhaupt einen Status annehmen kann ;-)

Danke euch beiden. Diese Info hatte ich vermutet und gebraucht.
Wieso er überhaupt compiliert und wieso ein DEFAULT dann zu TRUE 
falsifiziert ist mir immer noch ein Rätsel. Hätte wie ihr auch erwartet, 
dass der Compiler zumindest eine Warnung ausgibt. Nichts dergleichen!

von Stefan E. (sternst)


Bewertung
0 lesenswert
nicht lesenswert
D a v i d K. schrieb:
> Wieso er überhaupt compiliert und wieso ein DEFAULT dann zu TRUE
> falsifiziert ist mir immer noch ein Rätsel. Hätte wie ihr auch erwartet,
> dass der Compiler zumindest eine Warnung ausgibt. Nichts dergleichen!

Wenn es keine Meldung vom Compiler gibt, woher weißt du dann überhaupt, 
dass "er es nicht finden kann"?

Alles irgendwie sehr nebulös.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
D a v i d K. schrieb:
> der Compiler
Welcher denn?
Und was änderst du jetzt in deinem Programm zwischen "geht" und "geht 
nicht"?

> Diese Info hatte ich vermutet und gebraucht.
Dass ein Compiler etwas "ahnt"?

> Wieso er überhaupt compiliert und wieso ein DEFAULT dann zu TRUE
> falsifiziert ist mir immer noch ein Rätsel.
Du solltest das mal auf einen "Dreizeiler" reduzieren, so dass du ein 
einfaches Programm hast, das mal den Fehler aufweist und mal nicht. Dann 
kann man das evtl. nachvollziehen. Aber bisher waren die allermeisten 
"Compilerfehler", die Anfänger hatten, letztlich Bedienfehler.

Ich hatte bisher erst 2 richtige Fehler im Compiler, einer trat sofort 
nach einem Update auf. Der andere hat fast eine Woche Zeit gekostet, um 
nachzuweisen, dass es tatsächlich der Compiler war, der einen 
unaligned Zugriff falsch abhandelte.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Und was änderst du jetzt in deinem Programm zwischen "geht" und "geht
> nicht"?

Das hatte er ja zu Eingangs beschrieben:

D a v i d K. schrieb:
> Ich hatte lediglich vergessen den Header
> des obigen Schnipsels einzubinden.

Und da er keine Lust hat, das nochmal auszuprobieren oder gar zu 
verstehen, ist die angebotene Lösung der vorausahnenden Kompilierung 
ausreichend ;-)

von Hugo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> vorausahnenden Kompilierung

Ein schöner Ausdruck! Muß ich mir unbedingt merken, wenn es mal wieder 
um die "Ahnungen" eines Compilers geht.
Das hat schon fast was von "künstlicher Intelligenz" :-)

von D a v i d K. (oekel) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefan E. schrieb:
> Wenn es keine Meldung vom Compiler gibt, woher weißt du dann überhaupt,
> dass "er es nicht finden kann"?
>
> Alles irgendwie sehr nebulös.

Na weil mein Programm die Ausgänge regelmäßig ändert , sonst bräuchte 
ich ja keinen MC.
Also Header eingebunden und Ablauf/Display beobachtet.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Nee...
So nicht!

Wenn der Kompiler was nicht findet, dann hagelt es Errors.
Spätestens der Linker bricht dir dann ins Essen.
Denn der hat die Pflicht, die extern Deklaration aufzulösen, mit einer 
Adresse zu versehen.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
D a v i d K. schrieb:
> Na weil mein Programm die Ausgänge regelmäßig ändert , sonst bräuchte
> ich ja keinen MC.
> Also Header eingebunden und Ablauf/Display beobachtet.

Gutes Vorgehen, um "mal eben kurz zu schauen", schlechtes Vorgehen um 
damit die Frage in einem Forum wie diesem zu starten.

Als nächstes könntest du mal direkt am PIN des uC messen, welche 
Spannungen da anliegen (am besten mit einem Oszi). Sollte da wider 
Erwarten eine Spannung kleiner 0.3*Vcc anliegen kannst du beginnen, 
Stück für Stück deinen Code abzuspecken bis der Fehler verschwindet.
Sollte der Fehler bis zum Schluss, wenn der Code also so einfach ist wie 
möglich, immer noch da sein kannst du den Quellcode mal packen und hier 
hoch laden. Vielleicht erkennen dann die Spezialisten wo genau das 
Problem ist.

von xXx (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
D a v i d K. schrieb:

> DDRC |= ((1 << PC3) | (1 << PC4) | (1 << PC5) | (1 << PC6) | (1 <<
> PC7)); /* Ausgaenge */

Könnte es nicht so sein, dass der Pin PC7, auf Eingang geschaltet werden 
sollte bevor man ihn abfragt?

> bool heater_STATUS(){
>   return (PINC & (1 << PC7));
>         //return (PORTC & (1 << PC7));

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Was ich mich frage, wifür überhaupt zurück lesen?
Der aufrufende Teil könnte sich ja auch einfach merken was passiert, 
zumal hier ja auch sowieso noch eine globale Variable gesetzt wird.

Die Variable könnte dann auch noch so zurück gesetzt werden
1
heater_OFF()
2
if(heater_STATUS() != 0)
3
{
4
 // alarm, geht nicht aus??!!??
5
}
6
else
7
{
8
 virtualTankUp = true;
9
}

Na, vielleicht, eher mit weniger Zeilen. :-)

Einzeiler zu kapseln finde ich generell etwas überflüssig.
Vor allem welche die nicht danach aussehen als bräuchte man die drölfzig 
Mal im Code.

Und statt das sich das Programm den Zustand merkt kann man das auch so 
einrichten das in jedem Umlauf erneut entschieden wird ob was an oder 
aus sein soll.
Die Bedingung die zu einem heater_ON() führt ist ja sowieso schon 
vorhanden und wird geprüft.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
D a v i d K. schrieb:
> Wie ich oben bereits geschrieben habe ist der Code richtig. Und
> selbstverständlich habe ich einige Iterationen durch, in denen ich
> validiert habe, dass die Ausgänge richtig schalten.

Na wenn sowohl der Code korrekt ist, als auch elektrisch alles passt, 
dann ist die einzige übrig bleibende Erklärung, dass dein µC kaputt ist.

von Patrick J. (ho-bit-hun-ter)


Bewertung
0 lesenswert
nicht lesenswert
Hi

Wenn z.B. ein OC-Ausgang benutzt wird, können auch 'Andere' die Leitung 
auf LOW ziehen.
Obwohl man gerade selber HIGH sendet (in diesem Fall den PullUp an hat 
und der Port auf IN geschaltet ist), muß Das nicht mit dem tatsächlichen 
Stand zu tun haben - deshalb liest man den Zustand des Pin, weil man 
nicht wissen will, was geplant ist, sondern, was wirklich anliegt.

MfG

: Bearbeitet durch User
von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Patrick J. schrieb:
> Wenn z.B. ein OC-Ausgang benutzt wird, können auch 'Andere' die Leitung
> auf LOW ziehen.

Das sieht nur schwer nach AVR aus und die haben keine Open-Collector 
Ausgänge, zumindest nicht als IOs.
Zur Überwachung würde ich dann auch einen anderen Pin als Eingang 
benutzen.

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
Auch bei einem AVR kann man, wenn der Pin sich im Output befindet, den 
IST-Zustand über PINx abfragen. Gerade wenn mit Pull-Up / -Down 
gearbeitet wird ist dies sehr hilfreich. Ob dies nun bei allen AVR so 
ist, kann ich nicht beurteilen - zumindest geht es beim ollen 
Attiny2313, Mega16 und Mega32u4.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Rene K. schrieb:
> Auch bei einem AVR kann man, wenn der Pin sich im Output befindet, den
> IST-Zustand über PINx abfragen.

Ja, klar.
Nur wenn der Pin als Ausgang geschaltet ist und auf High, aber extern 
gegen Low gezogen wird, dann ist der Pin kurz vor dem Abfackeln.
Ebenso anders herum mit dem Pin auf Low geschaltet und extern gegen Plus 
gezogen.
Das kann man zwar abfragen, sowas sollte aber schon in der Schaltung gar 
nicht möglich sein.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Patrick J. schrieb:
>> Wenn z.B. ein OC-Ausgang benutzt wird, können auch 'Andere' die Leitung
>> auf LOW ziehen.
>
> Das sieht nur schwer nach AVR aus und die haben keine Open-Collector
> Ausgänge, zumindest nicht als IOs.

Korrekt. Ungeachtet dessen könnte ein auf H gesetzter Ausgangspin 
trotzdem extern auf L gezogen werden. Das ist dann zwar nicht ganz 
regelkonform, insbesondere weil dann ein heftiger, möglicherweise sogar 
außerhalb der absolute maximum ratings liegender Kurschlußstrom aus dem 
Pin fließen würde. Aber gehen würde es. Und: man könnte genau diesen 
Fall durch das Lesen des PIN-Registers feststellen.

> Zur Überwachung würde ich dann auch einen anderen Pin als Eingang
> benutzen.

Das wäre im eben geschilderten Szenario kein Vorteil.


Rolf M. schrieb:
> D a v i d K. schrieb:
>> Wie ich oben bereits geschrieben habe ist der Code richtig. Und
>> selbstverständlich habe ich einige Iterationen durch, in denen ich
>> validiert habe, dass die Ausgänge richtig schalten.
>
> Na wenn sowohl der Code korrekt ist, als auch elektrisch alles passt,
> dann ist die einzige übrig bleibende Erklärung, dass dein µC kaputt ist.

Wobei ein Blick auf bisherige Beiträge des TE (beileibe nicht nur in 
diesem Thread) die Wahrscheinlichkeiten ganz massiv dahin verschiebt, 
die Annahme "der Code [ist] richtig" in Frage stellen zu wollen.

: Bearbeitet durch User
von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Ja, klar.
> Nur wenn der Pin als Ausgang geschaltet ist und auf High, aber extern
> gegen Low gezogen wird, dann ist der Pin kurz vor dem Abfackeln.
> Ebenso anders herum mit dem Pin auf Low geschaltet und extern gegen Plus
> gezogen.
> Das kann man zwar abfragen, sowas sollte aber schon in der Schaltung gar
> nicht möglich sein.

Das ist richtig. :-) Es heißt ja nicht ob es gut ist, sondern ob es 
geht.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Die Frage die ich in den Raum geworfen habe war ja auch nicht, ob das 
funktioniert, sondern wofür überhaupt. :-)
OpenCollector jetzt mal ausser acht gelassen.

Wenn sowas möglich ist buche ich das als Schaltungsfehler und wenn mir 
der Pin abfackelt nützt es herzlich wenig wenn die Software davon was 
merkt.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> ein heftiger, möglicherweise sogar
> außerhalb der absolute maximum ratings liegender Kurschlußstrom aus dem
> Pin fließen würde. Aber gehen würde es. Und: man könnte genau diesen
> Fall durch das Lesen des PIN-Registers feststellen.

Nicht wirklich.
Ein Strom außerhalb der Maximum Ratings zerstört den µc in beliebig 
kurzer Zeit.
Ob du das vor der Zerstörung noch durch Rücklesen des Pins erkennen 
kannst und auch noch dagegen reagieren kannst, ist Zufall und mit 
Sicherheit auch abhängig vom Controllerchip und dessen 
Herstellungscharge.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
xXx schrieb:
> Könnte es nicht so sein, dass der Pin PC7, auf Eingang geschaltet werden
> sollte bevor man ihn abfragt?
Nein, das ist nicht erforderlich.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Was ich mich frage, wifür überhaupt zurück lesen?

Um z.B. an anderen Stellen im Programm zu prüfen, ob grade geheizt wird 
oder nicht. Kann man auch mittels Flag in Software machen, man kann aber 
auch den Hardware-Pin einfach abfragen. Mach ich fast immer so.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
>> Na wenn sowohl der Code korrekt ist, als auch elektrisch alles passt,
>> dann ist die einzige übrig bleibende Erklärung, dass dein µC kaputt ist.
>
> Wobei ein Blick auf bisherige Beiträge des TE (beileibe nicht nur in
> diesem Thread) die Wahrscheinlichkeiten ganz massiv dahin verschiebt,
> die Annahme "der Code [ist] richtig" in Frage stellen zu wollen.

Darauf wollte ich eigentlich auch hinaus. Es ist eben ungeschickt, wenn 
das System nicht funktioniert und man um Hilfe bittet, zuerst mal voller 
Inbrunst zu postulieren, dass man alles richtig gemacht hat. Das lässt 
nicht viele Möglichkeiten für Hilfe zur Lösung des Problems offen.

MaWin schrieb:
> Ein Strom außerhalb der Maximum Ratings zerstört den µc in beliebig
> kurzer Zeit.

Wie kurz sind die denn deiner Erfahrung nach?

> Ob du das vor der Zerstörung noch durch Rücklesen des Pins erkennen
> kannst und auch noch dagegen reagieren kannst, ist Zufall und mit
> Sicherheit auch abhängig vom Controllerchip und dessen
> Herstellungscharge.

Ich hab's zwar noch nicht ausporbiert, aber kann mir irgendwie nicht 
vorstellen, dass bei einem Kurzschluss am I/O-Pin der µC innerhalb einer 
einstelligen Zahl von Mikrosekunden abraucht.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Ich hab's zwar noch nicht ausporbiert, aber kann mir irgendwie nicht
> vorstellen, dass bei einem Kurzschluss am I/O-Pin der µC innerhalb einer
> einstelligen Zahl von Mikrosekunden abraucht.

Ein Atmega328 verkraftet mehrere Millisekunden das Eineinhalbfache des 
im Datenblatt angegebenen Wertes für einen Pin, das ist zumindest meine 
Erfahrung

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Wie kurz sind die denn deiner Erfahrung nach?

Das spielt keine Rolle, weil es bei deinem Chip anders ist.

Wenn Elektronik für eine beliebig kleine Zeit außerhalb der Maximum 
Ratings betrieben wird, dann ist sie als defekt anzunehmen.

von Detlev T. (detlevt)


Bewertung
0 lesenswert
nicht lesenswert
D a v i d K. schrieb:
> Wieso ist bool test = heater_STATUS();
> immer TRUE, wenn heater_STATUS() extern definiert wurde und er es nicht
> finden kann?

Also ich verstehe das jetzt so, dass das Programm wie gewünscht 
funktioniert, wenn die Header-Datei eingebunden wurde. Fehlt diese, tut 
es das nicht.

Der Grund liegt im C-Standard. Erst einmal sind (aus historischen 
Gründen)  Funktionsprototypen im Gegensatz zu C++ nicht obligatorisch. 
Der Compiler sieht einen fehlenden Prototypen daher nicht als Fehler an, 
sondern geht bei der Kompilierung der aufrufenden Funktion defaultmäßig 
davon aus, dass der Rückgabe-Wert der aufgerufenen Funktion ein int ist, 
auf dem AVR also 2 Bytes.

Die aufgerufene Funktion hat den Rückgabewert bool, beschreibt also nur 
ein 8-Bit-Rückgabe-Register. Die aufrufende Funktion interpretiert 
jedoch zwei Register als Rückgabewert (int). Der (implizite) cast von 
int nach bool ist laut Standard immer true, wenn der int-Wert ungleich 
Null ist. Steht also in dem als High-Byte des Rückgabewertes 
interpretierten Register keine Null (was meistens der Fall ist), ergibt 
sich also am Ende ein 'true', selbst wenn die Funktion selbst ein 
'false' zurück gegeben hat.

Daher: Immer alle Warnungen des Compilers einschalten und auch ernst 
nehmen!

: Bearbeitet durch User
von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:
> Daher: Immer alle Warnungen des Compilers einschalten und auch ernst
> nehmen!

Sollte er eine Header nicht finden, wirft er keine Warnung raus sondern 
bringt einen Fehler und compiliert garnicht erst.

von Detlev T. (detlevt)


Bewertung
0 lesenswert
nicht lesenswert
Rene K. schrieb:
> Sollte er eine Header nicht finden, wirft er keine Warnung raus sondern
> bringt einen Fehler und compiliert garnicht erst.

D a v i d K. schrieb:
> Ok, der Code ist 100% korrekt. Ich hatte lediglich vergessen den Header
> des obigen Schnipsels einzubinden.

von Dietrich L. (dietrichl)


Bewertung
2 lesenswert
nicht lesenswert
MaWin schrieb:
> Wenn Elektronik für eine beliebig kleine Zeit außerhalb der Maximum
> Ratings betrieben wird, dann ist sie als defekt anzunehmen.

Ich würde es etwas anders formulieren: man muss mit einem Defekt 
rechnen.

Denn:
- der Hersteller garantiert unterhalb der Maximum Ratings, dass das 
Bauteil nicht kaputt geht
- der Hersteller garantiert aber nicht, dass das Bauteil oberhalb der 
Maximum Ratings kaputt geht.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Ein Strom außerhalb der Maximum Ratings zerstört den µc
> in beliebig kurzer Zeit.

Mein Motorrad schafft auf ebener Strecke maximal 140km/H. Laut 
Betriebsanleitung soll ich vermeiden, über einen längeren Zeitraum mit 
maximaler or annähernd maximaler Geschwindigkeit zu fahren, besonders 
bei erhöhter Temperatur.

Das ist genau so ein Wischiwaschi, wie der maximale Strom von I/O Pins 
bei Mikrochips.

In den 90er Jahren machte ich anhand eines PC Mainboardes die Erfahrung, 
daß die 74LS245 Bustreiber sehr empfindlich auf Schrauben im Slot 
reagieren.

Ich kann mich allerdings nicht erinnern, daß mir danach jemals auch nur 
irgendein IC wegen Kurzschluss an einem einzelnen Ausgang kaputt 
gegangen wäre (womit ich nicht behaupten will, daß alle IC's 
kurzschlussfest seien).

Insofern würde ich "in beliebig kurzer Zeit" auf "in beliebig langer 
Zeit" ändern. Es ist in der Praxis lange nicht so dramatisch, wie deine 
Bemerkung anmutet.

Zur Erkennung von Kurzschlüssen kann ich mir durchaus vorstellen, das 
PIN Register eines AVR Ausganges zu lesen. Man könnte dann die Leitung 
deaktivieren und eine entsprechende Fehlermeldung anzeigen.

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:
> Rene K. schrieb:
>> Sollte er eine Header nicht finden, wirft er keine Warnung raus sondern
>> bringt einen Fehler und compiliert garnicht erst.
>
> D a v i d K. schrieb:
>> Ok, der Code ist 100% korrekt. Ich hatte lediglich vergessen den Header
>> des obigen Schnipsels einzubinden.

Ja dazu darfst du folgendes aber auch nicht vergessen:

D a v i d K. schrieb:
> wenn heater_STATUS() extern definiert wurde und er es nicht
> finden kann?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> Ein Atmega328 verkraftet mehrere Millisekunden das Eineinhalbfache des
> im Datenblatt angegebenen Wertes für einen Pin, das ist zumindest meine
> Erfahrung
Ein Atmega verkraftet monatelang einen Kurzschluss gegen Vcc oder GND 
ohne merkbaren Schaden. Ich habe das mal an 10 getestet und die dann 
gegen neue Atmega vermessen: auch nach 2 Monaten Kurzschluss keine 
messbaren Unterschiede zu unbelasteten Pins ode Pins neuer AVR.

Stefan U. schrieb:
> Insofern würde ich "in beliebig kurzer Zeit" auf "in beliebig langer
> Zeit" ändern. Es ist in der Praxis lange nicht so dramatisch, wie deine
> Bemerkung anmutet.
So ist es. Man kann sogar einen kompletten Port kurzschließen. Der AVR 
wird heiß, funktioniert aber hinterher trotzdem noch.

xXx schrieb:
> Könnte es nicht so sein, dass der Pin PC7, auf Eingang geschaltet werden
> sollte bevor man ihn abfragt?
Sieh dir einfach mal die innere Beschaltung eines AVR IO-Pins an: den 
Pegel am Pin kannst du immer lesen. Egal, ob der Treiber auf Ein- oder 
Ausgang geschaltet ist.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Ein Atmega verkraftet monatelang einen Kurzschluss gegen Vcc oder GND
> ohne merkbaren Schaden.

Das ist eine gewagte These an deren Korrektheit ich Zweifel hege.
Vielleicht klappt das unter so Randbedngungen wie das der 
Spannungsregler gar nicht genug Strom liefern kann.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Das ist genau so ein Wischiwaschi, wie der maximale Strom von I/O Pins
> bei Mikrochips.

Wenn das Programm den Pin abfragt, ob der Kurzschluss-Fall eingetreten 
ist, dann hab ihr einen Fehler in eurem Schaltungsdesign. Denn ihr habt 
euer System außerhalb der Spezifikation designed.
Das wird euch auf jeden Fall auf die Füße fallen.
Der Kurzschluss muss schaltungstechnisch/programmtechnisch verhindert 
werden. Er darf in keinem Fall auftreten können. Und dann braucht man 
ihn auch nicht abzufragen, da er ja nicht auftreten kann.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Ich habe das mal an 10 getestet und die dann
> gegen neue Atmega vermessen

Und aufgrund dieser Stichprobe gehst du jetzt mit deinem 
Kurzschlusskonzept in deinem Design in Serie?
Sehr gewagt.

Der AtMega ist nicht für Kurzschlüsse am Pin ausgelegt. Wenn das durch 
äußere Gegebenheiten auftreten kann, muss es in einer Vorschaltung 
abgefangen werden.

Und dann braucht man den Pin auch nicht abzufragen.

von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
> Das wird euch auf jeden Fall auf die Füße fallen.

Na wenn du meinst... Das Gute ist, wir müssen uns nicht einige werden.

Wenn die Schaltung zuverlässig funktionieren soll, sollte man zweifellos 
nur das tun, was das Datenblatt zusichert.

Wenn es billig sein soll, dann einfach mal ausprobieren, was geht. Aber 
hinterher nicht rumheulen, wenn ein Bauteil dabei dann doch kaputt geht.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Na wenn du meinst... Das Gute ist, wir müssen uns nicht einige werden.
>
> Wenn die Schaltung zuverlässig funktionieren soll, sollte man zweifellos
> nur das tun, was das Datenblatt zusichert.
>
> Wenn es billig sein soll, dann einfach mal ausprobieren, was geht. Aber
> hinterher nicht rumheulen, wenn ein Bauteil dabei dann doch kaputt geht.

Na also. Da sind wir uns dann doch noch einig geworden.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:

> Ein Atmega verkraftet monatelang einen Kurzschluss gegen Vcc oder GND
> ohne merkbaren Schaden.

Vorsicht!

> Ich habe das mal an 10 getestet und die dann
> gegen neue Atmega vermessen: auch nach 2 Monaten Kurzschluss keine
> messbaren Unterschiede zu unbelasteten Pins ode Pins neuer AVR.

Das ist durchaus glaubhaft, aber nur unter bestimmten Randbedingungen, 
deren wichtigste ist: Es muss ein grosses Gehäuse sein (oder auch ein 
kleines Gehäuse, dann aber auf relativ viel Kupfer darunter).

Der erste Knackpunkt ist nämlich die Verlustleistung. Solange das 
Gebilde die loswerden kann, ohne die Temperatur im Hotspot allzusehr 
ansteigen zu lassen, geht die Sache halbwegs in Ordnung. Eins meiner 
privaten Beispiele dazu: Nutzung zweier (komplementär betriebener) 
Timer-OCR-Ausgänge zum direkten Betrieb eines (magnetdynamischen) 
Lautsprechers im Brückenbetrieb. DDS-PWM, entsprechende Filterschaltung 
natürlich vorher durchgerechnet und hardwaremässig auch tatsächlich 
vorhanden.

Diese Anwendung (näherungsweise Leistungsanpassung, also nichtmal 
wirklich Kurzschluss) schafft es im Dauerbetrieb, einen Mega1284P in 
DIP40 auf ca. 20K über Umgebungstemperatur zu bringen. Das ist 
tatsächlich relativ unkritisch und läuft monatelang im Dauerbetrieb ohne 
jegliche Probleme und es sind auch, genau wie du es beschreibst, danach 
keinerlei Degradationserscheinungen messbar.

AAABERR: mit einem 1284P im 7x7mm VQFN-Gehäuse geht die Sache schon ganz 
anders aus (du ahnst, wie genau...) Und wenn du es nicht wahrhaben 
willst: Probier es einfach selber aus, die Rauchwolke, als Entertainment 
aufgefasst, ist die 7 Euro durchaus wert ;o)

Zu der Abwärmeproblematik kommt allerdings noch ein weiteres Problem 
hinzu, welches allerdings im privaten Umfeld oder Büroumgebungen wohl 
kein Problem darstellt, spätestens in der EMV-Prüfung aber gnadenlos 
aufgedeckt wird. Energieeintrag mit hinreichenden Transienten (Teil der 
EMV-Prüfung) grillt auch die solcherart überlasteten Ausgänge eines 
1284P im DIP40-Gehäuse zuverlässig und hochgradig (nämlich zu 100%) 
reproduzierbar.

Allerdings ist gut möglich, dass dieser Effekt bei einem wirklichen 
Kurzschluss am Ausgang nicht aufgetreten wäre, weil der Energieeintrag 
im konkreten Fall offensichtlich über die Zuleitung zum Lautsprecher 
erfolgt ist und kein gnädiger Kurzschluss sie vom Ausgangstreiber 
ferngehalten hat. Ein wenig Ferrit-Magie an der richtigen Stelle löste 
dieses Problem...

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Stefan U. schrieb:
>> Das ist genau so ein Wischiwaschi, wie der maximale Strom von I/O Pins
>> bei Mikrochips.
>
> Wenn das Programm den Pin abfragt, ob der Kurzschluss-Fall eingetreten
> ist, dann hab ihr einen Fehler in eurem Schaltungsdesign.

Richtig. Ich wollte das auch keinesfalls als empfehlenswertes Design 
darstellen, sondern nur darauf hinweisen, daß es u.U. tatsächlich 
sinnvoll sein kann, den Pegel an einem auf Ausgang geschalteten Pin per 
Zugriff auf das PIN Register zurückzulesen. Als Designpattern taugt das 
so richtig erst bei open-drain Ausgangsstufen.

Was den Defekt des µC angeht - das hängt wesentlich an bishher nicht 
diskutierten Randbedingungen. Die Ausgänge der AVR können IIRC bei 3.3V 
Versorgung ohnehin schon nicht so viel Strom treiben, wie die maximum 
ratings erlauben. In diesem Fall wäre man also schon mal auf der 
sicheren Seite. Ansonsten ist das Limit ein thermisches. Die MOSFET in 
den Ausgangsstufen schnüren früher oder später ab und begrenzen den 
Ausgangsstrom. Die Frage ist, ob die Verlustleistung und die damit 
einher gehende Temperaturerhöhung ausreicht, den Chip permanent zu 
schädigen.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Als Designpattern taugt das
> so richtig erst bei open-drain Ausgangsstufen.

Ich lese auch öfter einen Output Pin ein.
Das erspart ein Flag im Ram.

Kann mich nicht erinnern, da jemals einen falschen Wert bekommen zu 
haben.
Never.

Beitrag #5101856 wurde von einem Moderator gelöscht.
von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Arduino F. schrieb:
> Ich lese auch öfter einen Output Pin ein.
> Das erspart ein Flag im Ram.

Da könntest du aber genauso gut das PORT-Register nehmen.

von Detlev T. (detlevt)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Arduino F. schrieb:
>> Ich lese auch öfter einen Output Pin ein.
>> Das erspart ein Flag im Ram.
>
> Da könntest du aber genauso gut das PORT-Register nehmen.

Kleiner Tipp: Für solche Zwecke haben ATMEGAs General Purpose 
IO-Register (GPIO). Das sind einzelne Bytes von Speicher, die im 
IO-Bereich (0x00-0x3F) liegen und daher sehr effizient angesprochen 
werden können.

von Patrick J. (ho-bit-hun-ter)


Bewertung
0 lesenswert
nicht lesenswert
Hi

Arduino F. schrieb:
> Kann mich nicht erinnern, da jemals einen falschen Wert bekommen zu
> haben.
> Never.

Hier bei mir geht es nicht um einen 'falschen' Wert - bei mir hier geht 
es darum, ob jemand Anders den Pin auf LOW zieht - und Da ist die 
Abfrage, ob der Pin wirklich HIGH ist, nicht die schlechteste Wahl.

MfG

Beitrag #5101939 wurde von einem Moderator gelöscht.
Beitrag #5101944 wurde von einem Moderator gelöscht.
von Patrick J. (ho-bit-hun-ter)


Bewertung
0 lesenswert
nicht lesenswert
... und da sind Sie, die Nazi-Vergleiche :)

Wie war dazu der Fachbegriff?

Jupp, dieser Post darf ohne Bedenken (mit) gelöscht werden.

@Hater
Die paar Takte Unterschied vom aktivem Setzen des Ausgang bis zum 
Einlesen dürften durch ein rjmp oder Interrupt-Aufruf locker erreicht 
werden.
Mich interessiert, ob der IST mit dem SOLL-Zustand überein stimmt.

Mein Ablauf:
- Pin setzen (IN HIGH oder OUT LOW, das HIGH kommt von einem PullUp)
- bei PinChange 'nachsehen', welchen Pgel wir gerade haben und, ob Das 
unser Pegel ist
- bei LOW Außen und HIGH Innen kann ich davon ausgehen, daß da Jemand 
Anders 'funkt'.

Die Zwischenzeit, Die der PIN braucht, um mein aktives Setzen 
umzusetzen, habe ich nach dem nächsten rjmp bereits überbrückt.

Ich sehe in dieser Verzögerung keine Probleme.

MfG

PS: Wobei ich nicht der TO bin - nur nebenbei erwähnt

: Bearbeitet durch User
Beitrag #5101956 wurde von einem Moderator gelöscht.
von c-hater (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Patrick J. schrieb:

> Die paar Takte Unterschied vom aktivem Setzen des Ausgang bis zum
> Einlesen dürften durch ein rjmp oder Interrupt-Aufruf locker erreicht
> werden.

Natürlich. Aber wenn du in Assembler schreibst:

 sbi PORTy, BITx
 sbic PINy, BITx
 rjmp anywhere
 rjmp anywhereelse

wirst du wider Erwarten bei anywhereelse landen. Und, es kann dir auch 
in plain C passieren, dass genau dies passiert, wenn du sinngemäß den 
gleichen Code schreibst. Übrigens ist das gerade dank der relativ guten 
Optimierung des Compilers so...

Nur in dem Arduino kann das nicht passieren, weil der eben einfach lahm 
ist. Genau um die Unterdrückung dieser Information ging es vermutlich 
eigentlich im Wesentlichen bei der Löschung meines Posting. Und genau 
darum, dass ich nicht bereit bin das zu akzeptieren, weil ich das für 
einen niederen Beweggrund halte, geht es hier.

: Bearbeitet durch Moderator
Beitrag #5101979 wurde von einem Moderator gelöscht.
Beitrag #5101994 wurde von einem Moderator gelöscht.
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Das ist eine gewagte These an deren Korrektheit ich Zweifel hege.
Tu das.

c-hater schrieb:
> Aber wenn du in Assembler schreibst:
>  sbi PORTy, BITx
>  sbic PINy, BITx
>  rjmp anywhere
>  rjmp anywhereelse
> wirst du wider Erwarten bei anywhereelse landen.
Kommt drauf an. Auf die Taktfrequenz und die Last am Pin. Im ohmschen 
Normalfall geht es hier wie erwartet nach anywhere...

c-hater schrieb:
> AAABERR: mit einem 1284P im 7x7mm VQFN-Gehäuse geht die Sache schon ganz
> anders aus (du ahnst, wie genau...) Und wenn du es nicht wahrhaben
> willst: Probier es einfach selber aus, die Rauchwolke, als Entertainment
> aufgefasst, ist die 7 Euro durchaus wert ;o)
Werde ich tun.

BTW: die Löschungen deiner Posts könnten in deiner unnötig unmöglichen 
Wortwahl liegen. Ich bin sicher, du weißt, was ich meine. Wenn solche 
Worte zu deinem Umgangsformen gehören, dann lass sie dort. Hierher 
gehören sie jedenfalls nicht.

: Bearbeitet durch Moderator
von S. Landolt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Im ohmschen Normalfall geht es hier wie erwartet nach anywhere
Also bei mir (ein ATmega328P) geht es, wie erwartet, nach anywhereelse.

von S. Landolt (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Und die dazu gehörende Stelle im Datenblatt: "When reading back a 
software assigned pin value, a nop instruction must be inserted as 
indicated in Figure 14-4."

von c-hater (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Lothar M. schrieb:

> Kommt drauf an. Auf die Taktfrequenz und die Last am Pin. Im ohmschen
> Normalfall geht es hier wie erwartet nach anywhere...

OMG.

Nein. Du hast offensichtlich nicht ein AVR8 Datenblatt wirklich 
gelesen...

Wenn schon die Zensoren so derart krass anfähig sind, wie soll sich denn 
dann jemals die Wahrheit durchsetzen?

> BTW: die Löschungen deiner Posts könnten in deiner unnötig unmöglichen
> Wortwahl liegen.

Das kann dann höchstens "Arduidiot" gewesen sein. Ich finde den Begriff 
allerdings auch im Rückblick nicht nur sehr kreativ und lustig, sondern 
obendrein überaus zutreffend...

Aber OK, ich kann voll verstehen, dass er den Arduidioten selber 
vermutlich nicht so gefällt und sie auch nicht in der Lage sind, das 
einfach an sich abgleiten zu lassen, wie erwachsene Nutzer des Internet 
das zu tun in der Lage wären...

Als Kompromiss würde ich der Zensur vorschlagen, in Zukunft einfach nur 
solche mißliebigen Begriffe zu "schwärzen", statt gleich das ganze 
Posting zu löschen...

Oh, ich weiß, dass das geht. Macht allerdings den Zensoren mehr Arbeit. 
So what: Für so viel Macht muss man auch mal ein wenig (mehr) 
arbeiten...

Ihr seid euch doch hoffentlich bewußt, welch große Macht ihr ausübt?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> in Zukunft einfach nur solche mißliebigen Begriffe zu "schwärzen", statt
> gleich das ganze Posting zu löschen...
Habe ich dann ja auch gemacht. Allerdings ist es eben unglaublich 
mühsam, den Dreck anderer wegzuräumen.

c-hater schrieb:
> Nein. Du hast offensichtlich nicht ein AVR8 Datenblatt wirklich
> gelesen...
Doch schon mal. Aber danke für die Erinnerung an dieses Gebastel. Das 
war bei den ersten AVR übrigens noch nicht so, es kam erst mit dem 
ersten Shrink und der dabei eingeführten Synchronisationsstufen an den 
Eingängen.

von Rolf M. (rmagnus)


Bewertung
2 lesenswert
nicht lesenswert
c-hater schrieb:
> Aber OK, ich kann voll verstehen, dass er den Arduidioten selber
> vermutlich nicht so gefällt und sie auch nicht in der Lage sind, das
> einfach an sich abgleiten zu lassen, wie erwachsene Nutzer des Internet
> das zu tun in der Lage wären...

Erwachsene Nutzer sollten aber auch in der Lage sein, Postings ohne 
Beschimpfungen zu verfassen.

> Als Kompromiss würde ich der Zensur vorschlagen, in Zukunft einfach nur
> solche mißliebigen Begriffe zu "schwärzen", statt gleich das ganze
> Posting zu löschen...

Ich schlage vor, solche Begriffe ganz einfach nicht zu verwenden, wenn 
du nicht willst, dass deine Postings gelöscht werden.

> Oh, ich weiß, dass das geht. Macht allerdings den Zensoren mehr Arbeit.
> So what: Für so viel Macht muss man auch mal ein wenig (mehr)
> arbeiten...

Nur weil du dich nicht beherrschen kannst, sollen andere sich extra 
Arbeit machen? Lass die Beleidigungen einfach weg, dann wird auch nix 
gelöscht, und niemand hat irgendwelche Arbeit damit, deine Posting davon 
zu bereinigen. Die Moderatoren sind doch nicht deine Putzfrauen, die 
hinter dir her wischen...

> Ihr seid euch doch hoffentlich bewußt, welch große Macht ihr ausübt?

In den Nutzungsbedingungen steht klar, dass Beiträge, die Beleidigungen 
enthalten, gelöscht werden. Nicht vom Moderator so umformuliert, dass 
sie den Regeln entsprechen, sondern gelöscht!

von S. Landolt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Das war bei den ersten AVR übrigens noch nicht so,
> es kam erst mit dem ersten Shrink und der dabei
> eingeführten Synchronisationsstufen an den Eingängen.

Wann soll das gewesen sein - beim AT90S1200?
Mein ältester, ein AT90S8515-8PI von 9825, verhält sich genauso.

von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
c-hater schrieb:
> Das kann dann höchstens "Arduidiot" gewesen sein. Ich finde den Begriff
> allerdings auch im Rückblick nicht nur sehr kreativ und lustig, sondern
> obendrein überaus zutreffend...

Schade dass fachliche und soziale Kompetenz nicht immer in Personalunion 
in Erscheinung treten. Du bewegst dich, in Sachen sozialer Kompetenz, 
eher auf den Niveau einer Bordsteinkante.

Zur Erinnerung:
Das Grundgesetz spricht von "Würde".
Und das Strafgesetz kennt die "Beleidigung".

Du bewegst dich mit deinen Äußerungen im strafbaren Bereich, und findest 
das auch noch toll. Sogar stolz drauf.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
S. Landolt schrieb:
> Mein ältester, ein AT90S8515-8PI von 9825, verhält sich genauso.
Mhmmmm...
Offenbar trügt mich die Erinnerung. Ich finde da auch nichts mehr. Oder 
ich verwechsle das tatsächlich mit dem 8051.
Dieses Verhalten ist aus meiner Sicht als Hardware-Designer sowieso ein 
Fehler im Silizium. Aber wie heißt es so schön: "Wir waren jung und 
brauchten das Geld!"   ;-)

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
@Arduino Fanboy

Du hast zwar Recht aber dein Beitrag ist auf ebenso niedrigem Nieveau. 
Nur die Wortwahl ist gepflegter. Lass ihn doch einfach, jeder bekommt 
irgendwann die gerechte Strafe für sein Handeln - sei es durch andere 
oder weil sie sich irgendwann selbst in die Sch*** rein reitet. Da muss 
man gar nicht nachhelfen.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.