PIN vs PORT beim OUTPUT

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

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...

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 ;-)

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!

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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!

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.

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.

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.

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?

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.

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.

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.

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.

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.

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

... 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

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.

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.

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!

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!"   ;-)