Hallo, ich möchte einige Mikrocontroller(8-Bit AVRs & Rasperry PI) über Bus verbinden. Allerdings müsste jeder Microkontroller eine einmalige Adresse haben (ähnlich wie bei 1-Wire Bus, der leider zu langsam ist)SPI und I²C währen schnell genug. I²C hat zu wenige Adressen. SPI Adressierung leider über CS-PIN auch nicht möglich. Der Bus muss auf im Mikrocontroller vorhandener Hardware aufbauen, es soll keine zusätzliche Hardware verwendet werden. Gibt es eine Möglichkeit eine vorhandene Schnittstelle (I²C, SPI, URAT oder 1-Wire) so einzusetzen, das man vor jeder Nachricht die Adresse über den Bus sendet, und der Empfänger mit der gesendeten Adresse die Daten empfängt. Es müsste allerdings auf dem Geschwindigkeitsniveau von SPI oder I²C liegen. Danke Marcel
Marcel schrieb: > einige Mikrocontroller Marcel schrieb: > I²C hat zu wenige Adressen. Kannst du das wenigstens grob eingrenzen?
Es sollen so 20 - 40 MCs auf dem Bus kommunizieren können. Es soll so viele Adressen (48Bit)verwendet werden, das jeder MC eindeutig an seiner Adresse zu identifizieren ist. Ich könnte mir auch vorstellen jeden MC so eine Art MAC-Adresse zu geben. Das wichtigste währe das man es PnP zusammenstecken kann. Der Anwender soll keine Adressen ändern müssen. I²C würde von der Adressanzahl reichen, es müsste nur gewährleistet sein dass bei Anschluss eines MCs automatisch eine noch nicht benutzte Adresse zugeteilt wird.
Es sollen so 20 - 40 MCs auf dem Bus kommunizieren können. Es soll so viele Adressen (48Bit)verwendet werden, das jeder MC eindeutig an seiner Adresse zu identifizieren ist. Ich könnte mir auch vorstellen jeden MC so eine Art MAC-Adresse zu geben. Das wichtigste währe das man es PnP zusammenstecken kann. Der Anwender soll keine Adressen ändern müssen. I²C würde von der Adressanzahl reichen, es müsste nur gewährleistet sein dass bei Anschluss eines MCs automatisch eine noch nicht benutzte Adresse zugeteilt wird.
@ Marcel (Gast) >Es sollen so 20 - 40 MCs auf dem Bus kommunizieren können. Es soll so >viele Adressen (48Bit)verwendet werden, das jeder MC eindeutig an seiner >Adresse zu identifizieren ist. Für 40 uCs reichen 6 Bit. > Ich könnte mir auch vorstellen jeden MC so eine Art MAC-Adresse zu geben. >Das wichtigste währe das man es PnP zusammenstecken kann. Der Anwender >soll keine Adressen ändern müssen. I²C würde von der Adressanzahl >reichen, es müsste nur gewährleistet sein dass bei Anschluss eines MCs >automatisch eine noch nicht benutzte Adresse zugeteilt wird. Kann man machen, 1 Wire macht es über eindeutige 64 Bit IDs, welche in der speziellen Sequenz abgefragt werden. Damit kann automatisch der gesammte Bus initialisiert werden.
40 Controller, und dann noch nahe beieinander. Könnte man da nicht nur einen Rechner mit mehr Leistung nehmen? 40 * 16 MHz = 640 MHz. Ein zweiter Raspi reicht aus. Kommunikation über Ethernet. Das ist alles schon fertig.
Marcel schrieb: > I²C hat zu wenige Adressen. Für 40-50 Controller reicht es aber trotzdem. Der große Vorteil ist halt, dass es hier echten Hardware-Support gibt. Alles andere kostet dich Zeit, nämlich zum Entwickeln des Konzepts sowie zur eigentlichen Programmierung. Im Rahmen eines anderen Projekt (Beitrag "LED Tisch mit Berührungs-/Gegenstandserkennung") denke ich zur Zeit über einen UART Ring nach. Auch hier sollen die Slaves addressiert werden können, um z.B. einzelne Controller zu programmieren bzw. deren EEPROM auszulesen. Allerdings hängt das alles sehr stark von den Anforderungen ab, und darüber hast du uns nicht all zu viel verraten. Mit freundlichen Grüßen, Karol Babioch
Marcel schrieb: > Es sollen so 20 - 40 MCs auf dem Bus kommunizieren können. Es soll so > viele Adressen (48Bit)verwendet werden, das jeder MC eindeutig an seiner > Adresse zu identifizieren ist. Ich könnte mir auch vorstellen jeden MC > so eine Art MAC-Adresse zu geben. Wenn Du Deine AVRs durch PIC18F67J60 ersetzt, kannst Du gleich Ethernet und TCP/IP nehmen. Die üblichen Mechanismen wie Zeroconf, DHCP etc existieren dort alle schon. Der genannte PIC hat Ethernet MAC+PHY gleich mit auf dem Chip drauf, d.h. einfacher, kleiner und billiger bekommst Du es sonst einfach nicht hin. Microchip liefert Dir die gesamte erforderliche Software kostenlos. Ansonsten: (a) RS485 plus ein entsprechendes Protokoll obendrauf. Geht problemlos mit AVR über UART. (b) CAN: Da nimmst Du besser einen PIC18F25K80, der hat nämlich schon den passenden CAN-Controller eingebaut. Bei einem AVR wäre das noch ein extra Baustein mit extra Quarz, und das ist deutlich teurer als der PIC, der alles schon eingebaut hat und nur noch den PHY (Transceiver braucht). Du könntest auch einen LPC11U24 nehmen, aber der ist im QFN-Gehäuse und damit schwerer zu verarbeiten. Für längere Strecken brauchst Du ein richtiges Bussystem, das an beiden Enden terminiert ist, damit es keine Reflektionen gibt. I2C ist nicht für längere Strecken und höhere Teilnehmerzahlen gedacht und geeignet, weil es nicht richtig terminiert werden kann (ist nicht vorgesehen) und keine differentielle Übertragung nutzt. Problem: Wenn Du den Bus auftrennst, um weitere Teilnehmer einzufügen, steht der Bus, weil zu dem Zeitpunkt ein Ende nicht terminiert ist. Das ist bei einer Bustopologie so. Stichleitungen sind nicht erlaubt, alle Teilnehmer hängen direkt am Kabel. Auch das hat nachrichtentechnische Gründe. Das heute gebräuchliche Twisted-Pair Ethernet verwendet einen Sternverteiler (Switch) und vermeidet damit die obigen Nachteile, d.h. hier kann man in laufenden Betrieb Teilnehmer hinzufügen oder entfernen, ohne die anderen Teilnehmer zu stören. fchk
Du könntest en modifiziertes I2C Protokoll nehmen. Gib allen Mikrocontrollern die gleichen 7bit Adresse als Dummy. Damit bist Du erstmal kompatibel zum I2C Protokoll. Der Master sendet zuerst die Dummy Adresse mit R/W Bit auf "WRITE". Dann sendet er die n Bytes lange Adresse des Slaves, der angesprochen werden soll. Ein Bit davon bestimmt, ob Du lesen oder schreiben willst, es ersetzt also das ursprüngliche R/W Bit des I2C Protokolls. Der angesprochene Slave antwortet mit ACK, die anderen Slaves reagieren nicht. Andere Mikrochips können wie üblich per I2C angesprochen werden.
Stefan us schrieb: > Du könntest en modifiziertes I2C Protokoll nehmen. An sich eine schöne Idee, die mir so noch gar nicht gekommen ist. Andererseits verdoppelt man damit den Overhead. Hat es eigentlich einen Grund warum das ursprüngliche R/W Bit WRITE sein soll? Solange man das bei allen konsequent macht, sollte das doch egal sein, oder über sehe ich etwas? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Hat es eigentlich einen Grund warum das ursprüngliche R/W Bit WRITE sein > soll? Weil danach der zweite Teil der Adresse geschrieben wird.
Max H. schrieb: > Weil danach der zweite Teil der Adresse geschrieben wird. Oops, wohl zu wenig Schlaf erwischt. Besonders habe ich hier ja nicht mit gedacht :). Danke! Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Marcel schrieb: >> I²C hat zu wenige Adressen. > > Für 40-50 Controller reicht es aber trotzdem. So wie ich die Frage verstehe, soll nicht nur jeder µC an dem einen Bus, sondern jeder insgesamt eine eigene Adresse haben. Eben wie bei MAC-Adressen: Marcel schrieb: > Ich könnte mir auch vorstellen jeden MC so eine Art MAC-Adresse zu geben.
Marcel schrieb: > I²C hat zu wenige Adressen. I²C gibt es auch mit 10-Bit Adressierung. Bei deinen max. 40 µC hättest du gerade mal 4 Prozent des Adressraumes ausgeschöpft.
Stefan us schrieb: > Du könntest en modifiziertes I2C Protokoll nehmen. Gib allen > Mikrocontrollern die gleichen 7bit Adresse als Dummy. Also die eigentliche Adressierung in Software? Könnte man dann nicht besser gleich SPI ohne CS nehmen und sich damit die ungenutzte I²C-Adressierung sparen?
Weitere ad hoc Variante, in der eine Adressierung analog der 48-Bit Ethernet Adresse mit der Effektivität der I2C Adressierung von hier ausreichenden bis zu 112 Slaves kombiniert wird: Ein GENERAL CALL (Adresse 0) mit folgendem Steuerbyte 0xAA (beliebig gewählt) versetzt alle Slaves in den adressfreien Modus, damit das Verfahren ggf. komplett von vorne beginnen kann. Nötig beim Restart des Masters. Ein GENERAL CALL mit Steuerbyte 0x55 versetzt alle adressfreien Slaves in einen Modus zur Adressvergabe. In diesem Modus wird mit der SDA Leitung (und nur dieser) mit einem Arbitrationsschema orientiert an 1-Wire aber mit für AVRs geeigneterem exaktem Verfahren ein einzelner Slave ausgewählt. Der kriegt dann vom Master eine eindeutige I2C-Adresse verpasst und nimmt danach nicht mehr an diesem Verfahren Teil. Aktivitäten auf SDA ohne Aktivität auf SCL interessiert I2C Hardware nicht, stört also nicht. Fest adressierte I2C-Slaves bleiben einsetzbar, solange sie sich nicht am GENERAL CALL stören (ist in AVRs abschaltbar). Der Master kann das Vergabeverfahren, sowie ein Polling aller ihm bereits bekannten Slaves, alle paar Sekunden durchführen, um neue und verschwundene Slaves zu erkennen.
:
Bearbeitet durch User
Genereller Nachteil aller I2C Verfahren: Es gibt keinen zuverlässigen Mechanismus zur Absicherung gegen Fehler. Störungen auf den Leitungen können Master wie Slave aus dem Konzept bringen, selbst wenn der Inhalt der Frames CRC-gesichert sein sollte.
Frank K. schrieb: > ... > (b) CAN: Da nimmst Du besser einen PIC18F25K80, der hat nämlich schon > den passenden CAN-Controller eingebaut. Bei einem AVR wäre das noch ein > extra Baustein mit extra Quarz, und das ist deutlich teurer als der PIC, > der alles schon eingebaut hat und nur noch den PHY (Transceiver > braucht). Du könntest auch einen LPC11U24 nehmen, aber der ist im > QFN-Gehäuse und damit schwerer zu verarbeiten. > ... Den AT90CAN32/64/128 kennst Du anscheinend nicht?
Frank K. schrieb: > Bei einem AVR wäre das noch ein extra Baustein mit extra Quarz, Selbst wenn man MCP2515 statt AT90CANxx einsetzt kann man dennoch ohne doppeltem Quarz arbeiten. Der vom AVR wird dann oft überflüssig.
Rolf Magnus schrieb: > Könnte man dann nicht besser gleich SPI ohne CS nehmen und sich damit > die ungenutzte I²C-Adressierung sparen? Nein. SPI ist im Gegensatz zu I2C ein bidirektionales Protokoll, es fließen also bei der Komunikation immer Daten gleichzeitig in beide Richtungen. Das funktioniert natürlich nur mit Punkt-zu-Punkt-Verbindungen. Ohne CS würden alle Slaves ihre Daten gleichzeitig auf den Bus legen, und: KRAWUMM. Wenn du SPI ungefähr in dieser Art verwenden willst, wie es dir vorschwebt, brauchst du für alle Busteilnehmer eine unabhängig deaktivierbare MISO-Leitung, was nicht gerade ein weit verbreitetes Feature üblicher SPI-Hardware ist... Du müßtest also bei jedem Busteilnehmer, der das nicht kann, mit zusätzlicher Hardware nachhelfen (z.B. 1/4 74126) und bräuchtest dann dort auch einen zusätzlichen Pin zur Kontrolle eben dieses Treibers. Dazu kommt das Problem, daß der Master alle Slaves gleichzeitig treiben können muß und zwar auf drei Leitungen, MOSI,SCK und CS. Da ist auch schnell die Grenze des Möglichen erreicht. Also auch hier nochmal drei Bustreiber. Und wenn es gar eine Multimaster-Architektur werden soll, brauchen zumindest alle Busteilnehmer, die auch Master sein sollen, den vollen Satz von vier Bustreibern. Von dem recht komplexen Softwareprotokoll, welches auf jeden Fall zusätzlich nötig wäre mal ganz zu schweigen. Und normale SPI-Geräte könnten an diesem Bus nur mitbetrieben werden, wenn sie nach wie vor jeweils eine eigene CS-Leitung bekommen.
Martin schrieb: > Frank K. schrieb: >> ... >> (b) CAN: Da nimmst Du besser einen PIC18F25K80, der hat nämlich schon >> den passenden CAN-Controller eingebaut. Bei einem AVR wäre das noch ein >> extra Baustein mit extra Quarz, und das ist deutlich teurer als der PIC, >> der alles schon eingebaut hat und nur noch den PHY (Transceiver >> braucht). Du könntest auch einen LPC11U24 nehmen, aber der ist im >> QFN-Gehäuse und damit schwerer zu verarbeiten. >> ... > > Den AT90CAN32/64/128 kennst Du anscheinend nicht? Doch, aber der ist für viele Anwendungen zu groß und zu teuer. Im Bereich 20 bis 28 Pins hat Atmel nichts anzubieten. Macht aber auch nichts, Microchip hat da eine reichhaltige Auswahl, nicht nur bei 8-Bittern, sondern auch bei 16- und 32- Bittern. Es gibt noch ein paar Automotive-AVR-Varianten, aber die sind im freien Handel kaum erhältlich. fchk
A. K. schrieb: > Frank K. schrieb: >> Bei einem AVR wäre das noch ein extra Baustein mit extra Quarz, > > Selbst wenn man MCP2515 statt AT90CANxx einsetzt kann man dennoch ohne > doppeltem Quarz arbeiten. Der vom AVR wird dann oft überflüssig. Auch dann ist der PIC (a) billiger, (b) kleiner und (c) bei der CAN-Kommunikation schneller als die AVR+MCP2515-Kombination. Man kann direkt auf die CAN-Register zugreifen (das sind SFRs wie alle anderen Register auch, da ist kein SPI dazwischen), und der ECAN des PIC18F25K80/26K80 ist eine deutlich verbesserte Version des MCP2515 mit mehr Puffern und weniger Bugs. fchk
Frank K. schrieb: > CAN: Da nimmst Du besser einen PIC18F25K80, der hat nämlich schon > den passenden CAN-Controller eingebaut. Noch besser einen LPC11C22FBD48, der hat auch noch den CAN-Transceiver eingebaut. Und ist kein PIC.
Frank K. schrieb: > Auch dann ist der PIC (a) billiger Als ich vor einigen Jahren mal einen PIC18F258 ausprobierte war der deutlich teurer als ein ATmega8 plus MCP2515. Jedenfalls bei Reichelt. Nicht dass das wirklich eine Rolle spielen würde, aber es war schliesslich dein Argument. ;-) > (b) kleiner und (c) bei der CAN-Kommunikation schneller Klar. Es ging mir nur um den Quarz. Dass Microchip da Atmel einiges voraus hat ist klar - einige Bugs aber auch, die CAN Module von Microchip waren zumindest früher mit recht bösen Bugs ausgestattet.
:
Bearbeitet durch User
A. K. schrieb: > Als ich vor einigen Jahren mal einen PIC18F258 ausprobierte war der Autsch. DAS ist ja wirklich eine alte Kamelle - in diesem Fall wundert mich das nicht. Der wird zwar immer noch produziert für die Leute, die alte Designs haben, aber das lässt sich Microchip auch sehr gut bezahlen. Den Nachfolger 18F2580 gibt es so viele Jahre, dass er inzwischen auch schon wieder überholt ist. Ich habe mal nachgeschaut: Reichelt hat wirklich noch einiges an nicht mehr zeitgemäßem Uraltzeugs im Angebot (alle PICs mit dreistelligen Nummern nach dem F), aber nur wenige moderne Varianten (die mit J und K in der Typenbezeichnung). Dafür sollte man eigentlich den zuständige Produktmanager ins Achtung stellen. Woanders wurden solche Leute schon aus weit geringerem Anlass gevierteilt. fchk
Frank K. schrieb: >> Als ich vor einigen Jahren mal einen PIC18F258 ausprobierte war der > > Autsch. DAS ist ja wirklich eine alte Kamelle Sicher - aber das war anno 2007.
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.