AVRs lassen sich nicht mehr programmieren

[braineater]

hallo alle zusammen

ich hab das selbe problem meine avrs lassen sich nach einiger zeit nicht
mehr programmieren

ich hatte am anfang einen atmega8515 der einige zeit ging und sich dann
nicht mehr programmieren ließ
daraufhin hab ich mir 2 atmega16 bestellt und diese programmiert einer
hat 2 stunden lang perfekt funktioniert bis er sich nicht mehr
beschreiben ließ als ich dann den anderen in einer anderen (einfachen)
schaltung testen wollte ließ sich dieser auch nicht mehr beschreiben
bei allen drei fällen hat ponyprog plötzlich den avr nicht mehr erkannt
error 24
hab den dann mit leds getestet und alle pins scheinen zu funktionieren
auch die avrs ziehen normal strom und an der software hab ich auch
nichts geändert wie auch an den fuse bits

arbeite mit avr studio und ponyprog unter xp
programmiere in assembler
hab n pc netzteil als netzgerät 5V
und n steckbrett zum schaltung aufbauen
der programmer ist gekauft und am parallel port angeschlossen
kabel länge zwischen programmer und avr is die orgninal kabelläng ca 1m

ich hab schon einiges gelsen dass durch lange kabel die fuse bits
geändert wurden aber dass dies 2mal hintereinander passiert und dann
auch noch mit dem gleichen effekt bei verschiedenen programmen halte ich
für seh unwarscheinlich

ah ja und meine frage is was ich noch probieren kann außer mir neue avrs
kaufen

mfg braineater

 

[oldmax]

Hi
Vermutlich hast du die Fusebits für einen externen Quarz gesetzt und der Quarz auf deinem Programmer streikt. Hast du dir mal mit einem Oszi den Takt angesehen ? Stimmen die Einstellungen der Fusebits mit dem Quarz in der Frequenz überein ? Ich kann hier nur raten, aber da ich Anfangs auch ein paar Atmegas "abgemeldet" habe, hab ich mir einen externen Taktgenerator gebaut und damit diese wieder gesprächsbereit bekommen. Einfach einen Taktgenerator mit Spannung versorgen, ein Stück flexible Leitung dran mit einer Stecknadel am Ende. Fertige Taktgeneratormodule in IC Größe bekommst du für wenig € bei den Elektronikhändlern. So kannst du zumindest ein Taktsignal an den entsprechenden Eingang legen und das IC dabei im Sockel lassen. Nun sollte der Zugriff über ISP auch wieder möglich sein. Ich benutze ein Pollin-Board. Bisher konnte ich dann wieder an die Fusebits und mit Ponyprog unsinnige Einstellungen rückgängig machen.
Ich habe gestern einen Monitor für verwendete Variablen ins Forum gesetzt, vielleicht hilft er dir zukünftig, deine Controler zu durchschauen. Wär nett, wenn da mal ein Feedback kommt.
Gruß oldmax

 

[dino03]

Hallo ,

kabel länge zwischen programmer und avr is die orgninal kabelläng ca 1m

Mein selbstgebauter Parallel-Progger unter Pony läuft ohne Probleme.
Ich habe bei mir 40cm Kabellänge dran (Flachbandkabel). Im Internet steht
was mit 30cm weil man sonst über 8MHz wohl Probleme bekommen soll.
Bei mir läuft der bis 16MHz problemlos.
Mein Progger ist hier im Forum in diesem Beitrag zu sehen.

Bei welcher Taktfrequenz hast Du denn Probleme ?
Wenn er noch neu ist, dann läuft der Prozzi noch auf 1MHz.
Kann also an der Kabellänge liegen, wenn er später (mit höherer Frequenz)
nicht mehr antwortet.

Gruß
Dino

 

[braineater]

