mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik I2C oder SPI, eure Meinungen


Autor: Gerhard Humer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

für ein weiteres meiner Projekte (CNC Anwendung) möchte ich eure
Meinungen bzw. Erfahrungen heranziehen.
Bei diesem Projekt sollen bis zu 6 Atmel's miteinander kommunizieren

Ein Mega8 erhält die Daten über RS232 vom PC, dieser soll auch als
Master für das Bussystem zw. den Atmels arbeiten.
Je nach Anzahl der CNC-Achsen kommen dann noch 3 bis 5 At90s2313er
oder auch mega8 als Slave's zum Einsatz. Diese übernehmen die
Interpolations-Aufgabe und Ausgabe an die Endstufen.

Meine Frage: Welches der beiden Bussysteme I2C oder SPI
würdet ihr hier verwenden.
Vielen Dank für eure Beiträge im Voraus.

Gruss Gerhard

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gab es etwas:
http://www.mikrocontroller.net/forum/read-1-81113.html#81113

IIC geht gut, wenn die Leitungen kurz sind.
Ich würde als Kopplung zum PC einen Mega64/128 oder 162 nehmen, der
zwei UARTs hat und alle anderen µP am 2. UART mit
Multiprozessorprotokol betreiben. Hier hat man meines Erachtens den
größten Spielraum bzgl. langer Leitungen, unterschiedlicher µPs und
Fehlersuche. (Bei Gelegenheit werde ich das noch halbduplex mit
CAN-Bustreibern antesten.)

SPI habe ich noch nie gebraucht - außer, um ext. SR anzusteuern. Zwar
kann man die Byteübertragung sehr schnell machen, riskiert aber, daß
der Empfänger 'überrannt' wird. Zudem finde ich es lästig, ein Byte
zu senden, um ein Byte zu lesen.

Autor: Gerhard Humer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

Danke für deine rasche Antwort.
Die AVR's sitzen alle auf einer Platine. Leitungslänge
wird max. 5 cm sein. Im Vordergrund wird die Geschwindigkeit stehen.
Mega 64/128 ist bestimmt eine Möglichkeit jedoch um einiges teurer
als ein mega8.
Ups, hab ich im vorigen Beitrag vergessen, es wird noch ein mega8
als Slave im Bus hängen der die Taktrate, Beschleunigung und Brems-
werte berechnet und an die INT0 der anderen AVR's weitergibt.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gerhard,

dann wird Deine Wahl wohl auf IIC fallen.

Wenn Du stärkere Motoren verwendest, solltest Du auf jeden Fall die
Sicherheit des Bedieners/Systems beachten.
Zu empfehlen ist ein Timeout für IIC, damit der Bus nicht hängenbleiben
kann. Das könnte passieren, wenn der lesende IIC-Master nicht alle Bits
vom Slave abholt (z.B. durch watchdog reset) und der Slave endlos auf
den Abschluß der Übertragung wartet. (Der neuere LIN-Bus hat dies im
Protokoll berücksichtigt.)
Hilfreich kann es sein, daß die Haupt-CPU mit einem Portpin alles
Sub-CPUs über /RESET neu starten kann; wenn INT1 nicht anders verwendet
wird, könnten die INT1s alles µPs verbunden werden, um z.B. Aktionen zu
synchronisieren. Ein einfacher Portpin ohne INT-Fähigkeit könnte auch
genommen werden.

Dies nur als Anmerkungen.

Autor: Martin Götzenberger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OT

Hallo Gerhard!

Über so einen Ansatz für eine Fräsmaschinensteuerung habe ich auch
schon mal nachgedacht. Daher ein paar Fragen, die hier nicht wirklich
hingehören, vielleicht passen sie auch gar nicht zu deinem Projekt:

Welche Antriebe verwendest du?

Bei Schrittmotoren: welche max. Frequenz?

Machen die 'kleinen' nur einfache Pulsausgabe, oder interpolieren die
auch noch? wenn ja: wie?

Ist die Ansteuerung mit linearen Frequenzrampen oder ruckbegrenzt?

zum PC-Programm:

Fertig gekauft/Share/Freeware/eigen?

Nach DIN/ISO, oder irgend welchen anderen Standards?

Fräserradiuskorrektur?

Bin schon 'ne zeitlang auf der Suche, hab' aber noch keinen sicheren
Treffer.

