www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Mikroprozessor trifft auf falschen Opcode, was passiert?


Autor: Bert Hurtig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ihr,
ich hätte da mal eine Frage zum Mikroprozessor, also was passiert genau, 
wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein 
Mikroprogramm befindet, also wenn eine nicht belegte Speicherstelle im 
ROM angesprochen wird?
Oder anders gesagt, wenn durch einen bösen Zufall ein ungültiger 
Assemblerbefehl in den Arbeitspeicher geschrieben wird (beim 8085 zB 
FDH).
Meine Frage bezieht sich jetzt speziell auf den 8085, aber 
wahrscheinlich ist die reaktion bei den anderen Mikroprozessoren 
ähnlich.
Oder gibt es gar keine Reaktion und der Programm-Counter wird einfach im 
1 erhöht um den nächsten Befehl anzusprechen?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bert Hurtig schrieb:
> Hallo Ihr,
> ich hätte da mal eine Frage zum Mikroprozessor, also was passiert genau,
> wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein
> Mikroprogramm befindet, also wenn eine nicht belegte Speicherstelle im
> ROM angesprochen wird?

Was genau passiert, hängt von der CPU ab.

Manche werfen eine Exception, wieder andere ignorieren den Befehl, 
andere tun tatsächlich irgendetwas mehr oder weniger Sinnvolles, was 
sich aus dem Aufbau des OpCodes ergibt.

Wie es beim 8085 ist, weiß ich jetzt nicht. Aber bei einem seiner 
populären 'Nachfolger', dem Z80, gab es durchaus brauchbare 
'undokumentierte Befehle', die auch benutzt wurden.

Kannst dich ja mal auf die Suche machen. Das Bitmuster für FDH 
aufschreiben und dann alle Befehle durchgehen, die in diesem Bitmuster 
ihren konstanten OpCode Teil wiederfinden. Die Bits die im Opcode 
variabel sind (meistens irgendwelche Registernummern) ergänzt du dann 
aus FDH und siehst nach ob die CPU diesen Befehl tatsächlich ausführt.

Autor: Mike J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meist führt das zu einem Neustart, schau dir mal an was im leeren 
Speicher steht. (0xFF oder 0x00)

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wahrscheinlich ist die reaktion bei den anderen Mikroprozessoren
> ähnlich.

Nein, die Reaktionen sind sehr unterschiedlich, und können sogar bei 
gleichem Mikroprozessor von der konkreten Masken-Revision abhängen.

Die Reaktionen gehen von "es passiert gar nichts" über "der Prozessor 
führt den Illegal-Opcode-Handler aus" bis "die CPU hängt sich auf" und 
im Extremfall (sehr selten) "der Prozessor wird beschädigt".

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bert Hurtig schrieb:

> wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein
> Mikroprogramm befindet

Mikroprogrammierung zur Ausführung von Opcodes ist nicht universell 
verbreitet. Andererseits darf man bei mikropogrammierten CPUs von einem 
definierten Verhalten bei undefinierten Opcodes ausgehen, denn sowas wie 
unbelegte ROM-Plätze gibt es nicht (irgendwas steht immer drin), 
während einfache nicht mikroprogrammierte CPUs mitunter eben das machen, 
was sich als Schmutzeffekt aus unvollständiger Dekodierung ergibt. Man 
hat da schon welche gesehen, in der bestimmte Codes sozusagen zwei 
verschiedene Operationen gleichzeitig ausführten.

Autor: Bert Hurtig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die schnellen antworten!
Also mein Problem ist ich habe nur einen Simulator zur Hand um es beim 
8085 zu testen.
Dieser bringt dann die Meldung: "Trap: Opcode 0000H ERROR" (0000h ist 
die Speicheradresse wo ich FDH reingeschrieben habe). Er geht nach der 
Meldung aber normal zum nächsten Befehl weiter. Jetzt weiß ich nicht ob 
das mit der Realität übereinstimmt. Vielleicht weiß das ja jemand...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bert Hurtig schrieb:

> Dieser bringt dann die Meldung: "Trap: Opcode 0000H ERROR" (0000h ist
> die Speicheradresse wo ich FDH reingeschrieben habe). Er geht nach der
> Meldung aber normal zum nächsten Befehl weiter. Jetzt weiß ich nicht ob
> das mit der Realität übereinstimmt. Vielleicht weiß das ja jemand...

Das ist das schöne an undefinierten Opcodes. Das Verhalten ist 
undefiniert, folglich weiss niemand ausser dem Entwickler des Cores, was 
dabei genau passiert. Und da es längst nicht mehr nur den 
Original-Intel-Core mit seiner 12fach-Taktung gibt, kann sich das u.U. 
bei verschiedenen Cores unterscheiden.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bert Hurtig schrieb:
> Danke für die schnellen antworten!
> Also mein Problem ist ich habe nur einen Simulator zur Hand um es beim
> 8085 zu testen.

Simulatoren sind da meistens pingeliger bzw. bilden die tatsächlich in 
der Hardware vorhandenen Decodierlogik nicht exakt ab.

> Dieser bringt dann die Meldung: "Trap: Opcode 0000H ERROR" (0000h ist
> die Speicheradresse wo ich FDH reingeschrieben habe). Er geht nach der
> Meldung aber normal zum nächsten Befehl weiter. Jetzt weiß ich nicht ob
> das mit der Realität übereinstimmt.

