|
Anzeige
|
Das Ding mit den Bussystemen
Gast
#6424326
Moin. Ich bin neu dabei was Bussysteme angeht. Da gibt es ja dutzende Protokolle. Wie sieht das in der Praxis eigentlich aus, muss man dabei genau wissen wie die alle Funktionieren oder sagt man tatsächlich einfach "Ah hierfür benutzt man I2C und hierfür CAN" und wendet dann einfach Methoden aus Libs an? MFG Beides richtig, würde ich sagen. Wenn man weiß wie die Busse funktionieren, kann man auch leicht sagen, wann welcher Bus sinn macht. Selber programmieren tut das am Ende wohl kaum jemand, da werden üblicherweise fertige Bibliotheken verwendet. Stefan L. schrieb: > Selber programmieren tut das am Ende wohl kaum jemand, da werden > üblicherweise fertige Bibliotheken verwendet. Üblicherweise werden dafür zuallererst fertige Module in den Controllern verwendet. Denn beim I²C und beim SPI könnte man sich noch noch mit Herumzerren an den Portpins behelfen, aber zumindest der SPI wird dadurch nicht schnell. Und man kann während der Übertragung nichts anderes tun. Und wenn ein µC keinen CAN hat, dann programmiert man den sich nicht so einfach her. Sondern man muss extern einen Baustein anschließen, der mit einem Bus angesteuert wird, den der µC hat. Hallo23467 schrieb: > "Ah hierfür benutzt man I2C und hierfür CAN" Im Groben läuft das so, Ja. Aber das kann man nur aus dem Bauch heraus entscheiden, wenn mann einen groben Überblick der Bussysteme hat. Und dafür muss man nicht "genau wissen wie die alle Funktionieren" sondern zumindest wie auf Konzeptebene funktionieren. Das Bussystem ergibt sich aber eigentlich aus den Anforderungen heraus und nicht umgekehrt. Ist alles auf einer Platine, oder verteilt, welche Geschwindigkeiten werden gefordert und dann vor allem: Welche fertig kaufbaren Komponenten gibt es für deinen Anwendungsfall. Ach und falls Hobby: Gibt es fertige, frei verfügbare Bibliotheken dafür.
Gast
#6424383
Wenn nicht das Projekt zwingend den Bus vorschreibt, (z.b. durch eine Zusatzplatine entscheidet) muss man eine Kosten/Nutzenanalyse machen. Klingt schlimmer als es ist. Ich weiß das z.b. für meine Projekte ein ARDUINO ausreicht. Also schaue ich welche Bussysteme der Prozessor (ATMEL) kann. Beim Arduino sind es 2. Also einfach die passende Libs ziehen, für 90% aller Hardware gibt es eine. Installieren bzw. einbinden, und das war es. Lass dich nicht von den Experden verwirren. Libs sind dafür da, Zeit zu sparen und solange sie in den Speicher des Chip passen, nutze Sie. Du hast immerhin den ganzen Speicher bezahlt. ;) Bei einen anderen Projekt kann es sein das die Entscheidung anders ausfällt. Ein Arduino ist weder ein Allheilmittel noch der schnellste auf diesen Planeten. ;) Aber 1.50 Euro als fertige Platine mit Usb-Anschluss und Co. soll erst mal ein anderer bringen ;) Grundsätzlich gilt. Eine gute Planung spart Geld, Zeit und vor allen Dingen nerven. Hallo23467 schrieb: > Moin. Ich bin neu dabei was Bussysteme angeht. Du meinst wohl Feldbusse. Dann sag das auch. Es gibt nämlich auch eine ganze Menge Bussysteme, die keine Feldbusse sind. > Da gibt es ja dutzende Protokolle. Wie sieht das in der Praxis > eigentlich aus, muss man dabei genau wissen wie die alle Funktionieren > oder sagt man tatsächlich einfach "Ah hierfür benutzt man I2C und > hierfür CAN" und wendet dann einfach Methoden aus Libs an? Du meine Güte, hier geht ja alles durcheinander. Die Auswahl eines geeigneten Feldbusses. Protokolle. Und dann noch Software. Verschiedene Feldbusse haben verschiedene Eigenschaften. Und sind deswegen auch jeweils für verschiedene Aufgabenstellungen besser bzw. überhaupt geeignet. Man muß die Eigenschaften kennen und seine Anforderungen, um eine Auswahl zu treffen. Ein Bus ist in erster Linie erstmal Hardware. Wenn dein Controller kein CAN Interface hat, dann kannst du offensichtlich auch keinen CAN-Bus damit betreiben. Damit hast du jetzt schon die zweite Einschränkung bei deiner Auswahl. Die Software schließlich implementiert in der Tat das (bzw. ein) Protokoll für den Bus. Für kompliziertere Sachen wie CAN oder LIN wird man bevorzugt auf eine fertige Library setzen. Für einfaches Zeug wie I²C braucht man das eher nicht. Da ist das Protokoll (wenn man es denn so nennen will) im wesentlichen spezifisch für das Gerät am anderen Ende. Merkmale, anhand derer sich Bussysteme unterscheiden lassen sind parallel vs seriell: werden mehrere Datenleitungen benutzt oder werden Bits nacheinander übertragen? Differentiell oder Single-Ended? Werden zur Datenübertragung 2 Leitungen verwendet und der Empfänger misst die Spannung zwischen diesen 2 Leitungen oder ist es nur Leitung, die gegen GND gemessen wird? Full-Duplex, Halb-Duplex? Kann gleichzeitig empfangen und gesendet werden oder immer nur abwechseln? Master-Slave, Multi-Master? Erfolgt der Schreibzugriff auf den Bus nur auf Befehl von einer zentralen Stelle (Master-Slave) oder haben Busteilnehmer selbst die Möglichkeit, auf den Bus zu schreiben? Das sind so die ganz großen Unterschiede. Zur Einordnung eines neuen Bus ist es immer hilfreich, diese Kategorisierung zu machen, weil damit auch wesentliche Eigenschaften des Bus gerklärt sind. Parallel braucht mehr Leitungen. Weil alle Signale gleichzeitig am Ziel sein müssen gibt es Probleme bei längeren Strecken und oder höheren Geschwindigkeiten. Differentiell hat einen viel höheren Störabstand als Single Ended. Für Full-Duplex braucht man mehrere Leitungen oder spezielle Tricks, um das mit einer Leitung zu machen. Für Halb-Duplex irgendeine Koordination des Zugriffs. Wenn ein Bus Multi-Master ist braucht er irgendwelche Mechanismen, um Kollisionen zu behandeln. (wenn zufällig 2 gleichzeitig anfangen zu senden).
Gast
#6424419
Axel S. schrieb: > Du meine Güte, hier geht ja alles durcheinander. Die Auswahl eines > geeigneten Feldbusses. Protokolle. Und dann noch Software. Nur so als Tipp: Du schreibst das Selbe wie alle Anderen, nur mit ekelhafter Attitüde. Dein Post wiederholt die vor dir, deinen hättest du dir komplett sparen können. Aber du musstet natürlich etwas dazu schreiben und damit es irgendwie anders klingt noch mit dieser Art und Weise. Bringt nix. MFG. Noch eine Unterscheidung wäre synchron vs. asynchron Bei synchron gibt es eine Taktleitung, die ansagt wann neue Daten da sind oder auf den Bus gelegt werden müssen, z.B. beim Parallel-Port, bei GPIB, I2C, SPI. Asynchron gibt es keinen Takt, der Sender legt die Bits nacheinander auf die Leitung und es gibt ein einzuhaltendes Timing. (RS232, RS485, CAN, LIN)
Gast
#6424445
@Tilo Ja genau. So ist es. Das muss man natürlich alles bedenken, nur wird man ja sicher Libs dazu nutzen und das Protokoll nicht neu schreiben. JEder Chef würde ja am Rad drehen, wenn man pausenlos das Rad neu erfindet. Hallo23467 schrieb: > @Tilo > > Ja genau. So ist es. Das muss man natürlich alles bedenken, nur wird man > ja sicher Libs dazu nutzen und das Protokoll nicht neu schreiben. JEder > Chef würde ja am Rad drehen, wenn man pausenlos das Rad neu erfindet. Ja, aber das sind ganz unterschiedliche Ebenen! Der Bus, also wie er elektrisch funktioniert, welches Zugriffsverfahren benutzt wird, alle Unterscheidungsmerkmale von oben, sind es, die bestimmen wofür sich ein Bus eignet. (Lange/Kurze Entfernung, schnell/langsam...) Wenn man dann tatsächlich einen bestimmten Bus benutzen will, braucht man die notwendige Hardware, die an die Leitung angeschlossen werden kann. Das sind z.B. Leitungstreiber und -Empfänger, bei RS485 braucht man einen Treiber, der die 2 differentiellen Signalleitungen mit ordentlich Spannung treibt und einen Empfänger, der aus der Differenzspannung wieder ein digitales Signal macht. Hardware ist aber auch oft in Silizium gegossene Logik. Ein UART bei seriellen Protokollen kümmert sich um das getaktete Rausschieben und Einlesen von Bits. Ein CAN-Controller kümmert sich um den Buszugriff, mögliche Kollisionen und prüft die Checksumme. Damit man von der Software aus die Hardware benutzen kann verwendet man dann oft Bibliotheken. Bei einfacheren Protokollen ist es manchmal so, dass nicht zwingend eine Bibliothek notwendig ist. SPI z.B. ist technisch so simpel, dass man auch direkt die Register Schreiben/Lesen kann, über die die Hardware angesteuert wird.
Gast
#6424525
Tilo R. schrieb: > Ja, aber das sind ganz unterschiedliche Ebenen! Eben. In der Praxis: 1. Wofür brauche ich den Bus? --> Was kommt in Frage? 2a Hat meine Hardware davon schon irgendwas an Bord? Falls nicht: Was brauche ich zusätzlich, kann ich es in Software machen? 2b Gibt es dafür fertige Bibliotheken? Und dann kommt das abwägen der Vor- und Nachteile, letztlich eine Entscheidung. Und natürlich wird man auch berücksichtigen, womit man bereits Erfahrungen hat und was an dieser Stelle üblicherweise verwendet wird. Es gibt hier im Forum etliche Beispiele, wo jemand einen ungeeigneten Bus verwendet hat und sich vom Forum dann Hilfe versprochen hat. Jüngstes Beispiel im Forum war imho, wo jemand mit I2C Daten über 15 Meter übertragen hat und dann Störungen bekam, sobald ein Motor eingeschaltet wurde. Tja, Frage 1! Wenn du noch unsicher bist, klassifiziere halt mal die üblichen Verdächtigen.
Gast
#6424617
Eigentlich läuft es anders herum. Man bekommt eine Aufgabe (oder möchte etwas machen) und überlegt sich, was man kennt (z.B. Tasten, Display) und was man nicht kennt (100 Byte jede Sekunde zwischen 5 Geräten austauschen, 1MB-EEprom anschließen). Und dann schaut man halt beim Auftraggeber oder bei ähnlichen Projekten, wie die das machen. Und wenn es damit Problem gibt, schaut man, was es sonst noch so gibt. Wer (auf dem PCB) ein SO-8 EEPROM mit 1MB anschließen will, oder einen Lagesensor, der findet als Schnittstelle quasi nur I2C und SPI. Der Fragt sich nicht, ob CAN, RS232 oder Ethernet nicht auch gehen. Wenn I2C (um beim Beispiel zu bleiben) ausreicht, dann nimmt man das. Oder SPI. Wenn man 4 ICs braucht und die Adressierung noch passt, und Portpins knap sind, nimmt man I2C, wenn man mehr Geschwindigkeit braucht, SPI. Das alles aber im Vorfeld, bevor man das erste Layout macht. Sich busse einfach mal so anschauen, ist wie Klavierspielen auf einem Keyboard ohne Strom. Ja, mit Erfahrung OK, ohne Erfahrung eher nutzlos. A. S. schrieb: > Sich busse einfach mal so anschauen, ist wie Klavierspielen auf einem > Keyboard ohne Strom. Ja, mit Erfahrung OK, ohne Erfahrung eher nutzlos. Das sehe ich anders. Ich denke SPI, I2C, RS232, RS485 und CAN sollte man sich schon mal grob angeschaut haben. Wenn man dann mal irgendwas anderem begegnet kann man das vergleichend einordnen. SPI und I2C werfe ich dabei mal in einen Topf (der Unterschied ja hauptsächlich die zusätzliche Adressierung und Leitungszahl). Single-Ended, kleine Pegel. Am Besten auf einer Platine bleiben, definitiv keine großen Strecken. RS232 hat viel höhere Pegel und geht deswegen weiter. Und hat nur 2 Kommunikationspartner. Es gibt aber auch RS232 mit kleinen Pegeln, kann praktisch sein. RS485 hat differentielle Pegel, ist noch störsicherer, kann ggf. mehr Teilnehmer, man muss sich aber um den Buszugriff kümmern. CAN hat auch differentielle Pegel, legt aber auch das Buszugriffsverfahren und die Kodierung fest. Und semantisch diskutiert man dann nicht mehr über Sender und Empfänger sondern über Botschaften die auf den Bus gelegt werden. (Imho ein wichtiger, oft nicht verstandener Punkt) Finde es immer witzig: Der Bus, der gar nicht genannt wird, der am häufigsten verwendet wird und von dem die wenigstens Ahnung haben wie er funktioniert: USB
Gast
#6424788
Timo N. schrieb: > Finde es immer witzig: Der Bus, der gar nicht genannt wird, der am > häufigsten verwendet wird und von dem die wenigstens Ahnung haben wie er > funktioniert: USB Ja schon :) Bei USB läuft i.d.R. fast alles über Libs und Frameworks. Nur Freaks oder Idioten (oder beides) meinen immer wieder, man kann das doch vieel besser als der uC Hersteller oder die Zulieferer implementieren. Tilo R. schrieb: > Ich denke SPI, I2C, RS232, RS485 und CAN sollte man sich schon mal grob > angeschaut haben. Wenn man dann mal irgendwas anderem begegnet kann man > das vergleichend einordnen. Stimme dem zu, wobei ich für RS232/485 folgende Unterteilung machen würde: Zuerst die Grundlage: UART Dann die physikalische Ebene: RS232 RS422 RS485 / (HART) Dann das Protokoll: Profibus, Modbus, etc. Die etablierten Bussysteme geben eigentlich immer das Protokoll und die physikalische Ebene vor.
Gast
#6425789
WerWieWas schrieb: > Bei USB läuft i.d.R. fast alles über Libs und Frameworks. Wobei der Niklas G hier einen tollen Artikel samt C++ Beispiel dazu verfasst hat. Und W.S. hat eine kompakte Implementierung in C geschrieben, die mir persönlich das "aha" (so geht das) Erlebnis brachte.
Gast
#6426086
Stefan ⛄ F. schrieb: > Wobei der Niklas G hier einen tollen Artikel samt C++ Beispiel dazu > verfasst hat. Und W.S. hat eine kompakte Implementierung in C > geschrieben, die mir persönlich das "aha" (so geht das) Erlebnis > brachte. Das ist schon für diejenigen, die das dann auch so genau wissen wollen. Den meisten reicht es wahrscheinlich einfach zu wissen, wie das ganze grob funktioniert (Endpoints etc.). Ist aber nur meine Meinung ;) Wenn ich mit der Grundeinstellung, jedes Subsystem, Betriebssystem usw. bis aufs letzte Bit verstehen zu wollen entwickeln würde, würde das Produkt vermutlich in zig Jahren nicht fertig sein. Genau dafür wurden HALs entwickelt, genau deshalb gibt es Frameworks und Libs. Um immer wieder kehrende, oft auch normierte Vorgänge nicht jedes Mal neu implementieren zu müssen. Hallo23467 schrieb: > oder sagt man tatsächlich einfach "Ah hierfür benutzt man I2C und > hierfür CAN" und wendet dann einfach Methoden aus Libs an? noch ein Bus ohne I2C ohne CAN https://de.wikipedia.org/wiki/Europe_Card_Bus#
Gast
#6426240
Schlaumaier schrieb: > Also einfach die passende Libs ziehen, für 90% aller Hardware gibt es > eine. Installieren bzw. einbinden, und das war es. Lass dich nicht von > den Experden verwirren. Libs sind dafür da, Zeit zu sparen und solange > sie in den Speicher des Chip passen, nutze Sie. Hmm, merkwürdig, bei 50% meiner Projekte kann ich die Libs nicht so verwenden, sie kollidieren mit Ressourcenbelegung, lassen sich nicht simultan mit anderen verwenden, oder sind schlicht umfangreicher als benötigt. Nur Mal ein Beispiel: ATmega328 bedient LCD Glas, das erzwingt alle 2ms einen Interrupt der nicht zeitverschoben werden darf. Dazu muss man aber sekündlich ein DS18S20 (OneWire) oder TSIC306 (Zacwire) auslesen, deren Auslesevorgang länger als 2ms benôtigt. Da ist ganz schnell Ende mit vorgefertigten Libs. Die sind eher für Laien. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
