Nachdem ich schon einige Zeit lese, habe ich mir hier auch mal einen Account gemacht.
Kurz zu meinem Problem: Ich beabsichtige mir einen LattePanda IOTA (https://www.lattepanda.com/lattepanda-iota#) zu kaufen. Selbiger hat leider nur einen freien PCIe Port (PCIe 1x 3.0 FPC), wie er auch beim RPi 5 verwendet wird. Ich möchte jedoch eine SSD und einige Portkarten (RS232/RS458 und ggf. GPIO, I2C udg.) anschließen.
Es gibt auf Amazon einige "PCIe Switch" die mehrere PCIe aus einem Anschluss zur Verfügung stellen. Taugt so etwas was, oder ist dann die Bandbreite so eingeschränkt, dass es nicht zufriedenstellend funktioniert? Ich habe leider wenig Erfahrung mit PCIe und möchte keine Karten um 100 € kaufen, wenn es dann übelst langsam ist oder garnicht funktioniert.
Kurz zu meinem Problem: Ich beabsichtige mir einen LattePanda IOTA
(https://www.lattepanda.com/lattepanda-iota#) zu kaufen. Selbiger hat
leider nur einen freien PCIe Port (PCIe 1x 3.0 FPC), wie er auch beim
RPi 5 verwendet wird. Ich möchte jedoch eine SSD und einige Portkarten
(RS232/RS458 und ggf. GPIO, I2C udg.) anschließen.
Es gibt auf Amazon einige "PCIe Switch" die mehrere PCIe aus einem
Anschluss zur Verfügung stellen. Taugt so etwas was,
Keine Ahnung, ob hier jemand etwas dazu sagen kann (und will), bisher sieht es ja nicht danach aus.
Aber auf mich wirken Deine Aussagen ein bisschen so, als würdest Du Dir viel mehr Kopf über Performance machen, als Dir gut tut. Ich mein, RS232, RS458, I2C und GPIOs über PCIe? Auch für eine SSD ist PCIe völlig überdimensioniert, solange damit nicht in Wirklichkeit eine NVME gemeint ist.
Was hast Du denn mit dem Teil vor, und: hast Du auch den Lattepanda IOTA vor allem wegen seiner Performance ausgewählt?
Ich wuerde mir da auch nicht Sorgen um die Peformance machen, sondern eher: Wie sollen denn die PCIe-Verbindungen in HW gemacht werden?
Auf dem SBC-Board ist irgendein wilder Folienconnector, wie werden denn die ominoesen Amazon-PCIe Switche angeschlossen?
Mit Wago-Klemmen oder Tuedeldraht ist's ja eher nix bei PCIe.
Und wenn du da eh dann einen ganzen Sauverhau mit Zusatzplatinen etc. brauchst, waere da denn nicht ein kompletter Standard-Mini-PC besser?
Ja vermutlich mache ich mir zu viele Gedanken... Bei 115200 Baud ist die Leistung echt egal. Selbst GPIO-Bitbang sollte gehen.
Worüber ließen sich solche Portkarten noch anschließen? Mit USB zu RS232 habe ich keine guten Erfahrungen! Ich glaube, dass USB zu I2C udg. auch nicht besser funktioniert.
Kurz zu meinem Problem: Ich beabsichtige mir einen LattePanda IOTA
(https://www.lattepanda.com/lattepanda-iota#) zu kaufen. Selbiger hat
leider nur einen freien PCIe Port (PCIe 1x 3.0 FPC), wie er auch beim
RPi 5 verwendet wird. Ich möchte jedoch eine SSD und einige Portkarten
(RS232/RS458 und ggf. GPIO, I2C udg.) anschließen.
Wenn Du viel IO brauchst, ist der IOTA vermutlich das falsche Produkt. Du bist wahrscheinlich mit einem Odroid H4+ besser bedient.
https://www.hardkernel.com/shop/odroid-h4-plus/
Oder auch eine ältere Version (H2, H3(+)), wenn Du das günstig bekommst. Da hast Du echte UARTs, zwei I2C direkt vom Chipsatz, SATA-Ports für SSDs, einen M.2 Typ M Slot mit 4 Lanes für diverse Sachen etc.
Es gibt auch andere kleine PC-Boards, wobei ich nicht weiß, ob Du wirklich PC-Architektur brauchst. Der Raspberry Pi 5 hat auch 5 extern zugängliche UARTs direkt im RP1 IO-Controller drin, ohne dass Du über USB gehen musst - plus den Debug-UART und den Bluetooth UART. Die meisten Erweiterungen nutzen jedoch nur den UART0, den es auch schon bei den alten PIs gab.
Es gibt auf Amazon einige "PCIe Switch" die mehrere PCIe aus einem
Anschluss zur Verfügung stellen. Taugt so etwas was, oder ist dann die
Bandbreite so eingeschränkt, dass es nicht zufriedenstellend
funktioniert? Ich habe leider wenig Erfahrung mit PCIe und möchte keine
Karten um 100 € kaufen, wenn es dann übelst langsam ist oder garnicht
funktioniert.
PCIe Bridges funktionieren schon. PCIe an sich ist jedoch ziemlich empfindlich, und eigentlich möchtest Du es nicht über Kabel weiterleiten. Ich kann jetzt nicht sagen, wie der IOTA auf PCIe Bridges reagiert. Beim Pi war es zumindest so, dass im Bootrom kein Platz für die Bridge-Support gab (oder gibt), so dass man von einer NVME-SSD nur booten konnte, wenn keine PCIe Dridge dazwischen war.
Ich habe den Eindruck, dass Du Deine Wahl vielleicht nochmal überdenken solltest.
Es gibt auch andere kleine PC-Boards, wobei ich nicht weiß, ob Du
wirklich PC-Architektur brauchst.
Intel 86x währe schon von Vorteil. Darum finde ich LattePanda gut. Es ist quasi einen RPi mit Intel N150. Mein Plan ist die PCIe HATs des RPI 5 genau so auf den LattePanda nutzen zu können.
PCIe Bridges funktionieren schon. PCIe an sich ist jedoch ziemlich
empfindlich, und eigentlich möchtest Du es nicht über Kabel
weiterleiten.
Wie empfindlich ist "ziemlich", reden wir da von Störunegn ab 5 oder 50 cm? Ich glaube diese Flachbandkabel sind so 10 - 16 cm.
Ich habe den Eindruck, dass Du Deine Wahl vielleicht nochmal überdenken
solltest.
Ja ich fürchte auch. Dann kann ich zwar die HATs nicht nutzen (haben Flachbandanschluss) aber was nicht geht geht nicht.
Intel 86x währe schon von Vorteil. Darum finde ich LattePanda gut. Es
ist quasi einen RPi mit Intel N150. Mein Plan ist die PCIe HATs des RPI
5 genau so auf den LattePanda nutzen zu können.
Aha. DAS ist also die Motivation.
PCIe Bridges funktionieren schon. PCIe an sich ist jedoch ziemlich
empfindlich, und eigentlich möchtest Du es nicht über Kabel
weiterleiten.
Wie empfindlich ist "ziemlich", reden wir da von Störunegn ab 5 oder 50
cm? Ich glaube diese Flachbandkabel sind so 10 - 16 cm.
Bei PCIe Gen 2 (das ist das, was der Pi zuverlässig macht, Gen 3 hält er nicht in allen Parametern ein) ist das das auch das äußerste, was man machen sollte. Wobei nicht nur der Folienleiter kritisch ist. Auch die FFC-Stecker sind nicht für Signale im Bereich mehrerer GHz vorgesehen. Ja, es gibt Kabelverbindungen für PCIe, aber die sehen deutlich anders aus und verwenden Twinax-Kabel.
Der N150 macht PCIe Gen 4. Das ist schon so empfindlich, da macht schon die Ausrichtung des Glasfasergewebes im FR4 einen Unterschied. Ich weiß nicht, ob Du den Link im BIOS auf Gen2 runterdrehen kannst.
Ich habe den Eindruck, dass Du Deine Wahl vielleicht nochmal überdenken
solltest.
Ja ich fürchte auch. Dann kann ich zwar die HATs nicht nutzen (haben
Flachbandanschluss) aber was nicht geht geht nicht.
Der N150 macht PCIe Gen 4. Das ist schon so empfindlich, da macht schon
die Ausrichtung des Glasfasergewebes im FR4 einen Unterschied. Ich weiß
nicht, ob Du den Link im BIOS auf Gen2 runterdrehen kannst.
Ich habe leider garkeinen Plan, was da für ein BIOS oben ist. Ich weiß nur dass man es bei meinem PC einstellen kann.
Die HATs für den RPi 5 machen die IMHO auch nur Gen. 2 (muss natürlich nicht sein IK).
Mein Plan ist die PCIe HATs des RPI
5 genau so auf den LattePanda nutzen zu können.
Das wird vermutlich nicht gehen, fürchte ich. Aber für den LattePanda gibt es anscheinend eigene HATs, die sich aber wohl -- wenn ich das richtig gesehen habe -- nicht stacken, also nicht übereinander stecken lassen.
Mir ist ziemlich schleierhaft, was so ein oller Lattenpanda fuer Vorteile in dem Setup hier haben soll gegenueber irgeneinem Popel-Mini-PC mit entsprechender CPU. Bei dem waeren die PCIe Lanes wenigstens auf einer richtigen Platine und enden an den entsprechend genormten Steckplaetzen und gehen nicht mit schwindligen Folienleitern ueber irgendwelche Switche...
Mit USB zu RS232 habe ich keine guten Erfahrungen!
Das kann bombenstabil funktionieren, wenn man a) vernünftige USB-Seriell-Bridges verwendet und b) weiß, was man tut. Bit-Banging mit den Handshakeleitungen (was es als Frickellösung für manche Probleme gibt) ist damit ziemlich unbrauchbar; wenn man beispielsweise meint, RS485 mit einer USB-Seriell-Bridge und nachgeschaltetem, per Software gesteuerten RS485-Konverter betreiben zu wollen, hat man keine guten Karten. Da praktisch jede bessere USB-Seriell-Bridge aber die Ansteuerung von RS485-Treibern in Hardware unterstützt, muss man sich nicht darum kümmern.
Dann sollte man sich auch Gedanken über das zu nutzende Protokoll machen - wenn man mit hoher Baudrate einzelne Bytes hin- und hersendet, statt größere Datenblöcke, wird man mit USB-Seriell-Bridges auch nicht viel Glück haben, da diese aufgrund Pollings der USB-Schnittstelle nicht beliebig schnell auf eingehende Daten reagieren können.
Und wenn man, statt mit dem Betriebsystem-API mit einem wilden Schichtkuchen an Libraries und Abstraktionslayern hantiert, dann kann einem natürlich auch das noch Probleme bereiten, die schwer zu finden sind. Nicht alles, was Leute auf Github als tolle Library hochladen, taugt überall.
Ist man sich dieser Einschränkungen bewusst, kann man aber langzeitstabile serielle Kommunikation über USB betreiben.
Ich glaube, dass USB zu I2C udg. auch
nicht besser funktioniert.
Und auch da gilt das gleiche.
Der Lattepanda ist aber für diese Problemstellugen eigentlich genau der richtige, da der nicht einfach nur ein PC ist, sondern da auch noch ein Microcontroller drauf werkelt - den kann man den ganzen wirklich zeitkritischen Kram erledigen lassen.
Ich habe mir gerade das Datenblatt des LattePanda IOTA organisiert. Da steht, dass er 128 GB internen Storage hat. Hab ich wohl anfangs übersehen... Peinlich peinlich... ;)
Dann ist das geswiche gar nicht nötig, weil ich den M2.2 M-Key für die Karte nutzen kann und keine MVNE-SSD brauche.
Der Lattepanda ist aber für diese Problemstellugen eigentlich genau der
richtige, da der nicht einfach nur ein PC ist, sondern da auch noch ein
Microcontroller drauf werkelt - den kann man den ganzen wirklich
zeitkritischen Kram erledigen lassen.
Da ist halt die Frage, was "diese Problemstellungen" letztendlich sind. Ich bin der Meinung, dass sich ein µController, der den evtl. zeitkritischen I2C/Seriell/whatever-Kram machen soll, leichter (via USB) an einen Standard-PC anflanschen laesst, als eine PCIe-Bridge an einen Lattenpanda.
Gruss
WK
Edit: oops, zu langsam, um auf die neusten Erkenntnisse des TO zu reagieren :-)
Weil manche (ja auch welche für Linux!!!) Programme auf ARM nicht wirklich funktionieren. Ich mag dann keine Programme selbst kompilieren müssen, die es für Intel 86x fix und fertig gibt.
Weil manche (ja auch welche für Linux!!!) Programme auf ARM nicht
wirklich funktionieren.
Würdest Du mir bitte freundlicherweise einige nennen? Ich frage, weil ich dieses Linuxzeugs schon eine ganze Weile lang mache, und mir aktuell beim besten Willen kein Programm einfällt, auf das dies zuträfe.
Hä? Sofern die Programme nicht besonders abartiges treiben oder Teile davon in Assembler geschrieben sind, sollten die sich für beliebige Prozessorarchitekturen übersetzen lassen.
Hä? Sofern die Programme nicht besonders abartiges treiben oder Teile
davon in Assembler geschrieben sind, sollten die sich für beliebige
Prozessorarchitekturen übersetzen lassen.
Das ist keine Raketenwissenschaft.
Schau an, dass wusste ich nicht. Dachte mir nur, die währen für 86x weil meistens ein Kommentar mit "Prozessor: Intel 86x 64bit" oder etwas in der Art dabei steht.
Ich nehme mal an "normale" Linux 86x-64 Binarys laufen nicht unter ARM? Ich habe mit ARM (von MCUs mit M0 abgesehen) leider null erfahrung.
Würdest Du mir bitte freundlicherweise einige nennen?
Bei mir geht es i.b. um MPLAB X, das gibt es zwar für Linux aber ich
habe es bisher nur unter 86x zum laufen gebracht.
Ah okay, danke für die Auskunft. Wobei ich persönlich es schon bedenklich finde, wenn die Abhängigkeit von einer IDE so weit geht, daß sie sogar die verwendete CPU-Architektur beeinflußt oder gar bestimmt. Aber gut, das ist letztlich ja Deine Wahl, nicht meine.
Kleine Programme von GitHub sind sowiso immer Glücksspiel, aber da gibt
es meistens nur 86x Makefiles und umschreiben traue ich mir noch nicht
zu.
Korrekte Makefiles sind nicht architekturspezifisch.
Ich nehme mal an "normale" Linux 86x-64 Binarys laufen nicht unter ARM?
Ueblicherweise laufen x86-64 binaeries natuerlich nicht auf ARM CPUs. Aber wenns unbedingt sein muss, und Performance wurscht ist, kann man unter Linux lustigen Schweinskram mit qemu und binfmt_misc treiben...
Schau an, dass wusste ich nicht. Dachte mir nur, die währen für 86x weil
meistens ein Kommentar mit "Prozessor: Intel 86x 64bit" oder etwas in
der Art dabei steht.
Github-Projekte enthalten in der Regel Sourcecode. Wenn da was von "Prozessor x86" dabei steht, dann beschreibt das ein fertig übersetztes Programm (von Ausnahmen wie Assemblerorgien abgesehen).
Warum aber willst Du mplab nutzen? Macht das irgendwas besonderes, was man mit anderen IDEs nicht auch könnte?
Warum aber willst Du mplab nutzen? Macht das irgendwas besonderes, was
man mit anderen IDEs nicht auch könnte?
Ich bin ein fauler Sack und wechsle ungern die IDE.
Für AVR und Co. kenne ich uner Linux sonst nur Arduino, PlatformIO und Eclipse. PlatformIO und Arduino sind IMHO Müll, weil das extrem viel macht was ich nicht brauch (ich schreibe C und asm).
Du könntest Dir beibringen, wie man mit vscode eine beliebige Toolchain nutzt. Dann kannst Du Dich von derartigen Abhängigkeiten befreien, und vscode ist als IDE durchaus brauchbar.
Das ist im Sourcecode verfügbar, es gibt aber auch fertig übersetzte Binaries für den Raspberry Pi:
Der Aufwand, sich darin einzuarbeiten, lohnt, denn damit kannst Du wirklich plattformunabhängig werden, das Ding läuft eben nicht nur unter Windows und macOS oder Mainstream-Linux, sondern z.B. auch unter FreeBSD.
Der Aufwand, sich darin einzuarbeiten, lohnt, denn damit kannst Du
wirklich plattformunabhängig werden, das Ding läuft eben nicht nur unter
Windows und macOS oder Mainstream-Linux, sondern z.B. auch unter
FreeBSD.
Da kenne ich bisher nur PlatformIO und das ist wie erwähnt eher eklig. Werde ich mir mal ansehen. Zum "normalen" programmieren, also für den PC, ist mir VSC auch am liebsten.
Da kenne ich bisher nur PlatformIO und das ist wie erwähnt eher eklig.
Das liegt aber nicht an vscode, sondern am (auch meiner Ansicht nach) sehr umständlichen Buildprozess und der unnötig komplizierten und unflexiblen Sourcecodestruktur.
Aber dafür gibt es halt durchklickbare Assistenten, die Dich an die Hand nehmen, um irgendwas zu erreichen. Die brauchen wohl den umständlichen Buildprozess und die Sourcecodestruktur.
Ich nutze keine Assistenten, ich habe mir eine Handvoll "tasks" definiert, etwas Makefile-Magie drübergestreut und bei mir wirft CMake aus einer CMakeLists.txt, die als Projekt- und Konfigurationsdatei dient, dann ein Makefile aus, das wiederum den von mir verwendete Compiler (clang/llvm) aufruft und noch ein bisschen anderen Krams macht. Das ist in meinem Fall zwar nicht für einen µC, sondern für ein Betriebssystem, aber das läuft nicht auf meinem Entwicklungsrechner, sondern remote auf einem Testsystem. Und ich nutze lldb als Remotedebugger; dafür gibt es ein nettes Plugin für vscode, was damit das eine wesentliche Plugin ist, das ich nutze. Die anderen sind nur nice-to-haves wie z.B. das "intellisense"-Plugin für C/C++-Quelltext, damit Syntaxhighlighting und Sourcevervollständigung funktionieren.
Für eine µC-Konfiguration müsste man "eigentlich" nur das lldb-Plugin durch eines ersetzen, das mit dem jeweiligen Debug-/Programmieradapter des Zielsystems zusammenarbeitet. Das sollte auch mit einem gdb-Plugin gehen, denn für viele Debug-/Programmieradapter gibt es gdb-Debugserver.
Aber es gibt halt sehr viele unterschiedliche Auffassungen, wie so ein Buildprozess in eine IDE integriert sein muss, und wie sehr man dabei an die Hand genommen werden muss.
Ich bin ein fauler Sack und wechsle ungern die IDE.
Gerade dann wäre es natürlich sinnvoll, sich einmal eine IDE anzueignen, die möglichst viel kann und auf möglichst vielen Plattformen läuft. Ein uraltes UNIX-Gestein wie ich nimmt dann eine der Emacs- oder vi-Varianten. Modernere Menschen vermutlich eher so etwas wie VS-Code, VS-Codium, Atom oder Sublime, die zwar im engeren Sinne keine hochintegrierten IDEs sind, sich aber extrem flexibel konfigurieren und erweitern lassen, wenn man mag.
Da kenne ich bisher nur PlatformIO und das ist wie erwähnt eher eklig.
Das liegt aber nicht an vscode, sondern am (auch meiner Ansicht nach)
sehr umständlichen Buildprozess und der unnötig komplizierten und
unflexiblen Sourcecodestruktur.
Aber dafür gibt es halt durchklickbare Assistenten, die Dich an die Hand
nehmen, um irgendwas zu erreichen. Die brauchen wohl den umständlichen
Buildprozess und die Sourcecodestruktur.
Wir haben das im CoderDojo als "pofi ArduinoIDE" empfohlen bekommen. Es ist aber IMHO vor allem eines, und das ist undurchsichtig.
Gerade als Anfänger sollte man sich doch mit "echten" Sachen befassen! Wenn es nicht gleich ASM sein soll, dann doch zumindest etwas wo man auf die IO-Reg des AVR noch selbst zugreift. Wenn man schon die alten AVR nutzt, bei denen das noch geht!
Gerade als Anfänger sollte man sich doch mit "echten" Sachen befassen!
Was hat das mit der verwendeten IDE/dem verwendeten Editor zu tun?
Gerade die Vorgehensweise, die mit vscode möglich ist (Kommandozeilencompiler etc. aus der Toolchain via selbst konfigurierbarer "Taks" aufrufen), bietet hier doch die größte Flexibilität.
Und wenn einen das überfordert, kann man das auch sein lassen und nutzt vscode nur als reinen Texteditor, mit etwas anderem Komfort und Bedienkonzept als "vi" oder "emacs".
Das Kompilieren muss man dann halt selbst in der Kommandozeile anstoßen.
Allerdings, wenn man das hinbekommt, kann man sich darauf auch o.g. "task" basteln, das ist keine Raketenwissenschaft.
Ob man den µC nun durch irgendeinen Abstraktionsschichtkuchen anspricht, oder direkt auf dessen Peripherieregistern herumklimpert, ist davon aber vollkommen unabhängig.
Ok, dann verstehen wir uns. Ja, das versucht einen etwas zu gründlich an die Hand zu nehmen, und macht --ganz wie das Original-Arduino-Zeugs-- viel zu viel irgendwo hinter den Kulissen.
Und es hält sich nicht an die Spielregeln. Vscode kennt die Betriebsart "portabel"; jedes Plugin, das sich daran hält, hat seinen eigenen Krempel, den es herunterlädt, dann im "portablen" vscode-Verzeichnis einzusortieren. platformio aber schert sich nicht darum, und packt seinen Kram dennoch irgendwohin ins Benutzerprofil-/Home-Verzeichnis.
Und es hält sich nicht an die Spielregeln. Vscode kennt die Betriebsart
"portabel"; jedes Plugin, das sich daran hält, hat seinen eigenen
Krempel, den es herunterlädt, dann im "portablen" vscode-Verzeichnis
einzusortieren. platformio aber schert sich nicht darum, und packt
seinen Kram dennoch irgendwohin ins Benutzerprofil-/Home-Verzeichnis.
Wir schweifen ab... ...egal.
Ich wußte nicht, dass das so gut geordnet ist. Wobei das .net Plugin auch eine ~/.dotnet anlegt, e.v. habe ich es aber auch falsch installiert.
BTW die ArduinoIDE legt einen ~/.arduino einen ~/Arduino und einen ~/.Arduino15 an. Die Lib sind ja teilweiße ganz cool (wenn Speicher egal ist) aber einige C++ Libs brauchen keine drei Verzechnisse in ~
Hast Du denn die "Portabel"-Betriebsart aktiviert?
Nein :/
Werde ich aber machen. Mich nerven überhaupt die ganzen versteckten Ordner im ~. Also nicht nur von VSC sondern auch von anderen Programmen. Ich habe bisher noch keinen (guten) Weg gefunden das zu vereinfachen aber das mit dem Prtabelmode von VSC ist in jedem fall hinfreich.