Nein.
Was die Intel-8085 genau macht, weiß ich nicht. Aber einen Illegal 
Opcode Trap macht sie mit Sicherheit nicht. Ich denke eheer, bedenkt man 
das Alter der CPU, dass sie sich einen Befehl aus dem OpCode 
zusammensynthetisiert. Ob der irgendetwas Sinnvolles macht, müsste man 
ausprobieren.

Oder danach googlen
"8085 undocumented opcode" scheint mir erfolgversprechend.

Edit:
Da haben wirs ja schon
http://electronicerror.blogspot.com/2007/08/undocu...

Ein FDH macht einen
Jump to location addr if K flag is set.

Wobei das 'K-Flag' ein nicht benutztes Bit im Statusregister F ist.

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bert Hurtig schrieb:
> ich hätte da mal eine Frage zum Mikroprozessor, also was passiert genau,
> wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein
> Mikroprogramm befindet, also wenn eine nicht belegte Speicherstelle im
> ROM angesprochen wird?

Naja, eine nicht belegte Speicherzelle ist oft gleichzusetzen mit dem 
Wert 0xFF. Der Opcode 0xFF korreliert häufig mit der Anweisung NOP. 
Manchmal werden auch einfach alle "illegalen" Opcodes als NOP 
interpretiert.

> Oder anders gesagt, wenn durch einen bösen Zufall ein ungültiger
> Assemblerbefehl in den Arbeitspeicher geschrieben wird

Der STM8 macht einfach einen Reset. Sinnvoller Weise wird im 
Statusregister das Illegal-Opcode-Flag gesetzt.
"Illegal opcode reset: If a code to be executed does not correspond to 
any opcode or prebyte value, a reset is generated. [...]
Bit 2 of Reset Status Register - ILLOPF: Illegal opcode reset flag:
0: No ILLOP reset occurred
1: An ILLOP reset occurred"

> Meine Frage bezieht sich jetzt speziell auf den 8085,

Dann schreib' das doch bitte in Zukunft auch ins Subject, das würde die 
Sache ungemein erleichtern, da ich den Fred als Nichtlesenswert gleich 
übersprungen hätte. Tagging z.ß. wurde schon im vorigem Jahrtausend 
erfunden. Das hast Du nun davon: Du kriegst eine (unpassende) Antwort. 
;-)

> aber wahrscheinlich ist die reaktion bei den anderen Mikroprozessoren
> ähnlich.

Eben nicht! Von der Interpretation als NOP bis hin zum ILLOP-Interrupt 
ist alles möglich und wird auch alles implementiert.

> Oder gibt es gar keine Reaktion und der Programm-Counter wird einfach im
> 1 erhöht um den nächsten Befehl anzusprechen?

Auch möglich. Leider kann ich zum 808x im Speziellen nichts sagen, da 
ich damit "noch" nichts gemacht habe.

Iwan

Autor: Bert Hurtig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So dann scheint das wohl geklärt, danke nochmal an alle geht ja echt fix 
hier.
Besonders der Link ist interessant, danke Karl heinz Buchegger !

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bert Hurtig schrieb:
> wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein
> Mikroprogramm befindet,

kann beim 8085 nicht passieren, da die OpCodes beim 8085 von 00h bis FFh 
gehen.
D.h. jeder Wert wird als OpCode oder als Adresse gewertet, je nachdem ob 
der Befehl davor ein 1-Byte, 2-Byte oder 3-Byte Befehl war.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
im Übrigen steht beim 8085 00h für NOP

Autor: 8085 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... schrieb:
> kann beim 8085 nicht passieren, da die OpCodes beim 8085 von 00h bis FFh
>
> gehen.

Beim 8085 sind nur 246 Opcodes definiert.

Bei 10 Bitmustern ist das Verhalten (mir jedenfalls) nicht
bekannt.

8085

Autor: Michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>wenn im Arbeitspeicher ein Operationscode steht, hinter dem sich kein
>Mikroprogramm befindet, also wenn eine nicht belegte Speicherstelle im
>ROM angesprochen wird?
Dir fehlen ja alle Grundlagen! Ein 8085 holt sich kein Mikroprogramm, 
weil es da sowas nicht gibt. Wenn ein falscher Befehl im ROM/RAM steht, 
ist entweder falsch programmiert oder der ROM/RAM ist defekt!
Und was ist ein ungültiger Befehl? Und wenn er eben auf "FDH" trifft, 
dann macht er es dann auch!
Oder machst du dir Gedanken um die undefinierten Befehle des Z-80? Ich 
glaube, der FDH ist so einer. Dies wäre aber ein ganz neues Thema.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich frage mich auch wie man einen falschen Opcode auf den µC bekommt, 
der Assembler stellt in diesem Fall ja keine File zum Flashen her, die 
einzige Möglichkeit wäre es, das nachträglich im Programm Flash-oder 
-ROM eine Speicherzelle kaputt geht oder kippt.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>ich frage mich auch wie man einen falschen Opcode auf den µC bekommt,
>der Assembler stellt in diesem Fall ja keine File zum Flashen her, die
>einzige Möglichkeit wäre es, das nachträglich im Programm Flash-oder
>-ROM eine Speicherzelle kaputt geht oder kippt.

Ganz einfach:

 Programm
 .db XY,....
 Programm

MfG Spess

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

illegale Opcodes haben schon auf dem 6510 im C64 genervt, da wurden die 
gern genommen, um den Hackern das Hacken schwerer zu machen.

Naja, die meisten Disassembler konnten die dann eben mit 
disassemblieren, die benutzte Mnemotic war nur nicht richtig genormt. ;)

