www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Steuerungsprojekt mit bidirektionaler Kommunikation


Autor: Steffen Kleinert (fenert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe ein neues Projekt, bei dem ich eine Steuerung für ein 
Transportmodul erstellen soll. Die gleichartigen Steuerungen der Module 
sollen sich selbstständig dezentral organisieren und nur mit ihren 
nachbarn kommunizieren. Das heißt ohne ein übliches Bussystem mit 
Addressierung, da die Module auch nicht wissen sollen "wo" oder "wer" 
sie sind und somit keine Adressen zugewiesen bekommen.
Da die Module sehr klein sein werden und die Verbindungen zwischen ihnen 
kaum länger als 20cm werden sollten, überlege ich, ob ich einfach SPI 
als Basis nehmen kann. Das würde mir ermöglichen die maximal 8 
Nachbarmodule mit 8 Select-Leitungen (oder weniger) auszuwählen und die 
Daten zu übertragen.
Um eine zeitgleiche Kommunikation von mehreren Modulen im Gesamtsystem 
zu ermöglichen, ohne das diese sich gegenseitig behindern müssen die 
Kommunikationsleitungen voneinander getrennt sein. Das würde ich durch 
über die Select-Leitungen geschaltete Relais realisieren, die eine 
Übertragung auf SDO, SDI und CKL nur auf den benötigten 
Leitungsabschnitten ermöglichen.

Ist das Eurer Meinung nach möglich, oder habt ihr andere 
Ideen/Anregungen?
Wie funktioniert SPI als Multimastersystem? Kann ich beispielsweise mit 
einem ATmega16 solch ein Kommunikationssystem realisieren und wie 
verhalten sich AVRs wenn ein Konflikt (Mehrfachbelegung) auf dem SPI 
auftritt?
Kann mir jemand Sagen, ob es ICs gibt, die man als SPI/SPI-Transceiver 
(oder währe Repeater richtiger) verwenden kann, da das dem Verhalten das 
ich für die Leitungstrennung brauche am ehesten entspricht.

Danke im Voraus für die Hilfe. Ich weiß, das ich ziemlich früh mit 
meinen Fragen zu euch komme, aber ich habe etwas Zeitdruck bei dem 
Projekt und hätte mich ansonsten auch erstmal 2 weitere Wochen durch 
Datenblätter und andere Literatur gewühlt.

Steffen

Autor: Steffen Kleinert (fenert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist gerade noche eine einfache Alternative eingefallen, könnte ich 
auch SPI und I²C einsetzen? SPI als Kommunikation zwischen den 
Steuerungen und I²C Steuerungsintern.
Was haltet Ihr davon?

Steffen

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also für ein dezentrales System würde ich weder I2C noch SPI einsetzen, 
da diese nativ Master-/Slave-Systeme sind.

Mein Vorschlag wäre, die Verbindungen untereinander über eine asynchrone 
serielle Schnittstelle zu machen.
Jedes Modul hat dann 8 solcher Schnittstellen (dein vorgegebenes Maximum 
an Nachbarn), mit denen das Modul kommunizieren kann.
So wäre erst mal der Krampf mit wer ist Master/ wer Slave weg, da jedes 
Modul einfach Daten zum Nachbarn schicken kann (über Datenpuffer sehr 
gut realisierbar).

Viel Spass beim Planen ;-)

Autor: Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die gleichartigen Steuerungen der Module
>sollen sich selbstständig dezentral organisieren und nur mit ihren
>nachbarn kommunizieren.

Was sind das für "Module"? Was ist ihre Aufgabe? Sollen das Sensoren
sein?
Du mußt schon ein wenig konkreter werden.

Nur als Beispiel: Wenn die "Module" vom Master(µC) lediglich abgefragt
werden sollen, ist die ganze Sache ziemlich einfach.

Autor: Steffen Kleinert (fenert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Flo:
An RS232 haben wir auch schon gedacht, wichtig währe dabei aber eine 
Realisierung der Schnittstelle mit möglichst wenigen Leitungen. Kann man 
uCs auch nur über TxD und RxT verbinden? Das währe dann wohl eine recht 
elegente Lösung. Die Anzahl der Leitungen ist wichtig, da für zukünftige 
Versionen eine Plug&Play anbindung der Module zueinander angestrebt ist 
und je mehr Leitungen desto Fehleranfälliger.

@Werner
Die Module sind gleichberechtigte und gleichartige Teilnehmer am 
Gesammtsystem aus Modulen. Jedes Modul hat normalerweise eine Steuerung, 
Aktoren (2 Motoren) und einen Sensor. Jedes Modul kann Senden und 
Empfangen und besitzt zu seinen Nachbarn (max. 8 Module) je eine 
Bidirektionale Schnittstelle.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Module sind gleichberechtigte und gleichartige Teilnehmer am
>Gesammtsystem aus Modulen. Jedes Modul hat normalerweise eine Steuerung,
>Aktoren (2 Motoren) und einen Sensor. Jedes Modul kann Senden und
>Empfangen und besitzt zu seinen Nachbarn (max. 8 Module) je eine
>Bidirektionale Schnittstelle.

>An RS232 haben wir auch schon gedacht

Das ist bei den Anforderungen ja wohl ein Scherz?
Nimm Ethernet.

Autor: Magnetus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm Funk ;o)

duckundweg

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm seriell, geht eben auch nur mit rx und tx (und Masse natürlich).
Der physical layer wäre dann die serielle asynchrone Übertragung, darauf 
kannst du ein schönes Protokoll aufsetzen.
Btw über was solln sich die Module unterhalten?

Autor: Steffen Kleinert (fenert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Holger
Ethernet ist keine brauchbare Lösung. Die Module sollen nur mit ihren 
jeweiligen Nachbarn kommunizieren! Diese Kommunikation läuft nicht über 
einen Globalen Bus/Netzwerk sondern über Bidirektionale Leitungen und 
sie sollen auch kein eine eigene Identität/Adresse haben, was für so 
ziemlich jeden Bus eine zwingende Voraussetzung ist.
Das alles habe ich oben beschrieben.

Autor: Steffen Kleinert (fenert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Btw über was solln sich die Module unterhalten?
@Flo
Wie oben angedeutet handelt es sich um Transportmodule, diese können 
Objekte (Pakete und so ein Zeug) in jede belibige Richtung bewegen. 
Dabei sollen die einzelnen Module selbständig entscheiden wolang sie ein 
Paket am besten befördern und wie sie das Ziel am 
schnellsten/effektivsten erreichen. Trotzdem sollen die Module 
vollkommen austauschbar und das Gesamtsystem jederzeit umstrukturierbar 
sein. Natürlich sollen dabei immer nur die Module aktiv sein, die gerade 
ein Objekt transportieren und bei einer beliebigen Ausdehnung des 
Systems auch beliebig viele Objekte zeitgleich bewegt werden.

Naja, also werden die wohl übers Wetter reden... oder auch über 
Transportobjekte, deren Position, Größe, Geschwindigkeit, etc und Ziel.

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde in dem Fall auf CAN setzen

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steffen Kleinert schrieb:
> @Flo:
> An RS232 haben wir auch schon gedacht, wichtig währe dabei aber eine
> Realisierung der Schnittstelle mit möglichst wenigen Leitungen. Kann man
> uCs auch nur über TxD und RxT verbinden?

3 Leitungen brauchst du mindestens.  RxD, TxD und Masse

Problem ist eher die Realisierung von 8 UARTS auf einem Modul.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum nicht gleich CAN, wie "Schrotty" schon erwähnt hat.
Das CAN Modul des Controllers übernimmt dabei automatisch die Dinge, wie
Kollisionsauflösung, Filterung, CRC, etc. der "Nachrichten".
Kann einem ne Menge Arbeit abnehmen!

Keine Adressierung nötig. Nur die "Nachrichten" benötigen eine 
eindeutige ID.
(Sind glaub bis zu 24-Bit - Also viel Spielraum ;-))

Wenn Du AVR's mit CAN nimmst, dann kannst Du mit den MOBs (Message 
Objects)
die Aufgabe recht elegant lösen. Es stehen 15 solche Objekte zur 
Verfügung.
Je nachdem was man benötigt, kann man die beliebig zu RX oder TX 
Objekten konfigurieren.

Allerdings empfehle ich für den Einstieg einen preiswerten 
CAN-PC-Adapter, damit man das auch Debuggen kann. Ein relativ nettes 
Teil wäre z.B. von
IXXAT der USB-CAN Adapter. Die API für Visual C++ ist auch nicht so 
schwer,
so dass man sich relativ einfach ein Diagnose-Tool schreiben kann. Das 
mitgelieferte ist zwar in der Lage die Nachrichten anzuzeigen, aber
man möchte das ja auch im "Klartext" haben ;-)