Hi
Vermutlich hast du die Fusebits für einen externen Quarz gesetzt und der Quarz auf deinem Programmer streikt. Hast du dir mal mit einem Oszi den Takt angesehen ? Stimmen die Einstellungen der Fusebits mit dem Quarz in der Frequenz überein ? Ich kann hier nur raten, aber da ich Anfangs auch ein paar Atmegas "abgemeldet" habe, hab ich mir einen externen Taktgenerator gebaut und damit diese wieder gesprächsbereit bekommen. Einfach einen Taktgenerator mit Spannung versorgen, ein Stück flexible Leitung dran mit einer Stecknadel am Ende. Fertige Taktgeneratormodule in IC Größe bekommst du für wenig € bei den Elektronikhändlern. So kannst du zumindest ein Taktsignal an den entsprechenden Eingang legen und das IC dabei im Sockel lassen. Nun sollte der Zugriff über ISP auch wieder möglich sein. Ich benutze ein Pollin-Board. Bisher konnte ich dann wieder an die Fusebits und mit Ponyprog unsinnige Einstellungen rückgängig machen.
Ich habe gestern einen Monitor für verwendete Variablen ins Forum gesetzt, vielleicht hilft er dir zukünftig, deine Controler zu durchschauen. Wär nett, wenn da mal ein Feedback kommt.
Gruß oldmax

könnte ich als taktgenerator zum beispiel einen ne555 verwenden da ich da eh noch ne menge bei mir rumliegen hab und welche frequenz(en) muss der dann ausgeben können und an welches beinchen muss ich den hinmachen?

 

[braineater]

Hallo ,

Mein selbstgebauter Parallel-Progger unter Pony läuft ohne Probleme.
Ich habe bei mir 40cm Kabellänge dran (Flachbandkabel). Im Internet steht
was mit 30cm weil man sonst über 8MHz wohl Probleme bekommen soll.
Bei mir läuft der bis 16MHz problemlos.
Mein Progger ist hier im Forum in diesem Beitrag zu sehen.

Bei welcher Taktfrequenz hast Du denn Probleme ?
Wenn er noch neu ist, dann läuft der Prozzi noch auf 1MHz.
Kann also an der Kabellänge liegen, wenn er später (mit höherer Frequenz)
nicht mehr antwortet.

Gruß
Dino

öhm.... ich denk mal die standart taktfrequenz von ponyprog da ich da noch nie was umgestellt hab XD
wo kann man die umstelln hab auf die schnelle da nix gefunden

 

[dino03]

Hi braineater,

standart taktfrequenz von ponyprog da ich da noch nie was umgestellt hab

Da hab ich auch nix umgestellt. Wüßte ich jetzt auch nicht. Ich meine die
CPU-Frequenz, Quarz-Frequenz, ... (wie man es auch nennen will). Also der
Takt mit dem der ATmega läuft und nicht der Programmiertakt vom Programmer.

Ich hab mich jetzt mit den beiden Takten noch nicht näher befaßt. Der
CPU-Takt muß aber glaube ich so 4-16mal (korrigiert mich ) höher als der
Programmiertakt sein. Da gibt es wohl bei den langen Programmierleitungen
so viel Übersprechen, das da die Daten teilweise hinüber sind.

Kannst Du die Leitung von deinem Programmer zum Controller kürzer machen ?
Oder ist das nicht so einfach hinzukriegen ?

Oder bau dir doch mal mit ein paar Widerständen (siehe hier) nen kleinen
Programmer nur um festzustellen wo dran es liegen könnte. Der kleine
Progger ist schneller aufgebaut als nen Oszillator
Mit dem hab ich auch angefangen. Der läuft.

Den Controller mal schnell auf nen Steckbrett und den selbstgebauten
Progger mit 30cm-Strippen anschließen. Wenn er dann erreichbar ist,
dann ist die Leitung von deinem Kauf-Progger zu lang.

Gruß
Dino

 

[Grandpa]

Hallo,