Beim Z80 und dem Nachbau U880 aus DDR-Fertigung war so zumindest sicher, 
daß es ein 1:1 Nachbau war. Alle illegalen Opcodes gingen genauso.

Gruß aus Berlin
Michael

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8085 schrieb:
> Bei 10 Bitmustern ist das Verhalten (mir jedenfalls) nicht
> bekannt.

siehe 
http://electronicerror.blogspot.com/2007/08/undocu...

Autor: Bernhard R. (barnyhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zurück zur Ausgangsfrage:
Was passiert, wenn ein Programm auf einen nicht definierten Opcode 
trifft?

Ich erweitere die Frage:
Was passiert, wenn ein Programm auf eine Instruktion trifft, die im 
derzeitigen Status des Systems nicht ausführbar ist, z.B.
- Undefinierter Opcode
- Schreiben auf Read-Only Speicher
- Zugriff außerhalb des existierenden Speichers
- Warten auf ein Ereignis, während das Interruptsystem gesperrt ist
- ...

Und die präzise Antwort:
Dann passiert genau das, was die Entwickler der betreffenden CPU für 
diese Situation implementiert haben, z.B. (nicht unbedingt vollständig, 
aber auf jede CPU zutreffend)
- es wird ein Interrupt geworfen
- es wird eine halbwegs sinnvolle undokumentierte Instruktion ausgeführt
- die Operation wird als NO OP ausgeführt
- ein Speicherzugriff läuft ins Leere
- es kommt eine Fehlermeldung auf der Operator-Konsole (z.B. IBM 
Z-Serie)
- ...

Für manche CPU ist das Verhalten dokumentiert, für manche nicht.

Bernhard

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard R. schrieb:

> Dann passiert genau das, was die Entwickler der betreffenden CPU für
> diese Situation implementiert haben,

Da du die Frage erweitert hast, kannst du auch diese Antwort erweitern. 
Es passiert das, was sich
* die Entwickler übelegt haben, das passieren soll
* sich zufällig durch die Art der Verschaltung ergibt.

Worauf ich raus will: Du hast die Punkte angesprochen

- Schreiben auf Read-Only Speicher
- Zugriff außerhalb des existierenden Speichers

einer Z80 ist es egal, wenn sie auf ein EPROM schreibt. Die macht 
einfach ihren Schreibzyklus. Ob da im Speicher tatsächlich etwas dabei 
passiert, interessiert die CPU nicht.
Früher war es bei kleinen Systemen gang und gäbe, dass die 
Adressdekodierung nicht vollständig gemacht wurde. Da konnte es dann 
schon sein, dass derselbe physische Speicher 2 oder mehrmals im 
Adressraum der CPU auftauchte. Änderte man die Speicherzelle (aus Sicht 
der CPU) an der Adresse 0x3003, dann hat man damit auch automatisch 
0x7003, 0xB003, 0xF003 verändert, weil all diese Adressen auf denselben 
physischen Speicher gemappt wurden.
Hat das jemanden gestört? Nein. Am allerwenigsten die CPU :-)
Der CPU ist es auch egal, ob sich an einem CS Ausgang des Adressdekoders 
tatsächlich ein RAM-Chip befindet oder nicht. Die legt ihre Signale auf 
den Bus und tut so als ob da etwas wäre.

Natürlich kann man das alles auch abstellen. In der Adressdekodierung, 
dort wo die Chip-Select Signale anfallen, könnte man die CS für die 
EPROMs abzweigen, mit dem WR Signal verknüpfen und auf einen Interrupt 
Eingang der CPU führen und so einen Schreibzugriff auf das EPROM 
detektieren.

Man könnte auch den Adressdekoder vollständig machen, bzw. wieder die 
Rückmeldung über einen Interrupt liefern: Da wo du schreibst, gibt es 
gar keinen Speicher.

Aber all das hat letzten Endes immer Silizium gekostet und war 
verhältnismässig teuer. Einfacher ist es dem Programmierer zu sagen: So 
ist die Situation, nutz sie nicht aus und leb damit. Wenn du sie aber 
ausnutzt, dann Wasche ich meine Hände in Unschuld, du musst selber 
wissen was du tust.

Langer Rede kurzer Sinn:
begiebt man sich in das Gewässer undokumentierter Befehle, ungültiger 
Adressen, ungültiger Hardware-Zugriffe, kann alles Mögliche und Denkbare 
passieren. Es ist zwar auf einer speziellen Hardware ein immer gleiches 
verhalten, aber 15 unterschiedlich aufgebaute Boards können 15 
unterschiedliche Verhaltensweisen an den Tag legen.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard R. schrieb:
> Dann passiert genau das, was die Entwickler der betreffenden CPU für
> diese Situation implementiert haben

was ist, wenn diese nichts expliziertes implementiert haben.
dh, die dekodierlogik (insofern es keine mikroprogramm-gesteuerte 
Maschine ist) hängt in einem undefiniertem Zustand. Was da passsiert, 
hängt von der individuellen (für jede Hardwarerevision) Verschaltung des 
Dekoders ab.
Es kann quasi alles mögliche passieren. Die Schaltung ist ja 
höchstwahrscheinlich auf die möglichen Eingabewörter optimiert, so dass 
eventuell nicht alle Bits eines OP-Code getestet werden, wenn bekannt 
ist, dass es keine spezifizierten Codes mit diesen Bits gibt. Was dann 
im Decoder passiert ist Zufall. Wenn dadurch zB irgendwelche internen 
Treiber falsch angesteuert werden, kann das, wie oben bereits erwähnt, 
auch zur Zerstörung der CPU/MCU führen.

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:
> Wenn dadurch zB irgendwelche Treiber
> falsch angesteuert werden, kann das, wie oben bereits erwähnt, auch zur
> Zerstörung der CPU/MCU führen.

