FAT16_32 monopolisiert SPI-Bus

Hans K.

Subject:

FAT16_32 monopolisiert SPI-Bus

· Posted: 17.12.2013 - 11:28 · #1

Hallo

In meiner alten Version des AVRco (V4.93.00) hat der FAT16-Treiber jeweils den Inhalt des SPCR-Registers auf dem Stack gesichert und nach getaner Arbeit wieder hergestellt.
Die neue Version (V5.04.55) tut dies nicht mehr. Damit gibt es jetzt Probleme in Applikationen, wo auch andere SPI-Busteilnehmer mit unterschiedlicher SPI-Konfiguration arbeiten sollen (z.B. MP3-Player mit SDcard und VS1011).
Wäre es möglich, diese SPCR-Rettung wieder einzuführen? Ansonsten muss in jeder Applikation, welche in den Genuss des neuen FAT16_32-Treibers kommen will, umständlich nachgepflegt werden.

Gruss
Hans

Administrator

Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: FAT16_32 monopolisiert SPI-Bus

· Posted: 17.12.2013 - 13:32 · #2

Hallo Hans,

ich schaue mir das an.

rolf

Administrator

Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: FAT16_32 monopolisiert SPI-Bus

· Posted: 18.12.2013 - 18:28 · #3

Hallo Hans,

ich kann das ganze nicht nachvollziehen.
Dieses Register wird ja nur beim Init geschrieben und dann nie wieder.

Werden also unterschiedliche SPI Typen am selben Port angeschlossen
dann muss bei jedem Wechsel das Register neu gesetzt werden. Egal
wer das tut, die Applikation oder der Treiber, es ist derselbe Aufwand.

Aber nur die Applikation weis im Endeffekt was da zu tun ist oder nicht.

rolf

Hans K.

Subject:

Re: FAT16_32 monopolisiert SPI-Bus

· Posted: 19.12.2013 - 13:56 · #4

Hallo Rolf
Also, der FAT16_32-Treiber tut folgendes:

Code

; >> FAT16 Init <<
                        SBI       PORTB, 0
                        SBI       PORTB, 3
                        SBI       DDRB, 1
                        SBI       DDRB, 2
                        SBI       DDRB, 0
                        NOP
                        NOP
                        NOP
                        LDI       _ACCA, 05Ch
                        OUT       SPCR, _ACCA

Soweit klar. Dann aber auch:

Code

SYSTEM._DiskReset:
LDI _ACCA, 05Ch
SYSTEM._L3945:
OUT SPCR, _ACCA

Zu dem Zeitpunkt hat die Applikation das SPCR möglicherweise für einen anderen Busteilnehmer schon umgestellt.
und weiter:

Code

SYSTEM._PutByteSPI_S:
LDI _ACCB, 05Eh
OUT SPCR, _ACCB

Demgegenüber hatte sich V4.x etwas dezenter verhalten:

Code

SYSTEM._InitMMC:
                        IN        _ACCB, SPCR
                        PUSH      _ACCB
                        LDI       _ACCB, 05Eh
                        OUT       SPCR, _ACCB

// Der bestehende SPCR-Inhalt wird also gesichert
// und am Ende wiederhergestellt

                        POP       _ACCB
                        OUT       SPCR, _ACCB
                        LDI       _ACCA, 0
                        RET

Daneben gibt es keine weiteren Zugriffe auf SPCR.
Es stimmt, dass sich die Applikation um alles kümmern kann. Aber in einer Konfiguration mit nur einem weiteren SPI-Busteilnehmer wäre das Leben des Applikationsentwicklers einfacher, wenn der FAT16_32-Treiber den Bus wieder herstellen würde (wie das früher einmal der Fall war).

Gruss
Hans

Administrator

Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: FAT16_32 monopolisiert SPI-Bus

· Posted: 19.12.2013 - 13:59 · #5

Hallo Hans,

ok, das lässt sich realisieren.

rolf

Hans K.

Subject:

Re: FAT16_32 monopolisiert SPI-Bus

· Posted: 19.12.2013 - 14:13 · #6

Danke, Rolf.

Übrigens trifft dies auch auf den FAT16-Treiber zu, nicht nur den FAT16_32.

Gruss
Hans

Administrator

Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: FAT16_32 monopolisiert SPI-Bus

· Posted: 19.12.2013 - 16:49 · #7

Hallo Hans,

ich habe das mal näher nachgeprüft.
Es gibt im neuen Treiber mehrere Stellen wo das SPCR geschrieben wird.
Init, DiskReset, mehrere Speed Umschaltungen etc.
Z.B. muss bei diversen SDs die ersten Zugriffe mit low-speed erfolgen.
Dann erst kann mit high-speed gearbeitet werden.
Es ist sehr schwierig hier immer das richtige zu sichern und zurückschreiben.
Aus Zeitmangel werde ich das vorläufig nicht angehen.
Sorry.

rolf

FAT16_32 monopolisiert SPI-Bus

Registered users in this topic