hi! also ich habe ein ganz stumpfe frage aber ich komme einfach nicht zu irgendeiner lösung. ich habe ein progrämmchen geschrieben und möchte ganz einfach eine wartezeit von 1s z.b. einsetzen. ich nutze bascom und zum flashen ponyprog wenn ich nun ganz einfach waitms 1000 eingeben habe ich eine zeit vn ca. 8sekunden... sehr seltsam!!! ok bei timern geht es weiter. z.b. die servofunktion von bascom macht 7hz statt normalerweise 50. nuja dann habe ich halt eine servofunktion selber geschrieben die 50hz machen sollte. und sie macht ... ----> 20kHz !!! also der controller macht gewissermaßen was er will aber nicht was man ihm sagt... was ist das? ich nutze die interne 1mhz frequenz. (muss net supergenau sein). ist bei nem atmega8 das selbe wie bei 16 oder 32... bin kurz vorm verzweifeln!
ich hab zwar keine ahnung von bascom... aber... ich "schätze" mal, das die funktionen für nen 8Mhz Quarz geschrieben worden sind. mit dem internen rc oszillator läuft dann alles 1/8 mal so schnell. was deine funktion angeht tippe ich auf einen programmierfehler. kannst du die taktfrequenz irgendwo "einstellen"? gibts da irgendwo ein "define" (sorry spreche nur 'C')!?!?... dann das erstmal auf 1Mhz setzen.
@Henning: zu 99,9% macht der uP genau das was du ihm sagst ;-) Lokko hat ja bereits eine entsprechende Vermutung gepostet. Entweder hast du unter Options - Compiler - Communication - Frequency 8MHz eingetragen oder im source steht $crystal=8000000. grüße leo9
nö im programm und in den einstellungen habe ich 1mhz stehen, habe auch zum spaß schonmal 8mhz oder 4mhz hingeschreiben und das mach KEINEN unterschied!!! das komische ist halt, daß der controller totalen brei macht. manche zeiten sind länger als vorgegeben, manche langsamer...
Mach doch mal ein möglichst kleines Testprogramm, bei dem das Problem bereits auftritt. Pack dann das ganze Projekt (mitsamt den Einstellungen) in ein Zip und pack es hier in den Dateianhang einer Nachricht.
Henning: ich will Dich nicht entmutigen und Bascom ist sicher ganz nett, aber zum ordentlichen Programmieren lade Dir AVR-Studio 4.12 frei herunter, lerne Assembler und progge dann. So hast Du den Controller voll im Griff und mußt nicht in falsche Richtungen vermuten. Später kannst (!) Du dann auf C umsatteln, aber mehr als Assembler kann C auch nicht. Assembler ist die mächtigste Sprache, was die Prozessornähe angeht. Klar muß man einiges über die Dörfer programmieren und hat nicht so leckere Routinen, die einem alles abnehmen, aber dafür ist man dann später ganz alleine für sein Programm verantwortlich und muß nicht auf irgendwelche Compiler oder Interpreter schimpfen, von denen man nie genau weiß, was die zusammenassembeln. Grüße!
ja assembler/c schön und gut aber ich will nix großartiges schreiben nur paar ganz stumpfe sachen dafür lohnt sich das nicht und es muss an nem fehler leigen den ich scheinbar mache, denn diese funktionen laufen normal immer... habe mal den kompletten kram angehängt für einfach nen led-blinker t1=t2=1000ms=1s auf atmega16@8mhz
Woher nimmst du die 8MHz? Bist du sicher, dass der AVR nicht doch mit den internen 1MHz werkelt? ...
jo hab es in dem falle mal mit 8mhz getestet aber es macht halt null unterschied was ich da angebe... kann auch 4 oder 16mhz angeben ist immer das selbe!
> kann auch 4 oder 16mhz angeben ist > immer das selbe! Wo gibst du das an? - Im Quelltext des Programms? Wie stellst du die Taktfrequenz des AVRs ein? - An den Fusebits des Controllers? Wird die Angabe der Taktfrequenz im Quelltext überhaupt zur Berechnung der Verzögerungen herangezogen? - Werden die Verzögerungswerte (Warteschleifen oder Timer-Vorteiler und Zählumfang) vom Compiler/Assembler anhand der angegebenen Taktfrequenz berechnet oder werden die Werte als Zahlen (Konstanten) angegeben? ...
also ich gebe die frequenz im quelltext, in den chip settings und in den übertragungs settings an... ob die frequenz herangezogen wird weiss ich nicht... denkt ihr das ist alles auf 8mhz berechnet warum auch immer?... die fuses für den externen quarz habe ich bisher nie setzen müssen... vielleicht sollte ich es mal tun nur leider verstehe ich nicht wirklich wie das mit ponyprog geht... also welche ck ich da nu setzten muss und welche nicht. und irgendwie soll das im ponyprog noch invertiert sein oder so... ich werde mal eine wartezeit von 125ms angeben, das müsste dann bei 1mhz ja ca. 1sekunde entsprechen, ergebnis: jo das geht. ziemlich genau 1sek soweit man das halt nach uhr ersehn kann.
nachtrag: hab das selbe nochma geflasht mit einer wartezeit mehr drin und nu stimmt die frequenz wieder überhaupt nicht. an den werten habe ich nichts verändert... ich verstehs nicht :(
Solange du nichts an den Fusebits des AVRs verändert hast, tuckert der mit dem internen RC-Oszillator, der auf etwa 1MHz calibriert ist. Dies ist die Werkseinstellung bei Auslieferung (siehe Datenblatt, suche mal im Datenblatt nach dem Wort "shipping"). Wenn du eine andere Taktquelle brauchst (für Uhr braucht man schon einen Quarz), dann musst du die Fusebits dementsprechend ändern. Aber mach dich vorher sachkundig, beim geringsten Fehler ist der AVR nicht mehr per ISP ansprechbar. Mit Wartezeiten wird das aber sowiso sehr ungenau. Da ist man mit der Nutzung eines Timers bedeutend besser bedient. Auch solltest du überdenken, ob du wirklich in BASCOM programmieren willst. Mit ASM bist du bedeutend näher an der Hardware und hast daher viel mehr Übersicht über das, was du programmierst. Da gilt nur das Datenblatt und der Befehlssatz, der ja eigentlich Bestandteil des Datenblatts ist. Hier mal einige Beispiele für Zeitzählung mit Timer in Assembler: http://www.hanneslux.de/avr/stopuhr/index.html http://www.hanneslux.de/avr/zuenduhr/index.html ...
@Henning: Wenn Du den internen 1MHz-Oszillator benutzt, dann mußt Du natürlich auch $crystal=1000000 angeben. @Hannes: Ja, bei Bascom werden die Konstanten automatisch passend gemacht. Das ist ja der Sinn. Man gibt einmal den Takt an und dann haben Wait-Befehl, RS232-Baudrate usw. usf. das richtige Timing. Ich halte es für verkehrt, zuerst mit Assembler anzufangen. Man empfiehlt jemandem, der kochen lernen möchte, doch auch nicht, er solle sich zuerst mit Chemie beschäftigen. Und wieso soll er gerade mit Assembler anfangen? Man versteht Maschinensprache und die Eigenheiten einer CPU viel besser, wenn man sich vorher mit Logik und CPU-Design beschäftigt hat. Insbesondere sehe ich an dieser Stelle auch keinen Lerneffekt durch Assembler: Die CPU läuft nicht mit dem Takt, den er vermutet hat. Wenn er die Warteschleife in Assembler geschrieben hätte, dann hätte er vermutlich ewig an der Schleife rumgesucht und nichts gefunden.
> Man versteht Maschinensprache und die Eigenheiten > einer CPU viel besser, wenn man sich vorher mit Logik und CPU-Design > beschäftigt hat. Richtig. Und wenn man mit ASM beginnt, muss man sich zwingend mit der Controller-Architektur befassen. BASCOM ist so weit von der Hardware entfernt, dass man sich nicht richtig mit der Architektur befassen kann. Die vielen BASCOM-Fragen zum Umgang mit der internen Peripherie bestätigen meine Aussage. Wem die vorhandenen Bausteine des Baukastens BASCOM reichen, der möge sie verwenden. Wer aber tiefer vordringen will, der stößt schnell an Grenzen. Wenn du mit BASCOM glücklich bist, dann ist doch alles ok. Da ich gern die Übersicht über das, was ich mache, behalte, schreibe ich meine Programme in Assembler. Und wenn jemand Verständnisprobleme mit der internen Peripherie (Timer, ADC, Interrupt...) hat, stelle ich auch mal ein Programm zur Verfügung, in dem diese Hardware benutzt wird, um zu zeigen, wie man es machen kann (nicht muss). Was ist daran falsch? ...
@Markus: Wenn ich das richtig verstehe, scheint es wohl so zu sein, das trotz Setzen der entsprechenden Konfigurationsvariablen auf die korrekten Werte nur Müll herauskommt. Und dass Ändern dieser Variablen nichts am Ergebnis ändert. Sollte das nicht anders sein? <OT> Zum Thema 'Anfangen mit Assembler': Meine Bascom-Versuche waren auch komplette Fehlschüsse, hab' dem Kram dan von der Platte gefegt und mit Assembler angefangen - Nach 10 Minuten blinkte die erste Led. Im richtigen Tempo. Denn da kann man durch Abzählen schnell feststellen, ob es am Controllertakt liegt, oder ob man sich verrechnet hat. Bei Interpreter/Compilersprachen kann man nicht hineinsehen, man weiss einfach nicht ob da nicht der eine oder andere dicke Hund drin vergraben ist. </OT> Gruss Jadeclaw.
das kann doch net sein gibt genug leute die bascom verwenden und auch damit klarkommen. z.b. roboternetz. da wird zum großteil bascom verwendet. @markus kaufmann: mir ist klar, daß ich 1 000 000 einstellen MÜSSTE, aber es ist EGAL was ich einstelle!! er nimmt arauf überhaupt keine rücksicht ich glaub ich könnte sogar 123 456 789 einstellen und ihn würde es nicht jucken... ob ich 1mhz, 4mhz,8 mhz oder 16mhz einstelle ist egal die zeiten sind immer um den gleichen faktor falsch! waitms 1000 sind IMMER ca. 8sekunden, egal welchen takt ich einstelle. @all: ich denke für die grundfuktionen kann ich auch mit bascom gut basteln und im falle des falles kann ich auch nen stück inline assembler setzen.
> @all: ich denke für die grundfuktionen kann ich auch mit bascom gut > basteln und im falle des falles kann ich auch nen stück inline > assembler setzen. Wenn du meinst... Ich kann aber gut und gerne darauf verzichten, dass bei jedem Interrupt 128 Takte vertrödelt werden, nur um alle 32 Register zu sichern und wiederherzustellen, obwohl sie in der ISR nicht benötigt werden. Und kein halbwegs ernstzunehmendes Programm kommt ohne Interrupts aus. Inline-Assembler ist lächerlich, wenn man keine Übersicht über die von BASCOM genutzten Ressourcen (Register, SRAM...) hat. Also mach du es auf deine Art, ich mache es auf meine Art, und das funktioniert bei mir sogar. Entschldige bitte, dass ich helfen wollte. :=) ...
>BASCOM ist so weit von der Hardware entfernt, dass man sich nicht >richtig mit der Architektur befassen kann. Kann man schon. Muss man aber nicht. >Die vielen BASCOM-Fragen zum >Umgang mit der internen Peripherie bestätigen meine Aussage. Dafür wollen die Assembler-Programmierer dann wissen, wie man zwei 16Bit-Zahlen multipliziert und ähnlichen Trivialkram. Dieses Problem stellt sich dem Hochsprachenprogrammierer gar nicht erst. >Wem die vorhandenen Bausteine des Baukastens BASCOM reichen, der möge >sie verwenden. Wer aber tiefer vordringen will, der stößt schnell an >Grenzen. Welche Grenzen soll BASCOM denn haben? > Wenn du mit BASCOM glücklich bist, dann ist doch alles ok. Bin ich nicht - aber das liegt eher an den Eigenheiten von Bascom. Ich kann es z.B. absolut nicht ausstehen, daß man in Bascom nicht X = A + B + C schreiben kann. Aber das geht in Assembler ja auch nicht. >Da ich gern die Übersicht über das, was ich mache, behalte, schreibe >ich meine Programme in Assembler. Das geht auf Dauer nicht. Irgendwann kommst Du an den Punkt, an dem Du Dich entscheiden mußt, ob Du lieber ein Jahr Arbeit in ein Teilproblem investieren willst oder doch den fertigen Baustein benutzt. Aber auch wenn der Aufwand nicht so extrem ist, so kann man sich mit fertigen Modulen einfach oftmals auf die eigentliche Arbeit konzentrieren: Ich habe u.a. Fernbedienungssignale ausgewertet. Zuerst die Rohdaten zum PC geschickt und von Hand analysiert und als ich dann das Datenformat verstanden hatte habe ich die Daten auf dem MC ausgewertet und auf einem LCD dargestellt. Dank der fertigen Routinen in Bascom konnte ich mich auf das eigentliche Problem (die Signalauswertung) konzentrieren. Hätte ich auch noch die RS232- und die LCD-Ansteuerung schreiben müssen, dann hätte das sicherlich doppelt so lange gedauert. Und ich bezweifle, dass ich dabei viel gelernt hätte. Markus
@Henning: Stehen im .cfg-File (Frequency= )und im .rpt-File (XTAL= am Anfang und _XTAL= am Ende) die richtigen Frequenzen drin?
im *.cfg file steht mittendrin bei controller connection oder so "Frequency= 1000000". im *.rpt file steht oben so ca. zeile 20 "XTAL = 1000000" und fast ganz am ende steht das selbe nochmals mit unterstrich vor XTAL... ich meine ich verstehe euch ja, daß ihr lieber c oder assembler programmiert. aber ich brauche keine großartigen routinen etc. sondern nur relativ stumpfe funktionen! daher nutze ich halt gern bascom da ich ein basic kind bin bzw. schon immer war ;) und ich meine diese funktion scheint im allgemeine ja zu funzen genau wie z.b. bascom interne servofunktion aber aufgrund der bei mir schief laufenden frequenzen/timings gehts halt net :( also ich denke nicht, daß es was grundsätzliches im programm ist sondern entweder ich habe noch irgendwo eine einstellung vergessen oder die meinige bascom version ist buggy.
Welche Version verwendest Du denn? Ersetz doch mal die Waitms 1000 durch Waitms 250 Waitms 250 Waitms 250 Waitms 250 Nur so 'ne Idee, falls da ein Bug vorliegt. Ich habe mir das vor ein paar Jahren mal näher angeschaut, damals konnte Bascom mit 16Bit-Dauer umgehen, aber FastAVR (anderer Basiccompiler) nicht. Letzerer hat dann einfach die unteren 8Bit genommen.
naja zur zeit läuft das waitms 1000 ja, aber die servofunktion von bascom besipielsweise macht 7hz statt 50hz... habe wirklich das gefühl der controller macht was er will...
Der Controller macht was du ihm angiebst. Ich habe dein test2 mal in meinen Mega8 hineingespielt, funktioniert ohne Änderung. Die LED blinkt im sekundentakt. Nun rate mal wo der Fehler liegt. Zur Programmmierdiskussion, ich programmiere in C, aber es soll jeder mit dem arbeiten mit dem er am besten zurechtkommt. Hubert
Nur mal so interesse halber: Benuzt du PonyProg und hast eventuell nur Programm ohne vorheriges Erase durgeführt?
Hallo Henning Ich denke Du mußt erst durch programmieren der Fuses Deinen Chip dazu bringen die Richtige Frequenz zu benutzen. Ich verwende Bascom und STK500 seit Jahren und habe mit den Wait Befehlen noch nie Probleme gehabt (inkl. 1....16 Mhz Quarze und internes RC Timing). Insgesamt bin ich mit Bascom seh sehr zufrieden und wenn ich mal ein Problem hatte so hat man mir bei MCS sehr schnell und extrem kompetent geholfen. Bleib bei Bascom denn Du bist sicher 20 Mal schneller mit einem Projekt fertig als mit Assembler. Das komplizierteste was ich gemacht habe ist eine komplette Einspritz und Zündanlage mit Kennfeldern fürs Motorrad und da wurden nur meine Limits erreicht und nicht die von Bascom. Michael
Falls ich gemeint bin. Ich benutze PonyProg und habe vorher ein Erase durchgeführt. Ich habe auch einen anderen Quarz 3MHz verwendet mit dem richtigen Ergebnis.
>>habe wirklich das gefühl der controller macht was er will...
Da sind wir wieder beim Punkt, der Controller macht das, was er SOLL.
Fakt! Der hat kein Eigenleben.
Was bei dir nämlich nicht funktioniert ist BASCOM !
Würdest du Assembler benutzen, weißt du 100%ig was der Controller tut.
Bei BASCOM nicht.
Viel Spaß noch mit deinem Problem, aber so baukastenartigen Sachen wie
BASCOM tu ich mich nicht an.
Ohne jetzt den "Flamewar" wieder anzuheizen: Ich programmiere in C. Ich sehe das als "Zwischending" zwischen Assembler und "Hochsprachen" wie BASCOM an: Man muß sich um fast alles selber kümmern. Sowas wie Stack-Initialisierung oder Interrupt-Vrktor-Tabelle spare ich mir gerne. Solche Sachen kann der Compiler weniger fehlerträchtig erzeugen. Andererseit muß ich mich aber um Sachen kümmern (und sie verstehen), was mir BASCOM abnehmen würde, wie die Einstellung der Fuses. Eigentlich ist egal, mit welcher Sprache man zum Ergebnis kommt, man muß nur wissen, wie man zum Ziel kommt. Und wenn man sich dabei auch um die Fuses kümmern muß, dann ist es halt so. Wer sich nicht traut, sich das Datenblatt zur Hand zu nehmen und versucht, die Sachen selber einzustellen, dem muß man vermutlich auch bei grün über die Strasse helfen. Wer mit Mikrocontrollern rumbasteln will, der muß sich auch mit deren Innenleben beschäftigen; egal in welcher Programmiersprache.
Kann man schon. Muss man aber nicht... Mit Bascom kann man es nicht. Die Bascomer befassen sich nicht mit dem AVR , sondern kennen nur die Paste und Copy-Taste. Sind sehr faule Progammer.
Hallo Henning, Dein Programm funktioniert einwandfrei. Ich habe es eben in einen ATtiny2313 mit 14,7456 MHz Quarz geladen. Portpin d.5 blinkt im Sekundentakt. Es kann eigentlich nur an falschen Fusebits liegen.
@Rahul Ich glaube nicht das dir BASCOM die Einstellung der Fuses abnimmt, was aber im gegebenen Fall das Problem sein dürfte, sonst würde sich bei mir nicht der Takt ändern wenn ich den Quarz tausche
Um zum ursprünglichen Thema zurückzukommen (BASCOM hin oder her, ich
programmiere auch in C und Assembler, habe von BASCOM keine Ahnung,
aber das will der Thread Opener eh nicht wissen, der will nur wissen,
wie er seinen µC ans laufen kriegt, und das dürfte in dem Fall ein
programmiersprachenunabhängiges Problem sein):
Das setzen der Fusebits ist in Ponyprog dann kein Problem, wenn Du
beachtest, dass Du zunächst die aktuellen Einstellungen liest (mit
Read) und dann erst Deine Änderungen machst, so dass das
'gefährlichste' Fusebit SPIEN, das in PP 'ausgeblendet' ist, als
'programmiert' zurückgeschrieben wird. Für Quarze in dem genannten
Bereich müsstest Du die Häkchen bei allen CKSEL-Bits entfernen
('unprogrammed', also '1') und bei CKOPT ein Häkchen machen
('programmed', also '0'). Die SUT-Bits setze ich auch meistens
'1' (kein Häkchen). Damit müsste es eigentlich zunächst
funktionieren. Wenn Du dann noch das Häkchen bei JTAGEN wegmachst,
kannst Du auch Port C komplett nutzen.
Nur wie gesagt, erst die Bits auslesen, dann drauf achten, dass bei
SPIEN AUF_JEDEN_FALL ein Häkchen ist (_WICHTIGST!_). Dann nur die
Bits ändern, die geändert werden müssen, dann schreiben.
Ohne ändern der Fusebits CKSEL usw. wirst Du den Controller nie dazu
bekommen, mit etwas anderem als den internen 1 MHz zu laufen.
Gruß und frohe Ostern
Johnny
Nachtrag: Wozu brauchst Du eigentlich PonyProg? Aus Bascom heraus läßt sich doch genausogut flashen (eigentlich viel besser, weil die Einstellung der Fusebits viel komfortabler ist.
Angehängte Dateien:
-
isp1.jpg
18 KB
bascom unterstützt aber soweit ich das bisher herausgefunden habe nicht meinen einfachst seriell-programmer (siehe anhang). @johnny.m: vielen dank für die ausführliche heranführung an die fuses. werde mich daran dann wohl mal versuchen, das problem liegt aber doch woanders begraben denke ich, denn auch mit dem internen 1mhz takt gibt es diese probleme. @Läubi: öhm nö ein erase führe ich vor dem neu flashen eigentlich nicht durch. ich schieb einfach die neuen daten drauf. werde das mal testen.
> das problem liegt aber doch woanders begraben denke ich Mit 99% Sicherheit nicht. IN praktisch allen Fällen in denen das Timing trotz mehrfacher Kontrolle durch den Programmierer und des Forums immer noch nicht stimmt, stellte sich raus, dass der AVR mit einer anderen Frequenz lief als der Programmierer dachte.
hm das misteriöse ist eben, daß es zur zeit läuft zumindest die led im 1sek takt. aber werds trotzdem auf 8mhz legen das ganze.
Angehängte Dateien:
-
avr-parallel.gif
4 KB
@Henning, Aber dieser Programmer wird von Bascom unterstützt und ist bestimmt um vieles schneller als der serielle (eingetragen wird er als STK200/300).
also der 16er läuft... aber ich glaube beim 8er müssen die fuses anders gesetzt werden denn der is nun nicht mehr ansprechbar :D
@Jack: Das ist kein Paralleler Programmer, sondern ein serieller...
Das Ding ist ein serieller Programmer und nennt sich SI-Prog. Infos gibts bei Lancos (http://www.lancos.com/prog.html). STK200 ist afaik ein Parallel-Programmer.
Das ist einb serieller Programmer am Parallelport (LPT, Druckerport)... @Hubert G: War eher so gemeint, dass Bascom einem vieles abnimmt, aber nicht die Fuses-Einstellung.
Sorry, unklar ausgedrückt. In Bezug auf den µC sind natürlich beide seriell. Ich meinte natürlich, dass der SI-Prog über RS232 läuft. Tschuldigung
@Simon, alle Programmer für SPI sind seriell, aber eben am Parallelport er- heblich schneller als am seriellen (und über den programmiert er ja, siehe isp1.jpg
Ja, aber es ist trotzdem kein Parallelprogrammierer, selbst wenn er am parallelen Port hängt. Parallele Programmierer werden über mehrere Pins mit dem AVR verbunden. Und warum sollte denn der LPT im Pin-toggln schneller sein als der serielle?
Hallo Henning, nimm das mal. Fuses richtig gesetzt ist natürlich Voraussetzung. $regfile = "m16def.dat" $crystal = 8000000 Config Portd = Output Do Waitms 1000 Portd.5 = 1 Waitms 1000 Portd.5 = 0 Loop Bei deinem Test2.zip hat Bascom einige Fehlermeldungen gebracht, kannste also kaum ausprobiert haben.
Gibt es eine neuere Bascom-Version die "Portd 0.5 = 1" versteht. Entweder ist es Port D5 oder Port D0 oder?
Das hat mich auch gewundert, aber ich habe die aktuelle Version geholt und da lief es plötzlich. Und er beschwert sich ja auch nur über die Geschwindigkeit.
??? also ich habe bascom version 1.11.8.2 der code von test2.bas lautet wie folgt: $regfile = "m16def.dat" $framesize = 24 $swstack = 8 $hwstack = 32 $crystal = 1000000 Config Portd.5 = Output Do Wait 1 Portd.5 = 1 Wait 1 Loop wüsste nicht wo da ein fehler drin sein sollte? weiss net wie ihr da auf port 0.5 kommt... habe auch mal die zip nochmal entpackt und reingeschaut, auch da steht nix von "0.5"... der code funzt zur zeit einwandfrei, glaube es lag echt daran, daß ich nicht vorher den chip erast habe. tue das nun immer... aber ich habe mit den selben fuseeinstellunge wie beim 16er mal versucht einen mega8 auf externen quarz umzustellen (nach datenblatt sind es die selben einstellungen wie beim 16er) aber der ist nun tot. bekomme nur noch device missing... :(
äh da fehlte eben noch ne zeile vor dem "loop" ;) (Portd.5 = 0)
Leg mal an XTAL1 einen Takt von 1 - 4MHz an und versuch nochmal die Fuses vom ATMega8 zu lesen. Geht es, dann den Clock korrekt einstellen, dann will er auch wieder. Und zukünftig dran denken: 1. Vor dem Ändern einer Fuse IMMER die Fuses lesen, erst dann ändern und zurückschreiben. 2. Fuse-Einstellungen sind zwischen verschiedenen Typen nicht immer übertragbar. Port 0.5 ? Vom Bascom gibt es auch eine Version für den Intel 8051. Dort werden die Ports durchnummeriert. Hier natürlich wenig hilfreich. Gruss Jadeclaw.
@Henning Deine .bas Datei wird bei mir von VB geöffnet und der hat da die 0 dazugepackt. War bei dir also alles ok. @Markus Ich brauch tatsächlich ne neue Version. Das Autoupdate in meiner Vollversion(1.11.7.4) funktioniert nicht mehr, MSC hat da was geändert, muß mich jetzt erst registrieren.
hallo jadeclaw, ich habe vorher die fuses gelesen und sie dann gesetzt. habe nu schon 2 atmega8 zerlegt :( leider habe ich keinen hochfrequenzgenerator.
Brauchst du auch nicht. Wenn du noch einen µC hast, dann programmier ihn so, dass er einen Pin toggelt. Den benutzt du dann als Taktgenerator.
>Brauchst du auch nicht. >Wenn du noch einen µC hast, dann programmier ihn so, >dass er einen Pin toggelt. Den benutzt du dann als >Taktgenerator. War nicht das Pintogglen mit definierter Frequenz das Problem?
Ich denke, im Moment hat er das Problem, dass er 2 ATMegas zerfust hat und nicht weiss, wie er die wieder ins Leben zurückholt.
Vielleicht sollte ich doch einen "zerfuste-Mikrocontroller-Reanimier-Service" anbieten...
> Vielleicht sollte ich doch einen > "zerfuste-Mikrocontroller-Reanimier-Service" anbieten... Die Idee hatte ich auch schon... :) ...
Dann übernimmst du die Ost-Region und ich die Nord-Region... Im Süden und Westen werden sich auch noch Leute finden...
> Dann übernimmst du die Ost-Region und ich die Nord-Region... > Im Süden und Westen werden sich auch noch Leute finden... Im Prinzip ja... Nur leider habe ich da schon in deinem Revier "gewildert" indem ich 4 niedersächsische Tiny2313 wiederbelebt habe. So'n Mist aber auch... Grüß die Sprotten... ...
hm joa ich denke ich werd den irgendwie wieder ans leben bekommen unter umständen. aber das problem besteht noch immer, wenn ich sie auf externen quarz fuse sind sie platt und ich weiss nicht woran es liegt. :(
Wie hast du denn überhaupt die Fuses eingestellt? (nicht die Brennmethode, sondern die Werte interessieren...)
Henning, vielleicht hast du ja noch ein Verständnisproblem betreffs Taktquellen und fust daher auf eine andere Quelle, als du denkst. Analysiere doch mal das Kapitel Clock-Sources im Datenblatt und versuche mal, die verschiedenen möglichen Taktquellen den verschiedenen Fusebiteinstellungen exakt zuzuordnen. Vielleicht klärt sich dadurch dein Irrtum auch ohne fremde Hilfe auf. Falls du im Osten zu Hause bist, stelle ich dir deine zerfusten AVRs gerne wieder auf Auslieferungszustand. ...
Also ich habe den Atmega8 mit genau den selben Einstellunge geflasht wie den Atmega16 (der ATMEGA16 läuft). Habe alle CKSEL Bits nicht aktiviert und den Haken bei ckopt gesetzt.
Wieviel MHz hat der Quarz? Laut Datenblatt ist CKOPT gesetzt(=0) und CKSEL 1-3 nicht gesetzt (=1) für Quarze kleiner 1 MHz. Für schnellere Quarze muss CKOPT ebenfalls nicht gesetzt(=1) sein. Diese Einstellung ist für ATMega8 und 16 gleich. Was mich wundert, dass der 16 damit läuft. Die beiden Caps (12-22pF) auch dran? Gruss Jadeclaw.
CKSEL = 0000 oder CKSEL = 1111 ? Im ersten Fall brauchst du jetzt einen Quarzoszillator, im zweiten Fall "nur" einen Quarz (mit Kondensatoren). CKOPT ist IMHO irrelevant.
Angehängte Dateien:
-
ttl_qu_oszillator.gif
973 Bytes
Quarzoszillator selbstgemacht --> Anhang Gut für 1 - 16MHz. Gefunden hier: http://www.netzmafia.de/skripten/hardware/digital/digital.html Gruss Jadeclaw.
habe das grad mal mit dem oszi nachgemessen und mir fiel auf es ist ein 4mhz und kein 8mhz quarz. muss ich dann vielleicht low frequency crytal setzen? die kondis sind richtig dran (22pf) beim 16er ist es ein 8mhz...
öhm niemand eine antwort dazu? low frequency crystal oder nicht?
>öhm niemand eine antwort dazu?
Das Datenblatt vielleicht...Die meisten, die sich hier rumtreiben
müssten vermutlich auch ins Datenblatt wegen der Einstellungen
gucken...
Irgendeine Fuseeinstellung ist für "3-8MHz external resonator" (oder
so ähnlich) verantwortlich.
Low Frequency ist eher der Bereich <1MHz...
Table 4 auf Seite 25 des Mega8-Complete-Datasheet...
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.