Ich habe den Parallel- Programmer von www.rumil.de/hardware/avrisp.html nachgebaut. Mit einem TRI-State-Chip drauf, da kann ich sogar dran bleiben, auch wenn das Programm läuft. Das Innenleben ist auf meiner Seite www.acvision.de zu sehen.

BASCOM hat ihn sofort angenommen. Damit habe ich einen ATmega8 und Attiny13V-PU und -SU mehrfach über einige Tage beschrieben. Bis dahin hatte ich keine Aussetzer. Mein Kabel ist ca. 30cm lang. Sollte mit PonyProg funktionieren.

Grüsse,

Michael

 

[dino03]

Hallo nochmal , ...

mir ist gerade noch was aufgefallen ...

hab n pc netzteil als netzgerät 5V
und n steckbrett zum schaltung aufbauen

Du programmierst über nen normalen PC ? und hast deine Schaltung über
ein anderes PC-Netzteil versorgt. Es liegen also beide Teile
(der Programmer-PC und die Schaltung) über die jeweiligen Netzteile
an Erde. Hat schon jemand an Erdschleifen gedacht ? Ausgleichsströme
zwischen den beiden Teilen, die dir die Programmerdaten zerkloppen ?

Ist jetzt nur so ne Idee. Aber versuch mal, deine Schaltung über irgendeine
erdfreie Versorgung zu betreiben (Batteriepack mit 4 NiMh-Akkus, ...).
Versuch macht kluch

Ich benutze nämlich zum programmieren nen Laptop mit Par-Port (jetzt allerdings
auch mit AVRISPmk2 und USB).

Gruß
Dino

 

[braineater]

Kannst Du die Leitung von deinem Programmer zum Controller kürzer machen ?
Oder ist das nicht so einfach hinzukriegen ?

für ein paar mal würd des mim kürzmachen schon funktionieren aber auf die dauer isses n bissle blöd wenn man immer zum programmieren untern tisch hocken muss


außerdem wenns am programmer kabel länge liegt dann würde es ja wenigstens ab und zu funktionieren weil ich ja ne zeit ohne probleme mit dem kabel programmiert hab
also wird es so wie ihr sagt warscheinlich an den fuse bits liegen kann ich dass vll auch irgendwie testen hab hier auch noch n oszi rumstehen geht halt nur bis 1 mhz

und wenns an den fuse bits liegt wie mach ich dass nun genau mit dem oszillator

mfg braineater

 

[Grandpa]

Hallo,

ich hab ebenfalls einen Laptop mit LPT und bislang immer noch ein Breadboard, das über ein Labornetzgerät ohne PE versorgt wird, die Kappe des Programmers ist mit der Masse der Platine verbunden. Frequenz bislang immer nur 1Mhz. Aber - das hilft nicht wirklich weiter, oder?


Gruss,

Michael

 

[Oskar01]

Hallo,
wie sieht die Programmiermaske im AVR-Studio4 denn aus?
Manchmal verstellt "Windows" eigenmächtig die Menüeinträge.
Da steht dann EEPROM File ist ein Hex-File. Das muß natürlich EEP heißen.
Dann ist die ISP- Frequenz (Reiter "Board") nicht 1/4 Oszillatorfrequenz,
manchmal nur 14 kHz. Und so weiter.
Manchmal verstellt sich das "Device". Da steht dann noch ATMega 8515 drin,
obwohl ich den ATTiny2313 flashen wollte.
Und und und.
Daran lag es meistens an der Person vor dem PC- bei mir jedenfalls - wenn es partout nicht mehr zu flashen geht.

Hoffentlich hilft es.
Berichtet mal weiter.


Gruß von Oskar01

 

[norgas]

hallo alle zusammen

ich hab das selbe problem meine avrs lassen sich nach einiger zeit nicht
mehr programmieren

