Hallo Welt & liebe Forengemeinde! Ich suche im Augenblick nach einer Möglichkeit größere Datenmengen (100 - 200 kb/s pro Slave) von mehreren Slave-Modulen an einen Master zu senden. Im Idealfall sollten dabei folgenden Bedingungen erfüllt sein: - die Kommunikation wird vom Slave Modul eingeleitet (während des Betriebs kommt es auf den Slave Modulen zu einigen "Wartezeiten" die ich gerne für die Kommunikation nutzen würde um jeweils kleine Pakete (2-4 Byte) zu versenden) - die Kommunikation findet einseitig statt (vom Slave zum Master) Empfangsbestätigungen oder Fehlermeldungen werden nicht benötigt, zum einen um den Slave nicht zu belasten zum anderen da es sich um Echtzeitdaten handelt die im nächsten Zyklus bereits erneuert wurden. - ein Master muss mehrere Slaves betreuen können (im Augenblick 6 später falls möglich auch mehr) Mir ginge es jetzt vor allem um die Frage ob denn schon etwas existiert das diese Anforderungen erfüllt? Vielen Dank schon im Voraus für die Hilfe! Tom
1. Komplettes TDMA möglich. 2. 10 MBit/s (20) 3. Mehre Knoten möglich. Auf jedem fall darf es größer als 6 sein.
Hallo Tom, da gibt es diverse Ansätze. Ich fürchte um Dir helfen zu können brauchen wir etwas mehr Informationen. - Ich gehe davon aus, das Du Kabel verlegen kannst willst!? - Über welche Längen reden wir? - Darf es ein Stern oder ein Bus oder ein Ring sein? Protokolle kann man dan daraus entscheiden Grüße Frank
Hallo Jerry und Frank, vielen Dank schon mal für die Antworten! Das Ganze findet auf relativ kleinem Raum statt, maximale Distanz zwischen Slave und Master wäre schätzungsweise < 1,5 m, eher noch deutlich weniger. Topologie ist völlig frei, ich bin für alle Vorschläge offen!
Hallo Tom, ok Du machst es also nicht wirklich einfacher ;-) Da ich nicht sicher bin wie deine Slaves und dein Master aufgebaut sind und daher nicht sagen kann welche Schnittstellen diese zur Verfügung haben vermute ich das DU nur eine einfache Serielle hast. in diesem Fall täte ich einen Stern vorschlagen und die 2 - 4 Bytes beim Master pro Slave in einem Schieberegister ablegen. Technisch relativ einfach und Du brauchst kein großes Protokoll um Kollisionen zu vermeiden.. Der Nachteil dieser Variante ist das Du für jeden weiteren Slave den Registersatz einfügen musst. Dazu kommt das Du dich festlegst wieviele Daten ein Slave verschicken darf (muß) damit dein Master nicht durcheinander kommt. Sobald Du es variabler brauchst werden Protokolle und damit overhead benötigt. Grüße Frank
Hallo Frank! Sorry, war wirklich nicht meine Absicht es dir schwerer als nötig zu machen ;-) Genau, im Idealfall würde ich einfach einen digitalen Ausgang des Slave uC mit einem Eingang am Master verbinden und dann die Daten rüber schaufeln. Dass es ganz so einfach nicht wird hatte ich schon erwartet, wobei dein Ansatz mit den Schieberegistern sehr interessant klingt! Wenn ich dich richtig verstehe dienen die Schieberegister als eine Art Warteschlange bis der Master den entsprechenden Slave-Kanal ausliest, korrekt? Vielen Dank & noch einen schönen sonnigen Tag! Tom
Jep genau das ist die Idee. Da gibt es jetzt natürlich 1391 verschiedene Ideen wie man das bauen kann. Ich denk mir mal was einfaches zum probieren aus. Das kann man dann zur Professionellen Nutzung immer noch optimieren ;-) bis später mal Frank
Das ist, denke ich, ein typischer Fall für den I2C. Bei Atmel heißt der SPI. Ich nehme RS485, aber nur weil ich sehr lange Leitungen und große Störungen habe.
Hallo Hermann, war auch meine 1. Idee. Aber dann ist mir klar geworden, das bei Tom Anwendung Master und Slaves vertauscht sind. Dazu das Problem das der Empfänger (Tom's Master) die Daten von mehreren Sendern quasi parallel abnehmen muss. Deswegen meine Idee mit den Schieberegistern als Puffer. Leider gibt es die link Bausteine aus den alten Transputerzeiten nicht mehr. Da war das alles ganz einfach ;-) Wenn Du einen Lösungsansatz mit I2C hast würde mich der interessieren.
Hermann schrieb: > Das ist, denke ich, ein typischer Fall für den I2C. > Bei Atmel heißt der SPI. Oh nein: der I²C heißt bei Atmel TWI, weil der Name I²C Geld an Philips kostet. SPI kommt von Motorola und ist ganz was ganz anderes...
Hallo Leute, da offensichtlich alle was gegen meine etwas verstaubte Schieberegistervariante haben ;-) rufe ich hiermit zum vergleich auf welcher der verfügbaren Busse besser für Tom geeigne ist. Tom kann uns derweil mal verraten welchen uC er auf dem master und den Slaves einsetzt. evtl. schränkt das die Auswahl ein. Nur aus Spass werde ich am Schieberegister basteln ;-) Grüße Frank
Man sollte bei der Standard-Master/Slave-Lösung bleiben. Ein Slave hat sich grundsätzlich nicht unaufgefordert zu melden und den Master gibt es nur einmal. So wie die Anforderung beschrieben ist, ist das kein Master/Slave-Prinzip. Wenn sich hier alle Slaves melden, wenn sie gerade Zeit haben, sind sie definitionsgemäß kein Slave. Das geht nicht auf einem Bus wegen Kollisionen. Ich denke, das Master/Slave-Prinzip läßt sich auch hier verwirklichen. Das ist 1000-fach bewährt und dafür gibt es fertige Protokolle usw. Also der Master gibt ein Kommando mit der Adresse des Slave. Der hat als einziger zu antworten. Der Master verwirft das Kommando nach einem Timeout. Bei mir klappt das vorzüglich. Habe dabei das MODBUS-Protokoll verwendet. Man muss das Timeout in jedem Fall so lang wählen, dass der Slave antworten kann. Das ist dann eben so lang bis der Slave Zeit hat. Schieberegister-Lösung geht natürlich auch, da nimmt man z.B. Interbus-S. Mit Eigenbau habe ich damit keine Erfahrung.
Hallo zusammen! Hermann hat recht, nach der klassischen Definition trifft die Master/Slave Bezeichnung in diesem Fall nicht wirklich zu, da die "Untereinheiten" von sich aus den Datentransfer einleiten sollen. Dies wäre mir auch eine sehr wichtige Bedingung, da diese durch den Prozess des Datensammelns eigentlich schon ausgelastet sind, wobei wie anfangs erwähnt aber sowieso etwas ungenutzte Zeit anfällt während auf eine AD Konvertierung gewartet wird. Diese Zeit nun für die Kommunikation zu nutzen wäre eben ideal. Für die Entwicklung wurde der ATmega328 genutzt, obwohl das nicht zwingend die endgültige Entscheidung ist was den uC angeht. Insofern klingt Franks Schieberegister-Ansatz nach wie vor sehr interessant. Die Frage wäre jetzt nur, wie man Schreib- / Lesezugriff auf das Register synchronisiert, so dass nur dann gelesen wird wenn alle Bits bereits korrekt gesetzt wurden. Evtl ließe sich das ja schon durch ein Startbit lösen, nur wenn dieses auf 1 ist, ist das Register gefüllt, kann gelesen werden und wird danach komplett auf 0 gesetzt. Oder hat jemand eine elegantere / effizientere Lösung? Vielen Dank an alle Beitragenden für eure Hilfe!! Tom
Moin Moin, @Herman Kann man das evtl. als Multimaster lösen? Wenn der Sender Zeit hat versucht er den Bus zu bekommen und wenn er den nicht bekommt schickt er halt keine Daten? @Tom Genau bei der Datengültigkeit liegt der Hase im Pfeffer. Nach meiner Meinung gibt es da 2 Lösungsansätze: 1. man schickt ein "Startbit" mit was in der richtigen Position im Schieberegister anzeigt das Gültige Daten vorliegen. Das Risiko dabei ist das wenn der Sender schon wieder schickt obwohl der Empfänger noch nicht gelesen hat es immer noch zu falschen Daten kommen kann. 2. man gönnt der "Schnittstelle" eine "Daten OK" Leitung mit der der Sender anzeigt das er gerade nix sendet. Ich tendiere im Moment zu letzterem. Habe aber das Startbit dafür genutzt um zu sehen wie viele Bytes übertragen wurden. Also schaut bei meiner Idee der Leitungssalat derzeit so aus: TXD CLK DataValid GND Die Schaltung im Groben: 4 Schieberegister 9 Bit mit Löschen (gibt es das als Baustein?) in Reihe geschaltet. TXD und CLK Füttern die Schieberegister,DataValid geht auf nen Port am Empfänger. Vom Ablauf her denke ich mir das so: DataValid = 0, Daten werden vom sender geschickt Daten 1. Bit 1. 8Bit Daten (* Anzahl Bytes) ins Schieberegister tickern DataValid = 1, Daten im Schieberegister können gelesen werden. Empfänger prüft jeweils über das 1. Bit wie viele Daten angekommen sind und liest die Daten aus. Empfänger löscht das jeweilige Schieberegister (damit das 1. Bit wieder weg ist) und so wieter. Ich werde mal versuchen da nen Plänchen für zu basteln. Dauert aber ein wenig, weil ich derzeit weit weg und ohne jedes Tool sitze muss also über meine Wählleitung erst mal saugen ;-) Evtl. kann jemand mal schauen ob man bei den Sendern den TWI in der Richtung "verbiegen" kann? Grüße Frank
Eine Frage: Muß der Sammel-uC in der Lage sein, mehrere (im Extremfall alle) Datenströmen parallel zu empfangen oder gibt es da irgendwelche Randbedingungen beim Datenaufkommen. MfG
Ich hab sowas schon mit TWI gemacht, allerdings kommt es da echt auf die Art der physikalischen Verbindung an. Mit 0815 Kabeln bin ich da gescheitert, mit STP Kabel und STP Steck-Verbindungen hab ich es dann auf ca. 1,2m in industriellem Umfeld gebracht bei fuer mein Projekt ausreichender Geschwindigkeit. Meine Controller waren unterdshiedliche Atmegas mit 16MHz Cristallen. Ich muesste mir mal den Code anschauen um zu sagen mit welcher Geschwindigkeit ich den TWI hab laufen lassen. Das Problem bei mir war, das ich echtes Multimaster brauchte, so das jeder im Bus, wann immer, anfangen kann zu erzaehlen. Es hat mich einiges an Zeit, stundenlanges googeln und lesen, und Nerven gekostet die Atmegas dazu zu bewegen richtiges Multimaster ueber die eingebaute Hardware zu machen. Aber wie immer, ist man am Ende schlauer als zuvor. Und man weiss, dass wenn man alles richtig macht, es auch funktioniert. Gruss Ju
Moin Tom, Frage: Kann ich davon ausgehen das jedes übertragene Byte != 0 ist? Dann kann ich mir das extra Bit sparen ;-) Gruß Frank
Einen guten Morgen zusammen! Frank Sander schrieb: > 1. man schickt ein "Startbit" mit was in der richtigen Position im > Schieberegister anzeigt das Gültige Daten vorliegen. > Das Risiko dabei ist das wenn der Sender schon wieder schickt obwohl der > Empfänger noch nicht gelesen hat es immer noch zu falschen Daten kommen > kann. In letzterem Fall könnte ja der Sender einfach vor jedem neuen Senden das Register löschen um ungültige Daten zu vermeiden. Allerdings wäre dann der vorherige Satz natürlich verloren... > 2. man gönnt der "Schnittstelle" eine "Daten OK" Leitung mit der der > Sender anzeigt das er gerade nix sendet. Klingt auch nach einer guten Lösung. Könnte es denn hier im schlimmsten Fall zu einer Race Condition kommen, oder ist das vernachlässigbar? (Leser prüft Daten Ok Leitung aber bevor er den tatsächlichen Lesezugriff ausführen kann wurde doch schon wieder das nächste Bit geschoben) @ Matthias >Muß der Sammel-uC in der Lage sein, mehrere (im Extremfall alle) >Datenströmen parallel zu empfangen oder gibt es da irgendwelche >Randbedingungen beim Datenaufkommen. Da die einzelnen Sender eben genau nicht synchronisiert sind kann es durchaus zu parallelen Datenströmen kommen. @ Juergen >... die Atmegas dazu zu bewegen richtiges Multimaster ueber die > eingebaute Hardware zu machen. Aber wie immer, ist man am Ende schlauer >als zuvor. Das hört sich sehr interessant an, hast du dazu noch ein paar weitere Infos wie du das letztlich lösen konntest? @ Frank > Kann ich davon ausgehen das jedes übertragene Byte != 0 ist? > Dann kann ich mir das extra Bit sparen ;-) 0 kann durchaus vorkommen, sorry ;-) Aber da es ja hier erstmal um das Konzept geht, kannst du natürlich auch ohne Nullen arbeiten. Vielen Dank an alle, ich weiß euren Input sehr zu schätzen! Guten Start in den neuen Tag und bis dann! Tom
Moin Tom, auch wenn ich es schon gesagt habe: ok, Du machst es nicht wirklich einfacher ;-) Ich habe mittlerweile nen Eagle am rennen und bin am Schalten. Racing habe ich denke ich ausgeschlossen durch Schieberegister mit Puffer. Bin derzeit am Stricken wirklich nur die 3 o.g. Signale zu benötigen. Konzeptschaltung kommt also bald ;-) (Wenn ich verstanden habe wie ih die "Drucken" kann und dann hier anhängen) Gruß Frank
Frank Sander schrieb: > (Wenn ich verstanden habe wie ih die "Drucken" kann und dann hier > anhängen) Eagle-Menü: Datei - Exportieren ... - Image
Angehängte Dateien:
-
Schieben.png
12 KB
Hallo Halli, @Tip: Super Danke!! @Tom (und wer immer sonst noch Spass dran hat) Anbei mal ein erstes Konzept. Damit kann man bis zu 4 Byte empfangen. IC5B verrät wie viele Byte gesendet wurden. Die Puffer und der Zähler werden noch nicht zurück gesetzt, da bastel ich noch. Dann muss ich auch noch nen Multiplexer basteln das man die Bytes über einen Port einlesen kann. Ich bin für Ideen immer offen ;-) Ach ja, das ist bitte nur ein Konzept und NICHT ausgetestet. in dem Plänchen fehlen diverse Spannungsversorgungen, Kapazitäten und so was alles ;-) Grüße Frank
Angehängte Dateien:
-
Schieben.png
12 KB
Hallo noch mal ;-) so nu habe ich auch das mit dem Zurücksetzen im Griff. Ich habe die Schieberegister getauscht gegen welche mit tri state Ausgang. Der Vorteil: Es können jetzt alle Schieberegister Parallel auf einen Port des Empfänger uC geschaltet werden. Der zu lesende wird via pin 13 des Schieberegisters ausgewählt. Aus diesem Grund auch der 74244 am Zähler (IC5B). auch idese können alle Parallel auf einen Port des uC geschaltet werden und über das Gate wird ausgewählt welcher "Byte Anzahl" gelesen wird. Gesteuert wird alles durch den Sender. Genauer durch die /Send_Data_Sender Leitung. diese Leitung muss vom Sender während des senden auf 0 gehalten werden. Wenn alle Bytes durch getickert wurden muss der Sender diese Leitung auf 1 setzen. Dadurch werden die Daten in den Puffer der Schieberegister übernommen. Durch das Zählen der TX Clock Pulse und Teilen dieser durch 8 (IC5A & B) haben wir die Anzahl der gültigen Bytes. Gültig ist die Information am Zähler nur bis ein neuer Sendevorgang beginnt. Um Kummer zu vermeiden sollte der Empfänger auch nur bis dahin Daten lesen. Kurz: Wenn "Send_Data_Sender" auf 1 ist kann, darf, sollte man die Register auslesen. Ist das Signal 0 lässt man die Finger davon. Diese Schaltung kann ohne viel Kummer auf 15 Bytes erweitert werden. Einfach mehr Schieberegister einfügen. Es können beliebig viele Sender parallel geschaltet werden. Ist eine Frage ob und wie schnell der Empfänger uC die Dinger auslesen kann. Theoretisch kann man auf die Steigende Flanke des "Send_Data_Sender" einen Interrupt auf dem Empfänger auslösen. Ob das nötig ist, ist von der Anwendung abhängig. Habe ich was vergessen? Habe ich was verdreht? Gibt es Denkfehler in der Schaltung? Lasst es mich bitte wissen. Gruß Frank P.S. Ich kann das ganze leider nicht testen. Dummerweise habe ich auch keinen Simulator hier. Wenn jemand einen Simulator auf OSX empfehlen kann!?
Ups noch einen habe ich: Die Bausteine sind nach rein Logischer Funktion ausgewählt. NICHT nach elektrischen oder timing Gesichtspunkten! Gruß Frank
@Frank Das mit den Shift Registern (SR) und der Logic drumherum ist eine schoene Fingeruebung, doch besteht weiterhin das Problem, das der Empfaenger (hier im Thread als Master bezeichnet) die Daten aus den SR's lesen muss. Dazu benoetigt er Zeit und eine Unmenge Port Pins in Deinem Beispiel. Fuer mich sieht das nicht nach einer optimalen Loesung aus. Die Leute die SPI, I2C & Co entwickelt haben, sind Dir da ein paar Schritte voraus. Das was Du da gezeichnet hast, kann man mit dem SPI der AVR's und einem zusaetzlichem Pin (dem CS zBsp.) direkt machen. Alle MOSI der Sender gehen auf den MISO des Empfaengers. Die CS sind alle zusammengeschaltet. Will ein Sender senden, ueberprueft er den CS, wenn frei dann zieht er den CS auf den entsprechenden Pegel und legt los seine Daten zu senden. Erstes Byte ist seine ID, zweites Byte die Menge der Daten die er senden will, dann die Daten und wenn noetig eine Pruefsumme. Der Empfaenger laeuft im Interrupt-Betrieb, das heisst wenn ein Byte komplett ist kommt der Interrupt, er liest das Byte aus, und es kann weiter gehen. Eine State Machine macht die Zuordnung der Bytes. Der SPI des AVR ist gut schnell, und die ISR macht das lesen auch ausreichend effective. Alle Leitungen sind einseitig in der Datenrichtung, somit ist es einfach mit ein paar Optokopplern die Physikalischen Leitungen stoerungsfrei zu bedienen. In der Industrie ist das eine sehr oft verwendete Schnitstelle zu Sensoren mit Messwertaufbereitung. Nachteil des SPI ist, das der SPI des AVR nicht redundant (doppelgepuffert) ist, damit also Daten verloren gehen koennen wenn der Empfaenger (die Software darin) das nicht richtig handhabt. Somit suchen wir ein Protokoll das dieses umgeht, und kommen dabei auf I2C(TWI). Beim I2C funktioniert der ganze Protokoll Kram und Identifizierung schon zu grossen Teilen in der Hardware. Wichtigste Aufgabe des Programmierers ist es da, "alle" I2C Zustaende in der Software zu behandeln. Nachteil ist, das die Datenrichtung beidseitig ist, somit die Implementierung in Hardware ueber laengere Kabel etwas umfangreicher. Dafuer war I2C aber auch nicht gedacht. Zur Programmierung des TWI im AVR. Wie weiter oben schon geschrieben. Wenn man es macht wie es sein soll funktioniert alles perfekt. Alle Beispiele zu TWI und I2C die ich gesehen habe, haben Defects, immer ist irgend etwas was nicht funktioniert was dann den Bus in der Luft haengen laesst. Es werden die tollsten Erfindungen gemacht um das zu "korrigieren" meistens wird bei diesen "Korrektionen" der Bus resettet. Das ware Problem ist aber, das keines der gesehenen Beispiele alle moeglichen Zustaende des I2C behandelt. Wenn dann ein nicht behandeltes Ereignis eintritt, bleibt der Bus in der Luft haengen weil nicht darauf reagiert wird. Ju
Hallo Jürgen, ich hoffe doch das es eine bessere Möglichkeit als mein Monster gibt. Nicht zuletzt aufgrund Hermanns und deiner Kommentare bin ich eifrig am lesen und lernen. Bitte sei mir net böse das ich die Chance zu einer Fingerübung genutzt habe. Es ist fast 20 Jahre her das ich das letzt mal so was gebastelt habe und es hat mich einfach gereizt mal zu testen ob noch was geht ;-) Ein bischen widersprechen muss ich allerdings bei den unmengen Port pins ;-) Es sei den 16 Pins (im Maximum) sind eine Menge. Interruptsteuerung kann man dem Ding auch noch verpassen :-) Aber ich gebe zu dann wird es langsam wild. Ich täte um die Asynchronität zu gewährleisten normal die Daten in einen Speicher tickern und vom Empfänger über eine 2. Schnittstelle auslesen. Da ich aber keinerlei Unterlagen hier habe und mir jede Information über eine gute alte Wählleitung (ja so etwas gebt es noch) zusammen sammeln muss, konnte ich diesen Entwurf nicht erstellen. Ich weiß es gibt serielle Speicher, aber gibt es die mit 2 Schnittstellen? Wäre das ein Denkansatz um die letzten Probleme zu lösen? Gruß aus der ferne Frank
@ Frank: Schon mal ein großes Dankeschön an dich für die Ideen und Ausarbeitungen, hat mir auf jeden Fall einige neue Denkanstöße und Ideen gegeben! @ Juergen: Auch dir großes Dankeschön für die ausführlichen Infos und Empfehlungen, auch diese Ansätze werde ich mir noch mal genauer anschauen! Grüße & einen schönen Abend! Tom
Das einfachste ist ein kleiner CAN Bus. Als Controller hat sich der MCP2515 bewährt. http://de.wikipedia.org/wiki/Controller_Area_Network
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.