ich glaube (hoffe) nicht dass die Entwickler sowas nicht abgefangen 
haben,
das wäre ja schon grob fahrlässig,
es kann doch jederzeit vorkommen dass durch einen Bug z.B. der Stack 
zerschossen wird und der Rücksprung dadurch irgendwohin, also evtl. auch 
auf einen illegalen opcode erfolgt

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:

> Wenn dadurch zB irgendwelche internen
> Treiber falsch angesteuert werden, kann das, wie oben bereits erwähnt,
> auch zur Zerstörung der CPU/MCU führen.

Theroretisch möglich, praktisch ziemlich ausgeschlossen. Dass eine 
Maschine auf undefinierte Opcodes stösst ist im Rahmen von Programm- und 
Speicherfehlern sehr oft der Fall, gehört somit also zum Regelbetrieb. 
Da darf dann nicht jedesmal die Maschine in die Luft fliegen.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube, das mir dem CPU zerstören, ist eher ein historisches 
Ereigniss ;)

Ich erinnere mich mal gehört zu haben, dass es ein System gab, auf dem 
eine bestimmte (verbotene) Instruktionsfolge zum durchbrennen eines 
Widerstands in der CPU geführt hat. An mehr Deteils kann ich mich leider 
nicht erinnern.

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ich glaube (hoffe) nicht dass die Entwickler sowas nicht abgefangen
>haben,
>das wäre ja schon grob fahrlässig,

Wieso das denn ?

Man darf auch nicht vergessen, dass der 8085 schon in den Siebzigern auf 
den Markt kam. Da gab es noch kein VHDL oder Verilog, wo man einfach 
eine others -> "0000" Option hatte.

Da wurde das Ganze noch schön von Hand aufgemalt und zum Verifizieren 
wurden diskrete Logikgatter gewrappt und man hatte genug zu tun, die 
dokumentierten Dinge ans Laufen zu kriegen.

Ich würde stark annehmen, dass der einfach irgendwas macht, aber nichts 
definiertes.

Gruss
Axel

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel schrieb:

>>ich glaube (hoffe) nicht dass die Entwickler sowas nicht abgefangen
>>haben, das wäre ja schon grob fahrlässig,
>
> Wieso das denn ?

Weil ein CPU-Entwickler, der sowas zulässt, seinen Brötchengeber in den 
Ruin treiben kann. Da es wie schon beschrieben durchaus zum Regelbetrieb 
gehört, auf undefinierte Opcodes zu stossen, wäre ein entsprechender 
Defekt ein Gewährleistungsfall.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel schrieb:

> Ich würde stark annehmen, dass der einfach irgendwas macht, aber nichts
> definiertes.

Wie man an der oben verlinkten Liste undefinierter Opcodes des 8085 
erkennen kann ist deren Funktion alles andere als zufällig. Ganz im 
Gegenteil, diese Operationen sind/wären teilweise ungemein nützlich und 
sind garantiert absichtlich so entstanden.

Autor: Michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn CPU und Treiberbausteine beide auf Ausgang sind und dann 
gegeneinander kämpfen, gewinnt der Stärkere. Das ist heute noch so.
Und wer auf 0000H (Programmstart nach RESET) bewußt so einen Befehl 
setzt, dem ist nicht zu helfen. Da fehlt ja noch jegliche 
Initialisierung!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Inwiefern muss man die 8085-CPU initialisieren, abgesehen vom 
Reset-Signal?

Dass man ein Rechnersystem mit 8085 im Zentrum so bauen kann, dass 
bestimmte Operationen den Rauch rauslassen ist klar. Aber das hat dann 
nichts mit undefinierten Opcodes zu tun, sondern mit undefinierten 
Bus/IO-Operationen oder -Sequenzen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael_ schrieb:
> Wenn CPU und Treiberbausteine beide auf Ausgang sind und dann
> gegeneinander kämpfen, gewinnt der Stärkere.

Im Prinzip ja.
Allerdings:
* sind es nur wenige Opcodes, deren Funktion nicht offiziell
  dokumentiert ist.

* das Durchbrennen findet nicht in Nanosekunden statt, d.h. mit
  dem nächsten Befehl geht die CPU ja wieder in einen definierten
  Zustand über

Wenn du an einem AVR zwei Pins verbindest und beide auf Ausgang mit 
unterschiedlichem Potential programmierst, so ist das sicherlich nicht 
gut für die Ausgangstreiber, aber ein bischen was halten die schon auch 
aus.
Du stirbst ja auch nicht sofort am Blutverlust, wenn du dich mit dem 
Messer schneidest.

Autor: Michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Autor: Karl heinz Buchegger (kbuchegg) (Moderator)
>Datum: 13.04.2010 19:03

>Ein FDH macht einen
>Jump to location addr if K flag is set.
>Wobei das 'K-Flag' ein nicht benutztes Bit im Statusregister F ist.

Na wie ist das K-Flag nach RESET? Und was soll da gleich ein Sprung nach 
????
Und ein 8085/Z-80 braucht ja noch Stack, CTC, PIO DMA... , die wollen 
alle wissen was los ist.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael_ schrieb:
>>Autor: Karl heinz Buchegger (kbuchegg) (Moderator)
>>Datum: 13.04.2010 19:03
>
>>Ein FDH macht einen
>>Jump to location addr if K flag is set.
>>Wobei das 'K-Flag' ein nicht benutztes Bit im Statusregister F ist.
>
> Na wie ist das K-Flag nach RESET? Und was soll da gleich ein Sprung nach
> ????
> Und ein 8085/Z-80 braucht ja noch Stack, CTC, PIO DMA... , die wollen
> alle wissen was los ist.

