mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SPI oder CAN?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Paul W. (solarturtle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe eine Frage, welchen Bus ich nehmen sollte.

Folgendes Problem:
- Zwei Controller für Motorsteuerungen (Also 1 Controller = 1 Motor)
- Ein Master Controller (empfängt Daten von Motorcontroller wie Strom, 
IST-Speed etc. / Sendet an die Controller SOLL-Speed und evtl. weitere 
Werte)
- Motorcontroller sollen die SOLL-Speed Nachricht zeitgleich erhalten 
(10ms Raster)

Nun bin ich am Überlegen wie ich die Kommunikation am besten aufbaue.
Entweder CAN oder SPI. UART fällt wohl raus, weil zu langsam.

Kann ich bei SPI beide Slaves aktivieren, wenn ich die SOLL-Speed 
Nachricht sende, sodass beide Slaves die Nachricht zeitgleich erhalten?

Was würdest Ihr aufgrund eurer Erfahrung für einen Bus wählen, was ist 
schlauer? Beim CAN habe ich halt etwas höhere Kosten weil ich einerseits 
einen Motorcontroller mit CAN nehmen muss, wie auch für die zusätzlichen 
CAN Transceiver ICs.

Danke,
Paul :-)

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Paul W. schrieb:
> Entweder CAN oder SPI.
Das eine ist ein Feldbus für größere Distanz, das andere ein 
"Platinenbus".

> UART fällt wohl raus, weil zu langsam.
Warum zu langsam? So schnell wie CAN kann der allemal...

> sodass beide Slaves die Nachricht zeitgleich erhalten?
Schicke die Daten im Voraus und dazu einen Zeitstempel, wann die 
ausgeführt werden sollen...

