Ist das Möglich über RS232

das ist kein Problem des MC, sondern der Schnittstellenbausteine. Bei
üblichen RS232 musst du sicher mit der Baudrate runtergehen, je nach
Gesamtleitungslänge. Wieviele Eingänge ein Treiber verkraftet, kann ich
dir jetzt auch nicht sagen, logisch ist das jedenfalls kein Problem.
Ohne Rückkanal wird das Ganze aber mit Sicherheit schiefgehen. Du
schickst eine Meldung los und hoffst, dass sie ankommt. Was, wenn
nicht? Merkst du nicht einmal.
Ich würde RS485 nehmen und alles quittieren lassen. Mit einer einfachen
2Drahtleitung hast du bidirektionalen Verkehr, zwar nur Halbduplex, aber
das ist kein Problem.

Nein mom ich habe da noch was vergessen...

Ich jage das hinter dem PC durch einen MAX232 oder 202 durch und
bekomme dann das 5V Signal. Dieses schicke ich direckt auf den µC und
zwar auf alle gleichzeitig. An Rx und Tx und werte die Daten dann aus.
Einen rückkannal habe ich dadurch doch. Ich habe ja einmal Rx zum
Senden und Tx zum empfangen, oder andersrum, ich vergesse das immer
weider...

Dann lege ich alle Rx und Tx von den kompletten µCs an den Bus und muss
denen nur noch sagen macht mir keine Kollisonen im Netz.

Getestet habe ich das ganze bisher mit zwei µCs im Betrieb ohne lange
kabelverbindung das ging ja wunderbar, aber ich denke mir irgendwann
ist das Signal duch die vielen Eingangswiederstände der vielen µCs so
fertig das sie das Signal nicht mehr erkennen können.

alle Tx an eine Leitung geht aber bei RS232 nicht...

so wie auf dem anhängenden Schaltplan habe ich mir das vorgestellt.

Die Txe hängen jetzt aber alle an einer Leitung soll heißen da kanns
sehr leicht passieren das mehrer Ausgänge gegeneinander treiben.
Selbst wenn du den Tx auf Eingang lässt und nur auf Ausgang schaltest,
wenn er senden soll kann es bei 100 µCs sehr schnell durch was auch
immer für Umstände dazu kommen das zweie gleichzeitig senden...
Also ich würde auf jeden Fall Schnittstellen-ICs verbauen. Abgesehen
von der Kollisionsproblematik könnte auch der 5V-Pegel bei der
Leitungslänge zum Problem werden.

Das funktioniert so nicht. Setze einen MAX483 auf der PC-Seite und pro
MC ebenfalls einen. Damit kannst Du bis zu 256 Geräte am Bus
betreiben.

Die RS485 ist zwar eigentlich nicht für sternförmige Verbindungen
gedacht, funktioniert aber bei einigen mir bekannten Installationen
(max. 200m Leitungslänge, 9600 Baud [nein, die sind nicht von mir])
recht gut.

Steffen

Datenblatt macht schlau !
Wichtige Punkte sind gekennzeichnet.

Nimm statt RS485 RS422 - das ist die für diese Anwendung vorgesehene
Treibertechnik.

Damit lassen sich problemlos mehrere hundert Meter Kabel mit hundert
Teilnehmern versorgen - sofern man mit der Baudrate in einem sinnvollen
Rahmen bleibt; 9600 ist kein Problem.

Du wirst Dir allerdings einige Gedanken um ein sinnvolles
Kommunikationsprotokoll der µCs mit dem PC ausdenken müssen - ein
Master-Slave-Protokoll mit Telegrammen definierter Länge und Pollen der
einzelnen Slaves löst Kollisionsprobleme.
Wenn es um Hausautomation geht, sind die Antwortzeiten ja nicht so
sonderlich kritisch (wer will eine Raumtemperatur binnen 3 ms
ändern?).
Statt das Rad neu zu erfinden, könntest Du Dich an einem bestehenden
Protokoll orientieren; da gibt's ja 'ne ganze Menge.


Derlei Verfahren werden in industrieller Gebäudeautomatisierungstechnik
eingesetzt und funktionieren dort ohne Probleme.

Also ich hab mir jetzt mal alle möglichen übertragungsarten angeschaut
und finde das can protokoll am interesantesten. Ich habe auch schon
viel hier im Forum zum lesen gefunden und ein wennig danach gegoogelt.
Leider habe ich eine grundlegende sache noch nicht verstanden...

Also ich Programmiere meine Atmels, welcher ist mir eigentlich für
dieses projekt egal, in Asambler. Wenn ich jetzt einen belibigen Atmel
nehme und diesen mit dem MCP 2515 verbinde (parallel?) kann ich dann
einfach ein byte an den MCP2515 schicken und der gibt das auf dem
canbus aus? warscheinlich nicht das währe bestimmt zu einfach.
Vieleicht würde mir ein beistpielqueltext mit kommentaren helfen,
leider habe ich noch keinen brauchbaren gefunden.

der mcp2515 wird per spi angeschlossen, sollte also schon ein avr sein,
der das in hardware hat.
ganz so einfach geht die ansteuerung leider nicht, sonst wäre das
datenblatt nicht 80 seiten stark :)
http://ww1.microchip.com/downloads/en/DeviceDoc/21801b.pdf

@Matthias
Schau Dir doch mal diese Seite an:
i2c rs485 Adapter
http://vodka.tky.hut.fi/~jap/Electronics/I2C-adapter/index.html
Und allgemein:
http://zebra.tky.hut.fi/~jap/Electronics/

Könnte für diese Aufgaben eine Alternative zum CAN Bus sein.
Stellt quasi einen verlängerten I2C Bus dar.

Ich hab für mein nächstes projekt ( sowas wie eine Alarmanlage )
mich für diese Variante entschieden.
Kann aber noch nicht sagen obs funktioniert
Die Hardware ist noch im Bau.

Ich meine das bietet einige Vorteile.
Hardware kosten praktisch null.
i2c ist in den Megas per Hardware ansprechbar.
Sternförmiger RS485 Verkabelung ist über die i2c kopplung möglich.
Nicht alle Busteilnehmer müssen mit einem uC ausgestattet sein- I2C
Bauteile können einfach so an den Bus gekoppelt werden.
Das i2c protokoll ist einfach und Librarys sind verfügbar.

Könnt ihr mir vieleicht auch noch helfen etwas zu finden.

Ich brauche im endefeckt zwei Knoten und eine RS232 Anbindung für den
PC. Vieleicht noch ein PC Programm was dann die Daten auf dem Bus Logt.

Möglichst so das ich nur noch die Platinen ätzen muss und die Bauteile
anlöten. Dann könnte ich anhand dieser relativ einfachen schaltung
bestimmt ganz leicht erkennen wie das ganze funktioniert. Leider habe
ich bisher nur recht komplizierte Schaltungen gefunden mit jeder menge
Schnickschnackt...

Habe ich das auch richtig verstanden das man über den Can bus die
Atmels Programmieren kann, also grob ausgedrückt ich schicke das
kompilierte *.hex file über den RS232 Anbinder in den CanBus, mit
zieladresse natürlich, und der rest ist schon alles fertig?