Guten Tag! Ich hab zum Thema nichts passendes auf Google und auch nicht hier gefunden. Und zwar möchte ich per SPI mehrere Atmegas oder Tinys, um die 100, ansprechen, die in einem 10x10 Array angeordnet sind. Ich stelle mir vor, per Multiplexing jeweils X und Y-Leitungen anzusprechen und mit einem NAND-IC an den Knotenpunkten CS zu aktivieren. Die Datenleitungen und Clock wären alle miteinander verbunden. Es geht darum, Messwerte abzufragen und jeweils ne Hand voll LEDs anzusteuern. 1. Ist die Idee gut bzw. machbar? :-) 2. Gibt es Störanfälligkeiten? Es spielt sich immerhin auf 1m² ab und es geht um hohe Frequenzen. Genaue Frequenz muss ich dann noch im Test bestimmen. 3. Ich bin gerade selber auf der Suche nach den I/O-Spezifikationen. Die Ausgänge schalten auf Hochohmig wenn kein CS aktiv ist. Brauchte ich für die Eingänge (1x MOSI auf 100x MISO) noch eine Verstärkerstufe oder reicht die Leistung? Vielen Dank!
Die 100 Geräte am Bus würden einen µC Ausgang ziemlich belasten. Dadurch wird das Signal langsamer (Anstieg- und Abfallzeiten sind länger). Über die HF-Eigenschaften denke ich lieber nicht so genau nach... Ich würde als Kompromiss ein paar Bustreiber (74HC125 o.ä.) mit schalten, und damit etwa 10 Busse á 10 Teilnehmer draus machen. Das sollte die Betriebssicherheit beträchtlich erhöhen.
@ Adrian S. (adrian_s38) >Ich stelle mir vor, per Multiplexing jeweils X und Y-Leitungen >anzusprechen und mit einem NAND-IC an den Knotenpunkten CS zu >aktivieren. Kreativ, aber eher unsinnig. Für sowas nimmt man einen Bus. >1. Ist die Idee gut Nein. >bzw. machbar? :-) Ja. >2. Gibt es Störanfälligkeiten? Es spielt sich immerhin auf 1m² ab und es >geht um hohe Frequenzen. Genaue Frequenz muss ich dann noch im Test >bestimmen. Tu das. >3. Ich bin gerade selber auf der Suche nach den I/O-Spezifikationen. Die >Ausgänge schalten auf Hochohmig wenn kein CS aktiv ist. Brauchte ich für >die Eingänge (1x MOSI auf 100x MISO) noch eine Verstärkerstufe oder >reicht die Leistung? Alles eine Frage der Geschwindigkeit.
Danke für die Antworten bisher! Das mit dem Bus-Treiber ist eine gute Idee. Ich hatte mir SPI ausgesucht, da ich das ganze dann auch bequem über die gleich Technik programmieren könnte. Wäre die Hardware der TWI-Schnittstelle denn stabiler? Oder muss man für beides Treiber vorsehen? Mein aktueller Plan wäre jetzt: CS wie bisher über X/Y-Koordinaten benutzen, Die Busleitungen MISO, MOSI über Treiber zu unterteilen. Dazu noch Kritik oder Verbesserungsvorschläge?
Gast
#3698487
Wieso nicht twi und eventuell i2c mux oder SPI sei als chain oder nicht MIT bypass zb MIT 244
Hier wäre ein anderer Bus als ausgerechnet SPI doch von Vorteil, und zwar einer, bei dem Du die Adressinformation gleich mit in das übertragene Datenprotokoll packst. Das mag zwar auf den ersten Blick aufwendig erscheinen, aber die Ansteuerung Deiner CS-Matrix ist das auch, und das eine mehr übertragene Datenbyte verlangsamt das Protokoll effektiv nicht. Das I2C-Protokoll ist für derartiges geeignet. Wenn Du nur Deine eigenen µCs verwendest, kannst Du auch andere Datenraten als die "offiziell" von I2C vorgesehenen 100 bzw. 400 kHz verwenden. Es gibt I2C-Implementierungen mit Datenraten im MHz-Bereich, das ist also mit SPI durchaus vergleichbar. Und Du hast erheblich weniger Drahtverhau; eine 10 x 10 - Matrixschaltung nebst 100 NAND-Gattern braucht ja auch etwas Platz.
Vielen Dank für den verständlichen Beitrag, Rufus! Ich habe keine Abneigung gegen andere Protokolle. Ich wiege halt noch die Optionen ab. Adressierung und andere Protokolle machen mir keine Sorgen. Auch nicht das extra Adress-Byte. Ist I²C denn stabiler gegen kapazitive Verwaschung des Datenstroms? Vermutlich muss ich da auch Treiber benutzen. Ich will mich ja nicht auf SPI festbeißen. Vorteil ist immer noch das ich per Batch alle 100 MCUs auf die selbe Weise programmieren könnte. Die NAND-Gatter machen keine Platzprobleme. Platz wäre auf den 100 Platinen genügend. Gruß Adrian
Adrian S. schrieb: > Ist I²C denn stabiler gegen kapazitive Verwaschung des Datenstroms? Schöne Formulierung. > Vermutlich muss ich da auch Treiber benutzen. Dafür gibt es spezielle I2C-Bus-Repeater: http://www.nxp.com/products/interface_and_connectivity/i2c/i2c_bus_repeaters_hubs_extenders/#products Dann allerdings ist der I2C-Takt auf maximal 1 MHz begrenzt; achte bei der Auswahl des Bausteines auf den unterstützten Takt. Bei der I2C-Variante müsstest Du eine eindeutige Adressierung der µCs vornehmen, d.h. entweder mit externer Hardware (I/O-Leitungen etc.) die Adresse in Hardware vorgeben, in Deinem Programm fest vorgeben (ungünstig, braucht immerhin 100 verschiedene Varianten) oder per Software einstellbar machen (und im EEPROM oder was auch immer Deine µCs haben abspeichern).
Vielen Dank! Ich schätze ich wäre bei ca 80KHz inklusive Reserve und Pausen. Werde mal ne Kostenrechnung machen. Adressierung bei I²C ist mir klar. Die MCUs hätten im EEPROM ihre Adresse. Danke für die Hilfe!
Du kannst die I2C-Adressierung auch auf SPI übertragen wenn Dir bidirektional lieber ist und weniger CS-Leitungen nehmen. Intersil macht das z.B. bei den MCP23017/23S17 so.
Dann aber muss man das SPI-Protokoll etwas ... anders interpretieren. Während der Übertragung des Adressbytes darf keiner der Slaves antworten, sonst gibt es Datensalat, und für den Rest darf nur der jeweils angesprochene Slave antworten. "Nicht antworten" bedeutet hier, die Sendedatenleitung im Tristate (hochohmig) zu lassen. Das dürfte mit den Standard-SPI-Routinen nicht ohne Anpassungen möglich sein, und ob es die jeweilige SPI-Hardware ohne weiteres unterstützt, wird vom verwendeten Controllertyp abhängen. Gut, das ließe sich mit einem Treiberbaustein wie z.B. 'HC125 erledigen, der über eine Portleitung vom Slave anzusteuern ist.
Gast
#3699750
Wie wäre es mit der LPC11C Serie von NXP? CAN Treiber incl. Tranceiver im uC inklusive. Wäre bei 100 Teilnehmern evtl eine "günstige" alternative wenn man sich Treiber, äußere Beschaltung und Platz sparen kann.
Wenn die Slaves auch antworten sollen, ist das AVR-SPI ein Albtraum. Ein Perpetuum mobile zu entwickeln ist einfacher. Bei I2C ist es dagegen kein Problem, wenn ein Slave mal etwas länger braucht, um in den Interrupt zu kommen. Die Master-Hardware wartet dann automatisch. Der Favorit ist aber ganz klar CAN. Da hat man den geringsten Programmieraufwand bei maximaler Zuverlässigkeit.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.