Guten Tag, Ich bin relativ unerfahren auf dem Gebiet, hoffe ihr könnt mir helfen. Danke schonmal im Voraus. Anwendung: Die Daten eines Beschleunigungssensors sollen echtzeitfähig über SPI abgefragt werden können. Das ganze soll dann zur weiteren Verarbeitung mit Ethernet/EtherCAT weiter gesendet werden. Zur Konfiguration sollte ein Speicher vorhanden sein, mit dem Config-Dateien eingelesen werden können (z.B. je nachdem welchen Sensor man gerade verwendet). Denkbar wäre auch einfach ein SD-Card-Shield. Ziel ist es, die ganze Stromversorgung über das Ethernet/EtherCAT zu lösen, sodass es keine großen Verkabelungsthemen gibt. Bisher hab ich mit einem Arduino Uno gearbeitet, der verfügt allerdings weder über Ethernet, noch SD-Card oder sonst irgendwas. Deshalb möchte ich auf ein anderes Board wechseln. Das Board sollte möglichst weit verbreitet sein, also nichts super spezielles, sodass man leicht Hilfe findet, bzw. es einfach zu programmieren ist. Ich hoffe ihr habt ein paar Vorschläge :) Falls ihr weitere Daten benötigt reich ich die natürlich nach. Vielen Dank und Gruß!
Ethernet und EtherCAT sind schon zwei sehr verschiedene Sachen, Ethernet ist erstmal deutlich einfacher. Für Arduino gibt es Ethernet Shields, kompakter wird es wenn man Cortex-M mit Ethernet Interface nimmt. LPC1769 wäre so einer, bei STM gibt es auch eine grosse Auswahl. Für EtherCAT hat TI spezielle Prozessoren, die Sitara Reihe. Da musst du zum Arduino einiges dazulernen. Bzw. ich habe auch mal was von EtherCAT Shields für Arduino gelesen, ich weiss nicht ob die inzwischen lieferbar sind. Angeboten werden die hier: https://www.bausano.net/shop/en/home/16-arduino-ethercat.html
Cortex M4/M7 mit externem Phy ethernetfähig genug Speicher und schnell genug mit guter Reserve. zur versorgung : PoE gibt einige Schaltkreise von MPS ... zur Config: Ich würde das über ethernet machen. webserver drauf oder client der sich eine config holt( autoprovisioning ..)
Ethernet ist aber nur bedingt Echtzeit-kompatibel, ebenso SD Karten. Wie sind deine Anforderungen an das Timing?
Nimm ein Zynq Board, dort kannst du bei Bedarf dann auch nen EtherCAT ip core einbauen. Wenn dir das zu teuer ist musst du halt einen LAN9252 an einen uC/SoC deiner Wahl flanschen
Ein raspi ist erstmal overkill aber mit poe-hat out-of-the-box Ethernet und poe fähig. Bei einem Einzelstück ist die gesparte Arbeit oft mehr Wert als die Teile.
Mit einem Raspi ginge das Programmiertechnisch in der tat am Schnellsten und du hättest den größten Support (da viel mehr Leute den für Netzwerk Zeugs einsetzen als uC). Frage ist ob es dir, wie im Text geschrieben, reicht wenn nur die Verbindung vom Chip zum Sensor in Echzeit läuft (raspi hat Hardware SPI, sogar zwei davon), oder auch der gesamte Netzwerk Stack echtzeitfähig sein soll. Config Daten dann auf einen USB Stick, damit du nicht für jedes Gerät das ganze OS auf microSD Karte vorhalten musst. Wobei sich ein Abruf von diesen Daten auch per Netzwerk recht schnell umsetzen ließe. Z.B. mit einem FTP Server.
:
Bearbeitet durch User
Infineon hat z.b. die XMC4xxx Reihe mit fest eingebautem EtherCAT Modul. Gibt Evalboards dafür.
Erstmal vielen Dank für die zahlreichen Antworten! Also Raspberry fällt eigentlich raus, weil wir davon quasi weg wollen. Bisher wurde ein Beschleunigungssensor mit einem Raspberry via Python abgefragt, da schaffen wir aber nur ne begrenzte Abtastfrequenz (weil Python zu langsam). Da das ganze irgendwann industrietauglich werden muss, wollen wir sowieso weg von Raspberry. Ich hab mir bereits viele MC angeschaut die einen Ethernet Anschluss haben, darunter Arduino Uno + Ethernet Shield Arduino Ethernet w/o PoE Infineon XMC4500 Evaluation Board BeagleBone Black BeagleBone ist ähnlich dem Raspberry, weshalb das wahrscheinlich rausfällt. Ob Arduino industrietauglich ist, sei auch mal dahingestellt. Außerdem benötigen wir min. 2 SPI-Masters, soweit ich weiß hat Arduino Uno nur einen. Vor allem soll das ganze ja echtzeitfähig sein. Die RTC beschränkt sich allerdings nur zwischen Sensor und MC, weshalb es egal ist wenn es bei Ethernet ein paar Verzögerungen gibt. Scheint, dass ich vor allem auf den Infineon gehen müsste. Ist das aufwändiger, "nicht so handlich" wie ein Arduino (sorry für die noob Frage)? V.a. müsste ich mir wahrscheinlich noch ein RTOS raussuchen oder?
Manuel M. schrieb: > da schaffen wir aber nur ne begrenzte Abtastfrequenz > Vor allem soll das ganze ja echtzeitfähig sein. Nur so als Hinweis, "echtzeitfähig" bedeutet nicht "schnell". Welche Garantien musst du denn einhalten und wie schlimm ist eine Nichteinhaltung?
Manuel M. schrieb: > Erstmal vielen Dank für die zahlreichen Antworten! > Also Raspberry fällt eigentlich raus, weil wir davon quasi weg wollen. > Bisher wurde ein Beschleunigungssensor mit einem Raspberry via Python > abgefragt, da schaffen wir aber nur ne begrenzte Abtastfrequenz (weil > Python zu langsam). Und auf die Idee, das Ganze in C/C++ zu machen, seid Ihr nicht gekommen? > Da das ganze irgendwann industrietauglich werden > muss, wollen wir sowieso weg von Raspberry. Der Raspberry wird auch in der Industrie genutzt. > Ich hab mir bereits viele MC angeschaut die einen Ethernet Anschluss > haben, darunter Du meinst wohl Boards und nicht MC. > Vor allem soll das ganze ja echtzeitfähig sein. Die RTC beschränkt sich > allerdings nur zwischen Sensor und MC, weshalb es egal ist wenn es bei > Ethernet ein paar Verzögerungen gibt. Wie wäre es, wenn Du einfach mal die exakten Timinganforderungen angibst? So ist das nur stümperhaftes Stochern im Nebel. > Scheint, dass ich vor allem auf den Infineon gehen müsste. > Ist das aufwändiger, "nicht so handlich" wie ein Arduino (sorry für die > noob Frage)? V.a. müsste ich mir wahrscheinlich noch ein RTOS raussuchen > oder? Nein, musst Du nicht. Aber Du solltest Dich mal ein bisschen mit der ganzen Thematik beschäftigen. Offensichtlich kennst Du Dich nur sehr oberflächlich mit der ganzen Sache aus.
Du solltest dich mal mit sowas auseinander setzen: https://www.phytec.de/produkte/texas-instruments/am335x/?gclid=EAIaIQobChMIlJGk3fSM3gIVS6qaCh3rgAS9EAAYAiAAEgJqufD_BwE
Hier wird man ja gut zerlegt. Neverever schrieb: > Nein, musst Du nicht. > Aber Du solltest Dich mal ein bisschen mit der ganzen Thematik > beschäftigen. Offensichtlich kennst Du Dich nur sehr oberflächlich mit > der ganzen Sache aus. Manuel M. schrieb: > Ich bin relativ unerfahren auf dem Gebiet, hoffe ihr könnt mir helfen. > Danke schonmal im Voraus. Ich kenn mich absolut nur oberflächlich damit aus, deswegen frag ich ja. Stefanus F. schrieb: > Wie sind deine Anforderungen an das Timing? Leider habe ich noch keine Anforderungen an das Timing vorliegen, ich weiß dass das wichtig wäre. Akutell wird ein ADXL345 Beschl.-Sensor, mit Python ist da aber bei 1600 Hz Schluss, 3200 Hz wollen wir allerdings erreichen. Eine Nichterfüllung wäre nicht so dramatisch, hängen keine Leben und keine Sachwerte davon ab. Dass wir auch nur auf C/C++ umsteigen könnten ist klar. Allerdings ist mein Betreuer der Meinung, dass Raspberry nicht wirklich industrietauglich sind, weshalb ich die Aufgabe hab nach Alternativen zu suchen. Was wäre denn der Vorteil vom Raspberry z.B. zum Infineon Evaluation Board? Danke
Manuel M. schrieb: > Allerdings ist > mein Betreuer der Meinung, dass Raspberry nicht wirklich > industrietauglich sind Schwachsinn
Welche großen Entfernungen sollen denn zwischen Beschleunigungssensor und PC überbrückt werden, damit Ethernet sich auch lohnt? Für kurze Strecken wäre ein USB-UART Umsetzer deutlich einfacher zu programmieren.
Manuel M. schrieb: > Dass wir auch nur auf C/C++ umsteigen könnten ist klar. Allerdings ist > mein Betreuer der Meinung, dass Raspberry nicht wirklich > industrietauglich sind, weshalb ich die Aufgabe hab nach Alternativen zu > suchen. Der Raspberry hat genau zwei Vorteile: 1. Er ist billig, weil er durch eine Organisation gespnsort wird 2. Er ist wegen 1. bei Bastlern beliebt, was die Präsenz im Internet deutlich erhöht Aber: 1. Der Prozessor ist nicht nur nicht langzeitverfügbar, was für viele Kunden wichtig ist. Er ist vielmehr überhaupt nicht verfügbar, weil Broadcom ihn nur an die Raspberry Pi Foundation liefert und an niemand anderen sonst. 2. Der Prozessor ist Consumerware und nicht für irgendwelchen erweiterten Temperaturbereiche zertifiziert. Auch AEC-Q200 kannst Du vergessen. 3. Dem Prozessor fehlen wichtige Schnittstellen, die in der Industrie wichtig sind: CAN, Ethernet (das Netzwerk beim Pi läuft über USB 2.0 und ist damit kastriert), verschiedene Feldbusse Für den BeagleBone gelten diese Dinge nicht. Wenn Du tatsächlich EtherCAT brauchst, scheidet der PI aus. Punkt. Da wären die Infineon-Prozessoren eine bessere Wahl. Oder die Ti Sitara Prozessoren, die auch für den BeagleBone verwendet werden. Wobei der BeagleBone selber angeblich aufgrund seiner internen Verschaltung EtherCat nicht unterstützt, obwohl der Prozessor selber es könnte. Siehe http://www.ti.com/lit/wp/spry187h/spry187h.pdf fchk
Chris schrieb: > Manuel M. schrieb: >> Allerdings ist >> mein Betreuer der Meinung, dass Raspberry nicht wirklich >> industrietauglich sind > > Schwachsinn Erkläre mal bitte warum doch tauglich, das würde mich echt interessieren.
Vielen Dank für die hilfreiche Antwort @fchk Peter D. schrieb: > Welche großen Entfernungen sollen denn zwischen > Beschleunigungssensor > und PC überbrückt werden, damit Ethernet sich auch lohnt? > Für kurze Strecken wäre ein USB-UART Umsetzer deutlich einfacher zu > programmieren. Die Kommunikation zwischen Board und Sensor ist nicht mit Ethernet realisiert, nur die Kommunikation nach außen mit einem IPC, auf dem dann weiterhin Python läuft, der dann die Daten analysiert. Dies muss nicht echtzeitfähig geschehen, weshalb auch EtherCAT nicht zwingend erforderlich. DanVet schrieb: > Du solltest dich mal mit sowas auseinander setzen: > > https://www.phytec.de/produkte/texas-instruments/a... Sieht auch sehr vielversprechend aus. Das und die Infineon XMC4xxx Kit Reihe kommen wohl am ehesten für in Frage.
Manuel Mueller schrieb: > nur die Kommunikation nach außen mit einem IPC Diese meinte ich auch. "unerfahren" und "Ethernet" halte ich für keine gute Kombination. Ich hab auch viele kommerzielle Produkte gesehen, die zwar über USB angeschlossen werden, jedoch auf dem PC als COM erscheinen.
Verstehe ich dich richtig, dass du im Grunde genommen nur 3200 Messungen pro Sekunde über SPI von einem Sensor abrufen willst? Die Aufgabe des Mikrocontrollers wäre dann, das die Intervalle festzulegen und die Daten zu puffern, damit sie etwas unregelmäßiger an den PC weiter gereicht werden können? Darauf ergäbe sich die Frage nach der gewünschten Puffergröße.
Stefanus F. schrieb: > Darauf ergäbe sich die Frage nach der gewünschten Puffergröße. Ergibt die sich nicht aus der maximalen Verzögerung des Netzwerks bzw. des abrufenden Programms? EDIT: Btw. hier hat jemand bis zu 20k Abrufe eines SPI ADCs mit dem Raspi realisiert in C++: https://www.raspberrypi.org/forums/viewtopic.php?t=83877
:
Bearbeitet durch User
Stefanus F. schrieb: > Verstehe ich dich richtig, dass du im Grunde genommen nur 3200 > Messungen > pro Sekunde über SPI von einem Sensor abrufen willst? Die Aufgabe des > Mikrocontrollers wäre dann, das die Intervalle festzulegen und die Daten > zu puffern, damit sie etwas unregelmäßiger an den PC weiter gereicht > werden können? > > Darauf ergäbe sich die Frage nach der gewünschten Puffergröße. Absolut. An sich also eigentlich keine RT Application. Mit Puffergröße meinst du den RAM des Boards? Alex G. schrieb: > EDIT: Btw. hier hat jemand bis zu 20k Abrufe eines SPI ADCs mit dem > Raspi realisiert in C++: > https://www.raspberrypi.org/forums/viewtopic.php?t=83877 Vielen Dank, ich schau mal drüber.
> Mit Puffergröße meinst du den RAM des Boards? Ja genau. Wenn wir mal von einem durchschnittlichen Windows PC ausgehen, auf dem noch ein paar andere Programme laufen, wäre ein Puffer von vielleicht 3 Sekunden nicht schlecht. Also 3 Sekunden mal 3200 Messungen. Wie viele Bytes eine Messung belegt, weist du hoffentlich selbst. Ich denke, damit kommst du in den Bereich einiger zig Kilobytes, womit 8bit AVR schon einmal raus sind. Ich hätte dafür ohnehin einen µC bevorzugt, der schon Ethernet dabei hat. Da gibt es diese billigen ESP8266 Module mit WLAN, ich bin allerdings nicht sicher, inwiefern sich aktives WLAN mit dessen SPI Schnittstelle vertragen - also ob das Timing dann noch sauber hinzubekommen ist.
Stefanus F. schrieb: >> Mit Puffergröße meinst du den RAM des Boards? > > Ja genau. Wenn wir mal von einem durchschnittlichen Windows PC ausgehen, > auf dem noch ein paar andere Programme laufen, wäre ein Puffer von > vielleicht 3 Sekunden nicht schlecht. Also 3 Sekunden mal 3200 > Messungen. Wie viele Bytes eine Messung belegt, weist du hoffentlich > selbst. > > Ich denke, damit kommst du in den Bereich einiger zig Kilobytes, womit > 8bit AVR schon einmal raus sind. Ich hätte dafür ohnehin einen µC > bevorzugt, der schon Ethernet dabei hat. > > Da gibt es diese billigen ESP8266 Module mit WLAN, ich bin allerdings > nicht sicher, inwiefern sich aktives WLAN mit dessen SPI Schnittstelle > vertragen - also ob das Timing dann noch sauber hinzubekommen ist. Vielen Dank für deinen Beitrag, hat mich echt zum Nachdenken gebracht. Wir waren eigentlich soweit, es nochmal mit dem Arduino Ethernet with PoE zu versuchen, allerdings hat dieser nur 2 kB SRAM. Pro Messung bekommen wir 3 floats, also 3x 4 kB, bei 3200 Hz wären das 38 kB pro Sekunde. Und da sind ja nicht mal lokale Variablen, Funktionsparameter usw. eingerechnet. Das scheint definitiv viel zu wenig zu sein. Da mein Betreuer langfristig vom Raspberry weg will, ist es keine Option einfach weiter den Pi mit C++ zu nutzen. Kann mir jemand sagen wie viel Aufwand es Evaluation Boards wie die folgenden zu programmieren? Die haben ja ein eigenes OS bzw RTOS. https://www.phytec.de/produkte/texas-instruments/am335x/#flexible-echtzeitunterstuetzung https://www.infineon.com/cms/de/product/evaluation-boards/kit_xmc45_relax_v1/ Vielen Dank
Bei 38 kB pro Sekunde und drei Sekunden Speicherbedarf ist der ESP8266 auf jeden Fall auch raus.
Manuel Mueller schrieb: > Kann mir jemand sagen wie viel Aufwand es Evaluation Boards wie die > folgenden zu programmieren? Die haben ja ein eigenes OS bzw RTOS. > https://www.phytec.de/produkte/texas-instruments/am335x/#flexible-echtzeitunterstuetzung > https://www.infineon.com/cms/de/product/evaluation-boards/kit_xmc45_relax_v1/ > > Vielen Dank Vorsicht. Versteif dich nicht auf konkrete Hardware. Der Hauptknackpunkt ist hier die Programmierumgebung und die vorhandene Software. Unterschätze keinesfalls den Aufwand, Ethernet in Firmware zu lösen. Wenn du kein Beispielprojekt für Ethernet für das konkrete Board hast, mit dem du zurechtkommst, kannst du dich auf einen langen, steinigen Weg einstellen. Wenn du dagegen ein für dich verständliches gutes Beispielprojekt hast, wirst du schnell eine Lösung liefern können. Was gut ist, hat viel mit dir zu tun: Gut ist, was funktioniert, und was du verstehst. Ich würde mehrere IDEs herunterladen und die Beispielprojekte ansehen. Das, mit dem du am Besten zurechtkommst, ist die beste Lösung. Schau eventuell auch mal in der STM32-Ecke. Ich bin kein Fan der STM32-Serie *1) aber du wirst viel Code und Hilfe im Internet finden. Viel mehr jedenfalls als für die XMC-Serie. *1) und das liegt an mir: Ich werde mit CubeMX und der Peripheral Lib nicht warm. Andere schon. Gutes Beispiel also ;-)
Stefanus F. schrieb: > Bei 38 kB pro Sekunde und drei Sekunden Speicherbedarf ist der > ESP8266 > auf jeden Fall auch raus. Die 3 Sekunden waren nur ein Beispiel von Stefanus. Trotzdem wäre nach <0,05s die RAM vollgeschrieben. soso... schrieb: > Vorsicht. Versteif dich nicht auf konkrete Hardware. > > Der Hauptknackpunkt ist hier die Programmierumgebung und die vorhandene > Software. Unterschätze keinesfalls den Aufwand, Ethernet in Firmware zu > lösen. Wenn du kein Beispielprojekt für Ethernet für das konkrete Board > hast, mit dem du zurechtkommst, kannst du dich auf einen langen, > steinigen Weg einstellen. > Wenn du dagegen ein für dich verständliches gutes Beispielprojekt hast, > wirst du schnell eine Lösung liefern können. > Was gut ist, hat viel mit dir zu tun: Gut ist, was funktioniert, und was > du verstehst. > > Ich würde mehrere IDEs herunterladen und die Beispielprojekte ansehen. > Das, mit dem du am Besten zurechtkommst, ist die beste Lösung. > > Schau eventuell auch mal in der STM32-Ecke. Ich bin kein Fan der > STM32-Serie *1) aber du wirst viel Code und Hilfe im Internet finden. > Viel mehr jedenfalls als für die XMC-Serie. Alles klar, danke. Danach werd ich dann wohl gehen. Die STM32 sehen vielversprechend aus.
Manuel Mueller schrieb: > Pro Messung bekommen wir 3 floats, also 3x 4 kB, bei 3200 Hz wären das > 38 kB pro Sekunde. der angegebene Sensor stellt eigentlich max. 3*13bit(x,y,z) mit max.3200Hz bereit und vom Prinzip dürfte der Sensor mit seinem 'Messung-fertig- Interrupt' besser als Datentaktquelle geeignet sein als ein mutmaßliches polling oder auf gut Glück abfragen. Der Raspberry selbst (oder ein anderer Betreuer kompatibler KleinPc) dürfte das zwar schaffen, aber ein zusätzlicher kleinst-µC (bspw. 16MHz,spi,uart,16byte ram,..) könnte (auch unter Komplexitätsreduzierungsgesichtspunkten) eine sinnvolle Ergänzung sein: kleinst-µC (2MHz Spi/ 2MBaud 8n1) liest auf interrupt-signal vom Sensor x,y,z aus und 'verpackt' 3*13-bit -->3*2*7-bit und das letzte Byte bekommt als Paketendemarkierung ein gesetztes b7, damit das Weiterverarbeitungsprogramm nach der byteweisen sysnc-suche (wenn nichts schiefläuft) nur noch für größere C 'bequeme' n*6 Blöcke einlesen muss. Ob ein KleinPc wie der Rasperry als Middleware für einen 'richtigen' PC dann noch nötig ist wäre eine andere Frage. kurz: es kann sich lohnen zu fragen welches System Datenverarbeitung imitiert, ob Sender oder eher Empfänger Buffer eher passen und ob zusätzliche Hardware trotz zusätzlicher Fehlermöglichkeiten die Komplexität nicht doch verringern kann.
nimm doch einen µC deiner Wahl (kann ein simpler Atmega sein) dann schließe daran ein Ethernet-UART Modul an und fertig ist das Gerät. Die Module gibt es als kompakte Bauteile (sieht von außen wie eine Ethernetbuchse aus, hat aber den ganzen Ethernet TCP/IP Stack drinn). Kläre aber vorher noch ab welche Datenrate sich von deinen Beschleunigungssensoren ergibt und was genau unter "Echtzeit" verstanden wird. Hier fehlen noch zu viele Angaben Welche Stückzahlen werden benötigt - kommt es auf jeden Cent an? https://www.lantronix.com/products/xport/#tab-features EDIT: Wenn es EtherCAT sein muss gibt es das auch mit UART: https://www.deutschmann.de/de/produkte/embedded-solutions/unigate-ic/unigate-ic-ethercat/
:
Bearbeitet durch User
Jonny O. schrieb: > nimm doch einen µC deiner Wahl (kann ein simpler Atmega sein) dann > schließe daran ein Ethernet-UART Modul an und fertig ist das Gerät. [ ] Ja, ich habe den Thread nicht gelesen. Bitte ankreuzen.
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.