ich hatte am anfang einen atmega8515 der einige zeit ging und sich dann
nicht mehr programmieren ließ
daraufhin hab ich mir 2 atmega16 bestellt und diese programmiert einer
hat 2 stunden lang perfekt funktioniert bis er sich nicht mehr
beschreiben ließ als ich dann den anderen in einer anderen (einfachen)
schaltung testen wollte ließ sich dieser auch nicht mehr beschreiben
bei allen drei fällen hat ponyprog plötzlich den avr nicht mehr erkannt
error 24
hab den dann mit leds getestet und alle pins scheinen zu funktionieren
auch die avrs ziehen normal strom und an der software hab ich auch
nichts geändert wie auch an den fuse bits

arbeite mit avr studio und ponyprog unter xp
programmiere in assembler
hab n pc netzteil als netzgerät 5V
und n steckbrett zum schaltung aufbauen
der programmer ist gekauft und am parallel port angeschlossen
kabel länge zwischen programmer und avr is die orgninal kabelläng ca 1m

ich hab schon einiges gelsen dass durch lange kabel die fuse bits
geändert wurden aber dass dies 2mal hintereinander passiert und dann
auch noch mit dem gleichen effekt bei verschiedenen programmen halte ich
für seh unwarscheinlich

ah ja und meine frage is was ich noch probieren kann außer mir neue avrs
kaufen

mfg braineater

Mit dem sch.. programmiern hat wohl Atmel ein Problem. Keine Ahnung an was das liegt aber die Menge Probleme die's gibt kann wohn nicht an der D..heit deir Benutzer liegen. Habe selbst ATmega168p mit denen ich noch debuggen (in Zeitlupe) kann. Das ist aber schon alles. Die DWEN Fuse lässt sich nicht mehr zurücksetzten. Das hilft zwar nicht weiter aber es ist vielleicht ein Trost dass man nicht selbst der I.. ist. Vermute stark dass Atmel einen Bug in den Devices oder in der Software hat. Da kann man Tage verbraten und man kommt nicht weiter. Leider hilft nicht sausser Devices wechseln.

 

[Markus]

Hmmmmmm

Hmmmm, harte Worte....

Mit dem sch.. programmiern hat wohl Atmel ein Problem. Keine Ahnung an was das liegt aber die Menge Probleme die's gibt kann wohn nicht an der D..heit deir Benutzer liegen. Habe selbst ATmega168p mit denen ich noch debuggen (in Zeitlupe) kann. Das ist aber schon alles. Die DWEN Fuse lässt sich nicht mehr zurücksetzten. Das hilft zwar nicht weiter aber es ist vielleicht ein Trost dass man nicht selbst der I.. ist. Vermute stark dass Atmel einen Bug in den Devices oder in der Software hat. Da kann man Tage verbraten und man kommt nicht weiter. Leider hilft nicht sausser Devices wechseln.

aber oft ist es leider nicht so einfach, und die Schuld auf die anderen schieben sollte man erst dann, wenn man sich selbst sicher ist und eine Erklärung dafür hat, was genau passiert.

Sicherlich lässt sich ein Fehler in der Software oder im Device nicht gänzlich ausschließen. oft hilf hier jedoch ein Blick in das Datenblatt im Bereich Erratas. Bekannte Probleme sind dort üblicherweise beschrieben.

Ich für meinen Teil kann die von Euch geschilderten Probleme weder mit PonyProg, noch mit AVR-Studio, AVRISP mkII, Selbstbauprogger, STK500, STK501, BASCOM usw. nachvollziehen. Ich habe meine Devices (Mega8, 16, 32, 64 und 128) schon viele viele Male (weit über 100 Mal) programmiert und jedes Device lebt immer noch.

Leider ist es in sehr vielen Fällen nach wie vor der Fall, dass der Fehler meistens vor der Tastatur sitzt. ja ich weiß, dass wollt ihr jetzt nicht hören und es hilft in Euren Problemfällen auch nicht weiter. Aber manchmal ist ein Blick in die Erratas ein klarer Vorteil.

Wie gesagt, mir ist aktuell nichts bekannt!

Grüße,
Markus

 

[dino03]

Hi alle,