servus,
Martin

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine komplette PC-Lösung ist ja EMC, siehe http://www.linuxwiki.de/EMC.


Es bräuchte nur nochmal jemanden, der eine kostengünstige Einsteckkarte
designt, wo Encoder und Motorendstufen angeschlossen werden können.

Winfried

Autor: JürgenF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Winfried,
schau Dir das mal an.

http://5128.rapidforum.com/topic=112282918267

Mit besten Grüßen
Jürgen

Autor: Axel Stab (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gerahrd,

sechs AVRs auf einer Platine klingt etwas merkwürdig und falls Kosten
relevant sind, auch nicht unbedingt wirtschaftlich. Ich würde SPI
bevorzugen, wegen der besseren Synchronität. Du kannst alle in eine
Daisychain packen und mit 1Mbaud Daten für alle Slaves durchblasen.
Evtl. kannst Du sie auch parallel hängen. Durch ein Select oder
Strobe-Signal hast Du alle 100% synchron. Wenn man noch synchrone I/Os
braucht, kann man das einfach mit Schieberegistern machen.

Aber schau Dir auch mal den TMC428 und TMC236 von trinamic.com an. Der
428 erzeugt Mikroschritte, Rampen usw. für drei Achsen, der 236 ist ein
28V/1,5A Treiber, u.a. mit SPI-Eingang. Kannst Du rein zufällig über
mich beziehen. Soll aber keine Schleichwerbung sein. Wettbewerber sind
z.B. Allegro A3972 (auch SPI, billiger, aber mehr Verlustwärme) oder
auch ST (allerdings meist schlechteres Microstepping). Kannste auch
kaufen, eigentlich vertreibe ich ja fertige Module und Baugruppen,
übrigens auch an Fräsenbauer. Arbeite gerade an einem G-Code Interface,
HPGL habe ich schonmal gemacht.

In der Anlage noch eine evtl. Interessante Hardware-Alternative: ein
kleines Board mit einem kleinen ARM7 von Philips (60MIPS, 32bit) plus
USB-Interface. Der kann sehr viel besser interpolieren als der AVR und
z.B. SPI-Motortreiber dann direkt ansteuern. Da bastele ich auch gerade
an einem Prototypen für 2 Achsen. I/Os kann man noch ohne Ende per CAN
oder SPI dranhängen. Hat übrigens auch I2C.

Axel

Autor: Gerhard Humer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

danke Michael für deine Input's.
Werde mal erste Test's mit IIC versuchen und mal den Datenfluss
begutachten.

@Martin , wie schon von Jürgen geschrieben, dort
findest du die Servoendstufen, sind von mir.
Die "kleinen" sollen auch die Interpolation der Achsen machen ,
also Arbeitsteilung.
Rampen sind da wohl ein MUSS, ich möchte auf ca. 100 kHz Taktrate
kommen.
PC Prog , eigen.
Sprache Din/ISO und ev. HH-Code.
Fräserradiuskorr. , nein.

"Bin schon 'ne zeitlang auf der Suche, hab' aber noch keinen
sicheren
Treffer."
Ich auch, aber auch ohne Erfolg.

@Winfried
EMC läuft doch nur unter Linux , oder ?

Gruss Gerhard

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe da auch nicht den Sinn des Vernetzens.

Erstmal wird alles viel komplizierter, da ein sicherer, verlustfreier
und echtzeitiger Datentransport benötigt wird.

I2C oder SPI kannste beim 90S2313 vergessen, sowas hat der nicht.
Bleibt also nur die UART.

Und der LPC2106 hat ja schon 6 PWM-Ausgänge und 2
Interruptprioritäten.
Lade Dir einfach mal die Keil Testversion runter.


Peter

Autor: Martin Götzenberger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OT

@Gerhard

Servoendstufen... alle Achtung,
100kHz ist auch nicht ohne, aber wenn ich mir die Servoendstufen
anschaue, ist das für dich sicher kein Problem.

Werde mir demnächst mal Mach2 ansehen. Da sind ein paar ganz pfiffige
Ideen 'drin. Fräserradiuskorrektur ist für mich eigentlich ein muß
(hab' auch schon an 'ne echte TNCxx gedacht, eine die halt noch
Analogsollwerte ausgibt. Sind aber schwer aufzutreiben, wenn man nicht
zu viel Geld ausgeben will)

servus,
Martin

Autor: Gerhard Humer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi ,

wenns ohne Bus geht , also alles von einem AVR machen lassen, das wäre
natürlich einfacher, klar.
Werd da mal ein paar Tests machen.
Für 2-Achs- Interpolation z.B. Kreisfräsen sicher kein Problem
aber bei Fünfachs-Interpolation mit vernünftiger Geschwindigkeit
wird ein einziger AVR sicher überfordert werden.
Deshalb mein Gedanke die Kommunikation zum PC getrennt von den
Interpolationsberechnungen zu erledigen , natürlich syncronisiert,
klar.
Mit PWM kann ich hier nichts anfangen, brauch an den Ausgängen
2 Signale für Takt und Richtung pro Achse.

Gruss Gerhard

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gerhard: EMC - ja hauptsächlich Linux. Es soll wohl auch unter W2K
laufen. Oder sagen wir es so: Es soll man jemand dran gebastelt haben
und  den Code dafür auch angepasst haben. Aber ich hab dafür noch keine
fertigen Pakete gesehen. Das wird wohl dann eher in wochenlangem Basteln
enden.

Winfried

Autor: Gerhard Humer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

@Winfried,
Hab ein komplettes Steuerprogr. für Windoof geschrieben was wie fast
alle anderen über die parallele Schnittstelle die daten ausgibt.
Läuft zu 99% absolut super, aber eben dieses eine Prozent krieg ich
unter Windoof nicht in den Griff, weil's eben nicht
Echtzeitfähig ist. Deswegen meine Überlegungen diesen Teil von ein
paar AVR's machen zu lassen welche die Daten über die RS232 bekommen.

Gruss Gerhard

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für meine Überlegungen war ich von ATmega8 mit IIC als Sub-CPUs
ausgegangen. Korrektur: SMBus ist die Weiterentwicklung von IIC
(LIN-Bus ist Quatsch).

Mit einem ATmega64-16 betreibe zwei Stepper mit max. 10kHz, wobei jeder
Schritt per Interrupt getriggert wird. Im Interrupt werden auch die
Beschleunigungsrampen erzeugt. Vielleicht kann man das noch etwas
beschleunigen, aber ich behaupte: 100kHz mit AVR ist zuviel verlangt.
Es sollen ja nicht nur Schritte erzeugt werden.

Autor: Gerhard Humer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Michael,

genau deswegen meine Überlegungen die Arbeit auf mehrere aufzuteilen
und die aufwendigen Sachen wie Kreisinterpolation vom PC erledigen zu
lassen
Über die Rs232 kommen dann "nur" mehr die Werte die die einzelnen
Achsen zu fahren haben die M-Befehle und Vorschubwerte.

Gruss Gerhard

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gerhard: Das ist wirklich nicht einfach, Windows echtzeitfähig zu
bekommen. W98/ME sollte man sowieso vergessen. Aber ab W2K geht es
definitiv. Und man bekommt sogar ganz erstaunlich gute
Ausgabefrequenzen hin. Bis 25KHz Takt soll wohl kein Problem sein,
manche sollen es sogar schon bis 40KHz hinbekommen haben. Wir hatten
mal das Programm von trimeta da, das konnte glaube ich bis 25KHz.
(www.trimeta.de)

Man könnte mal in diversen Newsgroups googeln, ob man findet, wie man
da vorgehen muss. Eine Frage des Trimeta Entwicklers findet man z.B.
hier:
http://groups.google.de/groups?q=friedemann+st%C3%...

Andererseits kämpfen viele mit dem Engpass, den eine parallele
Schnittstelle mit dem Takt-Richtungs-Signal so mit sich bringt. Auch
wenn du gut bist und 40 KHz hinbekommst, ist das für eine
Microschrittendstufe mit z.B. 25 Microschritten zu wenig. Gleiche
Probleme hat man, wenn man Servos mit hochauflösenden Encodern über
eine Geckodrive (http://www.geckodrive.com) Endstufe o.ä. betreibt.

Von daher finde ich es schon einen guten Weg, die Bahnberechnung in
eine Extra Hardware zu verbannen und über serielle Schnittstelle oder
USB zu gehen, um dann z.B. nur den G-Code zu übergeben, was ja nicht
mehr zeitkritisch ist.

Das, was du vor hast, hat übrigens jemand schon fertig:
http://www.benezan.de/Beamicon-TPI.html


Winfried

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.