Adressierung über Bus

@ 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.

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

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.

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.

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:
> 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.

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:
> 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.

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.