Randbemerkung:
Ich hab hier auch mal ein paar Baugruppen per RS232 bzw. TTL-UART 
verbinden
müssen. Hätten wir das mit CAN gemacht, dann wäre das wesentlich 
einfacher
geworden. Aber die Komplexität hängt von der Anwendung ab!

Autor: Zipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kloppt den CAN Muell in die Tonne. Da ist die Messagelaenge auf 6 byte 
begrenzt. Normales UART ist flexibler.

Autor: Loonix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde da auch über ein CAN nachdenken, die Vorteile liegen auf der 
Hand.

@Matthias
>(Sind glaub bis zu 24-Bit - Also viel Spielraum ;-))

Bei CAN 2.0B sind es sogar 29 Bit.

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau Zipp, CAN ist definitiv Müll!
-- Ironie an --
Darum wird er auch gern in KFZ verwendet und erfreut sich auch in der 
Automatisierungstechnik einer gewissen Beliebtheit.
Schonmal was davon gehört, dass man längere Nachrichten splitten kann?
Macht dein Rechner, an dem du gerade sitzt und im Netz surfst, übrigens 
auch, denn Ethernet ist genau der gleiche Müll, das kann nämlich nur 
1500 Byte pro MAC-Frame. Also schlichtweg unmöglich, damit deine 
Urlaubsbilder zu übertragen. Ich würd da auch auf nen flexiblen UART 
setzen.
-- Ironie aus --

