Matthias Sch. schrieb:
> Lies doch mal unter Windows die Fuses des vom Apple programmierten Chip
> und umgekehrt. Dann kommst du dem Problem vermutlich schnell auf die
> Spur.
Hallo Matthias,
vielen Dank für die Tipps. Ich habe mit Burn-o-Mat die aus MAC gesetzte
Fuse auf dem chip in windows ausgelesen. Und auch das gleiche Umgekehrt
in MAC die Fuse aus Windows gelesen. Es war für ATmega8 identisch.
Das gleiche Versuch habe ich mit ATtiny45 gemacht. MAC setzte ATtiny45
Fuse richtig und Windows schreibte Fuse für ATtiny 45 False, habe schon
ein paar ATtiny45 zerstört. Blöde ist das AVRDUDE sagte mir in allen
Platform die Fuse war für ATmega8 richtig gesetzt.
Ich kann auch servos mit "falschem" Takt in ATmega8 betreiben, was
meiner Meinung nach auch relativ taktsensible Tätigkeit ist. Nur für
USART Tätigkeit ist die Taktabweichung zu groß.
@Alle
Ich habe auch die Entwicklung in VMware guest System Opensuse 12.1
und guest System Windows XP in den gleichen Windows 7 Host probiert. Das
Verhalten ist ganz unterschiedlich. (Um die unwichtige Infos zu sparen,
gehe ich hier nicht mehr genau ein, kurz gesagt, es hat für USART Task
nichts gebracht).
Nehme ich an, dass die Fuse von Windowsumgebung richtig gesetzt ist, was
ich auch eigentlich von AVRDUDE weiss, kann mein Problem irgendwo
anderes liegen?
Ich habe auch schon Fuse in MAC setzen lassen und dann code in Flash von
MAC aufsetzen lassen, Lesen und Senden in USART lief richtig. Im
gleichen Chip Fuse unverändert bleibt, identisches Code für Chip von
Windowsumgebung (virtualisiertes windows xp und nicht virtualisiertes
windows7 )in Flash aufladen lassen, dann zerhaue ich die Takt.
Das ist was ich nicht verstehe, hat Flash code, Bootloader in ATmega8
Einfluß auf Fuse? Die Platformabhängige Implementierung von avr-lib
sollte aber nicht der Grund für mein Problem oder irre ich mich? Ist es
ein Fuse Problem?
Ich freue mich auf Eure Antwort. Mich reizt es sehr dass ich die Ursache
meines Problems auf dem Grund gehen kann.