Mit dem sch.. programmiern hat wohl Atmel ein Problem. Keine Ahnung an was das liegt aber die Menge Probleme die's gibt kann wohn nicht an der D..heit deir Benutzer liegen. Habe selbst ATmega168p mit denen ich noch debuggen (in Zeitlupe) kann. Das ist aber schon alles.

Da muß ich auch mal was sagen...
Ich hab bis jetzt nen AT90S2313, nen ATmega8535 und nen ATmega32
programmiertechnisch gequält (mit Betonung auf gequält!).
Der alte 90S2313 läuft auf 4MHz Keramik-Resonator und die beiden
mega8535 und mega32 laufen auf 16MHz.
Ich weiß nicht, wie viele hundert mal ich die Teile programmiert habe
Wenn man anfängt, dann debuggt man den Code durch ausprobieren auf
dem Controller. Die Controller leben bei mir immer noch und arbeiten
absolut problemlos mit den PonyProg und nem selbstgebauten
Parallel-progger und auch mit AVR-Studio und AVRISPmk2 zusammen.

Leider ist es in sehr vielen Fällen nach wie vor der Fall, dass der Fehler meistens vor der Tastatur sitzt.

Ich nenne sowas Layer8-Fehler

Ich hab auch oft gedacht das da irgendein Teil hinüber ist. Aber die Dinger
tun nur das was man ihnen sagt und verarbeiten stur die Daten die man
ihnen schickt.
Frei nach dem Motto : Sch...e rein = Sch...e raus !

Alleine den ATmega32 (siehe den Beitrag in den Projekten mit dem
Daddelboard) steckt seit Anfang an in dem Teil und hat für jede neu
dazugekommene Hardwarekomponente mindestens 50 Propgrammierzyklen
bekommen.
Mal rechen ...
Basissystem, LCD, UART, Tasten, LEDs, RTC, 1-Wire, ...
Also grob über den Daumen mindestens 350mal programmiert
Der läuft wie ne Eins und immer noch auf 16MHz volle Kanne.

Gruß
Dino

 

[norgas]

Hmmmm, harte Worte....



aber oft ist es leider nicht so einfach, und die Schuld auf die anderen schieben sollte man erst dann, wenn man sich selbst sicher ist und eine Erklärung dafür hat, was genau passiert.

Sicherlich lässt sich ein Fehler in der Software oder im Device nicht gänzlich ausschließen. oft hilf hier jedoch ein Blick in das Datenblatt im Bereich Erratas. Bekannte Probleme sind dort üblicherweise beschrieben.

Ich für meinen Teil kann die von Euch geschilderten Probleme weder mit PonyProg, noch mit AVR-Studio, AVRISP mkII, Selbstbauprogger, STK500, STK501, BASCOM usw. nachvollziehen. Ich habe meine Devices (Mega8, 16, 32, 64 und 128) schon viele viele Male (weit über 100 Mal) programmiert und jedes Device lebt immer noch.

Leider ist es in sehr vielen Fällen nach wie vor der Fall, dass der Fehler meistens vor der Tastatur sitzt. ja ich weiß, dass wollt ihr jetzt nicht hören und es hilft in Euren Problemfällen auch nicht weiter. Aber manchmal ist ein Blick in die Erratas ein klarer Vorteil.

Wie gesagt, mir ist aktuell nichts bekannt!

Grüße,
Markus

