Moin! Mein Projekt sieht vor, dass ein Atmega8, nennen wir ihn mal "Master" Steuerbefehle an und Rückmeldungen von mehreren weiteren Atmegen (Plural von Atmega?) sendet und empfängt. Was ist da sie schlaueste/ sicherste/ professionellste Art der Realisierung? Meine Vorstellung: an die UART des Masters kommt nen Mux. Bin über spannendere Lösung dankbar!
am einfachsten irgendein Bus-System, z.Bsp. RS485 -> Fertig!
Schlau wäre es, wenn Senden und Empfangen an und von mehreren Clients ein Feature sein soll, nicht auf den UART zusetzen, sondern gleich eine busfähige Schnittstelle zu nehmen. - gerd
Bei der Aufgabenbeschreibung würd mir noch LIN einfallen.
Das waren jetzt alle Schnittstellen auf einmal. Welche bietet denn den höchsten Bedienkomfort bzw geringsten Programmieraufwand wenn es darum geht, Telegramme zu versenden?
Das "beste" wirst du nicht finden. RS-485 oder LIN gehen sowieso nur mit externen Bustreibern, CAN im Prinzip auch (wenn du nicht gerade die CAN-fähigen Controller in Betracht ziehst). SPI ist Mist, wenn man einen Controller als Slave hat, da der Slave keine Möglichkeit hat, dem Master zuzurufen: "Kleinen Moment, bitte!". TWI hat diese Möglichkeit, dafür ist es ein passiv gepullter Bus, was die Störsicherheit ein wenig runterdrückt und vor allem die Datenrate. Für 1-wire trifft das alles auch noch zu, außerdem gibt's dafür keine Hardwareunterstützung im Controller.
Prickelnd. Ich hätte nichts gegen weitere Bustreiber, wie sie für den vielzitierten RS485 nötig wären. Doch braucht man für 1 RS485 doch auch 1 UART, oder nicht?
Du brauchst für RS485, CAN und LIN einen UART. je nach Geschwindigkeit kann man ja auch nen Software UART implementieren. Ist halt die Frage was die Controller sonst noch so machen sollen.
Du kannst antürlich auch UART verwenden und dort ein Softwareprotokoll drüberpacken. Ob da aber der Aufwand-Nutzen Faktor gegeben ist bleibt offen.
Benötigte Datenrate? Anzahl Busteilnehmer? Zu überbrückende Distanz? Geforderte Zuverlässigkeit? Geforderte Latenz? Wie soll das Übertragungsverhalten aus Sicht der Controller aussehen? Senden die z.B. oft und kleine Pakete oder grosse, lange Übertragungen oder ...
Es geht nicht um Leben und Tod und auch nicht um explosionsgefährdete Bohrplattformen. Und richtig eilig ist das auch nicht. (Modelluboot) Datenrate: mittel Busteilnehmer: ca. 5 Entfernung: max. 1m Zuverlässigkeit: ahap (auch Egogründe)
Größenwahnsinniges Atmega Makro- Netzwerk <> Busteilnehmer: ca. 5 ;-)
Für Modellbau würde ich I2C nehmen. Keine weiteren Komponenten, damit klein und billig.
Joa das dachte ich mir auch grad ;) aber da würd ich denke auch zu i2c greifen.
... Datenrate: mittel ... Da empfehle ich etwas moderates an Silizium einzusetzen.
Hab schon etwas mit IIC- Porterweiterungen gespielt, aber wie läuft denn das, einen Atmega als Slave einzusetzen?
Hallo Vielleicht ist sowas wie Token Ring eine Alternative. Txd an RXD des nächsten, dann wider TXD davon an RXD des übernächsten bis der Ring geschlossen ist. Gruß JJ
Hört sich gut an. Abei bei Kabelbruch ist Holland in Not!
Bei 5 Megas kann man auch die RS232 der einzelnen Teilnehmer noch parallel schalten. Einer hat die Führung. Alle anderen halten die Klappe und reden nur noch Aufforderung. Den einen, der die Führung hat, kann man ja KaLeun nennen.
Hallo Wenn ein Kabel bricht, ist wahrscheinlich bei jedem Bussystem Holland mehr oder weniger in Not. Ich kenne es auch nur, weil ich weiß, das an einem Packet-Radio Knoten die TNC mit Token Ring verbunden sind. Ist einfach zu realisieren, jeder kann an jeden senden. Nagut, jeder sieht alles und muß erstmal schauen, ob es ihn betrifft, oder ob es nur weiterzuleiten ist. Und ich schätze, das in einem Modell-Uboot nicht wirklich viel zu tun ist für die ATmegas, die machen das weiterleiten so nebenher. Gruß JJ
...auf einem Uboot nicht viel zu tun? Wenn Du wüsstest. RS232 parallel schalten find ich interessant, ich mag RS232. Aber geht das so einfach?
Wie viele Maaten ließen sich denn an einen Kaleun anhängen?
Stephan R. schrieb: > ...auf einem Uboot nicht viel zu tun? Wenn Du wüsstest. Kann es sein, dass du deine Megas masslos unterschätzt? > RS232 parallel schalten find ich interessant, ich mag RS232. Aber geht > das so einfach? Einfach so parallel geht natürlich nicht. Das Tx vom KaLeun geht an alle Rx der niederen Ränge. Die Tx der niederen Ränge gehen über eine UND Schaltung auf das Rx vom KaLeun, TTL-RS232 vorausgesetzt. Jeder der anderen muss ja die Möglichkeit haben, die Leitung vom Ruhezustand (1) auf 0 runterzuziehen. Wenn du jedem Teilnehmer einen MAX232 spendierst, dann wird aus dem UND ein wired-OR (Ruhepegel ist ja dann -12V und die Teilnehmer ziehen diese beim Senden auf +12V) Was machen deine Megas eigentlich, dass du gleich 5 Stück dafür brauchst?
ich nehme die RS232-Version in der beschriebenen Variante auch für alle möglichen Vernetzungen ums Haus. Problem ist aber, dass der Slave nicht von sich aus Meldungen an den Master senden kann. Die Pollingrate des Masters bestimmt, wie schnell der Slave sein wichtiges Anliegen an den Master senden kann. Notlösung wäre eine /INT-Leitung pro Slave zum Master. Da wird es aber schon wieder Fummelei... Uwe
7 Drucksensore, 12 Temperaturfühler, 6 Magnetventile, 2 Antriebsmotore, 2 Verbrennungsmotore (mit je 1 Glühkerze, 1 Startermotor, 1 Kühlwassermotor, 6 Temperaturfühler, 2 Geschwindigkeitsmesser, 1 Magnetkupplung, 1 DC- Generator), 2 Kompressore, 1 Tiefenpeilsonar, 2 Distanzsensore, GPS, GSM, LWL, ISM, 4 Akkuüberwachungen, 1 Raumlufttrockner, 1 Raumluftumwälzung, 1 Kompasssensor, 2 Inklinometer, 4 Getriebemotore + Lagerückmeldung, 1 Mikrowellensensor, Kamerabildübertragung und Speicherung mit einem Atmega?
Im AIRBUS bildet man für sowas verschiedene LAN-Segmente... ;-)
LWL = Lichtwellenleiter? Wenn ja, (nur aus Neugier) was überträgst du damit innerhalb des U-Boots? - gerd
Nix. Wegen der Innerhalbdesbootsübertragung habe ich ja diesen Threat gestartet. LWL kommt zum Einsatz, wenn das Böötlein in der salzigen Ostsee baden geht, wo Funk nicht tief genug hineinreicht.
Bis auf das Kamerabild: Gähn, und wie verhinderst du dass den Megas langweilig wird? Ach ich vergass: du vernetzt sie ja. Da können sie ja dann was übers Netzwerk spielen :-) PS: Die schiere Anzahl an Sensoren soll dich nicht beeindrucken. Schieberegister als Port-Erweiterungen sind schon erfunden. Wichtiger als die Anzahl an Sensoren und Aktuatoren ist: wie schauts mit dem Timing aus? Ein einzelner Mega kann deine Sensoren mit links ein paar tausend mal in der Sekunde abfragen. Und da bleibt dann immer noch jede Menge Rechenzeit übrig. Warum ich das aufs Tapet bringe: Weil die Dinge selten einfacher werden, wenn man mehrere Prozessoren auf ein Problem ansetzt. Durch die notwenige Kommunikation verkompliziert es sich oft.
Für den Notfall ist die Zolllast immer voller Bier und Kartenspiele liegen unterm Bock. Ich hab mir schon gedacht dass es vielleicht mit weniger Bauteileinsatz geht, aber ich finde es aufgeräumter: In der Mitte die Zentrale, die alles managt; hinten bei den Motoren eine eigene Box, in der ein Atmel sich ganz in Ruhe um seine Motore kümmern kann... Das hält - so meine Vorstellung- auch die Programme der jeweiligen Atmegas übersichtlicher und ich kann weitgehend auf Porterweiterungen verzichten.
> 2 Kompressore, 1 Tiefenpeilsonar, 2 Distanzsensore, GPS, GSM, LWL, ISM,
LOL
Da der ex VP so ein VIP ist, sollten wir die PK wegen der PR auf dem WC
und nicht im TV machen. Dann sagt die MP zum KGB LMAA!
(Good Morning Vietnam)
Ich habe kürzlich von meinem abkackenden Atmega geschrieben, der immer dann stehen blieb, wenn am Stecker gewackelt wird. Lieber, nur EIN Atmega bleibt stehen.
Hallo, Habe mich jahrelang mit Feldbus-Systemen beschäftigt. Bei diesen Anforderungen liegst Du nahe am modernen KFZ. Ob der AtMega das on Board hat oder nicht - der CAN - Bus ist das richtige für deine Wünsche. Er ist CDMA fähig (daher kann jeder mit jedem...) und hat außerdem Prio - Slots, so daß hochpriore Geber eben auch eher Ihre Nachrichten (meist kurz) weitergeben können. jemand anderer Ansicht ? Gruß, THaala
Stephan R. schrieb: > Mein Projekt sieht vor, dass ein Atmega8, nennen wir ihn mal "Master" > Steuerbefehle an und Rückmeldungen von mehreren weiteren Atmegen (Plural > von Atmega?) sendet und empfängt. > Was ist da sie schlaueste/ sicherste/ professionellste Art der > Realisierung? Schau Dir doch mal an, wie andere das machen: z.B. Automobilindustrie. Dort wird für die einfachen und langsamen Geschichten LIN verwendet (weil billig), und für die schnellen CAN. Zuverlässig & millionenfach erprobt. Wenn Du was anderes nimmst, musst Du schon verdammt gute Gründe haben. Ein guter LIN-Slave ist der Tiny167, der ist nämlich für sowas gedacht. Für CAN nimmst Du entweder einen 90CANxxx oder einen Mega64C1 oder Mega64M1, die letzteren haben auch LIN-Hardware drin. Für CAN und LIN brauchst Du immer externe Transceiver-Chips - das hat Fertigungsgründe. Wenn Du unbedingt DIL-Gehäuse haben willst, schau Dich bei Microchip um - die haben in der Richtung mehr Auswahl, und ein dsPIC ist auch nicht zu verachten. fchk
yepp CAN ist wohl der geeignete Bus zumal das Protokoll die Hierrchishe und die ereignetgesteuerte Kkommunikation ermöglicht. Wird in zwischen auch bei Aufzügen zum Standard. Und der nur nen paar Dutzend Taster und LED und eine Handvoll Sensoren und Antriebe. Vorteile: Störstolleranz durch Diffsignalübertragung hohe Übertragensrate, fehlererkennung und effektive Fehlerbearbeitung ..... http://techwww.in.tu-clausthal.de/site/Dokumentation/Standards/CAN-Bus/CAN-Bus.ppt MfG
> Für CAN und LIN brauchst Du immer externe Transceiver-Chips Falsch: http://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf Ist aber eher was für On-Board-Kommunikation. Externen Module die Aktoren wie z.B. E-Motoren antreiben würde ich so nicht verbinden (-> Masseversatz).
@ Thomas: Masseversatz? Und warum ist CAN etwas für On-board-communikation? Ich habe heute vom CAN-Bus geträumt, und zum Glück gibt es -soweit ich weiss- auch einen CANbusfähigen Controller von Atmel. Kennt sich jemand mit der Materie aus? Ist das ein reiner CAN-Controller oder ein üblicher, nur mit CAN?
Wenn Geld keine Rolle spielt kannst ein paar AT90CAN einsetzen und eine fertige CAN-Bibliothek verwenden. Siehe hier: http://www.kreatives-chaos.com/artikel/universelle-can-bibliothek Da bist halt für Controller + CAN-Bustreiber 10-12€ los aber dafür hast ne Kommunikation die sicher funktioniert.
wegen 5 Bausteinen? "Brain, was machen wir heute?" "Pinky!, das was wir jeden Abend machen." "Was denn, Brain?" "Wir werden versuchen die Weltherrschaft an uns zureißen!" so viel zu Größenwahnsinn....
Hi, off topic @Stephan R. könntest du mir mal bitte eine PM schicken, hätte da ein paar Fragen zur restlichen Hardware des Bootes. on topic Ich würde dir auch zu CAN raten. Schau mal bei Microchip, die haben fertige CAN-Bausteine und Bustreiber. Dann könntest du weiterhin deine Mega8 benutzen. So twisted pair kann man auch noch überall durchs Boot quetschen. Bei Microchip findest du sicher auch eine Beschreibung von CAN, über die Controller lässt sich ja streiten. Die Dokus von denen finde ich aber ziemlich gut. Democode gibts auch ;) Gruß Simon
> @ Thomas: Masseversatz? Ja, Masseversatz. > Und warum ist CAN etwas für On-board-communikation? Gemeint ist natürlich nur die verlinkte Lösung ohne Transceiver.
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.