SPI-Bus, SD-Karte, CAN und LCD -> wie lösen(C/C++)?

Dein AVR hat 2 UARTs, die Du auch im SPI-Modus betreiben kannst. Es ist 
am Besten, CAN und SD-Karte auf getrennte SPI-Ports zu legen oder - noch 
besser - einen Controller mit integriertem CAN zu verwenden.

fchk

NickNack schrieb:
> Da beide Möglichkeiten leider nicht umsetzbar sind bleibt nur die
> Softwarelösung.

Klar sind die Umsetzbar. Warum nicht? Es ist schwer zu helfen, wenn man 
die Hintergründe nicht kennt.

@ NickNack (Gast)

>ich stehe gerade vor der Aufgabenstellung eine SD-Karte, einen
>CANbus-Treiber(MCP2515) und ein SPI-Lcd(1,8"noname)an einem
>Atmega1284(als Spi-Master) zu betreiben.

Kein Problem.

>Da ja immer nur einer der Teilnehmer gleichzeitig auf dem Bus aktiv sein
>darf, stelle ich mir die Frage wie ich diese am besten entkoppel und
>nacheinander abarbeite?!?

Nacheinander? Siehe Multitasking.

>Ein Taskmanager ist vorhanden, allerdings wie löse ich z.B. das
>pollen(dummy-bytes senden) bei der SD-Karten-Initialisierung bis diese
>antwortet(Bibliothek: http://www.roland-riegel.de/sd-reader/)?...

Ich sehe da kein Problem. Man ruft die Init-Funktion der SD-Karte auf, 
die arbeitet ne Weile, dann ist sie fertig. SD-Karte wird per Chip 
Select deaktiviert, dann können andere SPI-ICs angesprochen werden. Ganz 
normales kooperatives Multitasking.


>Programmiert wird im Atmel-Studio in C/C++.

Ohhh C++. Aber Keine Idee wie man so ein eher einfaches Problem angeht? 
Komisch.

NickNack schrieb:
> ich stehe gerade vor der Aufgabenstellung eine SD-Karte, einen
> CANbus-Treiber(MCP2515) und ein SPI-Lcd(1,8"noname)an einem
> Atmega1284(als Spi-Master) zu betreiben.

Und welcher von den dreien ist der "Update in Form einer 
Erweiterungsplatine"?

Hast Du noch GPIOs frei, um einen zusätzlichen Software-SPI zu ergänzen? 
Oder soll die Erweiterungsplatine mit einem zusätzlichen "Chip-Select" 
an den vorhandenen (Hardware-SPI?) angeschlossen werden?

Falk Brunner schrieb:
> SD-Karte wird per Chip
> Select deaktiviert, dann können andere SPI-ICs angesprochen werden.

Kann das "Chip-Select" nicht zwischendurch auch inaktiviert werden, um 
mit dem SPI andere Dinge zu machen? Oder nimmt das die SD-Karte krumm?

@Torsten C. (torsten_c) Benutzerseite

>> SD-Karte wird per Chip
>> Select deaktiviert, dann können andere SPI-ICs angesprochen werden.

>Kann das "Chip-Select" nicht zwischendurch auch inaktiviert werden, um
>mit dem SPI andere Dinge zu machen?

Komischer Satz.

Eher so.

Ja, Chip Select der SD-Karte kann zwischen Operationen inaktiv (=High) 
werden, damit wird die SD-Karte inaktiv geschaltet, in dem Sinn, dass 
die SPI-Kommunikation nicht an sie gerichtet ist. INTERN macht sie dabei 
natürlich KEINEN Reset sondern wartet auf neue Anweisungen per SPI, wenn 
CS wieder aktiv (= LOW) wird.

>Oder nimmt das die SD-Karte krumm?

Nö. Es gibt sicher ein paar Stellen, wo es Timeouts gibt, aber an die 
kommt man im Normalfall so nicht ran, wenn man eine fertige FAT-Lib 
benutzt, die stecken in den Details der SD-Karten Kommunikation und 
damit der FAT-Lib. Jeder Aufruf einer Funktion der FAT-Lib endet mit 
einem deaktivierten CS der SD-Karte. Also kann man sinngemäss einfach so 
machen.

1

while (1) {

2

  zugriff_SD-Karte()

3

  zugriff_CAN()

4

  zugriff_LCD()

5

}

@Falk Brunner (falk): Danke für die Klarstellung.

Torsten C. schrieb:
> Oder soll die Erweiterungsplatine mit einem zusätzlichen "Chip-Select"
> an den vorhandenen (Hardware-SPI?) angeschlossen werden?

PS: Oder ist vielleicht gar kein weiterer GPIO für ein weiteres CS frei? 
Dann kannst Du vielleicht aus zwei CS-Signalen vier machen, z.B. mit 
einem 74HC138.