Schau. Dasselbe passiert doch auch wenn du in andere Befehle schräg 
einsteigst. Machst du einen

.org 0010H
   C3 CD 00      ; jump to 0x00CD
   C9            ; ret

und springst du irrtümlich nach 0011H, dann wird der CD als Call 
ausgeführt auf die Adresse C900H. Was dann in weiterer Folge passiert, 
ist schwer zu durchschauen (dort könnte man ja wieder quer in einen 
Mehrbytebefehl eingestiegen sein). Aber deswegen brennt nicht gleich die 
CPU ab. Sie macht irgendwas, so wie sie immer irgendwas macht. Ob das 
K-Flag beim Reset einen definierten Zustand hat oder nicht, können dir 
wahrscheinlich nur die Entwickler sagen. Und wenn du als erste 
Instruktion einen FDH hast, dann hast du den dort eben. Mit allen 
Konsequenzen. Wenn sich das dann so auswirkt, dass Bustreiber 
minutenlang gegeneinander arbeiten, klar, dann wird irgendwann einer 
aufgeben.

Programmieren bedeutet nun mal: Wissen was man tut. Programmieren auf 
Assemblerebene ohne Betriebssystem bedeutet: die volle Verantwortung 
übernehmen, ohne Netz und doppelten Boden. Aber es ist auch nicht so, 
dass beim geringsten Fehler sofort der magische Rauch entweicht.

Autor: Michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Verbindung von undefinierten Befehlen und zerstörter Hardware
>Ich glaube, das mir dem CPU zerstören, ist eher ein historisches
>Ereigniss ;)
>Ich erinnere mich mal gehört zu haben, dass es ein System gab, auf dem
>eine bestimmte (verbotene) Instruktionsfolge zum durchbrennen eines
>Widerstands in der CPU geführt hat. An mehr Deteils kann ich mich leider
>nicht erinnern.
 habe ich nicht gemeint.
Es sind zwei weiter oben getrennt angebrachte Themen.
Natürlich gehen undok. Befehle und eine CPU, die das versteht, recht 
gut.
"Man muß nur wissen was man tut".

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://en.wikipedia.org/wiki/Halt_and_Catch_Fire

Und Seite 65 in 
ftp://reports.stanford.edu/pub/cstr/reports/csl/tr/86/289/CSL-TR-86-289. 
pdf

Autor: bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber es ist auch nicht so, dass beim geringsten Fehler sofort der magische Rauch 
entweicht.

Üblicherweise nicht, ausser beim 6502. Den konnte man per Software 
grillen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bensch schrieb:

> Üblicherweise nicht, ausser beim 6502. Den konnte man per Software
> grillen.

Wie?

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> bensch schrieb:
>
>> Üblicherweise nicht, ausser beim 6502. Den konnte man per Software
>> grillen.
>
> Wie?

Kenne ich auch nicht und das als alter Knochen, der auf dem PET in 
Hexcode(!) programmierte. Aber es gab die Geschichte beim C64, wo man 
wohl den Videocontroller durch falsche Registereinstellungen zu heiß 
werden lassen konnte und dieser sich dann dauerhaft verabschiedete. Der 
war aber sowieso jenseits von Gut und Böse, was das thermische 
Management angeht.


Prinzipiell muß man aber bei diesem Thema sowieso streng nach CPU 
unterscheiden. Die früheren machten bei undefinierten OpCodes irgendwas. 
Scherte niemanden. Später wurde das bei neuen Designs auch 
berücksichtigt und heute ist es eher Standard, das die CPU definiert aus 
dem undefinierten Zustand rausgeht und das meist auch reported!

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard R. schrieb:
> Ich erweitere die Frage:
> Was passiert, wenn ein Programm auf eine Instruktion trifft, die im
> derzeitigen Status des Systems nicht ausführbar ist, z.B.

Man könnte die Fragstellung auch völlig zwanglos folgendermaßen 
erweitern:

   Warum ist die Banane krumm?

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:
> Wenn dadurch zB irgendwelche internen
> Treiber falsch angesteuert werden, kann das, wie oben bereits erwähnt,
> auch zur Zerstörung der CPU/MCU führen

Ein Beispiel dafür war die HP-3000. Die konnte man per Microprogramm 
schrotten. Dazu brauchte man noch nichtmal ungültige Opcodes. (Das Gerät 
war ursprünglich vom Anwender microprogrammierbar, was dann aber schnell 
abgestellt wurde.)

Für die alten Rechner mit Ringkernspeicher gab es noch einen viel 
simpleren Trick, den Speicher zu schlachten:

   jmp $

die kleinste unendliche Schleife. Sie brachte bei manchen Maschinen den 
Kernspeicher zum Glühen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb:

> Aber es gab die Geschichte beim C64, wo man
> wohl den Videocontroller durch falsche Registereinstellungen zu heiß
> werden lassen konnte und dieser sich dann dauerhaft verabschiedete.

Das hat dann aber nichts mit dem 6502-Prozessor zu tun und es wird auch 
nicht der Prozessor gegrillt, sondern der Videocontroller.

