Mit AVR durch 0 teilen ?!

Hallo,
ich habe im Internet folgendes Video gefunden:
http://www.youtube.com/watch?v=mZ7pUADoo58

Ist das möglich? Ich personlich denke das es ein Fake ist.
Ist es überhaupt möglich einen AVR so zu "belasten" dass er heiß wird?

Gruß
Flexxx

Ein Fake. Der youtube-Benutzer zerstört wohl gerne AVRs:

http://www.youtube.com/watch?v=4YEL7Jx26Wk

Gruß

mic

Wenn du durch 0 teilst müsste der Compiler dir doch eigentlich einen error zurückliefern, bei mir zummindest eine Warnung:

bei folgendem Code:

Code:

---

#include <avr/io.h>
#include <util/delay.h>

int main(void){
   
    DDRB = 0xFF;
   
    while(1){
   
        PORTB = 128 / 0;
        _delay_ms(1000);
   
    }
   
}

---

folgende Fehlermeldung:

Code:

---

main.c: In function 'main':
main.c:10: warning: division by zero

---

Und warum sollte man sich die mühe machen den Editor aufzumachen und das Programm zu schreiben und zu kompilieren?
Einfacher gehts mit 12V an Vcc :D

MfG

Torrentula

EDIT: Natürlich ein Fake :) Frage mich trotzdem warum man einfach so zum Spaß nen 5 Euro Atmega32 grillt ... kann man gleich den 5er verbrennen

Nein, 12V steckt der weg, hab ich schon probiert^^ (Und er funzt immer noch)

Aber ist ja nur ein Warning?!?

Kannst du das Ergebnis mal posten?

Zitat:

---

Nein, 12V steckt der weg, hab ich schon probiert^^ (Und er funzt immer noch)

---

Tatsächlich? Hmm... es wird Zeit das Netzteil einzuschalten :D

Zitat:

---

Kannst du das Ergebnis mal posten?

---

Meinst du jetzt das HEX-File?

Kannst du haben:

Code:

---

:1000000012C019C018C017C016C015C014C013C044
:1000100012C011C010C00FC00EC00DC00CC00BC06C
:100020000AC009C008C011241FBECFE5D4E0DEBF5E
:10003000CDBF02D03AC0E4CF8FEF87BB80E890E01D
:1000400060E070E00BD020E931E068BB80E197E22E
:10005000F9013197F1F70197D9F7F7CF97FB092EFF
:1000600007260AD077FD04D00CD006D000201AF461
:10007000709561957F4F0895F6F7909581959F4F04
:100080000895AA1BBB1B51E107C0AA1FBB1FA617DF
:10009000B70710F0A61BB70B881F991F5A95A9F731
:0E00A00080959095BC01CD010895F894FFCF96
:00000001FF

---

Ich meinte das, was dann an PortB anliegt^^

Habs selbst grad kompiliert - funzt tatsächlich... Jetzt nur noch AVR + Steckbrett + USBasp suchen und mal gucken...

Wenn ich einen Tipp abgeben Darf:
Entweder
1. Müll oder
2. Nix

Grade ausprobiert und: es ist option 2 --> nix passiert

MfG

Torrentula

Also, ich hab jetz hier nen Attiny2313, er explodiert NICHT^^

Als Ergebnis von 128/0 kommt 127 raus (An PortD fehlt das PD7, und an B hängt ja der Programmer)
Bei 0/0 kommt allerdings 0 raus...

Zitat:

---

Zitat von -schumi-

Nein, 12V steckt der weg, hab ich schon probiert^^ (Und er funzt immer noch)

Aber ist ja nur ein Warning?!?

Kannst du das Ergebnis mal posten?

---

Stimmt, aber nicht immer. Relatv sicher knallt es bei 230VAC als Versorgung. :-(

Gruß Richard

Zitat:

---

Zitat von Flexxx

... Ich personlich denke das es ein Fake ist ...

---

Wieso sollte das echt sein? Der Rauch nach dem Knall kommt nämlich von der Seite - vermutlich vom Aschenbecher - und es ist auch nicht üblich, dass NACH einer thermischen Gehäusewand-absprengung das Wafer des Controllers so hübsch unbeschädigt da liegt. Neben all dem anderen, das den Ratschlag als Ammenmärchen (negativ) auszeichnet.

Die Linien der Explosion sind reingemalt. Also alles in allem ein sehr aufwendiger Fake, d.h. mit Nachbearbeitung, Geräuscheinspielung und auffräsen des Gehäuses.
Danke, oberallgeier, für die Info. Ich habe mich schon gefragt, wo die dunkle Stelle zu sehen ist. :)

Stimmt mir ist garnicht aufgefallen, dass man eigentlich garnicht sieht wie die Plastickstücke des Gehäuses wegfliegen. Aber ein schöner aufwändiger Fake^^

MfG

Torrentula

Hallo!

Das Video finde ich optimal für alle, die Innereien von einem µC noch nicht gesehen haben. Anschauen ist angeblich billiger, als Sebstversuche mit unbekanten Endresultat. :lol:

Um das "Compiler-Meckern" zu umgehen:
Einfach in einer Schleife den Teiler überlaufen lassen, dann müsste es zu einer Divison durch null kommen ohne das der Compiler bereits beim Compilieren etwas davon mitbekommt.

In etwa so:

Code:

---

Dim A as Integer
Dim B as Byte

For B = 1 to 255
    Incr B
    A=A/B
    Print A
Next

---

Nachdem der Compiler bei For B = 1 to 256 bemerken würde, dass sich 256 niemals in einer Byte-Variablen ausgehen können, inkrementiere ich kurzerhand direkt in der Schleife nochmals um eins. Damit würde beim letzten Schleifeneintritt B = 255 sein, nach Incr B schließlich null.

Ich habe es noch nicht ausprobiert, aber was denkt ihr darüber?

Gute Idee! Bitte ausprobieren.
Es wird folgendes passieren:
1) Es werden die Zahlen in Zweierschritten ausgegeben: 2, 4, 6, 8, ... etc. bis 254, und dann ...
2) Wieder von vorn. (weil eine Exception, ausgelöst durch die CPU, den µC neu starten wird.)

Ich habe es jetzt ausprobiert:
Bei der Divison durch null wird 255 als Ergebnis ausgegeben und der Controller läuft weiter, als ob nichts geschehen wäre. Irgendwie enttäuschend. :/

Ja, in der Tat.

Schade, ich hatte etwas anderes erhofft :D

mfg

By the way:
Für Gleitkommazahlen ist ein Ergebnis beim Teilen durch null definiert:
Für Gleitkommazahlen (float und andere Datentypen) ist aber durch den Gleitkommastandard IEEE 754 unter anderem eine Division durch 0 definiert. Dieser Standard definiert zwei Gleitkommazahlen namens +Inf und −Inf (infinity = unendlich) und unterscheidet zwei Zahlen mit dem Wert 0: +0 und −0. Beide repräsentieren die Zahl 0, beim Testen auf Gleichheit werden diese beiden Zahlen als gleich betrachtet. Für das Rechnen mit +0, −0, +Inf und −Inf legt der Standard naheliegende und natürliche Regeln fest, wann immer es möglich ist.
Quelle: http://de.wikipedia.org/wiki/Null#Di..._auf_Computern

Gut zu wissen.
Also ist dann x/-0 = -Inf unf x/+0 = +Inf (solange x > 0)?

Eigentlich müsste ja 0/0 auch 1 ergeben, hm?