: Bearbeitet durch Moderator
Autor: H.Joachim S. (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist in erster Linie ne Frage der Entfernung und der Störumgebung.
CAN heisst im Normalfall: fire and forget. Würde ich empfehlen.
UART ist nicht von sich aus zu langsam, ist ne Frage der zu 
übertragenden Datenmenge/Baudrate und verwendetem Protokoll. Kann man 
durchaus drüber nachdenken. SPI würde ich nur bei kleinen Entfernungen 
nehmen (oder du brauchst auch da wieder Treiberschaltungen).

Autor: Frank K. (fchk)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Paul W. schrieb:

> Kann ich bei SPI beide Slaves aktivieren, wenn ich die SOLL-Speed
> Nachricht sende, sodass beide Slaves die Nachricht zeitgleich erhalten?

Prinzipiell ja, ABER: !CS aktiviert ja bei einem SPI-Device MISO (Master 
In-Slave Out). Im nicht selektierten Zustand ist dieses Signal 
hochohmig. Wenn Du jetzt zwei Devices gleichzeitig aktivierst, wird MISO 
von zwei Chips getrieben, und das gibt Bruch. Du könntest die MISOs von 
den Slaves per AND (74AHC1G08) verknüpfen. Dann würde zwar nichts 
elektrisch mehr kaputt gehen, aber ob Du dann sinnvolle Daten bekommst?

Im Klartext: Nein, bei einen normalen SPI ist es nicht vorgesehen, dass 
zwei Slaves gleichzeitig betrieben werden.

Microcontroller mit mehreren SPI-Devices sind aber nichts 
ungewöhnliches. Darfst halt nur nicht ausschließlich bei AVR suchen.

fchk

Autor: Paul W. (solarturtle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Das eine ist ein Feldbus für größere Distanz, das andere ein
> "Platinenbus".

H.Joachim S. schrieb:
> SPI würde ich nur bei kleinen Entfernungen
> nehmen (oder du brauchst auch da wieder Treiberschaltungen).

Hmmm, nunja. Alle Controller werden sich auf einer gemeinsamen Platine 
befinden. Daher wäre die Entfernung auch klein.

Frank K. schrieb:
> Im Klartext: Nein, bei einen normalen SPI ist es nicht vorgesehen, dass
> zwei Slaves gleichzeitig betrieben werden.

Und wenn ich das SPI als Daisychain aufbaue? Dann müsste ich zwar die 
Speed Nachricht doppelt nacheinander senden, aber dafür übernehmen die 
Controller die Nachricht erst bei der SS Flanke, also zeitgleich.

Lothar M. schrieb:
> Schicke die Daten im Voraus und dazu einen Zeitstempel, wann die
> ausgeführt werden sollen...

Also würde quasi per Triggerpin auch gehen:
- Chip 1 Speed senden
- Chip 2 Speed senden
- 10ms Interrupt auf Master -> Gemeinsamen Interrupt-Pin auf den 
Controllern triggern, dann wird der Wert aus dem SPI Buffer übernommen.

Wäre das sauber?

: Bearbeitet durch User
Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paul W. schrieb:
> Frank K. schrieb:
>> Im Klartext: Nein, bei einen normalen SPI ist es nicht vorgesehen, dass
>> zwei Slaves gleichzeitig betrieben werden.
>
> Und wenn ich das SPI als Daisychain aufbaue? Dann müsste ich zwar die
> Speed Nachricht doppelt nacheinander senden, aber dafür übernehmen die
> Controller die Nachricht erst bei der SS Flanke, also zeitgleich.

Sofern die Slaves das können, wäre das eine Möglichkeit. Ich würde da 
aber eher einen Master mit zwei Hardware SPI Master nehmen. Gibt ja 
genug davon.

fchk

Autor: Paul W. (solarturtle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Sofern die Slaves das können, wäre das eine Möglichkeit. Ich würde da
> aber eher einen Master mit zwei Hardware SPI Master nehmen. Gibt ja
> genug davon.

Okay. Ich sehe gerade das der Motorcontroller den SPI schon braucht um 
den DRV Chip zu bedienen. :(

So könnte ich es aber auch per UART aufbauen, oder?
Also zwei UART zu den Slaves und vielleicht ein Triggerpin, auf dem die 
Slaves die Werte aktivieren?

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es denn zur Abwechslung mit einem der Aufgabe angemessenen 
Controller? Dem da z.B.:

https://www.reichelt.de/dsPIC-33-Controller/33EP64GP504-IPT/3/index.html?ACTION=3&GROUPID=4087&ARTICLE=121689&SEARCH=dsPIC33EP32GP&START=0&OFFSET=16&;

fchk

Autor: Paul W. (solarturtle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Wie wäre es denn zur Abwechslung mit einem der Aufgabe angemessenen
> Controller?

Der Master Controller soll auch was ordentliches werden, also PIC32 oder 
STM32. Da mangelt es nicht an Schnittstellen. Der fragt dann auch die 
ganze sonstige Sensorik ab und alles drumrum.

Nur bei den Motorcontrollern, welche sich nur um ihren Motor kümmern 
sollen, bin ich etwas eingeschränkt, weil ich mich da mit der TI 
Instaspin-FOC Geschichte schon eingearbeitet habe und einen 
FOC-Controller nicht unbedingt auf einem Fremdcontroller implementieren 
mag (zuviel Arbeit und zuviele Fehlerquellen).
Und bei dem kleinen TI Controller gibt es nur 1 UART, 1 SPI. Wenn ich 
größere nehme, kostet das mehr und ich habe viel mehr Pins, welche ich 
alle nicht brauche.

Daher wäre denke ich die UART Alternative im Hinblick auf Fehlerquellen 
und Kosten die beste Lösung :-)

Autor: Dieter M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vom Datenvolumen her ist das vermutlich relativ sehr klein.
z.B. ein Datenpaket enthält evtl. 20 Bytes alle 10ms = 2kByte/s, bei 
zwei Controllern entsprechend 4kByte/s. Wenn beide Motorcontroller 
antworten, sind das in diesem Beispiel 8kByte/s.

Das schafft UART ganz locker. (hab UART schon mit 3MBit/s am Atmel mit 
USB-FTDI betrieben)

Das erste Byte könnte der Addressierung des Slaves dienen.

Die Synchronisierung könnte mit einem 10ms-Triggersignal vom Master 
erfolgen.

Zur Sicherheit kannst Du natürlich noch eine einfache Checksumme an die 
Nachrichten anhängen. (z.B. alle Bytes einfach aufsummieren)

Achtung Stolperfalle!
Bei einem busartigen Aufbau müssen die Sender der Slaves abgeschaltet 
werden, wenn die gerade nichts senden. Und die TX-Leitung der Slaves 
sollte noch einen 10k Pull-up bekommen.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Microcontroller mit mehreren SPI-Devices sind aber nichts
> ungewöhnliches. Darfst halt nur nicht ausschließlich bei AVR suchen.

Warum nicht?
Z.B. ATmega2560 kann bis zu 5 SPI-Master.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.