Autor: Loonix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Zipp
>Da ist die Messagelaenge auf 6 byte begrenzt. Normales UART ist flexibler.

Tut mir leid, aber das ist falsch. Erstens kann ein Frame bis zu 8 Byte 
Nutzdaten enthalten, zweitens steht dir noch Platz im Identifier zur 
Verfügung.

Der Vergleich mit UART hinkt insofern, dass für jedes Byte der 
"Protokoll-Overhead" in Form von Start/Stop-Bit benötigt wird. Analog 
dazu kannst du auch bei CAN beliebig viele Frames aneinander reihen.

Autor: Loonix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Steffen Kleinert
>Danke im Voraus für die Hilfe. Ich weiß, das ich ziemlich früh mit
>meinen Fragen zu euch komme, aber ich habe etwas Zeitdruck bei dem
>Projekt und hätte mich ansonsten auch erstmal 2 weitere Wochen durch
>Datenblätter und andere Literatur gewühlt.

Wenn in dem Stadium schon Zeitdruck herrscht, ist die Aufgabe vielleicht 
zu groß für einen Einzelnen. Ich könnte dir evtl. einen Entwickler zur 
Mitarbeit empfehlen. Interesse?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du bist noch längst nicht soweit, jetzt schon das Übertragungsmedium 
festzulegen, das kommt mindestens 10 Projektetappen später.

Du mußt erstmal festlegen, wie die Kommunikation organisiert werden soll 
und ob überhaupt was sinnvolles dabei herauskommt.
Und dann mußt Du noch die Datenrate und die Echtzeitanfordungen 
festlegen.

Und irgendwann viel viel später kann man sich dann das passende 
Übertragungsmedium aussuchen.


