|
Anzeige
|
Zu bloed fuer den Atmega88?Moin, ich versuche gerade krampfhaft, dem Mega88 sinnvolle ADC-Werte zu entlocken. Leider erfolglos, denn: 1. Sind die Werte beim nachrechnen einfach nur falsch 2. Schwanken einige unnatuerlicherweise nichtmal um ein Bit (wie beim Trabbi. Wenns nicht klappert, isser kaputt...).
Ahrg, vergessen weiterzuschreiben *g. Den asm-Teil hab ich aus Verzweifelung eingefuegt, da uc=getadc(channel) auch nicht wirklich funktioniert. Dazu ist vielleicht noch zu sagen, dass die gleiche Platine mit einem Atmega8 einwandfrei funktionierte, HW-Fehler kann man also ausschliessen. Ist der Mega88 wirklich noch so unausgereift, dass man ihn nicht verwenden kann? Auch der Watchdog fuehrt bei mir zu einem Absturz, aus dem man den µC selbst mit normalem HW-Reset nicht mehr befreien kann, sondern erst Klimmzuege machen muss. MfG
Gast
#213205
Passt der Prescaler zum Takt? Nein, aber da hab ich auch schon alles durch. 64 Sollte ja ganz gut passen aber damit klappts leider auch ned. mfG
Gast
#213207
liegt am dat-file/compiler. hab mit m168 ähnliche probleme.mit m8 dagegen alles bestens.... Ja aber eigentlich sollte es doch funktionieren. Ich hab das *.hex, das Bascom erzeugt in AVR-Studio geladen und keine Fehler gefunden. STS wurde ueberall richtig benutzt und die Adresse der Register stimmen auch alle. Komische Sache. MfG
Gast
#213209
Dass der Mega88 eine 1.1V-Referenz an Stelle einer 2,56V-Referenz hat, hast Du sicher berücksichtigt. Japp, die Referenz ist ja auch aus. Haengen 5V an Vref :( MfG
Gast
#213211
Was mit Bascom los ist weiss ich nicht, den kenne ich nicht. Aber mit
diesem Assembler-Code setzt Du den Prescaler auf /2, was bei dem Takt
nicht funktionieren kann:
ldi R25 , &B11000000 'start conversion (adcsr.adsc=1)
STS adcsr,R25
Hm, dat stimmt allerdings. Dieser Teil kam aus dem *.hex, das Bascom erzeugt hatte. Werd das mal eben testen. Vielen Dank und mfG, André Super, hab ich gar nicht drauf geachtet. Nun funktioniert das schonmal. Bleibt noch das Problem mit dem Watchdog, der macht was er will. Beim Atmega8 funktionierte folgendes: reset: start watchdog do:loop Fuehrte nach ca.16ms zwangslaeufig zum Reset. Beim Atmega88 fuehrt es dazu, dass der Controller eiskalt stehenbleibt und nicht mehr auf Reset-Signale reagiert. Vielmehr muss man ihm erst einige Sekunden den Saft abdrehen und kann ihn anschliessend durch wildes "Reset-Druecken" wieder zum Leben erwecken. Hat dazu vielleicht jemand ne Idee? Werde mich damit auch gleich nochmal befassen und evtl. das Stueckchen asm posten. Danke nochmal an meinen Fast-Namensvetter *g
Gast
#213214
Dafür wär's halt nützlich, zu wissen, was genau der Bascom draus macht. Immerhin hat der Mega88 einen Watchdog-Interrupt, der Mega8 nicht. Aber dass ihn dies dazu bringt, auf Reset nicht zu reagieren, das ist schon etwas bizarr.
Also er scheint, wenn man ihn denn einmal ans laufen gebracht hat, einmal zu "resetten". Danach kommt gar nix mehr, wobei ich vermute, dass er da irgendwo schon am Programmstart haengenbleibt und ihn irgendein Bit immer wieder am Weiterlaufen hindert. Das Bit laesst sich wohl nur mit recht unkonventionellen Methoden wieder richten. Werd dann mal weiter Datenblatt waelzen. MfG Naa, ist natuerlich Mist WDE gleich beim Start zu setzen *g. Der Compiler braucht dringend ein Update... Leider aendert sich dadurch auch noch nix, ich vermute es liegt am WDRF-Bit. MfG
Gast
#213217
In der üblichen Sequenz zum Einschalten vom Watchdog-Timer wird der
Timer unmittelbar davor vorher zurückgesetzt:
wdr
cli
ldi r24, (1<<WDCE) | (1<<WDE)
out WDTCSR, r24
; -- Got four cycles to set the new values from here -
; Set new prescaler(time-out) value = 1024K cycles (~8.0 s)
ldi r24, 1<<WDE | 1<<WDP3 | 0<<WDP2 | 0<<WDP1 | 1<<WDP0
out WDTCSR, r24
sei
Ausserdem steht im Datasheet, dass man in der Initialisierung WDRF
zurücksetzen sollte.
Alles wie gehabt :( Hab leider von C oder anderen Sprachen nicht unbedingt die grosse Ahnung. Koennte mal jemand versuchen, den gleichen Code in C zu schreiben und das *.hex oder *.bin zur Verfuegung stellen? Wenns geht mit gleicher Baudrate und gleicher Quarzfrequenz. Es schlug uebrigens auch ein Simulieren im AVR-Studio fehl, wobei das aber in Schleifen hing, wo es gar nicht haette haengen duerfen. Danke und mfG, André Antwort schreiben |
Anzeige
|
