Hey, ich brauche mal eueren Rat! 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. MFG Florian
Florian schrieb: > 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?
Moin, 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? Gruss WK
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. MFG Florian
Ein T. schrieb: > Auch für eine SSD ist PCIe völlig > überdimensioniert, solange damit nicht in Wirklichkeit eine NVME gemeint > ist. > Ja ich meinte NVME (die für den M2.2 M-Key in Laptops und auf kleineren Mainbords)
Florian schrieb: > 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. fchk
Frank K. schrieb: > 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. Florian
Florian schrieb: > 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. Besser ist das. fchk
Frank K. schrieb: > 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). Florian
Florian schrieb: > Die HATs für den RPi 5 machen die IMHO auch nur Gen. 2 (muss natürlich > nicht sein IK). Wenn die das einzige Argument sind, dann lass die Finger von dem Latte Panda und nimm was anderes, wo Du keine HATs brauchst. fchk
Florian schrieb: > Intel 86x währe schon von Vorteil. Darf ich fragen, warum? > 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.
Moin, 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... Gruss WK
Florian schrieb: > 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. MFG Florian
Moin, Harald K. schrieb: > Und auch da gilt das gleiche. Das seh' ich genauso. > 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 :-)
:
Bearbeitet durch User
Ein T. schrieb: > Darf ich fragen, warum? 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. Florian
Dergute W. schrieb: > Edit: oops, zu langsam, um auf die neusten Erkenntnisse des TO zu > reagieren :-) Wer zum Geier is Edit?!
Florian schrieb: > Weil manche (ja auch welche für Linux!!!) Programme auf ARM nicht > wirklich funktionieren. Aha. > Ich mag dann keine Programme selbst kompilieren > müssen, die es für Intel 86x fix und fertig gibt. Keine Arme, keine Kekse. Insbesondere, wenn man meint, mit Linux unterwegs sein zu müssen.
Florian schrieb: > 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.
Ein T. schrieb: > 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. 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. LG Florian
Florian schrieb: > 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. Das ist kommerzielle Software, davon gibt es nur fertig compilierte Binaries, und zwar praktisch ausnahmslos x86_64-Binaries: > MPLAB X IDE only supports computers with processors based on > Intel® 64 or AMD® 64-bit architectures or Arm®-based Apple® silicon Ja, da steht auch ARM, aber das bezieht sich nur und ausschließlich auf das macOS-Binary. Florian schrieb: > aber da gibt es meistens nur 86x Makefiles 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.
Harald K. schrieb: > 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. MFG Florian
Florian schrieb: > Ein T. schrieb: >> 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.
Moin, Florian schrieb: > 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... Gruss WK
Ein T. schrieb: > Aber gut, das ist letztlich ja Deine Wahl, nicht meine. Naja ich hatte auch nichts das für ARM spricht...
Florian schrieb: > 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?
Harald K. schrieb: > 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). MFG Florian
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: https://code.visualstudio.com/docs/setup/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.
Harald K. schrieb: > 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.
Florian schrieb: > 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.
Florian schrieb: > 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.
Harald K. schrieb: > Florian schrieb: >> 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! MFG Florian
Florian schrieb: > 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.
Harald K. schrieb: > Was hat das mit der verwendeten IDE/dem verwendeten Editor zu tun? > Eh nichts, meine nur PlaftormIO. Eigentlich ist VCS nur ein Editor, damit kann man machen was man will.
Florian schrieb: > Eh nichts, meine nur PlaftormIO. 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.
Harald K. schrieb: > 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 ~ MFG Florian
Florian schrieb: > Ich wußte nicht, dass das so gut geordnet ist. Hast Du denn die "Portabel"-Betriebsart aktiviert? https://code.visualstudio.com/docs/editor/portable
Harald K. schrieb: > 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. MFG Florian
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.