Ich hatte in der Vergangenheit in Visual Studio Code (VSC) immer mal das Problem, dass Projektwechsel nicht erkannt wurden. Will heißen: Ich habe in VSC so 10 bis 15 Projekte drin und da ist es mir oft genug passiert, dass ich aus ESPuino heraus in ein anderes Projekt gewechselt habe und bei „BUILD“ dann aber doch ESPuino kompiliert wurde. Ich habe dazu dann ein bisschen recherchiert und da stand, dass eigentlich immer genau das Projekt aktiv sein sollte, zu dem die Datei gehört, die man gerade geöffnet hat.
Das Problem hat sich vor einer Weile ein Stück weit für mich gelöst, weil ich seitdem um unteren Bildschirmrand das Environment (env:…) festlegen kann - siehe Screenshot.
Wähle ich das Passende dort aus, öffnet sich auch der passende Projekt-Task und das Kompilieren + Flashen ist kein Problem mehr.
Nun hat mich ein Benutzer angeschrieben, der mit dem Gesamtprozess Probleme hatte und auf seinen Screenshots erkenne ich auch, dass er ENV unten nicht konfigurieren kann. Ich weiß ehrlich gesagt nicht, wie es bei mir dorthin gekommen ist; vielleicht hat es auch mit dem Plugin Gitlens zu tun!?
Kurzum: Ich wollte einfach mal fragen, wie ihr das so macht. Bei mir ist die Einrichtung halt schon 2,5 Jahre her und insofern weiß ich nicht mehr so genau, was ich da wie genau gemacht habe. Ich denke das würde auch Einsteigern hier helfen und ich würde es entsprechend verlinken.
Danke für den Hinweis , mir passierte das auch ständig und ich habe mir immer geholfen indem ich alle Projekte bis auf das aktuelle mit " Remove Folder From Workspace " entfernt habe.
Das Environment habe ich auch , habe es aber bis eben nicht beachtet und wie es dahin gekommen ist weiß ich auch nicht .
Das war auch ganz sicher mal so aber seit einigen Monaten nicht mehr ???
Diejenigen, die das Fenster nicht haben: Vielleicht einfach mal unten auf der Statuszeile einen Rechtsklick mit der Maus. Bei mir heißt das „PlatformIO: Project Environment Switcher“. Das muss dann wohl angehakt werden. Hat demnach also nix mit Gitlens zu tun.
Als Neueinsteiger hier mein Input:
Die Auswahlmöglichkeit „env“ unten am Fenster erscheint erst nach Installation von PlatformIO + Neustart bzw. Neuladen (wenn man den Button nach Installation klickt).
Aber auch mit der Auswahlmöglichkeit stehe ich erstmal nackig da, da ich keine Ahnung habe, was ich auswählen soll. Sind das unterschiedliche ESP varianten mit unterschiedlichen Pinouts auf den Boards? Ich habe diese „ESP-WROOM-32“, die ich in der Arduino IDE als „ESP32-WROOM-DA Module“ auswählen muss. Ich nehme mal an, dass ich die Pins entsprechend zuweisen muss. Sonst irgendwas zu beachten?
Also im Laufe der Zeit habe ich mit verschiedenen ESP32-Develboards gearbeitet:
Lolin32: Vorgänger von Lolin D32
Lolin D32: Kleiner Bruder des Lolin D32 pro (Wroom statt Wrover, kein SD-Slot, kein i2c-Slot)
Lolin D32 pro: Pinkompatibel mit Lolin D32 (GPIO 16 und 17 fehlen aber) AZDelivery Devkit: Wird viel via Amazon vertrieben. Gibt es in zwei unterschiedlichen Varianten soweit ich weiß (unterschiedliche Anzahl der Pins / GPIOs).
TTGO T8
ESP32-A1S
Dazu kommen dann noch mein FePo-Develboard und mein E32 LiPo, wobei die 100 % pinkompatibel sind mit dem Lolin D32 pro. Das ist insofern wichtig, weil man dann das gleiche env verwenden kann.
Da das Zusammenstecken sehr mühsam und fehleranfällig ist, habe ich angefangen, Platinen dafür zu designen. Und da dort die GPIOs nicht mehr nach Belieben geändert werden konnten, aber ich Config-Profile geschrieben, die sich letztlich in den env-Profilen wiederfinden. Sie mappen auf die settings-.h im Unterordner src/. Wobei hier noch anzumerken ist, dass es teilweise pro Develboard mehr als nur eines gibt, weil eines SD über SPI anbindet und ein anderes halt für SDMMC 1 Bit.
Wenn du keine Platine von mir nutzen willst, dann kannst du dir davon im Prinzip auch eines anpassen. Du solltest jedoch keines mit „pro“ verwenden, da hier 16 MB Flash erwartet werden; das hat dein Develboard nicht.
Musst dir halt überlegen, ob das von dir gewählte Develboard zielführend ist. Als Festspannungsregler ist ein AMS1117 verbaut, der sich aufgrund seines hohen Verbrauchs nur sehr bedingt für Akkuanwendung eignet. Zudem besitzt das Develboard keinen Akkuanschluss. Das ist beim o.g. DevKit aber auch so: Das habe ich halt entwickelt, weil ich oft danach gefragt wurde, da diese Boards sehr verbreitet sind in .de. Wenn man nicht den Anspruch hat, dass der ESPuino mit Akku laufen soll, ist das tatsächlich auch egal (der ESP32 ist der Gleiche).
Ach, das ist ja toll, ich schreib dir gleich mal. Ein Hauptgrund für meine Wahl war USB-C. Ich habe schlicht keine Lust mehr auf den nervigen, wackligen und damit fehleranfälligen µUSB. Ich finde nicht mal ordentliche Kabel (oder Adapter von USB-C), wo die Haltenasen nicht bald in der Versenkung verschwinden und damit nicht mehr halten und zum Wackelkontakt führen. Jedenfalls sind die Boards aber offensichtlich schlecht dokumentiert, selbst der Pinout ist nicht zu finden, womit ich im Leben nicht gerechnet hätte.
Der Spannungsregler wäre kein Problem, ich habe hier noch einige mit sehr niedrigem quiescent current rumfliegen. Das war für mich im Rahmen von Datenloggern schon immer ein großes Thema, den Stromverbrauch in den Bereich der µA zu drücken.
PS: Warum nennst du LFP Akkus eigentlich FePo? Das „Po“ klingt wie Polymer (analog LiPo), dabei meinst du normales LiFePO4?
