Hallo, Hab da eine Projektidee von einem Künstler (Installation) bei der mehrere Module (uC STM32, Display, Taste) miteinander verbunden werden sollen. Die Module sind nicht weit auseinander, vielleicht max. einem Meter. Es sollen aber schon gut 50 Stück möglich sein. Beim Start des Systems soll eine Enumerierung stattfinden. Der Master numeriert die Module durch, damit jedes anhand seiner physischen Position in der Kette adressiert werden kann. Es soll eine vom Master gesteuerte Slideshow (640x480, evtl. JPEG) gesendet werden können. Allerdings kommen immer neue Bilde vom Master, weswegen eine Vorab-Speicherung in dem Modulen flach fällt. Der Master soll also überall einzeln Bilder "hochladen" können. Ich denke ein paar MBit/s wären also ganz gut. Jetzt dachte man schon daran, weil ja 2 SPIs pro uC vorhanden sind, ob man nicht einfach einen SPI für IN und einen weiteren für OUT nehmen soll und so die Kette bilden könnte. Klar, das dauert etwas bis ein Bild bis ganz hinten transferriert wird... muss ja auch nicht in Echtzeit sein, wenn es ein paar 100ms dauert, egal. Und als Verkabelung soll auch ein Standard genommen werden, damit es nicht zu teuer wird und man nicht jedes Kabel selbst löten muss. Aber SPI.. hatte eigentlich gleich an RS485 gedacht. Das braucht aber wieder extra Receiver/Transmitter pro Modul, wäre aber technisch wohl am saubersten (symmetrisch zusammen mit Ethernetkabel z.B.) Hat jemand alternative Vorschläge wie man sowas einfach lösen könnte?
:
Bearbeitet durch User
SPI sollte das PCB eigentlich nicht verlassen, daher ist die Idee, einen anderen Übertragungsstandard für die Verbindung der Module zu nehmen, schon richtig. Da du ohnehin vorhast, für die INs und OUTs separate Schnittstellen zu verwenden, ist RS485 in meinen Augen fast ein wenig überdimensioniert (das Multipoint-Feature wird bei dieser Art der Verkabelung nicht benötigt). Man könnte es mit RS232 versuchen oder sogar mit den 3V-USARTS der Controller (+ zusätzlichem Schirm), dann wären gar keine separaten Transceiver notwendig. MBit/s wirst du damit natürlich nicht erreichen, dafür ist es am einfachsten aufzubauen. Man bekommt halt nichts geschenkt ;)
Markus schrieb: > SPI sollte das PCB eigentlich nicht verlassen, SPI ist schon ok, das ist niederohmig. Du meinst wahrscheinlich I2C, das ist etwas anfälliger bei langen Leitungen.
Treiber irgendwelcher Art wirst du sowieso brauchen, also nimm doch gleich die für RS485, ist schon die richtige Wahl. Und die kosten auch kein Vermögen :-)
Warum nicht direkt Ethernet und als Controller Raspberrys oder ähnliches?
Bei RS485 kann man aber die physische Position nicht zum Enumerieren benutzen.
Stefanus F. schrieb: > Bei RS485 kann man aber die physische Position nicht zum Enumerieren > benutzen. Wenn man, wie von OP beschrieben, je einen Port für IN und OUT verwenden will, geht das auch. Wie schon gesagt, ich finde es aber überdimensioniert.
Danke schonmal für das rege Feedback: Ethernet müsste man wieder sternförmig verteilen. RPI mag ich in diesem Fall nicht, weil ewiges booten, SD Karten-Gefummel und riesen SW-Overhead. RS485 würde nicht im klassischen Sinne als Bus sndern nur jeweils Peer-to-Peer betrieben.
Also ich bin selber kein Freund der Raspberrys, aber ein Zero WH mit nem Buildroot basierten System bootet in 5 Sekunden, passt auf ne 64 MB Karte und per Wlan entfallen auch die Kabel... Achja, die SD Karten können nach dem Booten auch raus.
:
Bearbeitet durch User
Peter M. schrieb: > Klar, das dauert etwas bis ein Bild bis ganz hinten transferriert > wird... muss ja auch nicht in Echtzeit sein, wenn es ein paar 100ms > dauert, egal. 640x480 = 307200 pixel, 3 bytes (RGB) pro pixel ergibt dann fast 1MB. Wenn das in 1/10 Sekunde durchlaufen soll, brauchst du also schon 8 bis 10MB/s, oder halt irgendein komprimiertes Format - JPG, PNG...
Ja Eric, da hast du schon recht, das wird viel - unkomprimiert. Ich denke mal, daß die Bilder schon als JPEG oder PNG reinkommen und die STM32 die wir da nehmen werden, die schaffen das dann schon in nützlicher Zeit wieder zu dekomprimieren.
Bernd K. schrieb: > SPI ist schon ok, das ist niederohmig. Du meinst wahrscheinlich I2C, das > ist etwas anfälliger bei langen Leitungen. Es ist genau umgekehrt. I2C filtert die Eingänge mit einem Tiefpaß gegen schnelle Störflanken und ist daher unempfindlich gegen Leitungsreflexionen und Übersprechen.
Nimm doch CAN. CAN Bus ist im STM32 schon drin und kommt mit 50 nodes zurecht. Das CAN Protokoll kann mit Kollisionen umgehen, wenn mehrere Nodes gleichzeitig senden wollen. Du brauchst allerdings noch zusätzlich einen Transceiver Chip in jedem Node. CAN hat bis zu 300 MHz (http://www.bittiming.can-wiki.info) Wenn Du wirklich nur einen Sender und 50 Empfänger hast, dann kannst Du auch einige helle LEDs auf die Platinen leuchten lassen (IR oder sichtbares Licht) und jeden Knoten mit einem Photoempfänger ausstatten. So kommst Du auf wirklich hohe Übertragungsraten. See: https://de.wikipedia.org/wiki/Li-Fi Bleibt noch 10BASE2 Thin Ethernet. Das hat auch eine Ringtopologie, aber ich befürchte, das wird kaum noch unterstützt. Oh, oh, and DMX of course, but it may be to slow for sending jpegs. https://en.wikipedia.org/wiki/List_of_network_buses
:
Bearbeitet durch User
Danke an alle für die rege Beteiligung. SPI: Einen Tiefpass könnte man auch selber vor den SPI-Eingangspin bauen. I2C: Der High-Level wird bei I2C durch den Pull-Up-Widerstand erzeugt. So gesehen, ist nur der "L"-Zustand niederohmig, wohingenen "H" durch den Pull-Up-R definiert wird (z.B. mit 4,7k). Von daher finde ich den SPI fast besser, weil H/L => Push-Pull. Allerdings müsste man da die schnellen Flanken durch serielle Rs dämpfen, sonst "klingelt" das Signal schnell mal. Es bleibt aber ein asymmetrisches Signal. WLAN: bringt mir keine Enumerierung wenn neu aufgebaut wird. Beim Erweitern bzw. Umbau muss wieder was mit dem AP gekoppelt werden. Dann muss geschaut werden, welche IP ist jetzt wo. Zudem WLAN kann schon recht dicht sein am Austellungsort, da muss man evtl. die Kanalauslastung checken. Ja klar könnte man machen und würde schon funktioneren, aber seriell wäre doch einfacher und zuverlässiger. Zusammenstecken wäre jeder Zeit in beliebiger Reihenfolge möglich. N CAN hatte ich mir auch schon überlegt. Aber auch hier: wenn alle am Bus hängen, wie numeriere ich das durch. Wenn dann auch mit Peer-2-Peer CAN. Da gewinne ich nicht viel gegenüber UART/RS422 oder 485. Das mit dem LED-Prinzip ist noch interessant, nur bedingt das halt, daß alle Empfänger den Sender immer sehen kann. Das kann ich leider nicht garantieren, weil ich nicht weiss, wie der die Teile anordnen will (in welcher Form).
CAN ist gut, aber kann keine automatische Enumeration nach Verkabelungsreihenfolge. Wäre es denkbar, beim ersten Einschalten nach dem Auf-/Umbau die Kette abzulaufen und jeweils den Knopf drücken und so die Module manuell zu enumerieren und das im EEPROM speichern zu lassen?
Peter M. schrieb: > wenn alle am Bus hängen, wie numeriere ich das durch. Mit Kodierschaltern. https://www.conrad.de/de/kodierschalter-hexadezimal-0-9a-f-schaltpositionen-16-hartmann-hex-codierschalter-1-st-705462.html Die kannst du im Grunde genommen bei jeder Art von Bus zum festlegen der Adresse verwenden, auch bei Ethernet/WLAN. Ist es denn wirklich sinnvoll, sie automatisch fortlaufend durch zu nummerieren? Was ist, wenn ein Modul defekt ist, sollen sich dann alle Nummern um 1 verschieben?
Für diese Geschwindigkeit kommst du bei keinem System um Terminierung rum. Entweder lässt man was RS485 verwandtes p2p laufen und schaufelt intern die Daten oder Signale rüber oder man hat einen zweiten, langsamen Bus der die Teilnehmer bequem enumeriert und danach die Bildübertragung dem schnellen Bus überlässt. HDMI und VGA fahren z.B. ein I2C neben den Bilddaten her für einen ähnlichen Zweck (dort halt ohne Enumeration mehrerer Teilnehmer).
Ich denke auch, dass CAN hier das Mittel der Wahl ist. Und auf der Leiterplatte findet sich bestimmt noch ein Plätzchen für den Transceiver. Hast dir schon Gedanken über die Versorgung gemacht? Angenommen jedes Modul verbrät nur 1W, dann musst du 50W bereitstellen. Du musst also mit der Spannung hoch, wenn du nicht dicke Kabel zu den Modulen willst. Also muss auf jedes Modul noch ein Buck-Converter. Ich nehme an, das ganze soll dann irgendwie steckbar sein. Da wäre es ja schön, man könnte alles in einer Leitung führen und auf Standards zurück greifen wie zB Ethernet Patchkabel oder M8 oder M12 Verbinder. Für die Vergabe der Adressen wirst vermutlich noch ein Hilfssignal benötigen, über welches selektiert wird, welche Node gerade ihre Adresse bezieht.
was spricht denn dagegen, die 50 nummerierten Module in der richtigen Reihenfolge anzuklemmen? Ich würde die Daten entweder im Vorraus übertragen, diese müssten dann halt zwischengespeichert werden z.B. in einem http://www.microchip.com/wwwproducts/SST26WF080BA/documents Der Master muss dann nur ein Startsignal schicken bzw. das ganze synchronisieren. Aber das ist ne ganz schöne Materialschlacht.
Ist doch viel eleganter, wenn man sie einfach wahllos aus der Kiste nehmen und zusammenstecken kann, oder?
Da ganze soll halt möglichst "Idiotensicher" sein und wir wohl immer wieder aufgebaut und wieder zusammengesteckt, je nach Austellungsort wohl mit mehr oder weniger Modulen. wenn ein Modul defekt ist (oder einfach keins mehr kommt), dann muss das der Master erkennen und weitermelden (Debug Port oder Service Display) Der Master kann dann sagen, hey ich kann nur bis 10 adressieren, danach kommt nichts mehr. Dann weiss man gleich Modul an Stelle 11 (oder die Verbindung dorthin) wird defekt sein. >Hast dir schon Gedanken über die Versorgung gemacht? Ja ist auch so ein Thema. Die Ethernetkabel müsste man da wohl mit etwas mehr Spannung fahren. Soweit ich weiss geht da max 1A per Adernpaar und ich hätte nur 2 (485) bzw. 3 (CAN) davon frei.. >Ethernet Patchkabel oder M8 oder M12 Verbinder Die habe ich aber auch nur bis 0,34mm2 gesehen.. und mehr als 48V wollte ich eigentlich nicht einsetzen.
Weißt du schon was Konkreteres über die die zu erwartende Leistungsaufnahme pro Modul? Denn wenn du da grob daneben liegst kann passieren, dass das ganze Konzept für den A... ist
Schaltest du die Module alle hintereinander? Dann könntest du eine zusätzliche Adressierungs-Leitung zwischen den Modulen verlegen: (Master) Out -> In (Modul 1) Out -> In (Modul 2) Out -> ... Die Eingänge bekommen einen Pulldown und Schmitt-Trigger. Der Master sendet beim Einschalten eine Nachricht: "Wer jetzt eine steigende Flanke sieht ist Modul 1" und gibt einen Impuls am Ausgang. Modul 1 sieht die steigende Flanke, adressiert sich auf "1" und schaltet die Adressierungs Ein- und Ausgänge über ein kleines 74LVC1G08 zusammen. Weiter gehts: "Wer jetzt eine steigende Flanke sieht ist Modul 2", der Impuls rauscht durch das Und-Gatter an Modul 1 vorbei und Modul 2 kann sich adressieren. Durch die Logikgatter hat jeder Abschnitt Adressierungs-Leitung einen eigenen Treiber mit niedriger Laufzeit. Das kann man auch sehr elegant zum synchronisieren der Show nutzen, indem der Master darüber einen langsamen Takt verteilt. Für dieses Signal wäre es IMHO auch vertretbar auf spezielle Leitungstreiber zu verzichten.
Meine Idee: - RS422 vollduplex. Hier gibt es Sender und Empfänger, die locker 10 MBit/s Datenrate und mehr können. Bei so etwas ist ein AVR raus, da brauchst Du einen ARM oder MIPS (PIC32) mit DMA und geeigneten UARTs. Früher hätte man da Zilog ESCCs mit HDLC genommen, aber das ist ja inzwischen aus der Mode gekommen. Damit ist zumindest genug Bandbreite für irgendwelche Bitmaps etc vorhanden. PIC32 kann seine UARTs mit 20 MBit/s fahren, bei STM32 ist bei 4.5MHz Schluss. TIVA 4C geht bis 10 MHz. Du kannst Dir überlegen, ob Du nur Point2Point-Verbindungen zwischen Nachbarn haben willst (dann muss jeder Slave Nachrichten, die nicht für ihn gedacht sind, weiterrouten), oder ob Du tatsächlich einen physikalischen Bus willst. Ein physikalischer Bus ist in der Gesamtlänge und von der Anzahl der Knoten begrenzt (bei vielen CAN und RS422/485-Transceivern auf 32!). Bei P2P kannst Du einen Ring bilden und Pakete in beide Richtungen des Rings senden, hast aber auch immer Latenzen bei jedem Hop. - ConfigIn, ConfigOut Signal. In der Enumerationsphase sind alle Knoten passiv. ConfigOut jedes Moduls ist low. Der Master setzt sein ConfigOut, das mit dem ConfigIn des ersten Slaves verbunden ist, fragt Identifikationsdaten ab und setzt die Slaveadresse. Mit dem Setzen der Slaveadresse verlässt der erste Slave den Konfigurationsmodus und setzt sein ConfigOut. Nun wird der nächste Slave konfiguriert etc etc. Das Ende ist erreicht, wenn keine gültigen Konfigurationsdaten mehr empfangen werden, oder - in einem Ring - wenn das ConfigOut wieder beim Master zurückkommt. - Stromversorgung. 48V DC, Schaltregler in jedem Modul. 48V ist die höchste Gleichspannung, die noch als Sicherheitskleinspannung gilt, d.h. wo man noch ohne Berührschutz auskommt. Die Spannung willst Du so hoch wie möglich haben, um maximal viel Leistung darüber übertragen zu können. Daher arbeiten sowohl ISDN als auch PowerOverEthernet mit 48V. Bei halber Spannung (24V) bekommst Du nur noch ein Viertel der Leistung übertragen - das willst Du also nicht. - Verkabelungssystem. Hier würde ich auf etwas fertiges zurückgreifen. RJ45 wäre Preiswert, die 48V kämen dann extra noch dazu. fchk
Naja, beim CAN Bus kann zumindest jedes Modul eine eigene ID haben, so dass der Controller weiss, welche Module eingesteckt sind. Wenn Du dann sowieso Ethernet Patchkabel einsetzt, dann hast Du ja noch Adern frei. Eine davon kannst Du dann nutzen, um die Aufzählung über eine langsame 5V serielle Leitung durchzuführen. In etwa so: 1 ---+--- +48V ----... 2 ---+ 3 ------- CAN H ---... 4 ------- CAN L ---... 5 ------- ENUM TX ----- RX1 [MCU1] TX1 ---------- RX1 [MCU2] TX1 ------- etc. 6 ------- frei 7 ---+ 8 ---+--- 48V GND -... Der Hauptcontroller sendet per RS232 langsam (2400bps, da nur MCU VCC level und nicht differential) einen Wert an MCU1. Die empfängt diesen Wert und meldet ihn über den CAN Bus zurück an den Hauptcontroller, addiert 1, und sendet den neuen Wert an MCU2, usw. . Alles can per Patchkabel verbunden werden. Wenn die Leistung nicht für alle Module reicht, dann kann man weitere Netzteile mitten drin hineinschleifen, ohne den Aufbau zu stören. Mit einer geschickten Belegung der Ethernetstecker kann der Aufbauer sogar den Patchkabel Ein- und Ausgang verwechseln, ohne die Funktion zu stören.
Ich vermute mit 1W pro Modul kommen wir nicht hin. Mehr als 5W werden es aber sicher nicht. Daher gehe ich mal von total max. 250W aus, die verteilt werden müssen. Eine Kombination von Addressierleitung zusammen mit einem CAN Paar über simples JR54-Patchkabel und parallel noch eine dickere 2 Pol-Leitung für Spannungsversorgung. So könnte es wohl aussehen. Die Leitungen werden mit schwarzem Textilband eingewickelt. Das ist matt und da fällt es nicht auf ob eine oder zwei Leitungen drin stecken...
An sowas in der Art dachte ich auch. Nur ein klein bisschen abgewandelt. Alle Nodes haben nach Power On den Out auf Low. Der Master zieht seinen Out auf High und schickt die zu vergebende Adresse auf den Bus. Die Node mit High am Eingang (also die erste) übernimmt die Adresse und 'merkt' sich, dass sie konfiguriert wurde. Dann zieht sie ihren Ausgang auf High und der Master vergibt die nächste Adresse. Usw... Logik in der Node: Siehst du am Eingang High und bist noch nicht konfiguriert, übernehme die empfangene Adresse, setze dich selbst auf konfiguriert und ziehe deinen Ausgang auf High. Zum Thema Power: Ein AWG23 Patchkabel hat ca 0,25 qmm pro Ader. Das macht ca 70mOhm/m. Also 140mOhm für hin und rückweg. Wären bei 1A grad mal 140mW im Kabel. Nimmt man je ein Adernpaar, dann halbiert sich sogar der Wert. Wenn ich mich nicht verrechnet habe, dann sollte das unkritisch sein
Was bringt denn hier CAN? Gar nichts. Datenrate deutlich geringer, heftiger overhead, nur kleine Datenpakete. Und den Riesenvorteil (kollisionsfreier Multimasterbetrieb) brauchst du hier gar nicht. Und bei 50m schaffst du nicht mal mehr 1Mbit. Automatische Adressierung in der Reihenfolge der phys. Anordnung geht auch nicht von alleine. Eine zusätzliche Leitung die von Modul zu Modul geht, kann das Adressierungsproblem lösen und vom master können Adressen zugewiesen werden.
Das Problem bei der Stromversorgung ist halt, wenn ich alles in einer Kette anordne, dann mus das erste Kabel den maximalen Strom an alle Module tragen... Deswegen und weil das eben "schöner" ist, ohne zusätzliches Power Supply dazwischen, würde ich recht ordentliches Zweipol-Kabel mit 48V nehmen. Dann hab ich halt vier Stecker pro Modul: 2x 2Pol (Norm weiss ich noch nicht) und 2x RJ54. Das wäre soweit OK.
H.Joachim, ja die 1m zwischen den Modulen ist nur ein Maximalwert. Der baut auch welche direkt nebeneinander. Allerdings kann das ganze Gebilde schon eine einige Meter Schlange sein. also doch eher wie Anfangs gedacht... RS422/485
H.Joachim S. schrieb: > Was bringt denn hier CAN? Du hast schon recht. Aber was schlägst du vor? Ethernet wäre gut. Aber dann brauchst bei einer Ringtopo noch auf jeder Node nen Switch. SPI, I2C ist auch nicht grad ideal wegen Störanfälligkeit. Wegen Power: Es gibt auch Kombistecker.. Aber sowas ist vermutlich nicht günstig und die Kabel musst sicher selbst konfektionieren
Peter M. schrieb: > ja die 1m zwischen den Modulen ist nur ein Maximalwert Und würdest du dann auch kürzere Verbindungskabel nutzen, wenn die direkt nebeneinander stehen? Also eine grosse Kiste mit verschieden langen patchkabeln für alle Eventualitäten?
Peter M. schrieb: > Da ganze soll halt möglichst "Idiotensicher" sein und wir wohl immer > wieder aufgebaut und wieder zusammengesteckt, je nach Austellungsort > wohl mit mehr oder weniger Modulen. Think simple. Du kennst die Störungen nicht die in dein System reinfunken. Bei 50 m baust du 2 Netze auf, eines davon ist das Störungsnetz. Was spricht gegen Ethernet (evtl. mit Poe) und eine logische statt physikalische Adressierung? Schnell genug, störsicher, etablierte Protokolle und günstig Kabel und Komponenten gibt es auch überall vor Ort (das hat mir schon oft den Ar... gerettet). De Schnittstelle im Notebook ist auch schon da. Wenn du die Adresse nicht mit Filzstift, Aufkleber oder Port Steckplatz festlegen willst wird bei der Inbetriebnahme halt ein Bild mit der Adresse angezeigt und du ordnest das kurz zu. Bei 50 Empfängern ist das flott gemacht, geht sogar mittels Vlan.
Schlumpf schrieb: > Aber was schlägst du vor? RS485. Bei 50m funktioniert das auch mit Telefonkabel (RJ11 oder RJ12 mit Flachkabel) Oder mal das uralte 10BASE2 wieder reaktivieren :-)
>Und würdest du dann auch kürzere Verbindungskabel nutzen, wenn die direkt nebeneinander stehen? Ja sicher so kurz wie möglich. Geht ja auch um die Optik :D Mehr als 10m wird die Geschichte auch bei 50 St. nie. >Du kennst die Störungen nicht die in dein System reinfunken. Ja, RFI/EMV liegen mir bei derm Vorhaben eh schon im Magen. >Was spricht gegen Ethernet Solange ich es nicht sternförmig machen muss, also am ersten Modul 50 Kabel entlangführen muss... An Ethernet dachte ich auch schon, da die STM32 das ja eh schon drin haben (bis auf PHY) und mit in den in die Buchsen eingebauten Übertragern halt super galvanisch entkoppelt, das wäre schon was nur müsste ich bei der Anordnung auch wieder zwei ETH-Schnittstellen pro Modul haben...
>10BASE2
Das gute alte 10BASE2 und der Augenblick wenn man wiedermal beim Räumen
ein duzend BNC T-Stücke findet und denkt... ja, so ging LAN damals als
ich jung war :D
:
Bearbeitet durch User
H.Joachim S. schrieb: > RS485. Na ja, so richtig toll ist das aber auch nicht. Regulär auch nur 32 Nodes möglich und die Datenrate knickt dir auch gehörig weg mit der Leitungslänge... hmm Du meinst, dann sowas wie Modbus zusammenstricken? Könnte klappen.
Wenn RS485, dann nicht als Bus, sondern peer-2-peer zwischen den Modulen. UARTS sind ja genug vorhanden in den Controllern. Klar gibts dann Delay durch jeden Node, aber wenn man die Transfers klein segmentiert...
:
Bearbeitet durch User
Moin, Peter M. schrieb: > das wäre schon was nur > müsste ich bei der Anordnung auch wieder zwei ETH-Schnittstellen pro > Modul haben... Dann nimm halt statt dem simplen PHY jeweils einen kleinen 3-Port-Switch; z.B. sowas wie den KSZ8873. Gruss WK
Peter M. schrieb: > Klar gibts > dann Delay durch jeden Node, aber wenn man die Transfers klein > segmentiert werden... könnte man evtl über DMA lösen. Man darf halt nicht vergessen, dass der µC noch so ganz nebenbei ein Video abspielen und eventuell sogar dekomprimieren soll. Wenn er dann noch ständig von der UART zugeschissen wird, könnte das echt eng werden. Angesichts des Aufwands und der Kosten, die in dem Projekt vergraben werden, würde ich glaub zu Ethernet tendieren. Nen externen 3-Port-Switch neben den STM setzen (ca 4 Euro) und dann bekommt der µC nur das, was auch für ihn bestimmt ist und ist nicht damit beschäftigt, Daten von A nach B zu schaufeln. Ich hätte echt ein bisschen Schiss, hier hunderte (oder tausende) von Euro in ein Projekt zu versenken, wo alles auf Kante genäht ist. Dann lieber noch 200 Euro mehr ausgeben und Reserven haben. Aber das ist nur so ein Gefühl..
WK, interessante Alternative. 2 Eth-Ports und ein MII welches ich direkt an den STM32 legen kann. Und da 10/100 Eth nur zwei Paare braucht, wäre noch Platz für eine Enumerierungsleitung über die Patch-Kabel.
Angehängte Dateien:
-
RS485_TI.PNG
46 KB
Schlumpf schrieb: > Na ja, so richtig toll ist das aber auch nicht. Naja, man muss ja nicht bei den Urschleim-SN75irgendwas bleiben....
Leute, find ich echt super das Brainstorming hier. Es muss kein Video abgespielt werden. Latenz ist nicht das Killer-Thema. ich teile aber Schlumpfs Gefühl "lieber noch 200 Euro mehr ausgeben und Reserven haben". Wenn ich "denen" das Konzept vorstelle und die sagen, jo das machen wir, dann sind +/-200€ für ein Exponat Schnuppe. Wird eh schon teuer genug. Naja, ich sag nur "Fördergelder" :D
H.Joachim S. schrieb: > Naja, man muss ja nicht bei den Urschleim-SN75irgendwas bleiben.... Stimmt schon.. aber ich hab ja oben geschrieben, was ich machen würde. Selbst die 40 MBit/s knicken vermutlich bei langen Leitungen ein. Peter M. schrieb: > 2 Eth-Ports und ein MII welches ich direkt > an den STM32 legen kann. korrekt Peter M. schrieb: > Und da 10/100 Eth nur zwei Paare braucht, wäre > noch Platz für eine Enumerierungsleitung über die Patch-Kabel. Wäre eventuell nicht mal nötig. Bei Ethernet kann man wahrscheinlich sogar die physikalische Topologie über die Switches rekonstruieren. Weiß da jemand was drüber? Was Kabel angeht: Industriekabel sind idR recht teuer. Aber vielleicht mal bei den Bühnentechnikern schauen. Vielleicht gibt es da ja was. Die haben ja auch das Problem, dass Daten und Power kreuz und quer verteilt werden müssen. Vielleicht gibt es da ja was Passendes, wo Ethernet und Power in einem Kabel übertragen werden kann
Moin, Peter M. schrieb: > Und da 10/100 Eth nur zwei Paare braucht, wäre > noch Platz für eine Enumerierungsleitung über die Patch-Kabel. Naja, also egal ob Ethernet, RS-irgendwas, CAN oder CAN-doch-nicht oder noch was anderes: Ich glaub', dass das ganze Ding rein softwaremaessig ziemlich viele ganz dicke Bretter zu bohren beinhaltet. Wahrscheinlich noch viel dicker und mehr, als du momentan glaubst. Von daher wuerd' ich da keine extra Leitung ziehen, sondern Enumerierung eben rein per Software ueber Ethernet machen. Der Vorteil bei Ethernet ist, dass es fast fuer jeden Furz schon ein fertig ausgepatschtes, dokumentiertes (RFC) und irgendwo schon eingesetztes Protokoll gibt. Der Nachteil: Du musst's halt finden. Gruss WK
:
Bearbeitet durch User
Matthias M. schrieb: > CAN hat bis zu 300 MHz (http://www.bittiming.can-wiki.info) Habe ich das überlesen, oder ist das wirklich niemandem aufgefallen? Nein, CAN geht nicht bis 300MHz, auf der Seite von dem Link werden die Parameter für die CAN-Unit aus dem Takt der CAN-Unit abgeleitet. Also was man einstellen muss wenn man die Unit mit 300MHz taktet und zum Beispiel 1MBit haben möchte. Normales CAN geht bis 1MBit und kann dabei bis 8 Byte Pakete haben. Das neuere CAN-FD geht wohl bis 10MBit, üblich sind aber 2MBit und die meisten Transceiver gehen auch offiziell bestenfalls bis 5MBit. Und die Pakete können bis 64 Byte groß sein. Dafür müsste der unbekannte Typ STM32 aber CAN-FD unterstützen und das können soweit nur die H7 (und irgendwelche L-Typen die im Zusammenhang mit einem Display eher nicht relevant sein sollten). In 5 Jahren oder so nimmt man für sowas vielleicht Automotive Ethernet. :-) 10Base-T1s oder wir das heissen soll, ist kein Punkt-zu-Punkt mehr.
>softwaremaessig ziemlich viele ganz dicke Bretter
:D jaja, das stimmt schon. Dicke Bretter wie diese zu bohren ist
allerdings mein Tagesgeschäft seit >15 Jahren. Projekte über alle 7 OSI
Layer und noch eigene low-level Treiber - alles schon gemacht. Aber man
muss ja nicht jedes Rad neu erfinden.
IP/Ethernet gefällt mir prinzipell recht gut, da einiges an Erfahrung
vorhanden.
Die Plus-Punkte wären
+ wenig EMV-Ärger
+ Traffic Routing
+ Standardkomponenten
+ Reihenschaltung durch Mini-Switch pro Modul möglich
Rudolph: ja STM32H7 (die lowcost 750er) könnten es werden.
:
Bearbeitet durch User
Guter Punkt - der Softwareaufwand wurde noch gar nicht betrachtet. Und der dürfte bei kaufmännischer Betrachtung ganz schnell die Hardwarekosten in der Bedeutungslosigkeit versinken lassen. Die Frage ist also auch: was kannst du? Und was kannst du in welcher Zeit leisten? Es soll schon Projekte gegeben haben, die am Kosten- und/oder Zeitrahmen gescheitert sind, obwohl der Ansatz an sich korrekt war.
Peter M. schrieb: > Leute, find ich echt super das Brainstorming hier. ich auch :-) Du kannst ja auch mal schauen, ob es ein Derivat des STM32 mit integriertem Switch gibt.
>Es soll schon Projekte gegeben haben, die am Kosten- >und/oder Zeitrahmen gescheitert sind, obwohl der Ansatz an sich korrekt >war. Wohl wahr, wohl wahr. Die Gefahr sehe ich durchaus. Muss mir gut überlegen, welches Konzept ich denen vorlege. >was kannst du? Einiges. Habe lange (>10Jahre) Automotive Networks entwickelt. Viel LIN, CAN, MOST. (MOST wäre auch noch was, wenn es nicht so speziell und teuer für kleine Stückzahlen wäre. Zudem ist es halt eine Ring-Topolgie).
Moin, Schlumpf schrieb: > Du kannst ja auch mal schauen, ob es ein Derivat des STM32 mit > integriertem Switch gibt. Kann man natuerlich machen, aber wenns das tatsaechlich geben sollte, dann brauchst du jeweils noch 2 PHYs... Gruss WK
>ob es ein Derivat des STM32 mit > integriertem Switch gibt. hab ich noch keinen gesehen. Und ja, es bräuchte auch nochn zwei PHYs. Daher ist der KSZ8873 schon recht passend.
Dazu passend 2 Stück von https://www.digikey.de/product-detail/de/wiznet/J1B1211CCD/1278-1052-ND/7604176 1,30 / Stück
mikeselectricstuff hat sowas mit iPod Displays realisiert (YouTube). Über den Bus berichtet er auch.
> welchen Bus nehmen?
Ethernet 100BaseT!
24 - 48 Port Switches gibts für 1€/Port.
ID anhand der MAC.
Display ans (Banana, Orange, Rasp)-berry stecken und fertig ist die
Hardware.
H.Joachim S. schrieb: > Was bringt denn hier CAN? Gar nichts. Datenrate deutlich geringer, > heftiger overhead, nur kleine Datenpakete. Der Overhead ist aber nur im Controller. Von der Software her ist CAN so ziemlich das einfachste, was es gibt. Und man darf beliebig viele Datenpakete hintereinander senden. Die Nutzdatenrate ist allerdings nur 500kBit, CAN-FD geht etwas höher. Eine hohe Datenrate ist aber auch nicht nötig. Mit einem SPI-Flash kann man bequem auf jedem Modul 64MB zwischenspeichern und dann über eine einfache Scriptsprache Bildsequenzen synchron ausgeben lassen.
CAN hat auch den Vorteil, dass man Übertragungsfehler erkennt und einzelne Nodes ohne Polling auch Fehler zurück melden können. Ob die Geschwindigkeit reicht hängt wirklich sehr von der Anwendung ab. Dazu haben wir einfach nicht genug Details.
SoC Rulez! schrieb: >> welchen Bus nehmen? > > Ethernet 100BaseT! > > 24 - 48 Port Switches gibts für 1€/Port. > > ID anhand der MAC. > > Display ans (Banana, Orange, Rasp)-berry stecken und fertig ist die > Hardware. und stromversorgung über poe.
CAN ist sicher in der engeren Auswahl. Die 500kBit währen wohl zuwenig, daher CAN-FD. Bei Ethernet müsste ich halt die ganzen oberen Layer mit reinziehen. Da wäre CAN in der Tat simpler, zumal das ja ein geschlossenes System ist, auf das keiner von Aussen drauf muss. Die MCU ST32H7 hat zwei CAN-FD on-chip, würde ich also schon anbieten. Als Verkabelung RJ54 / Patchkabel.
> Ethernet 100BaseT! > > 24 - 48 Port Switches gibts für 1€/Port. Fällt aus, wegen Stern-Topologie. Das soll eben gerade eine Art Endgespeiste Schlange bilden, ohne das jedes Modul eine eigene Leitung zu einem Switch bekommt. Steuerteil(Master) liegt irgendwo in einer Schwarzen Kiste ab Boden und ab dort gehts los mit einem möglichst dünnen Kabel (z.B. Ein dickeres Adernpaar für die 48V DC und CAT6)
würde das auch über Eth mit POE machen ggf einen STM32 mit LCD dran die können auch recht fix JPEGs decodieren und das ganze ist gut erweiterbar oder für andere dinge verwendbar ^^ der SW aufwand hält sich in grenzen
>ggf einen STM32 mit LCD dran
Genau das wäre die Idee. Ein STM32H750 (billig-version mit nur 128k
Flash).
Es gäbe zwar kleine IP-Stacks, aber CAN wäre halt genügsamer von der SW
Seite her.
Matthias M. hat da schon weiter oben einen praktischen Vorschlag für die
Belegung des RJ54 mit CAN und Enumerierungsleitung gemacht.
:
Bearbeitet durch User
CAN-FD - ja, das würde gehen. Höhere Datenrate an sich im Datenbereich und vor allem grössere Pakete. Und wenn das dein angedachter Controller schon unterstützt - umso besser. Allzuviele gibts noch nicht mit FD.
Peter M. schrieb: > Bei Ethernet müsste ich halt die ganzen oberen Layer mit reinziehen. Wieso? Was du innerhalb des Frames zwischen Source-MAC-Address und FCS machst, interessiert weder den PHY noch den Switch (MAC-Switch) noch den MAC-Controller. Das kannst du komplett mit einem prorietären Protokoll deiner Wahl "befüllen". Du nutzt einfach nur die unteren Layer. Die Vorteile der Physik zur Übertragung und die des MAC zum Switchen. Peter M. schrieb: > Da > wäre CAN in der Tat simpler, zumal das ja ein geschlossenes System ist, > auf das keiner von Aussen drauf muss. Ist dein System ja auch. Der Master und die Slaves sind ein geschlossenes System. Die Sprache, die die gemeinsam sprechen, kannst du selbst erfinden. Und dann wird der Aufwand nicht mehr als bei CAN. Eventuell sogar geringer, da du deine Nachrichten nicht so klein segmentieren musst, wie bei CAN. In nen MAC-Frame passen immerhin ca 1500 Byte rein.
Ich würde einfach per Cube MX das LwIP RTOS Beispiel nehmen Dann die socketAPI und fertig der salat Jpegdec lieb zur Dekompression Du wartest einfach auf eine eingehende Verbindung mit einem Bild Auf der master Seite kannst du wunderbar einen PC nehmen die die Bilder pro Modul reinläd Einfach eine TCP Verbindung aufbauen und Bild Reinschießen , fertig. Das sind in Summe 20-40 Zeile Code die man selbst schreiben müsste Der Rest ist quasi Out of the Box aus dem Cube MX
>Was du innerhalb des Frames zwischen Source-MAC-Address und FCS >machst, interessiert weder den PHY noch den Switch (MAC-Switch) noch den >MAC-Controller. Ja, ist ein Argument. Und wenn die FCS am Schluss nicht stimmt, dann muss ich halt schauen, dass ich das letzte Frame nochmal bekomme. Wäre jetzt auch nicht wild so ein Handshake-System zu bauen. Eth-Switch-Baustein (2 Port) zieht 90mA (~0,3W @3,3V) De CAN MCP2562fd zieht auch max. 45mA, und davon zwei je Modul Es kommt also aufs Selbe raus hinsichtlich Stromverbrauch. EDIT: CubeMX machts einem echt leicht, das stimmt. Find ich eh genial was ST da alles an Tools und Proof-Of-Concept Sachen liefert.
:
Bearbeitet durch User
Moin, Peter M. schrieb: > Und wenn die FCS am Schluss nicht stimmt, dann > muss ich halt schauen, dass ich das letzte Frame nochmal bekomme. Wäre > jetzt auch nicht wild so ein Handshake-System zu bauen. Genau das ist der springende Punkt, den seh' ich anders. Wenn du eben statt IP irgendwas selberdengelst, was auf Ethernet aufsetzt, dann musst du dich um diesen ganzen Shice selber kuemmern: Selber spezifizieren, coden, testen, debuggen. Nimmst du die ueblichen "hoeheren" Protokolle (TCP, TFTP, ...), dann sieht das jetzt fuer dich so aus, als haettest du einen Mordsoverhead. Aber ich glaub' eben, dass dieser Mordsoverhead noch viel mordsmaessiger wird, wenn du dir da irgendwelche Protokolle selberzusammenzimmerst, bis das nur halbwegs funktioniert. Klar brauchst du wahrscheinlich mehr RAM/Flash/externe Libraries als mit der handgedengelten Loesung. Aber's wird wohl schneller oder ueberhaupt fertig. Gruss WK
>statt IP irgendwas selberdengeln, Selber spezifizieren, coden, testen, >debuggen.
Alles schonmal gemacht. Schreckt mich jetzt nicht umbedingt ab.
Aber klar, wenns was Fertiges gibt und es in die 128kB passt... ich muss
es nicht haben.
Die Fehler/Retransmit-Sache könnte ich mir mit CAN sparen. Da ist
Auto-retransmit schon in der Hardware drin.
Dergute W. schrieb: > Genau das ist der springende Punkt, den seh' ich anders. Wenn du eben > statt IP irgendwas selberdengelst, was auf Ethernet aufsetzt, dann musst > du dich um diesen ganzen Shice selber kuemmern: Selber spezifizieren, > coden, testen, debuggen. Nimmst du die ueblichen "hoeheren" Protokolle > (TCP, TFTP, ...), dann sieht das jetzt fuer dich so aus, als haettest du > einen Mordsoverhead. > Aber ich glaub' eben, dass dieser Mordsoverhead noch viel mordsmaessiger > wird, wenn du dir da irgendwelche Protokolle selberzusammenzimmerst, bis > das nur halbwegs funktioniert. > Klar brauchst du wahrscheinlich mehr RAM/Flash/externe Libraries als mit > der handgedengelten Loesung. Aber's wird wohl schneller oder ueberhaupt > fertig. deswegen das bsp mit dem RTOS lwip das schöne ist .. der macht den ganzen bufferkram alles für dich. socket(),bind(), accept() , recv() mehr brauchst du fast nicht .. und der kram landet da wo du es willst vorteil bei echter IP lösung ist das man das ganze auch im nachhinein beliebig erweitern könnte ... allein deswegen lohnt der aufwand das so zu machen
> Eth-Switch-Baustein (2 Port) zieht 90mA (~0,3W @3,3V) > De CAN MCP2562fd zieht auch max. 45mA, und davon zwei je Modul > > Es kommt also aufs Selbe raus hinsichtlich Stromverbrauch. Öh, nö, Du brauchst ja nur einen CAN Transceiver je Modul. Um die Sternform und auch das aktive durchleiten im Ethernet zu vermeiden könntest Du Taps bauen, so wie hier: https://www.instructables.com/id/Ethernet-Tap/ Dann schickt der Host halt blind UDP Pakete in der Gegend rum, und die einzelnen Clients greifen sich die Pakete mit der passenden MAC. Am Ende der Linie ist dann wohl noch irgendein Abschluss nötig. Und wieviele passive Taps so eine Leitung verträgt, weiss ich nicht. Vielleicht geht's ja tatsächlich mit zwei von diesen: https://www.digikey.de/product-detail/de/wiznet/J1B1211CCD/1278-1052-ND/7604176 und einem kleinen Verstärker dazwischen, also ohne switch. Ich denke, DU brauchst nen Testaufbau und eine sehr gute Abschätzung der nötigen Datenrate.
:
Bearbeitet durch User
Ich denke, dass es recht übersichtlich ist, da selbst was zu schreiben. Aber klar, es ist allemal mehr Arbeit, als was Fertiges zu nehmen. Vorallem ist es sicher auch von Vorteil, wenn man so ne Kiste mal auch einfach an den PC stecken kann, um z.B. ein Firmwareupdate zu machen oder paar Statusinformationen abzufragen, etc. Noch ne Idee: Könnte man sich die Tatsache, dass der Switch gemanaged ist zu nutze machen, um die Topologie zu scannen? Die Module lauschen nach Power On alle nur auf ihrem masterseitigem Port. Der Port zum Nachfolger ist blockiert (muss der Switch können). Dann kommt ein Broadcast mit der Aufforderung, auf den geantwortet wird, WENN die Node noch nicht konfiguriert wurde. Danach schaltet die Node den Porz zum Nachfolger frei. Somit könnte man recht einfach rausfinden, in welcher Reihenfolge die MAC Adressen in der Kette hängen.
>Öh, nö, Du brauchst ja nur ein CAN Modul. Wenn ich CAN länger machen will (eben wirklich die 50m mit 50 Teilnehmern) dann würde ich es wohl mit Peer-2-Peer CAN-FD machen und bräuchte dann eben zwei CAN-Treiber pro Modul. >RTOS lwip, ja kenn ich, läuft auch sauber Bitraten: Damit das brauchbar ist, sehe ich mind. 5 MBit/s. >DU brauchst nen Testaufbau Ja klar, das brauch ich eh. Muss mal das STM32H743I-EVAL, NUCLEO-H743ZI rauskramen und mir den Footprint von der IP-Lösung anschauen.
>Könnte man sich die Tatsache, dass der Switch gemanaged ist zu nutze >machen, um die Topologie zu scannen? An sowas dachte ich auch, da ich es vom MOST Bus her so kenne: Dort sendet der Master (0x400) als erstes Licht in den nächsten Slave im Ring. Der wacht auf, Initialisiert sich und erhöht den Node Position Counter (0+1, physical addr. 0x401). Er leuchtet weiter zum nächsten Node, gibt den Counter weiter. Der macht das selbe (1+1, 0x402) usw. Am Ende des Rings kommt wieder der Master, der gleich weiss, wieviele Nodes da sind, wieviel Delay der Ring hat usw.
So wäre es natürlich auch möglich... Allerdings muss der letzte dann erkennen, dass er der letzte ist. Aber das könnte er über den Link-Status des PHY für den Nachfolger raus finden.
>Link-Status des PHY für den Nachfolger raus finden.
Ja genau. Einfach einen Timeout laufen lassen nach der Link-Aktivierung
und wenn da nach x Sekunden nichts kommt auf dem Secondary Port kommt
bzw. der Link tot ist, dann ist das Ende der Schlange erreicht. Der
Master wird dann mit einer simplen Nachricht informiert, da is nix mehr,
ich bin der Letzte.
Peter M. schrieb: > Einfach einen Timeout laufen lassen nach der Link-Aktivierung > und wenn da nach x Sekunden nichts kommt Klingt simpel. Allerdings bekommst du bei dieser Methode nicht so ohne weiteres mit, welche MAC Adressen die Geräte haben. Und die benötigst du aber. Aber du könntest natürlich statt der Node-Positionen aufsteigende MAC Adressen vergeben. Ob das schlau ist, gerade, wenn man die Geräte mal an nen PC steckt, sei mal dahin gestellt. Vielleicht doch besser, die MAC einmalig vergeben und dann über die von mir genannte Methode abfragen und eben gar keine weitere Node ID vergeben, sondern einfach über die MAC Adressen arbeiten.
Für 50 Stück würde ich keine so komplexe Entwicklung ohne Betriebssystem machen. Klar das geht, aber warum willst Du dir das antun? Mein Vorschlag nimm irgend so einen Mini-Linux-Computer, ak. Raspi, und Pack den über kaskadierte Switches an deinen Zentralrechner. Dann hast du an jeder Stelle maximal 5 Netzwerkkabel, da gibt es ja mittlerweile ziemlich dünne. Booten kannst Du übers Netzwerk. Wenn ich dich richtig verstehe, willst Du eine geografische Adressierung, also der einzelne Knoten soll wissen wo er sich im Netzwerk befindet. Das finde ich auch eine gute Idee, weil DU Knoten ohne irgendwelche Konfiguration einfach tauschen kannst. Wenn ich das richtig sehe, sollte sich das mit der VLAN Funktion eines managed Switch realisieren lassen. Der ZyXEL GS1200-5HP könnte passen. Falls du unbedingt nur ein LAN Kabel haben willst, dann kannst Du ja jeden Knoten mit einem USB-Ethernet-Dongle versehen. Und dein Netzwerk so durchschleifen. Für die Stromversorgung lässt sich ja eine kleine Adapterplatine mit DC/DC Wandler für jeden Knoten stricken, evtl. kannst Du ja auch die POE Signalauskopplung auf der Platine vorsehen.
nimm doch einfach billige android tabelts vom chinaman da ist alles drin was du brahcst flash ram nen display und wlan. Du baust ein Wlannetz mit einem Webserver auf. Auf diesen connecten sich die Tablets nach einanader und bekommen so eine ID zugewiesen. Danach rufen alle tabelts eine Webseite auf die für ihre id generiert wird und darauf kannst du anzeigen was du möchtest. Tuchbuttons gibts dann auch. Wenn man Hardwarebuttens braucht spendierst du denen einen stm32F7 oder so mit ethernet der sich auch am webserver anmeldet
Ja klar, man kann auch was mit fertigteilen "basteln", aber ist hier etwas speziell. 4:3 Tablets gibts nicht. Zudem soll das auch einfach einen Schalter haben: AN und es geht in 5 Sekunden los. nicht noch jedes Tablet in 3m Höhe manuell einschalten usw.
Peter M. schrieb: > Das mit dem LED-Prinzip ist noch interessant, nur bedingt das halt, daß > alle Empfänger den Sender immer sehen kann. Das kann ich leider nicht > garantieren, weil ich nicht weiss, wie der die Teile anordnen will (in > welcher Form). Wieso? Vielleicht wäre es ja möglich zwischen die einzelnen Module eine Glasfaser zu verlegen. dann wäre die Räumlich Anordnung egal. Jedes Module bekommt ein Eingang ein Ausgang für das nächste und die Installation wird als Daisychain betrieben.
imonbln schrieb: > Vielleicht wäre es ja möglich zwischen die einzelnen Module eine > Glasfaser zu verlegen. dann wäre die Räumlich Anordnung egal. Jedes > Module bekommt ein Eingang ein Ausgang für das nächste und die > Installation wird als Daisychain betrieben. Da würde sich ja dann 100Base-FX förmlich aufdrängen... Wobei wir dann wieder beim Ethernet wären... Nur halt in teuer über POF :)
Peter M. schrieb: > Wenn ich CAN länger machen will (eben wirklich die 50m mit 50 > Teilnehmern) dann würde ich es wohl mit Peer-2-Peer CAN-FD machen und > bräuchte dann eben zwei CAN-Treiber pro Modul. Dann brauchst Du aber auch einen 2. CAN-Controller im MC. Und die SW muß jedes Paket von der einen Seite auf der anderen weiter senden. Ein Repeater nur alle 10, 20 oder 25 Slaves sollte reichen.
Frank K. schrieb: > PIC32 kann seine UARTs mit 20 MBit/s fahren, bei STM32 ist bei 4.5MHz > Schluss. TIVA 4C geht bis 10 MHz. Aus dem RM0410 (STM32F76xxx, STM32F77xxx):
1 | USART main features |
2 | • Configurable oversampling method by 16 or 8 to give flexibility |
3 | between speed and clock tolerance |
4 | • A common programmable transmit and receive baud rate of up to |
5 | 27 Mbit/s when USART clock source is the system clock frequency |
6 | (Max is 216 MHz) and the oversampling by 8 is used |
Die F76xxx haben acht UARTs, damit könnte man einen Hub bauen, der z.B. 5 Ketten mit je 10 Modulen betreibt. Man kann also 5 Bilder gleichzeitig senden. Vor allem braucht man nur 1/5 des Stroms auf den Kabeln. Leider ist dann die Verbindung Master->Hub der Flaschenhals, aber auf der gleichen Platine geht das schon. Evt. kann es ja auch der Master übernehmen. Ich würde immer Treiber-ICs spendieren, egal, ob RS422 oder CAN oder oder. Die sind ESD-mässig doch etwas robuster.
>2. CAN-Controller im MC Ist beim ST32H7 vorhanden >Ein Repeater Das wäre halt unpraktisch, weil dann muss der Aufbauer immer mitüberlegen, wo mach ich nen Repeater. Und denen trau ich zu, dass die das 100% irgendwie verbocken. >Ich würde immer Treiber-ICs spendieren Da hast du recht, direkt Pins des uC auf nen Bus halten -> schlechte Idee.
:
Bearbeitet durch User
Peter M. schrieb: >>2. CAN-Controller im MC > > Ist beim ST32H7 vorhanden Dann kann man das so machen. Die Bandbreite verringert sich ja nicht dadurch. Und der 2. Transceiver ist ja kein Kostenfaktor. Wir leiten auch immer +24V mit über das Kabel und ein TSR 1-2450 macht dann 5V/1A daraus. CAN hat den Charme, daß man es Bare-Metal verwenden kann. Es läuft auch schon ohne jeden Softwareoverhead stabil. Bei UDP muß man sich dagegen um Datenverluste selber kümmern. Und TCP/IP hat richtig viel Overhead.
Ethernet kann man auch ganz rudimentär betreiben. Wenn man das tut, dann muss man sich in der Tat um Datenverluste kümmern. Aber das kann man auch auf einer recht tiefen Ebene ohne großen Protokolloverhead machen. So wie man es eben auch machen würde, wenn man die Bilder per SPI oder I²C übertragen würde. Wie ich bereits geschrieben habe, muss man ja nicht zwingend UDP oder TCP/IP verwenden. Schlumpf schrieb: > Was du innerhalb des Frames zwischen Source-MAC-Address und FCS > machst, interessiert weder den PHY noch den Switch (MAC-Switch) noch den > MAC-Controller. Bei CAN sind nur ca 60% der Bandbreite für Nutzdaten verfügbar. Bei Ethernet sind es 99% Bei Ethernet stehen mir also effektiv 99MBit/s zur Verfügung (unter optimaler Ausnutzung des Frames) Durch die Switche kann ich ohne Belastung der Nodes jede Node erreichen. Bei CAN muss ich endtweder ein großes Netz aufbauen (dann geht die Bandbreite runter) oder jede Node hat zwei CAN-Ports und dann muss jede Node jeden Frame kopieren... Also ich würde definitiv zu Ethernet tendieren. Und wenn einem der ganze Overhead mit TCP/IP zu viel ist, dann erfindet man eben sein eigenes Protokoll. Angesichts der nötigen Funktionalität halte ich das für eine leichte Übung.
Erinnert mich ein bischen an ein System welches bei der Bahn eingesetzt wurde. Jeder Wagen hat für Durchsagen ein lokalen Bus und ein Zugbusmodem mit eine 2 Drahtleitung an jede Kupplung. Alle Wagons sind also über diese Zugbusmodem verbunden. Aktiviert man eine Fahrerstand als master föngt das Zugbusmodem an beiden Kupplungen an serielle Daten zu senden und sucht dort nach Wagons. Meldet sich einer wird er nummeriert und bekommt den befehl seine leitung von Kupplung A nach B zu schließen. Der Master pollt nun durch den ersten Wagen duch zum zweiten Wagen. Meldet sich dierer wird er nummeriert und schließt sein Kabelverbindung an die freie Kupplung. Das geht solange weiter wie Wagons angekuppelt sind und beim letzten dann ein Timeout passiert. Der letzte terminiert dann das Kabel und der Master macht an seiner anderen Kupplung das gleiche ... könnte ja sein er sitzt nicht am Ende. Zum Schluß gibt es einen durchgängigen Bus und der Master kann jeden einzelnen Slave addressieren oder broadcast Daten senden.
Ich hab das mal rechnerisch überschlagen, wie sich das mit CAN gestalten würde Annahme: Bild mit je 8Bit RGB macht bei der Auflösung ca 1MByte pro Bild. Komprimierung lassen wir bei der Betrachtung mal außen vor. Ein CAN-Frame besteht aus ca 14 Byte. Davon sind 8 Byte Datenfeld. Es müssen also 1MByte irgendwie in diese 8Byte-Häppchen gequetscht werden. Und dass da nix durcheinander kommt mit den Häppchen, sollten sie eine ID bekommen, welches der vielen Häppchen gerade übertragen wird. Wenn man das ausrechnet, dann stellt man fest, dass einem nur noch 5 Byte für die Daten übrig bleiben. 3 Byte werden benötigt, um diese 200.000 Häppchen zu numerieren. Effektiv hat mal also noch 5Byte Nutzdaten in einem 14Byte großen CAN-Frame Das sind ca 30% Also bleibt mir von der Datenrate des CAN nur 1/3 der Datenrate effektiv übrig. bei 1MBit/s wären das noch ca 0,3MBit/s. Nun teilen wir noch durch 8 weil wir ja in Bytes gerechnet haben und erhalten dann 0,04MByte/s. Jetzt stopfen wir das Bild in diese Highspeed-Verbindung: 1MByte / 0.04MByte/s = 25s Ein Bild benötigt also 25s bis es ankommt. Bis also nach Power On alle Bilder geladen sind, vergehen über 20min. Dein Kunde wird dir vor Glück um den Hals fallen und du wirst bei der Inbetriebnahme wahnsinnig :-) Und hier ist ja nur die reine Übertragungsdauer betrachtet!! Bei CAN-FD sieht es schon besser aus.. Hier sind bis zu 64 Byte möglich. Davon sind dann nach Abzug des Counters für die Segmente noch 62 Byte übrig. Unter der Annahme, dass der Overhead ähnlich ist, wie bei CAN, haben wir eine Ausnutzung der Bandbreite von ca 85% Bei 10MBit/s bleiben also ca 8,5MBit/s was ca 1MByte/s entspricht. Damit wäre das Bild dann in 1s durch. Alle Bilder zu laden dauert aber immer noch ne knappe Minute. Wie sieht es bei 100Base-TX aus? 1500Byte Datenfeld im Frame vs 18Byte overhead = nahezu 100% Bandbreite, die zur Verfügung steht. 100MBit/s = 12MByt/s => 80ms/Bild => 4s für alle 50 Bilder. Nehmen wir an, dass du während der Entwicklungsphase und Testphase das System 500mal Starten wirst. Dann bist bei CAN 250 Stunden mit Warten beschäftigt Bei CAN-FD immerhin auch noch 8h bei Ethernet ist es ne halbe Stunde. In der gesparten Zeit kannst du dir ganz locker Gedanken über ein "Bare-MAC"-Protokoll inklusive Datensicherung und allem Pipapo machen :-) Wenn ich das bauen müsste, wäre für mich der Fall klar, für welchen Weg ich mich entscheiden würde... [Ich habe bei den Berechnungen natürlich oft ingenieursmäßig überschlagen. Aber falls ich irgendwo nen groben Fehler drin habe, korrigiert mich bitte]
Moin, Bauform B. schrieb: > Die F76xxx haben acht UARTs, damit könnte man einen Hub bauen, der z.B. > 5 Ketten mit je 10 Modulen betreibt. Yay! Endlich Switch-Software selber entwickeln koennen/duerfen/muessen. Wie waer's mit Leistungs I2C, statt UARTs? Ich stell mir da jeweils 2x 'nen 2N3055 vor, der auf 12Ohm 50Watt Pullup-Widerstaenden gegen 24V arbeitet ;-) SCNR, WK
Dergute W. schrieb: > Wie waer's mit Leistungs I2C, statt UARTs? > Ich stell mir da jeweils 2x 'nen 2N3055 vor, der auf 12Ohm 50Watt > Pullup-Widerstaenden gegen 24V arbeitet ;-) Fast genauso machen wir das. Statt 2N3055 gibt es zwecks Strombegrenzug einen TDE1737, neuerdings BTS3800SL. Ganz so verschwenderisch sind wir auch nicht, 820 bis 3300 Ohm an 24V müssen reichen.
Jitterer schrieb: > nimm doch einfach billige android tabelts vom chinaman da ist alles drin > was du brahcst flash ram nen display und wlan. > > Du baust ein Wlannetz mit einem Webserver auf. Also mMn. ist das mit Abstand die beste Idee von allen. Was spricht dagegen?
Hyper Mario schrieb: > Was spricht > dagegen? Hat der TO bereits beantwortet: Peter M. schrieb: > Ja klar, man kann auch was mit fertigteilen "basteln", aber ist hier > etwas speziell. 4:3 Tablets gibts nicht. Zudem soll das auch einfach > einen Schalter haben: AN und es geht in 5 Sekunden los. nicht noch jedes > Tablet in 3m Höhe manuell einschalten usw.
^^ nette rechnung aber bei JPEG sinds vlt noch 100-150kb je bild ein STM32 mit HW Jpeg decoder kann das bei VGA auch noch in 25FPS ^^ mach einfach das ding zum JPEG/MJPEG display und gut ist am PC kannst dann einfach bilder per festes http protokoll reinschießen und gut ist - ich würde das über einen TCP socket machen - bedeutet weniger arbeit zwecks buffering und so elm chan tjpegdec passt ohne probleme in den ITCM RAM des M7 daher geht auch ein billigerer STM32F74x die lib zerpflückt den stream in blöcke .. wenn du dir ein gutes buffermanagement einfallen lässt , brauchst du kein ganzes bild zwischenpuffern musst dir quasi nur gedanken machen wie das mit der Position gelöst wird aber über speed brauchst dir keine gedanken kmachen ggf über die IP adresse positionieren 192.168. x . y koordinaten alle mit subnetmaske 255.255.0.0 und dann gehts los
Cghgf schrieb: > aber bei JPEG sinds vlt noch 100-150kb je bild Klar, deswegen schrieb ich ja auch, dass ich bewusst mal ohne Komprimierung betrachte. Die Intention war einfach aufzuzeigen, dass die Idee, das über CAN zu übertragen im Vergleich zu Ethernet schon deutliche Schwachstellen hat. Ob man dann ein eigenes Protokoll entwickelt, oder auf bestehende Protokolle zurückgreift, ist eigentlich nebensächlich. Ethernet ist einfach dafür gebaut, große, zusammenhängende Datenmengen zu managen und zu übertragen. CAN ist dafür gebaut, ein paar Bits durch die Gegend zu schubsen. Entsprechend gibt es für Ethernet auch fertige Protokolle, die sowas unterstützen. Bei CAN gibt es sowas bestimmt auch.. Aber dann ist es auch wieder gerad egal, welche Dienste, Sockets, Protokolle,... ich implementieren muss. Dann denke ich, wird es mit CAN auch nicht weniger aufwändig, als mit Ethernet. Der Vorteil, dass CAN ein paar Sachen in Hardware macht, ist einfach gemessen an den Nachteilen, die CAN mitbringt ein eher schwaches Argument, hier CAN einzusetzen.
Schlumpf schrieb: > Ein CAN-Frame besteht aus ca 14 Byte. Davon sind 8 Byte Datenfeld. Nein, CAN-FD hat bis 64 Byte Nutzdaten.
Danke euch für die Analysen. Die Datenmenge und keine harte Anforderung ans Timing, da liegt Ethernet klar vorne. Ds bisschen Auto-Retransmit ist schnell eingebaut. Hab das Prinzip hier schon fertig liegen in C. Wurde für einen Firmware-Loader über K-Line verwendet.
Rudolph R. schrieb: > Nein, CAN-FD hat bis 64 Byte Nutzdaten. Rudolph R. schrieb: > Verflixt, zu langsam für Edit... Dann brauche ich ja jetzt nix dazu sagen, oder?
Schlumpf schrieb: > Hat der TO bereits beantwortet: Sorry, nicht gesehen > > Peter M. schrieb: >> Ja klar, man kann auch was mit fertigteilen "basteln", aber ist hier >> etwas speziell. 4:3 Tablets gibts nicht. 4:3 Folie mittels Schneidplotter als Bastellösung. > Zudem soll das auch einfach >> einen Schalter haben: USB Stromversorgung keine Option? > AN und es geht in 5 Sekunden los. nicht noch jedes >> Tablet in 3m Höhe manuell einschalten usw. Evtl. Standby und Ein/Aus Kommando über USB (per HUB/Repeater wg. der Länge). Rudolph R. schrieb: > Schlumpf schrieb: >> Ein CAN-Frame besteht aus ca 14 Byte. Davon sind 8 Byte Datenfeld. > > Nein, CAN-FD hat bis 64 Byte Nutzdaten. Genau das richtige für ein Multimediaprojekt ;-).
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.