Stell Dir ein virtuelles Medium vor.
Ein Modul stellt eine Anzahl X von Bytes in diese Medium, was soll dann 
mit diesen Bytes passieren?
Ohne Adressierung werden die Bytes dann wohl ewig im Medium 
umherkreisen.

Warscheinlich wirst Du Mann-Jahrhunderte Entwicklungszeit benötigen.


Peter

Autor: Steffen Kleinert (fenert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema CAN:
Ich habe bereits eine sehr umfangreiche Steuerung für ein 
Vorgängerprojekt mit einem AT90CAN128 realisiert, das auch sehr gut 
funktioniert hat. Ein Hauptaugenmerk liegt bei dieser Arbeit jedoch bei 
der Umsetzung eines Kommunikationssystems das ideal ist für das 
Dezentralisierungskonzept. CAN stellt für die üblichen dezentralisierten 
Systeme eine sehr gute Basis da, allerdings ermöglicht CAN ebenso wie 
alle anderen BU-Systeme keine Zeitgleiche Kommunikation mehrerer 
Teilnehmer untereinander.
Ein kleines Beispiel zur Veranschaulichung:
Man Stelle sich einen großen Saal voller Menschen vor. Jemand tritt ans 
Podium und hält eine Rede, angenommen jeder im Saal würde still zuhöhren 
dann hätten wir ein klassischen Kommunikationssystem, mit einem Master 
bzw. Sender. Wenn es jetzt zu einer Podiumsdiskussion kommt haben wir 
den Fall das jeder im Saal sich zu Wort melden kann und ihm alle 
zuhören. Das währe eine Situtation wie in einem Multimastersystem (bsp. 
CAN). Realistischer aber ist das sich alle Personen im Saal 
untereinander mit ihren Nachbarn unterhalten und sich nicht durch die 
Unterhaltungen der anderen Anwesenden gestört fühlen. Das spiegelt die 
Art von System wieder die für die Arbeit angestrebt ist.
Ich hoffe das macht es etwas verständlicher.

Um ein derartiges System zu erzeugen, muss eine "physikalische" Trennung 
zwischen an der Komunikation beteiligten und passiven/freien Modulen 
möglch sein, da anderenfalls die Informationen die nur an ein 
benachbartes Modul gerichtet sind den gesammten Bus blockieren.

Ich habe da schon Ideen, die auch noch vorstellen werde, wenn ich sie 
für ausgereift genug halte.

@Loonix
Danke für das Angebot, aber das ist für eine Projektarbeit nicht 
unbedingt zweckmäßig und wenn ich Gas gebe wird das schon was werden.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Autor:  Steffen Kleinert (fenert)

Das klingt nach DSSS

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das heisst, dass du maximal 8 Module im System hast, wovon jedes nur mit 
seinem unmittelbaren Nachbarn kommuniziert. Sprich: Die Module sind 
quasi in "Reihe" geschaltet und jedes "sieht" nur seinen Vorgänger und 
Nachfolger?

Autor: Steffen Kleinert (fenert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schrotty schrieb:
> Das heisst, dass du maximal 8 Module im System hast, wovon jedes nur mit
> seinem unmittelbaren Nachbarn kommuniziert. Sprich: Die Module sind
> quasi in "Reihe" geschaltet und jedes "sieht" nur seinen Vorgänger und
> Nachfolger?

Nicht ganz, das System kann prinzipiell aus unbestimmt / unendlich 
vielen Modulen bestehen. Diese werden schachbrettartig angeordnet, so 
das jedes Modul 4 (Von-Neumann-Nachbarschaft) oder 8 
(Moore-Nachbarschaft) benachbarte Module hat (bzw. auch weniger, wenn 
Module fehlen).

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steffen Kleinert schrieb:

> Nicht ganz, das System kann prinzipiell aus unbestimmt / unendlich
> vielen Modulen bestehen. Diese werden schachbrettartig angeordnet, so
> das jedes Modul 4 (Von-Neumann-Nachbarschaft) oder 8
> (Moore-Nachbarschaft) benachbarte Module hat (bzw. auch weniger, wenn
> Module fehlen).

Also im Grunde so, wie das die Transputer vor Jahren gemacht haben.
Wenns die noch gibt, wäre das sogar eine Überlegung wert. Die haben die 
Kommunikationshardware schon eingebaut. Frag mich aber nicht, was sowas 
heute kostet :-)

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist einfach, mit welcher Performance du die Daten übertragen 
musst.
Logisch kannst du natürlich lauter Peer-To-Peer Verbindungen aufbauen, 
die aber Physikalisch auf einem genmeinsamen Kanal laufen.

Um´s mit deinem Raum zu vergleichen:
Alle wollen sich unterhalten , aber die Menge der auszutauschenden 
Informationen ist so gering, dass es ausreichend ist, wenn immer nur 
einer im Raum redet und die anderen schweigen. Somit hat am Ende des 
Abends auch jeder alles gesagt, was er loswerden wollte ;-)