Grafikkarten, die ja nach wie vor die Timings programmierbar gestalten, 
kann man sicherlich auch heute noch (bzw. erst recht) in Nullkommanix 
ins Nirvana jagen. Nur hat an dem Ende kein Programmierer ausserhalb des 
Herstellers irgendwas verloren.

Aktuelle Prozessoren kann man mit speziellen Befehlssequenzen u.U. 
soweit treiben, dass die übliche Kühlung grenzwertig bis ungenügend 
wird. Gekühlt wird nicht unbedingt auf maximal mögliche Leistung, 
sondern auf die Thermal Design Power (oder so ähnlich) des gehobenen 
Normalbetriebs bei aktiver CPU. Daher finden sich dort thermische 
Sicherungen, zuerst mit Betriebssystem/BIOS-Support zum runtertakten, 
danach ggf. als Notnagel hardwired mit eingelegten Zwangspausen. Was 
dazu führt, dass arg staubgeplagte Rechner durch einfaches Säubern 
schneller werden können.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Abdul K. schrieb:
>
>> Aber es gab die Geschichte beim C64, wo man
>> wohl den Videocontroller durch falsche Registereinstellungen zu heiß
>> werden lassen konnte und dieser sich dann dauerhaft verabschiedete.
>
> Das hat dann aber nichts mit dem 6502-Prozessor zu tun und es wird auch
> nicht der Prozessor gegrillt, sondern der Videocontroller.

Ja schön A.K. Finde ich toll, wenn du mich nur halb zitierst. Arbeitest 
du bei BILD?


>
> Grafikkarten, die ja nach wie vor die Timings programmierbar gestalten,
> kann man sicherlich auch heute noch (bzw. erst recht) in Nullkommanix
> ins Nirvana jagen. Nur hat an dem Ende kein Programmierer ausserhalb des
> Herstellers irgendwas verloren.

Früher auch gerne den dahinterliegenden Monitor!


>
> Aktuelle Prozessoren kann man mit speziellen Befehlssequenzen u.U.
> soweit treiben, dass die übliche Kühlung grenzwertig bis ungenügend
> wird. Gekühlt wird nicht unbedingt auf maximal mögliche Leistung,
> sondern auf die Thermal Design Power (oder so ähnlich) des gehobenen
> Normalbetriebs bei aktiver CPU. Daher finden sich dort thermische
> Sicherungen, zuerst mit Betriebssystem/BIOS-Support zum runtertakten,
> danach ggf. als Notnagel hardwired mit eingelegten Zwangspausen. Was
> dazu führt, dass arg staubgeplagte Rechner durch einfaches Säubern
> schneller werden können.

Ist das eigentlich irgendwie standardisiert? Ich glaube, bei mir kam das 
auch mal vor. CPU-Lüfter blieb stehen, der Rechner ging aus, aber das 
Netzteil war noch an. Ist das in jedem BIOS anders?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:

> Ein Beispiel dafür war die HP-3000. Die konnte man per Microprogramm
> schrotten.

Yep, per Mikroprogramm ist sowas weit wahrscheinlicher. Auf der Ebene 
gilt Schrott rein Schrott^2 raus.

> die kleinste unendliche Schleife. Sie brachte bei manchen Maschinen den
> Kernspeicher zum Glühen.

Laut obigem HCF-Link eher zum Qualmen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb:
> A. K. schrieb:
>> Abdul K. schrieb:
>>
>>> Aber es gab die Geschichte beim C64, wo man
>>> wohl den Videocontroller durch falsche Registereinstellungen zu heiß
>>> werden lassen konnte und dieser sich dann dauerhaft verabschiedete.
>>
>> Das hat dann aber nichts mit dem 6502-Prozessor zu tun und es wird auch
>> nicht der Prozessor gegrillt, sondern der Videocontroller.
>
> Ja schön A.K. Finde ich toll, wenn du mich nur halb zitierst. Arbeitest
> du bei BILD?

Zitate sinnvoll zu kürzen gehört eigentlich zu den Netiketten. Was habe 
ich verfälscht?

> Ist das eigentlich irgendwie standardisiert? Ich glaube, bei mir kam das
> auch mal vor. CPU-Lüfter blieb stehen, der Rechner ging aus, aber das
> Netzteil war noch an. Ist das in jedem BIOS anders?

Ich stecke da nicht so tief drin. Es gibt allerdings heutzutage durchaus 
mehr Schnittstellen zwischen Betriebssystem und dem "BIOS" als man aus 
DOS-Zeiten so kennt. Der ganze Kram rund um ACPI, System Management Mode 
und sowas. Deshalb hängt ja auch der Support für die diversen 
Schlafzustände des Rechners so stark am BIOS.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Für die alten Rechner mit Ringkernspeicher gab es noch einen viel
> simpleren Trick, den Speicher zu schlachten:
>
>    jmp $
>
> die kleinste unendliche Schleife. Sie brachte bei manchen Maschinen den
> Kernspeicher zum Glühen.

Das ist wohl eher in den Bereich der Folklore einzuordnen. Kernspeicher 
reagiert recht empfindlich auf Temperaturschwankungen. Deshalb hatte der 
Speicher entweder Temperatursensoren, um die Schreib- und Leseströme an 
die Temperatur anzupassen, oder eine Heizung, um die Temperatur konstant 
zu halten (bei um die 40℃).

Bis da irgendwas anfängt zu glühen hätte der Speicher schon lange keine 
korrekten Daten mehr geliefert, und damit hätte die CPU auch den "jmp 
$"-Befehl nicht mehr sauber gelesen und ausgeführt, womit die Schleife 
durchbrochen gewesen wäre (wenn auch auf undefinierte Art und Weise, 
womit wir wieder beim Thema wären ;-)