Bin durchaus nicht der arrogante Benutzer der meint es machen nur die anderen Fehler. Meine den Zusammenhang mit den Fuse Bits und der Programmierung durchaus verstanden zu haben. Ich bewege mich aber in den verschiedensten Foren und finde so eine Vielfalt an Problemen mit dem Programmiern sodass ich glaube es sind nicht in alllen Fällen der Benutzer schuld.
Ich arbeite in grossen und ganzen gerne mit Atmel aber es gibt doch ein paar Dinge die mich an der Sorgfältigkeit zweifeln lässt mit denen Atmel die Dinge angeht.
Dazu zählen z.B. Fehler in AVR Studio die jeder Benutzer, wenn er damit arbeitet, nach dem ersten Tag bemerkt aber von Release zu Relase weitergezogen werden. Damit meine ich, dass wenn man mit AVR Studio im Vollbildmodus arbeitet, das Vollbild etwas nach unten verschoben ist, sodass man die unterste Zeile nicht mehr sieht. Weiters wird beim Verlassen des Programms nicht immer gefragt ob das Projekt gespeichert werden soll. Das sind alles Punkte mit denen man leben kann, aber die mich zweifeln lassen das eben andere wichtige Sachen wie die Programmierung mit der entsprechenden Sorgfalt angegangen werden.

 

[braineater]

da ich sehe dass dieser thread ein bischen in ein algemein thread über programmier probleme übergeht, wiederhol ich nochmal meine zuletzt gestellte frage

mit welcher frequenz und wie (an welchen port und so wieter und sofort) kann ich mein avr wiederbeleben bei verstellten fuse bits weil ich glaube, dass das das problem ist
und könnte ich das mit einem ne555 realisieren? (brauche keinen schaltplan nur kurze beschreibung was für ein taktsignal an welchen pin vom avr kommen muss)

und dann noch ne frage.
Wenn ich statt das programmerkabel zu verlängern einfach den lpt port verlänger, hat das den selben Effekt wie ein langes Programmerkabel?

und @norgas sowas wie deine beschriebenen probleme mit avrstudio waren bei mir nie.
er frägt immer ob ich speichern will und ich seh auch alles von der grafischen oberfläche
vieleicht solltest du dir mal die neuste version runterladen ;-)

MFG braineater

 

[norgas]

Sorry braineater, mein Ärger gehört nicht in dein Thema. Die einzige sichere Methode um deinen uP wieder zu holen, ist ihn mit High Voltage Programming zu löschen. Dazu brauchst daber z.B. ein STK 500. Wenn die SPEN Fuse gelöscht wurde geht nichts anderes mehr.

Da du mit Assembler arbeitest hast du die Probleme mit dem Speichern des Projekts nicht. Das sind Einstellungen für den AVR-GCC-Compiler die nicht gespeichert werden.

 

[braineater]

Sorry braineater, mein Ärger gehört nicht in dein Thema. Die einzige sichere Methode um deinen uP wieder zu holen, ist ihn mit High Voltage Programming zu löschen. Dazu brauchst daber z.B. ein STK 500. Wenn die SPEN Fuse gelöscht wurde geht nichts anderes mehr.

Da du mit Assembler arbeitest hast du die Probleme mit dem Speichern des Projekts nicht. Das sind Einstellungen für den AVR-GCC-Compiler die nicht gespeichert werden.

also muss ich wohl oder übel warten bis ich wieder geld hab um mir neue avrs zu kaufen und bis ich mal wieder genug teile an meiner teslaspue geschrottet hab dass sich ne reichelt bestellung lohnt XD

weiß jemand eine antwort auf die frage, ob ich mit nem verlängerungskabel vor dem programmer, die fehler mit zu kurzen programmierkabeln beheben kann ? weil ich will nich immer untern tisch hocken müssen

 

[dino03]

Hi braineater,

jetzt mal wieder zum eigentlichen Problem in diesem Thema

mit welcher frequenz und wie (an welchen port und so wieter und sofort) kann ich mein avr wiederbeleben bei verstellten fuse bits weil ich glaube, dass das das problem ist

Wenn es nur die Taktbits sind, ist das kein großes Problem.
An XTAL1 kann man ihm einen Takt aufzwingen. Sieh mal im Datenblatt
unter "System Clock and Clock Options" nach.
XTAL1 ist der Eingang der Takterzeugung und XTAL2 ist der Ausgang -
also die Rückkopplung für Quarze und Resonatoren. An XTAL1 kannst
Du also einen Quarzoszillator, NE555 oder anderes taktgebendes
anschließen. aber immer auf TTL-Pegel achten.
Ich würde so 1MHz bis 4MHz anliefern. 1MHz ist ja auch die Standardrate
wenn er noch blank ist. Es soll aber wohl auch mit wesentlich weniger gehen.