Autor: Loonix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Steffen Kleinert
>Danke für das Angebot, aber das ist für eine Projektarbeit nicht
>unbedingt zweckmäßig und wenn ich Gas gebe wird das schon was werden.

Ok, ich hatte das Projekt als kommerzielles Ansinnen aufgefasst. In dem 
Fall ist das natürlich nicht zweckmäßig, klar.

Viel Erfolg bei diesem interessanten Projekt!
(ich freue mich, wenn ich hier dazu was lesen kann)

Autor: Loonix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Schrotty
>Um´s mit deinem Raum zu vergleichen:

Finde ich gut dargestellt. Es wäre also interessant zu wissen, wie lange 
der "Abend" dauert und ob jeder Teilnehmer in dieser Zeit zu Wort kommen 
kann.

Autor: Zipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie verbindet man jeden controller mit seinen 8 Nachbarn? Alle auf einen 
Bus geht ja so nicht, denn dann wuerden sich die Busse teilweise 
ueberlappen. Es gibt controller, die haben 4 UART, die eher teuren. Aber 
8 ?

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Software-UART ?
Mit niedrigen Baudraten lässt sich das sehr leicht machen.
Jeweils ein Port (8 Pins) als Rx festlegen und ein Port als Tx, die 
lassen sich dann bis auf die verschiedenen Puffer exakt gleich 
behandeln.