Andreas

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Abdul K. schrieb:
>> A. K. schrieb:
>>> Abdul K. schrieb:
>>>
>>>> Aber es gab die Geschichte beim C64, wo man
>>>> wohl den Videocontroller durch falsche Registereinstellungen zu heiß
>>>> werden lassen konnte und dieser sich dann dauerhaft verabschiedete.
>>>
>>> Das hat dann aber nichts mit dem 6502-Prozessor zu tun und es wird auch
>>> nicht der Prozessor gegrillt, sondern der Videocontroller.
>>
>> Ja schön A.K. Finde ich toll, wenn du mich nur halb zitierst. Arbeitest
>> du bei BILD?
>
> Zitate sinnvoll zu kürzen gehört eigentlich zu den Netiketten. Was habe
> ich verfälscht?
>

Du hast den Fokus verändert. Von meinem "ich kenne das nicht von der 
CPU, aber vom Videocontroller" zu "Das hat dann aber nichts mit dem 
6502-Prozessor zu tun ... sondern der Videocontroller."

Ist aber nicht so wichtig.

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie man an der oben verlinkten Liste undefinierter Opcodes des 8085
>erkennen kann ist deren Funktion alles andere als zufällig. Ganz im
>Gegenteil, diese Operationen sind/wären teilweise ungemein nützlich und
>sind garantiert absichtlich so entstanden.

Ich würde eher vermuten, die ursprünglich geplanten Funktionen haben 
nicht so funktioniert, wie sie sollten. Also hat man sie aus der 
Dokumentation rausgenommen, statt alles neu zu machen.

>Weil ein CPU-Entwickler, der sowas zulässt, seinen Brötchengeber in den
>Ruin treiben kann.
Das ist ziemlicher Quatsch. Eine Gewährleistung, wenn man ein Baustein 
ausserhalb der Spec nutzt, wird kaum greifen.

Gruss
Axel

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel schrieb:
> Das ist ziemlicher Quatsch. Eine Gewährleistung, wenn man ein Baustein
> ausserhalb der Spec nutzt, wird kaum greifen.

Nunja, strenggenommen benutzt du ein Auto auch ausserhalb der Spec, wenn 
du damit im Halteverbot parkst, trotzdem dürfte der Hersteller ein 
Problem bekommen, wenn dabei jedesmal der Motor Feuer fängt ;-)

Andreas

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel schrieb:

> Das ist ziemlicher Quatsch. Eine Gewährleistung, wenn man ein Baustein
> ausserhalb der Spec nutzt, wird kaum greifen.

Das ist ziemlicher Quatsch, denn die ungewollte Ausführung undefinierter 
Prozessor-Befehle ist innerhalb der Spezifikation eines normalen frei 
programmierbaren Prozessors oder Rechners. Nicht unbedingt in dem Sinn, 
dass damit irgendwas Definiertes geschieht, aber in dem Sinn, dass er 
dadurch nicht abrauchen darf. Es sei denn, das betreffende System kommt 
als fertige Lösung. Ein System, dass für Programmierung durch den 
Anwender freigegeben ist, das muss einfache Programmfehler auf der 
freigegebenen Ebene verkraften können.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Ferber schrieb:
> Bis da irgendwas anfängt zu glühen hätte der Speicher schon lange keine
> korrekten Daten mehr geliefert

Ich habs nicht selbst erlebt, aber es soll tatsächlich zu echten 
Hardwaredefekten geführt haben.

Natürlich ist spätestens beim Überschreiten der Curie-Temperatur des 
Kernmaterials Schluß. Was die Schreib/Leseverstärker bis dahin machen, 
steht auf einem anderen Blatt. (Da die Kernspeicher nur destruktiv 
lesbar waren, folgte auf einen Lesezyklus automatisch ein Schreibzyklus 
mit dem ausgelesenen Bit.)

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das ist ziemlicher Quatsch, denn die ungewollte Ausführung undefinierter
>Prozessor-Befehle ist innerhalb der Spezifikation eines normalen frei
>programmierbaren Prozessors oder Rechners. Nicht unbedingt in dem Sinn,
>dass damit irgendwas Definiertes geschieht, aber in dem Sinn, dass er
>dadurch nicht abrauchen darf. Es sei denn, das betreffende System kommt
>als fertige Lösung. Ein System, dass für Programmierung durch den
>Anwender freigegeben ist, das muss einfache Programmfehler auf der
>freigegebenen Ebene verkraften können.

1. Wir reden hier nicht von einer Hausfrau als Anwender, sondern von 
einem ausgebildeten Menschen, von dem erwartet wird, dass er für das 
spezifizierte Umfeld sorgt. Das bedeutet vorgegebene 
Versorgungsspannung, Temperatur, usw. usf.

2. Du kannst ja mal versuchen, Gewährleistung für einen tatsächlichen 
Prozessorfehler einzutreiben, wo der Prozessor definitiv etwas anders 
tut als im Datenblatt steht. Wenn Du das glaubst, dann lies Dir mal die 
vielen Errata Sheets durch, die es zu fast allen erhältlichen 
Prozessoren gibt. Das sind alles Fehler, an denen sich Kunden den Arsch 
gesucht haben, bis die Hersteller zugegeben haben, dass der Prozessor 
tatsächlich einen Fehler hat. Und zeige mir mal den Kunden, der weniger 
als 100.000 Stück/Jahr abgenommen hat, der dafür irgendwas bekommen hat, 
ausser einem freundlichen "Danke für den Hinweis". Bei Kunden, die 
ernsthaft mit Liebesentzug drohen können, ist das naturgemäss anders.
Und da willst Du Gewährleistung durchsetzen, wenn  Du einen verbotenen 
Befehl benutzt hast ?

