SPI via USI am ATTiny2313 - Schieberegister schiebt nicht

[Daniel L. (danielschlumpf)]

Hallo zusammen,

ich verzweifle schon seit einigen Stunden an meinem ISP via USI am 
ATTiny2313... ich gehe bei der Übertragung hierbei prinzipiell so vor:

- ich lade die Daten in das USIDR register
- ich aktiviere den Timer0 und lasse zählen
- bei jedem Timer0 Overflow wird ein Interrupt ausgelöst, in dessen ISR 
ich USITC setze um den Takt zu generieren (muss so langsam sein, passt 
schon)
- beim USI Overflow wird der Zähler gestoppt, Übertragung vorbei

Ich habe nun durch LEDs an den Ausgängen (extrem langsamer Takt) und 
funktionierende SPI-Empfänger folgendes Verhalten nachgewiesen:

- der Timer0 Interrupt kommt genau wie er soll
- synchron hierzu wird das Clock-Signal generiert
- MOSI bleibt jedoch konstant auf 0  :(

Mein ISP Empfänger kommt damit auch klar und zeigt mir als Ergebnis die 
empfangene 0x00 an. Scheint halt so, als ob das Schieberegister nicht 
vorgeschoben wird.


Vermutlich liegt der Fehler hierdrin, ich verstehe es nämlich nicht ganz 
(Referenz Datenblatt Seite 148):

Variante 1:

USICR = (1<<USIWM0) | (1<<USICS1) | (0<<USICS0) | (1<<USICLK);

ISR( TIMER0_OVF_vect )
{
  USICR |= 1<<USITC;
}

So steht's in vielen Quellen, ich erzeuge beim Interrupt über USITC die 
Clock selber. Laut Datenblatt wird das Schieberegister jedoch extern 
getaktet, wie soll das funktionieren?

Variante 2:

USICR = (1<<USIWM0) | (0<<USICS1) | (1<<USICS0);

So fände ich es sinnvoll, laut Datenblatt werden sowohl Schieberegister 
als auch der Counter direkt durch den Timer0 Overflow ausgelöst. Wenn 
ich das tue, erzeuge ich jedoch keinen Takt am Ausgang und es werden 
auch keine Daten geschoben.

Variante 3:

USICR = (1<<USIWM0) | (0<<USICS1) | (0<<USICS0) | (1<<USICLK);

ISR( TIMER0_OVF_vect )
{
  USICR |= 1<<USICLK;
}

Fände ich auch sinnvoll entsprechend Datenblatt (nun mit USICLK manuell 
getriggert anstelle USITC), aber generiert ebenfalls weder Takt noch 
Daten.



Wie müssen die Bits gesetzt werden, damit der Timer0 Overflow die ganze 
Geschichte takten kann?

Und wie funktionieren externe Takte, ist das nicht für den Slave-Betrieb 
gedacht?

DANKE!

[Daniel L. (danielschlumpf)]

GELÖST

Ich habe den Fehler gefunden, bin aber noch verwirrter als vorher, 
vielleicht kann mich jemand aufklären. Ich baue eine Kommunikation 
zwischen dem besagten ATTiny2313 und einem ATMega32 auf, mit dem ATTiny 
als Master und dem ATMega32 als Slave.

Damit es funktioniert, sind die Datenleitungen de facto nun so 
verschaltet:

ATTiny2313    ATMega32
USCK    <--->    SCK
MISO    <--->    MOSI
MOSI    <--->    MISO

Die Datenleitungen für MOSI und MISO sind also vertauscht, was 
eigentlich überhaupt keinen Sinn macht.

Ich verwende ausserdem ISP zum programmieren des ATTiny über die gleiche 
Stiftbuchse, über die ich auch die SPI-Signale austausche, und 
programmieren ging mit der 'normgerechten' Beschaltung ohne Probleme. 
Für den SPI-Datentransfer muss ich allerdings die beiden Pins MISO und 
MOSI tauschen...

Ist das eventuell ein Fehler im Datenblatt? Dass im Datenblatt die 
Bezeichnungen DO und DI sich auf den Slave-Betrieb beziehen und man für 
den Master umdenken muss, habe ich gelesen, aber es steht ja auch 
explizit MISO und MOSI an den Pins, seltsam...

Any ideas?

[Marc H. (mheimann84)]

Hallo,

Ich möchte ebenfalls den attiny2313 mit dem USI als Master SPI 
verwenden. Außerdem verwende ich ebenfalls ISP zum programmieren, was 
bei mir aber nach dem Draufspielen von Code, der das USI verwendet, 
nicht mehr funktioniert. Bei mir liegt der programmer quasi direkt auf 
den I/O Pins vom uC. Kann mir bitte jemand sagen, was eine 'normgerechte 
Beschaltung' bedeutet?

[Blackbird (Gast)]

MOSI - Master Output / Slave Input
MISO - Master Input / Slave Output

(ähnlich wie bei RxD und TxD)

Blackbird

[Marc H. (mheimann84)]

Hallo,

das Programmieren klappt bei mir, soweit ich nicht versuche das USI zu 
verwenden. Momentan ist der attiny2313 wie im Schaltplan (Anhang) 
angeschlossen. Bei http://elm-chan.org/works/avrx/report_e.html steht 
weiter unten: the ISP pins, RESET, SCK, MISO and MOSI must be reserved 
for ISP function. Anscheinend ist es aber Daniel Luscher gelungen den uC 
mit einer 'normgerechten' Beschaltung trotzdem zu programmieren.

[Vivil (Gast)]

Schau Dir mal dein RESET an.

[Marc H. (mheimann84)]

Den RESET habe ich gemäß 
http://www.mikrocontroller.net/articles/AVR_In_System_Programmer#ISP an 
Pin 5 angeschlossen. Der Pushbutton ist dafür da, um das Programm bequem 
neu zu starten. Wenn er nicht gedrückt ist, sollte nichts weiteres 
angeschlossen sein. Das ist zumindest meine Absicht :)

[Vivil (Gast)]

Es geht nicht darum wie du dein IPS beschaltet hast. Es geht darum wie 
Du den Reset am µC geschaltet hast.

[spess53 (Gast)]

Hi

>Es geht nicht darum wie du dein IPS beschaltet hast. Es geht darum wie
>Du den Reset am µC geschaltet hast.

Was soll denn da sein? Der ATTiny2313 hat einen internen 
Pull-Up-Widerstand am Reset-Pin.

MfG Spess

[Vivil (Gast)]

spess53 schrieb:
> Der ATTiny2313 hat einen internen
>
> Pull-Up-Widerstand am Reset-Pin.

Wie kommst du darauf.

[spess53 (Gast)]

Hi

>Wie kommst du darauf.

Datenblatt->DC Characteristics->Reset Pull-up Resistor.

MfG Spess