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
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
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
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
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
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é