Zu bloed fuer den Atmega88?

[André K. (andre-)]

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...).

$regfile = "m88def.dat"
$crystal = 18432000
$baud = 115200

Config Adc = Single , Prescaler = 8 , Reference = Off
Start Adc

Config Portc = Input : Config Portb = Input : Config Portd = Input
Portb = 0 : Portc = 0 : Portd = 0


Dim Uc As Integer
Dim Channel As Byte


Print "start"


Do
   For Channel = 0 To 7
      lds r25, {channel}
      sts admux, r25

      ldi R25 , &B11000000    'start conversion (adcsr.adsc=1)
      STS     adcsr,R25

      !x1:
      LDS     R25,adcsr
      SBRC    R25,adsc
      jmp x1               'wait for conversation's end
(adcsr.adsc=0)

      LDS     R22,adcl
      Lds R23 , adch

      sts {uc}, r22
      sts {uc+1}, r23

      Print Uc ; ":";
   Next

   Print
   Print
   Waitms 600
Loop

End

[André K. (andre-)]

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

[A.K. (Gast)]

Passt der Prescaler zum Takt?

[André K. (andre-)]

Nein, aber da hab ich auch schon alles durch. 64 Sollte ja ganz gut
passen aber damit klappts leider auch ned.

mfG

[Kai (Gast)]

liegt am dat-file/compiler. hab mit m168 ähnliche probleme.mit m8
dagegen alles bestens....

[André K. (andre-)]

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

[A.K. (Gast)]

Dass der Mega88 eine 1.1V-Referenz an Stelle einer 2,56V-Referenz hat,
hast Du sicher berücksichtigt.

[André K. (andre-)]

Japp, die Referenz ist ja auch aus. Haengen 5V an Vref :(

MfG

[A.K. (Gast)]

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

[André K. (andre-)]

Hm, dat stimmt allerdings. Dieser Teil kam aus dem *.hex, das Bascom
erzeugt hatte. Werd das mal eben testen.

Vielen Dank und mfG,
André

[André K. (andre-)]

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

[A.K. (Gast)]

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.

[André K. (andre-)]

$regfile = "m88def.dat"
$crystal = 18432000
$baud = 115200

LDI     R24,&B00011000           'set wdce  + wde
STS     wdtcsr,R24
LDI     R24,&B00010000           'wdtp = 16ms
STS     wdtcsr,R24

Wait 1
Print "start"

LDS     R24,wdtcsr
ORI     R24,8                    'set WDE
STS wdtcsr , R24


Do
Print "X"
Waitms 1
Loop


End

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

[André K. (andre-)]

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

[A.K. (Gast)]

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.

[André K. (andre-)]

$regfile = "m88def.dat"
$crystal = 18432000
$baud = 115200

cbi mcusr, 3

Wait 1
Print "start"

cli
wdr
LDI     R24,&B00011000
STS     wdtcsr,R24
ldi r24, &B00001000
sts  WDTCSR, r24


!xs:
jmp xs

End

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é