Autor: Steffen Kleinert (fenert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke daran die Verbindungen mit Tri-state buffern zu blockieren 
wenn eine Verbindung nicht erlaubt ist. Somit währen die Anschlüsse 
quasi Sackgassen und nur auf einem Weg ist ein Partner zu erreichen. 
Diesen Weg bzw. Kommunikationspartner könnte man mit einem 
"Cabel-Select" auswählen und über die selbe Leitung quasi als 
"Handshake" eine gleichartige Reaktion beim Empfänger erzwingen. Dadurch 
währen nur die Module tatsächlich verbunden, welche gerade kommunizieren 
und alle anderen, auch die unmittelbaren Nachbarn würden nicht 
beeinflusst.

Zum Thema Datenmenge und Datenrate:
Das alles ist derzeit recht schwer einzuschätzen, da die endgültige 
Datenmenge, die zukünftig angestrebt ist nicht nur für mich Neuland ist. 
Sie sollte aber so gering wie möglich bleiben einige Byte sollten 
eigentlich reichen.
Die Datenrate dagegen wird umso höher sein. Im einfachsten Fall haben 
wir 2 Nachrichten pro Auftrag / Zyklus. Da die Module sehr klein werden 
sollen (Kantenlänge <10cm) sind immer mehrere Module aktiv und senden 
gleichzeitig Nachrichten. Zudem soll die Geschwindigkeit mit der 
gearbeitet werden soll möglichst groß sein und so komme ich auf etwa 
1000 bis 2000 Nachrichten/sec je Objekt auf dem Gesamtsystem wobei das 
Gesamtsystem im idealfall unbegrenzt ist und schnell mehrere tausend 
Module haben könnte. Und je größer das Gesamtsystem desto mehr Objekte 
werden zeitgleich transportiert.
Eine Lösung mit mehreren Subnetzen währe sicherlich möglich, aber Ziel 
der Arbeit ist es auch herauszufinden ob nicht mehr möglich ist. Zudem 
ist ein System das bidirektionale Kommunikation verwendet genauso 
zuverlässig mit 10 Modulen und einem Objekt wie mit 1 Million Modulen 
und 100 Objekten.

Oder um es mit meinem Beispiel zu veranschaulichen:
Es ist eher ein Singelabend mit Masssenblinddate wo jeder nur kurz Zeit 
hat sich seinem Gegenüber anzupreisen bevor man schnell zum nächsten 
Tisch muss (habe keine Erfahrung damit, aber so stelle ich´s mir vor).

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde auf rs232 bei den Standartprotokollen gehen, immer Empfänger 
optoisoliert. Half Duplex auf zwei Leitungen, Break = Busy und wenn was 
nicht
passt, innerhalbs des Stop-Bits die TX auf high ziehen oder schon 
vorher,
wenn man Rechenzeit braucht und die übertragung wiederholt werden soll.

TX-> High= Wait / busy, muss aber gleich oder länger als 10bit sein.
TX-> low = warten auf Datenübertragung.

Autor: Steffen Kleinert (fenert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach ausgibiger recherche und diversen Überlegungen die Verbindungen mit 
tristat buffern, Relais u. a. zu sperren habe ich bei meiner Recherche 
festgestellt, dass es von Atmel eine Controller gibt, der 4 
USART-Schnittstellen bereitstellt. Der ATmega2560 scheint daher wie für 
mich gemacht, alle benachbarten Module können sich ungestört unterhalten 
es könnten sogar alle Nachbarmodule gleichzeitig mit dem selben Modul 
"quatschen" oder umgekehrt. 4 eigenständige RS232-SChnittstellen machen 
es möglich.
Der einzige Nachteil ist, dass der 2560 im TQFP-100 Format vorliegt und 
ich schon einmal einen TQPF-64 mit Hand gelötet habe und nicht erpicht 
bin das noch zu steigern, zumal ich mehrere Boards löten muss. Aber zum 
Glück gibt es das hier: 
http://www.chip45.com/AVR-ATmega-Mikrocontroller-M...

Damit kann ich glaube ich alles machen was ich brauche und habe 
eigentlich viel zuviel spiel nach oben. aber für eine prototypische 
Testanlage sollte das akzeptabel sein.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TQFP 100 ist nicht schwierig zu loeten. Niemand loetet da jeden Pin 
einzeln. Fluxgel drauf, und mit dem zinnbenetzten Kolben drueberziehen. 
So'n Ding ist in weniger als 1 Minute geloetet.

Autor: Uwe Castagne (Firma: privat) (olmuk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ohne die vielen Anregungen zu unterbrechen, möchte ich einen neuen 
Ansatz
vorstellen :
Wenn ich das richtig verstehe, stehen von jedem Modul eine oder mehrere
Entscheidungen (von Fahrwegen?) an.
Warum versiehst Du Deine Moduel nicht mit einem Transponder mit einer 
eindeutigen Nummer und liest vor einer Entscheidung den Transponder.
Der übergeordnete PC mit Steuerung "endscheidet" wo das Modul hin soll.
Die Verwaltung der Modulinhlate ist dann wohl auch einfacher.

Datenbanksystem, Aufragsverwaltung, I/O und habe fertig.

Gruß Uwe

Autor: Steffen Kleinert (fenert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Uwe:
Das ist genau das was wir nicht wollen. Es soll keine übergeordete 
Steuerung geben, welche das System kontrolliert. Lediglich eine 
Datenbank, aus welcher die Informationen über das zu transportierende 
Objekt beim ersten Kontakt mit dem Modulsystem geladen und dann zusammen 
mit dem Objekt von Modul zu Modul bewegt werden. Zudem soll das Modul 
keine eindeutige Bezeichnung haben, damit Module jederzeit gewechselt, 
entfernt oder hinzugefügt werden können, ohne irgendwelche Einstellungen 
vornehmen zu müssen.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Module müssen !!! eine eindeutige Bezeichnung haben, schon deshalb, weil 
z.B ein FW-Upgrade oder ein Defekt vorliegt, und du dann wissen willst, 
welches Modul das ist, eindeutig. Auch zur Addressierung kann diese 
eindeutige Nummer gewählt werden, z.B. wenn du einen gemeinsamen Bus 
zusätzlich hast,
z.B. RS232 mit 2400 Baud, um an Module ranzukommen, nenn ihn Servicebus,
bzw um unterschiedliche Timeouts bei einem Bussystem zu haben, und so
die Systeme zu koordinieren, bzw. automatisch Adressvergabe usw,
wo das dann sehr wenig bis nichts mit dem zu tun hat, daß das modul
wenn es fehlt problemlos ersetzt werden kann. Z.B. ein Ethernetadapter,
wenn er defekt ist, ersett man ihn, der hat auch eine eindeutige 
Adresse,
aber mit DHCP z.B. sowie Routingprotokollen ist der komplett 
austauschbar.
Andererseits, ohne eindeutige Adresse würde dies niemals funktionieren.
So ist es vielfach bei uC.

Autor: Steffen Kleinert (fenert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht habe ich es etwas falsch ausgedrückt. Natürlich müssen die 
Module über einen Servicebus bsp. Ethernet ansprechbar sein Dieser Bus 
darf aber nicht zur Kommunikation der Module untereinander verwendet 
werden (siehe diverse Beiträge zuvor). Die Bezeichnung der Module währe 
damit dynamisch und nicht beim Einbau festgelegt, bzw. fest an die 
Position innerhalb des Gesammtsystems gebunden. Bei "eindeutige 
Bezeichnung" hatte ich an eine Kennung gedacht, wie ich sie bei einem 
anderen Projekt verwendet hatte, wobei sich die Kennung auf die Position 
des Moduls bezogen hatte (in X/Y-Koordinaten) diese Kennung wurde dann 
auch als Busadresse verwendet.

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schlagt mich, aber ich verstehe die schnelle Ablehnung von Ethernet 
nicht. Im Prinzip ist das naemlich genau das, was hier die ganze Zeit 
beschrieben wird.

Erstens kann eine Ethernetverbindung auch eine Point-To-Point-Verbindung 
(also zwische genau 2 Modulen) sein und zweitens laeuft das Ethernet, 
wie wir es tagtaeglich benutzen, mitnichten ueber einen Bus:

Wenn Module A, B, C und D an einem Switch haengen, dann kann A mit B 
kommunizieren ohne die Unterhaltung von C und D zu stoeren. Eine 
Adressierung ist nur notwendig, damit der Switch das machen kann, was 
hier als "Cable Select" beschrieben wird.

Aber man kann natuerlich auch das Rad neu erfinden wollen...


Volker

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ethernet zieht rabiat Strom, da sollte man schon die Datenrate brauchen.

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verschneiter Tag schrieb:
> Ethernet zieht rabiat Strom, da sollte man schon die Datenrate brauchen.

0.5W waeren fuer mich kein Ausschlusskriterium... und auch nicht rabiat. 
Das darf selbst nach neusten Richtlinien ein Geraet schon im Stand-By 
verheizen. ;)


Volker

Autor: Schrotty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Volker:
Ethernet wäre hier die sprichwörtliche Kanone, mit der man die Spatzen 
vom Dach schießt.
Aber es wäre insofern elegant, dass jedes der Module einen 5-Port-witch 
dartstellen würde. Ein Port für das Modul an sich mit eigener 
MAC-Adresse und die anderen vier Ports für die Nachbarmodule.
Man könnte sogar von jedem Punkt aus im Netz theoretisch jedes Modul 
ansprechen, falls es mal notwendig sein sollte.

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.