Workflow der Terkin Sandbox mit WSL und VSCode für den Upload (hier Pycom Device)

Entwicklung / Development Firmwareschmiede / Firmware development
, ,
1

Das aktuelle Problem mit dem Deepsleep meines Pytrack (als Unterbau für den Lopy4) hat mich dazu gebracht, dass ich die Terkin Sandbox mit WSL und VSCode jetzt zum Laufen gebracht habe. Soweit klappt das bisher auch. Ich kann von VSCode auf die Verzeichnisse der WSL zugreifen und dort entwickeln. Was sich mir bisher nicht erschlossen hat der Workflow zum Upload der Änderungen auf den Lopy.
Mit make install-ng wird alles fein vorbereitet und der cross-compile läuft auch durch. Der Upload startet und gibt fleißig immer Checking FILENAME aus. Es werden aber scheinbar keine geänderten Dateien erkannt und demnach keine Dateien auf dem Lopy ausgetauscht. Ändere ich zum Testen z.B. einen Text einen log.info(''), so wird diese Codeänderung nicht zum Lopy übertragen. Erst wenn ich den Flashspeicher des Lopy komplett lösche und dann per make install-ng übertrage sehe ich meine Änderungen.

Mache ich da im Workflow etwas falsch für die Syncronisierung? Andere make Variante vielleicht?

VG,
Jan

1 Like
2

Hi Jan,

schön dass Du Dich schon so weit vorgearbeitet hast und dass das Setup über WSL schon so gut funktioniert, sogar inklusive cross-compile via “make install-ng”.

Ich kann mich dunkel erinnern, dass es noch Probleme mit den Datei-Zeitstempeln gab, so dass unter manchen Umständen die Änderungen nicht so erkannt wurden, dass eine inkrementelle Übertragung möglich war. Zumindest hatte ich das bei mir auf macOS beobachtet und mich darum bemüht, die Situation zu verbessern [1].

Da die Übertragung über USB/UART mir aber bei zunehmender Größe unseres Datenloggers trotzdem zu lange dauerte, obwohl die Größe der Dateien durch die Bytecode-Kompilierung ja bereits reduziert wurde, bin ich dann dazu übergangen, die Übertragung per FTP zu erschließen [2]. Entsprechende Dinge habe ich damals bei Operate the Terkin-Sandbox using the MicroTerkin Agent dokumentiert, leider hatte sich jedoch bei Entwicklung der Terkin-Sandbox ff. herausgestellt, dass wir diese Variante nicht so einfach unter Windows fliegen konnten, zumindest nicht unter “Windows native” – ich weiß nicht, ob wir “Windows/WSL” damals in diesem Kontext genauer untersucht hatten.

Wie der aktuelle Stand des Ökosystems ist, kann ich leider nicht genau sagen, da ich schon eine zeitlang nicht mehr damit gearbeitet habe. Auch zu speziellem Verhalten unter Windows kann ich nichts beitragen, da ich auf macOS arbeite. Aktuell benutzt Du ja auch ein aktuelles offizielles Firmware-Release von Pycom, richtig?

Unter Umständen würde es für einen Entwicklungsbetrieb unter Windows sinnvoll sein, auf die make-basierte Übertragung zu verzichten und rein per VSCode/Pymakr zu arbeiten und zu synchronisieren. Wenn das an der Stelle gut gelöst ist, sollte das ja dann nur die geänderten Dateien übertragen?

Ich weiß, dass sowohl @MKO und @clemens als auch ganz besonders @poesel sich damals so ein Setup draufgeschafft haben und durchaus passabel damit arbeiten konnten. Vielleicht können Dir beide an dieser Stelle weiterhelfen oder auf entsprechende Dokumentation verweisen? Danke!

Herzliche Grüße,
Andreas.

  1. Soweit ich mich erinnern kann, handelte es sich damals um entsprechende Verbesserungen am rshell Programm, siehe

    Es waren aber auch weitere Verbesserungen an der Pycom Firmware notwendig, siehe

    Murphy tauchte hier damals an allen Ecken und Enden auf – furchtbar ;]. ↩︎

  2. Dabei bin ich dann auf Don't invoke MicroPython's "m_malloc" within C-level RTOS extensions gestoßen (Murphy again!). Die entsprechenden Nachforschungen und Verbesserungen, die dann zu Fix core panics: Don't use m_malloc and gc_malloc unintended by amotl · Pull Request #418 · pycom/pycom-micropython-sigfox · GitHub geführt haben, haben mich einiges an Nerven gekostet. Siehe dazu auch Core dump during FTP file transfer, caused by a heap lock. · Issue #443 · pycom/pycom-micropython-sigfox · GitHub. ↩︎

3

Läuft bei dir VS im WSL Modus?(muß als Erweiterung installiert werden.) Oder arbeitest du in 2 Fenstern VS/WSL? Gab da glaube ich ein paar Probleme mit gleichzeitigen Zugriff von Windows und WSL auf die Dateien.

4

Ich hatte es bisher in zwei Fenstern versucht, wobei VS auf den Order \\wsl$\Ubuntu-18.04\home\jake_hh\terkin-datalogger\src zugreift, also quasi aus Windows heraus.

Das WSL-Plugin habe ich vorhin mal installiert, aber noch nichts damit gemacht. Ich versuche das mal, danke!

5

Diese Variante hat @poesel benutzt, wenn ich mich nicht täusche. Vielleicht kann er dazu noch ein paar Tipps beisteuern?

6

Mit dem Plugin hast du dann die Bash gleich unten in VS mit drin. Die PyMakr erweitrung muß im VS(WSL) auch noch ein 2.mal installiert werden. Dann hast du auch ein automatisches REPL. VS(WSL) ist fast eine eigenständige Version.
Die das geclonte Verzeichnis befindet sich bei mir im Windows Dateisystem.
So daß ich Git mit einer Benutzeroberfläche nutzen kann. Geht mit entsprechendem Plugin auch direkt aus VS Code aus.