Gruss
Axel

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Axel: Wenn aber tatsächlich der Prozessor permanent beschädigt wird, 
ist das ja wohl etwas anderes. Also hör bitte auf so zu Klugscheißern...

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel schrieb:
> Und zeige mir mal den Kunden, der weniger
> als 100.000 Stück/Jahr abgenommen hat, der dafür irgendwas bekommen hat,
> ausser einem freundlichen "Danke für den Hinweis".

Nunja, bis heute kannst du deinen Uralt-Pentium mit FDIV-Bug gegen einen 
ohne diesen Fehler bei Intel kostenlos austauschen lassen.

Aber Ausnahmen bestätigen bekanntlich die Regel ;-)

Andreas

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Ferber schrieb:

> Nunja, bis heute kannst du deinen Uralt-Pentium mit FDIV-Bug gegen einen
> ohne diesen Fehler bei Intel kostenlos austauschen lassen.

Eher schon werde ich mir das betreffende Exemplar einrahmen und an die 
Wand hängen. Der hat mir statt dessen noch jahrelang gute Dienste 
geleistet. Siehe
http://www.mathworks.de/company/newsletters/news_n...

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
>> Nunja, bis heute kannst du deinen Uralt-Pentium mit FDIV-Bug gegen einen
>> ohne diesen Fehler bei Intel kostenlos austauschen lassen.
> Eher schon werde ich mir das betreffende Exemplar einrahmen und an die
> Wand hängen.

"Pentium FDIV-Bug. Ich war dabei." ;-)

Dürfte aber auch bis heute der einzige Prozessorbug sein, der es mal bis 
auf die Frontseiten von Tageszeitungen gebracht hat.

> Der hat mir statt dessen noch jahrelang gute Dienste
> geleistet. Siehe
> http://www.mathworks.de/company/newsletters/news_n...

Ack, der Bug war für die meisten Anwendungen eher nicht relevant. Andere 
Bugs hatten viel weniger Publicity, obwohl der Impact an sich viel höher 
war (F00F z.B.).

Andreas

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Ferber schrieb:

> "Pentium FDIV-Bug. Ich war dabei." ;-)

Yep ;-). Ziemlich direkt.

> Ack, der Bug war für die meisten Anwendungen eher nicht relevant.

Deshalb hat mich das auch nicht gestört, einer auf ~1Mrd Kehrwerte mehr 
oder weniger ungenau, tja nun. Aber für mich stand am Tag drauf fest, 
das Intel da dennoch einen riesigen Bock geschossen hatte, der sie 
ziemlich viel Geld kosten würde. Zumal diese Art Fehler, wo falsch 
gerechnet wird, wirklich jeder versteht, ganz im Unterschied zu dem K6 
Bug unten.

> Andere
> Bugs hatten viel weniger Publicity, obwohl der Impact an sich viel höher
> war (F00F z.B.).

Eher AMDs 32MB Bug in der ersten Serie vom K6. Anders als der FDIV- und 
der F00F-Bug war der nämlich kaum vermeidbar weil nicht an bestimmte 
Befehle gebunden, und er war gut reproduzierbar aber nicht sonderlich 
deterministisch. Stand bereits früh ganz harmlos im errata sheet, unter 
"self modifying code" getarnt. 
http://membres.multimania.fr/poulot/k6bug.html

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Eher AMDs 32MB Bug in der ersten Serie vom K6. Anders als der FDIV- und
> der F00F-Bug war der nämlich kaum vermeidbar weil nicht an bestimmte
> Befehle gebunden, und er war gut reproduzierbar aber nicht sonderlich
> deterministisch. Stand bereits früh ganz harmlos im errata sheet, unter
> "self modifying code" getarnt.
> http://membres.multimania.fr/poulot/k6bug.html

Wenn ich das richtig verstanden habe, dann war da ein Bug in der Logik, 
die selbstmodifizierenden Code behandelt, der Bug wurde aber auch durch 
nicht-selbstmodifizierenden Code ausgelöst, weil die Erkennungs-Logik 
dafür nur die unteren 25 Bits der physikalischen Adresse berücksichtigt 
hat (deshalb die 32MB).

Da fällt mir aber ganz spontan als (wenn auch ziemlich aufwendiger) 
Workaround (für nicht selbstmodifizierenden Code) ein, via Paging dafür 
zu sorgen, dass ein Prozess nie physikalische Pages im Abstand von 
32MB-vielfachen des aktuell ausgeführten Codes verwendet. Kostet 
allerdings wohl spürbar Performance, da ggf. bei Sprüngen auf eine 
andere Page häufig erstmal Daten im Speicher verschoben werden müssten.

Aber ist Geschichte ;-)

Andreas

Autor: Jens G. (jensig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Klaus (Gast)
>Ich glaube, das mir dem CPU zerstören, ist eher ein historisches
>Ereigniss ;)

>Ich erinnere mich mal gehört zu haben, dass es ein System gab, auf dem
>eine bestimmte (verbotene) Instruktionsfolge zum durchbrennen eines
>Widerstands in der CPU geführt hat. An mehr Deteils kann ich mich leider
>nicht erinnern.

So wurde der PROM erfunden ...

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.