ATmega32U2 und (fast) nix geht.

[AE (Gast)]

Hi,
nach 2 Tagen erfolgloser Tests mit einem ATmega32U2 USB Board brauche 
ich mal eure Hilfe:
(Grundsätzliches läuft, wie das Hexfile mit Flip programmieren und zu 
starten und der Bootloader)

Die Richtungsports DDRB und DDRD lassen sich offenbar programmieren, die 
Datenregister auch, da sich Änderungen da bemerkbar machen (an den 
angeschlossenen LEDs)
Die LEDs bleiben an B6 (H-aktiv) und D3 (L-aktiv) aber bei entspechender 
Programmierung nicht statisch ein sondern flackern mit 5-10 Hz.
Nach Reset keine Verhaltensänderung, nach Spannung (Vcc) aus-ein 
allerdings sind sie statisch ein.

Für die Code-Fans:
  .include "m32U2def.inc"

.def temp    = r16
.def leds = r17

main:
         ldi r16, 0xFF
         out DDRb, r16       ; Inhalt von r16 ins IO-Register DDRB 
ausgeben
         out DDRD, r16       ; Inhalt von r16 ins IO-Register DDRD 
ausgeben

         ldi r16, 0b01001011 ; B6 H-aktiv und D3 L-aktiv
         out PORTb, r16      ; r16 ins IO-Register PORTB ausgeben
         out PORTd, r16      ; r16 ins IO-Register PORTD ausgeben
schleife1: rjmp schleife1

Inwiefern spielt da mit rein ob das von AVR studio erzeugte debug oder 
release-Hexfile geladen wird?

Werde morgen mal mit Oszi schauen...

[AE (Gast)]

Bin nun völlig gefrustet.
Aber auch neue Erkenntisse:
Der Quarz schwingt mit 16 MHz.
Das Flackern ist tatsächlich jedesmal nach dem flashen, das nervt zwar 
aber wenn man es weiß, kurzer Kaltstart und läuft. Kennt das noch wer?
Werde mal morgen probieren ob ein Kleiner Elko auf der Platine was 
bringt, irgendwie siehts nach schief gelaufenem Reset aus.

Was richtig Stress macht und mich schon beim Thema UART ewig Zeit 
gekostet hat, daß offenbar was mit dem Systemtakt was nicht stimmt.
Habe mehrfach ausgerechnet und recherchiert, Theorie und Praxis kommen 
nicht zusammen.
Also 16 MHz Quarz mit einem Prescaler von 1024 macht 15625 Takte pro 
Sekunde. Für 100ms also rund 1562.
ldi     temp, ((1<<CS11)|(1<<CS10));|(1<<WGM12))     ; Teiler 1024
sts     TCCR1B, temp

Lade ich diese 1562 = 0x061A wie folgt in das Compare-Register,
ldi    temp1, 0x06
ldi    temp2, 0x1A
sts    OCR1AH, temp  ;Compare Register beschreiben
sts    OCR1AL, temp2  ;
fängt das den Wert aber erst nach ca 32 Sekunden ein.

Stelle ich den Prescaler auf 1, erfolgt der Compare nach 110ms.
Mir ist völlig schleierhaft wie der interne Takt offenbar bereits so 
niedrig sein sollte - kann doch nicht sein...

[Thomas F. (igel)]

> ldi    temp1, 0x06
> ldi    temp2, 0x1A
> sts    OCR1AH, temp  ;Compare Register beschreiben
                     ^

Sollte hier nicht temp1 stehen?

[AE (Gast)]

Ja hast recht. Ist mir beim posten passiert.
Daher kommts nicht.
Es muß am Clock liegen, wie sonst könnte ich Compare-Zeiten von einer 
halben Minute bekommen...
Rechnerisch sind im o.g. Rahmen max. ca. 4 sec möglich

Habe grad nochmal das ganze auf Interrupt-Betrieb umgestellt- (vorher 
war nur Compare-Bit-Polling) aber nix neues....

Kann das Problem möglicherweise von irgendeiner fuse kommen die  der 
USB-Teil im Bootloader braucht? Sollten lt.Datenblatt zwar separat 
laufen aber langsam gehen mir die ideen aus.
(Hab eben beim googeln was ähnlich klingendes entdeckt.)

[AE (Gast)]

Das im Eingangspost erwähnte Flackern kann ich definitiv verhindern wenn 
bei FLIP das Häkchen neben dem Start Application Kopf weggenommen wird.

(Flackern wenn LED angesteuert wird, bei Timern usw äußert sich das eher 
in nicht erfolgender Compare_Out-Port Toggelei usw.)

Beim Timer hab ich es jetzt empirisch so gelöst daß ich den Prescaler 
auf 8 gestellt habe und CTC Modus eingeschaltet:
  ldi     temp, ((1<<CS11)|(1<<WGM12));|(1<<CS12))     ; Teiler 8
        sts     TCCR1B, temp
Per Compare Interrupt (der netterweise den Zähler auch wieder 
runterstellt)
        ldi     temp, (1<<OCIE1A)      ; OCIE1C: Compare C Match 
INTERRUPT
        sts     TIMSK1, temp
wird dank
  ldi temp, (1<<COM1A0) ;COM1A00: toggeln an OC1A= port c6
  sts     TCCR1A, temp
wenn man es erlaubt mit
  ldi  temp, (1<<DDC6)    ;Ab jetzt kann Port6 toggeln
  out  DDRC, temp
ein prima Kontrollsignal sichtbar an Port c6
Meine 100ms bekomme ich da bei Vorladen von 0x61a8.
Was ganz offensichtlich mit 4 Bit Aufwärtsverschiebung dem theoretisch 
errechneten Wert von 0x061A und damit seinem 16-fachen recht nahe kommt. 
Bedingt durch den niedrigeren Vorteiler ergibt sich ein Systemtakt von 
2MHz

Nachdem ich das Datenblatt nochmal nach Fuses gescannt habe, der Beweis, 
schön versteckt:The device is shipped with the CKDIV8 Fuse programmed.

Danke auch. Jetzt paßt keine einzige Baudrate mehr na danke.

Vielleicht 19,2k mit verdoppelter Geschwindigkeit

Vielleicht hilfts ja jemand.
Ist übrigens ein NooGroove Board aus Amiland. Gabs grade reduziert in 
der doofen Bucht.
Gute N8