Searcher

Hallo,
kein Tag ohne Probleme

Nachdem ich mit dem Datenblattbeispiel "SPITransfer_Fast", wie im vorherigen Blogeintrag beschrieben, mit 8MHz SPI-Takt Daten über das USI los geworden bin, habe ich heute versucht auch wieder Daten damit einzulesen. Natürlich gab es da auch ein Problem.

Die "SPITransfer_Fast" stellt mit dem ersten Befehl "out USICR , R16" den three wire mode auf dem USI für SPI ein und toggelt gleichzeitig durch strobe auf USITC den SPI-Taktausgang SCK. In meinem Fall von LOW to HIGH. Das Setzen des three wire mode veranlaßt das USI gleichzeitig das erste Bit aus USIDR an den Datenausgang DO anzulegen. Das folgende "out USICR , R17" toggelt durch USITC wiederum den Takt von HIGH nach LOW und schiebt durch USICLK strobe das nächste Bit aus dem Schieberegister auf die DO Leitung. usw.

Code:

    SPITransfer_Fast:
    Out Usidr , R16                             'store data to USI shift out register
    ldi r16,(1<<USIWM0)|(1<<USITC)
    ldi r17,(1<<USIWM0)|(1<<USITC)|(1<<USICLK)
    Out Usicr , R16                             'three wire mode (first bit to DO), toggle SCK to HIGH
    Out Usicr , R17                             'three wire mode (already set), toggle SCK to LOW AND shift next bit to DO
    Out Usicr , R16                             'three wire mode (already set), toggle SCK to HIGH
    Out Usicr , R17                             'three wire mode (already set), toggle SCK to LOW AND shift next bit to DO
    .
    .
    .

Das erste "out Usicr , R16" hat mich Stunden der Fehlersuche gekostet, da es fehlerhaftes Einlesen vom Flashspeicher mit dem "Continous Array Read" verursacht hat.

Der Flashspeicher stellt sich automatisch auf SPI mode 0 ein, wenn er bei HIGH to LOW Flanke am CS (chip select) ein LOW auf der SCK Leitung findet, wie bei mir.

Zum "Continous Array Read" gibt es die Opcodes 0xE8 und 0x68. Einer von beiden muß zuerst als Befehl zum Flashspeicher geschickt werden. Der Unterschied zwischen den beiden besteht darin, daß der Flashspeicher mit 0x68 sein erstes Daten-Bit in Richtung µC eine fallende Taktflanke später anlegt als bei 0xE8. Ich wollte das 0xE8 benutzen

Dadurch, das durch das "Out Usicr , R16" das MSB (most significant bit) von dem 0xE8, ein HIGH gleichzeitig mit der Taktflanke LOW nach HIGH angelegt wurde, hat der Flashspeicher dieses erste HIGH nicht mitbekommen und im weiteren Verlauf mit 0x68 gearbeitet. Der Flashspeicher braucht eine "Data In Setup Time" von mindestens 5ns, in dem die Daten anliegen müssen bevor die LOW to HIGH Taktflanke zur erfolgreichen Datenübernahme kommen darf. Die Folge waren verfälschte Daten beim Auslesen des Flashs, da diese dann einen Takt später als erwartet ankamen.

Habe dann einfach noch ein "SBI USICR , USIWM0" vor dem ersten "Out Usicr , R16" eingefügt, so daß das MSB vom 0xE8 früh genug (ein Einzyklusbefehl -> 1/16MHz=62,5ns) vor der ersten Taktflanke auf der Leitung liegt.

Da die HW Pins des USI und die ISP Programmierpins sich überschneiden und beim Flashzugriff mit gestecktem Programmer stört, hat der ATTiny861A ein schönes Feature. Mit dem USIPOS Bit im USIPP Register kann man die USI Leitungen von PB0, PB1, PB2 auf PA0, PA1, PA2 umschwenken. Hab ich sofort genutzt

Mühsam ernährt sich das Eichhörnschen