und könnte ich das mit einem ne555 realisieren? (brauche keinen schaltplan nur kurze beschreibung was für ein taktsignal an welchen pin vom avr kommen muss)

Sollte der NE555 gebacken kriegen. nen paar PicoFarad als Kondensator
und so 1MHz sollte der packen. Einfach Standard-NE555-Schaltung und
den Ausgang an den XTAL1. Den NE555 mit +5V versorgen und fertig.
Ich glaube, er hat aber nen OpenCollector-Ausgang (kann das sein?)
Also zur Sicherheit noch nen 4k7 von +5V nach XTAL1 und fertig.

und dann noch ne frage.
Wenn ich statt das programmerkabel zu verlängern einfach den lpt port verlänger, hat das den selben Effekt wie ein langes Programmerkabel?

Leider ja. Die Treiber sitzen bei dem Parallel-Proggerkabel im PC, wenn er
nur die Widerstände drin hat. Wenn er nen 74LS244 oder LS245 oder,...
drin hat, dann wird das Signal zwischendurch wieder aufgefrischt. Aber
besser wird es durch lange Leitungen auch nicht
Mit diesen 74LS... Treibern im Progger kann man beide Seiten des
Proggers wohl schätzungsweise auf 50cm Kabellänge setzen.
Gebe ich aber keine Garantie drauf. Wenn Du dir die Leitungsprobleme
ersparen willst, dann besorg dir nen AVRISPmk2 und nen 5m USB-Kabel
Das sollte lang genug sein Außerdem nimmt die Geschwindigkeit
bei nem Mega128 doch erheblich zu


< OFF-TOPIC (sorry Dirk) >
Zu dem anderen Thema ...
Ich will jetzt keinem auf den Fuß treten und wem der Schuh paßt der zieht
ihn sich an ...
Probleme entstehen meißtens wenn man irgendetwas nicht genau liest
sondern nur kurz überfliegt oder meint das man es sowieso alleine am besten
weiß und gute Ratschläge einfach in den Wind schießt. Und außerdem
hat man es bis jetzt ja immer so gemacht und warum soll das jetzt nicht
mehr so gehen.
Ich hab mich auch schon oft genug geärgert wenn etwas nicht so funktioniert
hat wie ich wollte. Ich würde mal sagen, 90% der Fälle waren eigene Fehler.
Bei einem selbstgebauten Kennlinienschreiber für TRIACs hab ich wochenlang
rumgewerkelt und das Ding lief einfach nicht. Wie ich ihn wieder zerlegt hab,
hab ich gemerkt, das da einfach die Betriebsspannung an einer Stelle fehlte.
Bei den ersten 1-Wire-Experimenten hab ich die Bits falschrum in das Byte
geschoben, usw...
Wenn irgendwas überhaupt nicht will dann helfen meißt folgende Sachen ...
- Man schläft einfach mal ne Nacht drüber
- Man läßt mal nen anderen drüberschauen
- Man versucht einem anderen die Schaltung/dasProgramm/... zu erklären
der andere muß dabei noch nichtmal was davon verstehen.
Dadurch bewegt man sich auf anderen Lösungswegen und erkennt schneller
wo der Fehler stecken könnte.
- Oder man läßt die Sache einfach mal nen Monat irgendwo liegen und kommt
durch das neu notwendgige einarbeiten in das Thema auf die Lösung.
< wieder ON-TOPIC >

So und nun fröhliches basteln.
Flamen könnt ihr woanders

Gruß
Dino

 

[braineater]

muss der takt dann genau auf 4 mhz bzw 1 mhz sein

oder kann er auch 2,75mhz oder so sein